Master Control Versus Master Data

/Master Control Versus Master Data

Master Control Versus Master Data

Much has been written and said about master data. Knowing which system has data, which system is responsible for maintenance of that data, which system is the gold source, which system is responsible for access control, and which approach is to be used to share, access, or replicate data across systems is fundamental to maintaining the usefulness of corporate information.

Little has been written about what I like to refer to as master control. In the Product Lifecycle Management (PLM) world, there are many systems that are involved at different points in the lifecycle. An idea management system is at the very front end of innovation, collecting thoughts that may or may not evolve into practical ideas. As concepts in the ideation system evolve and an organization decides to invest in those concepts to further define their merit, other PLM systems might start to be used. For example, sketching tools may help create a product rendering and early production analysis tools may help gain an early understanding of feasibility or impact.

As the lifecycle continues, more in depth use of a variety of PLM systems is introduced. A limited set of examples are product design, product definition, recipe management, artwork, package design, production planning, project management, time recording, demand planning and resource management. There are many more and these systems vary by industry.

Usually these systems are not from the same supplier. Some are homegrown systems and some are commercial off the shelf applications. The master data efforts are addressing the issues identified at the beginning of this article, and the importance of master data is largely because of the number of disparate systems that are required in the end to end product lifecycle.

There are challenges that exist beyond master data. Which PLM systems should be used and what value would they bring? When should those PLM systems be used?

Teams working in innovation often don’t know that a particular PLM system is available and would add value to their efforts. For example, a team working on an idea might not be aware that a PLM system might enable them to sketch an early prototype at low cost and without creating an entire master data product record that would suddenly be visible on reporting dashboards throughout the company. A catalog of PLM systems and their appropriate use (and value!) should be published and well understood by all who are working in the innovation lifecycle. Making such information available to people working in the innovation process enhances the pace and quality of innovation.

A bigger challenge is understanding when a PLM system should be used. Very often, organizations will begin a PLM activity too early or too late. For example, package design might occur before product definition is sufficiently agreed or locked down. As product definition changes, this causes rework. Since PLM systems, by their nature, feed one another such rework can carry significant costs. Likewise, waiting too long to begin package design adds a schedule risk and might slow down the speed of innovation.

Using the wrong PLM system at the wrong time in the innovation lifecycle can carry great cost.

An innovation process management system can meet both these needs and can coordinate the PLM activity. The innovation system spans the entire innovation lifecycle and therefore is the natural choice to coordinate and provide Master control for other systems used in the innovation lifecycle. It can assist teams in knowing which PLM systems to use, and when to use them, as applicability of those systems come and go throughout the innovation lifecycle. Further, the innovation system naturally provides management awareness and structured decision making to ensure the timing of the PLM investment is correct.

2016-06-07T11:10:32-05:00March 28th, 2013|

About the Author:

Paul Heller
Paul is Chief Technology Officer with Sopheon. He has 30+ years of experience in software development and software technologies. Paul is currently responsible for corporate technology strategy, product strategy and technology architecture.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.