Businesses with more than a few employees have been organized into departments for some time.  Historically, as tasks became more complex the individual worker specialized.  From this, the logical step was to form departments consisting of people with similar areas of expertise.  This expanded into a tradition with a solid foothold in all types of organizations - commercial, public, and ideal.

Organizing people and work into departments provided and still provides, benefits:

• People specialized within their field of expertise, developing a highly refined set of skills.
• Costs from centralizing various functions were lowered (i.e., equipment costs).
• The workplace was made more secure; everyone knews where they belonged and which tasks to perform.
• The organizational structure was more clearly defined and could easily be drawn and presented.

With this in mind, it could be stated that the modern enterprises consist of functional departments, while at the same time performing processes.  Figure 1.1 depicts typical enterprise with its vertical departments and horizontal processes that run through these (Andersen and Pattersen, 1996).  It has lately become obvious that this contradiction between mode or organization and tasks has created several problems.

Figure 1.1 - The contradiction between vertical departments and horizontal processes.

• As soon as people have been established within a square in an organization chart it often seems as if the lines of this square become solid boundaries within which they must remain.
• Communication across the borders is limited, and members of a department will perform only those tasks that naturally belong to the area of responsibility of their department.
• Each department seeks to maximize its influence and authority while at the same time, optimizing the department's performance level.
• The result is usually that the whole is far from being more than the sum of the individual elements, and in the worst case, far less.
• Each department suboptimizes within its area of responsibility, which in turn leads to conflicting objectives and conflicting actions between different departments. The total performance level of the organization is naturally in line with this (Rolstada, 1995).

Trends

These problems, and others, have formed the basis for more recent changes--from viewing the company as a number of departments to focusing on the business processes being performed. 

Several issues make this a logical transition:

• Ever process has a customer, and focusing on the process ensures better focus on the customer.
• The value creation with regard to the end product takes place in horizontal processes.
• By defining process boundaries and the customers and suppliers of the process, better communication and well-understood requirements can be achieved.
• By managing the entire processes that run through many departments rather than managing individual departments, the risk of suboptimization is reduced.
• By appointing so-called process owners, who are responsible for the process, the traditional fragmentation of responsibility often seen in a functional organization is avoided.
• Managing processes provides a better foundation for controlling time and resources.

Many of these elements are based on the fact that every single process has both a supplier, and a customer as shown in Figure 1.2. This, so called customer/supplier mode is central in the thinking underlying the process view.

Figure 1.2 - Process with supplier and customer

Business process: business and process. First, look at the element of process. One basic definition of process is: "a logic series of related transactions that convert input to results or output." To separate a company's processes from any other form of process can be defined in a number of different ways, these notes based on the following definition (Ericsson, 1993):

• A chain of logical, connected, repetitive activities;

• that utilizes the enterprise's resources;

• to refine an object (physical or mental);

• for the purpose of achieving specified and measurable results/products;

• for internal or external customers

A main point is that any business process has a customer, either external or internal. Based on this definition, almost all activities within a company can be seen as a business process or part of a business process.

There are a number of ways to classify business. Many leading companies with respect to process orientation have conducted thorough analyses of their own enterprises and have compiled lists of a different number of processes. For example, both Xerox and IBM have made lists of a different number of processes. These lists are thus specially designed for the tasks carried out in these companies.

One method for self-assessment, and benchmarking a framework of business processes was developed, in line with the thinking of Porter's value chain. The processes were divided into primary and support processes. In addition, some of the support processes were further separated into a new class termed development processes. The three groups were defined as follows:

• Primary processes are the central and value-creating processes of the enterprise. They run straight through the company, from activities on the customer side to receiving suppliers from vendors.

• Support processes are not directly value-creating process, but rather activities needed to support the primary processes. This includes activities like financial and personnel management.

• Development processes are processes that are supposed to bring the value chain with its primary and support processes to a higher level of performance. Examples are product development and supplier development.

Before documenting one or more processes, be sure that the business processes of the enterprise have been identified. It is rarely obvious which processes are undertaken by the different departments in a functionally organized company.

Two complementary routes to such understanding can be utilized (Peppard, 1998). The most direct way is to simply generate a list of the business processes believed to be encompassed by the organization. Such a job will often be based on existing process descriptions or procedures written for ISO-9000 certification or similar purposes.

• The strategy of the organization, which defines, and is shaped by:

• Stakeholders (that is, organizations, institutions, or persons affected by or with a vested interest in the organization and its business processes) who hold:

• Expectations with regard to products or services delivered by the organization through:

• The business processes that produce these products or services, and support that enables the production of them.

By going through this set of elements and identifying them in sequence, it is much easier to point to the business processes carried out by the organization, and that are necessary in fulfilling the expectations of its stakeholders.

All organizations are able to articulate their strategy, and if not, they are certainly not ready to make the step into process orientation. Once the strategy has been articulated, the identification of stakeholders is relatively easy, even though these include more than the obvious ones (that is, customers).

Important stakeholders are also owners, employees, suppliers, governments, local community, and so on, and they all have certain expectation towards the organization. Determining these expectations is again usually fairly straightforward, even if it sometimes involves interaction with the stakeholders.

When all of these expectations have been identified, and preferably ranked according to importance, the identification of the business processes necessary to fulfill them can begin.

By nesting backward from the output to the stakeholders through to primary and support processes and input into these, several strings of business processes emerge.

Even if this approach does not cover every conceivable process ever performed by the organization, this is actually just as well. Processes not encountered when backtracking from the stakeholders' expectations are hardly crucial in providing satisfaction to them. Thus, if omitted, they will rarely be missed.

When the key business processes have been determined, the real work of documenting each single process can begin.

• Who are the customers of the process

• Who are the suppliers of the process

• What are the requirements for the input and output of the process?

• What is the internal flow of activities of the process?

2. Construct a flowchart

Before starting to draw a detailed flow chart of a process, it is often necessary to create a more overall picture of who are part of the process and what relations they have to one another and to the rest of the world. This is especially true for more extensive and more complicated processes involving a number of individuals or departments. Is the objective, for instance, to document the process of order receipt and delivery of goods to the customer? If so, it can be quite a challenge to put in place the separate steps of the process just like that. In such a situation, relationship mapping is a suitable approach as a first step on the way.

In contrast to an ordinary flow chart, a relationship map does not consider activities or the sequence of such. The map is constructed by placing on a blank sheet, the different units, departments or individuals expected to participate in or impact the process. For the process of order receipt and delivery, logical participants would be the sales, planning, production, and procurement departments internally, as well as customers and suppliers.

Finance department and external transport companies should be included. A general rule is that it is better to include too many elements, as irrelevant ones will be naturally eliminated throughout the process. It is also possible to draw such a map on several levels, so that each department can be further detailed on a lower level without blurring the overall picture.

After establishing the potential participants in the process, each relationship among them is analyzed to define the type of relationship. Different types of arrows are suitable for this purpose. Elements that in the end remain without any relationships to other elements are removed from the map. In the end, the map is redrawn and will give a good overview about relationships between participants and stakeholders in the process.

The objective is to improve and adjust the process documentation until mutual agreement is reached that it actually reflects how the process is being performed today. On the other hand, you should be careful not to spend too much time creating a very detailed and 100 percent correct depiction of the process. It might very well be that, reasonably good documentation achieved quite easily is better than one that is extremely resource demanding to generate, but is perfect. This must be seen in the context of the later use of the process documentation.

Figure 1.3 - Example of a High-level Relationship Map