<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

How deep should process models go?

Have you been asked to do a process model and you just don't know the amount of detail that you need to do a successful process model? The level of granularity that you have in your process model will determine how useful it will be.

Any process model that you create has to stop somewhere. 

Now I'm not just talking about the left and right limits of that process. That's important but I'm talking about the level of detail that you place into that process. It is very tempting for us as process professionals to go in and have a look at all of the detailed processes and model those out because that's the stuff that's easy to obtain. Either by watching somebody do it or by looking up existing documentation. But when do you know it's time to stop? Well that's just as critical. 

The depth of process modeling is determined by the highest level to the lowest level of modeling. The highest level being the abstract level and the lowest level being the tactical level.

So in other words, from the abstract to the tactical, you need to make some leaps and bounds about how much granularity there is. Determining this granularity and keeping it consistent will ensure that process models created across your organization are consistent with your thinking. They're consistent to provide value to the organization and consistent for any end user consuming these process models to know what to expect. The key to ensuring the right level of granularity is, revisit your purposeful modeling. The purpose of modeling defines how much detail you require in these process models. More importantly, if you're going to use these process models for say communication then you need to ensure you're capturing the what of any kind of process.

An example could be clearing of a purchase order. The ‘what’ is, well, clearing up the purchase order. The ‘how’ is the detailed steps of where to click, the five to seven or so clicks on the application that determine the successful clearance of a purchase order.

So when you're process modeling all these tiers you need to be aware of which tier you're going to use for the right purpose.

Download Object Oriented Process Modelling Repository

Communication tiers are usually higher and of course tactical or more detailed information is usually at the lower tiers. Once you determine the kind of granularity you require based on your purpose of modeling, you are then able to extend that onto your conventions and standards and ensure that it remains as part of the way you work going forward.

So don't forget that each time you process model, it's tempting to stay at the lower levels but you need to bring yourself up to the abstract level and work your way down. The top down approach will ensure that the depth of modeling is consistent throughout the effort of process modeling in your organization. Now I'm not saying that every single process model needs to be the same amount of granularity. It depends on the purpose. The purpose highly determines how much information you put in each process model. The higher the level, the less information and of course the lower the level, the more detail that you want to put in there.

But ensure that you know you have an end game in mind. This kind of thinking of the detail helps you identify when to stop modeling and always approach from a top down -from an abstract to a tactical level. 

Watch Process Modeling Excellence Video Seminar - 45 minutes!

 

Related Posts

How To Replace Random Acts of Management With a Metamodel of Improvement

The simple existence of a problem is not enough reason to invest in fixing it, perhaps not now, perhaps not ever. Organizations need a systemic approach to define what good looks like, assess current performance, and make evidence-based decisions about which performance gaps to close. The Tregear Circles replace random acts of management with a metamodel for continuous process improvement. I have recently encountered several examples of the idea that higher process performance target scores are obviously better than lower ones, just because they are … well … higher; that setting a target of, say, 95% is, without doubt, better than a target of 88%, and in striving for improvement we should go 'as high as possible'.

Why Open Source Thrives on Cooperative Competition

Although I’ve spent the majority of my career on the consulting side of the fence I’ve also spent ten years on the client side, in senior IT roles, where I purchased a lot of software.  It was in 2006 that software sales people started offering alternatives to the traditional model of licence plus annual maintenance for proprietary software. These sales people were offering SaaS solutions and subscription-based open source software, neither of which I seriously contemplated buying.  Given that SaaS and open source software are now an everyday part of the IT landscape - why was I entirely unwilling to consider them a dozen or so years ago? The answer is simple. In neither case did they offer the benefits they do today, and, worse, the people selling them struggled to articulate what the real benefits of their offerings actually were. For the purposes of this post I’ll leave the SaaS model aside to instead focus on open source software. 

3 Ways to Measure the Usefulness of BPM

  In the fair dinkum department, the most important question about BPM must be "is it worth the effort?" It works in theory, but does it work in practice? What is the return on process? How should we measure, and report, the outcomes of process-based management?   The Wrong Answer Let's deal with the wrong answer first. It's not about the artifacts. No organization has a business problem called "we don't have enough process models." It is not a business improvement outcome to say we've trained 50 people on Six Sigma analysis, or appointed some process owners, or modelled a process architecture, or assigned process KPIs — these are all necessary, but none is sufficient. To the executive not yet fully engaged with the promise of process-based management, all this activity might sound more like a problem than a solution, more like a waste of resources than a successful outcome. And if that is all that is happening, she would be correct. We need good models, architecture, methods, and training — a metamodel of management — they are a means to an end, but not an end in themselves. Just having management tools is not the point; we must use them to deliver real organizational performance improvement. If our process management and improvement activities are not delivering measurable, objective, proven organizational performance improvements — improvements better than we might have otherwise achieved — then our process activity is, by our own definitions, waste.