It’s time to get your game on with gamification. On some level the word “Gamification” is an abuse of the English language, and until relatively recently, it wasn’t remotely a word at all. Just as technology constantly evolves (or devolves depending on your date of birth and/or propensity for crankiness), so does the language. Oxford English Dictionary nominated “Gamification” as one of the candidate words of the year way back in 2011. Strangely, “Gamification” was ultimately bested by “Squeezed Middle” which looks awfully like two words to me, but I digress. But what the heck is gamification? Any official definition is in a state of flux as the concept tries to gain traction, but quite frankly we’re used to that here in engineering and technology circles. For example – ever tried to define Product Lifecycle Management lately? Gamification, in essence, is the application of game design principles outside of gaming. And when we say gaming these days, we’re invariably talking about electronic gaming. Sorry, Chutes and Ladders.
Enterprise software, especially Product Lifecycle Management (PLM) Enterprise Resource Planning (ERP) is complex both from a functionality and integration perspective. Whether such software must necessarily be complex is a topic for another time. Success in any Enterprise software implementation often requires dedicated resources, careful planning, technical expertise, executive sponsorship, and a receptive culture, among other things. Sometimes the results of such efforts are transformational, producing both measurable and significant business benefit. In other instances, however, enterprise software implementation attempts can and do fail, due to a variety of possible factors. My last post regarding PLM Startups instigated a bit of unexpected controversy with regard to PLM failure. In case you’re not up to speed catch yourself up with the last post here: Why We Need More PLM Epic Fails. The point of controversy, surprisingly, is contention about whether PLM failure exists at all. Despite the fact that all other Enterprise software implementation is known to fail, is PLM somehow –perhaps magically- immune?
Quick, what’s the most assured certainty in startup land? Grossly irresponsible valuations? Nope. Grossly profitable exits? Try again. How about failure. Glorious, unbridled, OMGWTFBBQ failure. Innovation is an inherently risky affair; pioneering new concepts and ideas requires the willingness to both discard and overcome both mental and physical barriers. Dear reader, take careful heed of the universal wisdom of FakeGrimlock, legendary robot startup dinosaur. He advises that if you line up enough failures, they can become the collective foundation for a win. The cumulative knowledge gained from iterative experimentation manifests true innovation; you have to keep throwing yourself at the wall of impossible until impossible no longer exists. And the end result is… awesome. But what does this have to do with Product Lifecycle Management (PLM)? Currently, very little. And that’s the point.
Right behind Stonehenge and an improbability drive, Geometric Dimensioning and Tolerancing (GD&T) is somewhat of an engineering enigma, if there ever was one. Developed as a language for precisely communicating design intent, the ASME standard has been in existence for over half a century. The benefits of GD&T are very real, providing a reliable and verifiable means to ensure parts function and interface as intended, while reducing scrap rates normally driven by unnecessarily restrictive rectangular tolerancing schemes. Yet, at the same time, GD&T is largely not institutionalized in engineering curriculums, nor is training widely delivered to engineers at companies of all shapes and sizes. Some companies hold an utter disregard, and don’t utilize GD&T at all in their engineering. Model Based Engineering (MBE) promising to annotate GD&T directly into 3D models as Product Manufacturing Information (PMI), continues to suffer serious adoption problems. Certainly, something is wrong.
One of the most frustrating aspects of the Product Data Management (PDM) and Product Lifecycle Management status quo is just how much of the core practice is steeped in a configuration management tradition, harkening back to the days of the battle of Dagorlad, or in other words, a really, really, REALLY long time ago. These time-tested configuration management rules have but one fault: they were chiefly devised in a world absent of all the seemingly magical computing technology of this age. Yet many are never revisited, because it’s more than just a simple matter of contemplating new possibilities, but rather an intractable struggle against well entrenched software and organizational foundations. There are many such hard tenets of PLM lore that are often quoted as absolutes, be it that tradition and entrenchment has lasted since the ancient days (about 1965 or so).
At the heart of any enterprise system, be it Product Lifecycle Management (PLM), Enterprise Content Management (ECM), or Enterprise Resource Planning (ERP), beats the steady pulse of change management. Truly understanding the evolution of any complex system necessitates some form of change methodology. It’s interesting though, that outside of engineering/manufacturing circles, change management in of itself seems relatively unknown. Even mention the term change management outside this realm of expertise, and the first reaction typically is “Oh, you must mean organizational change management.” Qualify the term as engineering change management or document/asset change management especially and (with a few exceptions) it’s generally a world of deer and headlights. Alarmingly, it seems the tenets of change management are to be forever confined to the a world of engineering complexity, not because of their lack of relevance but perhaps their lack of accessibility. In contrast, witness the explosion of web applications that focus on real-time co-editing of content, sacrificing structure for immediacy. As the pace of business accelerates, there is mounting pressure to adopt those immediate models. Is this the death of change management?