Product Lifecycle Data and The Enterprise Software SNAFU
There is one downside of product development, and it usually does not become visible until it turns itself into an elephant inhabiting in the room: designing and producing technical objects generates a lot of data. Such data is usually called Product Lifecycle Data; in short, all the data created (and needed) to consistently plan the production of a product.
Product Lifecycle Data, despite the glamorous name, tends to be an inelegant, heterogeneous collection of spreadsheets, EDA/CAD files, code, scripts, documents, engineers' PTSD, and what have you. When things are small, each department usually does their own housekeeping of the data for the designs they own, and demand for this data outside the department tends to be very rare, if not zero. For example, BoMs (bill of materials) and inventories might be kept and maintained by a design engineer who also talks directly to the suppliers. But when things start to get bigger (in terms of system and organizational complexity), a supply or procurement department may pop up, and all of a sudden those BoMs and inventories become gold, as well as relationships with suppliers.
As growth accelerates, the budgeting activity (once an exercise of good faith between engineers) calls for a more professional and dependable approach, and the financial folks become very curious about how cost breaks down and builds up as well. To make things even more colorful, product variants appear, different versions of parts or components appear, and all this means that now someone or something has to keep track of what goes where, what version, what variant, what change has been introduced.
You get the picture: a surge of demand for product and production data, a surge of demand for higher quality of product data, a skyrocketing demand for cross-department coordination and configuration control. And spreadsheets become so complex that no one can get the formulas anymore.
Then, in an otherwise routinary meeting, someone drops the bomb:
“You know, we may need an ERP1…”
Or even spookier:
This moment tends to be neglected in the history of organizations, but it marks the end of the company’s age of innocence. It is the critical moment when it’s finally understood that the organization cannot go on by hoarding loose chunks of information all over the place, and enterprise software makes a triumphant entry, just like Monty Python’s legendary Spanish Inquisition4.
The enterprise software question is perhaps the grandmother of all the mothers of rabbit holes. It is a clusterfuck, and done the wrong way can seriously damage a company5. It contains all the ingredients a proper rabbit hole must have: vendor lock-in, learning curves, cross-department “pissing contests”, and thousands of hours of error-prone data migration done awfully manually by external parties who don’t have the right context but will still charge a good price for such a torturing task.
When selecting enterprise software, too many things must fall into place:
The ability of the enterprise software to grow with the business. How will the needs be different when the company is double or triple its current size?
The ease of integration between different building blocks of enterprise software: ERP with PLM, PLM with MRP, ERP with CRM. Acronyms, acronyms everywhere.
The long-term viability of the companies that created the various bits and pieces of enterprise software. Small software companies can serve niche industries very well, but a software vendor should be viable and responsive for the next decade or so. Solid customer support, training and updates are a must.
The overhead of managing the enterprise software and the IT resources they tend to require (and the cloud vs on-premises vs whatever discussion or cybersecurity concerns the IT crew will love to bring up).
The ease of integration with supplier data (which has to be highly secure) and with legacy elements of the organization. Project management tools, CAD tools, bug tracking tools, and more.
And perhaps most importantly, keeping the in-house software engineers distracted so they don’t end up proposing to develop the whole enterprise software themselves, unless your business is, well, enterprise software. It is good to send them on holidays when the ES question starts to heat up.
But, lost in the noise of the discussion above, one thing lurks as perhaps the toughest problem when needing to select ERP and PLM tools: lack of definition and awareness of the product hierarchy. Technical products tend to be boxes inside boxes inside boxes, and companies can go to very long lengths without making such hierarchical containment composition official, explicit and/or visible. And enterprise software must know it, and very deeply. The hierarchy is for sure implicitly defined (after all, we are assuming here that the organization has already shipped some products meaning that it managed to put boxes inside boxes), but still there is no common understanding what a subsystem is, what a sub-assembly is, or a component, or a part. Moreover, there is no unified agreement on how to uniquely identify elements, lacking for instance internal part numbers. Going shopping for enterprise software with all these details undefined can be a problematic endeavor, if it could be any more problematic. Making the product hierarchy (and an unambiguous terminology for the different levels of the hierarchy) very explicit up front, pays off, even at very early stages.
Last but not least, wherever the road might go in terms of enterprise software selection, it has to be done with an absolute, relentless, inflexible sponsorship from those in power. Adopting these kind of software suites across the entirety of an organization needs industrial loads of buy-in, discipline and adjustment to new workflows.
Any partial approach will keep people craving for having their spreadsheets back.