Any single Product Lifecycle Management (PLM) implementation is a unique combination of configuration and customization – a direct reflection of a particular company’s process, values, and structure. It’s a rare thing for PLM software to be introduced into a green field IT landscape, devoid of any data ownership competition or entrenched legacies. Not surprisingly, these pre-existing conditions color the solution, and uniqueness shines through even if two companies are executing on the exact same software platform. Long has the industry sought a magical Out of the Box (OOTB) alternative, something aiming to commoditize design and implementation as a simple turn-key package. Just add data, and a magical unicorn pops out, bringing transformational business process and rainbows everywhere. Certainly there have been no shortage of grand visions to achieve exactly that, but most such attempts have been rather disappointing. The common conclusion is you can’t get there from here; implementation must necessarily be unique. Companies are snowflakes. But snowflakes bring customization, and ownership costs rise considerably, becoming an adoption barrier. This is especially true for the little snowflakes, also known as Small-to-Medium Business (SMB). What to do?

The so-called OOTB solutions have all taken the best practice angle – the very same best practice that I’ve previously thrown under the bus in Monkey See, Monkey Do. Even if there were such as thing as a true best practice, how do they end up in the software? Driving toward an OOTB approach requires a software vendor to discover, vet, and implement best practices. As the vendor considers how to work discovered logic and functionality into their larger design roadmap, they must remain ever mindful of the economic rationale for doing so, especially if changes affect architecture limitations from decisions long since committed. So best practice OOTB functionality naturally derives from a software vendor’s largest and most lucrative customers, where the ends certainly justify the means. You can see the critical flaw in this development model, the assumption that what is good for the large conglomerate must also be good for everyone. Remember all the little snowflakes? Some of them just melted.

What’s needed is a balance between available choices and what is easily accessible. Up to this point, software vendors have struggled to load all of this into their products – trying to achieve some ultimate level of configurability, but there’s simply no way they can keep up with the little snow flakes and all their uniqueness. Those small companies won’t ever generate enough revenue for the vendor to get terribly excited about most of what they might want – after all software development isn’t free. And existing software won’t offer the right OOTB of functionality to attract more revenue. This chicken-or-egg scenario drives a familiar outcome: wholesale rejection of OOTB solutions and a slip back towards the pit of endless customization. Collectively holding your breath is probably not going to work. A solution requires a different outlook; the development burden must necessarily shift. Let the community decide. Don’t dictate the level at which any practice, best or otherwise, manifests itself.

There are many reinvented PLM wheels going round and round. Bits of customization, some of which are thematically similar, are constantly reinvented from one company to another. These are emergent practices that are so subtle and variable that there’s little visibility, understanding, or practicality from a software vendor’s perspective. Think about subtle but far-reaching examples – tools to help delete objects, or rename them, or manage workflows in bulk. These are the types of problems implementation teams are solving every day with customization. Except they have no easy way to share with each other – no way to build upon the shoulders of giants. Interchange occasionally happens at conferences, but a once-a-year activity is not effective. Resources like LinkedIn or other social networks help, but sharing a solution transparently is difficult – most end up highly dependent on customized data models. They’re not modular enough because the tools to create them don’t consider such a possibility. So even in the event of some level of collaboration, wheel reinvention continues unabated.

Quite a few people were intrigued about the idea of a PLM industrial super network in Big Amazing Colossal PLM Data, but lamented, given current barriers with IP and data security, how such a feat could be achieved. How do we possibly move from the remote PLM islands of today towards such an ideal? Well, how about a more modest first step. Instead of directly collaborating or sharing internal data – why not share solution components?  Provide the right tools such that any and all customization can be translated to a neutral context and easily shared. Permit the rise of emergent practices and subsequent mashups into newer and more interesting practices, wholly independent of any profitability concerns from the software vendor. Let the creativity flow and let the solutions justify themselves. It’s a way to give the little snowflakes choice without catering to them specifically. Reinvented wheels to rainbows.