A design change is not finished when the CAD model is saved. Engineering still needs to know which component changed, which products use it, which drawing manufacturing should follow, and what purchasing needs to do next.
When those answers are scattered across CAD files, spreadsheets, email, and business systems, choosing another application can feel urgent. But where should you begin—with PDM, PLM, ERP, or a better way to connect what you already have?
My recommendation is to begin with one product and one change. Follow the information from design through review, release, and purchasing. Watch where people must recreate data, reconcile conflicting records, or rely on someone remembering what happened.
That exercise gives you a practical basis for evaluating SaaS PLM software and deciding whether OpenBOM fits your workflow.
Start with the responsibility you need to improve
Manufacturers often compare products before agreeing on the problem. A team struggling with CAD references has a different requirement from a business struggling with production scheduling or formal configuration control.
Use this decision guide to establish your starting point:
These responsibilities can overlap. An ERP may include engineering-change functions, while a PLM platform may provide PDM. Evaluate the specific offering and modules rather than relying on category labels. Our guide to choosing the right engineering platform explores this landscape in more detail.
Understand what SaaS tells you
SaaS describes how software is delivered and operated. It does not tell you how the system represents a product, controls changes, or supports external participants. Enterprise PLM can also be delivered as SaaS.
PDM focuses on controlled product data, including design files and their relationships. PLM extends into broader product lifecycle processes. Their boundaries vary by platform.
Ask what the vendor operates and what your team must still configure, migrate, integrate, and maintain. Desktop CAD workflows may involve local workspaces and add-ins even when the data platform is cloud-based. Evaluate those practical requirements alongside browser access.
Test one product change from design to purchasing
Consider a hypothetical electromechanical assembly containing a bracket, a purchased motor, a controller PCB, and firmware. The motor becomes unavailable, and engineering must evaluate a substitute.
Use your own equivalent product during a trial or demonstration. Include the engineers, buyer, and release owner who would handle the change in practice.
1. Establish what the product contains
Bring in representative CAD data and an existing BOM. Check how the platform identifies reusable components and records their use in assemblies.
The same motor might appear in two products with different quantities. Its identity and core attributes should remain consistent, while each BOM records its usage.
Also include content that is missing from the mechanical assembly: the controller, firmware reference, or a non-modeled consumable. A CAD assembly tree provides valuable design information, but engineering must determine the complete product definition.
Our explanation of Design BOM versus Engineering BOM describes these distinct responsibilities. During evaluation, ask how configuration, inclusion, and part-number rules produce the intended engineering structure.
2. Follow the design evidence and revisions
Ask the vendor to show how files, Items, and BOMs are connected. A file version captures an update to design content. An Item or BOM revision identifies a controlled engineering definition. Their revision counters need not match.
For managed files, test assembly references, retrieval, and conflict prevention. For cloud CAD or external repositories, verify which source state is referenced and whether it remains accessible.
Then retrieve the previous approved product definition. Can the team determine which motor, drawing, PCB state, and firmware release were accepted together? Saving or importing design data alone should not be mistaken for engineering approval.
3. Investigate the change and involve the right people
Find where the motor is used. Review the replacement’s fit, electrical characteristics, supplier information, cost, and availability. Ask which records provide those answers and how current they are.
Let engineering and procurement work on the proposed change together. Test external participation with the access the supplier actually needs. Check both visibility and editing permissions.
If simultaneous BOM editing is important, demonstrate it. Test CAD file collaboration separately, including any locking required to prevent conflicting updates.
Some suppliers will continue using Excel templates. Include that exchange in the pilot and inspect how the response is reviewed and incorporated. As we explain in OpenBOM versus spreadsheets, familiar spreadsheet processes can remain useful alongside a controlled product-data foundation.
4. Approve the change and preserve the baseline
Walk through the required review and approval process. Identify who can edit the proposal, who accepts it, and who releases the result.
After approval, retrieve both the earlier baseline and the new definition. Continue editing the working data and verify that the historical record remains understandable within its preserved scope.
If your business requires effectivity, complex variants, or specialized regulatory controls, make those explicit pilot requirements. Request evidence for the particular capability and configuration you need.
5. Verify the operational handoff
Prepare the purchasing requirements in the designated procurement system, or publish the agreed Item and BOM data to ERP.
Inspect the receiving records: identities, quantities, units, mapped attributes, revision treatment, and required documents. Test a rejected update or missing mapping as well as a successful transfer.
Engineering approval, integration execution, and destination acceptance are separate events. Agree on who checks each one. Our article on engineering release and ERP integration follows these boundaries in more detail.
Also review open orders and existing inventory. Changing the product definition does not resolve the consequences for materials already purchased.
Include implementation effort and total operating cost
The subscription price is one part of the decision. The pilot should reveal the work needed to make the complete process usable.
Ask about data cleanup, migration, connector configuration, training, supplier participation, and ongoing administration. Establish which functions and integrations are included in the proposed subscription and which require additional services.
Review how refreshed CAD data interacts with information added by engineering or purchasing. Who owns each field? What happens when source data conflicts with an edited value?
For connected systems, document part-number rules, revision ownership, release criteria, and failure handling. Distinguish a supported connector from a partner solution or custom API integration. Compare the effort required for your actual workflow rather than assuming every cloud deployment follows the same schedule.
Where OpenBOM fits
OpenBOM is a cloud-native, multi-tenant service that brings cloud PDM, reusable Items, BOM management, revisions, and collaboration into a connected engineering environment. Its configurable data model and xBOM capabilities support different product perspectives, including engineering and manufacturing, with the structures and responsibilities defined for the process.
Three practical capabilities deserve attention in an evaluation: sharing selected product information across companies, working together on BOM data in real time, and connecting engineering tools with downstream business systems. Our cloud-native PLM comparison discusses the balance between these capabilities and deeper process requirements.
The integrations catalog is a useful starting point. Check the supported objects, source states, and transfer behavior of the particular connection you intend to use.
As the primary product-data platform
A manufacturer can use OpenBOM to manage engineering information, revisions, suppliers, and practical inventory and purchasing activities. This can support prototype builds and growing operations before the business needs a comprehensive ERP implementation.
When full ERP is already in place, define which operational transactions remain there and how engineering data reaches them. Advanced scheduling, warehouse operations, shop-floor execution, and financial management require evaluation beyond OpenBOM’s lightweight operational scope. The OpenBOM and ERP comparison explains these deployment choices.
Alongside enterprise PLM
An organization may already have the governance platform it needs while engineers still struggle with CAD connectivity, working BOMs, and supplier contributions.
OpenBOM can provide an engineering frontend for those activities. The deployment defines where engineering review occurs, where formal enterprise release resides, and how validated information moves between systems. An innovation or NPD team can also use a focused workspace with an agreed enterprise handoff.
Our enterprise PLM comparison discusses these complementary roles. Evaluate them against product complexity, process requirements, and implementation capacity rather than company size alone.
OpenBOM’s connected scope does not mean it matches the depth of every enterprise configuration, quality, or regulatory workflow. Demonstrate the mandatory processes before committing to a platform.
Connected to software and work-management tools
GitHub can remain responsible for code history, Jira for development work, and Notion for documentation. The evaluation should establish how relevant records connect to the product.
For our hypothetical assembly, ask which firmware release belongs with the approved controller and motor configuration. Recording that selection may be manual or use a configured integration. Our comparison with GitHub, Jira, and Notion explains the different information models involved.
Make the decision from the pilot evidence
At the end of the evaluation, ask participants to show the approved product definition, supporting design evidence, supplier response, and operational handoff.
Record the manual steps, configuration work, unresolved gaps, and cost of maintaining the process. If existing tools already cover the requirement, adding another platform needs a clear reason.
The strongest choice is the one your team can use to manage its required product decisions reliably. Bring one real assembly and one realistic change to an OpenBOM trial, then follow the information into its next use.
REGISTER FOR FREE and check how OpenBOM can help you.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
