Understanding, insight and visibility. Contrary to some's opinions the client themselves, even the people who directly participate in a process, don't always know the process as well as they think they do, much less a given process from end-to-end. As long as not too many cycles are expended on this ad nauseum, ad infinitum (as some do), it's one way to know what's going on, why things work they way they do and what opportunities may exist for doing them better, at the micro and macro level both. Remember, optimizing all the sub-flows of a process don't always result in a fully improved process. Then again, courtesy of the insight modeling can provide when done right, sometimes some part(s) or piece(s) of a process don't need to be, shouldn't be messed with.
It's about what's the correct process in this particular instance and continually examining that, refining it as business needs and markets change.
I second Patrick's response and would go on to say that it's amazing how well a simple process model can help with communication. You may not be talking specifically about the process, but it acts as a point of reference around which other conversations can take place.
In a recent project I was reviewing some old dust covered process models to see whether they were worth reusing or chucking away and starting again. I found one (actually there were a few but this one stuck out in my mind) that appeared to have been updated on a weekly basis. I called the guy that had been marked as owner on it. I wanted to chat and find out whether he was a closet process analyst. His job title suggested something very different.
He told me this "Our area is heavily regulated. We're handed new or changed regulations two or three times a week. In every case we need to assess the impact of these on our operation. We get the team together and we put this process up on a screen and we talk about the policy. It often doesn't impact the process but it helps us to ensure we all have the same frame of reference. And at the end of every discussion there's nearly always an improvement suggestion that we update in the process and implement."
It doesn't always happen but there are teams out there that find process models highly valuable and they're not even automating anything!
It might be helpful to inventory the modeling that is possible under a case, decision or a process.
e.g. we set up a case, wtih a set of objectives - what is the likely evolution of that case and what are the outcomes for major possible forks in the road?. - we do this the reward goes up but so does the risk; we do that, it takes longer/costs more but with reduced risk, what is our best guess re possible external events that could disrupt the case? Seems like a decision tree would be the way to go here.
in respect of a process, is it common practice across participants to map, compile, roll out and then have key stakeholders piano play the process? OR do we build a text file that bypasses keyboard entry and tries to stress test the process so that all possible pathways are engaged? Fine tuning here would involve rolling out a process with images of eventual data collection forms to avoid the time it takes to design e-forms.
When modeling, is it essential to bring together the stakeholders or sufficient to have tthese log into, for example, a GoToMeeting session where the facilitator navigates to show everyone how the processing is moving forward, how the case is evolving?
One big question is how do you model a process when handoff times between steps can exceed the time to perform steps? (i.e. users may be working on 10 cases/processes at a time and we are asking them to simultaneously pretend to be working on a new process)
Several ideas come to mind:
- Getting everyone on the same page as to the as--is process and potential to-be scenario. All participants can plainly see the advantages of the target state.
- Capturing process details, especially KPIs, that can be simulated and/or used to identify bottlenecks, eliminate waste, and streamline process
- Documenting process for compliance purposes.
- Moving from process modelling to process automation by adding data models, forms, expressions, integration, and user interfaces to create a full-blown application.
Process modelling is normally the start to process automation. In BPM Suites where there is no model there is no application. The advantage to doing process modelling into a BPM Suite is that you can turn it into an application with built-in mobility and analytics.
As the model becomes the application build arena so business users at last can see how their ideas come to life v quickly and fear of change is removed indeed becomes the norm. With this comes increased efficiency and effectively a future proof investment in new BPM supporting systems
Frankly just a model as a theoretical exercise does little to excite business but when the Model IS the App without coders / programmers needed then a new era of empowerment opens up. Also important are all the benefits of transparency for compliance and audit knowing exactly what is deployed.
From ref1 “Help SME becoming #digital” -Properly done, a business process model serves many purposes
On top of what Patrick and Craig already said, I'd touch upon another important business case for modelling, which is to ultimately enable execution.
A well-designed and well-explained model that is actually executable in a process engine goes a long way into having the customer not only discover their own requirements (huge problem in software projects), but clarify how the system will actually help them in the to-be scenario. This is huge and removes a lot of friction during the development, testing and acceptance phases of the implementation effort.
I would argue that even if the ultimate goal of the effort is not a system implementation, making your model run in an actual process engine (and hit all the possible walls in there) turns you into a much better process architect.
On a funny note: I had one of our consulting partners turn to us a process model that they designed - of course not only that the process could not be run in our process engine, but it made absolutely no sense, conceptually, semantically, not even visually. We asked them why did they design such a thing, they said "oh but it was okay, we just needed it for customer's sign-off as requirement" :-)
The question is not whether to model or not, but "how good are your models?" Because all software is modeling. The business case for modeling can be made, even in the face of skepticism. And those who get modeling right have bought themselves a ticket to the frontier of innovation and success.
So many hard-won insights concerning the business value of modeling! And clearly an often essential tool for achieving clarity. Given the putative number of failed monster projects that we all hear about, anything that can help us achieve clarity is likely a good thing.
That's business value and a business case right there!
Dr. Samarin has provided some formality concerning exactly what modeling is, which is important because too often we get all tied up in rhetoric and anecdote. Examining his list, one is left with the thought that maybe modeling is not just another artefact of technology but perhaps centrally important.
Let's take this further. Let's go maximalist and see if modeling maximalism is helpful in terms of business value.
Before anyone gets scared off however, note that we are "all modeling maximalists now"! On the wetware side, human language is saturated with metaphor, which are all models. And where software is concerned, all software concerns models. A sign signifies an object, and then it's "turtles all the way down" as they say.
So, now the question is not "is there business value to modeling", the question is "how good are your models?"
Because models define the things you can do with your software. For example, the accounting models implicit in your ERP system define the options you have for managing your cash flow.
And the process models that you construct for order-to-cash define how your business can manage order-to-cash inside an automated process system.
In fairness, the original question was posed as "what is the business case for doing a full-on BPMN process model?"
But expanding the modeling question allows us to expose some of the most exciting business and technical opportunities at the edge of the world of software technology.
Here are a few of the touch points between technology, modeling, business value, language and anthropology:
1) LEVEL CONFUSION -- Confusion between conceptual, logical and physical models in the world of data is implicated many software construction challenges.
2) LEADING EDGE -- One of the hottest areas in software today is "narrative", closely related to "experience" and "journey" -- and "process". And all of these concepts are in essence models or abstractions of reality.
3) SCIENCE TO THE RESCUE -- Modeling (e.g. conceptual modeling) is mostly today a craft activity and unscientific. And like most craft work the results are sometimes wonderful, but also limited. Ontology is the work of turning modeling into science.
4) ECONOMICS OF MODELING -- In terms of business value, consider the question of "well-understood commodity processes". A knowledgeable team can probably build such processes directly, without a lot of modeling overhead, "in their sleep". And that gets the team to the proverbial "80% of the way to completion". That easy 80% may have standard exceptions, so standard that we call the whole thing STP ("straight thru processing"). But the interesting thing is that the last 20% is where "winners are separated from losers" and we have left the island of commodities for the sea of wierd exceptions and complicated non-standard customer needs. And our ship will soon sink if we are building without models. Complexity escalates rapidly, and our only salvation is modeling.
5) ROUNDTRIPPING -- Mr. Nafornita has mentioned "execution", which gets to the mismatch between conceptual and executable models. Called "the roundtrip problem", this problem is I believe responsible for much of the disappointment since 2000 concerning workflow and BPM technology products.
6) AGAINST COMPLEXITY -- And most importantly, models are how we manage our interface with rich, complex reality. It is impossible for any control system (whether computer or human brain) to manage without models.
7) REIFICATION -- And lastly, the very idea of models generates its own problems. The word reification captures the situation where humans treat models "as reality"; once could even say that this problem is as old as humanity given our propensity to idol worship. But the problem is real and regardless of the value of a model, as has been pointed out many times on BPM.com, a model always has the possibility of hiding important aspects of reality which are not represented in the model.
8) DECISIONING & SIMULATION -- Models drive decisions, the life blood of business. And decisioning-in-the-large can be thought of as simulation, or "imagining the future". Simulation only works insofar as there is a model in place. Simulation is not done nearly as much as textbooks would suggest would be useful, but it's reasonable to expect more business and systems simulations in the future, for multiple reasons.
There is often resistence to formal modeling. Making a business case for any infrasatructure is always tough. And there are often conflicts of interest concerning modeling and various project stakeholders on both the IT side and the business side. Even modeling itself may be difficult -- which is why most software models in use today are the shared models implicit in ERP systems.
But if we want to win in the marketplace, we have to be able to build out that "last 20%".
That means capturing our pioneering business vision not with toothpicks, but with models. And then using those models to build and operate our value chain systems.
The business case for modeling can be made. and those who get it right have bought themselves a ticket to the frontier of innovation and success.
We believe modeling is important. No. More than that. It is critically important when companies are trying to transform themselves, redesign the execution applications, and then get all staff algined and on the same page. It a time of disruption it has never been more important.
But the modeling I am talking about is top down map/model with a simplified notation (ie UPN - see link). The sort that a business consultant would produce. Historically it is was white board, Visio or Powerpoint - but now there are far better and affordable cloud solutions available. The process diagrams, at the lower levels of the heirarchy, then feed BPMN or CMMN diagrams which are more execution focused.
UPN - top down, strategic, operational, management, training, compliance
CMMN, BPMN - requirements, technical, execution.
For BPM world peace - UPN and CMMN/BPMN need to coexist not compete.