How can you setup services, which are both flexible and robust? And how can you grow your fortune by $24bn in midst of the crisis, as Amazon did? And: Why you should utilize «Case Management» when modeling robust processes using BPMN.

Early in 1980 Michael Porter redefined enterprises as places to orchestrate value chains.

This abstraction of specific enterprises with their heritage and local properties to the understanding of enterprises as a mere sum of services is still remarkably useful – and proofs the statement that nothing is so practical as a good theory: With this approach you can both support management activities and coordinate humans as well as IT-services (Cf. the service based ITIL-framework). You also can outsource and offshore certain services as you like it or introduce Just-in-time delivery.

Services are also the best option to grow for any startup, as Michael E. Gerber describes so nicely in his book about The E-Myth revisited in 2004.

If you orchestrate your services right you might even be able to blossom inmidst of the chaos: Amazon grew by $24bn in midst of the Covid-19 crisis!

How?

How can this be achieved?

I will highlight three four aspects and celebrate the collaboration between men and machine and case management as concept to elevate this:

1. complexity
2. collaboration I
3. collaboration II
4. licenses and ownership

1. Complexity

Automated processes are a truly fine thing, because they do exactly what you want them to do, they obey you!

The disadvantage is that this is true even if you do not want them to do s.th. in a certain situation.

This is the story of the Disney animation «Fantasia», which was released as early as 1940, highly inspired by «Der Zauberlehrling» by Goethe, which was published in 1797!

The problem arises if the complexity and action room of the process it lower than the complexity of the problem it is dedicated to solve. According to Ashby’s law of Variety undercomplexity will fail for sure.

AI tends to be undercomplex

As all artificial intelligence applications are based on simplified models of reality reality beat AI very often. Therefore all AI applications have inherent restrictions which make them strong only in their dedicated narrow context of use and – pretty risky outside of that.

Anyhow, if you use a formal tool like UML or BPMN to describe processes in a perfected way, you are in principle on the right track, because these formal languages have their own internal syntactic grammar, which can be utilized by computers. The downside is that these nice and well thought through processes are likely to fail in practice because you have omitted the irregular options reality will provide for sure!

---

The joyful case of Case Management

Humans are, in contradictions to computers using AI, able to survive and own therefore native intelligence. The idea is therefore to create a kind of switches or gateways in the service description, where tasks can be handed over to humans problem solving capability.

This was added to BPMN later, by introducing CMMN to BPMN: So called Case Management enables you to let humans process tasks inbetween, and to hand over the results to the machine finally.

By this BPMN enable you to model processes which include both automated and human processing and makes it the tool of choice for robust and reality proven process development beyond lipstick-decorated processes which are likely to fail in praxis.

---

2. Collaboration I

What we have to consider, anyhow, is how to approach and contact humans using this Casemanagement. If one has to wait all day long to eventually do something this is obvoiusly not effective and error-prone, because the human being gets bored and might not be alert, when the situation arises to contribute.

We need, to speak lean, a kind of useful flow and human oriented design to make the whole machine-human interaction vivid and valuable.

3. Collaboration II

A couple of years ago Amazon bought the food chain Whole Food and integrated their logistics, one could say to «digest it» (literally), cum grano salis over night into it’s own logistic framework. This was possible due to a strit API-first and to interfaces which allows Amazon to connect different value streams internally with ease.

We can lear that a process has to have open interfaces which provide the capability to use them as flexible as business needs it.

4. Ownership and licenses – business elasticity

Finally, we have to have an eye on the ownership and the license fee for processmanagement.

Many tools, including fashionable low-code solutions, have fees per form, interface, capita or user interaction.

Such a solution might scale nicely and bring you the business elasticity you wish in order to grow with business demand. But if your fees exceed the benefits, you might obviously create a loss, right then when customer demand for your service!

The somehow overpromising Exo.works framework, created by Salim Ismail, is perfectly right with this aspect: It states that you should have your own value creating IT-core of your business platform under your own hood to avoid loosing the fruits of your investement and business activities, exactly then when demand rises.

So make sure the technical elasticity of cloud services is also double checked with regard to relevant business elasticity…

It might be worth noting here, that Porter already differentiated between core and auxiliary processes. This might also be the appropriate disctinction to decide, what should be powered by your computing intelligence and what can run elsewhere, appropriate services parameter assumed. Though later business management gurus Prahalad/Hamel focused on core competencies and rejected Porter’s view of market forces he had developed, too.

But that is another story for another opportunity ….