The purpose of this book is to:

• Define “Procedure” and how it differs from Process
• Define the elements of a procedure:
  • Triggers and outcomes
  • Controls
  • Method
  • Knowledge & skills
  • Resources
  • Evidence

• Aligning Procedure triggers & outcomes and to Process triggers & outcomes
• Decomposing Procedure triggers & outcomes
• Aligning triggers to mechanisms
• Procedure controls, including:
  • The standards to be used when executing the step.
  • The risk associated with step and the necessary mitigation.
  • The authorities required to execute the step.
• The method
  • The valid mechanism(s) for each step in the process.
  • The Function logic for each step. (This may be further defined by a Work Instruction).
  • The responsibilities for the execution of each step.
• Knowledge, Skills and Competencies
• Resources:
  • Plant or equipment
  • Tools
  • Hardware
  • Applications
  • Technology
• Evidence:
  • ensure that the step is being properly executed.
  • be able to demonstrate that it has been properly executed at any later date.
• Diagramming the Procedure
• The elements of the Procedure diagram
• Tuning the Procedure
• Swim lanes
• Work instructions
• Workflow vs Procedure

Is there any element of Procedure modelling that you think I have missed that you would like to see included in the book?

Have you got any special “tricks” that you have learned about procedure modelling that you would like to share with others? All original ideas that are included in the book will be fully attributed.

Please enter any suggestions you have in the comments box below.  I look forward to hearing from you.

“For about the last decade I have been using Capabilities to be what you are calling Function here. A capability is something a business does - regardless of how they do it. The nice part of Capability is that it doesn’t change, even when the implementation changes. Capabilities help you overcome the “How Trap” when eliciting requirements, when planning systems releases, and when performing organizational improvements and designs.”

My response to Dennis was:

I also use the term “Capability” but in a different way to the definition you gave. What a business does (more precisely what it OUGHT to do), regardless of the how it does it, I define as a Business Function. The different means by which a Function may be performed, I call “Mechanisms”. An example of this would be the Function “Accept Customer Order”. This could be carried out over the telephone, via fax or as an online transaction, i.e. three different Mechanisms for one Function. I align Capability with the standard English meaning of the word, i.e. what an enterprise is capable of doing and, in this sense, as with the title of your HBR article (which Dennis mentioned later in his comment), it may be associated with productivity. Capability couples a Function with elements that increase its depth, scope, productivity, etc. These elements could include knowledge, skills, technology, product portfolio, geography, and many others.

When talking to the executives of enterprise that want to grow Capability in a certain area, I ask a series of stepped questions beginning with the words:

“Are you currently capable of.. ”.

An example, is an insurance company that wanted to sell insurance products online throughout the US.

The first question asked was, “Are you currently capable of selling insurance products?”
The answer was “yes”, so no problem.

The next question was, “Are you currently capable of selling insurance products in all states?”
Now the answer was “no”, because the Enterprise did not have a licence for particular states. The solution was to obtain these licences.

The next question was, “Are you currently capable of selling insurance products online?”
Again, the answer was “no”, because their systems did not enable them to do this.

This enterprise was able to perform the Function “Sell Insurance Product”, but it did not have the Capability to sell in all states nor did they have the Capability to sell online. Two separate initiatives were put in place to provide this Capability.

This shows is how Capability is essentially different to Function.

Other posts on Capability are: Does Capability Equate to Process? and  Capability vs Requirement

I was recently asked by Jan van Bon from the Netherlands to define “the difference between a Function and Functonality”.

My reply was,

“A Business Function (or Function) is a core activity of an enterprise. It is something that the enterprise must do in order to meet its objectives and continue in existence.

Examples, of functions would be, ‘Sell Product to Customer’, ‘Bill Customer for Products Delivered’, ‘Recruit Employee’, etc.

‘Functionality’ is a general English phrase that is generally used when referring to a computerised system in defining what Business Functions the system fully or partly supports.”

Jan then came back with the following additional questions:

“You say a Business Function is a set of activities. Then let me ask you the next question:

Let me address these questions one at a time.

Does a Function Include People?

A Function does not include people. It may be performed by people but, alternatively, it could be fully automated and require no human input.

Does a Function Include Knowledge?

Well this depends on your definition of ‘knowledge’. All Functions require information (data in a context) as an input and may transform this information or create new information. As such, every Function will have an information output.

Every function will contain function logic and may also include business rules. In fully automated Functions, these will be built into the module executing the Function. Is this knowledge? Well perhaps it is as, without having the logic and business rules built into an automated module, humans with that knowledge would be required to perform the Function.

Does a Function Include Products?

A Function will always result in a product either physical or abstract. For example:

Does a Function Include All of These?

As the answers above show, sometimes ‘yes’ and sometimes ‘no’.

Is a Function a Result?

No a Function is not a result.

A Function is an activity that brings about a result. That result will be the delivery of the product for the Function, together with all of the information necessary to be able to ascertain that the Function has been successfully completed or, if not successfully completed, rolled back to the starting state.

Note: Function is synonymous with Business Function.

Read more on Business Function Modelling

Many of the points being made in the article were valid and sensible and then it read, “Each organization must align their processes, programs, and people to accomplish the unified goal that they expect from MDM.”

This is the point where I realized that something was seriously wrong. What this statement is saying is, “You have amassed all of this master data and you must now make sure that you totally organise your whole business around feeding and maintaining it.”

It’s a bit like all of the bees in a hive being expected to be totally dedicated to feeding and protecting the queen bee; to be an unquestioning and dedicated collective. Data is everything! Data must be served!

Well, and this may shock some people, data is not everything!

Data Quality Rule #1: “Data in any enterprise only exists to support the Functions of that enterprise”.

Data Quality Rule #2: “There are no exceptions to Rule #1.  Any data in an enterprise that does not support its Functions should be removed”.

Do all data practitioners think that data drives the organisation?  Is this a widespread point of view?  If so, businesses everywhere are in real trouble.  This may not be quite as bad as the lunatics running the asylum but it’s getting pretty close!

The statement in the article ought to have read something like:

“Each organization must ensure that all of the data held and used in the organisation (Master Data, Transactional Data and Reference/Domain Data) fully supports the Business Functions of that organisation.  It must also ensure that the objectives of all Processes and Programs are totally aligned with the objectives of the Functions.”

For clarity, a Business Function is NOT a business department!  Business functions are the core activities of any enterprise.  Sorry to have to put this in, but it is amazing how many analysts and managers get this wrong.

How would you score this post from 0 to 10?  If it is not a 10, what would it take to make it so?

Click to access the video on Removing Common Functions from  Hierarchy.

If you like this video or have any questions on the content please leave a comment below. I would love to hear from you.

Fundamental Rules of Data Quality

Data Quality Rule 1
Data ONLY exists to support the Business Functions of the enterprise. We might need to add Rule 1a, which is that a Business Function is NOT a Department! It is a fundamental business activity. Oh! and Rule 1b: A Function is not a Process!!

Data Quality Rule 2:
There are no exceptions to Rule 1. Data that is not used by any Function should be removed. If the data might be of value to someone else then the enterprise should put it up for sale, otherwise simply delete it.

Data Quality Rule 3:
Data quality is driven by Function Quality. Get the Function right and the data will be right. Rule 3a: Whoever is responsible for the quality of the Function is responsible for the quality of the data it creates.

Data Quality Rule 4:
If the enterprise does not have a Logical Data Model based on Business Function it has not got Data Quality. Rule 4a. A database schema showing tables and foreign keys is not a data model – it is a database schema!

Data Quality Rule 5:
Codes and Keys are not UIDs! This is a fundamental error made by a large majority of data analysts and data designers. Data Paradox: The use of unique keys as UIDs is the one means by which you can guarantee duplication in a database! See my posts on QUACKs and UIDs

So, instead of expending vast resources on trying to solve the insoluble, let enterprises take Alexander’s approach, cut through the cr*p knot and implement Data Quality Assurance by applying these Five Fundamental Rules.

The Integrated Modelling Method (IMM) combines a complete set of modeling techniques in a uniquely integrated manner that no other method does. This will enable you to consistently deliver high quality products, first time, every time.

This website explains all of the various facets of IMM. To help you get started quickly I have produced a set of Free Rapid Guides that you can get by leaving your details in the box in the right hand column.

I fear that the current approach to data quality will call for, either ever larger teams, or individuals with superhuman powers.  After all, what we are asking them to do is the equivalent of raising the Titanic!

In far too many enterprises, their data is indeed the equivalent of a massive wreck laying on the bottom of the ocean. How did it sink? Everybody is too busy trying to access the sunken data to even think about that.

Because nobody has bothered finding out why the data “sank”, all data newly created in the enterprise has the same flaws as the original and it too sinks to the bottom to join what has gone before.

Amazingly, instead of eliminating these flaws, the majority of data quality effort in enterprises, and the DQ industry as a whole, goes into developing ever more sophisticated dredging methods.  Many of the developers of these techniques are so pleased with their creations and have marketed them so well, that many enterprises now believe that a) it is not possible to create data without flaws that will keep it “afloat” or b) that it is cheaper to let it sink and then use the “amazing” new tools to recover it, than it is to remove the design flaws.

As long as enterprises perceive it to be impossible to keep their data ship afloat, then any person taking on the roll of Data Quality Director will either have to keep on developing or purchasing ever more sophisticated (and expensive) dredging tools or possess superhuman powers sufficient to raise the Titanic!

In a recent article on Data Quality Arkady Maydanchik was suggesting that a key solution to the current data quality issues that plague business everywhere is the creation of a dedicated Data Quality profession.

In a reply to the article I suggested that, far from solving the problems, the creation of a Data Quality profession was the one thing that would guarantee the perpetuation of data quality issues.

Root Cause Analysis

The only acceptable argument for setting up a Data Quality profession would be to eliminate all data quality issues, i.e. for the profession to make itself redundant.  Do you know of any existing profession, or can you even imagine one, who would be committed to this?  The sceptical among us might suggest that a Data Quality profession might even have a vested interest in perpetuating data quality problems.  What’s your opinions?

Most current data quality issues have their root in the separation in IT, for some crazy reason, of the roles of those modelling function and those modelling data.

Data only exists in an enterprise to support function. No other reason.

So, if you manage the quality of the data created and transformed by function, you manage the quality of all data in the enterprise.  The current separation of the roles of function and data analyst prevents this happening.

Function and Data Analysis Needs to be Combined.

Every good business analyst (and who would employ a bad one?) ought to be able to do high quality data analysis and every good data analyst ought to be able to do high quality function analysis.

And what would be call this combined role? Business Analyst. Because a good business analyst needs to fully understand - and that means analyse and model - both function and data.  Those that cannot are only understanding and modelling half the picture.

The Entity Relationship Diagram is every bit a much a business model as the Function Hierarchy or a Process Model.

More on Data Modeling | More on Function Modelling

Hard Coding Makes Life Harder

Due to inadequate (or no) data modelling prior to designing and building them, many restricting structures get hard coded into databases.  One of the most common examples of this are postal address structures.  Because systems usually start out being defined or developed by a team that is resident in one country, the postal structures for that country are usually what end up in the database.  This typically result in an address structure something like this:

The above structures might suffice for countries within the UK but would not fit the rest of Europe or the US. The analysts would defend their structures by saying that the few “foreign” addresses that they get are the “exception” and should be dealt with as such.

This seems a plausible argument but what they are really saying is “we have no intention of ever doing any significant business with any other countries”!

I wonder if the senior executives know that this decision has been made for them?

“Flexible” Does Not Mean “Unstructured”

Some data analysts try to avid the hard coding and arrive at solutions such as this:

This is not flexibility, it is simply a complete absence of structure.

Generic Structures Save the Day

Good general or “generic” data structures are the answer to the address structure problem - and to nearly all other structural database problems. A generic structure that can handle the postal address structure for any country is shown below.

The above structure would allow the structure for all countries to be handled by the database. By simply altering the order of data entry and putting Country first, all of the other fields required for the address structure for the country in question can be displayed and filled in.

Summary

• Inadequate data structures in databases are a major barrier to business growth.
• Inadequate data analysis and modelling cause flawed structures to be hard coded into databases or no structure at all.
• Proper data modelling, using an Entity Relationship Diagram, enable powerful, flexible, generic structures to be developed and built into databases first time.
• These generic techniques can also be used to address different national tax structures.
• Special care must be taken with Agile development to avoid the hard coding described above.

Useful Links: Read more of Data Structure Modelling | Get eBook on Data Structure Modelling