Business modelling

Years ago “operational excellence” was the buzz-word. With it came harmonized business processes—all customers have to go through the same process. Now, we’ve moved to “customer intimacy”: adjust the business process dynamically to the specific customer and his request.

To fully embrace “customer intimacy” the whole company needs to embrace this paradigm, at all levels, in all aspects. We need to design the business from the “customer intimacy” perspective. That is: from the customer perspective.

Service design

Most organizations view the service they provide from their own perspective. An (instance of a) service starts the moment a customer make a request and ends the moment the customer leaves with a fulfilled request. However, one should view a service from a broader perspective. The service starts when a (potential) customer considers (consciously or unconsciously) the service. It ends when the customer doesn’t remember the supplied service. By extending the service in this way, we do not only take the hard pre- and post-conditions into account (a correct filled in form and additional documents have been supplied), but “softer” pre- and post-conditions—like customer satisfaction, lead time and margins of errors—as well. The result of this thinking is that providing a service isn’t enough. “Customer intimacy” is only achieved when the customer wants to use a service and is satisfied with the whole service and not only the result.

Provided services are supported by internal services, and sometime by third party supplier. The result of this orchestration of services is the experience of the customer. Increasing the flexibility, extensibility en adaptability of this orchestration enables the possibility to quickly and easily implement new services or improve existing services. To accomplish this, services are viewed as building blocks of processes, that:

• provide minimal functionality: services are split into a minimal set of “atomic” processes. Each process fulfills an independent aspect of the services. This enables the possibility to improve individual services, or replace a service with minimal impact on the organization or service; and
• have minimal dependencies: individual services have a minimal dependency to and on other services. As a result failure (or just not executing) a single service can’t halt or delay the complete process; and
• have shared knowledge: knowledge (data, information and context) is a shared service resource. Data governance and security should be designed to provide both safety and availability for a broad audience. By preventing “private data” it is possible to break through organization barriers and to optimize on top of business functions; and
• have predictable contracts: every service defines the required information and authorizations, they provide product and performance guarantees. This reduces the governance overhead often required in organizations.

Process design

Processes are an important link in business operations. They operationalize a service, serve to give shape to the goals and strategy of an organization and are a management tool:

1. from the entrepreneur: on business goals and strategy; and
2. focused on specific (internal or external) stakeholders, such as the government requiring compliance with laws and regulations; and
3. focused on operations, to ensure that all employees do the right things.

The—commonly used—flow charts focus on the third level of control. However, flexibility is important on all three levels. A process is executed in the context of a service and the service is started by an initiator and influenced by one or more stakeholders. These interests must be explicitly included in the process design. By considering a process as a transaction between 2 actors, it is possible to operate all control levels.   Each transaction consists of five steps, which are executed in a fixed order (taken from DEMO, and Pronto):

1. the initiator makes a request, which clarifies what the initiator asks;
2. the executor examines the request and decides whether (or not) to comply with the request; on that basis he makes a promise to the initiator;
3. upon successful completion of steps 1 and 2, the executing party will take the necessary action to comply with the request (as promised / agreed); this step is called execution;
4. the result is delivered to the initiator and
5. the initiator decides to accept the result (or not).

Translated to a Dynamic Case Management situation, the initiator must be less tightly linked to the performer. After all, the initiator has an information need and who fulfills this need is irrelevant. This creates two flows. The initiator flow:

1. the initiator wants to use certain information (from a product) for the execution of the service it provides;
2. to this end he shall communicate the information need.

And the executor stream:

1. the executor makes the promise to meet an information need (using existing information), the so-called precondition;
2. then executes the necessary steps, the so-called tasks;
3. and delivers the result as an information product, the so-called post condition.

Product design

A performer delivers a product to fill the gap in time or space between two parts of what can be considered one service. For example, an insurance product is not the end product of an insurance policy. From the customer’s point of view, the repair or replacement of the insured object is the end point of the service. The “insurance product” here is a promise of future service.

Actions are performed to perform a service and deliver value. A service can be described with “what”, “how”, “where”, “who”, “when” and “why”. A product is an artifact that is passed between services and does not deliver value. It can take different forms: physical (a document), virtual (a record in a database), a relationship (e.g. between an organization and an employee), an aspiration (e.g. between a person and a brand) or a combination of this (e.g. a policy with both the policy document and one or more records in a database).