Designing A Hierarchical Process Tree Diagram: Basic Principles

 

Drvo

In this post, I am sharing the following collection of basic principles as a guideline for designing a hierarchical process tree diagram (HPTD):

1. Designing an HPTD requires top-down approach. That is, a higher level of the HPTD contains less information than a lower level of the HPTD.

2. The root or 0-level of an HPTD represents the scope of the HPTD.

3. Process decomposition is considered completed if every leaf of an HPTD is a primitive process. The primitive process is a process that have zero-to-many inputs, but one-and-only-one output

Note: In some cases, it’s recommended to conclude process decomposition before reaching the primitive processes of the HPTD (see Point 4).

4. Best Practice Suggestion: In case of a domain with a large volume of processes, it is recommended to continue with process decomposition till reaching a reasonably acceptable level of the HPTD.

What is and how to establish this reasonably acceptable level of the HPTD?

The reasonably acceptable level of the HPTD is a level providing a set of information/details that enables a full understanding of the domain: mutual relationships between the instances of the domain and relationships between the domain and its surrounding.

In other words, it’s suggested that process decomposition needs to be carried out until the full understanding of the domain is reached, regardless of whether the lowest level of the HPTD contains primitive processes or not.

Or, simply saying, the full understanding of the domain can be obtained without having the completed process decomposition (see Point 3)

Establishing the reasonably acceptable level of the HPTD depends on many influencing factors such as:

Available time and resources
Complexity and volume of the domain
Current phase of the project life cycle  etc.
Sometimes, instead of ‘full understanding of the domain’, we may end up with ‘reasonable understanding of the domain’ due to – for example – limited time or resources. In that case, the gap between ‘reasonable understanding’ and ‘full understanding’ would need to be bridged by applying other approaches rather than proceeding with process decomposition.

5. Best Practice Suggestion: A process should have no less than 3 and no more than 8 of its sub-processes. However, the recommended maximum number of the sub-processes is not eight, but six.

Note: If a number of the underlying sub-processes isn’t between 3 and 6(8), it is an indication that the process needs to be reviewed – it could be that something has been overlooked.

6. Every process should have a name that uniquely identifies the process within a given domain

Note: If you are creating an HPTD for the as-is with two or more repetitive processes, you could name these processes by simply adding a suffix like: RepetitiveProcess1, RepetitiveProcess2 …etc.

7. An HPTD must not have processes structuring an infinite recursion

Note: Although this rule seems obvious, the question is: If some ‘as-is’ processes do structure an infinite recursion, how could the rule be implemented in creating an ‘as-is’ HPTD? My suggestion would be to map and decompose the ‘as-is’ processes as ‘to-be’ processes within your ‘as-is’ HPTD – for the major purpose of mapping the as-is is to deliver the to-be, in any case.

 

Basic Principles for Designing A Hierarchical Process Tree Diagram

tree diagram

I am sharing the following collection of basic principles as a guideline for designing a hierarchical process tree diagram (HPTD):

 

  1. Designing an HPTD requires top-down approach. That is, a higher level of the HPTD contains less information than a lower level of the HPTD.

 

  1. The root or 0-level of an HPTD represents the scope of the HPTD.

 

  1. Process decomposition is considered completed if every leaf of an HPTD is a primitive process. The primitive process is a process that have zero-to-many inputs, but one-and-only-one output

Note: In some cases, it’s recommended to conclude process decomposition before reaching the primitive processes of the HPTD (see Point 4).

 

  1. Best Practice Suggestion: In case of a domain with a large volume of processes, it is recommended to continue with process decomposition till reaching a reasonably acceptable level of the HPTD.

What is and how to establish this reasonably acceptable level of the HPTD?

The reasonably acceptable level of the HPTD is a level providing a set of information/details that enables a full understanding of the domain: mutual relationships between the instances of the domain and relationships between the domain and its surrounding.

In other words, it’s suggested that process decomposition needs to be carried out until the full understanding of the domain is reached, regardless of whether the lowest level of the HPTD contains primitive processes or not.

Or, simply saying, the full understanding of the domain can be obtained without having the completed process decomposition (see Point 3)

Establishing the reasonably acceptable level of the HPTD depends on many influencing factors such as:

– Available time and resources

– Complexity and volume of the domain

– Current phase of the project life cycle etc.

Sometimes, instead of ‘full understanding of the domain’, we may end up with ‘reasonable understanding of the domain’ due to – for example – limited time or resources. In that case, the gap between ‘reasonable understanding’ and ‘full understanding’ would need to be bridged by applying other approaches rather than proceeding with process decomposition.

  1. Best Practice Suggestion: A process should have no less than 3 and no more than 8 of its sub-processes. However, the recommended maximum number of the sub-processes is not eight, but six.

 

Note: If a number of the underlying sub-processes isn’t between 3 and 6(8), it is an indication that the process needs to be reviewed – it could be that something has been overlooked.

  1. Every process should have a name that uniquely identifies the process within a given domain

Note: If you are creating an HPTD for the as-is with two or more repetitive processes, one way of naming these processes would be adding a suffix like: RepetitiveProcess1, RepetitiveProcess2 …etc.

 

  1. An HPTD must not have processes structuring an Infinite recursion

Although this rule seems obvious, the question is: If some ‘as-is’ processes do structure an Infinite recursion, how could the rule be implemented in creating an ‘as-is’ HPTD? My suggestion would be to map and decompose the ‘as-is’ processes as ‘to-be’ processes within your ‘as-is’ HPTD – for the major purpose of mapping the as-is is to deliver the to-be, in any case.

My Experience With A Cup Of Coffee

portable-net-book-cell-telephone-lying-wooden-table-coffee-shop-interior-freelance-distance-work-filtered-image-64332000

 

How it all started

Once I had a panel interview for a very demanding role, so I was exposed to numerous questions by six members of the panel who were eminent experts with huge knowledge in their respective fields.

I was doing really well till about fifteen minutes before the end of the interview. Then, suddenly, one of the members of the panel asked me to design and analyse a process flow then and there, using an example of my own choice. I have to say that his request would’ve not been a big challenge by itself, if there hadn’t been a catch.

I was given a couple of minutes to come up with such an example that would be very simple and easy-to-follow, yet complex enough to provide a various alternatives to analyse. And, what did I do? Instead of doing my best in finding an adequate example, I just went blank.

I was literally in the state of hibernation when – out of the blue – in my thoughts I saw myself in my pedagogy exam … Yes, believe it or not, pedagogy was one of the non-maths exams I had to pass before obtaining a bachelor degree in mathematics …

So, now I am sitting across from my pedagogy professor, and he says to me: ‘Now, let’s see how fast you can think… Pick quickly a ‘thing’, any thing, and use it to explain the difference between pragmatism and expediency’. At the exact moment when the professor is finishing his sentence, his assistant is coming in holding in his hand something that catches my attention – a cup of coffee.

I can’t explain why I was so strongly drawn by that matte-white, ordinary cup, but it really inspired me to provide an answer that led me to getting the highest grade on the exam. That same cup of coffee ‘woke me up’, and I became aware of my interviewers, again.

I didn’t know how long I was ‘dreaming’; however my voice was pretty calm when I addressed the members of the panel: ‘If you agree, as an example, I’d like to use a process that I believe we are all very familiar with: Making a cup of coffee’. Even though, considering the circumstances, my idea might’ve sounded a bit awkward, I heard encouraging: ‘Please do carry on…’.

After briefly describing the scope of the process and drawing the first version of the process flow, I started step-by-step to build up a ‘business case’ and discuss its alternatives. By the end of the interview, my golden matte-white-ordinary cup of coffee secured me a job offer.

Sharing My Experience

I stayed in touch with my master thesis mentor/adviser, a university professor, and sometimes I assisted him in running workshops for students and one-day seminars for organisations to help them to start developing their own capabilities regarding process mapping.

One of those seminars was scheduled a couple of weeks after my job interview, and I suggested the professor to use the ‘Making a Cup of Coffee’ example. He did that, and the result was really amazing. The audience was very responsive and interactive, and by the of the seminar they produced four different process flows being designed based on the presented initial version of the ‘Making a Cup of Coffee’ scenario.

Of course, we didn’t use this example all the time in our seminars or workshops. But, whenever we would introduce it, we always received positive inputs from our audience and had wonderful results.

Next Step…

In one of my next posts I will describe this scenario and the initial version of its process flow, including a set of questions that we used during the seminar for the purpose of engaging the audience in analysis and encouraging them to take part in transforming the process model by changing relevant influencing factors.

In addition, the initial version of the ‘Making a Cup of Coffee’ process will be graphically illustrated with three types of diagrams for process modelling: ITIL, IDEF0 and Swim lane.

The update is coming soon, and I hope it will be useful especially for those who learn or teach basics of business process modelling.

 

Process Automation and Process Orchestration

violinaTalking about automation vs. orchestration, some people use these terms interchangeably, while others are very determine saying that there is the difference between process automation and process orchestration.

In one article, its author explains the mentioned difference as follows:

Automation is concerned with a single task – launching a web server, configuring a web server, stopping a service. Orchestration, however, is concerned with automating, if you will, the execution of a workflow – of a process

Actually, many discussions on process automation vs. process orchestration can be found, but my point is that in all of them – at least, in those one that I have had an opportunity to read or hear – the word ‘automating’ makes an integral part of all definitions of process automation and process orchestration.

I am not saying that it shouldn’t be so; however, why can’t we observe process automation and process orchestration beyond the ‘computing’ zone?!

If we step out from the ‘computing’ zone and broader our perspective, I wonder what the definition of process orchestration would be in that case? Would we then talk about process automation versus process orchestration, comparing them? Or, we would simply put them into different contexts, for we don’t need to automate a set of processes, in which case process automation is not taking place; however should we expect these processes to produce a targeted outcome we need to plan and manage their orchestration well.

Consequently, from this broader perspective, process orchestration would precede process automation meaning that – in this scenario- we wouldn’t think of comparing these approaches (one versus another). Instead, maybe a new definition of process orchestration would be brought to the table.

Just my thoughts…

Should a Business Process Be Automated?

Business Process Automation

Very often, in order to improve their business, organisations invest a lot of time in analysing and mapping business processes. And, as a result, a collection of business process models is produced revealing, among other things, business areas for potential process automation.

But, should a process be automated?

Not every process has automation potential. In other words, before we decide to automate a process, we need to determine if the process brings higher value from automation

Here are some examples:

 Duplicated process – It is important to explore reasons for the duplication of a process. Is it duplicated due to lack of IT system integration, for example? Or, maybe, the process owners created some kind of workaround that actually improved their overall work. In this case, preserving the duplicated process might be more beneficial than removing it through automation.

 Redundant process – As illustrated in the example above, not all duplicated processes are redundant. On the other hand, in the example below, additional analysis is needed to establish whether a process is superfluous or not.

Let’s take an organisation that manages insurance claims and let’s presume that the following two processes have been mapped: First-level Claim Verification (Process 1) and Second-level Claim Verification (Process 2). Also, apart from their names, it has been confirmed that the only difference between those two processes is their owners: Junior Adviser and Senior Adviser, respectively.

In making a decision on whether the claim verification processes have automation potential, the following would need to be clarified:

  • Are any of those two processes redundant, considering that they differ only in who performs them? If so, which one?
  • If Process1 is redundant and removed, where and how will Junior Adviser be engaged after that?
  • Will the removal of any of the processes have an impact on other mapped processes? Etc.

Those additional findings would specify whether Process1 or Process2 should be automated or removed as a redundant process.

Paper-based work – The automation of this type of work is almost always taken into consideration when tending to reduce costs and increase performance. But, should every ‘paper’ (i.e. a set of activities required for managing the ‘paper’) be automated? Well, sometimes, a process might be more effective if performed manually.

In general…

Various parameters affect whether a process is fit for automation or not. One of these parameters could be an organizational climate. Simply, people might be comfortable with the current state of things. As an oppose to that, in another organisation, there could be a process with automation potential, but due to lack of assets and/or human resources, the automation of the process would be unfeasible (in this particular scenario, could it be said that the process has automation potential?! I wonder…)

Anyhow, if we want to say with certainty that a process could and/or should be automated, a broader perspective is required (benefit analysis, strengths/weaknesses, impact assessment and so on). Otherwise, we could end up with tons of specifications, workflows, and other documents suggesting ways of improvements, but not having tangible results.

How to Design an Operating Model – Part 2

With regard to my previous post, the Business Analyst fellows who contacted me in the meantime had some questions about the control mechanisms I mentioned, and role mapping and decomposition of operations in operating model designing, so here are some more details about that.

In short, the control mechanisms are regulations, instructions, rules, standards, contracts, legal framework etc. that constrain or/and direct processes/operations. Often, in business process designing, it is not necessary to map those control mechanisms, but they are very important when it comes to operating model designing as your operating model also needs to define governance process.

Let’s take, for example, the situation where two business units (BU1 and BU2) within your organisation have their own work instructions (WI1 and WI2) defined and your responsibility is to create an operating model at the organisation level. Also, let’s assume that some changes have been made in WI1. Without mapping WI1 and WI2, your operating model will not indicate if and how those changes affect WI2. This means that, in the case of mutual dependencies between WI1 and WI2, governance might fail.

Governance means all the processes that coordinate and control an organization’s resources and actions

In creating an operating model, it’s also important to apply the principles of business process (i.e. operation) decomposition. This decomposition needs to be a functional decomposition, but not completely separated from the organisational hierarchical structure. Regarding this, I came across this video clip that I believe can provide a bit more information.

Finally, role mapping… Actually, the only thing that I’d like to highlight here is the following relationship between the roles and control mechanisms. Generally, a control mechanism of an operation is usually in a form of a document and as such it represents an input of the operation. If the role that manages this control mechanism is not the same as one that conducts the operation, then the operation should have two roles assigned: a) Role1 that performs the operation and b) Role2 that manages the control mechanism.

Image

Increasing ROI of Project by Including Benefits of ‘Hidden’ Cases

http://attackofthecute.com/on/?i=1102

Generally speaking, in providing IT project delivery services, it is considered that a project is successful if it has fulfilled clients’ requirements, and has been delivered on time and within budget.
Of course, a return on investment (ROI) from the project is also something that is taken in consideration – or, shall I say, expected. However, I believe that most of the time, in calculating ROI, benefits that could be created during the process of project development (and prior to the project completion) are somehow omitted.

It usually goes like this…

Prior to initiation of a project, a relevant cost-benefit analysis is performed in accordance with the scope and purpose of the project. If the benefits outweigh the costs, the project is justified and can be moved forward.

Nevertheless…

Once the project development has been started, due to influences of the environment, there is a possibility for new – previously ‘hidden’ – cases to occur before the project completion.

Continue reading