Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

Essential Business Modelling Definitions

A recent post I made called “How ‘As-Is’ BAs Deliver ‘Has-Been’ Enterprises” has resulted in a lot of discussion both on this blog and in Linkedin.

One of the major things to emerge from all of this discussion is the confusion that exists regarding clear definitions for the fundamental elements of Business Analysis and Modelling.

The absence of these basic definitions does not just result in muddled, and sometimes heated, discussions on LinkedIn, it actually results in very expensive business modelling errors around the globe.

So, in order to bring clarity to these ongoing discussions, I provide below what I see as the minimum set of definitions that all Process Modellers should have at their fingertips.

Business Function A Business Function is a discrete activity or a coherent set of activities that an enterprise must perform in order to meet its business objectives and continue in existence. ALL DATA in an enterprise is created and transformed by the Business Functions.
Business Process A Business Process is the definition of the order of execution of selected Business Functions in response to a specific Business Trigger, in order to arrive at the specified Preferred Outcome for that Trigger. A Business Process comprises five essential elements, 1) a valid Business Trigger, 2) the Preferred Outcome associated with that Trigger, 3) the Business Functions that are required to be executed in order to get from the Trigger to the Preferred Outcome, 4) the order in which these Business Functions need to be executed and 5) a list of valid Non-Preferred Outcomes in case the Preferred Outcome cannot be attained.
Atomic Business Function This is a Business Function at the bottom of a Business Function Hierarchy, it is a Business Function that has no child functions attached to it.
Elementary Business Function An Elementary Business Function is a Business Function which, once begun, must be completed or, if not completed, must be wholly undone. If there is a valid intermediate stage for the Business Function it is not elementary. An Elementary Business Function may take the business from one valid state to another or may leave the state unchanged.
Business Mechanism This is the means by which a Business Function is executed within an enterprise. One Business Function might be executed in several different ways, that is, using several different mechanisms. The specific mechanism would be dependent on the resources and technology available to those carrying out the Business Function.
Business Procedure Whereas a Business Process defines the order of execution of Business Functions, a Business Procedure defines the order of execution of Business Mechanisms in order to arrive at the Preferred Outcome associated with a specific Trigger.
Business Event This is any occurrence of significance to the enterprise. Business Events fall into two main categories Triggers and Outcomes, and can arise due to occurrences both within and outside the enterprise.
Business Trigger This is an occurrence of significance to the enterprise to which a response must be initiated. This response could either be the execution of a single Business Function or the initiation of a Business Process.
Preferred Outcome This is the outcome that the enterprise would prefer to have achieved by the execution of a Business Function or of a Business Process initiated by a Business Trigger.
Non-Preferred Outcome If a Preferred Outcome cannot be achieved by the execution of a Business Function or a Business Process, then this is a valid, acceptable, if non-preferred, alternative outcome.

All of my ebooks on the various Modelling techniques of the Integrated Modelling Method (IMM) contain a full set of definitions for all aspects of Function, Process and Data Analysis and Modelling, and Systems Development.

You can read more about these books in the IMM Store.

If you think that these definitions would be of value to a friend or colleague, please share a link to this page with them. Thank you.


8 Responses to “Essential Business Modelling Definitions”

  1. Putcha V. Narasimham July 13, 2013 12:06 am #


    Continuing on BB:

    I have seen that combining physical and logical flows in the same process map creates a lot of confusion.

    PP: For instance, the two paths out of a conditional branch are NOT two different paths physical paths. They go to the same subsequent process which acts differently depending on one or the other option.

    It is OK to show different paths if the object flows are involved and they follow different physical paths. So, I consider it inappropriate (wrong) to use the flowchart conventions for data flows.

    QQ: This condition is well managed in DFDs where branches are not shown but the two options are sent as Boolean data through the same dataflow path.

    I want to know how you model physical and logical flows.

    I have another comment on desirable and undesirable inputs and outputs which are slightly distinct from preferred and non-preferred outcomes. I will post it separately.


    • John Owens July 15, 2013 5:01 am #

      Hi Putcha

      PP: Two flows of control out of a Process Step cannot go to the the same subsequent Step. This is a fundamental modeling rule for Processes. Also, a branch (conditional of unconditional), by it very definition, must take the Process in one direction or another.

      QQ: Any flow, whether it is a flow of control, a flow of data or of a physical object must be shown by its own arrow (or other representation). Flows must be combined. Even using a Boolean representation would be wrong as flow of data and flow of control very seldom truly coincide.

      I have never used Boolesn flow in a DFD and would advise against it. It is suggesting that only two flows of data are possible. There could be very many. A DFD is not meant to show the circumstances of data flow only that the data flows. All of the data flows should be shown, separated by commas.

      Another note on DFDs is that they NEVER be decomposed and should only be drawn at the level of Elementary Business Function, at which level the flow on data/information is much simpler.


  2. Putcha V. Narasimham July 12, 2013 11:38 pm #


    I was reviewing the copies of posts on process modeling and I have seen your reply above just now (12JUL13 4.21 PM PST).

    I recall you asked me for my definition of what I call TRUE FEEDBACK. I have sent a link http://www.slideshare.net/putchavn/true-feedback-extended-abstract-pvn-04-jun13 and also a supplementary document since all the related definitions were in draft form.

    I do not recall receiving any response. In case I have missed it let me know.

    If you felt that further interaction would not be helpful, I can understand. At times I too feel that way with some professionals …. there are many such professionals on LinkedIn.



    • John Owens July 15, 2013 4:35 am #

      Hi Putcha

      If you click on this link http://johnowensblog.com/process-procedure-models-for-ebook/ it will take you to two diagrams, one a Procedure Model and one a Process Mdel, showing how feedback can be used in such models in order to modify the path through them in order to turn a potentially negative condition into a positive one, wherever possible.


  3. John Antos March 25, 2013 2:46 pm #

    APQC has following Process Classification Framework (PCF). APQC PCF was designed by people in industry and consultants over 15 years and has been used by thousands of organizations. Remember, everyone thinks their taxonomy is best. If you have not seen PCF or used it, it is worth reviewing and adding to your toolkit in helping organizations improve. It is of minimal value to say my approach is better except to feed your ego. It is far better to say what can I use from this that might help an organization achieve their strategy and goals.

    Level 1 CATEGORY 1:highest level of process in enterprise. e.g. Market and Sell Products & Services

    Level 2 PROCESS GROUP: Group of processes. e.g. Perform after sales repairs

    Level 3 PROCESS: Series of interrelated Activities that convert Inputs into Results; process consume resources and require standards for repeatable performance; processes respond to control systems that direct quality, rate, and cost of performance.

    Level 4 ACTIVITY indicates key events performed when executing a process. (e.g. Receive customer request, Resolve customer complaints. Negotiate purchasing contracts.

    Level 5 TASK: Tasks represent next level of hierarchical decomposition after activities. Task are generally much more fine grained and may vary widely across industries. (e.g. Create business case and obtain funding; Design recognition program and reward)

    You can download their 28 page PCF at http://www.apqc.org

    • John Owens March 25, 2013 6:28 pm #

      Hi John

      Thank you for including this reference. I have used it and similar structures in many enterprises in many countries over many years. I stopped using them because a) they wre so cumbersome and b) have so many inherent flaws, that include:

      • They totally confuse Function and Process. This is by far their biggest flaw.
      • They introduce arbitrary naming levels that suggestS that by splitting one element into two that it becomes two different things. So WRONG!
      • The introduces a huge amount of duplication and redundancy. The relationship between the bottom level and top level elements is not hierarchical, it is a network. Any bottom level element can be part of one or are higher level elements.
      • They require 3 to 4 more diagrams to be drawn than are necessary.
      • They totally miss out means of modelling data structure or flow.
      • They are big, cumbersome and essentially inelegant ways of modelling an enterprise.

      It was the existence of so many fragmented, unintegrated and cumbersome methods and techniques that was the major spur to me developing the Integrated Modelling Method.

      Again, thank you for including the reference.


  4. Putcha V. Narasimham February 25, 2013 2:56 am #

    Dear John Owen:

    AA 1: I have been reading your posts. I appreciate the need for radical and fundamental redefinition of concepts of business processes and their relations to many concepts of business and its environment.

    AA 2: More than a year ago I noted your special emphasis on the need for “orderlessness” of a function and “order” of business process. I did not see the need for it and maintained some distance from your efforts. Now, I see that the “subtle distinctions” you are propagating may be “necessary”. In this context I appreciate the need for “elementary business function” and its definition. I will study your publications and see how to support your crusading reforms. I hope your publications receive more attention from serious professionals.

    BB: I found UML Activity Diagram and BPMN are seriously flawed. They show only the control flows and ignore object flows. Also they mix physical and logcal flows. I do not recall your stand on them. Also we need to take care of feedback on which also I do not remember your approach.

    CC: I have noted some adverse criticism which was UNFAIR. I am sure you expected such reaction which arises mostly because your proposals are new and challenging—NOT because there is anything wrong with your proposals. I am really surprised at the rapid defensive reaction of conservative professionals who should have directed their analysis and criticism to what was wrong with what they followed without questions. I have seen you have thanked one such critic.

    Best wishes,



    • John Owens February 25, 2013 4:06 am #

      Hello Putcha

      Thank you very much your kind and constructive feedback.

      The distinct, if subtle, differences that I talk about are critical to producing repeatable high-quality results in business modelling, as they remove all confusion andambiguity.

      BB: When modelling processes in IMM it is easy to differentiate between the flow of control and the flow of information. You can also show the flow of physical objects, such as documents. However, in processes I have found that what is really important is to know what information is flowing, regardless of the document it is on.

      If I am going to show the flow of objects, then I use a variation of an Information flow diagram (very similar to a DFD), with the the object shown as well as or instead of the information flow.

      CC: It is amazing what emotions my proposals for order and consistency can tend to get from some readers. I could speculate as to why this is, but my speculations might seem unkind, so I will not.

      Once again, thank you for your kind feedback.

      Kind regards

Leave a Reply