A Med Device Company’s Best Practice for Managing BOM Files
For the millions of fans around the world who read my blog daily, you’re now familiar with Swan Valley Medical Chief Operating Officer Laurence Sampson. His knowledge of PLM and soothing Earl Nightingale speaking tones have made him a sought-after speaker for high profile manufacturing events. And while Sampson has become somewhat of a celebrity, his company Swan Valley is sometimes still mistakenly referred to as Swan Lake.
Sampson knows PLM like Kirov and Bolshoi know ballet. And when he’s protected Swan Valley Medical from the evil black swans of product error and shipping delays, he’s defining new best practices to maximize his PLM investment.
Manufacturers, such as Swan Valley Medical, rely on managing their bill of materials (BOM) in a watertight manner. This can include a comprehensive list of parts (numbers and revisions), items, assemblies and sub-assemblies. Oftentimes it is considered as the recipe or shopping list for creating a final product.
A BOM explains what to buy, how to buy, and where to buy, and includes instructions for how to assemble the product.
We recently spoke with Sampson about BOM management best practices which he believes every company could benefit from—not just medical device companies.
Arena: Why don’t we start with a history lesson in how you determined you had a need for a PLM system?
Sampson: We had a bunch of files in a filing cabinet, and needed an electronic method for storage and approval of the files. Our understanding of PLM was simply a way to store and approve a variety of different file types in a smart document repository. So, we took the plunge and integrated Arena. We quickly learned it’s a terrific way not only to store and approve the files but also to interrelate the files and associated metadata.
Arena: It sounds like stage two was to define associations.
Sampson: Exactly. We have the assembly, sub-assembly, and part prints in our BOM. The BOM interrelates these files to show how the product is constructed. We can then link work instructions, labeling and an associated inspection documents.
Arena: Your final grand experiment was to extend the documents involved in associations to processes.
Sampson: Yes. The processes drive the conception, revision, review, and approval of the documents contained in the repository. Moreover, these processes inter-relate with one another. Some examples include CAPA, Complaints, Sales orders, and RMA. Post-market feedback can drive the need for an RMA for example. Or a complaint can drive the need for reporting of an adverse event. These processes then drive the creation of new documents, which are pushed back to the repository.
As a consequence, documents are then simply the container for holding the conclusion of these processes.
Arena: Let’s stop for a second and discuss the regulatory impact of these processes.
Sampson: The processes themselves are the subject of very specific regulated workflows. For example, the processing and promotion of complaints: Post-Market Feedback -> Complaints -> Adverse Event -> Product Recall.
Arena: Many companies want answers to these questions: How are adverse events required to be reported for each applicable region? How are CAPA’s processed, and requirements communicated to the staff member responsible for filling out the form? How are those inputs processed and approved? Once the processes are approved how are the documents pushed back into the system and added to the product history?
Sampson: Yep. A really powerful feature of this type of integration is the ability to show the thread of inter-related processes and their component assemblies, parts, suppliers, and project plans, for flawless audit research, and a truly complete design and production history.