Product databases- or should we say, product information databases- are an unskippable item of any manufacturer’s digital landscape. That is obvious by now. But what is a product database? What tangible business uses does it have? How is it used by different types of softwares? How do I create my data? Can I share it? Is it secure?
A term as simple as “product database” raises numerous considerations. Apparently trivial but still vital to be familiar with when initiating an NPD (New Product Development) IT project.
Product databases: basic considerations
We can easily define a product database as an organized collection of product-related data, stored and managed electronically. We call these data product specifications. They consist of a wide variety of information: product name, weight, internal reference, official reference, ingredients, raw materials, packaging, supplier, official labels, labeling information and so on. These specifications are obviously your most precious asset in your product development processes and projects.
You can decide to store your product database (and by extension every other type of database) physically on your own private servers or delegate this responsibility directly to your software provider or to a third-party hosting service provider.
In the first case, assuming the responsibility of your product database means:
– Having dedicated, available and secured servers
– Having internal expertise and availability to maintain these servers operational and quickly react to any issue
– Being on your own if a major event occurs
This is generally the case for “on premise” solutions, too often favored because of a lack of trust in outsourcing.
In the second case, delegating this responsibility means:
– Workload on your side limited to the relationship management with your provider
– No need to have a high-end IT expert in your teams to maintain the product database
– Every major update is automatically available
– Having a specialized business partner to support you in case of a major event
This is generally the case for “cloud” solutions, or “Software as a Service (SaaS)”.
Business uses of product databases
Product database tools range from accessible and highly versatile ones, such as Microsoft Access, to highly functionnaly specialized solutions like Product Lifecycle Management (P.L.M.) software. Although product database should be a priority, it does not represent a goal on its own. It is at the core of much more complex technologies and is a must-have, solid ground for deeper features.
- Product database and Product Lifecycle Management (P.L.M.) software: PLM software focus on innovation and new product development projects.
- Product database and Product Information Management (P.I.M.) software: PIM software focus on information distribution and its channels (e-commerce website, reseller’s product database, marketing tools, etc.).
- Product database and Enterprise Resource Planning: ERP software focus on the manufacturing and logistics of the product.
All these software come with their own incorporated database, required for the proper functioning of the solution. However, when in the process of building a comprehensive and consolidated IT architecture, these separate database instances start to hinder the flow of information.
Even though interfacing solutions is always feasible, it grows considerably with the number of solutions you have to interface: n*(n-1)/2 interfaces are required, “n” being the number of solutions you have to interface. Although this remains manageable when you only have a few solutions implemented, you may benefit from a Master Data Exchange (M.D.E.) solution to ease the cross flow of information. It basically operates as a central commutator of information between all your software solutions. Using this, the number of interfaces is reduce to n, “n” being the number of solutions you have to interface.
Specification management for product information traceability
Lascom’s PLM provides a unique repository that dematerializes all new product development (NPD) related information: raw material and packaging characteristics, mandatory files, suppliers’ details, etc. You define every item using a form with multiple fields to be filled free hand or from pre-existing libraries: classification, nutrients, ingredients, physical-chemical criteria, etc.
All the specifications are systematically stored to build a healthy and logical product and project database. It respects the data’s format, dependency relationships, criticality and its place in the NPD process. This makes the search and use of data for ulterior steps intuitive, efficient and secure.
You also entitle every user with a level of responsibility to avoid manipulation errors: double data entry, rekeying, unauthorized changes, etc.
