By Laila Pesoa
2019 SUNsource Leader Board Member

As we said in the previous blog, What should Super Users know about Knowledge Management? (I): What is in it for me?, the Super User is the person who is closer to the team and therefore is the best person to tell: who on the team needs what information, when and how it should be available, not forgetting why it is needed in the first place.

To do this, however, the Super User has to be able to identify and classify correctly the type of data/information that exists in his department in the first place, so as to know the best way to store it and make it available. This is not very straightforward. Just to mention the ones you most commonly “find in your desk”, any data or information can be Master Data, Reference Data, Transactional data, Process information or a Business rule.

Let’s start with definitions, then go through an example, and finish with some tips on storing information.

Basic definitions and where to store the data:

• Master data: “is the consistent and uniform set of identifiers and extended attributes that describes the core entities of the enterprise including customers, prospects, citizens, suppliers, sites, hierarchies and chart of accounts.” – Gartner, Inc.[1] See below some of the entities a retail company has in the system. All the information related to each of these entities, used for transactions (when the process is executed), are master data and should be maintained in the ERP system.

Master data is used for transactions. Transactional data describe business events and is responsible for generating the largest volume of data in the enterprise. It resides in the CRM, ERP, SCM, or other systems. [2] For example, purchase orders, sales orders, etc.

• Reference Data: often considered a subset of master data, it is shared by and used across different internal and external systems and used to give meaning to master data. [2] Sometimes it does not make sense to keep this data in the ERP system, depending on how much it changes and who uses it.
  
  The biggest problem is not in confusing it with core master data – it is in confusing it with process information. Reference information has to be considered when executing the process, but it should not be kept on process documentation. Why?
  
  • Because it usually refers to specific Customers and Entities, whereas the process is in general applicable to all of them.
  • Since it refers to a Customer’s/Entity/s it isn’t necessarily something very optimal, which you would like to include in your company’s standard process.
  • It can change much more often than the process steps, so having it stored on controlled documentation either creates extra work (rounds of review and approvals) or leads people to give up updating it.

• Process information: details how a process should be performed. The basic SIPOC: Supplier, Input, Process step, Output, Customer.
  
  The process can be captured in Procedures (steps explanation in text) or flowcharts (as a diagram of the flow). These documents should be controlled to be sure only the Process Owner (or someone with proper knowledge and authority) can update the steps, since they define how are the operations.

• Business rules: are statements that define or constrain some aspect of the business. Business rules have a business motivation (come from Business Decisions) and bring value. The biggest difference between “Process information” and a Business rule is that the first is defined based on the most effective way to do something, or on how the system works, while the latter comes from a business decision. This means that you could have different business decisions with similar results in terms of efficacy and efficiency, but a decision was taken that a certain approach will always be taken. This enables greater business agility, for it diminishes the number of decisions that must be taken on the fly, case-by-case.
  
  Business rules can be stored together with “Process Information” or with “Reference Information”, depending on the nature of each rule. But it should be made clear that this information is a business rule, not a Process step. This will affect both who can update it and what can be touched when working on a process improvement.

One example: raising a kid

Let’s look at an example to make this more practical. It may not be very precise (as Box and Draper said, “Essentially, all models are wrong, but some are useful”), but it helps understanding the concepts.

Let’s say you have a kid. There are things that are really part of your kid’s “essence” and go with her wherever she goes: name, temperament, when she was born, her tastes, etc. This is your child’s Master Data. Your kid is part of a lot of processes, either performed by her or by others around her: educational process, raising the kid, eating, doing sports, etc. Some of these processes are core for the child’s development and others aren’t, but nevertheless, they are all processes. Each time you take your child to school you are performing a transaction that is part of the educational process, for example.

When executing the processes, you have different kinds of information involved. Reference information would be to which school she is going at the moment, the doctor’s telephone, chores division at home or a special diet the kid needs while sick. These have to be considered when executing the process, but are not really process information.

About Records, I don’t think parents need examples… They are all documentation and other things the parents keep: school grades, diplomas, works from school, “the first drawing”, health analysis results, etc. This shows what has happened at specific moments in time.

Lastly, there are the Business rules: “on Sundays, the family has lunch together”; “No watching TV before you have finished your homework”; “You will have to eat all the food you serve yourself”. I am sure you have a long list of these…

Last tips:

• Don’t store information on emails! Even if you use email to inform your team about updates, be sure you have captured the new information in the proper place.
• Do not include Reference information, or other information that is changing all the time, in the Process documentation. The “changeable” part should be stored somewhere else, and the Procedure or Flow can make a reference to it. E.g., always refer to roles, not names and personal emails. If needed, maintain a separate table with the roles and the corresponding people, on a place where it is easier to update.
• Be careful with the links between different documents and tables. Be conscious that links have to be kept up to date, so be sure you need all the links you are creating, and that you know where they are.
• When you identify all different types of information your team is using, build a knowledge map to be sure it is clear where all is stored, who is maintaining it and how often. The next blog will give some tips on how to build a Knowledge map for your department.

[1] https://www.gartner.com/it-glossary/master-data-management-mdm/

[2] https://www.semarchy.com/en/overview/what-is-master-data/