Written by: Lateef Khan
Business Development Executive | General Manager Digital Services & Solutions | P&L Leader
As part of the product development process these days more and more product data needs to be created and managed. Depending on which industry vertical you belong to, it could be more or it could be less. If you’re in a regulated environment like Medical Device or Aerospace, there are stringent regulatory policies from the FDA, FAA, and the like, which most likely will require you to capture a significant amount of information to achieve compliance. Whether something is a safety part, RoHS compliant, make/buy part, to be manufactured in a particular factory, a spare or field replaceable unit, etc, these are all key elements defining a part which will ultimately drive many cross-functional processes across the organization.
Beyond the amount of product data that is needed, there are multiple philosophical considerations to make. When creating this information, do you “pokiyoke” the system behavior and make certain data fields mandatory? This would mean, until this information is populated, the system would not allow any progression in the workflow, I.e. process. Or do you make these data fields optional and manage this data creation by “business process”. As you would expect, there are pros and cons to either approach. If you make the population of too many data fields mandatory, you risk making the system unfriendly and frustrating the user. You potentially also risk slowing down the process to gather all information required and in some cases even risk a lower level of data quality, just to move the process forward. On the flip side, if your decision is to make it optional, while it may be a more desirable approach for users, it may result in getting a large amount of data with blank or null values.
Another area to reflect on is whether product data (items, boms, attributes) should be created and managed by central Product Data Teams (PDT) versus being created and managed by the actual functional user. The quandry here is while it makes sense to have the end user have skin in the game, sometimes the infrequency of their time in the system causes pain for them and uncertainty on how to use the tool in the correct manner. However these days user interfaces are becoming more intuitive and simple to use, allowing even the casual user the ability to manage their own data effectively, which may ultimately be the right way to head for industry so that users control their own deliverables and are not dependent on central teams. Central teams can then focus on more value added activities.
Another method of product data creation these days is to create all your relevant part data and attributes in a spreadsheet and then use that as an input file to bulk load into the system. While this may be viewed as something more productive or support entry of supplier related data, it potentially side steps the tool functionality gained through the user interface and could also result in possible errors leading to product data quality issues. This approach also causes risk in personas working outside and around the established and approved process.
Finally, the change control, maintenance, and sustainability processes today are at times quite disparate and cumbersome resulting in significant complexity to make even the most simplest of changes to your product data. It’s important to consider the type of changes you’re making to your product data, where in certain situations you can fast track a change and other times you need to go through the entire process with appropriate level of oversight. Establishment of decisions around which data elements and datasets follow the part revision and which follow their own revision are all key considerations to make in your change process and data model.
None of these decisions are a “one size fits all”. Would love to hear how other experts and PLM industry leaders are approaching practical decisions for managing product data across the enterprise. Please share your thoughts!