Process Thinking for Business Agility

BPM group of Stockholm University

Draft under development

Responsible: Ilia Bider, SU & IbisSoft, ilia@ibissoft.se

1. Motivation

The draft is aimed at understanding the requirements on business processes and business process support systems for emerging in 21 century organizations that function in the highly dynamic environment with global competition. There is a lot of talk about the organization of the future consisting of self-learning highly dynamic teams working in the agile manner to timely adjust the organization to the ever changing business world. Why does the organization of the future need such teams? What are their characteristics? What kind of technology should be used to support such teams? The draft is a try to give answers to some of these questions.

One of the main terms used to describe the new type of organization is business, or enterprise agility [1]. Though there is no definite definition of this term, most of the authors writing on business agility would agree on it having the following two components:

  • Being able to quickly adjust to changes in the constantly changing business world. The main question here is how to arrange product/service development so that a right product/service is delivered to the customers/market in the shortest possible time.
  • Being able to discover new opportunities constantly appearing in the dynamic world for launching completely new products/services. The main question here is how to arrange capabilities already existing in the organization to quickly utilize each opportunity, for example, in order to be one of the first in the new market.

Currently, the draft is structured in the following manner. Sections 2-8 are related to the first component of business agility. Sections 9-10 are devoted to the second component.

2. The traditional development cycle for products/services/processes

From the knowledge transformation point of view, the traditional cycle of development can be represented as a diagram on Fig 1. The diagram is an application of the Nonaka ideas about knowledge transformation in an organization [2]. The cycle starts with requirements engineering and ends with full implementation of the new product/service/process in the stakeholders  practice.

3. Risks with the traditional development cycle

Each transformation of knowledge includes risk of the procedure is not done correctly:

  1. Requirements specification do not catch the needs properly
  2. Requirements specifications are not converted into a proper design
  3. Product/service/process manufacturing does not follow the design exactly
  4. The new product/service/process is not properly understood by the stakeholders and is rejected or used in the wrong fashion

The risks above can be minimized by employing qualified requirements engineers, developers, manufactures, and trainers. However, these risks can never be totally eliminated.

                                     

Fig. 1. Knowledge transformation in the traditional product/service/process development

The biggest risk of all, however, in today's highly dynamic environment is that while a new product is under development, the problems/needs are continue to change. As the result, a wrong/outdated product/service/process is delivered to the business stakeholders.

The best, and may-be the only practically implementable way of minimizing this risk is to ensure that the development team has an updated tacit knowledge on the current problems/needs and can modify design based on this knowledge. This will also help in minimizing  other risks, e.g. the tacit knowledge possessed by the developers can help to compensate the inevitable errors in the requirements.

How to arrange that the development team has up-to-date tacit knowledge on the stakeholders needs? Two schemes  could be employed: agile development and cross-manning of business processes.

4. Agile development

A picture of the idealized agile development cycle from the knowledge transformation perspective is presented  in Fig. 2.

The idea behind the agile development is to avoid, as much as possible, to transfer knowledge into an explicit form. Minimum requirements and design documents, e.g.,  in form of notes, emails, or black- whiteboard diagrams will always exist. However, the formal legally binding requirements, or design documents are avoided. The evaluation and acceptance starts when a product/service/process comes into being.

Another idea behind the agile concept is having as small releases of new/modified products/services/processes as possible. The time for the full cycle diminishes, and the risk of launching an outdated/wrong product is thus minimized.

The agile development's motto is “Design, manufacture, and introduce in practice as little as possible as soon as possible”. For the areas where it is difficult/impossible to create something “little”, agile development won't work, at least not in its pure form. Other methods should be employed.

Fig. 2. Knowledge transformation in the idealized agile development

5 Cross-manning of business processes

We use Fig 3. to investigate where in an organization the tacit knowledge we need resides. Fig 3. presents a simplified view on an organization as consisting of assets and business processes (more exactly, business process instances) currently running in the organization. The most interesting assets in our case are people that are normally organized in units/departments. We differentiate two type of processes: internal (like product development) and boundary (like sales, or field services). The boundary processes run partly inside the organization and partly outside it (in the surrounding environment).

 Fig. 3.Traditional scheme of manning business process
The formation of Fig. 3,4 has been inspired by systems coupling diagrams from [5]

People engaged in the boundary processes spend most (or at least part) of their time outside the organization and have a possibility of obtaining tacit knowledge on the current needs and problems. Usually, each process is manned by people from a corresponding department, i.e. sales processes are conducted by the staff  from sales department, field services are conducted by the staff from the service department, product development is conducted by the staff from the engineering department, etc. In such situation, people who man the boundary processes and have a chance of acquiring the tacit knowledge that might be needed for the development do not directly participate in the development process.

There are two options to solve the problem above. One is to arrange internal processes for transferring tacit knowledge inside the organization. This will, most probably, require converting this knowledge, at least partly, in an explicit form before sending it to the development team. In addition, there should be some insensitive schemes to encourage such transfer. But even with all the problems of arranging internal processes solved, each additional act of knowledge transfer will add to the risk of knowledge transformation errors.

The other solution is cross-manning of business processes as is represented in Fig. 4. Cross-manning means that people participating in the development process participate also in the boundary processes (e.g. sales and/or field services). It can be sales people, or service engineers that participate in the development process, or (and) the developers that also participate in the sales and (or) field services processes. The advantages of this scheme is that there is no need for additional internal processes for knowledge transfer. Development team gets the knowledge directly through participating in the boundary processes. The disadvantages are that business processes should be adjusted to allow participation of the “foreigners”. This might lead to each   process becoming less “optimal” on its own. There can be lost off efficiency in each of the processes. However, this lost might be a small premium for ensuring the shortest time to the market for the product/service/process  that will also be “right” for the market.

Fig 4. Cross-manning of business processes that ensures tacit knowledge on the stakeholders needs is transferred to the development team in a natural way

Transferring the tacit knowledge on current needs and problems to the development team is not the only effect of cross-manning. The sales, or field service team that possesses the knowledge on the products/services/processes under development may start transferring this knowledge to  business stakeholder far in advance of the product reaching the market. This will create expectations and ensure smother transferring of knowledge on how to use the new product in practice, see the upper right corner in Fig. 1.

6. Impact of cross-manning on business processes

Cross-manning of business processes have serious implications on the way the processes  are to be developed, maintained, and supported by IT-tools. The two most important implications are:

  1. Each cross-manned process has multiple goals to achieve. For example, a sales process besides its main goal to sell a product or service, has a goal of giving the development team tacit knowledge on the current customer's needs/problems, even if they cannot be satisfied by the existing assortment of products/services. What's more it has a goal of informing and educating the potential customers about the products soon to come (the left upper corner in Fig. 1.)
  2. The process team becomes heterogeneous, i.e. it includes people with different backgrounds, experiences and goals.

The above implications mean that the idea of a process as a conveyor belt that could be optimized for one particular goal can no longer apply. A coordination and collaboration between people engaged in the processes comes to the forefront. This means that all participants should fully understand different goals, could see the progress of their achievement during the process run, and can help each other in achieving these goals.

Changes in the nature of business processes should also be reflected in the IT-tools aimed at supporting them. Instead of providing workflow engine that passes assignments in predefined sequence to various participants, a support system should provide the participants with a properly structured shared space that helps in tracking the progress and exchanging information between the participants.

As coordination and cooperation between the process participants becomes the main issue, a process should be adjusted to the team engaged in it, instead of being establish from the above.  The best way to design and “manufacture” an appropriate process is to use an agile process development according to Fig. 2.

7. A good process support system is a model of the process it supports

As shown in Fig. 2, an ideal agile development cycle does not create any explicit knowledge in form of drawing, diagrams, models. To understand what agile development of a business process means, let us add a new motto to the bubble on the left side of Fig. 1, making the list look like:

  • A good regulator is a model of the system it regulates
  • A good solution is a model of the problem it solves
  • A good key is a model of the lock it opens
  • A good process support system is a model of a process it supports

Interpretation of the last motto is relatively simple. In the agile process development, instead of modeling a business process, and then converting it into a system design, and coding the system, we go directly to “manufacturing” an IT-system that will support the process (the left bottom triangle in Fig.2). Then, we introduce the system, and thus the new process, directly into operational practice (the left top corner on Fig. 2).

As it was discussed in section 6, with cross-manned processes the focus moves from controlling the process participants to collaboration between the members of a heterogeneous team having multiple goals in mind. A process support system in this case should support collaboration, and information exchange, leaving responsibility of reaching multiple goals to the participants themselves.

The computer science has, for a long time, promoted the idea of using shared spaces for supporting collaboration. The idea was first introduced in the field of Computer Supported Cooperative Work (CSCW) and Groupware. With advances of Social Software, like Facebook, Wiki, etc., this concept got attention and full recognition. So, what we really need is a system with a shared space properly structured for the participants of the business process in question.

An example of how such a shared space could look like is shown in Fig. 5. The top part in Fig. 5 represents an upper level structure (a map) of the shared space for the process called “New product introduction”. The lower level details are organized with the help of  web forms that are attached to the process steps, boxes on upper level map, as shown in the bottom part of Fig. 5. The total structure of the shared space (a “map” plus all the step forms) constitutes a basic part of the process model  built in a process support system that provides this shared space.

Fig. 5. An example of of a process's shared space

8. Process “cutting” machine needed

Though, it is possible to manufacture a process support system that provides with a proper shared space by ad hoc programming, such approach would undermine the whole idea of agile development. It will be difficult to arrange short cycles of development and introduction in practice. A tool, a kind of a “process cutting” machine, is needed that allows the group to “cut” their own shared space without much help of IT-professionals.

The discussion above could be summarized in the picture as in Fig. 6 which shows the transition from the traditional process development to the agile process development supported by a “process cutting” machine/tool.

Fig. 6 Transition from traditional to agile process development

9. Pursuing new opportunities

Under an opportunity we understand a situation on the market that allows an organization to offer a new product or service to the customers based on the capabilities already in its possession. Under capabilities we understand any asset in the organization that can potentially be used for producing a new product or service. To assets belong people currently employed with their knowledge and experience, equipment, computer programs, started research and development projects, etc.

In the above, we consider the time window of a new situation to be quite short so that a situation itself does not represent an opportunity, unless the organization does posses capabilities needed for exploiting the situation. The opportunity can be either

  • Temporal - produce a limited number of products or services, and then stop

or

  • Permanent, where there is a fair chance that the situation creates a long-term niche on the market, or a completely new market.

In both cases, to employ the opportunity one needs to organize existing capabilities in more or less “quick and dirty” manner. With a temporal opportunity there is no time to make any optimisation. In case of a permanent opportunity, the organization needs to position itself in the niche or on the new market first, and only after that think about optimization. Starting with optimization may result in late arrival to the market and meeting much harder competition. Not being able to establish the presence quickly with the existing capabilities may indicate that the company does not have enough of them, thus the situation does not, in fact, represents an opportunity.

10. Capabilities needed for pursuing opportunities

As we mentioned above, to exploit an opportunity, an organization should be able to quickly arrange available resources to produce a new product or service. In other words, it needs to set up one or more new business processes in the timely manner. For this end, mastering the agile development of business processes becomes a capability that is necessary for pursuing new opportunities.

Above paragraph concerns an organization being able to pursue already detected opportunities. To detect them, the organization should have a process of discovering situations that could present opportunities. The team handling this process needs to have a first hand knowledge about both what is happening in the outer world, and what capabilities the organization has. Again, it will need to cross-man this process with the consequences described in section 6.

The last component of being able to pursue opportunities is capability development. This is an issue that requires strategic planning with a long time span, as planning should be based either on understanding slow trends, or just having a very broad program of developing capabilities. Just having mastered agile process development will not be enough.

11. Conclusion

References

[1] Sherehiy B., Karwowski W., Layer J.K. A review of enterprise agility: Concepts, frameworks, and attributes. International Journal of Industrial Ergonomics, 2007, 37, 445-460

[2] Nonaka, I. A dynamic theory of organizational knowledge creation. Organ. Sci., 1994, 5(1) 14–37.

[3] Conant R. and Ashby R. Every good regulator of a system must be a model of that system. Int. J. Systems Sci., 1970, vol. 1, No. 2, 89-97

[4] Scholten D. Every Good Key Must Be A Model Of The Lock It Opens.

[5] Harold Lawson A Journey Through the Systems Landscape. College publications, 2010