As I had mentioned in a previous blog (Engineering driven PLM versus Manufacturing Driven PLM "Clash of the Titans") my son has become fascinated with Greek mythology due to a series of books written by Rick Riordan titled Percy Jackson and the Olympians. Growing up I was also fascinated by Greek mythology and am always struck by how much it is still a part of our language and culture thousands of years later. One of my favorite stories is The Odyssey by Homer. In the story Odysseus, a Greek king is trying to get home to his wife and son and is presented with various challenges along the way that prevent him from seeing his home. One of these challenges was the Scylla and Charybdis. His ship was forced to sail between the Scylla, a horrible man-eating monster that was poised above on a rocky cliff and Charybdis, a whirlpool that would pull his ship to a watery grave. This story is the origin for the modern saying "stuck between a rock and a hard place". Odysseus chose to avoid the whirlpool because it could take his entire ship down and deal with the lesser perils of the monster from above. After all how many men could the monster actually eat? Twelve, I think. This obviously parallels situations in our modern world where companies are often forced to choose the lesser of two evils when resolving process and technology issues with Product Lifecycle Management (PLM). Engineering collaboration in particular is an area where companies are forced to compromise in one way or another to try and satisfy the diverse needs of a company.Engineers typically require fairly sophisticated solutions to maintain the relationships between the various parts and assemblies they create. They also tend to generate large amounts of data that can be used downstream for analysis, manufacturing and simulation. These large data sets with their multi-layered dependencies require a very robust solution that typically can only be provided by a CAD vendor like PTC, Siemens, or Dassault. Unfortunately, these solutions while ideal for managing engineering data can be ill-suited for the rest of the organization. This forces companies to compromise when selecting their PLM solution often saddling one organization or many with a tool that is not optimal for their requirements. This article will review the experiences of some of our clients and their struggles to reconcile their engineering departments with the rest of their organizations. It will also detail some of the issues companies encounter as they struggle with addressing the divergent needs of their company and some possible solutions.

One of the biggest issues companies encounter when trying to integrate engineering with the rest of the company via PLM is the dynamic nature of this environment. Successful companies generate large numbers of products and in order to generate large numbers of products even larger numbers of potential products must be created. To be successful an engineer needs to have the ability to iterate and experiment. Many of their ideas may not come to fruition and will never see the light of day. PLM systems are structured and are designed to track data that is submitted, to assign part numbers and to put the information under release control. Obviously this type of structure is not very popular in engineering circles. Even traditional CAD product data management (PDM) solutions are viewed with suspicion and loathing by some engineers and designers. They want the freedom to create while management wants to be able to safeguard their output and leverage it across the enterprise and possibly reuse it for other products. They want engineers to have visibility into things like cost and delivery so they can factor that into their design choices. They want manufacturing and purchasing to have early access to engineering information so that they can provide feedback and begin to prepare for new product development. They want to be able to leverage external partners for portions of the design to accelerate the process. Balancing the engineer's and designer's need for creative freedom with the need to manage this process has always been challenging. PLM has upped the stakes significantly. PDM tools are merely vaults with access control and maybe some light release management. PLM is a far more comprehensive solution that opens up the engineering environment to the rest of the enterprise. This creates significant anxiety for engineers and to assuage these concerns CAD vendors put in elaborate access control solutions that can ultimately create a quagmire for administrators and end users. This leads to one of the most common objections I hear about CAD based PLM solutions when I am interacting with clients. The user experience with these types of solutions is problematic. Engineers are accustomed to intricate user interfaces based on their experience with CAD systems. While CAD systems are becoming more and more accessible they are still fairly involved applications compared to Excel, Word, or even most ERP systems. CAD vendors must appease their engineering clientele by providing them with a robust and sophisticated solution that will meet their needs to control data and prevent others from inadvertently accessing wrong information or overwriting current information and do this in a way that doesn't hinder their creativity. It's a pretty tall order! On top of that they have to make sure that the interface does not inhibit adoption by the rest of the enterprise which is an even taller order, hence the rock and the hard place. In most cases based on the feedback I have received there is still significant work to be done to make CAD based PLM solutions more compatible with the enterprise.

When you vault CAD binaries in a PLM the stakes rise immensely. The PLM must have a data model that can capture the design product structure. The architecture must be able to support the transmittal of large amounts of information. The security must ensure that the information is locked up tight to avoid theft or error. All of these things impact the user experience from an interface and speed perspective. On the other hand not having some sort of engineering data in your PLM can severely cripple the benefit of having PLM in the first place. Many companies avoid the whole issue by adopting a user friendly PLM that either has no ability to capture CAD information or allows adoption without engineering. I am sure these systems yield significant benefit to the companies or they wouldn't bother putting them in place but they are missing a huge value opportunity by excluding engineering. I mentioned some of the benefits above but in general having everyone connected to the same system with a single data vault is preferable. This ensures early access to engineering which allows for optimization of cost and delivery. Change management becomes a much more integrated function and change is obviously one of the major drivers of product cost and delays. Early access minimizes late change and having engineering integrated into the change process gives you the ability to respond more rapidly. Some of this can be done without having engineering data in the system but it requires a lot of manual work to get product structure synced up between engineering and the rest of the company.

I think we can all agree that having engineering integrated in with the rest of the enterprise via PLM is a desirable goal. The question becomes how can a PLM system be robust enough to meet the needs of engineering without saddling the rest of the organization with poor performance and a daunting user interface? To link it back to my analogy do we choose the whirlpool that will take the entire company down or do we steer towards the rocks and the scary man-eating monster? We will explore a couple of solutions from Oracle that can possibly give companies the best of both worlds. Oracle offers an Engineering Collaboration module for most major CAD tools that allows engineering data to exist in their Agile PLM environment but as a separate design object. This gives engineers the freedom to control access to the information by only publishing out what they want the rest of the company to see. It is also a fairly open environment that gives them the opportunity to iterate if they choose. Unfortunately as I mentioned earlier CAD tools are very complex and sometimes third party solutions fail to meet the engineer's needs. In these cases it is possible to allow the engineering information that we term "work in process" (WIP) to stay in the authoring tools PDM application and use connectors to publish over to the PLM environment based on state changes like release or another type of promotion. This approach allows the engineers to use native tools and keep their environment relatively unchanged but gives the enterprise visibility when appropriate and doesn't burden the enterprise with overly sophisticated or complex interfaces and large data sets that can impact performance. Over the next four months we will demonstrate both types of approaches with Oracle to allow companies that are struggling with this issue to see what choices you have when navigating the treacherous waters of PLM integration to engineering. Hopefully our webinars with allow for smooth sailing and clear skies. Below we have a couple of short examples that show each approach. Click on the buttons if you want to see a short demonstration. We will go into more depth in the webinars.