Business Process Discovery – Basics

Every business has literally thousands of business processes. They range from business critical (e.g. client billing and recovery) to seemingly unimportant (e.g. employee leave request and approval).

 What people sometimes fail to recognise is that each of these has to WORK successfully both in its own right but also integrated with other business functions and processes.

 It is almost impossible to have a successful organisation that does not depend on the effective running of these processes. (I did it now J I used the word effective.)

 If you want to do something effectively, you have to know what it is; understand how it works to stand any chance of improving on it.

Welcome to Business Process Discovery

The steps to achieving this are:

1. Define Basic Process
Contrary to popular belief, you don’t have to get it right the first time. It simply has to include the most critical steps, functions, or decisions.

All these elements get noted is a simple format:

What should be focused on are questions like these:

  • What are the business output requirements?
  • How do we get to the delivery?

No values– Just a sequence of events

2. Describe Event (External)
Events usually have the following components:

  • Inputs
    • Documents
    • Data
    • Communications
  • Outputs
    • Documents
    • Data
    • Communications
  • Business Rules
  • People
    • Do
    • See

Basic rule – If multiples (components) occur, split the event into constituent parts (e.g. if two groups of people interact during the event, separate the event to address one group at a time).

3. Describe Event (Internal)
Which functions or actions occur within the event?

Please don’t be shocked when you discover that within the event there exist many or multiple mini processes.

Obviously the same route has to be followed in discovering the workings of the internal processes.

4. Limit Depth
As seen from the previous points, this could be an iterative, looped, and therefore almost endless cycle.

You can elect to manage internal discovery can also occur as a black box.

This, however has to be noted and the result of a decision.

5. Assemble Process
Well now most of the elements to successfully complete assembly and accurate description of the business process is in place.

The elements that govern how events relate to one another (business rules) can now be clearly described and noted.

Oh yes, as shown; now things like the ability of events to occur simultaneously or be processed in some predetermined sequence will become evident.

6. Evaluate – Feedback Loop
Is the process is executed as described:

  • How does the results compare to the initial requirement?
  • Is the process complete?
  • Does it fulfill all of the desired requirements?

This question and answer section is commonly called a Feedback loop.

The aim of the feedback loop is simply and irrevocably to ensure that the process is functioning optimally.

7. Standardise, train, replicate, implement, evaluate, and improve.

The aim of any business process description is to improve the business in which it functions.

The heading of this section describes the process that governs the management of all business processes.

Happy Happy – You’re done.

Posted in BPM

3 thoughts on “Business Process Discovery – Basics

  1. Hi Anton it’s me again 😉

    I was wondering, you place the loopback evaluation at the end of a string of events.Why do you do that? It is possible of course but should every event not in theory have their own Loopback evaluation?

    Maybe I can explain what my question is by an example.
    Let’s take this Business Process as an example. Taking the train from Amsterdam to Rotterdam to visit mum.

    Input is my mum calling me to come over and me saying that I will. This is what I define as process;
    Event 1 is walking to the trainstation
    Event 2 Buy Ticket
    Event 3 Get the train
    Event 4 Get out and walk to my mum’s house
    Output is a happy mum

    All of these do in general have their own Feedback Loop Evaluation that I can give a status A B or C. These statuses ALWAYS exist from 3 figures.
    A) Not started
    B) In Progress
    C) Finished
    In a three dimensional world there can never be a status more than those three.

    There is always 1 status per process and a process should be made up from Plan, Do, Check, Act. (The check of course is your Feedback Loop Evaluation)

    You will now get a process walkthrough:
    Event 1 is walking to the trainstation Status A, B or C
    (Not walkin, am Walking or Arrived at the trainstation)

    Event 2 Buy Ticket A,B or C but can only be B or C when event 1 is status C (Part of Business Logic) and Status B is not Valid since I either Have or have NOT bought the ticket.

    Event 3 Get the train Status A or C (again B not relevant)

    Event 4 Get out and walk to my mum’s house Status A,B or C

    I am wondering how you would describe an “Event”, is that a process on itself for you or am I misunderstanding something?
    And if it is a process, how would you decide on processes/events and their SUB processes/events

    Basiccaly how do you decide how deep down the rabbit hole you want to go?



  2. Hi Erwin,

    Great to hear from you too 🙂

    At first I would like to clarify that events (in my mind) are all processes (this include decisions). Secondly (in my mind) each process can be rolled up as an event in a larger process.

    This leaves me with the situation that each process can be seen as a sub or main process simply by changing your perception. That is why I try to veer away from that naming convention.

    So events are simply “packaged” processes that form part of larger processes.

    If we can then see that we end up with a hierarchy of processes, in a simplistic view, we will soon discover that we can go up and down the food chain (hierarchy) dependant only on perception or viewpoint.

    If we roll up your travel arrangements to visit your mother (in the example you supplied) into an event, we can comfortably place it in the larger process of what are you doing today? (Wake up, eat, go to mum, we go shopping, we have lunch, come back, make supper, sleep).

    Conversely, we can chop up the process of walking to the train station into smaller chunks, where you evaluate the walking part in sections, where you have to lock your front door, cross the road , draw cash money on the way, etc.

    The statement that each event will have its own feedback loop, is therefore correct. But to make sure that we apply the design rule consistently, we have to apply the feedback loop to the process we are currently describing. This would allow us to “package” the process into an event.

    Done this way we discover that we end up with reusable events, that we can slot into other processes, without having to define them again.

    The model works well with a few notable elements to consider:
    • If not careful, we can introduce events that will cause a process to loop within itself (only bad if not done unintentionally.)
    • We discover inter process dependencies that are not obvious (e.g. you only have so much money and the trip may endanger your plans for the next day.)
    • Multiple instances (occurrences) of the same process may highlight “bottleneck” or resource intensive dependencies (only bad in a finite world :-)).
    • Inter-dependence quickly adds complexity beyond our ability to visualize the situation.
    • Complexity may divert attention away from why you initiated the process in the first place (heavy reliance on the feedback loop.)

    How deep you go down the rabbit hole is dependent on a ratio -> effort to benefit. If the effort to describe and manage the process is worth the benefit of possible replication, use, or management of the event, do it. If not – don’t.

    Hope this covers all of your questions.

    Have a good day!

  3. Hi Anton,

    Yep, well put and explained.I think we are on the same page here. I was especially interested in the last bit, I like your comment that it is ratio that decides how deep we go down the rabbit hole. I believe there can never be a methodology or system to replace that ratio.
    Ratio combines experience and gutfeeling, both not to be found in systems.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s