| Introduction | | | | The succeeding Functions can then begin at any time |
| Before we can say what business process modeling | | | | convenient to the business, in accordance with |
| is we need to know what a Business Process is! This | | | | existing business rules. This definition is especially |
| may seem like stating the obvious, this is one of the | | | | useful as it makes the business ask the question, |
| most widely misused and misunderstood terms in | | | | "before we begin step X what other steps must |
| business and in business modeling! Analysts and | | | | have been completed?" |
| managers alike often use the term when what they | | | | More on Outcomes |
| are really talking about is a Business Function or a | | | | There are two types of outcome that can occur in a |
| Business Procedure. No wonder there is confusion!! | | | | Business Process: Preferred and Non-preferred. |
| Definitions | | | | A Preferred Outcome is the result that the business |
| Business Function: "A coherent, discrete activity that | | | | would like to achieve as the result of successfully |
| a business must perform in order to meet its | | | | carrying out the Process and should correspond to |
| business objectives and continue in existence." | | | | the stated objective. |
| Business Process: "Describes the order in which | | | | Every Process must have at least one Preferred |
| Business Functions need to be carried out in order to | | | | Outcome. |
| achieve a specified objective." | | | | A Non-preferred Outcome is a valid and controlled |
| So, in short, Functions describe what a business | | | | outcome other than the Preferred Outcome. |
| needs to do in order to continue in existence and | | | | Suppose that we are taking orders from customers. |
| Processes describe the order in which this needs to | | | | The Preferred Outcome would be "order authorized" |
| be done. | | | | but a Non-preferred Outcome could be "bad credit |
| From this we can also see that it is not possible to | | | | rating: order declined". A Business Process can have |
| do effective Business Modeling before we have | | | | several Non-Preferred Outcomes. |
| modeled the Functions!! | | | | Elementary Business Process |
| The Building Blocks of a Process | | | | Each step in a Process is a Function, which comes |
| The essential elements are: | | | | from the Function Catalogue (see the foot of this |
| - Objective | | | | article for more on this) and ought to be from the |
| - Trigger | | | | bottom level of the Catalogue as it stands at that |
| - Functions | | | | the moment in time. Ideally, these should be |
| - Precedence | | | | Elementary Business Functions (EBFs). A Process |
| - Outcome | | | | drawn using EBFs is called an Elementary Business |
| Objective: | | | | Process. |
| Every Business Process must have a clearly defined | | | | Decomposing Processes |
| objective that answers the question "what is this | | | | One of the biggest mistakes analysts make when |
| Process meant to achieve?". If the business does not | | | | doing Business Process Modeling is to "decompose" (a |
| have a clearly defined (written) view of what is | | | | lovely term!) Processes. This means that they break |
| meant to achieve then there is very little chance of it | | | | the Process down into more and more detail. |
| achieving it. | | | | This is a practice to be avoided AVOIDED AT ALL |
| It will not be possible to work out what Functions | | | | COSTS as it has two main faults: 1) it requires |
| need to be carried out and in what order in order to | | | | drawing far more diagrams than are necessary (up to |
| arrive at the preferred Outcome. | | | | 300% more) 2) it introduces fundamental logic errors. |
| In fact, without having a defined objective, the | | | | To avoid these errors all decomposition (somebody |
| business might not be able to define what the | | | | will have to think of a nicer word) should be done |
| preferred outcome actually is. This statement might | | | | using the Function Catalogue and each Process model |
| seem simplistic but it is the primary reason why so | | | | should be drawn using Functions from the bottom |
| many Business Processes are inefficient or fail | | | | level of the Catalogue (preferably EBFs). |
| altogether. | | | | Summary |
| Triggers: | | | | - Business Functions and Business Processes are NOT |
| These are events that occur that require the | | | | the same thing. |
| business to respond in some manner - they "trigger" | | | | - A Business Function describes what the business |
| a response in the business. Every Process must begin | | | | ought to do; a Business Process describes the order |
| with at least one Trigger. | | | | in which it ought to do it. |
| Outcomes: | | | | - Business Process Modeling should ALWAYS be |
| Other events occur as the result of activities carried | | | | preceded by Business Function Modeling |
| out by the business itself and these are called | | | | - Processes must always contain all of the defined |
| "Outcomes". In every Process the business gets | | | | elements of Objective, Trigger, Outcome, Functions |
| from the Trigger to the Outcome by carrying out | | | | and Precedence. |
| Functions in the correct sequence. | | | | - The objective of a Process should always be clearly |
| Precedence: | | | | sated in writing before the Process can be properly |
| Precedence is not, as many analysts mistakenly | | | | modeled. |
| believe, a definition of how the steps within a | | | | - Business Processes ought NEVER be decomposed - |
| Process are triggered. A more effective definition is | | | | this should be done using the Function Catalogue. |
| to say that it is a very specific way of defining what | | | | Note: The Function Catalogue is the core model of |
| Functions must have been completed before others | | | | the Integrated Modeling Method (IMM) a fully |
| can begin. | | | | integrated business systems modeling method. |