Something brought up by Scott Francis in [url=http://www.bp-3.com/blogs/2015/10/to-model-or-not-to-model/?nabe=6102089601122304:0]this blog[/url]. So to focus on processes for this discussion, does it always make sense to model processes?
No. However you should have an single source of truth, CxO agreed level 0 (or whatever you want to name it) and drilldown more (or less) deeper to those area's that require attention.
Where needed you can attach / build detailed models: As you have an agreed top level,
[i]you have a context[/i]. And context is the key here. I see too many times modeling exercises in their own right, reinventing wheels, cause sub-optimization etc.
Sure, to determine viability and practicality. I have an approach to automatically design business processes based on inference. It will design a "correct" sub-system to match the information requirements. Even so, I only look at it as a model to determine its viability. If acceptable, I update it into a Repository.
All the Best,
Greetings, Friends! Thought I would drop in as I do miss you all as I am off to focus on the Mobile Enterprise.
As usual, my answer is No and Yes and a Twist. No, processes need not be modeled first as the only best practice -- plenty of little successful projects start with automation. And, they have since the Client/Server days. (I was the kid in the business unit doing that when the first IRMA board leaked data off the mainframe) This incremental approach gives tremendous value by allowing the cow paths to be analyzed and never paved. Just iteration number one... So, there is the No and Yes. Now the Twist. How does that
[i]change[/i]when one takes Mobile into account? We know two things, that the world is moving quickly toward mostly mobile workers, partners & consumers and that the moments of engagement with the process are much different. Does it matter more then that we model first? Or, is my premise still valid?
Of course now that the “Model” can be the Application! Yes Declarative MDE (Model Driven Engineering) opens a new door. All proven 20+years R&D and waiting for the market to be ready. Such capability builds Adaptive Applications for all enterprise operational requirements putting people first.
Detail on how here in my contributions for those interested [url=http://modeling-languages.com/modeling-community-why-model/]http://modeling-languages.com/modeling-community-why-model/[/url] Might depend where you are on the Mahatma Gandhi’s scale of belief “First they ignore you, then they ridicule you then they fight you, then you win” plenty to think about…..but for sure it is the future…working on the plan to get it to the winning point!
And if you think I am “nuts” listen to first 30 mins of this [url=https://www.youtube.com/watch?t=23&v=BM8wuqPmVBg]https://www.youtube.com/watch?t=23&v=BM8wuqPmVBg[/url] new power source nothing to do with process; point is the World is changing and for sure Enterprise Software long over due for BIG change!
In my opinion YES, you should start by modeling the process. But, when I say modeling, I mean abstracting the reality in a model. It doesn’t mean a formal model in a BPM tool. My suggestion is to model the process as quick as possible, even in a piece of paper.
Then, you can evaluate or discuss the importance of the process, its complexity, depth, width and relevance for your business. It is an important enabler for a rich discussion, having at least a basic map of the process.
In fact, you can see the modeling as an activity to foster collaborative teams, aligning, motivating and strengthen member’s relationships (see [url=http://www.flokzu.com/blog/en/hr/process-modeling-collaborative-teams/]blog post about it here[/url]).
Then, you can decide if you keep the process at that level, or you proceed to automate it, in which case you will need a BPM tool and some modeling language (BPMN for example).
The question of modeling and processes is important because it gets to what I believe is a
[u]key challenge around selling business process technology[/u].
Can BPM technology be sold as empowering for [quote][u]business managers and analysts[/u]
Or is BPM technology only empowering for [quote][u]developers[/u]
Because if the latter, then the "
[u]once-removed[/u]" aspect of IT-oriented BPM technology
[u]undermines the BPM value chain by an order of magnitude[/u].
[u]Process modeling power is a key differentiator[/u]between BPM technology which directly empowers business, and BPM technology which can only be deployed indirectly for business, i.e. via IT.
Let's compare with the world of accounting. BPM process models are comparable to and as important as
[u]accounting charts of accounts[/u]. Most people don't look at charts of accounts very often. But you must have them and professional accountants refer to them frequently, and business people from time to time.
[u]Not having an explicit chart of accounts as part of your accounting system is unthinkable[/u]. Likewise, not having a process model available, for anything beyond the trivial, for inspection and management should be unthinkable.
BPM technology is technology, but it's not just "simple tool technology".
A shovel is a simple tool. You "just build it". We don't care if an engineering diagram exists for the stamping die for the shovel head. And in the past, lots of shovel heads were made without any CAD. A shovel-as-a-tool is not really part of "the language of work".
BPM is different.
BPM technology is beyond "simple tool".
At all levels BPM technology is already a
[u]language of wor[/u]k.
[u]language is model system[/u]for communicating about and managing our world.
Our BPM technology doesn't even need to be software-based.
BPM technology can be documentation in binders or even just present in the memories of our workforce. For example, work processes, say in 1920 or 1950, are already instantiated models of how managers and staff in those times imagined work to be organized.
The big change comes with the advent of information technology.
With IT it now becomes possible to
[u]explicitly surface our imagined processes using powerful software technology[/u].
This technology of process surfacing results in
[u]process work models in three [quote][i][quote][b]interrelated [/b][/i][/quote]levels[/u][/quote]:
(a) TECHNOLOGY MODEL -- The computer
[u]software[/u]which presents the
[u]highest level concepts with which we can build processes[/u],
(b) PROCESS MODEL --
[u]Designed and deployable process models[/u]and
(c) PROCESS INSTANCE -- Actual process
[u]instances of process models[/u].
This surfacing of processes for explicit management is revolutionary. The powerful technology of BPM (and other associated technologies) enormously increases the span of
[u]what can be governed[/u]in enterprise, and the
[u]speed with which enterprises can be evolved[/u].
So BPM technology-as-technology is
[u]necessarily very much about modeling[/u](specifically modeling for the domain of repetitive work).
[u]It just is[/u].
In this context then, the original question could be refocused as "
[b]how good are your modeling capabilities[/b]"?
A subsidiary question might be "what models do you want to incorporate into software technology and what models do you want to leave in the realm of the '
[i]tacit[/i]' or '
Specifically concerning the quality of your process modeling, "
[u][quote][b]is process modeling a first class citizen[/b][/u][/quote]" of your BPM technology? Or do you have to build process concepts (e.g. "task") by hand, using coding (e.g. push and pop stacks). And can process models be
[u][quote][b]directly shared between process technology levels[/b][/u][/quote]? We are only really getting to these capabilities now.
[i]And a lot of the disappointment concerning uptake of BPM technology in the 2000's I believe can be traced to the immaturity of the BPM software technology at that time, in particular because of the [quote][u]model round-tripping problem[/u]between (a) and (b) above. The word "interrelated" refers to the requirement that the process models ideally should be forwards and backwards compatible between levels. Consider integrated process technology as a BPM super-technology which encompasses all three levels.[/i][/quote]
Our original question started from interesting comments by Scott Francis on a piece by Keith Swenson, which in turn stemmed from visits to software technology conferences, conferences where the focus is so very much on modeling. This was fascinating to me because in the early 2000's I attended a number of academic conferences (ER Conceptual Modeling, Formal Ontology for IS) and am familiar with the orientation of academics who focus on modeling.
Certainly the distance between innovations in process modeling mathematics to any kind of in-place process product and practice is long. But the work of academics has given us the possibility now of solving the round tripping problem and has made possible the appearance BPM products where the model is executable without too much fine-tuning.
Business people and end-users want a shovel to help them do their work. But business processes are beyond just shovels.
Business processes are already about language and models. You can't escape models.
[u]We just need to do them better[/u].
Juan makes a great point: in the BPM universe, the model
[b]is [/b]the application. If we're talking outside the realm of BPM technology, sure, hey, build a nice model, why not. Of course, you have no idea who is actually following that model, and the model itself is subject to entropy from the moment of publication. So the value of a process model that does not, in and of itself, represent an application is severely limited.
Have to disagree with the comments suggesting standardized or top-down driven models. The value of BPM is in the ability to rapidly deliver a minimum viable solution, and then to (just as rapidly) iteratively improve that solution based on feedback from the business, customers, or other users. The result of this agile approach is an application that starts delivering value earlier, and ultimately delivers far more value overall, than any that could be set in stone and dropped into place fully-formed.
Scott's opinions only. Logo provided for identification purposes only.
As for your legitimate concerns about modeling and agility, may I suggest that there's nothing about doing model-driven which should be limiting in terms of granularity or governance. One can do a small process -- and benefit from results very quickly -- and still incorporate modeling (if the product being used supports executable models of course).
Considering that “a business process is an explicitly defined coordination for guiding the purposeful enactment of business activity flows” then the question can be as the following: does it always make sense to explicitly plan/model coordination? Thus, except if you want to use the only tacit knowledge coordination technique (see ref1) only, the answer is obviously yes.
And, the next question may be what to you use to express explicitly such a planning – BPMN, DMN, CMMN or something else? I would recommend the “horses for courses” approach.
For example, at present for one of my clients, we are implementing a process-centric solution which has almost all its processes defined by the business as Gantt diagrams. BTW, this process-centric solution also has a lot of checklists.
And, in this implementation we are using one of the agile methodologies (similar to one described by Keith) working model to coordinate the implementation team members.
Of course, the input into this agile way of working backlog is defined by solution architecture which follows “decomposition-cascade” coordination technique (see ref1 and ref2).
Thus it is mandatory to explicitly plan/model coordination and use various coordination techniques (not only flow-charts and decision tables).
There's another wrinkle the question asked.. .Question asked was "does it always make sense to model processes" but I think the modifier of WHEN makes a big difference:
* does it always make sense to model processes in advance?
* does it always make sense to model processes in hindsight?
I think in almost every case where a model may not make sense in advance (unpredictable etc.), it may make perfect sense to look at the collection of those "unmodeled" processes in hindsight (historical view) to discover emergent process paths or patterns...
A model is a proxy for reality, in our case a proxy for how a process behaves. One would need to model with the purpose of gaining insights into a poorly understood real system.
We as humans are very adept at understanding the individual consequences of our assumptions, but when we are to cummulatively account for the consequences of a large set of assumptions we fail - and that's why we invented computers, to help us model complex, real, systems. Think - weather systems.
With this perspective, the model serves both as an
[b]execution tool[/b](where we simulate
[i]reality[/i], therefore we account for complex assumptions) and as a
[b]comunication tool[/b](where we collectively align our understanding about how
[i]reality[/i]happens). The only difference is the
[i]image resolution[/i](so to say) - the amount of detail that we embed in our model: less means easier to understand, more means closer to reality.
[short break: this is where I always go and deride the "no-code" software trend: they communicate very well a simplified set of features but they totally fail in delivering an actual workable system by simply ignoring large chunks of the reality that surrounds software development: exceptions, errors, mistakes, integrations, compensations. For this reason, I call these cute little packages "happy path designers"]
So for me the key test when deciding whether I should model a process is a double question set: "does it help me execute it better?" or "does this clarify something to the team?". If the answer is "no" or "unclear", I chose not to model.
[i]example[/i]: I don't model the target-setting process in my company. I can describe it on the back of an envelope, literally. And that's as much as I need to communicate it. Can I execute it better by modelling it? Not really. Target-setting is above all a social engineering effort, where you trick your boss into lowering your target in order to maximize your chances of achieving it. And vice-versa (tongue-in-cheek). There's little value in modelling this rigorously.
May I suggest that the back-of-the-envelope (or even the imagination of some KPI you need) is still a model? Even if is a very small model?
If one can accept this, then such a small distinction has implications: models are necessarily a priori for all BPM projects, all the time. (And let's also state that the "act" of modeling needn't be top down or monolithic or narrowly defined. In an end-case, the acts of a business analyst drawing a line on paper or on a screen are both acts of modeling. Models can also be either explicit or tacit. Concerning tacit, we depend on the tacit models what are social constructs existing in the collective imaginations of work teams.)
If models generally conceived are necessarily part of BPM, then the question is simply "what are the costs and benefits, given a certain set of technologies", of "surfacing" a model from our imaginations? And what are the costs and benefits of using that resulting "object" as a reference point for managing our BPM processes?
Models can be surfaced in many ways, from almost free to costly, for example onto the back of the envelope, or, on the other hand, all the way into a BPM software product. Both these models are still models, regardless of where they are on the modeling continuum.
From this perspective, modeling is now both a first-class citizen of BPM technology (from implicit to explicit) and at the same time a normal cost-benefit question. And that means that modeling decisions can be and should be managed like any other management question.
To acknowledge the importance of modeling is to better understand the potential of BPM, the central technology of the work of business and enterprise. Unfortunately given what's at stake, BPM has also been oversold for a generation, with lingering disappointment. I believe that the disappointment around BPM technology stems significantly from issues around BPM modeling capabilities and BPM modeling costs.
I guess if we push this hard enough - models are necessarily a priori for everything that humans make, since they usually make things with an expectation on how the things will look and behave.
You should never forget that (in most cases) customers only bring their money to companies because they execute their processes well. Those companies deliver what they promise because their processes perform as needed.
I know many companies with happy customers, happy employees and some positive financial results, where they never have modeled any process.
I think most of them even don't know what it is and might react like 'Yeah sure, go home with your MBA toys, we have customers to serve'
So, a shared belief, trust ; far more important than any process thing.
So, the answer to the question: a big no.
But OK, sometimes customers (or other stakeholders) are not happy and companies want to improve how they execute and manage their processes.
Some choose to start process improvement initiatives and most of the time process modeling is part of that. But turning as-is models into to-be models means nothing without being able to implement it.
So some above comments make sense, because some choose to support their processes with some BPMS tooling. It can be traditional workflow, maybe more casemanagement style, but most of the time it needs a process model to operate.
And depending on the 'agiltiy', a model can be live in 'a click' .
You still have to be aware that a system that supports the execution of a process is not a process. A process also needs people, a way of managing.
It's only one of the enablers for process performance and can be a thing to take into consideration when you are not happy with process performance.
But don't forget that at this moment processes already are executed and managed; it's what every company does. Sometimes it needs to be done a little better and then a model might be needed.
But my approach isn't 'I model all processes' but 'I don't model processes untill....'
Sometimes it isn’t worth the hassle. When I was working in England, we once* tried to model the tea-making process but had to abandon the initiative because two groups couldn’t agree whether to put the [url=http://www.theguardian.com/notesandqueries/query/0,,-1400,00.html]tea in first or milk in first[/url].
As George Orwell wrote in [url=http://www.booksatoz.com/witsend/tea/orwell.htm]A Nice Cup of Tea[/url]:
This is one of the most controversial points of all; indeed in every family in Britain there are probably two schools of thought on the subject. The milk-first school can bring forward some fairly strong arguments, but I maintain that my own argument is unanswerable.
I agree with Emiel: if everyone’s happy with their tea, what’s the point?
* made-up story
I'm reminded of my mother's (OBM) dictum that you don't have to floss all your teeth -- just the ones you want to keep.
Same thing with process modeling. You don't have to push the modeling envelope. Just as long as you don't care about staying in business.
BPM technology isn't just about maintaining existing processes, on the basis of past modeling achievements. I think you can make an argument that BPM technology is primarily about empowering managers to effect business changes more often, more easily, more affordably -- the better to stay in business.
Speaking of which, pace @Orwell and @Peter, "if everyone's happy with their cuppa, exactly how long
[u]are[/u]you going to stay in business?" : )
But there's a big challenge, which is "how to sell modeling".
Selling the idea or tools of modeling is really hard.
Because modeling is a long, long way from value creation. (I first learned about this when selling RAD software . . . )
(Please also note a caveat that modeling can defined more generally than just "building a process model in BPM software", which is narrowly IT-centric. Process modeling is central to constructing systems for the work of business, but process modeling is just one management tool beside many tools, including financial modeling.)
For the complacent, one should note that executives earn their pay grades by being more than museum curators.
To be an executive is to have the responsibility for imagining the future and then building a bridge to that place.
From "as-is" to "to-be" is called many things, but semantically "modeling" completely encompasses this activity.
I believe that the solution to this problem lies in understanding both the technical and sales/governance dimensions of the problem.
And Geoffrey "Crossing The Chasm" Moore's new work on the "Four Zones" provides a road map for positive action (lots of material available on LinkedIn).
In the meantime, those who don't care to model the future can anticipate the fate of so many organizations, big and small, which have been disrupted out of existence over the past generation. Creative destruction indeed . . .
So for your own consultancy, a recipe might be "stir in one part Moore and one part process modeling" and you can bake a nice cake of insurance against the future for business clients.
- Page :
However, you are not allowed to reply to this post.