Estimated reading time: 4 minutes

Adventures in Engineering: Data Management Not Just Checking the Boxes

Good product data management is rooted in the thoughtful strategy, process, and execution of preserving your company’s product data. A robust data management strategy is key to giving direction to your company’s data management processes. Product portfolio, pedigree, and regulatory requirements are used to identify how to implement a data management plan/process to support your company’s products. The day-to-day tactical ins and outs of product data management should be executed per plan and in faith to the strategy.

Robust data management strategies I have encountered are in line with business plans, concise, and speak to dedication to task. Specific archival and configuration tools should not be part of a strategy. Why tie your company’s fate to that of another company? Neither should a strategy be centered around an individual’s skillsets or preferences. It is important to develop a strategy with focus that does not have unnecessary constraints.

An example data management strategy for a PCBA design service company may be written as follows: “Data management at ACME PCBA Design Incorporated is focused on accurately capturing customer requirements, tracing customer requirements to circuit/PCB design requirements, archiving design reviews, design milestones, and final design artifacts.” 

Data management plans/processes are about how data is handled and should be developed around the company products in accordance with the company’s data management strategy. Identifying your company’s high-level product portfolio (military, aerospace, medical, safety, commercial) can help identify which data management tools may be necessary. Product pedigree (high/low volume, high/low complexity, evolutionary product, new product, high/low cost, high/low quality) can significantly influence the scope of data that should be archived and under configuration control. Products developed under the purview of regulatory entities (FAA, FCC, EASA, FDA) may have unique requirements regarding data management and should be considered carefully.

I have encountered companies with multiple sets of configuration and archival tools because tools were chosen out of personal preference with no regard to the tool’s ability to meet regulatory requirements. Please be aware that specifications such as DO-178 have descriptive requirements for configuration tools and do not call out specific tools which meet the development needs (prescriptive). In many cases these data management plans get distilled into a process or instruction contained within company procedures which in turn are overseen by a company quality policy/process. 

In most cases, when you hire onto a company or join a work force, the data management strategy and plans(processes/instructions) are already established, and your role is that of implementer. When I have disagreed with a particular plan or strategy and felt the need to say or do something, I have found it best to execute to plan in good faith then demonstrate the enhancements I have in mind. I find this type of constructive criticism is typically well received and functions well as a trust building exercise. Often I get the nod to go ahead with my suggestions because they are not perceived as deviating from the process (plan) at hand but rather enhancing it. The goal then becomes establishing these enhancements as common practice to pave their way into becoming documented process. 

The execution of data management should be done with diligence not just out of obligation.  We’ve all heard of the term “just trying to check all the boxes.” My observation is that this type of mindset leads to finishing a task at the cost of completeness. A common scenario I encounter is incomplete configuration control of PCB design data. A common misconception is that the Gerber files are the source data used for PCBs and that is what needs to be under configuration control. The “stuff” used to make the Gerber files are just tools and not the source data itself, and I have experienced this situation more times than I have fingers and toes. All of the PCB design tools I have used in the last 20+ years use project-based data items (files and databases) to define specific PCB designs that facilitate source data control. So why is the actual source data being left out of the data management process?

Most often it is because the person directly responsible for entering data into the configuration system does not have in depth knowledge of PCB design and may not be interested in learning about it. Please be aware that even if you are not directly responsible for entering items into a data management system that you still can play a positive role in data management. My advice is to present your PCB design data in a straightforward manner as possible so others outside of the PCB design process can identify major items for data management purposes.

I typically provide customers a singular data package that is named after the project or product part number, “DataPackage” identifier in the name, and the month/day/year is appended, “Processor_IO_Board_DataPackage_08102020.” Key items or groups within the data package are clearly identified to assist those without specific domain knowledge such as PCBA assembly data, PCB fabrication data, schematics, partlist(s), and PCB source data.    

In summary, good data management is done with intention, not obligation. 

Chris Young is owner/lead engineer at Young Engineering Services LLC.