Information and process silos. For manufacturing organizations silos is a problem that slows down innovation and enterprise software efficiency regardless on what new product and technologies are you buying from software vendors.
The days when engineers were able to throw the design over the manufacturing wall and forget about it are over. Today, the demand of customers is to have seamless data and process integration between design, engineering, manufacturing, support, maintenance. Easy to say, but very hard to do.
My attention was caught by Engineering.com article – PLM This Week: PLM Investment Points Upwards – Accenture Pushes IBM Off the “Provider Throne”. One of the topics discussed there was related to how manufacturing companies will be able “to digest” all PLM related investment they made for the last couple of years. Apparently, integration of silos is still one of the key problems to solve.
The period of digestion that Marc Halpern refers to seems to be over, and companies are ready to develop their PLM solutions further. This is indicated by both the 2014 numbers and a strong start going into 2015. There are two primary aspects to this. First is the need to strengthen their ability to innovate, which is one of the key drivers according to CIMdata analyst Stan Przybylinski. The second is their efforts to integrate product development and manufacturing. Regardless of the new technologies that have emerged during the last few years, these two basic requirements are still of utmost importance. This once again proves that among larger organizations, more sophisticated levels of seamlessness and smooth processes are needed to break down existing silos.
In one of my last year articles, I shared thoughts why Manufacturing future will depend on solving old PLM-ERP integration problem. Engineering.com article made me think about it again.
So, data an processes are living in silos. What patterns and tools manufacturing companies can use in 2016 and following years to solve a problem. I can see 3 possible strategies for that.
1- Focus on single vendors and demand for vertical integration between tools.
This is one of the oldest strategy. Basically, the headache moves from your side to the vendor (usually ERP or PLM vendor) that will do all heavy lifting of vertical integration. You will be limited to use only tools provided by a specific vendor and vendor will make a commitment to integrate tools. Not bad, but it can potentially lead to vendors lock-in and some other unpleasant surprises related to product and service cost.
2- Build a better integration middleware or processes for existing tools.
A traditional middle ground between vendor lock-in and integration efficiency. Middleware is usually a software provided by vendors focusing on integration. There are many of these vendors around and you can pick one based on your domain, tools, data, etc. Usually vendor or another service company will do customization development to tailor product to a specific needs of your company. It works for very large companies. These products and services are usually expensive.
3- Unbundle software services for product development and manufacturing
Last year, I was talking about unbundling strategies. Navigate to my post to read more. Unbunlding is especially interesting when cloud/ SaaS options can be introduced. New type of tools can come to support specific tailored processes by re-using existing services of cloud and desktop tools. These tools will be focusing on seamless product development and manufacturing integration and provide a front door for users and companies development processes.
What is my conclusion? Data and process silos are hard. I can see manufacturing companies will be trying to implement and leverage all acquired PLM assets in coming years. But as ROI will slow down and integration complexity will raise, company might decide to check alternatives such as a better integration middleware or new (unbundled) services that will help to rationalize future of seamless product development and processes. Just my thoughts…
Best, Oleg
