I.Bider (IbisSoft, Stockholm), M.Khomyakov (M7, Moscow)

The paper describes a dynamic model of business processes suitable for building management automation applications. The model was devised in 1989-90 for the "DealDriver" project with the objective to build an application for supporting sales and marketing activities of a trading company.

One of the goals of this application was to organize the efforts of the people working on common goals. Most of the solutions to this problem originated from the time before computers became available for practically any company. However, it was a general practice then (and even now) that the developers followed the old management scheme when the company was being computerized, whereas modern computers offered unique opportunities for implementing new, far more effective approaches to management.

Having the above in mind, we started to consider the company's activity as a number of processes (such as "processing an order", "closing a deal") without regard to the way these processes were being managed. As the result, a model of business processes was built based on an idea of process-oriented management which can be described as a project management without project managers, a project manager's functions, e.g., planning, controlling the execution of activities, etc., being distributed among the workers involved in a particular process.

When building the model, two requirements were taken into consideration. First, the model had to be used for building application systems, not just for describing business processes. And, second, the model had to be used as a common language to discuss business specifications with the customers. The first requirement demanded the model being formal enough to be embedded in the tools supporting application development. The second requirement implied that the model (on some level) should be based on the notions that already existed in the business world and could be easily understood at least on the management level.

The resulting model was based on the concepts of:

• Operational goal, like:
• closing a sale
• getting money for an incoming sales order (after delivering goods)
• discharging the patient from the hospital (after his recovery)
• building a software system according to the specifications
• Fixing a bug or finding a work-around for a problem report, etc.
• Business process aimed to achieving an operational goal
• Dynamic and distributed planning of the activities performed within the business process.

The most natural approach to modeling business processes would be the object-oriented one, where business processes are represented as objects. We call these objects "orgobjects" to stress the fact that they serve as an organizing device for achieving the operational goals. The state of an orgobject reflects the current state of the business process, the difference between this state and the legitimate final one showing what further actions should be undertaken in order to reach the process goal.

As far as objects’ states are concerned, any of the existing object-oriented approaches could be used. However, the type of actions that we needed to cover couldn’t be naturally represented in the most spread object-oriented models derived from the object-oriented programming paradigm. A different approach to object-orientation was developed which is presented in the following section.

In our model, object is a central notion. Not only are business processes represented as objects, but also all other entities of the application domain, such as customers, goods, the company’s personnel, etc. Objects are complex and dynamic. The complex nature of objects is reflected by links that show the inclusion of one object into another. The dynamic properties of objects are represented with the help of:

• History
• Events
• Activities

History is the time-ordered sequence of all the previous states of objects. The history is most important for objects that represent business processes (orgobjects, as we call them) as it shows the evolution of the process in time. The history in some cases is used in addition to the current state of the orgobject to figure out what further steps should be completed to transfer the object to the final state.

Events are a special kind of objects that present additional information about transitions from one state of the object to another. An event contains date and time when the transition had occurred in the real world, date and time when it was registered in the system (may differ from the previous one), the person whose actions caused changes in the object (if applicable), his comments on the event, etc. A new event object is born each time some other object in the system has been change. An event is a system object aimed to tie the transition of the orgobject from one state to another to the point in space and time of the real world, e.g., when, where, who, etc. However, it possesses all the properties of other objects in the model. In fact, it can be changed, for example, in order to add additional comments on the event later. Changing the event object, naturally, will cause the creation of a new event to describe who when and why tried to alter the history (no "1984" is allowed). The sequence of events that concern the particular object represent a written history (interpretation) of this object, as opposed to the real history, i.e. the sequence of the previous states.

Activities represent actions that take place in the world of application domain, like getting a sales order, shipping goods, administering a drug to a patient, performing a software module compilation, etc. In the model, the activity moves an orgobject to the next stipulated state. An activity may be planned first and executed later. This process is realized in our model by a notion of planned activity. A planned activity is an object that contains such information as type of activity (shipping, compiling, etc.), planned date and time, deadline, reference to the person who is responsible for performing the activity, etc. Planned activities are included in the orgobjects which they will affect when executed. All planned activities included in the given orgobject compose the immediate plan of the process evolution. When executed, a planned activity changes the orgobject to which it belongs. This change may include adding new planned activities and deleting the old ones (for example, the one that is being performed) which will affect the object evolution in the future. After being executed, the planned activity becomes an event registered in the system.

Planned activities help to realize the idea of dynamic and distributed planning. Dynamic planning involves planning only the first few activities at the first stage. As soon as one or several of these are completed, new activities are planned with regard to the emerging state of the relevant orgobject. Distributed planning implies that the worker who has completed a planned activity himself plans the subsequent activities, thus there is no central planning. Moreover, he/she can assign these new activities not only to himself, but to other people too.

Naturally, human beings that work with the system are also represented as objects, a kind of resource objects. As we’ve seen above those objects are referenced to at least in two places of our model, i.e., events, and planned activities. This references show two main characteristics of the persons’ works:

• A sequence of registered events that refer to the same person shows this person’s workload in the past.
• A sequence of planned activities that refer to the same person constitutes a personal calendar of the person, and shows the workload of this particular human resource in the future. The latter should be taken in consideration when planning new activities for this resource.

Note: On the surface, our practical model is very much like a workflow diagrams, however internally it’ s quite different, from both theoretical and practical point of views, e.g.:

• It’s based on the object-oriented approach to process representation.
• It’s aimed to embrace all aspects of managing the routine work, not just workflow.

The main advantage of the model described above is its flexibility. It permits to choose the optimum approach to coping with each process, and within the same management scheme. Thus, simple processes that follow a standard pattern are dealt with in a completely decentralized manner, whereas some more sophisticated case will be dealt with by centralized individual planning and supervising. Moreover, the same process may be treated differently at different stages. For example, it may be started as a standard one, but later it can be planned and supervised individually. As a result, full control over all kinds of processes is gained and efficiency is not sacrificed.

Another important thing is that the model is not bound to any particular type of organizational structure. It can be used both in case the same member of staff completes all the activities required for achieving an operational goal, and in case each activity type is assigned to a particular worker. This permits to preserve the same management scheme when the organizational structure is changed, e.g., in case of a company's expansion.

Some other advantages are as follows:

• Orgobjects provide a perfect insight into the process’ state of affairs. The information stored in the objects is of great help to the management staff as it permits to evaluate the state of any process quickly (without going into the history).
• Histories make it easy to trace all the activities completed in a given process, which helps to draw up plans for complicated cases. They are also a very important source of data for all kinds of process evaluation and statistical analysis.
• The company staff becomes goal- and process conscious as it is easy for any person to overview all the activities (one’s own and those of others) completed in the process he/she is involved in. The history of an old orgobject is useful for "learning by example", which may help a worker to find solutions in difficult cases.
• Distributed planning is a very powerful tool for coordinating the work which makes unnecessary the intensive communication among the workers engaged in the same processes
• Since all the information on the past activities is being stored, the management is in a better position to resolve various kinds of conflicts.

During the DealDriver project, for which the model described above was devised, we also developed homemade development tools that included Hi-base - an object-oriented historical database, and Navi - an object oriented user-interface system. Hi-base is able to store all the previous states of the objects and show them on demand. Navi allows the end-user to easily navigate along the links connecting various objects to each other in presence and past (history). The results of the DealDriver project are summarized in brochures [1,2]. The tools developed for the project were later successfully used for building prototypes and working applications in other industries. One of those applications won the "Object Applications of the Year Awards 1997" in the group "Best object-based application developed using nonobject-oriented tools" (Object World Show in London, April 1997).

Our experience shows that the following should be considered when choosing or devising a formal language (model) for writing business specifications, and methods of implementing them in business applications:

1. The level of technologies available for building applications. Not paying enough attention to the existing technology may result in either:

• the current technology doesn’t allow to build a system according to the specifications, or
• business specifications repeat the current structure of business processes that are arranged manually, or with the help of an older computer system, whereas the modern technology allows far better approaches for arranging the business.

2. The adequacy of the existing modeling approaches to the purpose of business modeling. For example, in recent years, it become a common practice to use object-oriented method as defined in object-oriented programming for designing application systems, technical, as well as nontechnical, i.e. business applications. Even if this definition might be acceptable for the technical system design, it’s not intuitive and hence is not appropriate for designing interactive business applications. For example, an employee object that has a method of calculating it’s own wages doesn’t make any sense from the application domain point of view.
3. The most effective way of building a system according to the complex business specifications (and may be the only possible one) is by having the application development tools that incorporate the model on which the specifications has been built. Manual translation of business specifications into technical design has much less chances for success because, normally, business specifications undergo substantial changes during the project lifetime. The tools will allow quick introduction and testing of all the modifications made in the model.
4. The language of formal models is useful for refining business specifications with management, but it might be inappropriate when talking to the workers on the floor. Management often knows the overall business process, but not the details. The latter should be obtained from the workers.
5. The workers would, naturally, know nothing about orgobjects, but they know their job. The conditions in which an application designer works are similar to those of a linguist who studies a language that exists only in the spoken form. Linguists have special methods permitting them to get the necessary information from the native speakers without teaching them any linguistic notions. Moreover, it's considered a wrong practice to teach informants linguistics, as it may only spoil them.
6. An application designer needs similar methods that would permit him to obtain the detail knowledge of business without introducing the workers into the world of operational goals, distributed planning, etc. We believe that rapid prototyping is the right method. As soon as an application designer has identified the company's operational goals and processes, and designed a model to represent them, he/she should make a prototype of the system and let the future users test it, converting the feedback from them into changes in the model.
7. Application development tools that incorporate all general notions of business model is the best way towards reusability. Even the companies in the same industry may choose different approaches to organizing business, that’s why it’s difficult to find specific pieces of code that could be used in many systems. That is one of the reasons why the 4GL tools, though often built on wrong business models, have won a considerable market. Extending the general model and tools with new metaphors while building actual specifications and application systems is the best way to reuse the work done in the past.
8. Practically, it’s impossible to create a model that covers all the peculiarities of the particular application domain. For a model to be useful for building applications, it’s enough if it covers the most important issues of this domain. Everything that is left outside can be programmed by hand. To cover everything that is left beyond the model, the application development tools that incorporates the model should be flexible enough to supply hooks where the code specific for the given application could be placed.