The Business Function Model: Powering the Enterprise

The Business Function Model is the single most powerful business model that an enterprise can have, for this reason it is an essential tool for every Business Analyst and ought be at the core of every Enterprise Architecture.

If you’re sceptical about this claim, have a look at the key benefits of the Function Model listed below, then you decide:

  • It is an unambiguous definition of WHAT the business OUGHT to be doing.
  • Not everything that is done in an enterprise is a Process. On the other hand, everything that is done is a Business Function. For this reason, the Function Model is the only model that can effectively model all of an enterprise’s core activities.
  • There is no duplication or redundancy in the Function Model; every Business Function in the hierarchy appears once and once only.

    Example Function Hierarchy Model

  • Because the Function Model represents WHAT the enterprise OUGHT to be doing, it enables future state Business Processes to be built straight off without needing to first produce any ‘As Is’ models – which are a major cost to, and cause of failure of, so many Process Modelling projects.
  • Every step in a Business Process is a Business Function and every Business Function comes from the Function Model, so it is this model that supplies the key steps for every Process in the enterprise.  Without the Function Model all process steps have to be ‘plucked’ out of thin air.
  • Business Functions define the key Data Entities of the enterprise and the relationships between these.  So, without the Function Model, you cannot build an effective Data Model for any part of the enterprise.
  • The Function Model can show the whole of the enterprise in a single model.
  • It reduces the number of models that are required to be drawn by a factor of three.
  • It does not require levelling: a painful, time-consuming and costly step required by decomposed process models.
  • It covers all of the business, not just the processes.
  • It remains valid through changes both in technology and organisational structure.
  • It is an essential model for all system development and system procurement projects, as it is the Elementary Business Functions (EBFs) from the Function Model that are implemented as modules in  computer applications.
  • It is a powerful planning aid for system development projects.

With so many benefits, it is actually very hard to overstate the importance and power of the Function Model.

The Function Model is the only model that provides all of the above benefits.  This means that any enterprise that does not have a Function Model will get none of these benefits.

This is not just an academic modelling issue; it will have real consequences in the business.  These include losses in quality, productivity, customer service, customer retention, profits and market share. It will also result in increased costs in all areas of the business due to duplication, inefficiencies, poor staff retention, bad data quality, etc.

Share Button

Tags:

5 Responses to “The Business Function Model: Powering the Enterprise”

  1. Chris Lawrence March 5, 2013 5:46 am #

    Hi John,

    I agree that painstaking as-is process modelling can be counter-productive. However there are some environments where top-down to-be function modelling may not be the best place to start either.

    In a financial services context for example it is possible to view business processes from a purely logical perspective in terms of what needs to happen to get from an implicit or explicit customer request to the requested customer outcome. This ‘what needs to happen’ can be specified by rules, and rules within rules. Functions then derive from applying the rules to the customer request – expressed as data.

    For example the customer request could be an insurance application, and the rules will include evaluation of risk. The rules could be such that (scenario 1) any application which does not meet automatic underwriting rules must be vetted by a human underwriter. Or (scenario 2) the rules could be that any application which does not meet automatic underwriting rules is politely rejected. In scenario 1 an underwriting function is required. In scenario 2 no underwriting function is required.

    I share your scepticism about many BPM/BPR projects. But there are business environments where there is value in seeing the business process model rather than the function model as primary. In financial services and other service environments (rather than, say, manufacturing or distribution) business processes can lend themselves to being analysed purely in terms of data and rules. The problem then is that few legacy IT systems embody much understanding of business process, which is why ‘BPM systems’ are brought in to fill the gap from the outside – whereas for optimised automation process architecture should ideally be on the inside.

  2. Sumana Lan February 25, 2013 5:55 am #

    I map the existing process to work out what need to be achieved and all the details along the way, this help me understand the process and importantly the goals, then I can pinpoint the duplication and improve the efficiency.

    • John Owens February 26, 2013 1:21 am #

      Hello Sumana

      Thank you for your input. Unfortunately, the approach you are taking will not work.

      There are two primary reasons for this. The first is that you cannot determine from an existing Business Process what it is that it OUGHT to be doing. The second reason comes directly from this first reason. Because you cannot determine what the Process ought to be doing, you cannot tune it, because you have no idea of what it needs to be tuned to.

      That was only one effective starting point for process improvement and that is to produce a Business Function Model (BFM) for that part of the business involving the Process. This BFM will be a clear definition of WHAT the enterprise OUGHT to be doing. Once you know this, you can then build and tune your process.

      Kind regards
      John

  3. Richard Ordowich January 30, 2013 1:24 pm #

    I think modeling is an excellent technique to represent complexity however many representations portray a simplified view of what is often a complicated environment.

    Hierarchical models such as an organization chart give the impression that decisions and power flows from the top. Business process models depict processes as linear and logical. When interviewing front line staff who execute the business processes we frequently discover numerous bypasses, loops, dead ends and redundancy.

    I think the first models developed should reflect the complicated environment as it exists not
    as we wish it to exist. It should also reflect the social fabric of the organization, the silos, boundaries and obstacles not just the technical aspects.

    Also few systems and business processes were architected in the first place. Most evolved, sometimes chaotically. Representing these in clean, well-organized and structured diagrams is not a reality of the manner in which these systems operate or were designed.

    Once these complicated models are evident, then work can begin to determine how to optimize the processes or systems they represent. The world is a complicated environment. Some problems in business are “wicked” and the earlier everyone recognizes this, the greater the opportunity for them to address the realities.

    • John Owens January 30, 2013 7:26 pm #

      Hi Richard

      Thanks for the comments.

      Existing businesses are not complicated environments, they are chaotic environments brought about by many years of bad practices and bad habits, in the absence of any clear definition of WHAT it is that they OUGHT to be doing.

      You say, “I think the first models developed should reflect the complicated environment as it exists not as we wish it to exist.” That is so wrong and one of the major reasons why so many Process Modelling projects fail to bring any real business benefits. Modelling ‘as-is’ business processes is a pointless and costly indulgence of process modellers around the world. It brings absolutely no benefits to any enterprise. It will simply give them a job for life!

      “Once these complicated models are evident, then work can begin to determine how to optimize the processes or systems they represent.” Again wrong.

      There is a great programming axiom that all process modellers should have etched on their foreheads, which is, “Before you make sure that the code is right make sure that it is the right code.”

      Another programming truth that these modellers should also know is that you cannot infer from a program what it is that it ought to be doing. This means that you cannot tune it without having a specification that defines what it ought to do. Without this specification, all ‘tuning’ simply changes the program from doing one thing to doing something else. Does it bring it any closer to what it ought to be doing? Impossible to know!

      Business Processes are simply higher level programs. You cannot infer what it is that they ought to be doing and, without a specification, cannot simplify or tune them – you can only change them.

      However, this is all solved by having a Function Model which is the specification of what it is that all Business Processes ought to be doing.

      “The world is a complicated place”. That may be true. However, businesses are not! I have worked around the globe in businesses of all sizes and have never come across a complicated one yet.
      I have, however, come across businesses that are run in the most complicated ways.

      Regards
      John

Leave a Reply

Visit Us On TwitterVisit Us On FacebookVisit Us On Youtube