Current methods for redesigning organizations need to meet the required rate of change. This applies in particular to digital transformation with IT: the average IT project takes around two years to implement. Therefore, there is an urgent need for methods that make it possible to redesign and restructure organizations, preferably in an integral manner, within a few months. This demands a fundamentally different (scientifically grounded) method that can precisely specify the necessary interaction between the organization, communication, and information (systems).
Popular management literature concerning the redesign of business processes appears to have created more myths than methods. Particularly the lack of integration between the design of business processes and the design of information systems gave rise to a situation where the solution to this issue had to be sought in a different way of thinking and working.
The quest for a method that could rapidly design the strategy, business processes, organizational structure, and information systems of an organization began in a research school in the 1990s that views the business communication of organizations in a completely different manner. This school is now called ‘Enterprise Engineering’, which consists of an international group of researchers. On this basis, research is performed at various universities throughout the world. A methodology for Enterprise Engineering is DEMO (Design and Engineering of Organization), see https://demo.nl/demo.
One example demonstrates the difference in approach of DEMO. Management consultants and IT experts nurture the idea that a cash dispenser has completely assumed the function of the bank clerk. If we examine matters from a DEMO perspective, we realize that this is only partly true. The cash dispenser is indeed capable of supporting communication.
The successful communication between the Customer and the Bank is supported by a cash dispenser. However, imagine that the cash dispenser only provides one 50-euro note instead of two, or that the cash dispenser does not return the bank pass. The customer will not accept this. The question is then: will the customer enter into a discussion with the cash dispenser or will he or she go to the bank clerk? The latter is the case. The customer will address the clerk about the unsuccessful cash withdrawal and they will enter a discussion. The discussion may end in a dispute that a third party may eventually be requested to solve.
This first example shows that physical and information processes, including the filling in of a cash withdrawal form or the counting out of banknotes, can be assumed by dispensers and computers. But, because communication does not always occur successfully, a role is always reserved for humans. In DEMO, this role is referred to as an ‘actor’. The pattern of request-state-production-declare-accept is referred to as the success layer of a transaction. The transaction pattern also contains a discussion and a discourse layer. All kinds of discussions take place in the discussion layer, such as the refusal of a request by the supplier or the non-acceptance of the result by the customer. In the discourse layer, the background conditions of the transaction, such as the general terms of delivery, are probed and changed, if necessary. In this situation, the parties can call in a mediator, expert or arbitrator to solve the dispute. He or she will ensure that the claims are negotiable, will examine them, or give a judgement on them.
Summarizing, the transaction pattern presents 1 production act and 20 types of ‘messages’ in one go. In doing so, the transaction concept reduces the complexity of business communication in a simple manner.
A second example is necessary to illustrate another view held by DEMO concerning information and its support by Information Technology (IT). The large volumes of information that organizations produce and require to function properly have led to an abundance of manual and automated information systems. Combine these with the possibilities of the internet, and the great number of systems and messages (in paper, electronic and spoken forms) and it will be evident that it is increasingly difficult to obtain and maintain an overview of all sources of information. In order to keep and grasp these developments, it is important to be able to distinguish the main issues (the sources of information) from the side issues (the supporting technology). In DEMO sources of information are easily found by seeking the facts. A fact is created when actors agree on a certain assignment and subsequently accept its result. A collection of facts is called a 'fact bank', to prevent confusion with IT terminology involving information systems and databases.
An example of a fact is: that a father goes to the Municipal Registry Office to have the birth of his child recorded. The father requests the civil servant to register the name, birthplace and gender of his child. The civil servant receives the request, but before promising to register the child, he checks whether or not the name is allowed and that the place and date are correct. Assuming that everything is correct, the civil servant then performs a number of actions and then declares that the child has been registered. The father checks the declaration, which is an extract from the Register of Births, Deaths and Marriages, for writing or typing errors. At the moment that the father agrees, a fact has been created. A child bears the fact of this transaction a whole life long, on a driving licence, for example, or a passport, bank pass, credit card, library pass, health insurance registration, etc. until the certificate of death.
A driving licence is also a declaration of a successful transaction between two actors. As a fact, the driving licence contains the date of issue by the issuing body (in the Netherlands this is the Mayor), and the number of the driving licence. None of the other information on the driving licence has been created; it has been copied from other fact banks. The copied facts are taken from the Birth Register for the name, birthplace and date of birth, the Municipal Register for the address, and the declaration of the approved driving test institute that the candidate has succeeded in passing a certain type of driving test on a certain date. Thus, the driving licence contains one fact, namely, the driving licence with number X was issued by Mayor Y on date Z to the person in question. All the rest has been copied. The same applies to passports, bank passes, credit cards, library tickets, healthcare registrations, and death certificates. These, too, are declarations in an essential transaction that contain one fact and many copied data.
Nowadays, a fact bank is supported by many various manual and automated information systems. Because an information system contains much material copied from other fact banks, in addition to true facts, one occasionally cannot see the wood for the trees (information systems). It is difficult to retain an overall view of the complexity of information systems. It is easier to abstract from all documents and information systems and to return to everyday practice, namely, the transaction whose result is stored in a fact bank. The concept of abstraction is not new. As far back as the 1970s, a distinction was being made between documents (physical level) and information (logical level) to be able to design a single complex information system. Nowadays, a third level of abstraction is necessary to reduce the complexity of the many information systems. This third essential level consists of transactions and fact banks. Information systems can be designed easier and better from that level.
Besides the transaction and abstraction concepts, as outlined in the first and second examples, DEMO also comprises the system concept. DEMO makes models of organizations. These models describe organizations as systems consisting of social actors, transactions, and facts. The system concept specifies an organization as the cohesion of actors, transactions, and fact banks. As a consequence, DEMO does not regard processes or information separately but integrates both in the transaction. What DEMO links to these is a note of which two actors are responsible for the completion of a transaction. Due to the system concept, it is easy to see who does what when. Designing an organization as a social system is a feature of the DEMO manner of thinking and recurs in the models.
In short, the conclusion of many years of research in academia and practice is that DEMO is an excellent method for the rapid (re)design of both small and large enterprises.