Mastering Materials Master Data Management

Material, also called item/part/product in other domains and solutions, is THE most important master data object as it is central to many mission-critical business processes in sales, commerce, design, manufacturing, logistics, customer service and maintenance. The creation of material is an extremely cross-functional exercise that spans the whole supply chain. What starts off as a vision and a sketch on a napkin turns into a finished product. Like the Cybertruck below.

Coming back to the topic of Materials Master Data Management. We have seen a very unfortunate pattern of data entry oriented master data management tools (MDM) trying to tackle Materials Master Data Management and failing miserably. Right off the bat we would like to establish the following

Materials master data is not something you type into a form or an Excel sheet, run some validations, and send it via an approval workflow, and call it a day. Materials master data is the outcome of analysis and decision-making by Design, Manufacturing, Purchasing, Logistics, Marketing and Sales/Customer Service stakeholders.

Regardless of what some vendors advocate and would like you to believe, MDM most definitely is not the following

 

How Materials Master Data Management looks like in the Real World

New Material Creation

If you ask a design engineer, product engineer or material management stakeholder they will actually say that creating new materials might look something like below (for illustration only)

Changing Materials

And changing materials might look something like below. And typically an Engineering Change Request and/or Change Order is used to change materials.

Handling Bill of Materials (BOM)

Bill of Material (BOM) is a key aspect of material master data. New BOMs and changes to existing BOMs are actually related to new material creation or changes to existing materials. Any MDM solution that cannot handle BOMs will not be an effective MDM solution for Materials.

A BOM change is a change to Material

Document Management related to Materials

Files that are related to Materials (drawings, graphics, visualization files, specifications, etc.) are also a key aspect of Material Master Data. As a result master data solutions that need to handle materials should provide great support for managing files that are related to Materials.

Collecting Right Information from the Right Person

Since many people are involved in creating material master data it is best to get the right information from the right person. For example, a design engineer is in the best position to provide information related to “Weight” for example. On the other hand purchasing and manufacturing stakeholders are better able to obtain lead time and lot sizing information.

Validation at the Right Time, and By the Right Person

It is still a good idea to add validations (required fields, ranges, etc.) for materials master data. But there is a right time for validation. Too much validation right in the beginning can frustrate users and users that have no idea will select incorrect information or may just give up. Validation at later stages of the master data process can make sure that accurate master data makes it into downstream systems.

Summary

Materials Master Data Management is one of the most cross-functional process in the organization and the extended supply chain and is connected to many upstream and downstream processes in design/engineering, sales, marketing, purchasing, manufacturing and logistics. Treating it as a cross-functional business process leads to many advantages and benefits to individuals, teams and organizations.

Welcome to the (Business Workflow) Jungle, ServiceNow

We welcome ServiceNow’s entry into business process workflow market. Our strong belief is that more competition is always better for the customers. Usually more competition leads to lower prices, better products and higher quality. We are not very confident that such a scenario will reveal itself in the case of ServiceNow.

But first let’s evaluate the merits of one approach vs. another based on the needs, desires and aspirations of people that take part in, own, or design business processes for various functional domains. Many of these functional domains such as sales, commerce, marketing, design and engineering, manufacturing, order fulfillment, logistics, supply chain are interrelated. We can argue that ERP and various specialized application suites (CRM, Supply Chain, Human Resources..) already support many of the business processes. The problem has been that ERP and application suites due to their¬†transaction oriented design, complexity and cost, have left huge swaths of people that are central to business process out of the business process. These huge swaths of people have neither the visibility, nor take part in the business process.

ZFlow was designed and has been in use among many medium-sized to large customers for several years to address the above problems that many of these companies faced with ERP systems and application suites. Our customers have designed (themselves) business process workflows in many functional domains, including sales, engineering, manufacturing, order fulfillment, quality, finance and maintenance. What we learned from that experience is that workflow systems are best when they

  • Can support simple to sophisticated workflows that can bring user oriented activities (data preparation, reviews, approvals, etc.) and system integration (now called automation) activities into one process
  • Can handle process data, some of which can be fairly complex, that provides rich context to the process and often drives workflow logic
  • Provides an easy and methodical way for a very large number of people from within the organization and the supply chain to take part in and complete workflow activities
  • Do not charge for every user that participates in the workflow as it can be cost-prohibitive and counter-productive to the whole concept of collaborative workflow
  • Support invitation and participation of users dynamically as part of workflows
  • Require minimal or no programming (We definitely understand the need for programming for sophisticated workflows. In our experience, any introduction of code in a workflow system makes it less dynamic, but in some cases that is what is needed to provide meaningful and useful workflows)
  • Allow continuous updates and improvements to workflow easily. What’s the point of having a workflow if it cannot be improved as and when needed.

In all of the above facets, ZFlow has proven to be one of the best and remains unmatched. We don’t see that changing even with ServiceNow entering the market.