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, you have a context. 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 change 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 http://modeling-languages.com/modeling-community-why-model/ 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 https://www.youtube.com/watch?t=23&v=BM8wuqPmVBg 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 blog post about it here).
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 key challenge around selling business process technology.
Because if the latter, then the "once-removed" aspect of IT-oriented BPM technology undermines the BPM value chain by an order of magnitude.
Process modeling power is a key differentiator 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 accounting charts of accounts. 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. Not having an explicit chart of accounts as part of your accounting system is unthinkable. 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 language of work.
A language is model system 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 explicitly surface our imagined processes using powerful software technology.
This technology of process surfacing results in process work models in three interrelated levels:
(a) TECHNOLOGY MODEL -- The computer software which presents the highest level concepts with which we can build processes,
(b) PROCESS MODEL -- Designed and deployable process models and
(c) PROCESS INSTANCE -- Actual process instances of process models.
This surfacing of processes for explicit management is revolutionary. The powerful technology of BPM (and other associated technologies) enormously increases the span of what can be governed in enterprise, and the speed with which enterprises can be evolved.
So BPM technology-as-technology is necessarily very much about modeling (specifically modeling for the domain of repetitive work). It just is. By definition.
In this context then, the original question could be refocused as "how good are your modeling capabilities"?
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 'tacit' or 'undocumented'"?
Specifically concerning the quality of your process modeling, "is process modeling a first class citizen" 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 directly shared between process technology levels? We are only really getting to these capabilities now.
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 model round-tripping problem 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.
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. We just need to do them better.
Juan makes a great point: in the BPM universe, the model is 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.
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 execution tool (where we simulate reality, therefore we account for complex assumptions) and as a comunication tool (where we collectively align our understanding about how reality happens). The only difference is the image resolution (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.
One example: 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.
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 tea in first or milk in first.
As George Orwell wrote in A Nice Cup of Tea:
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 are you going to stay in business?" : )