One of the best parts of my role at Jama Software® is working with firms and people with different sizes and products, and services. I enjoy learning about their goals and challenges. I really enjoy geeking out and digging into processes and associated tools to identify areas for improvement. One question I get asked often is something like “I have PLM, why do I need Jama Connect?”
It is a fair question, so let’s dig in.
It may be helpful to define Product Lifecycle Management. Instead of using the definitions from the major PLM players (Aras, Siemens, PTC, Dassault) I am using a couple of internet sources – because the internet is always right. Wikipedia and Investopedia define PLM respectively as:
- The process of managing the entire lifecycle of a product from its inception through the engineering, design, and manufacture, as well as the service and disposal of manufactured products. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise. Ref Wikipedia
- The handling of a good as it moves through the typical stages of its product life: development and introduction, growth, maturity/stability, and decline. Ref Investopedia
Seems solid. But notice it does not say anything about a PLM tool. That is because PLM is a collection of processes first and THEN software tools enable and operationalize those processes. Everyone gets hung up on the tool which is a mistake. Build a solid process and then assemble the best of breed tools to compliment your processes.
Let’s illustrate this with an example. As I write this looking out the window I realize I need to mow my lawn tonight. The process of mowing the lawn is really broken down into lower level processes that I can choose the best tools for me to perform the needed processes. Since I’m a bit of a geek I had to make a chart to illustrate this.
Each low-level process can be accomplished with a number of tools. I highlighted the options I use in red. For my needs these are best of breed. I care about speed and general cleanliness, so I use a riding mower and a backpack blower and I mow once per week. If I wanted a golf course quality lawn I’d mow three times per week and use the old school rotary mowers as seen at the golf course. The bottom line is that you pick the tools that best accomplish your processes and their goals.
Single Source of Truth
By assembling the best of breed tools, you are able to ensure your team is able to operate in the manner YOU need to. But what about my data, you may ask. I don’t want to have data in three different systems. Absolutely correct. You want a single source of truth!
Lionel Grealou, a Digital Transformation evangelist that I follow discussed this topic in his blog, noting that “SSoT is often mistaken for a single database or repository for all data; rather it implies an intelligent enterprise data model constructed for optimum data integration and control across multiple sources, avoiding duplication and redundancy.”
That is an important distinction. We are advocating for a single SOURCE of truth as opposed to a single database of truth. This means that there is a single master of a given set of data. Using modern software platforms that have robust AND OPEN APIs (or through integration hub providers) it is a straightforward task to connect different platforms (and their databases) into your PLM process.
Taking this approach ensures that data is authored and managed in a single location and shared to all those that need it. Users do not need to know where it came from they just know it gets to the right person, at the right time, in the right format.
Forming a Digital Thread
Let us unpack that a bit further. Using my lawn mowing example, if I have a requirement to mow my land in one hour. Those requirements may decompose into the width of my mower (50”) and the horsepower of the motor (22 HP). Those requirements can be passed to the systems engineering and mechanical design teams for their design tasks. The 50” geometric requirement will directly feed the mechanical design. The horsepower requirement will drive the system design and may result in reusing an engine or designing a new one. Again, I made a rudimentary illustration that I think explains itself.
The takeaway here is that we can connect our people and processes. When we do, we support their needs by allowing them to utilize the tools that best fit their needs. This should yield efficiencies and positively impact the form’s bottom line.
The other outcome is that by connecting data, not only do we have a single source of truth, but we have also created traceability throughout our processes and data. The fancy new term for that is digital thread. You can learn more about the digital thread by reading this blog, written by Jama Software’s CEO.
As a note – I would be remiss if I did not note that I realize that I have glossed over the specifics of data models, storage, and APIs in play here. They are important, however, for the purposes of this discussion they are not necessary.
Best in Breed for the Win
Returning back to our question. In response, I’ll typically ask what PLM system they are referring to. I’ll also follow up with how they are using it – most PLM users only use their PLM systems for PDM. Next, I’ll need to understand if they have licenses to the PLM systems requirements package (if there is one), if they have the capability to customize the system, etc. Some PLM systems have bolt on RM applications that still need to be connected to integrate data. The answer is often a blank stare followed by a complaint about their PLM system.
Ok. So forget trying to shoehorn requirements management and systems engineering into your old PLM system. Why not take the modern approach and utilize a model-based SaaS platform like Jama Connect for your systems engineering and pass the data to your PLM system?
Industry analyst, Oleg Shilovitsky from BeyondPLM has weighed in on this topic, stating:
The PLM paradigm is shifting from central to decentralized. The paradigm of connected digital services is also a departure from isolated SQL-based architectures running in a single company. The data is connected, web services keep all the history and provide access to a distributed version of truth. Such modern architecture is also continuously updated, which makes the problem of system upgrades a thing in the past and irrelevant as everyone is running on the same version of the same software. Furthermore, the cost of systems can be optimized and SaaS systems can serve small and medium-size companies with the same efficiency as large ones.
Hmmm… Accessible data with optimized web services with configuration management and cost efficiency. Sounds like a winner to me!
Yes, Jama Connect is Compatible with Your PLM
Putting all of this together is a matter of making the connections I suggested in the data flow image above. In my simplistic example, we could use REST API capability and federation to ensure a SSOT. Jama Connect data (requirements, system architecture, etc.) would be stored in Aras Innovator as federated data to be usable by the detailed design, mfg, and quality teams – yet not be editable since it is owned by Jama Connect. The test data (i.e. data files) would the reverse, federated back to Jama Connect to support the validation and testing processes but owned by Aras.
Obviously, this is a simple example. There are details in play like how much you have customized your environment, but the basic idea remains the same: Use best in class platforms and connect the data to those that need it.
If you would enjoy talking further, please drop me a line and we can get together, I’m always happy to talk shop! dewing@jamasoftware.com.
