The smallest unit of business activity of meaning to a user. When it is complete, the elementary process leaves the business area in a self-consistent state. That is, the business person has come to closure on the process and all the business information is in a static and complete condition.
Criteria for Elementary Processes
To limit the decomposition, find a level of business activity that has meaning to the business as an activity, has enough detail to be useful, and is not so detailed that an execution of it would not imply that something useful and complete had been done. The elementary process is a business job, usually done by one person, that cannot be stopped in the middle without missing some information needed for the next elementary process. For example, to make a telephone sale, the elementary process must gather both what the customer wants and where the customer needs the material delivered.
It is always possible to find elementary processes, but their content and level are dependent on the business area context. What is elementary in the context of one enterprise, or even one business area, could be too high level or too low level in the context of another enterprise or business area. For example, in some enterprises, TAKE ORDER may be elementary, whereas in other environments, ALLOCATE STOCK OF BOOKS and CHECK CUSTOMER CREDIT may be elementary.
Self-Consistent Business Area
A process that leaves the business area in a self-consistent state is one whose output is complete and meaningful in itself. For example, a process may be defined that calculates the value of an order by calculating and summing the value of its items. As long as the values of individual items are not required by other processes, a process CALCULATE ITEM VALUE does not leave the business area in a self-consistent state. It provides partial or intermediate results that are of no interest to the user until they are all calculated and summed to give the final order value.
Level
Self-consistency alone, however, is not enough to define an elementary process. Any process at a level higher than elementary must also leave the business area self-consistent. For example, a process TAKE ORDER might have ALLOCATE STOCK OF BOOKS and CHECK CUSTOMER CREDIT as elementary processes. The process TAKE ORDER would, therefore, not be elementary even though it leaves the business area in a self-consistent state. It is possible that a user would see TAKE ORDER as a complete, self-contained unit with no useful subprocesses. In this case, the process TAKE ORDER would be elementary. Note that the level is defined in the context of the business user.
Implementation Factors
The identification of elementary processes may involve considering how processes have been implemented, because the user's perception is in terms of current procedures that support the process. Such implementation aspects should be set aside, and the business requirements should concentrate on defining the elementary process. The BAA should define the business as it should be, not as it is.
Unit of Work
When you define an elementary process, you are saying that there is a user activity that must be completely carried out for the business area to be satisfied. This often corresponds to a unit of work within an organization. It is a task, often assigned to a single person, with measurable outputs and one that achieves some recognizable benefits for the enterprise.
Although an elementary process ideally corresponds to a single unit of work, it contains no consideration of how it will be achieved. The completion of the process could take an appreciable period of time. One aim of Business System Design will be to minimize this time. During the execution of the process, the business area may be inconsistent (i.e., certain business rules may be broken), and some entities may not be in recognizable states. When the process is completed, all business rules must be satisfied and all entities must be in recognized states.
Previous : Domain
Section Overview : Development Technique Concepts
Overview : Table of Contents
This page was last built on April 12, 1997.