Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Edir: ok I looked it up and yeah I can see how this goes here now, but I doubt most people here even know what this is... or even would care.
Also the Green/black belt made me think Karate, at 1st
In order of appearance:
1) Is he talking about Karate?
2) Does he want to paint belts?
3) Cannabis involved?
4) Is that the New Generation speaking?
All of those models are already rough abstractions, and following the books on them is just an exercise in removing the important context of the work in favour of chasing useless metrics. If you want to train a team in quality assurance and making things work, Satisfactory could be a useful tool... IF you start by throwing the "rules" out the window, and instead make it into a set of free-form goals with no 'correct' solution ("achieve X PPM of Y part without using Z technology"; or "get to coal power inside of 1 hour using a team of 5 people where only 1 person can use the workbench to craft" -- challenges that have restrictions and limitations which require your team to analyse those limitations and figure out how they fit together) and then let your engineers/entire team figure it out on their own. That practice will be more valuable than trying to apply an already-inaccurate and reductive model to an even more inaccurate and reductive simulation that takes a physical impossibility (infinite resources from nodes) as its core premise and then twists everything to try and work with that.
The valuable bit isn't even the 'being able to come up with a solution'; it's the being able to justify why that solution works/achieves the goals and analyse how effectively it does so. The more that you constrain the problem-solving model with sets of rules/best practice/dogma, the less of the valuable understanding you gain along the way.
All of the models out there that spawned from JIT are attempts by people who already figured out a solution that works in THEIR specific context to explain their solutions to others who hadn't got that far yet; but so many people mistake the resulting breakdowns as "this solution will work in any context." Worse still, the creators of the more modern systems like LSS are stupid enough to believe that too, because they were brought up with the idea that JIT would be a one-size-fits-all solution (they're just "improving upon" it.)
Satisfactory is what happens where people who forget how to play (or whose idea of playing is showing off their complex technical skills) try to make a 'game' based on gamifying the concept of work. Trying to use said game to gamify the learning process of a real-life work method is, while perhaps ironically appropriate, probably one of the worst ideas I've heard this week. And given that I ditched out of engineering to go run kids' (and adults') parties in an arcade bar, said bad idea has some stroooooooong competition for that title this week alone -- it's going up against "hey let's all jump on the couch and see if we can make the bottom hit the floor!" (no, they couldn't -- actually they couldn't all even fit on the couch), and "if I steal this plushy and get a running headstart down the road they won't ever catch me!" (we didn't bother giving chase -- we sent an email to the dude's workplace that had booked their group Christmas party; he came back the next day to return the plushy and apologise profusely after his boss chewed him out for nearly getting their whole branch of the company banned from their new favourite venue)
I may not be a Brain Genius, Sigma Six Certified engineer but I do work in a place that requires rapid on-the-fly problem solving and a keen understanding of priorities and what values we want to focus on in this moment. Engineers (especially software engineers) come to my workplace all the time to cut loose and have fun, and the core part of my job is to 'surprise and delight' them -- one of the easiest ways to do that is challenge them to a game, let them think they have it all figured out, and then annihilate them by taking advantage of a rule or technique that they never thought to explore. Engineers get tunnel vision really, REALLY easily.
If you want to indoctinate your team into the specific dogma of S6/LSS, yeah Satisfactory could be useful for that. My question is... why in the ever-loving ♥♥♥♥ would you want to do that to them? All that relying on these models ever achieves is ruining perfectly good engineers by giving them even worse tunnel vision and training them to chase metrics over actual results.
Save your org some money: buy copies of Satisfactory instead of the guidebooks/textbooks, and tell your people "ok, treat this videogame as a puzzle to solve; and then use the experience as a lesson on what NOT to do when designing your own goals and workflows." The only thing that Satisfactory is really really good at is slowing down your progress so that you can do more work to get to the same place.
But then after reading: It's not
Must be an encrypted language, something like the Enigma Code during WWII
im always a bit skeptical when people try to implement Lean thinking in non production industrial contexts (like in office environments for instance), but games like this is literally about production industry so i think some lessons should be able to be learned from them.
A good joke doesn't require "Research" being done by the people its directed at.
This "Joke" is a complete FAIL, on the grandest terms of FAIL.
Some kind of QM/QA LSS process enhancement ♥♥♥♥♥♥♥♥, that forces real production facilities to run errands around every new product because a horde of managers all have to contribute to a partial more effective way to do things. With these models you end up with amazon workers having to pee in a bottle because nobody thought about the human factor anymore.
For once, I think you and I can agree on something: Satisfactory could be a good tool for teaching broad engineering concepts. Like identifying bottlenecks in a manufacturing process, for instance. Or the trade offs that come up in any engineering design space.....there are too many examples to list them all, but for a simple example I'd go for the two recipes for encased industrial beams. The default recipe produces more EIBs per minute, but the alternate recipe is more steel efficient. For a complex example, I'd point to the various ways we can make steel ingots, and the advantages and disadvantages of each.
ISHYGDDT