Organizing Systems - a Tool for Process-Oriented Management

I.Bider

Abstract: A new approach to management of the routine work is presented - a process-oriented management which utilizes the unique opportunities offered by modern computers. It's a combination of the function-oriented and project-oriented management, and it could be briefly summarized as a project management without project managers, a project manager's functions of planning and supervising being distributed among the workers involved in a particular process (e.g., processing an order in a trading company, or treating a patient in a hospital). The key notions of the process-oriented management are "orgobject" - an entity containing information on the current state of the process, history, and dynamic and distributed planning. The process-oriented management requires a supporting computer system - an "orgsystem". An orgsystem provides high efficiency by assisting the workers in coping with practically all activities they perform, and by offering a user-friendly interface.

Keywords: groupware, management, office automation, orgobject, planning

From the author: Dear reader! This is one of our first writings devoted to the topic of business process orientation. Drafted in 1992 it was published by Auerbach in 1997. In no way do we want to discourage you from reading this manuscript. We hope, it can still be of interest for you. However, we want you to be aware of many other papers written and published by us in the last 15 years. For full list consult http://processplatsen.ibissoft.se/en/node/33. In particular, if you are interested in this paper, you might also be  interested to have a look on:
Khomyakov M., and Bider, I. Achieving Workflow Flexibility through Taming the Chaos. OOIS 2000 - 6th international conference on object oriented information systems. Springer, 2000, pp.85-92. Reprinted in the Journal of Conceptual Modeling, August 2001: http://www.inconcept.com/JCM/August2001/bider.html

At the time of a prolonged recession many companies and organizations are looking for new opportunities to reach a greater efficiency. One of the natural solutions is computerization. Computers can increase productivity in many ways, including the following two: assisting workers in completing their everyday activities, and providing the management staff with information needed for decision-making.

Decision-making requires two types of information: external information, e.g., on potential customers and competitors, and internal information - about the company itself. The external information can be purchase, but it may prove to be of little use without the internal information. And the latter may be obtained only if it's collected on a day-to-day basis.

To cope with the task of collecting a reliable internal information, an integrated computer system is required that could embrace all aspects of an individual's routine work. The routine work can be described as a number of operations that include:

• execution of simple activities, like writing a letter, taking an order, giving a medicine to a patient, etc.,
• registration of the activities performed;
• planning of new activities;
• communication with colleagues concerning the above activities.

A system supporting all these routine operations can automatically gather internal information to be further used as a basis for decision-making. Such system also helps to organize the bulk of individuals' everyday routines, that's why we refer to it as an "organizing system", or orgsystem, for short.

Orgsystems are not widely spread yet, but they are coming to the forefront. We strongly believe that any new computerization (or recomputerization) project should begin with building an orgsystem. At the later stages, statistical analysis and other types of information processing necessary for decision-making, e.g., expert system support, can be added. (The reversed order of computerization would lead to, e.g., an expert system having no access to reliable internal information.)

One of the goals of an orgsystem is to coordinate the efforts of many people working together. This conditions the use of some underlying management scheme. One can choose to adopt one of the existing management schemes, or to create a new one. We believe that the real benefit of using an orgsystem can be obtained only if it is based on a new management scheme - the one that fully utilizes computers' ever increasing power. Such management scheme can activate hidden efficiency reserves, and stimulate the workers. Moreover, it can structure the internal information gathered by the orgsystem in a way that gives much better support to decision-making than a traditional management scheme.

One of the main problems that each enterprise faces is to organize the efforts of the people working on common goals. Most of the solutions to this problem originate from the time before computers became available for practically any company. However, it's a general practice even now, that the developers follow the old management scheme when the company is being computerized, whereas modern computers offer unique opportunities for implementing new, far more effective approaches to management.

We discovered the limitations of existing management schemes while computerizing a small trading company. Our objective was to develop a system able to assist the office workers in all aspects of their routine work. One of our tasks was a conventional one - to support such activities as taking orders, delivering goods, making a phone call, etc. The other one was more ambitious - to register all completed activities and to help plan new activities based on the completed ones.

We realized very soon that our second objective could not be achieved within the functional management scheme adopted in the company. To cope with our task 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 a result a new approach to management was developed which we call a process-oriented management. This approach 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.

The main point with the process-oriented management is that it permits a company to gain full control over all the processes within the frame of the existing, often functionally-oriented, organizational structure. This type of management facilitates also the communication between the workers involved in the same process, and it provides them with actual information on the state of the process, as well as on all activities performed and planned. Below, we present the main ideas of the process-oriented management, and the requirements for a computer system needed to support it. We tried our best to do that in a very informal way to make it easily understood by all concerned. It should also be mentioned that the author is not a specialist in the field of management, but he worked with experts on management throughout the project. The paper reflects a fresh view of an application developer not spoiled by the experience of the pre-computer management era.

The rest of this paper is organized as follows. In section 2, we outline our view on the management of routine work. In section 3, we present the main principles of the process-oriented management. We look at existing approaches to management of the routine work - the function-oriented management and project-oriented management, and then move on to describing the ways of transforming the project-oriented management into the process-oriented one. We discuss the process-oriented management without regards to computer systems, however, this type of management can't be implemented without computers. Requirements for a computer system designed to support the process-oriented management are discussed in section 4. In section 5, we discuss the major issues of the development and implementation of such systems. In section 6, we present a short summary of our practical and research work that lead to the development of a process-oriented approach to management.

2. Management of Routine Work - Objectives

It's generally recognized that the main objective of management is to ensure a successful achievement of a company's goals at minimal costs. A company has several different types of goals to achieve at any given moment - long-term, short-term, etc. As we are concerned with the management of routine work, it's the "conventional" everyday goals that are of primary interest to us; we call them "operational" goals. A typical operational goal for a trading company is, for example, to "drive" an incoming order through a delivery to receiving payment within certain time limits. A typical operational goal for a hospital is to administer the appropriate treatment to a patient that would lead to his discharging from the hospital. A typical operational goal for a software development company is to build a software system according to the specifications. But for the section of technical support of such company, a typical operational goal is to process a bug report so that the bug is fixed or/and a work-around solution is found.

Though operational goals may be quite unsophisticated, they, nevertheless, constitute the backbone of any business, as they have to be achieved on a day-to-day basis to ensure the proper functioning of the company. The character of operational goals depends on the type of business, but they have a number of common features:

• operational goals pop up more or less regularly;
• there is, usually, a standard procedure for achieving the operational goals of a given kind, which doesn't mean, of course, that a particular goal can't be approached in a different way if needed;
• there is often a set time limit for achieving an operational goal. If the goal is impossible to achieve within the time limit, it is discarded in a standard way.

To achieve an operational goal, a series of activities should be completed. For example, a series of activities aimed at getting payment for an incoming order includes delivery of goods and sending an invoice to the customer. This series may include more items in certain circumstances, for example, if the ordered goods are out of stock, they should be produced or ordered from the suppliers.

The activities aimed at achieving an operational goal are not, usually, executed immediately one after another, e.g., if the ordered goods are out of stock, it takes some time to get them from the suppliers. The execution of these activities is a process that continues over some period of time. The main objective for management of operational goals is to ensure that this process results in achieving the goal. 

Different activities concerning the same goal can be completed by different workers from different divisions. Another objective of management is, therefore, to coordinate the work of all workers participating in the process of achieving an operational goal.  

Approaches to management of operational goals may be divided in two types - function-oriented and project-oriented. The function-oriented management (Fn-management) is usually used in the environments where a lot of relatively simple operational goals pop up very frequently. The Fn-management implies that operational goals are handled in a routine manner by the staff where each member has his own function in achieving operational goals. A manager does not coordinate the execution of activities for each goal, workers just react on the incoming documents, phone calls, etc., by completing activities they are assigned, and forwarding the received or newly composed documents further to their colleagues. 

The project-oriented management (Pj-management) is usually used with more sophisticated goals such as construction or software projects. The Pj-management implies that a process for a new goal is planned in detail before the work on it starts, and there is someone (e.g., a project manager) who supervises all the work being done.

Fn-management is most cost-effective, but it works poorly when a process of achieving an operational goal deviates from a standard pattern, as it lacks control over individual processes. Pj-management gives full control over an individual process, but it's inefficient when a lot of coexisting processes are involved. There are working environments where one or the other type of management fits well. But in most environments a combination of these two approaches would be the way to obtain both full control over all processes and efficiency.

Below, we discuss our proposals for integration of the Fn- and Pj-managements. The result is a new type of management which we call the process-oriented management, or Pc-management, for short. This name highlights the main objective of the Pc-management - to control the processes, in contrast to Fn-management that places the emphasis on the execution of activities, and the Pj-management that emphasizes plans. We describe the Pc-management here in the following way. We consider an environment typical for the function-oriented management - a trading company, and try to introduce the project-oriented management in it. The process-oriented management is presented thus as a result of tailoring the project-oriented approach to fit a different kind of environment. We find this way most convenient for discussing our ideas, but it's not, naturally, the only possible one.

The Pc-management is based on the notions of "orgobject", "history" and "dynamic and distributed planning", which we can now turn our attention to.

The Pj-management involves developing a detailed plan for achieving a project's goal before the work on the project can start. This plan is premised on certain assumptions that may turn out wrong after the project is under way. The plan should then be adapted to the changed conditions. For this purpose, a clear picture of the current state of the project is required to figure out what should be done to complete the project.

A project often involves developing some product that is a physical object, e.g. a software system, a building, etc. This product comes into existence in some form already at the earlier stages of the project, e.g. a half-ready software system or a building under construction. This half-ready product serves as a good representation of the current state of the project. As the half-ready product can be studied without regards to how it has been produced, the plan can be revised without going into details of the project's history.

In cases where the Fn-management is involved, there is no half-ready product to represent the current state of achieving an operational goal. A kind of an abstract object that contains all information on the current state of the process would be helpful here. As it would serve as an organizing device for achieving the goal, we call it an "orgobject".

For example, an orgobject representing a process of "Get payment for an incoming order" may be a record that contains information on: the name and address of the buyer, a description of each kind of goods ordered, the quantity and price per unit of each kind, the quantities of goods already delivered; the amount of money invoiced; the amount of money received. Having this orgobject, the conditions for the successful achievement of the "get payment" goal could be formulated as follows:  

• have the numbers representing the quantities of 'goods ordered' and 'goods delivered' equal for each goods kind,
• have 'money invoiced' equal to the sum of 'ordered' multiplied by 'price per unit' for all goods kinds, and
• have 'money received' equal to 'money invoiced'.

As the process develops, the corresponding orgobject should change so that it reflects all the time the current state of the process. As soon as some activity is completed, the orgobject representing the process is to be modified. Thus, in the above example, after the delivery (full or partial), the quantities of the goods delivered are modified; if the customer has changed the order, the types and quantities of the goods ordered are modified, etc. To ensure that the orgobjects are always up-to-date, the routines for every type of activity should list not only the operations required for completing the activity (e.g., packing and shipping for delivery), but also instructions for the appropriate modifications of the relevant orgobjects.

Thus, the current state of an orgobject reflects the overall result of all activities completed earlier, and shows what actions should be taken to achieve the goal. To return to our example, if the quantity of the goods ordered is greater than the quantity of the goods delivered, the missing goods are to be delivered. If, on the other hand, the quantity of the goods ordered is less than the quantity of the goods delivered, then the customer should be asked to return some of the goods. Other examples: if the amount of money invoiced exceeds the payment received, then the customer should pay the difference. If the amount of the money received exceeds that of invoiced, then a credit note should be issued.

The current state of an orgobject contains only the result of the completed activities, but not a list of them, e.g.: the quantity of the goods delivered, but not the number of separate deliveries; the amount of money invoiced, but not the number of separate invoices, etc. This is OK if all goes as it should. But if something goes wrong, e.g., some goods sent off did not arrive, then the information on all activities performed is vital when figuring out what actions should be taken. This information can be collected through logging all the activities completed in the frame of the given process.

Let's consider the following logging scheme. Every time a worker executes an activity, he/she doesn't physically change the previous state of the relevant orgobject. He/she makes a new record instead which contain the new state of the orgobject and leaves the former one unchanged. For example, after a delivery, a new record is made containing the same information as the previous one except the information on the quantities of the goods delivered. The latter is updated according to the packing list.

The record on the previous state of an orgobject is placed in a special file containing the history of the given orgobject. The worker who completes an activity composes also a report where he/she records: the kind of activity completed, the name of a person who completed it, the date, time, comments, etc. This report is saved together with the previous state of the orgobject in the history file.

Given two consequent states of an orgobject and an activity report, we can reconstruct exactly what happened during the activity execution. For example, in case of delivery, we know exactly by whom and when the goods were delivered, and in what quantities. Thus, our log provides an easy access to the information on both the activity performed, and the state of events before and after it was performed.

As it was mentioned above, the Pj-management involves designing a detailed plan for each new process. If we try to apply the same to a Fn-management environment, two problems would arise:

• as Fn-processes are often trivial, their plans would be trivial too, e.g.: 'delivering goods' - 'invoicing the buyer' - 'getting payment'. It would be meaningless to record such plan for every process (and there are many in this kind of environments),
• unpredictable external events that often occur in Fn-management environments would demand revising the whole plan, e.g.: a customer has changed his order - additional delivery can be required, an invoice is to be sent later than it was initially planned, etc.

Dynamic planning is our answer to these problems. 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 (and standard routines adopted in the company). For example, after a delivery, another delivery is planned if not all ordered goods have been delivered, or invoicing is planned if all goods have been delivered.

The use of dynamic planning is fully beneficial in case of processes that follow a standard pattern. Otherwise, the usual planning is preferable. In case the character of the process (standard/deviating) is difficult to foresee, dynamic planning can be used at first, followed by conventional planning if necessary.

Another poser when trying to introduce the Pj-management in an Fn-environment is how to supervise a process. In cases where the Pj-management is involved, there is usually a project manager who supervises the execution of planned activities, and corrects the plan if needed. In an environment typical for the Fn-management, a project manager supervising each process would result in significant overheads.

A solution to this can be described as "distributed planning". Distributed planning implies that the worker who has completed a planned activity himself plans the subsequent activities. Moreover, he/she can assign these new activities not only to himself, but to other people too. For example, a worker who completes a delivery himself plans invoicing to be completed by another worker.

Distributed planning doesn't exclude the possibility of a centralized supervision of a process. In fact, a supervisor may intervene at any time and correct the plan if needed. Moreover, any member of staff can consult the supervisor in case he/she has some problems with his/her work on a particular process. He/she can do it by planning a special activity, e.g., "asking for help", and assigning his/her supervisor to complete it.

Let's have a look at the issue of implementing dynamic and distributed planning. Above, we considered orgobjects and plans as separate entities. Now, we put a plan inside the orgobject representing the corresponding process. As a result an orgobject besides the information on the current state of the process (e.g., on the customer, goods, delivery and payment) will also include a list of planned activities (e.g., delivery, invoicing, etc.), each of them containing information on what should be done, who's to do that and when.

Thus, a plan becomes part of an orgobject. Consequently, we can treat correction of the plan as one of the operations of changing the orgobject in the course of completing an activity. In section 3.1, we've already mentioned that instructions for modifying orgobjects should be included in the working procedures for each type of activities. To ensure proper dynamic planning, these instructions should embrace modification of the process's plan. In a simple case, a worker who has completed an activity modifies the relevant orgobject by removing this activity from the list of planned activities. In more complex cases, he/she adds new activities to the list, and/or removes some other activities from it.

Being an integral part of the orgobject representing a process, a plan is subjected to the logging we described above. As a result, all acts of replanning are registered in the same way as other modifications of orgobjects. Thus, for example, the name of a person who modified the plan is recorded, which may prove to be useful in case of conflicts.

The main advantage of the Pc-management is its flexibility. The Pc-management 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 Pc-management 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:

1. Orgobjects provide a perfect insight into the company's state of affairs. The information stored in the orgobjects is of great help to the management staff as it permit to quickly evaluate the state of a process (without going into its history). It also helps to give prompt answers to customers' questions.  This kind of information is not easily obtainable when traditional managements schemes are used. Thus, when the Fn-management is used, only the information on the executed activities of a given type is easily accessible, and when the Pj-management is used, only the information on the state of the plans execution is easily accessible.
2. Histories of orgobjects permit to easily trace all the activities completed on a given process, which helps to devise plans for complicated cases. They are also a very important source of data for all kinds of statistical analysis, and other types of information processing required for decision-making.
3. The company's 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 a process he/she is involved in. The history of old orgobjects is useful for "learning by example", which may help a worker to find solutions in difficult cases. The goal- and process-consciousness isn't easy to acquire with a traditional management scheme. Under the Fn-management, a worker doesn't see how a process he/she's in is accomplished. His/her personal goal becomes to complete as efficient as possible the activities he/she is responsible for. That may result in, e.g., a seller concentrating on making telephone calls most of which don't get him to closing a deal.
4. The Pj-management emphasizes following the schedule, which becomes the main goal of the workers engaged in a project. There is a danger that the workers do not keep their eyes open for changes in the surrounding world, which is, e.g., the main reason why large software projects often produce out-of-day systems.  
5. As all the information on the past is being stored, the management staff is in a better position concerning various kinds of conflicts, internal conflicts among workers engaged in the same process, and external ones, e.g., with customers or suppliers. 
6. Distributed planning is a very powerful tool for coordinating the work which makes unnecessary the intensive communication (exchanges of documents, phone calls, etc.) among the workers engaged in the same processes. They get the required information from the current states of orgobjects and their histories.

Let's imagine you are fascinated by the Pc-management and decide to implement it in your company. A lot of orgobjects start circulating around, each accompanied by a huge history file. You don't find the one you need, you never know which of the orgobjects contains the planned activities assigned to you, and when these activities should be completed. You strove for a better order and got yourself into a mess. And, as if that were not enough, you have a lot of extra work to do. You should construct a new state of an orgobject for each completed activity, and remember to put the new activities on the list and assign them to yourself and others. You wanted to improve the efficiency, but it sinks instead.

There is no need to worry, there is a means to restore the order and efficiency, and that's, naturally a computer system. It's primary aim is to make you happy with the Pc-management doing away with the chaos, that's why we call it an "organizing system", or orgsystem for short.

Let's have another look at the Pc-management, this time supported by an orgsystem. Orgobjects do not circulate between various members of the staff who are to work with them, they stay in the same place together with their history and plans, and are easily accessible to all workers involved. All planned activities assigned to a given individual appear immediately in his/her personal calendar, so that each worker knows exactly what activities he/she has to complete and when.  

An orgsystem provides the means to increase the efficiency by:

• assisting workers in executing each activity,
• providing an extremely user-friendly interface.

These two features are a key to successful implementation of an orgsystem. Without them people would not be motivated to use the system, consequently the Pc-management wouldn't work. Let's look at these features in more detail.

All operations needed for executing an activity under the Pc-management belong to one of the two groups:

• external operations - operations that affect the "external world", and
• maintaining operations - operations aimed at maintaining orgobjects.

The character of external operation depends on the type of activity, e.g., packing and shipping for delivery, programming and testing for developing a software module, etc. Maintaining operations are the same for all activities. They include:

• updating the information contained in the relevant orgobject,
• correcting the plan,
• logging the preceding state of the orgobject.

An orgsystem assists a worker to complete both the external operations and the maintaining ones.  

1. External operations. Level of help which is possible to offer for completing the external operations depends on the type of activity. For example, programming and testing of a software module are usually performed inside the computer, and they are already fully computerized. Here, an orgsystem should just integrate the existing tools for software development, e.g. editors, debuggers, etc., so that a proper tool is invoked when a user chooses to execute these operations.  Packing and shipping are not that easily computerized, not now anyway. But even there, an orgsystem can be helpful to some extent by, e.g., making up a packing list. It's important to give a hand in completing the external operations for each kind of activities. There's a risk otherwise. If some activity is left without the orgsystem's assistance, a worker who completes it can easily forget to make the appropriate changes in the orgobject concerned. In that case, the completed activity will still remain on the list of planned activities and the orgsystem will keep reminding the worker to complete it. There is also a danger that the same activity will be completed several times.
2. Updating. Modification of an orgobject can often be done on the basis of the information collected in the process of executing the external operations. For example, an "order" orgobject contains the information on the quantities of the goods already delivered. This information should be updated after each separate delivery. The new quantities can be easily calculated based on the packing list that was made at the previous step, which permits an orgsystem to update the orgobject without assistance from the users.
3. When correcting a plan, a worker is prompted by the system on the appropriate activities to plan next; in simple cases the plan is corrected by the system itself. This is possible, as an orgsystem possesses two type of knowledge:

• on the working procedures used in the company, which helps to plan new activities, and
• on division of responsibilities between different divisions, sections, and workers, which permits to correctly assign new activities.

4. Logging includes two operations: 

• saving the old state of the orgobject, and
• making a report on the activity completed.

Saving the old state of an orgobject is done by an orgsystem without any user assistance, but an activity report needs a human participation. Even there, an orgsystem helps by automatically supplying the information on what activity has been executed, by whom and when. The rest of the report, e.g., comments, is of course the responsibility of the worker.  

Conventional computer systems are designed as a set of functions operating on a common database, the main facility of the user-interface being multilevel menus. This type of the user-interface provides the user with a quick access to a function he/she wants to complete. It reflects the objective of a conventional computer system which is to help workers to cope with single activities like updating information, printing a report, etc. An orgsystem objectives are much wider, which brings about the need for a completely different kind of user-interface.

 An orgsystem's user-interface permits end-users to freely choose between the object-oriented and activity-oriented way of working with orgobjects, as well as easily switch from one to the other. The object-oriented approach is applied when a user wants to work with a particular orgobject for a longer time. In this case, he/she may need to look at the object's current state and its history, as well as to plan and execute various activities involving the orgobject. The activity-oriented approach is applied when a user wants to complete the same activity for a number of orgobjects. In this case, the dialogue designed for a given activity is repeated for all relevant orgobjects.

The object-oriented way is particularly useful when one worker is responsible for many activities involving an orgobject. It is also the way that management staff can use when there is a need to evaluate the state of a particular process and to devise a plan for a difficult case. The activity-oriented approach is preferable if a worker is responsible for only one type of activities. It's also the right approach to completing simple activities that do not require much human assistance, e.g., printing an invoice, etc.  

Another distinguishing feature of an orgsystem's user-interface is that it maintains personal calendars. A personal calendar is a list of activities assigned to a particular worker. The point is that these activities are included in different orgobjects and the calendar permits a perfect overview of a persons' many tasks. The orgsystem offers a variety of ways to use the calendar. A user can browse through his/her calendar, or some parts of it, e.g., to see all activities planned for a particular day, all activities of a certain type, etc. When browsing, he/she can start the execution of his/her activities (activity-oriented approach), or move to the orgobject where a particular activity belongs and start working with this orgobject in the object-oriented manner.

To maintain its user-friendly character, an orgsystem's user-interface should satisfy a number of general requirements. Most important are the following two:  

• easy access to all information required for working with orgobjects. For example, when working with an orgobject representing an order, a user should have access to all information related to the customer who ordered goods: his address, previous contacts with him, etc.;
• consistency. There should be standard procedures for navigating to an orgobject, for getting information (e.g., a company's address), for planning, for starting the execution of activities, etc. These standard procedures should be the same for all types of orgobjects and activities.

5. Joys and Hardships of an Orgsystems Developer

There are, naturally, technical problems to solve in the development of an orgsystem. The system requirements discussed in the previous section must be met. However, an orgsystem designer's greatest problem is that he starts the development in an environment initially not based on the Pc-management, which makes both design and implementation of an orgsystem far from trivial tasks.

An orgsystem designer should begin with:

• identifying the company's operational goals,
• figuring out what processes are used to achieve them, and
• designing orgobjects to represent these processes.  

His/her next task is to review all the working procedures and tailor them to fit the Pc-management scheme (by adding maintaining operations to each activity). This is often a tough job, as there are seldom some written descriptions of the working procedures, and if they exist, they are far from complete. The only way to cope with the job is to try and get the missing information from the company's workers.

The workers would, naturally, know nothing about orgobjects, but they know their job. The conditions in which an orgsystem 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.

An orgsystems designer needs similar methods that would permit him to redesign the company's working procedures without introducing the workers into the world of orgobjects, distributed planning, etc. We believe that rapid prototyping is the right method. As soon as a designer has identified the company's operational goals and processes, and designed the orgobjects to represent them, he/she should make a prototype of the system and let the future users test it.

To be able to use prototyping, an orgsystem designer needs appropriate application development tools. These tools should allow him to quickly produce a sketch of the system that has "look-and-feel" of a real system, but lacks processing routines and database access. It's this sketch that we call the prototype of the system. Working with it, a user can navigate among orgobjects in the same way as he would do that when the orgsystem is ready. He can modify existing orgobjects, create new ones, and see how to start different activities. But he can't save the information or see the results of the completed activities.

After the future users have accepted the prototype, the designer can stepwise add database access and processing routines, which would be also done with the help of the above mentioned application development tools.

Implementing an orgsystem means introducing the Pc-management in a non-Pc-management environment. This may be achieved in one of two ways:

• by substituting all the old working procedures in the company at once, or
• by gradual introduction of the new working procedures.

The first approach may suit small companies whose workers often switch from one activity type to another. An orgsystem would help to do these switches very quickly, and it would help the workers, who usually have a lot of different things to do, to preserve the order in their affairs. The staff of a small company would easily understand the advantages of using all facilities provided by an orgsystem: object- and activity-oriented ways of working, personal calendars, easy access to the history, etc.  

However, in case of large companies, the second approach may be the best choice. Large companies usually, have a lot of workers who are involved only in one or several activities for each process. These workers may believe that an orgsystem is too complex for their simple tasks. It would be difficult for them to see the advantages of the object-oriented user-interface, and their earlier experience of traditional computer systems can only make the things worse.

Luckily, an orgsystem provides a means for working in the activity-oriented manner, which would put the workers competing simple activities at ease. There would be no problem to teach them to use the orgsystem in the activity-oriented way, because it resembles their old manner of doing things. Later, the workers could be taught the object-oriented way as well, which would give them better possibilities to take the initiative and find solutions for difficult cases. But even if most of the office workers continue to use the activity-oriented approach, there would always be some key people who benefit from the object-oriented approach, e.g., management staff. 

6. Concluding remarks  

The notion of the Pc-management came into being when the author together with several colleagues developed an application for supporting sales and marketing activities of a trading company. The system was called "DealDriver" to highlight that it helps the workers to "drive" the deals to the end which is receiving payment. Deals were thus the first type of orgobjects designed. The work on the project started in spring 1989, and the first version of DealDriver was ready in summer 1990. Since then, Dealdriver has been successfully used at our home office to support one of IbisSoft's business activities - reselling of professional software.

The DealDriver project, gave us some valuable insights into the problems of orgsystems development which are summarized in our internal reports [1,2]. We developed also an experimental version of application development tools to support orgsystems development. These tools were later used for building both prototypes and functioning systems in a number of other application fields, e.g., hospital administration.

Next two subsections discuss some theoretical and technical aspects of orgsystems development. The reader who is not interested in such issues is invited to look over these.

Orgsystems development belongs to an application field called groupware, see, for example, [3,4]. This is a multidisciplinary field where social scientists and computer scientists work together. Some of the computer science fields related to our work are as follows:

• the behaviour of dynamic objects, where the orgobjects belong, is being formalized by the theory of object-oriented systems, see, for example, [5];  
• methods of storing and accessing structured information, which are vital for orgsystems development, are the subject of the database theory. Particularly related to our work are the theories of semantic databases (see, for example, [6]), object-oriented databases (see, for example, [7]), and temporal databases (see, for example, [8,9]);
• methods of planning for robots are one of AI's (Artificial intelligence) favorite research problems. The results obtained there may in some cases be directly applied to the management field. For example, the difference between classical and reactive planning (see, for example, [10]) corresponds to the difference between the pure Pj- and Fn-management.

The main ideas of the Pc-management originate from our previous research work on the CHAOS project [11,12] (CHAOS stands for Concurrent Human-Assisted Object Systems). The project's objective was to work out a formal model for describing distributed interactive systems. This model is based on the notions of objects and connectors.

Objects are used to represent the elements of the "real world", (e.g. people, companies, projects, etc.), whereas connectors are the active elements of the system whose task is to make changes in the objects. A connector may be thought of as a little computer connected to one or several objects. As soon as some of these objects change, the connector changes all the other objects to restore the consistency of the system.

Thus defined, our model has a purely reactive nature, i.e. changes in objects are made as a reaction to changes in other objects. But objects in our model can be complex, i.e. they themselves can contain connectors, which means that a reaction can result in adjusting the system configuration to changes in the environment.

The CHAOS model fitted the management field so well that all we had to do was to use another set of terms. Thus, complex objects became orgobjects, connectors became planned activities, and the principle of reactive reconfiguration of the system was called dynamic and distributed planning. Some of the results of applying the CHAOS model to management field were virtually the same as those from the research works based on the theory of planning (see, for example [13]). However, being more general than the theory of planning, our model provides a better framework for management automation as it covers all aspects of management not only the issues of planning.

The CHAOS model is abstract, but the approach taken in the DealDriver project was very pragmatic. The objective of the project was to create a working system, not to speculate on the management automation issues. This project differs in many ways from similar research projects. Below we list the most important differences:

1. Computer environment. We worked with PC computers under MS DOS in stand-alone and network versions, whereas research projects are often completed on Unix-based workstations. We used text-based terminals, not a graphic-based windowing environment with a mouse, icons, etc. This environment was chosen because it was the one an average company could easily afford.
2. Development tools. Research workers often choose programming languages popular among computer scientists like Lisp, Prolog, Smalltalk, etc. These languages have a sound theoretical basis (e.g., function theory, logic, etc.), but require a lot of programming when they are used for the development of an application. We made a point of getting the maximum available help with programming by employing commercially available application development tools. We chose JAM from JYACC as a front-end tool, and Btrieve from Novell as a record manager. These tools were of great help to us, as we had limited resources for completing the project (in terms of time and manpower).
3. Design principles. Researchers are often far too interested in the technical issues, such as methods of software design and programming, etc. We concentrated on user-interface issues instead. Our only principle of programming was: a program should work and permit to easily make necessary changes. All programming was done in C-language, and though our system was object-oriented in a very high degree, we didn't use any object-oriented extension to C.

Thus, two factors contributed to the successful completion of the DealDriver project:

• the use of a powerful abstract model, and
• a pragmatic approach to system development,

and we strongly believe that both of them are obligatory for the development of a computer system of a totally new kind.

We are also convinced that there is no need to wait 10-20 years, which it usually takes for new research ideas to be implemented in application systems. New ideas can be implemented today and with the means available now.  

As the main ideas of the process-oriented management came from the CHAOS and DealDriver projects, the author is very grateful to all who participated in them, especially: A. Borkovsky, M. Khomyakov, E. Pushchinsky R. Sjöborg and R. Svensson. I'm also very much indebted to Claudia Dobrina for her comments and help with editing and correcting this text.

Note: Btrieve is a registered trademark of the Novell Inc., JAM is a registered trademark of the JYACC Inc., and MS DOS is a registered trademark of the Microsoft Corp.

1. Bider,I. ObjectDriver - a Method for Analysis, Design and Implementation of Interactive Object- and Time-oriented Systems. Internal report. IbisSoft ab, Stockholm, 1991.

2. IS-Maker - Software Tools for Building Interactive Object- and Time-oriented Systems. Internal report. IbisSoft ab, Stockholm, 1991.

3. Ellis,C.A., Gibbs,S.I., Rein,G.L. Groupware - Some Issues and Experience. Communications of the ACM 34, 1 (January 1991), 39-58.

4. Hayes, F. The Groupware Dilemma. UnixWorld, February 1992, 46-50.

5. Ehrich,H.-D., Goguen,J.A., Sernadas A. A Categorial Theory of Objects as Observed Processes. In Proceedings: Foundation of Object-Oriented Languages. REX School/Workshop (Noordwijkerhout, The Netherlands, May/June 1990). Ed: J.W.deBakher, et all. pp. 203-228.

6. Hull,R., King. R. Semantic Database Modeling: Survey, Applications and Research issues. ACM Computing Surveys, Vol. 19, No 3, 1987, pp. 201-260.

7. Bertino,E., Martino,L. Object-Oriented Database Management Systems: Concepts and Issues. Computer, April 1991, pp. 33-47. 8. Snodgrass, R. The Temporal Query Language TQuel. ACM TODS 12/2 (June 1987), 247-298.

9. Ariav,G. Temporally oriented data definitions: Managing schema evolution in temporally oriented databases. Data & Knowledge Engineering. No 6, 1991, 451-467.

10. Downs,J., Reichgelt, H. Integrating classical and reactive planning within an architecture for autonomous agents. In Proceedings: European Workshop on Planning (1991). Ed.: J.Hertzberg.

11. Bider,I.G., Khomyakov,M.V., Pushchinsky,E.V.: CHAOS - Modelling Environment. ISR AN. Internal report No 1. Moscow, 1986, 70 p.

12. Bider,I.G., Khomyakov,M.V., Pushchinsky,E.V.: PRO - a Programming Environment for Designing Orgsystems. Manuscript, Moscow, 1987, 14 p.

13. Lutze,R. Customizing Cooperative Office Procedures by Planning. In Proceedings: Conference on Office Information Systems (1988),. Ed.: Robert B. Allen. pp. 63-78.