Are you still in search for a system that can easy check-out/check-in your files and asking how to uprev your assembly when you change sub-assemblies and parts? This is how a typical MCAD driven change management process sounds likes in a typical PDM system developed 20 years ago. It was designed when products were simple, the amount of electronics was significantly smaller, design and space factor was less significant and speed was much less a factor that was defined if you company will grow fast or disappear next year under the pressure of competition from a different country.
The reality in the field is that traditional methods, often rooted in siloed systems and manual workflows, struggle to keep up. These approaches, designed for simpler, less interconnected workflows, fail to address the reality of multiple CAD systems, complex dependencies between design, production, and supply chain teams.
The result? Delays, errors, and missed opportunities for innovation. This introduction explores why modern manufacturing demands a new paradigm for managing change and how embracing advanced tools and methodologies can turn a potential bottleneck into a competitive advantage.
However, modern change management is a complex discipline that requires coordination of multiple teams and tools together. The growing complexity of change management processes in today’s manufacturing is explained by multiplication of three factors – (1) complexity of modern high-tech products; (2) usage of multiple tools; (3) distributed nature of the teams and organizations involved in this process.
In this and the following few articles, I want to share my thoughts about complexity of change processes and how modern technologies and PLM software can provide a better support to resolve painful problems companies are facing in change management.
PDM vs PLM Discussion
In the last few articles on my blog, I analyzed the evolutionary trajectory of PDM and PLM tools and how change management and revision control process supported by these tools today can impact the efficiency and effectiveness of change management processes in organizations.
If you missed those articles, please check the following links:
PDM vs. PLM: Top 5 Revision Control and Lifecycle Challenges (and How Modern Platforms Solve Them)
PDM vs PLM: Current Status Quo, Challenges, and Future Development
PDM vs. PLM: From File Management to Connected Data, Product Lifecycle, and Product Models
Change management in modern manufacturing is more than just a technical process—it’s a balancing act of speed, accuracy, and collaboration across diverse teams and tools.
I really appreciate everyone’s comments you’ve made both online and offline in discussions with me. Manufacturing teams I’m talking to face growing number of challenges in managing change effectively, particularly as products grow increasingly complex and involve multi-disciplinary inputs spanning mechanical, electrical, and software domains. In additional it complicates by existing CAD, PDM, PLM, and ERP tools that involved in this process. Some of these tools are 20-30 years old, but they accumulated significant investment made by companies and it cannot be changed overnight.
The discussion about CAD, PDM and PLM tools is important because it gives you a perspective on the reality of existing change management processes in most of the companies.
A Retrospective of Engineering Change Management Process
Have you heard about CCB (Change Control Board). This is how I was first introduced to engineering change management a few decades ago. Back in those days, the change management process was largely manual, paper-based, and document-centric. Change requests relied on physical forms, drawings, and memos that were routed between departments for review and approval. This reliance on paper created significant delays, errors, and challenges in tracking changes. File cabinets and archives stored critical data, and retrieving historical records for audits or reference was labor-intensive and inefficient.
The workflows were sequential and rigid, requiring changes to move linearly through design, manufacturing, quality, and supply chain. Collaboration was minimal, and teams operated in silos, with little visibility into the broader impact of proposed changes. Bottlenecks were common, as approvals depended on individual availability or periodic meetings of Engineering Change Boards (ECBs). Communication between teams and stakeholders relied heavily on in-person meetings or written correspondence, slowing the process further.
Disconnected systems exacerbated these challenges. Data was stored separately in CAD files, MRP systems, and physical repositories. Manual data transfer between systems introduced errors and increased the risk of outdated or inaccurate information propagating through the product lifecycle. This lack of integration made it difficult to align engineering, manufacturing, and supply chain functions effectively.
Impact assessments and risk analysis were primarily manual, relying on human expertise and institutional knowledge. Predicting downstream effects on manufacturing or the supply chain was time-consuming and often incomplete, leading to costly oversights. Reactive change management was the norm, with teams addressing issues as they arose rather than proactively identifying opportunities for improvement.
The process’s lack of automation and integration also extended to supplier communication. Suppliers were informed of changes via letters, faxes, or phone calls, creating delays in adoption and discrepancies in versions. This manual approach, coupled with limited transparency and outdated information, often resulted in costly manufacturing errors and project delays.
What is the outcome of an inefficient change management process? These are my five
- Inefficiency and Delays: Manual, paper-based workflows and sequential processes caused significant delays in approvals and slowed down the entire change cycle.
- High Error Rates: Reliance on physical documents and manual data transfer increased errors in data handling and change implementation.
- Lack of Collaboration: Rigid workflows and siloed teams limited visibility and coordination, resulting in misaligned decisions and missed opportunities for optimization.
- Inaccurate Impact Assessments: Manual risk analysis often failed to identify downstream effects, leading to unexpected issues in manufacturing and supply chain operations.
- Costly Supplier Errors: Fragmented communication and poor version control with suppliers resulted in mismatched specifications, production delays, and additional rework costs.
Can we count on “Good-Ol Check-in/out” Process?
The roots of the product lifecycle management (PLM) process can be traced back to computer-aided design (CAD) and the way product data management (PDM) was originally organized. PDM evolved from document management systems with a central file storage (vault) system and simple functions like “check-out/check-in.” This process essentially means: “Take the file, move it from the vault to my computer, and block everyone else from making changes to this document.”
All existing mainstream PLM systems, such as Teamcenter, Windchill, Aras, SOLIDWORKS PDM, and Autodesk Vault, still operate in this way. But is this approach as effective today as it was when originally designed, especially in a world where new systems allow people to collaborate and work together on the same document, making multiple changes simultaneously?
Let me provide a simple example to illustrate this. Imagine two people—a design engineer and a procurement planner—needing to make changes to an Excel document representing a list of parts required for a specific production process.
In the first picture below, I’ve schematically illustrated how the traditional check-out/check-in process works with a simple spreadsheet. The initial state of the document is revision R1. To perform their changes, the system creates two revisions—R2 and R3—because each person is blocked from editing while the other is making changes. The result is two separate revisions created by each individual.
In the second picture, you can see a “workspace” approach where two people can simultaneously make changes in a shared “workspace.” All changes are recorded in real-time, and once both individuals have completed their collaborative work, a new revision can be created. What we observe is that, starting from the same state (R1), only one new revision (R2) was generated.
Paradigm Change from Old Revisions to Collaborative Workspace
The idea of managing product data changes using modern data-sharing mechanisms is not entirely new. It dates back over 20 years to when Google introduced Google Docs, revolutionizing traditional applications for the web. Google Docs was built on the foundation of Writely, an early browser-based word processor with real-time collaborative editing. Writely was created in 2005 by software developers Claudia Carpenter, Steve Newman, and Sam Schillace. Google acquired Writely in 2006 by purchasing its parent company, Upstartle.
The concept of “ditching the Save button” was groundbreaking and has since inspired engineers across various industries to develop collaborative applications that reimagine existing processes and tools.
I can bring two examples of CAD and PLM, using a collaborative workspace approach – Onshape and OpenBOM (disclaimer-I’m OpenBOM co-founder).
Onshape – Ditched “Save Button” & Moved MCAD Process to Browser
Onshape introduced an innovative mechanism that transformed traditional mechanical design by replacing individual geometry files with a collaborative workspace. This new approach enables co-editing and co-assembly of mechanical designs, seamlessly integrating with a modern PDM versioning process. Onshape also eliminated the “Save” button commonly used in traditional desktop CAD systems, streamlining the user experience. The following article from Onshape gives you an idea – Under the hood – How Onshape Works.
Onshape allows to multiple users to work together and preserve the history of changes.
OpenBOM – “Collab Grid” for BOM and Upside Down Lifecycle Process
OpenBOM took a similar approach to Onshape but applied it to complex product structures, creating a collaborative user experience where product structures are presented in an intuitive, “spreadsheet-like” interface. This allows multiple users to make changes simultaneously without blocking each other. The history of changes is automatically tracked, and product structure revisions can be easily snapshotted. A foundation of OpenBOM is a distributed flexible data management system for “data objects” (catalogs), global “BOM graph” using graph model and GraphDB, and collaborative environment allowing to multiple users to work together and to perform controlled changes:
OpenBOM allows multiple users to collaborate and edit data using a flexible data model. This model supports simple elements such as text, numbers, and currency, as well as complex data objects like images, formulas, and file attachments.
What is my conclusion?
New technologies will impact the way existing change management processes are orchestrated and managed. The fundamental shift is moving from a “file-based save method” to a data-driven, collaborative approach that organizes information into a shared workspace. This eliminates the need for saving and allows multiple people to make concurrent and coordinated changes.
From my perspective, this represents a fundamental change that will significantly impact how PDM/PLM systems operate today and how changes are managed. Just my thoughts…
PS. This is Part 1. In upcoming articles, I will share my perspectives on how collaborative change management processes will influence traditional process organization and support orchestration across multiple tools and teams, which are essential for modern manufacturing companies.
Best,
Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I’m advocates for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased.
