1 Background

As early as in the mid-1980s I had been considering possibilities of enabling employees of the departments to run data-processing operations by themselves. In those days this was known as end-user computing or fourth-generation language processing. The possibilities for letting employees from the department access information were still very limited at that time.

Despite this, the needs of the departments to generate information, regardless of IT (according mainly to their subjective viewpoint), was already very large at that time.

1.1 History of PCs

With the more widespread introduction of PCs into companies in the early 1990s the departments became increasingly independent of ‘centralized’ IT and thus started developing their own, ‘shadow’ IT departments. Tools such as Excel, Access and even Lotus Notes gave department users new flexibility to perform their individual processes and information gathering with IT support. In this way, an IT structure developed that was local to and controlled by the department.

1.2 History of the ‘Mainframe Mind Set’

The IT departments in companies were still acting largely within the culture that had evolved with application development for mainframes since the early 1960s. In the early phase of the development process, quality was assured by long specification phases. This was necessary since changes to the programming languages used could only be made with difficulty, due to the complexity of the code. The departments were used to the fact that implementing IT applications costs a lot of time and money and that, therefore, demands for new IT applications, or modifications of existing applications, could not be implemented quickly or spontaneously.

1.3 The Change Brought by Globalization

The effects of globalization and the resultant changes in the market have led to a demand for continuously shorter and more frequent product development cycles. The interconnectedness brought by the Internet provides customers with ever more information to let them compare the offers of competing suppliers, which significantly affects product development in the companies. The agility required as a result directly influences the processes and the associated IT systems.

There is often a need for changing the original concept as early as in the specification phase of an IT application development process. After the subsequent development phase before the ‘going-live’ deadline there are always a number of requests for changing the ‘finished’ application by the involved department. Consequently, the expectations of the departments concerning a new IT application are not met by the time the application is launched.

1.4 Effects in the Companies

In the companies as well, the agility of the market is resulting in changes of methods with respect to collaborative work. Collaboration (close networking) among the people involved in the process results in better adaptations to the rapidly changing challenges. This is also causing changes in roles and creating new workflows that then must be modified quickly. This much narrower, frequently changing interplay increases the complexity and traceability of the overall workflows IT is required to support. Each department knows ‘its’ roles and workflows. In the past it was the role of the IT department to bring together these different viewpoints, ensuring a well-targeted application landscape for the company based on an economically viable IT architecture. The IT department was thus the link between all IT applications in the company.

1.5 Departmental Expectations Are Changing

Due to the increasing number of new opportunities available to the departments and their ‘shadow’ IT, the use of apps and actual cloud solutions, the expectations of the departments to respect with the IT solutions in the company are changing. Now they want to exert influence on the ‘development’ of IT applications—quickly, flexibly, and without the ‘hurdles’ that IT development requires when delivering high-quality applications.

The now familiar way of working with IT applications—resulting from the spread of apps—creates the expectation that company IT applications will also allow greater ease of use (usability) through a reduction in complexity from the user’s point of view.

Forecasts by analysts that IT budgets will in future be shifted increasingly to the individual departments underline the trend that sees departments increasingly seeking opportunities for IT support for their processes independently of their own IT experts.

At the same time, due to the increasing complexity and more frequent changes in workflows and roles, it is becoming increasingly difficult for IT to function effectively as a central coordinator for the different roles/views (developing an authorization concept). The expert-driven consideration which IT applications are required in which situation (and which are not) is becoming ever more difficult to sustain.

1.6 An Ideal Scenario

In an ideal situation the experts of each department would be able to create and modify IT solutions directly in their own ‘language’. In this case the description of which workflows are performed with what information by each individual (subject) from his/her own viewpoint would be most suitable, since it allows describing exactly what an employee of a department actually understands. He or she is the expert on what can be done with what information. If it were possible for him/her to describe this simply and create an IT application out of it, the solution would be to have IT applications created (for different types of application) by the department directly. This would have to be achieved within the technical framework conditions of the IT department, which is also responsible for providing the information.

At the same time, IT development would be relieved of the many and growing demands by the departments for applications, driven by the need for agility. The backlog of requests that is caused by capacity limits in the application development section would be significantly reduced. The IT department could then concentrate on important aspects such as standardizing the IT architecture and, above all, on ensuring data availability. The IT department would thus gain strength as a business enabler, while the department would be used as an ‘extended workbench’ for application development.

2 Needs at Fiducia

2.1 The Introduction of S-BPM

Over the last 15 years Fiducia has documented its business processes using a BPM (business process management) modelling tool (ADONIS by BOC). The modelers trained in company organization for this purpose have adapted their modelling environment so as to be able to use it highly efficiently. Realizing that this way of modelling operates on a very abstract level, it turned out not suitable for the required level of detail when modelling actual IT-supported workflows. Hence, I decided to introduce an entirely different and unique methodological approach: Subject-orientated Business Process Management (S-BPM), based on the Metasonic S-BPM suite.

The aim of this shift was to be able to describe business processes from the viewpoint of the ‘subjects’, i.e., the roles involved in the departments. The level of detail would have to be so precise that each employee could describe all the steps and information required to perform each process. Since the employee performs these processes himself, it is easy for him/her to formulate his knowledge in a descriptive way. Since workflows need only to be described from individual perspectives, the description should also be simple. An employee describes what he/she obtains as an input to a process and where it comes from, what actions he/she performs and what outcomes he/she passes to other subjects (employees, systems, etc.).

Such as description results in a defined process for each subject, created by the role-holder.

The interplay between individual subject-based models is then described in terms of the communication between these models. Through this separation of individual processes assigned to each subject and the description of the interfaces between individual processes there emerges a modular process system that develops in its own components independently of other components, and that, if nothing changes at the interfaces, can also be modify each component independently.

The Metasonic S-BPM suite can then generate workflows directly from these process models, making the processes testable or even allowing generating a complete IT application directly.

To introduce these new methods along with the tool it was necessary to persuade two groups of staff of the need for this change: the ‘experienced process modelers’ and the IT specialists.

2.2 The Process Modelers

The new method was easy for the young process modelers to accept. They had no resistance to using and learning new methods or procedures. They adapted straight away to the new methodology and quickly realized that it offers many advantages. The specialists in the departments were also able to describe their subjective knowledge of workflows and the information they require for processing. The descriptions were developed in their own ‘language’ and thus their identification with the outcome was very strong.

Acceptance by the experienced modelers was different, however. They did not adapt to the new method at first. They expected that the subject-oriented business process management method would not be capable of describing complex processes. They felt this way in particular because the modelling was done with only five modelling symbols. The greatest hurdle, therefore, was to gain the acceptance of these modelling experts. The first attempts to demonstrate the new method would not be usable focused on very large complex processes. Again and again, workshops were held whose objective was to implement complex processes.

Yet by considering these complex processes from separate viewpoints, namely from each individual subject involved, even the most complex process lost its perceived complexity. The scope of each process was of course retained, yet the individual process steps, isolated for each subject, were not at all complex. Linking these individual process elements via the communications interfaces brought the whole process back together. It was thus possible to represent any process, however large or complex, simply and clearly in terms of each subject.

Once this procedure had gained acceptance, another point of resistance was being encountered. Having separated processes and thereby simplified the understanding of what was still a large and complex process, there was now the demand to view the entire process in a single overarching representation. Using S-BPM this also is naturally possible. The individual subjects addressed on the communication level give a complete overview. The interaction between the subjects becomes clear. In this way it is possible to fully understand the entire process. What the individual subjects are then required to do with the incoming and also the outgoing information is described by the behavior model of each subject separately. For a complete overview of the project, however, this representation is not necessary. The ‘subject jigsaw pieces’ and their communication via interfaces create an overall picture, while the links between these jigsaw pieces provide a detailed communication description.

Now that S-BPM and the Metasonic suite had been introduced not only as a modelling tool, their benefits to generate applications became evident. From the description using the S-BPM method in Metasonic, the process workflow is directly generated as an executable IT application. This ultimately demanded a high level of precision in the description, but in turn resulted in much higher quality. Finally, the model does not have the character of something that is used once and stowed in a drawer; on the contrary, it forms the direct programming for the future IT application.

2.3 The IT Experts

Recognizing the automated execution is exactly what provoked the resistance of the IT experts. Being forced to generate IT applications from subject-orientated business management representations initially created disbelief, and then fears of having to surrender competence. The applications developers sensed a threat that the departments would chip away at their sovereignty as experts with entrenched traditions. The current handling of the technical IT architecture was targeting several aspects: scalability to the appropriate number of users, security, performance, interfaces to the operational databases, and much more. Once all these points had been tested to the highest satisfaction they had met the demands of Fiducia, with its 4000 workstations. However, these technical reservations could be dropped now.

The discussion of IT applications being developed solely by the IT department persisted. The idea of enabling the departments to create small, simple workflow applications by themselves was perceived as a loss of competence for the IT department. The IT department rather accepted being the bottleneck when the development section was simply unable to implement many of these demands due to bottlenecks in capacity. The applications developers could in fact give highest priority to the ongoing development of the core applications. Normally, this by itself results in a very good level of utilization. On the other hand, flexible IT applications demanded by the departments on short notice that are also not intelligibly described can be implemented only when conditions allow that. This results in either frequent refusals or realization dates that are far too late to be of use for the departments.

This fact, compromising the image of the IT department as a business enabler, was ignored, in addition to the increasing orientation of the specialist department towards its ‘own’ solutions without involving the IT department. This ignorance was precisely one of the motives for introducing a change. Introducing the S-BPM method via the S-BPM Metasonic suite was intended to offer a flexible, agile solution to the department by IT. The interfaces with the operational systems, the data and the infrastructure would be delivered by IT; the department itself, meanwhile, would provide the business logic in its own language. The two sides would meet in the Metasonic S-BPM suite to create complete applications. The IT department retains ‘control’ over the applications created on a uniform IT platform, while the department can implement its requirements as flexibly as IT applications.

The fact that the need for this change existed could demonstrated by over 7000 Notes databases that have increasingly multiplied; the IT department was no longer the owner of these applications, while the department had also lost control over them. It was therefore urgently necessary that a solution supported by the IT department could be made available to the department.

3 A Sample Project: Managed Service Hardware (IT-Supported Process Introduction)

The hardware for over 4000 workstations at Fiducia was procured centrally for the 17 departments. This hardware was supplied centrally by the internal IT department (company organization), which was also responsible for ensuring that these workstation devices were working (incident process). Fiducia decided to bundle the procurement and the allocation process within the in-house IT department. One of the company’s subsidiaries had already provided this service for a major client. Hence, the internal IT department commissioned the subsidiary as provider to implement the managed service hardware. The result was a project, ‘The Introduction of Managed Service Hardware ’, that will be described in this case study, in particular in conjunction with the description of the benefits of S-BPM.

3.1 The Need to Introduce Managed Service Hardware

Standard practice for each department was to define their budgets for PC hardware needs for their workstations themselves. The result was that while the PC hardware was normally purchased in accordance with the standard company procedures, the choice of what hardware was purchased/replaced, and at what time, was the responsibility of the department. This led to three problem areas:

  1. 1.

    PCs that were technically outdated were being retained; it was the departments that decided when a PC should be replaced.

  2. 2.

    New PCs were always purchased for new employees, despite useable machines being available by departing employees of other departments.

  3. 3.

    It was not always possible to verify which PC was being used where.

3.2 Managed Service Hardware as a Solution

‘Managed service hardware’ was intended to supply PCs to the departments on a month-by-month billing basis. Procurement of the PC hardware would be done centrally and up-to-date equipment would be supplied to the departments from a storage facility. The decision to replace a PC would be the responsibility of the internal IT department. The device types were to correspond to the employee role. A high degree of standardization means diversity is restricted to seven groups (roles), including laptops and tablet devices. Software is also bundled on the basis of role. In case of fault occurrence, an appropriate replacement (PC) with the proper software could then be supplied, and the faulty unit could be taken for repair. Fault analysis would be carried out in the repair center subsequently, which would significantly reduce the out-of-service time of PCs due to faults.

3.3 Project Start: Initial Information-Gathering Process

In order to introduce this service, initial discussions were started with the subsidiary. An already established process at one of this subsidiary’s clients, which has a similar number of workstations, was selected to form the basis for the new process. The analysis began by using the descriptions available from the client’s project on how the service is provided for that client.

Since it has been possible to base the required IT solution on what seems, at least, to be a similar business logic used for an external client, the possibility of letting the department develop it with S-BPM and Metasonic was not considered. Instead, the project was carried out in the ‘classic’ manner, with some BPM modelling, (which was no longer to be used) and implementation effort carried by an application developer—in this case, SAP customizing experts.

These descriptions, including how they can be adapted to Fiducia, were discussed in a series of workshops. The following five process elements (abbreviated to IMACR) were examined:

  • Install

  • Move

  • Add

  • Change

  • Remove

All staff nominated as responsible for the workshops contributed its experiences to the corresponding process. These were the responsible roles nominated:

  • Persons responsible for interfacing with the process to be outsourced

  • Persons responsible for hardware specifications

  • Responsible persons representing the subsidiary

  • The dispatcher (task distributor)

Since the process had already been used for a client of the subsidiary, and the process was thus known in detail, these four roles were identified as those primarily involved in the process.

However, as it became clear later on, many more roles were relevant for the process. They had not become evident in the course of modelling, as in the beginning the focus was not on the subjects involved but rather on the workflow of each partial process. Most of the relevant information was thus discussed at a highly abstract level, in terms of workflows, their sequences and the interfaces.

3.4 Framework Conditions

To allow information about the status of the PCs to be punctually updated by the service technicians, it was necessary that the service technicians collect data directly on site and send them using smartphones. This would be achieved via an IT interface. Since the inventory data is managed in the SAP system as assets, a solution within the SAP system was assessed to be the naturally most suitable one. Here, each asset would be stored including its status, in a way that the current status for each PC would be known. The following parameters were defined as status properties:

  • In use at a workstation

  • In storage

  • Undergoing repair

  • Scrapped

To make this process more transparent it was modelled in the ‘classic’ manner (BPM) using the Adonis modelling tool. The modelling was done by internal modelling experts together with the departmental role-holders. The latter were asked in focus groups how the workflows run according to their view, and their responses were transferred to a BPM model (Adonis).

It was soon apparent that transferring the individual steps of the individual roles from the department into a model (to be created for each of the five process sections) was getting increasingly difficult. Although, e.g., an ‘install’ process is entirely straightforward at first sight, the different viewpoints of the different roles cause the modelling of each process step and thus tend to become ever more difficult to follow for the persons responsible in the respective roles. They do not see their individual roles as being central, but rather the workflows that have been documented across all roles.

The experienced process modelers nevertheless succeeded in modelling a process that is inherently consistent. They could achieve their objective, and validation was obtained at this very abstract level. What actually takes place in detail in the process is, however, remains open on this modelling level. It requires observing the actual role behavior, thus bringing the role to the center. As long as it is not the aim to create executable IT applications with BPM, much information can be dispensed with, which can in fact be of great importance if one models the process as it actually occurs.

The role-holders, who themselves have no experience in process modelling, were only able to test the process model under certain conditions. They could only identify themselves to a certain extent, since the modelling was performed by ‘experts’. It was thus not ‘their’ process model. In the dialogue between the process modelling experts and the specialist role-holders from the departments, no common level for understanding could be achieved. While the modelers were constantly focusing on the overall process, the role-holders had in mind their individual areas of responsibility in detail. This was, however, not emphasized by the modelers, who necessarily held on to their overall view of the process.

After seven workshops, a comprehensive process model was established for each of the five partial processes (IMACR). These process models, together with the descriptions of the scope of each individual task (SLA), were adopted as the basis for implementing the managed service hardware scheme, including its technical realization.

Since the task descriptions were related to the subsidiary’s client company, they only needed to be adapted to the present situation. The actual outlay of over 50 person-days to that point had been necessary for modelling the five partial processes. All persons involved were satisfied with the outcome, and work started with creating a specification for the technical support. Based on the outcomes of the modelling process, the service-level agreements with their requirements and the necessary extensions in the system assets in the SAP system, a specification was created. Initially, a solution was drafted that could gather the data using a Lotus Notes-based workflow; this data should then be used as the basis for updating the SAP data stock once a day.

This mechanism, however, had to be rejected. Out of a total of some 4000 PCs, roughly 20 are in use (IMACR) each day. To allow the service technicians and the other roles to find the current state of affairs in a timely fashion in the database, the changes need to be made directly in the SAP database as the leading system.

The solution scenario was now defined in such a way that all participants were provided with dialogues within the SAP system. It supported them with the necessary information to search for and/or update information. The necessary process logic could be implemented accordingly with SAP tools (service manager), enabling the accurate execution of the required workflows. The SAP dialogues could be implemented on the intranet platform, as had been done previously for other SAP solutions, and could also be invoked from there. The interface to the smartphones could be enabled when purchasing new software.

3.5 First Rough Estimate: 150 Person-Days

Once the specification was created, an initial rough estimate was made for implementing the concept. An optimistic scenario projected at least 150 person-days for customizing SAP and for modifying the SAP database.

3.6 Weaknesses Recognized

After a first inspection of the specification and its estimation for implementation, various issues became evident.

3.6.1 Lack of Detail

The actual tasks required for implementing an IT application, which were known to the role-holders, had not been modelled. The role-holders were not aware of that; they knew the details after all, and were already overloaded when representing the total model on the level of detail used in the process model. Despite the lack of required detail, it was too complex for them, since it was not their viewpoint that had been modelled, but rather an overall system perspective.

3.6.2 Redundancies in Partial Processes

Due to the focus on the partial processes (Install, Move, Add, Change and Remove), in the development of the process model the employees who are actually involved in the process were only ‘assigned’ to these partial processes. They were not central to the process design. Hence, redundancies appeared in the individual partial process steps. Considered from the viewpoint of the subject (role) such phenomenon would have been clear, since the role-holders would have defined their tasks from their viewpoint, their area of responsibility. Yet, in this way, each partial process was described independently of the other processes. In addition, ‘merely assigning’ the employees did not make evident which further roles were seen and needed by these employees in their partial processes. This knowledge was not collected by an exclusive observation of the overall process. In other words, the process has been put to the foreground rather than workflows of individual roles.

3.6.3 Modelling Outcomes Are not Sufficiently Detailed

Another problem concerned the quality of the modelling outcomes. The departmental specialists were mainly knowledgeable in their own areas of responsibility, being part of a large overall system. By looking at the overall process in the course of the modelling, their awareness of its complexity increased. The discussion about workflows involving many other roles was considered overloaded by the ‘role specialists’. They also kept giving a coarse-grained representation of their partial processes, trying not to increase the perceived complexity.

3.6.4 Low Level of Identification with the Outcome

As the departmental staff members are not skilled modelers, they need to accept the developments of the modelling experts. Similarly, the modelling experts are not specialists in the non-IT topics and struggle sometimes to understand what they are modelling. Accordingly, two cultures (the process modelers and the departmental specialist roles), each with different objectives, a different understanding and a different language, have come together in a dialogue that demonstrates the typical difficulties of translation between the business areas of the company and IT. For the departmental employees the outcome of the modelling process was not ‘their’ solution they had created by themselves.

3.6.5 Lack of Confidence in Making Mistakes

The role-holders from the departments are still not used to making statements on a higher level of abstraction of a process than their viewpoint. Due to their experience, if such statements are made, they will have to be interpreted for implementation. And, in case the statement is not absolutely correct, a change request will have to be made, which

  1. (a)

    drives up costs,

  2. (b)

    delays the planned implementation date, and

  3. (c)

    results in an even more difficult collaboration of the department with the IT section.

Overall, due to lack of detail, needless redundancies and ambiguities stemming from different viewpoints, the quality of process models is too poor to obtain practically useable inputs for implementing them.

3.7 Project Restart from Scratch

With a minimum of 150 person-days planned for implementation, modelling of insufficient quality and, finally, too many open questions about how to implementation the processes, I decided to rethink the project from the beginning. The new approach was based on the already introduced subject-orientated business management (S-BPM), although it was not popular with the ‘experienced’ process modelers.

3.8 Workshops with the Role-Holders

Together with a new team from the company organization, the persons in the responsible roles for the ‘managed service hardware’ process were invited to a relaunch workshop. This time, with S-BPM, the role-holders were the focal point. In the first workshop the departmental specialists were informed about the ‘methodology’ of how their knowledge would be collected and used to develop an IT application. Hereby, three different actions were represented in different colors.

  • Green for ‘I’m receiving something’,

  • Yellow for ‘I’m doing something with it’,

  • Red for ‘I’m delivering an outcome’.

Using this simple structure, discussions began about the ‘Install’ process. The content of the different tasks and the framing conditions were already known. What needed to be questioned, just as in the earlier project, were solely the necessary workflows and the roles involved.

Three different media were provided to enable the employees to ‘capture’ this information.

  • Direct capture on the PC with an easy-to-use interface in Metasonic.

  • Direct modelling on a ‘modelling table’ that at this time was still at an early stage of development (today this would be by far the best medium in my view).

  • The ‘flip chart’ to which magnetic cards are attached in three colors and which can be connected in the sense of an S-BPM model. The model can then be captured directly via the PC interface.

In the project, the latter method was adopted, since no technical hurdles (working on PCs with management) should arise, and the attention would be on the methodology rather than on tools from the beginning.

3.9 S-BPM Supports the Departments’ Way of Thinking

It became clear from the first workshop that the departmental employees could work with this method while maintaining a strong sense of identity. Using these three questions, each could describe the workflow known to him/her. The important details were also addressed immediately, in particular what information is required and who else also needs to be linked to this element of the workflow. It was thus the world the individual subjects perceived that was described. For each involved role (subject), a workflow with the necessary interfaces and content elements could be developed in this way. Shortly after being introduced to the methodology the role-holders took over the modelling themselves.

At the end of the first workshop the workflow models were entered directly into the Metasonic S-BPM suite. The data capture was complete in barely an hour and an initial workflow could already be visualized and simulated as a prototype. It became clear very quickly that more roles were required than those that had been originally defined. They are given in the following for Fiducia and the subsidiary.


  • The departmental employee

  • The employee’s manager

  • The person responsible for the hardware specifications

  • The person responsible for the interface to the outsourced process

  • The person responsible for the commercial stock

These five roles were represented by two employees.


  • The responsible person of the subsidiary

  • The dispatcher (task distributor)

  • The technician

  • Head of repair center

  • Head of software loading

These five roles were represented by three employees.

3.10 Methodology Can also Be Used by the Department in Connection with a Tool

These role-holders were thus also incorporated into the modelling process. In two further workshops (one day each) all the partial processes of the managed service hardware process were modelled with all participants based on the S-BPM method. Since the outcomes of this modelling could also be run directly on the PC, it was decided at the second workshop to use the PC directly for the modelling. The hurdle of using a tool had been overcome; the method had gained acceptance. At the point in time when a finished workflow emerged from the modelling and could be verified by simulation on the PC, many details emerged that required clarification. Since, however, the model could be modified straight away, the departmental specialists continuously gained confidence bringing their experience and understanding to bear. They could make no mistakes that would be difficult to rectify. They could make changes at any time and these would take effect straight away.

3.11 Full Identification with the Outcome

A further interesting effect could also be observed. Since the subjects (here, departmental experts) were at the center stage and were themselves ‘modelled’, the demand for certain special requests also changed. However, now the departmental experts themselves had to describe them, rather than passing them as development requests to the application development team without being aware how much effort was involved. The result of this approach was that functions that were not strictly necessary were left out, while the departmental experts identified entirely with the completed outcome. They had, after all, developed it by themselves. This accounts for a significant potential for savings in development costs, since only the genuinely necessary functionality is developed and no ‘frictional loss’ occurs between the department with its demands and the IT department with its limited resources. And since changes can often be made ‘on the fly’ by departmental staff themselves, they are motivated to remain involved with the IT application even after it has been created.

3.12 IT Application Could Be Completed at an Early Stage

After three workshops with five attendees each (15 person-days), modelling was completed—and already in an executable version. Now work could begin on the IT application itself.

The depth of detail was now sufficient to execute the workflows immediately, including all their content-related requirements. There were therefore no longer redundancies in the partial processes, as these had become apparent using the subject-centered approach and the prototypical execution. A very important insight was that the subsidiary could not provide this level of detail for the processes, although they would also have been conducted in a similar way for the external client.

However, the attempt to represent the processes using traditional BPM methods, as at the start of the project, did not result in a model representing the actual process in full detail, containing the actual workflows. Despite a very high outlay on modelling with BPM, the outcome did not represent the real-life situation. Using S-BPM, on the other hand, the workflows as actually being performed became evident. It resulted in many significant improvements with respect to standardization and clarification of interfaces, and thus in optimized work practice.

Additionally, the degree of completeness of the description of the workflows increased during these three workshops. For the first time, not only the standard processes, i.e., ‘when everything works according to plan’, were examined, but also the many exceptions that arise in practice. For the latter there had not been specific descriptions so far. Somehow it had always worked out, however, leading to unnecessary excess costs due to unclear definitions. Now, this excess outlay was no longer necessary.

The role-holders involved in the process still collaborated yet each from his/her own perspective or position to describe the workflows in such detail that the specification and technical concept were to a large degree already complete at this stage. To implement the IT application, data storage in SAP was still required. The SAP system was therefore considered as a subject in itself when modelling. Here again the same logic was used: what information SAP receive, what should be processed using that information, and what information should be passed on. In this respect, what a ‘subject’ represents is of no consequence to the method. This simplification also proved immensely helpful in facilitating the discussion when creating the model and the ‘technical’ interfaces.

Following this initial gathering phase of the descriptions of the current processes from each subject’s viewpoint during the three workshops, the process models were further refined and complemented with additional detail. Since the IT application thus obtained needed to be available to all employees on the intranet, the design of the input dialogues was specified in greater detail. When a managed service request was made, the interface to SAP was implemented to create a ticket automatically, and to adapt the relevant status message in SAP to this asset.

The Metasonic S-BPM suite has its own solution for including the dialogues on smartphones. It was integrated along with the interface to the SAP system. The service technicians can thus use their smartphones to store information about a ticket directly in the database of SAP and can also directly view new orders or changes of orders. The complete implementation of the outcomes (from the three workshops and a few subsequent specialist discussions), i.e., the executable IT applications required about 30 person-days development effort. Compared to the previously (optimistically) estimated 150 person-days this difference represented a significant cost saving.

Another factor was owed to the limited capacities of the SAP customizing personnel implementation had earlier been planned to take some nine months. Yet using the S-BPM approach provided by the Metasonic suite, the application was running in production in just two months. Due to this much earlier availability, the benefits of the solution could come into effect seven months earlier than planned.

4 Summary of Experiences Gained in This Project

The former standard procedure, in which process modelers (as the developers of the model) and departmental staff (as the process experts) sit opposite each other and try to map the workflows from their own viewpoints to create an IT application, has significant disadvantages.

The modelers are not experts in the departmental fields (non-IT); rather they need to represent in a model what the departmental staff tries to explain to them.

The departmental staff members, meanwhile, have their focus on those parts of the process that they deal with themselves, while the process modelers are concerned with the overall business process or work procedure. The roles involved are thus only assigned to parts of the overall process they are not the focus in reaching an outcome. Using a different approach, namely following the S-BPM method, the departmental specialists have now begun to describe, in their ‘own language’, the part of overall processes that they individually handle. Now the process modeler is mainly a moderator who provides support for how the method is used. The departmental staff members soon came to understand the method and are now capable of doing the modelling themselves.

Since there was no longer a media gap between the specialists and the modelers, the quality of the created model was substantially higher. The departmental specialists created the model themselves. No modelling expert was required to interpret what the specialists had told them in order to then integrate this information into a model. Since the outcome was immediately executable, it could be validated straight away, and deficiencies could be quickly spotted and corrected.

The difference between the process models created with the traditional BPM method and S-BPM could be revealed clearly, as it became clear how limited the level of detail is that can actually be portrayed with traditional BPM modelling techniques. Although this situation can certainly be improved with further expenditure, the underlying deficiencies, due to the focus on the overall process and its workflows rather than on those of the subjects, always remain.

The departmental employees identified themselves fully with the solutions they had produced. They were able to avoid excessive demands on themselves, while fully understanding in a verifiable way their workflows and actions, including exceptions in the process.

This statement also holds for the final documentation, as it captures how the workflows are actually used. Any change of the IT application is based on S-BPM models. Consequently, the documentation is always up to date. The employees’ understanding of the workflows, including exceptions, was deepened, which in turn increased their cooperation in terms of efficiency and the quality for the customer due to the achieved transparency of work procedures.

The standards for database interfaces in the Metasonic S-BPM suite enabled the integration of SAP as data storage system in a simple and comprehensive way. Since the user interfaces for the workflows were generated via the intranet or smartphones directly (without additional programming), the IT expenditure was significantly lower than in the solution originally conceived. The expenditure for the project was significantly below the planned effort for the original approach.

Expenditure with BPM (approx. 260 person-days):

BPM modelling (approx. 40 person-days), creation of specification and technical concept for implementation in SAP (approx. 50 person-days), SAP implementation by Customizing dept., including testing, documentation and productive release (approx. 150 person-days). Acquisition and technical implementation of a smartphone support system (approx. 20 person-days). Implementation was to be expected in one year.

Expenditure with S-BPM (approx. 70 person-days):

Modelling with the S-BPM method including documentation of IT application (approx. 30 person-days), implementing interface into SAP system and adapting database for the required parameters (approx. 30 person-days). Tests and pilot runs (approx. 10 person-days). Final implementation could be done in 3 months.

4.1 Outcomes and Recognized Effects of the Actions Taken

The introduction of S-BPM into a company is initially met with various forms of resistance. They vary according to the extent of the culture of readiness to change in a given organization. Changes are often perceived as threats. Hence, once a change requires fundamental rethinking, it is necessary first to get those on board who tend to hold onto the old approach. Modelers who have used BPM for years are likely to continue working according to the logic familiar to them; they will regard any change as nothing more than an augmentation or modification of BPM. They cannot (or will not) admit the possibility of a subject-focused approach. It is certainly hard for such groups to accept this new approach when they are not keen to recognize any undermining of the dependency of the departments on the modelling experts for IT application development. Further developments in traditional BPM, such as BPMN 2.0, are generally easier to accept. Comprising at least 50 notation elements, each having different characteristics, this modelling notation is sufficiently complex to be left in the hands of modelling experts. The benefits of S-BPM in enabling the departments to develop their models themselves can never be achieved with BPMN 2.0.

Application developers do not want, on one hand, to deal with the demand of the departments for small, agile IT applications. They simply have neither the time for meeting them, nor perceive the importance of such applications to the business areas. On the other hand, they do not want to give up their ‘unique selling point’ of being the only group capable of creating IT applications; this has always been the case, after all, for 50 years. In general the IT department’s confidence that departments can create their own applications is extremely low, and thus they tend to reject new approaches, such as S-BPM, in the beginning.

The departmental employees, the business experts, are also not immediately convinced that this S-BPM method, created specifically for their way of thinking, will provide them with a solution overcoming the IT application bottleneck. The practice that has been in place for the last 50 years and plays a major part is such that the interaction between the departments and the IT section is seen only to work in the way as experienced in the past. Nevertheless, the business experts are the group that has the highest willingness to engage in implementing new approaches. Due to the pressure of the market to provide new, agile IT applications that can respond quickly to changes in customer expectations, this willingness has increased. This development could be triggered by the need for shorter product development times, better, more flexible services, or a different sales approach.

The former ‘shadow IT’ in the departments suffers from the fact that it is not being supplied with the actual data of the company. Attempts had been made to make all information available to the departments by developing sophisticated data warehouse solutions; yet the workflows and actions had to be somehow supported with mails or Notes databases, in case it was not possible to wait for solutions from the IT department. And this shadow IT no longer meets today’s demands of IT applications. Its functionality is far too limited, it is isolated, as few groups in the department are able to use this tool, and it is impossible, finally, to integrate databases or to link such solutions with an operative core system.

From the viewpoint of the continuously increasing compliance requirements, there are now provisions that cannot be satisfied by shadow IT, too. Consequently, all three groups—department, process modeler, and IT department—need to be persuaded when S-BPM should be accepted. Gaining the approval of the departments is relatively straightforward due to the simple and straightforward development procedure. An early implementation meeting a typical need of one of the departments can help increase the acceptance of a novel methodology. A highlight in the project described was a change request that occurred 15 min before the application was due to go live. An employee had another good idea for improving the process at a certain point. When we offered him the possibility of implementing this modification, he could not believe us. Yet we made the change, and the application went live with this modification in place ten minutes later. This was a typical positive multiplier effect.

For process modelers it needs to be clear that they will continue playing an important role in the future, however, from a different perspective. Lengthy printouts stemming from modelling large processes are no longer acceptable. Rather, by viewing an overall process from separate viewpoints according to individual subjects, intelligible processes are created. In most cases the departments will be glad for the continuing facilitation by the modeler. After all, even with the S-BPM approach it is possible to define optimal or rather suboptimal workflows. The future role of the modeler will focus on such aspects, and lead to optimized process models that support the continuous improvement process through their flexibility for adaptation and their representation close to the perceived reality.

Application developers need to realize that their importance as business enablers will be recognized by the department only, once the changed requirements can be satisfied from the business areas, such as agile IT applications that can be both created and modified quickly. By using S-BPM and the Metasonic S-BPM suite, such an approach is enabled. The application developers and the overall IT department remain the owners of the platform and the interfaces. As such, they are also responsible for the most important element in the entire data-processing operation—information. This new role creates space for large and central application systems that cannot be created by the departments themselves. At the same time, however, the business areas are supported by the IT department in such a way that they can respond to the quickly changing demands of the market.

4.2 Several Benefits Have Been Achieved by Introducing S-BPM

Significantly less expenditure when implementing an S-BPM model created in cooperation with the department reduces the production costs . By separating processes by means of individual subjects, the complexity can be significantly reduced. This in turn considerably simplifies working with the role-holders in the departments, as they understand these ‘isolated’ viewpoints. By describing the individual communication to the other ‘isolated’ viewpoints of the other role-holders, the overall process and thus also the entire IT application emerge.

Achieving such a level of understanding facilitated working with the department when modelling processes. A form of ‘language’, S-BPM, was used for describing and implementing the IT application. This resulted in significantly better quality of outcome (no media gap), and the acceptance of the created solution in the departments was considerably higher. They had created the solutions by themselves.

Due to separating into subjects it was also much easier to make changes within complex processes. When beginning to describe a process, not all details are always present, yet with the S-BPM method it is possible to begin straight away. Changes often affect only individual, subject-related solutions. Using S-BPM they can then be modified independently of the others. Precision can thus be increased step by step.

Due to the significantly shorter production times for IT applications when using S-BPM, the benefit of a solution can become effective much earlier. Its flexibility allows meeting the need for adaptation arising from its use in production far sooner, leading to competitive advantages through application systems that can be used earlier and better adapted. Similarly, IT solutions that have not yet been thought through in detail can be made available at a very early stage. The stimuli for optimization popping up when using these applications can be implemented straightaway, dispensing with a long analysis phase that attempts to predict such optimization. It can be recognized when analyzing typical change request procedures after an application has gone live that this traditional way of development does not lead to the expected benefits. Obtaining experience directly from practical operations and then implementing work support quickly amounts to a paradigm shift in application development.

Documenting the IT applications and the associated processes and maintaining this documentation in its most up-to-date status, reflecting actual practice, offers a new level of transparency . Documentation no longer needs to be something laboriously assembled after release: it is now a component of the application itself and fully integrated. Information about the actual execution of the process steps, including content and time, is logged and can be automatically generated using a uniform procedure in S-BPM and the Metasonic suite. Such information also forms a significant element of process cost optimization , since only information actually obtained can be used to drive improvements. Often the benefit of such exact logging of process tasks is overlooked in IT applications.

Using a process interface that is uniform for all workflows, the different user interfaces of different IT applications can be aligned. Thus, e.g., in case of authorization management for data access, a single IT application was created using S-BPM to manage the various different authorization systems due to the variety of databases and systems and their specific tools. This uniform application provides the employees with a single user interface.

5 Closing Remarks

In conclusion I can only stress that S-BPM offers an entirely new approach to defining processes and their direct implementation utilizing IT applications. The underlying development principle is to decompose processes, however complex they are, into the individual subjects that are involved in the process execution . Apparent complexity is thus broken down and at the same time the quality of requirements of an IT application is ensured in such a way that an application can be derived from the specification directly.

This decomposition leads to an understanding by the departmental employees of how they can describe a process from their own viewpoint. They are ultimately the experts who are best able to describe their work. The fact that executable IT applications can then be created immediately enables the specialists to verify and to change workflows straightaway. They are thus enabled to engage actively and to take responsibility for the outcome, while identifying themselves with the results.

Using the standard Metasonic platform provided by the IT department, IT applications automatically generated from the modelling can be put into operation straightaway, still under the supervision of the IT department. The interfaces to data and systems are provided centrally by the IT department and can be selected by the departments. Changes in the course of modelling, and even during execution of an application already in use, are often very easy to achieve owing to the isolating subject view. On the basis of my experience, the adoption of this change process for this kind of IT application development is a must for agile organizations. S-BPM enables such significant benefits for the IT support to the business areas that considerable savings and, above all, quality improvements can be achieved only after completing few projects. Using a corresponding tool, agility can also be achieved professionally with IT applications.