The Data-flow View of Processes
Another traditional view of business processes is through data flows, where processes are seen as data processing entities. Data-flow representations have been largely used in the 1980s by systems analysts as an important component of what are known as structured systems analysis and design techniques (Davis, 1983) - a predecessor of the object-oriented analysis and design approach (Somerville, 1992).
Data-flow representations have been used chiefly to understand the flow of data within processes and, later, to automate this flow "as is" rather than to redesign processes. This "automation-of-old-processes" approach has been the target of strong criticism in the early 1990s and has often been described as the main cause of the low return on investment in information technology (IT) observed in both the 1970s and 1980s. The service sector has been particularly affected by IT's low return on investment, which has steadily declined to even negative figures; and IT investment has led to a decrease in productivity in a number of service industries, such as banking and insurance (Hackett, 1990).
Like the work-flow view of processes, the data-flow view can be expressed through a family of graphical representations, from which the most widely used is the data-flow diagram (DFD) (Gore and Stubbe, 1988; Pressman, 1987).An example of a DFD obtained from the analysis of the flow of data between the restaurants and the central kitchen of an Italian restaurant chain is shown in Figure 2. In this figure, a rectangular shape represents a data source or destination - the restaurant manager and the central kitchen manager functions.Arrows indicate the flow of data, which are described by freestanding text located beside the arrows. Oval shapes represent activities. Open-ended rectangles represent data repositories.
Figure 2. "Fulfill
Order" Process of a Central kitchen at an Italian Restaurant
Adapted from Kock (1995,
The process mapped through the DFD in Figure 2 starts with a chain restaurant manager, who tells the manager of the central kitchen, where all dish items are prepared, that the restaurant is short of some specific items (e.g., Bolognese sauce, spaghetti, Italian bread). The manager of the central kitchen then fills out a form, specifying what items are out-of-stock and which restaurant needs them. This form is then placed in the assistant manager's in-box.Approximately every 2 hours, the assistant manager of the central kitchen goes through the forms in the in-box, generates the orders to be prepared by the cooking team, and stores the orders in the out-box. When scheduling, the assistant manager tries to optimize the work of the cooking team by grouping requests that require the same resources (e.g., ingredients, cooking equipment). The cooking team then collects the orders from the assistant manager's out-box and prepares the Italian dish items ordered on a first-come, first-served basis. They also pack and stock these items in the delivery room as soon as they are ready. Delivery forms are filled out and attached to each of the packaged items for the restaurants, which are periodically delivered by the central kitchen's delivery team.
Although an incomplete model of real processes, representations based on the data-flow view of processes, such as DFDs, show the flow of data and how it is stored in a relatively clear way. As such, one can reasonably expect these representations, in some cases, to be more appropriate than representations based on work flow, such as flowcharts. This is true especially in the analysis of processes where the flow of data is particularly intense.
A dramatic increase in the flow of data has been predicted as one of the characteristics of today's and the near future's economy, particularly in the developed and developing countries (Drucker, 1989; Toffler, 1970; 1991). Hence, it is reasonable to expect that representations based on the data-flow view of processes become more useful in process improvement attempts than representations based on the work-flow view. As mentioned before in this chapter, the latter type of representations tend to provide a poorer picture of the flow of data, preventing the identification of, for example, data "buffers." Data buffers are organizational functions (rectangular shapes in DFDs) that perform the job of transferring data among other organizational functions. In a given process, these "buffers" are,
therefore, strong candidates to be removed from the process and replaced by information technology applications. This is the case in Figure 2, where the function central kitchen manager acts as a buffer between the restaurant manager and the assistant manager of the central kitchen. In the process analyzed, the manager of the central kitchen receives data from the restaurant manager and stores it in a data repository that will be used as input by the assistant manager of the central kitchen to generate an order. A more efficient version of the process would have the restaurant manager storing this data with no mediation of the manager of the central kitchen, who could use that time to do other things.
How much detail should be in the diagram when mapping processes through either flowcharts or DFDs? The activities in a process representation can be seen as subprocesses themselves, which can, in turn, be broken into new activities. In fact, seeing the activities of processes as lower-level processes and generating more-detailed diagrams by "exploding" these lower-level processes is a common practice in both flowcharting and DFD generation (Davis, 1983; Maull et al., 1995; Pressman, 1987). In doing so, however, two simple guidelines are suggested (Kock and McQueen, 1996):
- Each graphical representation of a process should
not have more than 14 activity symbols.
- In a process improvement context, the breadth of improvement sought should define the level of detail when modeling processes.
The first guideline is based on studies about general human cognitive limitations relating graphical representations and diagrams used in systems analysis and design (Kock, 1995a). The second guideline is based on a relatively new concept - the breadth of process improvement (Hall et al., 1993). Roughly speaking, the breadth of improvement correlates the number of different departments or distinct areas affected by process improvement decisions. The larger the breath of improvement, the less process detail is necessary. If one wishes to improve processes that cut across several (perhaps all) of the departments of an organization, the process representation should comprise little detail about subprocesses that belong to individual departments. As a general rule of thumb, the total number of high-level processes used to effectively represent any organizational unit can be anywhere between 10 and 20 (Hammer and Champy, 1993; Maull et al., 1995).