BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, February 25 2016, 09:49 AM
  4.  Subscribe via email

From Anatoly Belaychuk, who recently wrote [url="http://bpm.com/bpm-today/blogs/1056-bpm-maturity-model-go-deep-vs-go-wide-strategy"]this article[/url]: "Many organizations adopting BPM aim to have all their processes defined; others prefer to get the full control of a few first. There are methodologies supporting each approach. Which path would you recommend?"



Patrick Lujan Accepted Answer
Blog Writer

Top-down and bottom-up as usual, I'll go with both. "Full control of a few first" is quick hits, visible, garners advocacy and engagement both. "All processes defined" is the long tail and an on-going effort. Process ontology, like content taxonomy, is a living breathing organism and is constantly examined (exhumed?), refined and improved if you do it right as you build up a library, catalogue of assets on "how we do process at this org."


Just my tuppence.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Emiel Kelly Accepted Answer

I always start from the fact that a process is a means; a means to deliver results. So by making clear what usefull results you have to deliver, you know what processes you need (and probably have already)


So preferably I would start with a clear overview of all the results customers can call you for. Then you also have your primary process landscape. BTW, this not the same as having the process mapped. It's being clear what processes you need/have. 


But if that's a bridge too far and my customer would like to start fast with 'doing something with process' I want them to make very clear what process we are talking about; so what process result we are talking about and if it is worth to take a look at that process.


All to prevent good old sub optimization (being good in useless things) or prevent trying to control too large pieces of work.


 
Common Sensei at Procesje.nl
Comment
Fully agree. I'd like to add to this the aspect of "make it slick, stick and practical". Too much canvas and artefacts are being created, emailed and stored without tractability, ownership etc. This is also not similar to processmapping (:-)). It's more governing and using (in a very practical way) process knowledge, something that's an issue in pretty much any organization IMO.
  1. Walter Bril
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Geoff Hook Accepted Answer

"Get control of a few Important processes first" is where I would start, however this does imply measurements and that you know which ones are most important. This approach enables the team to deliver some value to the business much earlier and not get accused of 'mapping everything' for the sake of it.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Garvin Fouts Accepted Answer
Blog Writer

Generally, it is very difficult for firms we work with to justify mapping out all their processes first as they are primarily buying a solution for a specific process which has extensive risk associated with it. Once past that process project, firms generally will start looking at other process pain points to address and how to budget for those. This also allows for contextual and capability education for internal staff so they understand what is possible with the tools when mapping and defining requirements for the next process project.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4

There are several approaches:


1. Top-down


2. Bottom-up


3. Pyramidal – see slide 4 in ref1


4. Center of crystallization


5. Pin-ball


6. Capability-based


Usually, I use the #3 (the top of a particular pyramid) and then ##3-6 at the same time.


Thanks,

AS
References
  1. http://improving-bpm-systems.blogspot.ch/2015/06/incremental-transformation-to-digital.html
Comment
Thanks Patrick.

4. Center of crystallization – there is a process to be done first and next processes are built around it.

5. Pin-ball – next process to do is the current “point” of the most leverage or the current “point” of most problems. Of course, any change in processes changes such a point.

6. Capability-based – is described in http://improving-bpm-systems.blogspot.ch/2015/06/an-example-of-architecting-digital.html

Thanks,
AS
  1. Dr Alexander Samarin
  2. 9 months ago
I'd be interested on more info for #'s 4-6 from your perspective.
  1. Patrick Lujan
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Walter Bril Accepted Answer

Do:

[list="1"]
[*]
Start with using a well governed [quote][i]single source of truth[/i]
in 1
[i]hierarchical [/i]
repository (or being modern :-) : a shared single source of truth (using blockchain technology))
[*]
[i]Always [/i]
define one level 0 (or 1) where, pretty high level, you have an overview of
[i]every single aspect (using what, when, why and who) of your business you need in order to generate value for your customer. This should cover the top-down.[/i]

[*]
As you do this hierarchical,
[i]only drill down where your current painpoints are[/i]
, gradually and continuously improving. This covers the bottom-up. But in context of the top-down.
[*]
Keep it
[i]useful [/i]
for any audience, creating a high value assett of process knowledge they can use immediately!
[/list][/quote]

Do not (ever):

[list="1"]
[*]
Create [quote][i]isolated pieces of (process related) information without context[/i]
(e.g., stuff them in some Sharepont site or H: drive :-))
[*]
[i]Loose your audience[/i]
(any audience) by using a language they don't understand, can't use in daily practice
[*]
Assemble a process team
[i]describing the processes[/i]
. Process-owners need to be able to describe them.
[/list][/quote]

It's not even that hard actually... :-). Or is it?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
David Chassels Accepted Answer

Remember the end game in BPM is to "digitize" so always start with one project that matters. No doubt much cynicism from users at start but once they see their ideas coming to life they will quickly be enthusiastic! Best keep IT out until those legacy links required and getting ready to deploy. Remember build should be direct from thier input.


This approach will quickly prove validity ( or otherwise) of the claims made by software vendor. As confidence grows so will the spread to other areas needing help. Will also give confidence that you do not need a final detailed spec as change should be readily supported all of which saves time = money = happy CFO!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Scott Cleveland Accepted Answer
I subscribe to the 80-20 rule. You will get 80% of potential benefits from getting control of 20% or your processes.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
George Chast Accepted Answer

Anyone remember the Enterprise Data Models in the 80s? They hung on a wall... And, that was all you could do with them.


Quick Wins or Die.
Comment
LOLOLOLOLOLOL! I'm dyin' over here.
  1. Patrick Lujan
  2. 9 months ago
Not surprising that so many clients hate the expression "quick win".
  1. Dr Alexander Samarin
  2. 9 months ago
It's paranoya, man! :D
  1. Anatoly Belaychuk
  2. 9 months ago
"Quick win" for whom? For the client or for the consultant?
  1. Dr Alexander Samarin
  2. 9 months ago
George, I think your answer explains the problem with “quick wins” – acting within LoB is local optimization. A potential impact of some “quick wins” on the whole enterprise (usually in longer time frame) is often not considered carefully enough.
  1. Dr Alexander Samarin
  2. 9 months ago
Alex, for the business. Always for the business.
They fund it, their stakeholders deserve a return.
Dividing things by consultants vs vendors ignores the important folks.
I have sat on all four sides of that table, LoB, IT, Consulting & Vendor.
I was the kid in LoB when IT couldn't help us, so I did it myself
I have been in IT when Consultants ignored what we knew & went in a crazy direction.
As a consultant, I always listened to LoB AND IT to get the best perspective & melded that with what I knew.
Now, on the vendor side, I weigh it all.
But, always, it is about the business and the employees. Always.
The business has to survive so the employees can put their kids through college and retire.
  1. George Chast
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Jose Camacho Accepted Answer

The best is first to understand the big picture of the company, business strategy and global processes (not necessary a big effort), and then, start to control the most critical for business, according to the strategy. We can identify more or less four kind of different approaches, as following:



1) If company wants to compete based on low prices, we should start with the core processes with more volume of activity,

2) to compete based on quality and innovation, we should start on those processes which conduct to unique products/services,

3) to compete based on placement/distribution, better to start on processes to ensure the products are in the right place at the right time,

4) to compete based on promotion, the bet is to start on marketing and sales campaign processes.



If we can focus on what is really critical, we avoid wasting time and money.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
E Scott Menter Accepted Answer
Blog Writer

Start small. Fail fast. Learn. Repeat.


Rework isn't the enemy: paralysis is the enemy. If you do a bunch of small things quickly, and some of it has to be redone later in order for things to fit better together—great: do it. While your competitors are restlessly tapping their feet, waiting for the steam bubbles to start rising in the ocean, you'll be enjoying the benefits of what you've already accomplished.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Anatoly Belaychuk Accepted Answer
Blog Writer


[i]The test of a first rate intelligence is the ability to hold two opposed ideas

in the mind at the same time, and still retain the ability to function.[/i]


-- F.Scott Fitzerald


Maybe this is the answer?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
John Morris Accepted Answer

Mr. Belaychuk's original article is worth a visit. The article emphasizes an aspect of BPM programme success that needs highlighting:
[u]the importance of management bandwidth as a limiting factor[/u]
for a BPM programme.


Here's the argument, as I understand the article:


Any newly automated process requires lots of management attention during the initial deployment transitional period ("

[b]too expensive in terms of management[/b]
"). Without this attention, and
[u]before additional process controls are in place[/u]
, the probability of new process failure is high.


We are refering here to "

[b]managerial labour[/b]
" (my term) or the significant cognitive load on managers typically associated with operationalizing a new process, likely for an extended period of time. This transitional phase cognitive load is separate from all the labour that goes into constructing a BPM-based automated process in the first place.


If one accepts this argument, then inductively, 

[b]given a fixed supply of management labour[/b]
[u]the larger the number of new BPM processes initiated, the higher the probability of failure of any individual process[/u]
and even the programme as a whole. (And this phenomenon is exacerbated as processes evolve, i.e. given that new process models are likely unstable, they are constantly in need of management attention.)


There's lots of rhetoric about why BPM is good for you. Mr. Belaychuk has opened up the "black box of BPM" and found work inside. It's a great antidote to the magical thinking that inevitably leads to disappointment. There's work to be done -- just make sure you budget for it.
Comment
Thank you, John.
  1. Anatoly Belaychuk
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13

From a video series I am producing. . .


[i]"Corporate infrastructure includes working capital, access to capital, land, plant, equipment, premises, tools, software, access to the internet, patent rights, best practices [read processes], staff, outside consultants, suppliers, products, services, marketing, customers and distributors".[/i]



There is no reason why processes should receive special treatment - i..e inventory these along with all of the above in a free-form-search hierarchical knowledgebase.


Nowhere does it say what the required level of detail needs to be - "process name/ general description / start node / end node" is better than nothing.


As and when ROI assessments or annual budget allocations earmark process mapping, simulation, roll out and process monitoring initiatives, best practices can be moved from "pending" to "In progress" to "in production".


The advantages of a free-form-search hierarchical Kbase for corporate infrastructure (all of the listed categories) is that you can organize/view knowledge in as many ways as you like, all at one screen. It's not uncommon to have 10,000+ documents in a small-medium corporation.


As for how to approach inventorying processes, top-down simultaneous with bottom-up seems to work across different organizations/corporate cultures.


 
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14

Thanks to Roger Burlton we know that maturity curve has two parts: “structure maturity” and “culture maturity”. The former can be imposed and the latter cannot be imposed. ( see the second illustration in ref 1)


It seems that ‘ “Go Deep” first’ recommendation demonstrates the preference to a technological way to address business challenges while we know that the people is the most complex part of an enterprise as a system.


Thanks,

AS
References
  1. http://improving-bpm-systems.blogspot.ch/2013/10/conference-bpm-in-practice-vinlius.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.