I attended Inbound last week. It is a conference hosted by a company called Hubspot focused on Inbound marketing. Hubspot founders, Darmesh Shah and Brian Halligan, were early proponents of this approach to marketing which discourages email blasts and phone campaigns and encourages companies to create valuable content for their target markets to attract customers. To this end, Hubspot has created a platform that combines elements of content management, customer relationship management and other elements that are typically addressed by a variety of applications. Shah, in his keynote warned about the dangers of the “Frankensystem” saying, “that if you own a Frankensystem it will eventually own you.” This is a similar message to what I often hear from vendors in the product lifecycle management (PLM) space. They warn of using multiple solutions to address product development and process management needs saying that the cost and effort required to maintain these systems will become overwhelming at some point causing ultimate failure and trauma. This article will examine the merits of this argument and whether or not there can be a truly all-encompassing system to meet a company’s product development needs.
Can One System Do it All?
The first point that needs addressing is can one system really do everything anyway? If you look under the covers of most enterprise solutions they are typically cobbled together from different technologies but rarely a unified technology. I guess the benefit is that maintaining it is the vendor’s problem but this isn’t always a good thing. I know of examples with vendors where companies are unable to upgrade due to compatibility issues within the vendors own products so there is not always security in a single system. The other challenge is that no matter how broad a solution’s footprint may be there is always some external touch point that will ultimately be required. No system is an island and you will either have other applications in the company like engineering solutions or financial solutions or even marketing solutions that will benefit from integration and data exchange. The other factor involves external companies or partners and the need to share data with their systems. Very few companies have the financial clout to mandate that their suppliers and partners use the same system and frankly, two instances of the same system can be harder to integrate than separate applications.
Is it Always a Bad Idea to Utilize Multiple Systems?
The second point is that is it always a bad idea to utilize multiple systems and does this create issues? It really depends on the level of integration you put in place. Most integration involves the exchange of ascii data and possibly binary files. There is a requirement for mapping the data from one system to another and rules around what actions warrant the sharing of information. This type of information can be fairly straightforward to share and doesn’t require substantial amounts of overhead. As I mentioned above most vendors will use this type of technology internally to exchange information within their own systems. The key point in deciding whether or not to employ multiple systems is to understand your requirements and what technology is required to meet your needs. Ultimately the question revolves around not if you need to integrate but how you integrate. Certain methods will create issues but properly executed integration should be a boon to any organization.
Single vs. Multiple Systems
The burden of proof for deciding about a single system versus multiple systems boils down to functionality and productivity. Integration by itself is not a reason to sacrifice capability unless it is offset by a more appealing or beneficial capability. I will go back to the Hubspot example to illustrate this point. We were an early adopter of Hubspot because the concepts behind inbound marketing resonated with us and we knew it was the right direction to go but some the technology was inferior to systems we already had in place for web content management. We would have been taking a step back in capability if we had fully adopted the platform so we decided to utilize the elements of the Hubspot platform that we needed and to continue to use the CMS we already had in place. This strategy worked well for us and I suspect it is viable for many companies. An example that would apply to PLM is in the Computer Aided Design space. Most CAD products offer an application specific solution to manage engineering data. SolidWorks has EPDM, Pro/E has Intralink , AutoCAD has Vault etc. CAD data presents unique challenges when it comes to data management. The relationships between the files can be pretty complicated and the attribute information derived from the data can be fairly involved. If your engineering organization operates at certain levels of complexity it is generally true that the native PDM tool will offer superior functionality to an Enterprise solution
and that you will be compromising functionality if you forgo the native PDM. This does not mean that this is always the right decision. As I mentioned above, sometimes the single footprint can offer superior technology for the company at higher levels. Having your engineering data managed by the enterprise system requires that the engineering organization be fully integrated in with the rest of the company and know how to utilize the PLM. This can create synergies that outweigh the downside of less functional CAD data management. There are also viable technologies like our product DesignState that will integrate the native PDM tool with the enterprise application. The point is the decision should be made based on the merits of a single system versus the unfounded fears of an integrated one.
As I mentioned above, the method of integration is the more defining issue. More than likely you will be required to create integration solutions to disparate systems regardless of what PLM technology you choose. When creating integrations it is important to take a long view since you will most likely own your PLM for 5 plus years and have to survive multiple upgrades and possibly additional or replacement technology. Hardcoding integration is usually cost effective in the near term but limits your ability to change things and creates an unhealthy dependency on whoever wrote the integration. There are several technology solutions that can be leveraged for integration that will provide graphic user interfaces for creating the original integrations using object oriented architectures that are far more scalable than a hard coded integration. We have utilized platforms from Magic Software and Informatica to link ERP and PLM with very positive outcomes. The downside for these solutions is that the investment in the platform is substantial but if you have multiple systems to integrate or you expect the need to make changes will be significant that additional cost is well worth it. You will end up paying for the hardcoded solution 3-4 times during your ownership period versus spending smaller amounts to make changes through a platform. You can also invest in platform specific integration solutions like our DesignState solution or Oracle Design for Manufacturing Process Integration Pack (PIP). These types of solutions utilize a similar architecture to the integration platforms but are pre-configured to address a specific use case. This lowers the cost but gives you a similar robust capability and the opportunity to use the technology to make changes versus having to hire programmers to rewrite code. There are numerous applications like this you can purchase to lessen the risk and downsides around integration.
No matter which direction you choose there are always tradeoffs. The key is to understand the impacts of these tradeoffs and make a good decision for your company. There is no absolute pronouncement around enterprise versus best in class. Even if you elect to invest in an enterprise system you will still have integration requirements and the technology compromises could erode the productivity you hoped to gain with the investment in the first place. The key is be strategic about when and how you integrate. Make sure the solution will scale with your company and not create cost and time drains every time you upgrade or change process. Building bridges to islands of automation is not bad in and of itself as long as the bridges are built properly. Companies must discern whether utilization of multiple systems is truly in their best interest or whether there is genuine value in leveraging a platform where the integration is better disguised and the responsibility of a single vendor.