The True Face of Level 4 Process Mapping
Alex Jouravlev
Data and Enterprise Architecture veteran and practitioner with up to date strategic knowlege and hands-on skills in AI. Proponent and enabled of Data-Driven Enterprise. Everything Graph and Metadata
We need to have a serious conversation about Process Centricity vs Data Centricity in the face of Digital Transformation. However I would like to start with something that does not require any serious deliberation, which is rather obvious - Level 4 Process Mapping.
As an independent Consultants, on a number of occasions I was notified by the client that their Process Mapping consultancy is recommending to continue the mapping by going to Level 4. It is usually presented by more detailed, and therefore better mapping.
Is it?
Let’s look at the definition. The one I found is “documentation of systems, instructions and procedures required to complete steps in the level three processes and shows inputs, outputs, associated steps and decision points”. So it documents doing step-by-step through software systems to achieve particular business outcome.
Compare it with the definition of a Use Case: “a sequence of steps the user takes to achieve result of value”. Within a couple of years since Use Cases were introduced, they were criticised by Larry Constantine for been too detailed, who introduced Essential Use Cases - “result of value” without “sequence of steps”.
However that is not the end of Level 4 Business Processes. They also go should show the steps that system does, like storing data in the databases - kind of implementation diagrams, like UML Sequence Diagrams, that the Developers do.
So a Level 4 Process Diagram is a series of Use Case Scenarios stringed together and extended with implementation details. Such detailed and inflexible description can be useful when a lot of workers have to do repeated steps, say when applying Six Sigma to car manufacturing. However when applied to a software-intensive programme, they would mean abandoning any attempt of business agility. Or just assume that the processes would not be maintained, and become irrelevant after the first modifications.
In particular if the technique is applied to to-be Processes, they result in Process Mappers, usually not the best UI Developers or UX Designers, providing very prescriptive definitions for UI and implementation. Which will likely result in a 1990s experience of a 2018 system.