Enterprise is the Data: Are Processes Overrated?
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
The first thing I noticed when started to transition some of my clients from UML to OWL Ontology Modelling was that there was no notation for process modelling. While since then I developed an approach to model process-related information, that revelation made me think about the importance of processes. I dare to say, in today’s enterprise, data are primary, processes are secondary.
I believe that our understanding of enterprise is moving into the fourth stage:
- Stage 1: “Enterprise is the Structure”. We try to make an enterprise manageable by defining what silos it has, and what their responsibilities are.
- Stage 2: “Enterprise is the Processes”. We are trying to make the enterprise defined. We realise that collaboration between the silos, that makes the enterprise work, is not captured. Furthermore, we realise that silos working to their separate objectives do not necessarily deliver optimal results. Therefor we believe that an enterprise is defined by its processes. We haven’t forgotten the structure which is referenced in the processes.
- Stage 3: “Enterprise is the Services”. We are trying to make the enterprise agile. Processes, recorded on paper or in specialised software usually were hard to modify or for that matter understand. We decided to try to break enterprise into services that are accessed via specified interfaces. That will make processes small and directly executable.
- Stage 4: “Enterprise is the Data”. We want to optimise the enterprise. The enterprise is seen as collection of data that are manipulated by the enterprise, with secondary data used to judge the enterprise’s performance. The Services are still there, however likely be defined as REST-type operations against that data. The Processes of course exist, however seen more as implementation details.
Consider an example. Say you run a courier business – deliver parcels and packages for clients etc. You can view that business as a bunch of processes – like the process of order fulfilment, the process of marketing etc. Then you can start looking for inefficiencies in those processes, you will need to decide what data to use.
The more direct approach would be to start with deciding what kind of data show the health and functioning of the business, like profit, customer number, customer base growth, customer acquisition cost, customer retention, delivery times. They say if you cannot measure, you cannot manage – so we start with our ability to measure.
Then you can look at primary operational data: delivery orders, customer data, workforce data etc. Your enterprise is effectively in the business of converting data into data. Orders data are converted into instructions to delivery drivers. As the drivers proceed along their routes, they also generate data. You can choose to make something of those data in real time, or process them overnight.
After the data are defined, you can proceed to decide on the business rules and the processes. However with the data defined as the primary artefacts, you have process optimisation built-in. Say you may have different processes to convert orders into delivery schedules and shipment schedules. So instead of “that is how our enterprise works” we say “let’s find a process that will minimise costs and risks”.
So where do you start?
The first step, as with any undertaking, is to identify demand and the stakeholders. If you just went through massive implementation of an COTS ERP and BPM solution and everyone is in anticipation of the brave new world that follows, it is hardly the right time. However if the executives are demanding more data and buy into the idea of a data-driven enterprise, that is the good time to start.
The second step is to start producing executive-level Information Model – I call it “Executive Information Model” or EIM. Traditional Data or Class modelling notations that are focused on parcels of values are not suitable – your executive audience has no time to argue about naming and values, and you will not be able to educated them about Fourth Normal Form, encapsulation etc.
The only way is to use Web Ontology Modelling (OWL) 2.0 that focuses on properties and classification rather than data parcels. The focus should be on the data that the enterprise leaders will use to determine the health of the enterprise the way “The Lean Startup” made the startups data-obsessed.
The next steps is to model the operational data in computation-independent way. That information should either be consolidated with Process Models – however for some organisations “Process as Data” modelling may be sufficient while been a much more manageable activity.
(as always, comments on how to improve the post are welcome. And if you want me to write more on the topic, like a series of tutorials or a book, please let me know)
Senior Technical Product Manager at Amazon
10 年Data consistency is crucial but any compliant and efficient process will often suffice. Designing and implementing rigid processes is Taylorist thinking only suited to fixed algorithmic activities.
Hi Alex, interesting post. Your description of working from KPIs to business rules mirrors the Federal Enterprise Architecture Framework (FEAF). You may want to look at adapting it to your vision. Regards, Rick
Product & Digital Transformation | Author & Creator of THE STRATEGYJOURNEY | Entrepreneur | Investor
10 年I think process and data need to go together. One is useless without the other.
Solutions Architect
10 年If you cannot express state and process then I suspect your ontological formalism lacks expressive power.