Results Snapshot
Product records, controlled documents, BOM management, engineering change, and production release workflows went live within 8–10 weeks
Product data search and version confirmation time decreased by 35%, helping engineering, production, purchasing, and quality teams confirm current controlled data faster
BOM release and production readiness handoff time decreased by 33%, reducing repeated checks across engineering BOMs, manufacturing BOMs, purchasing specifications, and quality files
Engineering change impact analysis time decreased by 42%, with the system identifying affected items, BOMs, drawings, supplier files, and open workflows
Supplier specifications, inspection standards, certification files, and packaging label documents moved into one permission and version control model, reducing wrong-version sharing and repeated file requests
An Old Drawing Nearly Entered Pilot Production
The customer is an Ireland-based clinical diagnostic equipment manufacturer. Its products include compact benchtop diagnostic instruments, sample handling modules, disposable consumables, sensor assemblies, packaging labels, and service parts. The company serves hospital laboratories, diagnostic service organizations, and specialist channel customers, with both mature production models and new products still moving through validation and refinement.
Before the project, a pilot production preparation issue exposed the product data risk. Production was preparing to use an assembly drawing, but engineering later found that the drawing had already been replaced by a newer design. Purchasing had also sent an older bracket specification to a supplier, while quality was still confirming whether the inspection standard had been updated.
The issue was caught before batch production, but several teams spent significant time confirming which drawing, BOM, supplier specification, and inspection requirement were currently valid. This made leadership recognize that PLM was not simply a cleaner folder structure. Product data needed status, version control, ownership, impact visibility, and release evidence.
Too Many Files Was Not the Core Problem
The customer had plenty of product information. Engineering teams managed design drawings and specifications, manufacturing engineering maintained assembly documents and work instructions, purchasing stored supplier specifications and quotation attachments, and quality teams managed inspection standards, certification files, and release records. The difficult part was knowing which file was usable, which version had been released, which file applied only to prototype validation, and which file was obsolete.
This risk mattered in medical device manufacturing. A small bracket material change could affect design drawings, BOMs, supplier specifications, inspection standards, packaging files, and inventory. A packaging label size update could affect supplier communication, quality review, and production release. When those relationships were not connected, teams depended on emails, meetings, and manual checks to reduce risk.
The cost of wrong-version data was not limited to rework. It slowed pilot production preparation, increased supplier communication, extended quality review, and reduced production confidence in the files being used. The customer needed product data to be controlled, not merely stored.
Product Relationships Came First
Industry Software and the customer team began by mapping product data relationships rather than migrating every historical file. The project team reviewed how product master data, item codes, design drawings, engineering BOMs, manufacturing BOMs, supplier specifications, inspection standards, packaging files, and engineering changes related to one another. PLM could support daily collaboration only if these objects were connected.
Product master data became the first foundation. The system captured product numbers, item codes, specification attributes, lifecycle states, applicable product lines, responsible teams, and related files. Drawings were no longer isolated files, and BOMs were no longer just material lists; they were connected with products, items, suppliers, quality requirements, and change workflows.
This relationship model gave teams the context behind product data. When engineering updated a part, users could see where that item was used. When quality changed an inspection standard, teams could see the affected products and supplier files. When purchasing prepared supplier communication, it could confirm whether a file had been released. Product data became a traceable, reviewable, and reusable operating asset.
BOMs Could Not Serve Engineering Alone
The customer had often treated the engineering BOM as the common reference for every team, but the engineering BOM did not answer every production, purchasing, or quality question. It represented design structure, while production needed assembly levels, process materials, packaging items, test requirements, and approved substitutes. Purchasing needed supplier item numbers, purchasing specifications, and certification files, while quality needed inspection standards, release status, and controlled document versions.
Industry Software helped the customer distinguish engineering data from production readiness data in PLM. Engineering teams maintained design items, drawings, specifications, and BOM structures, while manufacturing engineering and production teams added assembly requirements, packaging files, test documents, and production applicability through controlled workflows. BOMs became more than an engineering output; they became a product data foundation shared by production, purchasing, and quality teams.
The system also supported version applicability. BOM versions could be linked to specific product models, configurations, customer batches, pilot production phases, or effective dates, reducing informal decisions about which version should be used. For a clinical diagnostic equipment manufacturer, this clarity reduced wrong-version pilot builds, repeated confirmation, and quality review pressure.
Change Impact Had to Be Visible
Engineering changes in medical device manufacturing rarely affect only one file. A sensor bracket material replacement can affect drawings, BOMs, supplier specifications, inspection standards, inventory, and pilot production plans. A packaging label update can affect quality files, supplier communication, and production release. A consumable material adjustment may also involve supplier certification and inspection items.
Industry Software configured engineering change workflows in PLM by connecting change requests, change reasons, approval responsibility, affected objects, effective rules, and change history. When engineering initiated a change, the system could use item, BOM, and document relationships to identify affected products, drawings, supplier files, quality documents, and open workflows. Reviewers saw more than the change description; they saw which downstream teams and execution points might be affected.
Change effectivity was also controlled. For new products not yet in production, changes could move directly into new BOM and document releases. For products in pilot production or production preparation, the system could flag the need to review legacy material use, supplier communication, quality document updates, and production transition planning. Engineering change moved from file editing to a cross-team product decision that could be executed and traced.
Supplier Files Could Not Depend on Email
Supplier collaboration was a critical scenario for the customer. Suppliers needed correct drawings, specifications, inspection standards, packaging requirements, and certification files, but they should not see product data outside their scope. When files were shared by email, teams had to repeatedly verify attachment versions, recipients, approval status, and whether obsolete files were still circulating.
After PLM go-live, supplier-facing files moved into permission and version control. Purchasing and engineering teams could connect supplier-visible files with items, BOMs, and supplier records, while permissions controlled what different user groups could access. When files were updated, teams could see which documents were released, which were in review, and which were obsolete.
Quality documents were connected to the same product data chain. Inspection standards, test requirements, certification files, and change records were no longer isolated attachments; they were linked with products, items, BOMs, and supplier records. During review, traceability work, or supplier communication, quality teams could confirm which files and requirements applied to a specific product version faster.
Customized Around Controlled Data
Industry Software’s PLM projects are not delivered as generic document libraries. From the start, the system was configured around the customer’s product structure, BOM management model, engineering change logic, supplier collaboration model, quality document control, and production release requirements. The customer’s product data process was translated into maintainable lifecycle states, approval nodes, permission rules, and version controls.
This customization mattered for a medical device manufacturer. Different product types require different data controls: instruments, configurable modules, disposable consumables, packaging labels, and service parts do not follow identical release, versioning, and traceability rules. A single folder structure cannot represent these differences, so different objects needed different lifecycle and approval paths.
Business teams also needed to maintain the rules over time. Engineering could adjust drawing and BOM version rules, quality could maintain inspection document and release requirements, purchasing could manage supplier file visibility, and manufacturing engineering could maintain production-applicable documents. PLM became not a fixed file repository, but a product data platform that could evolve with the customer’s product lines and quality requirements.
Start with Products Still Changing
The project did not begin with every historical product file. The customer had years of drawings, BOMs, supplier files, inspection records, and packaging documents, including active production models and discontinued products that still required service support. Cleaning everything at once would slow the project, but ignoring history completely would weaken traceability and service support.
Industry Software and the customer grouped product data into three categories. Products still in production, under frequent change, or approaching production release entered controlled management first. Legacy products with service part requirements retained the version and traceability records needed for support. Low-frequency historical files were migrated in batches or indexed for later reference.
This path moved PLM into real work faster. Engineering used change workflows first on active products, production confirmed controlled files first for current production models, and purchasing and quality managed the most frequently used supplier and inspection documents first. Value came from controlling current operational risk, not from moving files into a new platform.
Testing Followed Real Changes
Implementation testing used real product data scenarios. The project team validated new product introduction, BOM release, material replacement, drawing revision, supplier specification update, inspection standard change, and packaging label update scenarios. Each scenario began with a product record and moved through file versioning, BOM relationships, change approvals, affected objects, supplier files, and production release validation.
Testing revealed issues that habitual communication had previously hidden. Some item descriptions were inconsistent, some old files were still being referenced by purchasing, some engineering changes lacked clear effective dates, some supplier files had unclear visibility scope, and some manufacturing BOM release ownership had not been formally defined. The project team prioritized the issues with the highest impact on production, supplier communication, and quality traceability.
Core workflows went live within 8–10 weeks. The first phase stabilized product records, BOM versions, controlled documents, and engineering change workflows. The second phase expanded supplier collaboration, quality document linkage, ERP synchronization, and management reporting, followed by adjustments to fields, approval nodes, permission rules, and interface views based on user feedback.
Teams Started Trusting the Same Version
Training was organized around each team’s real work. Engineering teams focused on product record creation, drawing versions, BOM maintenance, and engineering changes. Production teams focused on confirming released BOMs and production-applicable files. Purchasing teams focused on supplier documents, material specifications, and controlled file access, while quality teams focused on inspection standards, approval records, document states, and traceability paths.
Early after go-live, some engineering users still preferred saving drawings in local folders, while production and purchasing users were used to asking by email for the latest version. The Industry Software implementation team used real change, BOM release, and supplier file update scenarios to show why controlled workflows mattered. The system was not adding steps for their own sake; it was reducing wrong-version files, missed approvals, and repeated confirmation.
The customer also formalized new data ownership. Engineering no longer released drawings alone; it also reviewed BOM impact and applicability. Purchasing no longer requested the latest specification by email; it accessed controlled versions through PLM. Quality no longer assembled review packages manually; it used the relationships across products, items, BOMs, and documents to support traceability.
The Change Appeared in Release Work
An operational review conducted 8–12 weeks after go-live showed that product data search and version confirmation time decreased by 35%. Engineering, production, purchasing, and quality teams could view document state, revision, approval history, and applicable products in the system instead of searching folders and email threads. For products in production or under active change, this reduced the risk of using outdated versions.
BOM release and production readiness handoff time decreased by 33%. Relationships between engineering BOMs, manufacturing BOMs, packaging information, test requirements, and applicable versions became clearer, allowing production teams to confirm readiness faster. Purchasing teams could also identify whether material specifications and supplier files were complete earlier.
Engineering change impact analysis time decreased by 42%. When engineering initiated material replacements, drawing revisions, or specification changes, the system could flag affected items, BOMs, drawings, supplier documents, and open workflows. Reviewers evaluated changes using a fuller impact view rather than relying only on change descriptions and verbal confirmation.
Supplier document management became more stable. Controlled specifications, drawings, inspection standards, and certification files were linked with items and supplier records, helping purchasing and quality teams identify which files had been released, which were obsolete, and which were still in review. Supplier communication moved from repeated attachment sharing toward controlled document collaboration.
Long-Term Value Came from Product Data Discipline
The long-term value of PLM is not only faster file search. For medical device manufacturers, product data discipline affects engineering efficiency, production stability, supplier collaboration, and quality traceability. Whether a version is effective, whether a change affects a supplier, whether a BOM is ready for production, and whether an inspection standard has been updated all shape execution quality from design to release.
As data accumulates, the customer can analyze which products change most often, which items most often trigger replacements, which supplier files are often incomplete, and which new product introduction steps cause delays. Stronger version control can reduce wrong-version production and rework risk, more complete change impact analysis can reduce quality and delivery issues caused by missed changes, and controlled supplier files can reduce repeated communication and wrong-file sharing.
Industry Software helped the customer build more than a file repository. It created a product data operating foundation connecting design, BOMs, engineering changes, supplier files, quality documents, and production release. It moved product information out of personal folders and email attachments into an approvable, traceable, and reusable lifecycle process. For medical device manufacturers, PLM turns product data into reliable execution evidence instead of a risk that must be checked repeatedly.
Client Quote
“A material change for one bracket sounded small, but it affected drawings, BOMs, supplier specifications, inspection requirements, and production files. Before PLM, production had to ask engineering whether the drawing was current, purchasing had to confirm which file had gone to the supplier, and quality had to check whether the inspection standard had changed. Now drawings, BOMs, change orders, and supplier files are connected, and affected objects are visible, which has reduced a lot of version-checking meetings.”