Don’t Look in Existing Data for Master Data Entities

Posted on February 23, 2012 by John Owens

Why not? Because it is about as effective as looking in the dumpster outside a restaurant for the ingredients for a gourmet meal.

In my last articles on the major errors made in Master Data Management (MDM), I explained how most MDM projects start in the wrong place and then head off in the wrong direction.  They do this by looking for Master Data Entities in the existing data of the enterprise.

A bold assumption, you say.  However, in this and my next article, I will demonstrate just how badly existing data can mislead anyone using it without using Logical Data Model techniques.

An Example

Let us look at a typical example of data to demonstrate what can go wrong.


This example was taken from the entertaining “Three Shirts Video” by Jim Harris in which he talked about the various approaches people take to MDM.  My thanks to Jim for this.

At first glance the above interpretation of what each item represents seems sensible. However, if we take a more detailed look we will see that looking at items in the form of rows from a database in this way can easily lead to misinterpretations that result in structural errors in the Master Data Architecture of the enterprise.

The above interpretation would lead us to believe that the data structure they represent would look like this diagram.

This might seem to have captured all that that is needed. However, because we started by looking at data in an existing database, shortcomings and structural flaws have been built into this structure.  So what are these?

Sale / Product / Transaction

The key entity of Sale has been missed out altogether.  Transaction does appear, however, this is just a means by which Sales of Products can be grouped.  The Transaction should not have an attribute of Cost, as this is derivable from the Price of each Product (though this attribute of Price is not shown against Product in the example data).  Product and Sale have become confused.

How can we identify what the real structure ares?  By building a normalised Logical Data Model for the entities, like I have done below.

The above LDM shows us what the Sales and Transaction data structures should look like.

Customer & Vendor

The next error comes with Customer and Vendor.  Normally these two entities (we will assume for the moment that they really are entities) would never appear in a database or on an entity model together.  This is all based on knowing your ‘Worldview’  - being able to answer the question “In this transaction, who am I?”.  Are you the ‘Vendor’ or the ‘Customer’.  If you are the ‘Vendor’ then you will not have ‘Vendor’ on your data model or in your database, because it is always you. The same logic applies if you are the ‘Customer’.

However, you will avoid this confusion entirely by realising that there are no such entities as Customer, Vendor or Supplier! These in fact are all derivable Roles played by the entity Party – which is the key entity in MDM that is missed completely by so many people!! Derivable entities ought NEVER appear in your LDM.

I will return to the Role of Customer in my next article.

Address

The example labels two items as ‘Location’.  These are actually Addresses, they are the addresses of two Locations, the first at which the a Party lives and the second at which a Party trades.  Address is another entity that very often badly structured in databases. This is because it has not previously been modelled at the logical level in the LDM.  A powerful Address structure is relatively easy to model.  One thing to remember is that Address is NOT an attribute of Party!

You Don’t Need ‘Customer’

A major paradox is the amount of emphasis that so many MDM practitioners place on ‘Customer’, considering that a) it is not actually a Master Data Entity and b) probably 50% of the business in the world never need to know who the ‘Customer’ is!

Think about it! How many purchases do you make in a week and how many times do you you have to provide you name, address, phone number, etc. before you can pick up your purchase?  Not Many. Most businesses that you deal with do not need to know who you, the Party acting in the role of Customer, are!  So why would it appear on their data model or in their databases?

The only exception to this is in the retail world is where the Sale is a credit Sale.  In this circumstance the business will need to know which Party played the Role of Customer so that they can be billed.

Let us now put all of this information into a single LDM.


The above LDM show us what the data structures represented by the data in the example really look like. This is significantly different to what the original table rows suggested.

Please Share

If you liked this post and think that it could be of value to a colleague or friend please feel free to share it by clicking on one of the social media links below.

Post to Twitter

Posted in DataQuality, Master Data Management | Tagged , | Leave a comment

Information Gathering 2: Analysis Workshops – The Key to Detail

Posted on February 15, 2012 by John Owens

The purpose of analysis workshops is to add detail to the information gathered during strategic one-to-one interviews with senior executives.  They are NOT the starting point for analysis.

The following content is an excerpt from the eBook IMM Function Modelling

Who to Interview

Once again the choice of interviewee is essential to the success of the workshops.  These will be middle management and other key people from the business who:

  • Have a vision of the way forward for the business.
  • Can see the business in terms OTHER THAN how things are currently done, who does them and the systems used to support the business.
  • Are comfortable working in a workshop environment.
  • Support the aims of the business modelling project.
  • Are empowered to act on behalf of the part of the business they represent.

Form of Workshops

The term “workshop” is most often used to describe a gathering of up to twenty people to discuss a particular part of the business.  This is perhaps the most inefficient and ineffective way of information gathering and is to be avoided because:

  • It fails to achieve what workshops are intended to achieve.
  • Wastes peoples time.
  • Gives analysis in general, and the project in particular, a bad name.

The most effective workshops are with a small number of people – two is the best number.  If you need to interview six people it is better to hold three separate two hour workshops with two people at each rather than one six hour workshop with six people.

Experienced analysts can run workshops with larger numbers of people, say up to six, but even then time is wasted by the additional interactions brought about by the larger numbers.

It is acceptable to bring together a large number of people (say twenty) in one place at one time but not in a single workshop.  The larger group should be broken up into smaller groups (the size depends on the experience of the analysts) and the workshops run with the smaller groups.  Feedback can be made to the whole group at various times during the day.

The Mechanics

The basic guidelines for running a workshop are:

  • Hold it in a room big enough for four people
  • The room should have at least one large whiteboard and several colours (black, red and blue is sufficient) of whiteboard markers that have not dried up!  An electronic white board from which photocopies can be directly taken is ideal as it saves a lot of time but a standard large wall mounted whiteboard will do.
  • The room should have a least one flip chart – two would be better.  Use the whiteboard markers to write on the flip charts.  NEVER take indelible flip chart markers into a room with a white board!
  • Two analysts should run the workshop, one to lead the session and draw models on the whiteboard, one to take supporting notes and ensure the lead analyst is hearing all that the interviewees are saying.
  • Have no more than two interviewees!  Four is too many to interview at one time and three will always result in a 2-1 split on opinions!  Sit them so that they can comfortably see the white board and flip charts.

Some of the more simple things can catch you out.  For example, if the room does not have a table big enough to hold any materials that the interviewees might bring along plus the writing materials for the two analysts you may all spend most of the workshop balancing things on you knees or dropping them on the floor!  I know I’ve done it!

Whenever possible use an electronic whiteboard to draw your diagrams.  These are not just sophisticated toys but a huge boon to productivity.  Using one will enable you to give copies of all diagrams produced to interviewees to take away with them.  Remember that electronic white boards are to be used and wiped.  Do not leave your models on the board and expect them to be there next morning!

The interviewees should be told that copies of the final models produced from any modelling tool will be sent to them in the near future for them to confirm that what has been captured and modelled is correct.

Preparation

Interviewees for workshops should be prepared by explaining to them at the time of booking the workshop with them:

  • The purpose of the workshop.
  • The form it will take.
  • The business area and topics that will be covered.
  • Why they were invited and what they will be expected to contribute.
  • It may be that when you explain this that they will come back and tell you that they are not the right person to pick.  If so, ask them to suggest a suitable alternative.

Proper preparation before all interviews and workshops makes them far more effective and efficient, reduces the time required and results in higher quality modelling products.

Please Share

If you liked this post and think that it could be of value to a colleague or friend please feel free to share it by clicking on one of the social media links below.

Post to Twitter

Posted in As Is To Be, Function Modeling, SDLC | Tagged , , | Leave a comment

Information Gathering 1: Strategic Interviews the Foundation of Success

Posted on February 15, 2012 by John Owens

The one-to-one strategic in-depth interview is the most effective means of gathering information from senior directors and senior executives and are the foundation of all successful system development and business improvement projects.

The following content is an excerpt from the eBook IMM Function Modelling

The purpose of one-to-one strategic in-depth interviews is to find out from key executives within the enterprise what their opinions are regarding the business area in question and the improvement project itself.

Such interviews will give you a feel for, provided you listen to what is said (sometimes what is unsaid), what is most important to the interviewee and, as he or she is a key member of the business, it is vital that you know this before proceeding with the project.  This is the type of information that you cannot gather from documents alone.  All of the knowledge you gather here will help you to formulate a forward strategy for the business modelling project.

Who To Interview

Effective strategic interviews with appropriate senior executives are the essence of the success of any business modelling project.  The term “appropriate” means that the person:

  • Is knowledgeable about the business area in question.
  • Is a key player in that area.
  • Is empowered to define and implement strategy for that area.
  • Has a vision of the way forward.
  • Supports the objectives of the business modelling project

These interviewees will be key people and opinion leaders from the business area in question plus members of groups with a valid interest in the business area, such as auditors.

Another group of people who have a very strong interest in the business area are its customers both internal and external.  An enlightened business modelling project manager would see that there are significant benefits to be had by involving customers in the information gathering process.

The number of in-depth interviews will vary depending on the size of the organisation and the scale and scope of the study.

For a small organisation with less than 30 employees one or two interviews should suffice.  As the size of the organisation and the scope of the project increases then the number of interviews will increase.

Whatever the size of the organisation, interviewing numbers greater than 12 will give diminishing returns – great extra effort expended with little extra to show for it.

The interviewees should represent all areas of the business falling within the scope of the project, with some overlap into related areas (such as customers!) to ensure nothing vital is missed.  The objective is to involve the minimum number of people with the greatest knowledge who know what the business ought to be doing now and in the future.

Many projects fail because interviewees for early in-depth interviews are chosen at too low a level in the business, generally people with detailed “hands on” knowledge of existing systems.  Such people are (generally) unsuitable for in-depth interviews, as they tend to see the business only in terms of the current system(s) and procedure.  They seldom appreciate the underlying Business Functions and lack a vision of what ought be happening.

Do not be afraid to insist on having senior executives for in-depth interviews.  It is essential that you have, their input is vital. If you structure the interviews as detailed here you will ensure that you do not waste their time.  Making audio recordings of interviews will also ensure you will not have to re-interview these people and ask them the same questions over again.

Some or all of the interviewees must be in a position to make or agree a forward strategy for the project.

What to Ask

Key managers are interviewed separately, one at a time.  Preparation for these interviews is essential.  In a large organisation this can take between half and one day for two analysts.  A major output from this preparation is a basic set of questions to be asked of the senior executives that should include, as a minimum, the following:

  • What are the Business Functions that the executive sees as being within the scope of the study?
  • With regard to those Business Functions that are in the scope of the study and are carried out in the executive ‘s department:
    • What are the business aims and objectives?
    • What are the key performance indicators, i.e. what measures should the business area use to measure how well it is performing these Business Functions?
    • What are the critical success factors for the business, i.e. what must be achieved by the business with regard to these Business Functions for the business to be judged to be successful?
    • What are the critical success factors for the business modelling project, i.e. what must be achieved by the project with regard to these Business Functions for the project to be judged to be successful?
    • What does executive see as being the Strengths, Weaknesses, Opportunities and Threats (SWOT) for the business and for the project?
    • Are there and existing risks and issues within the business area?
  • What do they see are the risks and issues for the project?
  • Any other questions that are relevant are then added to the above list.

Avoid asking “closed” questions, i.e. those requiring just a “yes” or “no” answer – unless you require a definite “yes” or “no” answer on a particular subject.

In general, each question should be the beginning of a dialogue between the manager and the lead analyst.  The supporting analyst should help keep the lead analyst and manager on track and bring them back to the listed questions if they stray too far.

Two analysts are always better than one at these interviews, even in small businesses.  It actually increases productivity.

A major aim of the one-to-one strategic interview is to get information from the interviewees that could not be obtained in any other way, for example, their current opinions on certain industry topics and the elements of the business or the modelling project they see as being most important.

Another major aim is to establish that the manager supports the objectives of the business modelling project and the changes that it will bring about in the business and, if not, why not.

The final question should be: “Is there anything that you think I should have asked you and which I have not?”

Structure Not Straight Jacket

Some analysts think that giving such structure to strategy interviews is somehow limiting them.  Good analysts will know the questions they will need to have answered during an interview.  They will also know that the only way to ensure that they get them answered is to ask them during the interview and that the best way to ensure that they are asked is to have them on a list of questions to be asked!

None of the above prevents the analyst from being creative, asking supplementary questions and expanding the interview into an open dialogue where appropriate.  Structured interviews ought to be methodical but not mechanistic.

Planning

The duration of the interview can be calculated in advance based on the amount of time it ought to take for the manager being interviewed to answer all of the questions on the list.  The typed up list should be taken to the interview and used as the basis for the agenda.

The interviewee should be prepared by sending them a synopsis of the list of questions explaining the purpose of the interview and indicating the type of questions that will be asked.  Avoid sending the list of questions itself as many managers are tempted to treat this as a questionnaire, complete it and return it to you thinking that that is an end to the matter. This does not give you what you wanted as the questions were on the starting point for a dialogue; it wastes their time and creates a negative situation that could have been avoided.

Method

These interviews will typically last between two and four hours depending on the size of the organisation and scope of the project.  Two analysts should take part in the interviews, one to lead and facilitate, the second analyst is there to take notes and monitor the lead analyst, ensuring that he/she is asking the correct questions, is listening and hearing the interviewee, is reacting to their responses and not missing any critical points.

The second analyst also takes notes but these ought not to be the primary means of capturing the findings of the interview.

Ideally, all in-depth interviews should be captured by an audio recording and a manuscript produced from which all the analysts in the project team can work.  The interviewee should be assured that the tape will only be played to members of the project team for the purposes of making a typed transcript – then erased.

At the end of the interview thank the interviewee and say that you will feed back a transcript of the interview as soon as possible to ensure that you have correctly captured what you think they told you.

Getting More Setail

To read about how to add detail to the information gathere in Sytratgeic Interviews read Detailed Modelling Workshops

Please Share

If you liked this post and think that it could be of value to a colleague or friend please feel free to share it by clicking on one of the social media links below.

Post to Twitter

Posted in As Is To Be, Function Modeling, SDLC | Tagged , , | 4 Comments

If I Wanted to Get to Dublin I Wouldn’t Start from Here: Part 1

Posted on February 13, 2012 by John Owens

The evidence suggests that most Master Data Management (MDM) projects are starting in the wrong place and heading in  the wrong direction!

After recently watching a very entertaining “Three Shirts Video” by Jim Harris in which he talked about how people approach MDM, I left the following comment:

Hi, Jim.  Great video.

This approach to MDM puts me in mind of a story about a visitor to Ireland who is lost and goes into a local store to ask for directions. “Can you tell me how to get to Dublin from here?”, he asks. To which the storekeeper replies, “To tell you the truth, if I wanted to get to Dublin I wouldn’t start from here!”

And that is the problem with the current approach to MDM. Too many people are starting in the wrong place and as a result will never get to MDM!!!

Where is the wrong place? Looking at existing data!! This is SO wrong that it is like looking in the dumpster outside a restaurant for the ingredients to prepare a gourmet meal!

Where is the right place? Building a Corporate Logical Data Model (CLDM). The CLDM will define EXACTLY what all the master data entities should be and avoids the fragmentation and flawed structures caused by the current approach.

For example, any enterprise starting with a CLDM would never split Party into Supplier and Customer! Nor would it ever have product structures made up of concatenated free text fields, like the product example in Jim’s video, that exist in so many badly structured legacy databases.

The CLDM is the wiring diagram for MDM. Any enterprise trying to manage its Master Data Entities without it is going to waste a lot of time, energy and money and, in spite of that, never end up where they need to be.

Some things are fundamental, like the keel of a ship, the main spar of an aircarft wing and CLDM in MDM.

Another thing about the CLDM is that it totally simplifies this whole practice. Instead of battling with the complexity of existing bad data, it brings clarity and power through simplicity. It completely removes the mystique.

Ironically, that might be why people do not use!

Regards, John

In his video Jim also gave some examples of data extracted from existing databases that demonstrate how these structures can cause people to misinterpret them and build the flawed structures of legacy systems into their MDM models.

In the next two posts on my journey to Dublin I will show what these errors are and, more importantly, how having the CLDM will enable you avoid them.

If you liked this post and think that it could be of value to a colleague or friend please feel free to share it by clicking on one of the social media links below.

Post to Twitter

Posted in Data Structure Modeling, DataQuality, Master Data Management | Tagged , , , , | Leave a comment

The As Is Logic Chasm

Posted on February 1, 2012 by John Owens

The following is an extract from the book I am currently writing on Procedure Modelling. The book explains the approach to take in order to build quality Procedures and the pitfalls to avoid when doing so.  One of the pitfalls is what I call the ‘As Is Logic Chasm’, into which so many BAs and business managers constantly fall.

Procedure Modelling in a Nutshell

The three essential components of a Business Procedure are:

  • Business Functions
  • A Business Process
  • Mechanisms for Business Functions

So, put in a nutshell, in order to effectively model a Business Procedure you must:

  • First model the Business Functions in question.
  • Model a Business Process that will take the enterprise from the occurrence of a specific Business Trigger to a specific Preferred Business Outcome.  The Business Functions will be steps in the Process.
  • Identify and list the Mechanisms by which the Business Functions included in the Business Process can be carried out.
  • Build an individual Business Procedure for each Mechanism.
  • Merge, rationalise and optimise all of the Business Procedures that link the specified Triggers and the Preferred Outcomes.

And that, in a nutshell, is the approach to follow in order to build quality Business Procedures.

In the rest of this book we will tell you in detail:

  • Exactly how to apply each step of this approach at the general and detailed level.
  • The benefits of following this approach.
  • Why so many people do not follow this approach, thinking that it is a waste of time and that there is a ‘faster, easier’ way.
  • The costly pitfalls of ‘faster, easier’ ways.

The “As Is” Logic Chasm

To many managers and business analysts the above approach might seem very long-winded and, in their opinion, a complete waste of time. Their argument is, “We know what the business is doing, so why don’t we just document and model it?”

Indeed, this assertion seems so sensible that it can stop you dead in your tracks and cause to ask, “Yes, why don’t we just model what we are doing now. Why don’t we model the ‘As Is’?”

However, as you analyse this assertion it slowly moves from being eminently sensible to being, well, insane!  Let’s look at it more closely.

The business is currently doing something that is undocumented, so how can anybody know that it is doing what it is supposed to be doing?  The answer is that you can’t.

The business is currently operating on the assumption that it must be doing what it is supposed to be doing.  How could it not be?  Actually, the opposite is the case. Because it has not been documented, there is no way that anybody in the business can possibly know what the business ought to be doing.

Basic Business Rule: If it is not written down, it is not known!

If you liked this post and think that it could be of value to a colleague or friend please feel free to share it by clicking on one of the social media links below.

Post to Twitter

Posted in As Is To Be, Procedure Modeling | Leave a comment

Process Modelling or Process Mapping?

Posted on January 31, 2012 by John Owens

There is constant confusion between process modelling and process mapping.  The following are a set of definitions that will help dispel the confusion and provide other definitions that will help you produce better business models.

Process The definition of the order of execution of a series of Business Functions in response to a Business Trigger in order to arrive at a Preferred Business Outcome.
Process Description A description, in plain English, of what a Business Process does, what it includes and what it excludes.  It is an expansion of the process objective.
Process Diagram A diagram representing a Business Process.
Process Flow The order in which Business Functions are executed in a Business Process, i.e. the flow of control through the process.
Process Mapping This term can have two meanings.  The First of these is when it is used incorrectly as a term for Process Modelling.

The second meaning is the act of linking the steps of a Business Process to other elements within the business. For example, the business might want to map the steps of the Sales Support Process to organisation units or to job roles within the business.

This mapping can be done either by adding Swim Lanes to a Process Diagram or by building a Matrix Model.
Process Model A formal model describing all or part of an enterprise in terms of its Business Processes.  A Process Model will consist of a Process Diagram and a set of definitions for each element of the Process, i.e. Business Trigger, Business Functions, Preferred Outcomes and Non-Preferred Outcomes.

Each of the Business Functions contained in the Process will be Functions from the Function Hierarchy.
Process Modelling That set of activities involved in describing all or part of an enterprise in terms of formal Process Models
Process Name A unique name for a Business Process that succinctly encapsulates the objective of the Business Process.
Process Objective A definition of what a Business Process is intended to achieve.  This stared objective should align closely to the Preferred Outcome for the process.
Process Step A single step in a Business Process.  Process steps are always Business Functions from the bottom level of the Function Catalogue, either Atomic Functions or Elementary Functions.

The above definitions are an extract from the Glossary in the book IMM Business Process Modelling available from the IMM Online Store.

If you liked this post and think that it could be of value to a colleague or friend please feel free to share it by clicking on one of the social media links below.

Post to Twitter

Posted in Process Modeling | Leave a comment

Customer & Supplier are Roles – But What Type?

Posted on January 24, 2012 by john

In two of my previous posts ‘There’s No Such Thing as Customer‘ and ‘Logical Data Model for Customer and Supplier‘, I showed that, if you have data entities on your Logical Data Model called ‘Customer’ and ‘Supplier’, then you are in trouble both in terms of Master Data Management and  Data Quality.

The data models in both these posts showed that Customer and Supplier are definitely NOT master data entities, rather they are Roles that the entity Third Party can play in its  relationship with the enterprise.

Derivable or Declarative?

In order to find ‘Customers’ you simply had to list all Third Parties to whom the enterprise had sold a Product or a Service.  To find ‘Suppliers’ you listed all Third Parties from whom the enterprise had purchased a Product or a Service.

Using the data structure in these models meant that the Roles of ‘Customer’ and ‘Supplier’ were derivable from the data within the enterprise and, as such, should not appear as entities on the Corporate Data Model.

However, it may be the case that the enterprise might want to know Third Parties to whom it would be willing to sell products and services and, just a importantly, to whom it would not be willing to do so.  Likewise with purchasing items from Third Parties.  As no sale or purchase has yet been made, it is not possible to derive these Roles of ‘candidate’ Customer or ‘candidate’ Supplier from the data.  They have to be ‘declared’ in some way, making them declarative Roles.

Declarative roles for Customer, Supplier, etc...

Each Allowable Role can be assigned to a Third Party by creating an occurrence of Assigned Role with an appropriate Start Date. Entering an End Date de-assigns the Role but leaves a record of the fact that it at one time existed.

Adding More Detail

If you have roles that require more detail to be known and held, then you can add sub-types to Assigned Role and extra attributes to the each sub-type, as required.  If necessary you can even add extra entities to link more detailed information to the sub-type.

Contract of Employment as a Role

The example above shows where a new entity has been added to allow all of the detail for a Contract of Employment to be linked to a Third Party.

If you liked this post and think that it could be of value to a colleague or friend please share it by clicking on one of the social media links below.

Post to Twitter

Posted in DataQuality, Master Data Management | Tagged , , , , , | 2 Comments

Data Quality: Objective or Subjective?

Posted on December 28, 2011 by john

In a recent discussion in a blog on Data Quality one of the commentators suggested that one could not have an objective view about Data Quality because data was an not an object. I had to respond to this obviously confused view of the term ‘objective’.

Looking at Data Quality objectively in no way implies that one is suggesting that data is a physical object. An ‘Objective View’ is an opinion not influenced by personal feelings, interpretations, or prejudice; rather an unbiased opinion based on facts. A ‘Subjective View’ is, obviously, the opposite of this.

The real problem is that, without reference to the purpose of the data (i.e. the Business Functions it is meant to support), all opinions on its quality are, necessarily, subjective, i.e. placing excessive emphasis on one’s own moods, attitudes, predjudices, opinions, etc., or as one dictionary definition puts it, “unduly egocentric.”

Because so many (nearly all) discussions on Data Quality are carried out in the absence of Business Functions, nearly all data quality opinions are subjective. Quality, in any field, can never be achieved if its definition is expressed in subjective terms. Data quality, expressed without the context of Business Functions, will always be subjective and, consequently, can never be attained.

However, instead of identifying and accepting this simple and empowering fact and simplying and solidifying Data Quality definitions, many (far too many) practitioners and commentators try to portray Data Quality as such a complex and esoteric subject that it cannot be defined in a way that can be understood by mere mortals.

Complex arguments about Data Quality are merely that – complex arguments.  In the world of quality (in any field) good definitions always converge to the simple, bad definitions and misconceptions always diverge to the complex.

The fact is Data Quality is essentially simple – once you view and define it in the context of Functions.

If you liked this post and think that it could be of value to a colleague or friend please share it by clicking on one of the social media links below.

Post to Twitter

Posted in DataQuality | Tagged , | Leave a comment

Logical Data Model for Customer & Supplier

Posted on December 20, 2011 by john

The logical data model below shows the data structure needed to support Customer, Supplier and Employee.  Pardoxically, none of these appear as an enitity on model!

How can that be? There is a very good reason for this, which is that Supplier, Customer and Employee are all deriveable data entities and, as such, ought NEVER appear on a logical data model – to put them there would be both a major modelling and practical error. It is this error that is one of the major causes of so many data quality issues related to the concept of “Customer” around the world

Data Structure for Customer, Supplier and Employee.
From the above model we can derive Data Views for Customer, Supplier, Employee and, over an above that, Creditor and Debitor. This is because all of these are derivable roles for the true Data Entity of Party.

So How Do We Do This?

Customer Any Party to which the enterprise has sold a Product or Service.
Supplier Any Party from which the enterprsie has purchhased a Product or Service.
Employee Any Party with which the enterprise has a Contract of Employment.
Creditor Any Party to which the enterprise owes money.
Debitor Any Party which owes money to the enteprise.

There are many more roles that a party can play that are not deriveable, such as Guarantor,  Agent, etc.  It is these, and not Customer and Supplier, that should appear in logical data models.

If you liked this post and think that it could be of value to a colleague or friend please share it by clicking on one of the social media links below.

Post to Twitter

Posted in DataQuality, Master Data Management | Tagged , , , | 2 Comments

Customer is Not a Master Data Enitity.

Posted on November 23, 2011 by john

Having Customer and Supplier as Master Data Entities is about as sensible as having Creditor and Debtor.

Why? Because all of these terms refer to derivable relationships and implementing them as Master Data Entities is both a modelling and business error. If this is true, why are they so often modelled as such?

It all starts with analysts misunderstanding business terminology. Bad analysts hear the terms ‘Customer’ and ‘Supplier’ being used throughout the business and imagine that these elements are definitely Master Data Entities – “they must be, that are not transactional entities” – and model and implement them as such.  Some of these analysts are publicly passionate about this approach, saying that it shows that the ‘listen to the business’.  I wonder what such analysts implement when they hear the term ‘Punter’ being widely used in some businesses?

Good analysts also listen to the business. However, instead of blindly implementing structures based on the terminology in common use, they look for the truth behind the terms and hear what is really being said.

One of the most empowering questions an analyst can ask is, “what do you mean by…?” So, when good analysts hear a member of the business talk about ‘Customer’, instead of falling into the trap of thinking that this is so obvious that it would be silly to ask, “what do you mean by ‘Customer’?”, they ask the question and begin a dialogue that will bring a new insight and power to the business.

So let’s begin the dilogue.

Analyst: “What do you mean by ‘Customer’?”

Business: “It’s anyone to whom we sell our products and services.”

Analyst: “Are these customers individuals or organisations?”

Business: “They could be either.”

Analyst: “Could you sell things to people or organisations who supply you with products and services?”

Business: “Yes, we could and we do.”

Analyst: “Could you sell things to your employees?”

Business: “Yes, we do all of the time”

Analyst: “Could you buy products or services from your employees, other than the services covered by their employment contract?”

Business: “Yes. A lot of the artwork that we sell we buy from our employees.  Some of them are quite famous locally.”

The above dialogue shows that the term ‘Customer’ refers to a relationship that the business has with a third party, either an individual or an organisation.

The dialogue also shows that the business can have several relationships with a single third party, for example, ‘Customer’, ‘Supplier’ and ‘Employee’.  All of which have traditionally been seen and modelled as ‘master’ entities.

Because ‘Customer’ is not in reality an entity, but a derivable relationship, it ought never be modelled as Master Data.

The  simplifies several definitions:

A ‘Customer’ is any third party to whom the business has sold products or services.

A ‘Supplier’ is any third party from whom the business has purchased products or services.

An ‘Employee’ is any third party with which the business has set up a contract of employment.

We could add to this:

A ‘Creditor’ is any third party that owes money to the business.

A ‘Debtor’ is any third party to which the business owes money.

A good analyst will definitely be hearing the repetition of the phrase  ‘Third Party’ in the above definitions, which suggests that this might very well be the key element around which to build the Master Data Model. What do you think?

If you liked this post and think that it could be of value to a colleague or friend please share it by clicking on one of the social media links below.

Post to Twitter

Posted in DataQuality, Master Data Management | Tagged , | 1 Comment