Another point that came up at the BPM & Case Management Summit: Do you think data has not been prioritized enough in BPM?
It's like security, should be accounted for from the ground up in any implementation, but most either unnecessarily concentrate on it solely or too much (as opposed to incorporating into the overall picture) or don't account for it at all until it's too late. But data, particularly in regards to integration, will make or break you if not accounted for.
There's a reason why data and process are the first two columns in Zachman.
Just my tuppence.
In the old days of "boxes and arrows" that was probably the case, I think. But as more and more processes are turning data into data (of more value, hopefully) it has become important of course.
When talking with customers about processes I prefer starting from the end, which can still be a physical product, but also a collection of data. Of course always to make clear if that collection of data or product really solves a customers problem and if a process is really needed for it.
I think it is getting more and more prioritized (or should), but don't forget that, when you talk about BPM, there is data on more levels:
- Execution of a Case level
- Monitoring of cases level
- Process (improvement) level
- Data that flows between processes
Wrote some words about that here
Actually... Data is incredibly important.
However and IMO the issue is more: Data in context. I see many times efforts where there is so much focus on data (only), that people completely forget in which wood they're cutting the trees... In other words: Scoping, the big (system thinking, holistic etc.) picture is missing. So we end up with not doing things inefficient, but especially with ineffectiveness (not doing the right things). Therefore, I believe it needs priority but with the effectiveness in mind...
You can buy a car and spend all of your time reading the brochure or you can read the brochure and then get in the car and drive.
Clearly a high level concept-only process map can be posted to a wall/screen for people to look at/comment but once you have a map with multiple parallel sub-pathways and branching decision boxes, some of which are likely to have auto-execute rule sets, you quickly get to where modeling in a run-time environment, with data, is necessary to test the logic and the branching.
If some of your process steps are algorithms that take data and enrich that data, unless you piano-play your process you will never easily know if you are collecting, upstream, the data the algorithm needs - you won't be able to validate the algorithm.
Once you are in production mode, any step that requires more than a "done" declaration will need a form at the step to record observations/measurements and oftentimes you will need/want to attach documents to steps.
Are there any BPMs out there that only maintain a "log" ? (i.e. the system appends a record of the step name, date/timestamp, a user "signature", but no data beyond this).
Nobody's going to suggest, I imagine, that data is unimportant (nor, for that matter, that data are unimiportant).
That said, BPM isn't about trading C for SQL. If you have to understand third normal form and the difference between "GROUP BY" and "ORDER BY" in order to implement your application, you may not be taking advantage of the power that BPM technology offers.
How many product demos have I seen that begin with, start by using our simple data model generator... Gee, thanks for the wafer-thin veneer on SQL Server Management Studio, but is that really why I invested in a low-code development platform? I'd venture not.
Even if we all agree that "data is important", still data is never "prioritized enough" because data is infrastructure and the business case for infrastructure is always a challenge.
Data itself is the alphabet of business semantics which are the content of our business systems. Without this alphabet, we cannot "say" the things we want to say. And that includes the statements we want to "say in BPM". If we haven't defined that data elements that can be used to define a field service return visit then we won't build a return visit very easily in our BPM field service application. (A complete inventory or ontology of irreduceable business semantics starts with data, but also includes rules and process.)
But the big challenge around data is not technology, or even governance, but it's an economic challenge.
Cheap sensors and cheap data combined with expensive business analysis inevitably lead to information overload (or alarm fatigue). We end up drowning our users and overwhelming their decision capacity because we didn't do the hard work defining the states, interactions and life-cycles of our assets, processes and rules. (And "hard work" translates into "budgeted for business analysis".)
So to build an application, you need to start with data and data models and then the whole business semantics kit. Will you build that kit yourself? Or buy it as part of a package? Maybe with some after-the-fact customization? Can you afford to maintain and evolve it to support your evolving business model?
It's something to consider that business semantics, starting with data, should be an explicit concern of executives responsible for business automation outcomes.
And this is done for a very good reason. The primary job of BPM is coordination – grab data from some places, make new ones (with some help from some people) and deposit them in the same & other places. And save the audit trail records, preferable in blockchain, before removing them from BPM. Like a perfect secretary or coordinator – light, scalable, agile, completely data-driven (thus transparent), and, of course, with some predictive analytics, if accepted.
Yes but the question should put emphasis on quality of data......? Frankly without data outcomes and presentation in any shape or form there is no BPM. The emphasis should be on creation of one version of the truth from source and no duplication? In order to give that vital assurance to both business colleagues and external interested parties such as compliance audit etc. Such transparency on how data is created and used is vital. So yes this data message needs to be emphasized which shoud be one of the priorities in BPM thinking.
BPMN has clearly excluded data from its scope. This may be technically correct, but it's still wrong for the business.
For business people, flows are easier to understand than states. But it is actually the states that need most architecting. The data model is extremely tricky to get right (and to scale right). And that is because, from an architectural standpoint, a database is one of the most serious (and dangerous) technological coupling points (since it's about consistency and integrity). Get it wrong and you're cooked for a long time.
So a proper working business solution will always have to include both data and processes. In a language, you cannot speak only in verbs and adverbs (actions and rules in flows), you also need nouns and adjectives (data objects and their attributes). And to really drive your point home you need style as well (UI).
Maybe that is one of the reasons of relatively low-traction of BPM technologies - it is never a pure workflow play. Never. Having data as second citizen of process tech was, strategy-wise, wrong for the process standards.
And it doesn't show many signs of improvement, as an industry. Look at all the cool no-code kids how far away they are from even mentioning data in their cute demos. Also, CMMN and DMN (much more persistent-data-centric than BPMN) are still making no inroads into proper business data modelling.
@Patrick - I kinda disagree that the data objects in BPMN 2.0 are first-class citizens. The 30-page section in the standard is a bit quaint, covering a bit of i/o specs in how they relate strictly to other process artifacts. A business app needs business data, from business objects. That is not addressed in the standard. So I do not use the data objects in BPMN 2.0, ever. They are way too sparse for the purpose of real-life execution.
@Alex, I agree that vendors are master at eluding the data moose on their table. You are saying exactly that vendors treat the data problem as second citizen. I am saying the standards should address this at least in underlying how important it is. (as for the anti-agilist, I remember your pain from our discussion :-) )
I would expect that the standards people work together in bringing a common taxonomy for business data objects too. OMG could cooperate more with OASIS (UBL, anyone?) or with vertical EDI dudes, or other standards bodies. After all, having a commonly agreed upon framework (and I am not talking only XML formats) should benefit both process standards and data standards.