CHAPTER 3

Modeling Integrated Information and Processes

If we want to understand the relationship between the services or products our business produces and the information that those services or products require for our business to be successful, then some modifications to the classical process modeling approaches are necessary. For the discussion in this monograph we will restrict our use to the classic block diagram commonly used for product manufacturing processes, a service blueprint used for modeling service processes, and a cross-functional diagram used to highlight different functional interactions required for a process.¹ Regardless of which process model you choose to use—one of the aforementioned models or another of the many models available—it is important to ask the following questions regarding each step of activity depicted in the model if you want to integrate information considerations into your process analysis. That is, what information is

IT professionals and software programmers are familiar with asking these questions when they map out data flows to determine what hardware and what information processing capability are required. So, some of you are likely to ask one or more of the following questions at this point.

The answer to the first question is that performance information is often the major difference between IT processes and other business processes. Because of their different natures, what is an important performance criterion for one is not a concern for the other. To further complicate matters, different terms are used in IT and other processes to define the same type of performance. The growth of shop lingo in different functional areas and the extended use of acronyms in business, such as those defined in appendix B, are a barrier to integrating the management of information and processes.

Process performance is usually measured by the process owner in a way that reflects their major priority. A business whose competitive edge is lower-cost products will be more concerned about the costs of performing each step and the amount of inventory waiting to be processed. A business that competes by providing the fastest response will be more concerned about the time required by each step and process delays. It is not that other performance measures matter, but when resources for improvement are often limited it is best to focus on those measures whose improvement will have the greatest positive effect on a company’s bottom line. Table 3.1 lists some of the common performance measures and some examples as to how they might be applied in information processing, manufacturing, and service functions.

Table 3.1. Common performance measures

To answer the second question, in some ways, we already partially use IT flowchart models for other processes because process modelers have adapted some of their symbols to more clearly communicate what a particular step in a manufacturing or service process does. Some common examples are summarized in Figure 3.1 using Microsoft® Visio®, one of several graphics software packages that provide business users the ability to construct various charts and diagrams. However, the information processing flowchart symbols lack the ability to represent customer interactions as clearly as they should for service process modeling, and there are a number of manufacturing process activities such as test cycles, robotic operations, and inventory processes that are also not well represented. In this monograph we will restrict ourselves to the use of the symbols shown in Figure 3.1. Some modifications to address the needs of a modeling approach for integrating the analysis of information process and other business processes will be suggested in a following book on the subject.

Figure 3.1. Information processing flowchart symbols adapted for use in other process diagrams.

For more complete lists and standardized definitions of flowchart and process diagram symbols, see International Organization for Standardization (ISO), ISO 5807 Information processing—Documentation symbols and conventions… or American National Standard, ANSI X3.6-1970, Flowchart Symbols and their Usage in Information Processing. For a list and description of the symbols available in Excel, the online summary by Hebb is useful.²

The last question regarding who is responsible for information in a business has a number of answers, because typically this responsibility should be distributed, depending on a number of factors. My basic guideline is to assign the responsibility to whoever has the most to lose if the information is incorrect, not available when it is needed, or lost. If the person lacks the technical skills to execute that responsibility on their own, then the person is expected to work with whatever IT function the business has or other sources, both internal and external, to resolve any problems that occur.

Whoever is in the best position to enter new information is responsible for its validity and accurate input. The reliable storage of that information for future use can be done by its creator if the creator is the only user, but normally this is largely an IT responsibility because most information is used by a number of functions in the company. IT is also responsible in this case for easy and prompt access to the stored information in their charge. Users have a responsibility for occasionally running separate checks to verify that the information they are receiving is true and still of value to them. It can be argued that IT should also be primarily responsible for providing technical support to the company’s network structure and information security processes.

Assigning such responsibility and defining what that responsibility is to an employee is not an easy task. Not taking the time to do the latter part well is a major cause of dysfunctions between IT personnel and other employees. As an example, managers of departments where their employees are capable of writing software or macro functions generally have a difficult time getting those employees to document their code, either in comments in the code or in separate documents. When an employee is the only user of the code or macro they have written, it is often argued by the employee that such a requirement is superfluous and would take more time from other work the employee should be doing. If the manager agrees, then considerable difficulties can arise when that code or macro becomes useful to others or needs to be handed over to another person should that employee be promoted, reassigned, or leave the company.

Author’s Note: Astute readers familiar with fast-food businesses are likely to note that I left out some activities, functions, or information processes in the following discussion. Some are intentional to simplify the discussion to more critical aspects of the process. Examples are omitting janitorial functions and other necessary maintenance and support activities such as human resources and payroll accounting whose daily routine is normally not affected significantly by processes involving customers. Otherwise, it would be very difficult to include a process diagram with such detail in a book of this size.

Because the fast-food restaurant business discussed in Example 1.2 has both service and manufacturing aspects with functional activities we will use it in all three of these modeling approaches to illustrate more clearly what the differences and similarities of these models are. Before we begin each model, let’s review the basic elements of the process, including the information content. This is important to do first, because it helps keep our thoughts on track when preparing a process model. The elements for a typical fast-food restaurant are:

The choice of a fast-food restaurant for these examples avoids some complications because the possibility of variations in the daily menu is considerably reduced. Seasonal promotions like eggnog shakes during the Christmas holidays are possible, but we will ignore them in our analysis, as their effect on the overall process would be minimal.³ Because the menu is standardized, this simplifies inventory and purchasing processes. It also allows a make-for-stock approach where the cooks in many fast-food restaurants prepare frequently ordered items in batches during periods of higher demand like lunchtime. Beverages, however, are usually prepared at the time of order.⁴

When the customer arrival rate is low, food is usually made-to-order and a single person may take the order, communicate with the kitchen, collect payment, and hand out the completed order to the customer. When the rate of demand picks up, this activity may be assigned to two persons—one person taking orders and communicating them to the kitchen and the other collecting payments and handing out the food. During the busiest times, three people may be assigned to handle the customer traffic more quickly.

Observe the need for information about customer choices and demand levels during the day to determine how much to prepare in advance, and when. Is it best to analyze the process for obtaining and using such information separately or should it be integrated as part of the customer ordering process?

A similar question can be asked regarding the payment process. Many fast-food restaurants do not accept credit cards in the drive-through lane because of the processing delays during rush-hour periods, but do so inside. In our following models we will assume cash payments only, avoiding the need to show the process steps for verifying a valid credit card and completing the transaction or what to do if the card is rejected. Is it best to include such steps in the overall customer ordering process or to analyze them separately?

The brief answer to such questions is that treating such information-based processes separately is only effective if their choices and outcomes are independent of what else occurs in the customer ordering process. That said, my approach would be to first review the process in a standalone manner to best determine the independent elements like interacting with the credit card service and then consider the dependent steps interacting with the host process.

In the following three examples we will assume that it is the time of day when the customer demand is highest. Hence, we will have one person handling the order taking process, another person collecting customer payments, and a third person pouring beverages and handing out completed orders to the customer. A number of fast-food restaurants serving drive-through customers in addition to walk-in customers have three separate stations in the drive-through lane: one at a menu display for taking orders, a window for collecting payments, and another window for picking up the finished order. Inside the restaurant, there is usually a line for placing orders and collecting payments and a separate location for picking up finished orders. During busier times, there may be one or two additional lines for taking orders and collecting payments.

The food preparation area will be cooking food in a make-to-stock approach for frequently ordered items and a make-to-order approach for highly perishable or less popular items.

Finally, recognizing that many small- to medium-sized businesses still use paper as the primary medium for their process information, we will use that approach as the default method. An exception for the fast-food example is the use of a computer for inventory tracking and accounting data, now a common practice for businesses in developed countries.

Classic Process Block Diagram

Let’s begin with the classic manufacturing process diagram where blocks represent activities or steps in the process and are connected in sequence according to the order that each step needs to be performed. When some steps can be performed independently in the sequence, we will use parallel or adjoining paths in the diagram. It is important to note that a block diagram does not explicitly show the overall duration of the process, although some users may include individual processing times with other information displayed inside each block. For the moment, we will restrict the block information to labeling the activity that the block represents. Figure 3.2 shows the process for a typical customer to obtain an order of food from the restaurant.

Figure 3.2. Block diagram of fast-food restaurant customer order process.

Service Process Blueprint

A service process blueprint separates the steps requiring some participation by the customer (called the front office) from those steps that are necessary to complete the process, but can be performed out of sight of the customer (called the back office). More advanced service process blueprints separate the front office activities into those steps requiring the participation of the customer from those that may require further participation of some of the customers. Some examples of the latter group are approval of additional repairs required, desired items being out of stock, credit card denial, and notifications that the order the customer has been waiting for has arrived or is ready.

As some back office activities evolve to use dematerialized forms of information, a few service process blueprints have separated back office activities into those that need to be done on the premises and those that can be done at another location (usually information processing and many supply chain activities). These refinements to the basic service blueprint are useful when implementing enterprise software solutions for customer relationship management (CRM) and choosing what activities can be located elsewhere or subcontracted to other vendors, as discussed in chapter 5.

For our fast-food restaurant example, we will use a simple front-office, back-office service blueprint as shown in Figure 3.3.

Figure 3.3. Service process blueprint for fast-food restaurant customer order process.

Cross-Functional Process Diagram

A cross-functional process diagram separates the individual process steps into columns or rows according to which organizational function is responsible for executing them, with each column or row representing a single function. These are often called “swim-lane” diagrams because they are similar to the layout of a swimming pool for athletic events. And some of us call them Rummler–Brache diagrams because we were first introduced to them in a book on improving performance by Rummler and Brache.⁵ While they called this method for depicting a process flow “a process map,” by any name it is a useful tool for showing both the sequence of steps and which entity is responsible for performing each step. The cross-functional layout also allows the incorporation of when and how long it takes to complete a step by adding a time axis to the length of the rows or columns. In Figure 3.4, we show the primary support functions for a customer order—cooking, inventory, and purchasing. If we include the information flows, we would need to include an IT function.

Figure 3.4. Cross-functional diagram of fast-food restaurant customer order process.

Adding Information Flows to Process Diagrams

Some information flows are already depicted in the process diagrams when they are an important step and obviously essential for the completion of the process in our example like the customer placing his or her order with the restaurant, the food preparation area receiving the order, and the customer being told what they owe for the order. The service process blueprint allows easier identification of the more obvious information exchanges since they are an integral part of dealing with the customer’s order and therefore are front-office activities.

The transfer of information to the kitchen depends on whether or not they have already prepared and put into stock what the customer wants or need to make-to-order what the customer wants and the customer should be told there will be an additional wait while they do so. Since the kitchen staff normally does not talk directly to customers, there must be a process for transferring such information to either the order taker or the person receiving the customer payments. Not so obvious is the need for inventory information to be updated as the kitchen uses up supplies and how and when that information is communicated to the purchasing function. If the fast-food restaurant is a franchise business, the purchasing group could be located anywhere. In such a case, do they get inventory needs through regular e-mails, database entries by the individual franchises, or by monitoring the local inventory directly using an Internet connection?

Although we have simplified the payment process by limiting it to cash payments, information from a local or centralized database regarding current prices is still needed to tell the customer what they owe the restaurant for their order. The same system is likely to be used to record point-of-sale (POS) data for accounting and tax applications, customer demand history, changes in product demand preferences, and so forth. Is that information archived locally or sent to some cloud application for processing and storage?

At this point, you hopefully should get the idea that there is a lot of information flowing around in even simplified process models and that most of the process steps for handling it are either not shown or are only depicted in very simple terms by users who are not familiar with IT systems. In contrast, IT functions are likely to have developed a very detailed model ofeach of the elemental information processes discussed earlier: inventory status, POS data, accounting information, and CRM data. Their models, however, are as likely to be as sketchy regarding the details of the material processes involved (verbally taking orders, preparing food, pouring drinks) as the typical process models are regarding electronic information processes. To bring these opposing viewpoints closer together requires three basic strategies:

In many larger enterprise organizations, an MIS (management information systems) function has either replaced their former IT functions or exists in cooperation with an IT function to achieve these strategies. In SMB environments, these strategies are more difficult to execute because of limited availability of hardware systems and the technical expertise to support them and their applications to the business. Online resources such as cloud computing and networking support are becoming more available to meet SMB needs, but the management at such businesses should keep the aforementioned strategies in mind when selecting such resources.

Keeping the earlier discussion in mind, let’s use one of the process models shown earlier to illustrate how one might modify a more traditional process modeling approach to show the information content of the process more clearly for analysis. Since all of the models have the same number of steps and the steps are all connected in the same sequences, we will use just the service process blueprint in Figure 3.3 for our example.

Figure 3.3 shows arrows pointing from each step to the next step in the sequence. In information flow models, an arrow represents a one-way transmission. In most real situations, the order taker repeats the order back to the customer to verify that they received the information correctly. This adds some time to the average completion time for an order and should be indicated by another arrow pointing back to the customer. In addition, if the customer and the order taker are not fluent in the same language or there is a noisy audio connection, this back-and-forth verification process could occur several times before there is an agreement on the correct information at both ends of the communication.

This situation also exists at other information transferal points in the process such as the payment step where the cashier tells the customer the price, the customer often verifies the amount, money is exchanged, change is counted by the customer, and so forth. Therefore, we modify the diagram to show these two-way communications by using two parallel arrows pointing in opposite directions. We could take this a step further to use arrows that also represent the medium used for transferring the information. In IT process diagrams, an arrow with a zigzag like a lightning bolt in the middle of the arrow, as shown in Figure 3.1, represents an electronic transmission. Because this fast-food restaurant still uses vocal sound methods for communication with the customer, we will use straight arrows for those actions and standard electronic symbols for a microphone and a speaker to represent the order taker. However, the zigzag arrow symbols are a better choice for some of the back-office communications with computer systems. These modifications are shown in Figure 3.5 along with the other modifications described later in the text.

Figure 3.5. Service process blueprint from figure 3.3 modified to show the information process content more clearly.

At the beginning of the process, customers usually read the menu before making their choices of what to order. Since most fast-food restaurants display a static menu at the ordering station, we will represent that information with a document symbol from Figure 3.1 to indicate that it is on a physical medium.

Now consider the transfer of order information to the cashier collecting payments and the person assembling the order. We will assume that the list of ordered items is in the form of a paper order filled out by the order taker and show a document symbol as part of the transfer process. The order goes first to the cashier to determine what the customer owes in payment and then to the assembly person. We are now at a decision point for the assembly person. If all of the cooked order items are already completed and waiting under the heat lamp, the assembly person proceeds to assemble the order for the customer. If not, then the order is given to the kitchen staff for them to prepare the required items and then returned to the assembly person with the finished items when they are completed.

More than collecting money occurs at the cashier station. The process of entering the list of items on each order into the cash register to calculate the total payment offers the best opportunity to collect point-of-sale data and also to input inventory changes. Otherwise, the order data given to the assembly person would have to be passed on in paper form after the customers pick up their orders for manual processing.

Potential Process Improvements

A number of potential process improvements can be considered when reviewing a completed process diagram. They can be changes in how items are physically handled or by identifying steps that appear to not add any value for the customer or the business⁶ and thus can be eliminated. In many cases, particularly for service processes, the biggest benefit can come from improving, altering, or replacing some or all of the information process components. A suggested checklist of questions to ask is:

Because the emphasis here is on the value of integrating information process considerations with other business process considerations we will not discuss other improvement possibilities such as food preparation methods here. That will be left to a subsequent book focused on overall process analysis and improvement methods updated to include the integration of information processes. Given this constraint, let’s address the above checklist as it applies to the fast-food restaurant customer ordering process.

The use of paper documents is still common to many smaller businesses and even parts of larger enterprises because it is easy to implement and familiar to employees. However, the ability to convert information conveyed on a physical medium such as paper into a digital form that can be processed electronically offers many benefits to business processes and should be the first thing to consider when improving a process currently dependent on paper documentation. Within a given process, the earlier in the process sequence that dematerialization is done, the greater the potential benefit. Here, a good choice would be for the order taker to enter the order information electronically using a traditional keyboard or a touchscreen display. By sending the information directly to the restaurant’s main computer system for processing, the computer can calculate the amount owed and send it electronically to the cashier, make the decision as to whether or not a make-to-order request needs to be sent to the kitchen, store the POS data, record a reduction in inventory supplies created by the order, notify purchasing when more inventory is needed, and so forth.

Note that just dematerializing the information also helps answer several of the other questions on the checklist. They could be answered without eliminating the use of paper forms, but the answers would be constrained to less effective possibilities such as redesigning the order form for easier entry and having the cashier enter the POS data into the central computer instead of the order taker.

A hidden advantage for the restaurant using this order process improvement is that they can gain additional information about customer demand. As the order is now in a dematerialized form, the input system can easily add other data that might affect the order, such as time of day, day of the week, weather information, number of customers waiting in line, and so forth, to the order data. An example of the use of such data is given at the end of appendix C where we discuss an application using Excel’s PivotTable function.

The last question on the checklist is perhaps the second-most important one for a service process improvement. Allowing customers to do some of the service helps businesses in a number of ways. It allows more standardization of the service process and reduces labor costs by having the customer perform some of the desired customization. An example is providing condiment stations so that customers can add what they want to their food or beverage instead of asking the restaurant staff to do it for them and increasing the complexity of the order information. Letting the inside customers pour their own beverages is another example and it gives them something to do while waiting in line for the rest of their order.

Using this approach, let’s return to the ordering step and combine it with some advances in information technology to allow the customer to dematerialize the order information as shown in Figure 3.6. The traditional menu is now a flat-screen display. Such displays have become larger, more reliable, and less expensive to the extent that they now can be used by fast-food restaurants to display their menu choices. Besides the high-tech look, such displays have the advantage of being easily updated to include seasonal promotions on the menu or to remove items temporarily out of stock. Animation sequences are also possible to help promote different items on the menus. A separate smaller display with a keypad or touchscreen capability is used by the customer to enter their order by either entering a code displayed with each item on the menu, or touching a corresponding button on the touch-screen. When the customer is ready to submit their order, it is summarized on the screen for their verification before they do so. This not only enters the order information in a dematerialized form at the earliest point in the process, but also eliminates the need for an order taker and the possible communication errors between the order taker and the customer.

Figure 3.6. Customer order process step modified to take advantage of information processing technology to provide dematerialized order information.

A few years ago, these improvements would have also required some customer education and familiarization to use the order entry process correctly. With the widespread use of ATMs and online shopping order entry, the new customer ordering steps should be familiar to most customers.