Chapter 10 Business Process and Information Systems Development \"Jeff, we clean the clubhouse restrooms twice a day . . . in the morning before 7 and again just before lunch. We've been doing that for years. Never been a problem.\" Mike Stone, facilities manager, is defending his department in a meeting with Jeff Lloyd, Fox Lake's general manager, and Anne Foster, manager of the newly formed wedding events department. \"That's just great Mike. Just great.\" Anne raises her voice, \"And what if, like on the PAST THREE SATURDAYS, we have two weddings in the afternoon? Do you think maybe guests at the second wedding would like clean bathrooms?\" Anne is incredulous that she has to ask for clean bathrooms, of all things. \"It's your friends and family at a wedding . . . at Fox Lake! You would hope the bathrooms will be clean!\" Jeff sits impatiently, he doesn't like the direction of this discussion, but he doesn't know where to take it . . . 328 Mike continues. \"Look, Anne, I can hire staff to clean the bathrooms on whatever schedule you want. I DO have a budget to pay attention to, however, so I'm not going to hire people to clean bathrooms that are already clean because we DIDN'T have two weddings that day.\" \"Well, Mike, should we talk about our problem with the toilet in the ladies room?\" \"What do you mean?\" \"I mean for a whole month, we've had a toilet that overflows . . . \" \"Mike, is that right?\" Jeff jumps in. \"Look. I don't have a plumber on staff. Steve's the weekend manager. He knows we watch our expenses, and he's not going to call a plumber on Saturday, weekend rates and all. So, he's does the right thing. He goes over there and tries to fix it himself.\" \"Seems like a good response, doesn't it?\" Jeff asks, wondering where this one is going. \"You're not going to take your bridal gown into a Porta Potty.\" \"I thought so, too. Saves us money and solves the problem. Turns out that plumbing equipment was never designed to have 250 people at an event. It's designed for one or two people from the restaurant, maybe a party of four golfers. Anyway, he fixes the toilet with spare parts and whatnot and, with that heavy use, it breaks again, and Anne comes unglued! Besides, if I had notice, I could bring in some Porta Potties . . . \" \"Mike!!! This is a wedding! You're not going to take your bridal gown into a Porta Potty. I CAN'T BELIEVE I'M HAVING THIS DISCUSSION!!!\" Anne is stupefied at his comment. Jeff steps in. \"OK, you two. Clearly, we've got some work to do. We're almost at the end of the big wedding season. Take a break and then sit down together and schedule it out. Figure out what it will take to get us through this year. Mike, let me know if you need more money and I'll see what I can come up with. But, I don't mean a lot. Meanwhile, I'll start thinking about a longer-term solution.\" Next week, Jeff meets in his office with Laura Shen, who'd been recommended to him as someone who could help solve the wedding events and facilities problems. \"Laura, I don't really know what you do. Margaret Silvester, one of our board members, said you'd helped with some computer problems at her company, and she insisted I meet with you. This doesn't seem like a problem for a computer programmer, though.\" \"Jeff, I'm not a programmer. I'm what's called a 'business analyst.' I know technology, and while I have written computer programs, that's not what I do. I specialize in understanding business needs, strategies, and goals and helping businesses implement systems to accomplish those needs. Often that involves computerbased systems, but not always.\" \"Well, what do you know about us?\" \"Margaret gave me a quick rundown. You've recently acquired a wedding events business and you've had problems integrating it with the rest of Fox Lake.\" \"That's about right. But, we didn't acquire a business . . . we hired someone who owned a small business and she hoped to make it bigger working for Fox Lake. I was looking for a source of more revenue.\" \"So, what's the problem?\" \"Facilities, mostly. We had some issues about using membership data for marketing, but not serious ones. The big problems are sharing facilities, timely maintenance, and tracking repairs. And, these wedding events stress us in ways we're not used to. The crew at the restaurant can serve up a few burgers and fries to the club members, but when we start putting high-end caterers into their kitchen space, well, like I said, it's stressful . . . \" \"I might be able to help. Did you see this coming when you started wedding events?\" \"No, not really. We just thought we could use our buildings for weddings . . . I didn't understand how it would impact everything else.\" \"Well, let me talk with your key people for a bit, and I'll get back to you with some ideas and a proposal.\" Study Questions Q1 Why do organizations need to manage business processes? Q2 What are the stages of Business Process Management (BPM)? Q3 How can BPMN process diagrams help identify and solve process problems? Q4 Which comes first, business processes or information systems? Q5 What are systems development activities? Q6 Why are business processes and systems development difficult and risky? Q7 What are the keys for successful process and systems development projects? Q8 2021? 329 Suppose Fox Lake had hired you instead of Laura. How would you proceed? According to Jeff, \"The big problems are sharing facilities, timely maintenance, and tracking repairs.\" How would you address these problems? What would you advise Fox Lake to do? Would you start by creating a spreadsheet or a database to schedule maintenance? If so, how would Fox Lake use either to solve these problems? Or, would you start by creating some sort of information system that has procedures for scheduling the use of facilities? Or, would you begin with a business process, say the process of planning weddings, and work from there to the need for information systems, and from there to the need for a spreadsheet or a database? To answer these questions, we will address two major themes in this chapter: business process management and information systems development. The two themes are closely related and overlap in important ways. We begin in Q1 through Q3 by describing the need for process management, the stages in the business process management cycle, and BPMN, a notation used for documenting business processes. Next, in Q4, we investigate the relationship of processes and systems by asking the question: Which should organizations create first? The response to that question sets up the discussion of systems development activities in Q5 and the challenges and keys to success in development projects in Q6 and Q7. We'll wrap up this chapter with a discussion of how information systems careers are likely to change between now and 2021. Q1 Why Do Organizations Need to Manage Business Processes? In order to discuss process design, we will extend the definition of business processes that we used in Chapter 3. Here we will define a business process as a network of activities, repositories, roles, resources, and data flows that interact to accomplish a business function. As stated in Chapter 3, activities are collections of related tasks that receive inputs and produce outputs. A repository is a collection of something; an inventory is a physical repository and a database is a data repository. The new terms in this definition are roles, which are collections of procedures, and resources, which are people or computer applications that are assigned to roles. Finally, a data flow is the movement of data from one activity or another or from an activity to a repository, or the reverse. To make this more clear, you can think of roles as job titles. Example roles are salesperson, credit manager, inventory supervisor, and the like. Thus, an organization might assign three people (resources) to the salesperson role, or it might create an information system (resource) to perform the credit manager role. To better understand this definition, consider a simple, but common, example. A Sample Ordering Business Process Suppose that you work in sales for a company that sells equipment and supplies to the hotel industry. Your products include hotel furniture, cleaning equipment, and supplies, such as towels and linens and staff uniforms. Processing an order involves the five steps shown in Figure 10-1. You are one of many people (resources) that perform the salesperson role. As a salesperson, you do not perform all of the activities shown; rather, you orchestrate their performance. You are the customer's representative within the firm. You ensure that the operations department verifies that the product is 330 Q1 Why Do Organizations Need to Manage Business Processes? 331 available and can be delivered to the customer on the requested schedule. You check with accounting to verify the credit required to process the order, and you check with your boss, a sales manager, to approve any special terms the customer might request (discounts, free shipping, extended return policy, etc.). We will document this process further in Q2. Why Does This Process Need Management? When you joined the firm, they taught you to follow this process, and you've been using for it two years. It seems to work, so why does it need to be managed? The fundamental answer to this question is that processes are dynamic and often need to be changed. This need can arise because a process doesn't work well, because of a change in technology, or because of a change in some business fundamental. Processes That Don't Work Well The most obvious reason for changing a process is that it doesn't work. The process does not produce the desired result, or it is so confused, with everyone following their own personal way of getting things done, that it is only good fortune when desired outputs are produced, now and then. Businesses with such broken processes cannot survive, and, consequently few processes are such complete failures. More common are processes that work, but not very well. For example, according to Figure 10-1, salespeople verify product availability before checking customer credit. If checking availability means nothing more than querying an information system for inventory levels, that sequence makes sense. But suppose that checking availability means that someone in operations needs not only to verify inventory levels, but also to verify that the goods can be shipped to arrive on time. If the order delivery is complex, say the order is for a large number of beds that have to be shipped from three different warehouses, an hour or two of labor may be required to verify shipping schedules. After verifying shipping, the next step is to verify credit. If it turns out the customer has insufficient credit and the order is refused, the shipping-verification labor will have been wasted. So, it might make sense to check credit before checking availability. Figure 10-1 Steps in Processing an Order Hotel Prepare Quotation Verify Availability Customers Check Customer Credit Orders Approve Special Terms Process Order 332 CHAPTER 10 Business Process and Information Systems Development Similarly, if the customer's request for special terms is disapproved, the cost of checking availability and credit is wasted. If the customer has requested special terms that are not normally approved, it might make sense to obtain approval of special terms before checking availability or credit. However, your boss might not appreciate being asked to consider special terms for orders in which the items are not available or for customers with bad credit. Another reason that processes don't work well is that they are misaligned with the organization's goals, objectives, or competitive strategy. If, for example, the vendor has chosen a low-cost strategy, then taking the time to verify shipping dates may be at odds with that competitive strategy. The labor to verify shipping dates will raise sales costs and may prohibit the vendor from providing the lowest possible prices to its customers. As you can see, it's not easy to determine what process structure is best. The need to monitor process effectiveness and adjust process design, as appropriate, is one reason that processes need to be managed. Change in Technology Changing technology is a second reason for managing processes. For example, suppose the equipment supplier in Figure 10-1 invests in a new information system that enables it to track the location of trucks in real time. Suppose that with this capability the company can provide next-day availability of goods to customers. That capability will be of limited value, however, if the existing credit-checking process requires 2 days. \"I can get the goods to you tomorrow, but I can't verify your credit until next Monday\" will not be satisfying to either customers or salespeople. Thus, when new technology changes any of a process's activities in a significant way, the entire process needs to be evaluated. That evaluation is another reason for managing processes. Change in Business Fundamentals A third reason for managing business processes is a change in business fundamentals. A substantial change in any of the following factors might result in the need to modify business processes: Market (e.g., new customer category, change in customer characteristics) Product lines Supply chain Company policy Company organization (e.g., merger, acquisition) Internationalization Business environment To understand the implications of such changes, consider just the sequence of verifying availability and checking credit in Figure 10-1. A new category of customers could mean that the credit-check process needs to be modified; perhaps a certain category of customers is too risky to be extended credit. All sales to such customers must be cash. A change in product lines might require different ways of checking availability. A change in the supply chain might mean that the company no longer stocks some items in inventory but ships directly from the manufacturer instead. Or, the company might make broad changes to its credit policy. It might, for example, decide to accept more risk and sell to companies with lower credit scores. In this case, approval of special terms becomes more critical than checking credit, and the sequence of those two activities might need to be changed. Of course, a merger or acquisition will mean substantial change in the organization and its products and markets, as does moving portions of the business offshore or engaging in international commerce. Finally, a substantial change in the business environment, say, the onset of a recession, might mean that credit checking becomes vitally important and needs to be moved to first in this process. Q2 What Are the Stages in Business Process Management (BPM)? Q2 What Are the Stages in Business Process Management (BPM)? The factors just discussed will necessitate changes in business processes, whether the organization recognizes that need or not. Organizations can either plan to develop and modify business processes, or they can wait and let the need for change just happen to them. In the latter case, the business will continually be in crisis, dealing with one process emergency after another. Figure 10-2 shows the basic activities in business process management (BPM), a cyclical (recurring) process for systematically creating, assessing, and altering business processes. This cycle begins by creating models of business processes. The business users who have expertise and are involved in the particular process (this could be you!) adjust and evaluate those models. Usually teams build an as-is model that documents the current situation and then changes that model to make adjustments necessary to solve process problems. Given the model, the next step is to create system components. Those components have the five elements of every information system, although some are entirely automated (no people and procedures) and some are entirely manual (no hardware or software). Next, needed business processes or changes to existing business processes are implemented. Well-managed organizations don't stop there. Instead, they create policy, procedures, and committees to continually assess business process effectiveness. The Information Systems Audit and Control Association has created a set of standard practices called COBIT (Control Objectives for Information and related Technology) that are often used in the assessment stage of the BPM cycle. Explaining these standards is beyond the scope of this discussion, but you should know that they exist. See www.isaca.org/cobit for more information. When the assessment process indicates that a significant need for change has arisen, the BPM cycle is repeated. Adjusted and new process models are developed, and components are created, implemented, and assessed. Effective BPM enables organizations to attain continuous process improvement. Like quality improvement, process improvement is never finished. Process effectiveness is constantly monitored, and processes are adjusted as and when required. Business process management has the same scope as discussed for information systems in Chapter 7: functional, cross-functional, and interorganizational. As shown in Figure 10-3, BPM becomes more difficult as the scope of the underlying processes increases. Finally, do not assume that business process management applies only to commercial, profit-making organizations. Nonprofit and government organizations Figure 10-2 Stages in the BPM Cycle Create Components Model Processes Implement Processes Assess Results 333 334 CHAPTER 10 Business Process and Information Systems Development Scope Description Example BPM Role Functional Business process resides within a single business function. Accounts payable BPM authority belongs to a single departmental manager who has authority to resolve BPM issues. Cross-functional Business process crosses into multiple departments within a single company. Customer relationship management (CRM); enterprise resource management (ERP) BPM authority shared across several or many departments. Problem resolution via committee and policy. Interorganizational Business process crosses into multiple companies. Supply chain management (SCM) BPM authority shared by multiple companies. Problem resolution via negotiation and contract. Figure 10-3 Scope of Business Process Management have all three types of processes shown in Figure 10-3, but most of these processes are service-oriented, rather than revenue-oriented. Your state's Department of Labor, for example, has a need to manage its processes, as does the Girl Scouts of America. BPM applies to all types of organizations. Q3 How Can BPMN Process Diagrams Help Identify and Solve Process Problems? One of the four stages of BPM, and arguably the most important stage, is to model business processes. It is so important because such models are the blueprint for the new process and system components. If models are incomplete and incorrect, components cannot be created correctly. In this question, you will learn standard notation for creating process documentation. Need for Standard for Business Processing Notation As stated, we define a business process as a network of activities, repositories, roles, resources, and data flows that interact to accomplish a business function. This definition is commonly accepted, but unfortunately dozens of other definitions are used by other authors, industry analysts, and software products. For example, IBM, a key leader in business process management, has a product called WebSphere Business Modeler that uses a different set of terms. It has activities and resources, but it uses the term repository more broadly than we do, and it uses the term business item for data flow. Other business-modeling software products use still other definitions and terms. These differences and inconsistencies can be problematic, especially when two different organizations with two different sets of definitions must work together. Accordingly, a software-industry standards organization called the Object Management Group (OMG) created a standard set of terms and graphical notations for documenting business processes. That standard, called Business Process Modeling Notation (BPMN), is documented at www.bpmn.org. A complete description of BPMN is beyond the scope of this text. However, the basic symbols are easy to understand, and they work naturally with our definition of business process. Hence, we will use the BPMN symbols in the illustrations in the chapter. All of the diagrams in this chapter were drawn using Microsoft Visio, which includes several BPMN symbol templates. Figure 10-4 summarizes the basic BPMN symbols. Documenting the As-Is Business Order Process Figure 10-5 shows the as-is, or existing, order process introduced in Figure 10-1. First, note that this process is a model, an abstraction that shows the essential elements of the process but omits many details. If it were not an abstraction, the model would be Q3 How Can BPMN Process Diagrams Help Identify and Solve Process Problems? Start End Activity (+ indicates subprocess defined) Decision or Gateway Data Process flow Message flow Other processes add new equipment and record the arrival of repaired equipment Annotation as large as the business itself. This diagram is shown in swim-lane layout. In this format, each role in the business process is given its own swim lane. In Figure 10-5, there are five roles and hence five swim lanes. All activities for a given role are shown in that role's swim lane. Swim-lane layout simplifies process diagrams and draws attention to interactions among components of the diagram. Two kinds of arrows are shown. Dotted arrows depict the flow of messages and data flows. Solid arrows depict the flow or sequence of the activities in the process. Some sequence flows have data associated with them as well. According to Figure 10-5, the customer sends an RFQ (request for quotation) to a salesperson (dotted arrow). That salesperson prepares a quotation in the first activity and then (solid arrow) submits the quotation back to the customer. You can follow the rest of the process in this diagram. Allocate inventory means that if the items are available they are allocated to the customer so that they will not be sold to someone else. Diamonds represent decisions and usually contain a question that can be answered with yes or no. Process arrows labeled Yes and No exit two of the points of the diamond. Three of the activities in the as-is diagram contain a square with a plus (+) sign. This notation means that the activity is considered to be independent of this process and that it is defined in greater detail in another diagram. For example, the Check Customer Credit subprocess is shown in Figure 10-6. Note the role named CRM in this subprocess. In fact, this role is performed entirely by an information system, although we cannot determine that fact from this diagram. Again, each role is fulfilled by some set of resources, either people or information systems, or both. Using Process Diagrams to Identify Process Problems The processes shown in Figures 10-5 and 10-6 have problems. Before you continue, examine these figures and see if you can determine what they are. The problems in these processes involve allocations. The Operations Manager role allocates inventory to the orders as they are processed and the Credit Manager role allocates credit to the customer of orders in process. These allocations are correct as long as the order is accepted. However, if the order is rejected, these allocations are 335 Figure 10-4 Business Process Management Notation (BPMN) Symbols 336 CHAPTER 10 Business Process and Information Systems Development Figure 10-5 Existing Ordering Process not freed. Thus, inventory is allocated that will not be ordered, and credit is extended for orders that will not be processed. One fix (several are possible) is to define an independent process for Reject Order (in Figure 10-5 that would mean placing a box with a + in the Reject Order activity) and then designing the Reject Order subprocess to free allocations. Creating such a diagram is left as exercise 3 in Using Your Knowledge (page 369). Q3 How Can BPMN Process Diagrams Help Identify and Solve Process Problems? How Can Business Processes Be Improved? The two major dimensions of business process effectiveness are performance and cost. Process designers can increase the performance of a business process in three fundamental ways. First, they can add more resources to the roles of a given process without changing its structure. This is the brute-force approach: add more people, equipment, or systems to the existing way of doing business. Such a change always Figure 10-6 Check Customer Credit Process 337 338 CHAPTER 10 Business Process and Information Systems Development adds cost; it may be worth doing, however, if the improvement in performance generates sufficient value to justify the cost. Second, designers can change the structure of a process without changing resource allocations. In some cases, if the change is particularly effective it can result in the same or greater performance at no additional cost, or even at less cost. Finally, designers can do both by changing the structure and adding resources. To better understand these alternatives, suppose the company having the process in Figure 10-5 finds that its inventory costs are larger than it expects. Investigation of the causes determines that inventory is being held for excessive amounts of time because orders are delayed due to the time required to check the customer's credit. To solve this problem, the company could speed up the process by adding more people resources to the Credit Analyst role shown in Figure 10-6. Or, the company might add resources by investing in an information system to augment or replace the humans who perform the credit-checking role. Instead of adding resources, the company could address this problem by changing the structure of the process to check credit before checking inventory availability. Such a change is shown in Figure 10-7. Another option is for the company to both add resources to the credit-checking process and to change the sequence of inventory and credit checking. Fox Lake Wedding Planning and Facility Maintenance Processes To further illustrate the use of business process modeling, consider the Fox Lake scenario that opened this chapter. It ended with Laura, a business analyst, planning to meet with Anne and Mike to determine what might be done to address Fox Lake's problems. Because Fox Lake has no existing maintenance scheduling system, this team of people needed to model a new business process. Assume that after they met, Laura created the business process model shown in Figure 10-8 (page 340). Four roles are shown in vertical swim lanes: The Bride & Family, Wedding Planner, Facilities Application, and Facilities Maintenance. An unknown number of resources will be assigned to each of these roles; many customers will play the Bride & Family role, one or more people will take the Wedding Planner role, some person or computing resource will take the Facilities Application role, and one or more people will take the Facilities Maintenance role. Examine the exchanges between the Bride & Family role and the Wedding Planner role. Bride & Family provide the requirements that the Wedding Planner uses to create a proposal. Then, Wedding Planner attempts to reserve the facilities. If all facilities are available, the proposal is transformed into bid with costs. If not, the Bride & Family are asked to revise their requirements (smaller number of guests, different date, reception outside, etc.). If the Bride & Family accept the bid and sign the bid, then the facility reservations are confirmed and a deposit is collected. That collection activity is documented as a separate process. This process model, like all models, is an abstraction. It does not include every detail, but it captures the essence of the process and the need to reserve Fox Lake facilities. It might seem odd to you to formalize the process of planning a wedding in this way, but such formalization is needed to create and implement business processes and related information systems. By the way, this model is incomplete. Many activities at Fox Lake besides wedding planning need to reserve facilities. Most likely, Laura would document those processes as well, or she might generalize this process into one that would work for all facility users, not just wedding planning. We needn't be concerned with those extensions here, however. The next step in the BPM process is to create components. That step leads us into the topic of systems development, and we begin by discussing the relationship of business processes and information systems. Q4 Which Comes First, Business Processes or Information Systems? Figure 10-7 Revised Order Process Q4 Which Comes First, Business Processes or Information Systems? This question is surprisingly hard to answer. It's difficult to answer in theory, and it's even more difficult to answer in practice. To understand why, you first need to understand how business processes and information systems relate. 339 340 CHAPTER 10 Business Process and Information Systems Development Figure 10-8 Fox Lake Wedding Planning and Facilities Maintenance Processes How Are Business Processes and Information Systems Related? To learn the relationship between business processes and information systems, examine Figure 10-9, which is a color-coded version of Figure 10-8. Information system elements are shown in bold colors, as indicated by the key. The Facilities database is shown in red, Facilities Reservation application programs are shown in orange, and procedures for using the Facilities Reservation system are shown in blue. This process involves a second, separate billing information system that is processed in the Collect Deposit subprocess shown in green. The other activities in this process are not part of any information system. We can deduce three important principles from this figure. First, information systems and business processes are not the same thing. Information system elements are embedded within business processes, but there are activities in business processes that are not part of the information system. Second, this business process uses two separate information systems; and, in general, a business process can utilize zero, one, or more information systems. The third principle is not visible in Figure 10-9, but we can infer it. The Facilities Reservation information system is likely to be used by other business processes. In fact, the Fox Lake billing process uses this system to bill customers for facility use. In addition, the budgetary process uses the Facility Reservation system to determine Q4 Which Comes First, Business Processes or Information Systems? a budget for future facility revenue, and so forth. Thus, a particular information system may be used by one or more business processes. Recalling the cardinality principles from Chapter 5, we can say that the relationship of business processes and information systems is many-to-many, as illustrated in Figure 10-10. For example, the Wedding Planning process uses two information systems (many), and, at the same time, the Facilities Scheduling system is used in four different business processes (also many). Wedding Planning Process Facilities Scheduling System Customer Billing Process Facilities Maintenance Process Payroll System Budgeting Process Billing System Example Business Processes Example Information Systems 341 Figure 10-9 Fox Lake Processes Showing IS Components Figure 10-10 Many-to-Many Relationship of Business Processes and Information Systems 342 CHAPTER 10 Business Process and Information Systems Development Which Comes First? Why do we care about this? What difference does it make? The many-to-many relationship between business processes and information systems poses a dilemma when it comes time to build them. Which should we do first? Should we specify one or more business processes and then build the information systems that they require? Or, do we attempt to determine, in the abstract, all of the ways that someone might use an information system, build it, and then construct the business processes around it? If you reflect on this situation, you can see why ERP systems, which promise to do everything, are both wonderful and terrible. They're wonderful because they include all the business processes and all the system components that an organization will need, at least as determined by the ERP vendor. They're terrible because, to implement ERP, an organization must attempt to do everything at once. But, for non-ERP business processes and information systems, and for small organizations like Fox Lake, which should come first? Consider the alternatives. Business Processes First Suppose we decide to design business processes first and then build information system components as a consequence of that process design. If we take this approach, we'll have a development process that looks like that in Figure 10-11. The organization will engage in business process management and construct system components in the create components stage of the BPM cycle. This approach works well for the business processes that are being constructed, but what about others in the future? Suppose the Facilities Reservation system is constructed to reserve facilities like rooms in buildings and the restaurant and that it works well for that purpose. But what if Fox Lake's golf operations department wants to be able to reserve one or both golf courses for special events? The golf course reservation process was not part of the requirements when the Facilities Reservation system was constructed for Wedding Events, and the system won't work for that process. So, starting from processes and working toward information systems is likely to work well for the business processes under consideration, but will cause problems later, for other processes that use the information systems. So, what if we start with the information system, first? Figure 10-11 BPM and Systems Development Systems Development Process Create Components Model Processes Information System Components Implement Processes Assess Results Q4 Which Comes First, Business Processes or Information Systems? Information System First To start with systems first, a development team would talk with representative future users of the system and attempt to determine all of the ways that someone at Fox Lake might want to reserve facilities. From those requirements, they would then design components and construct the system. Systems development is the process of creating and maintaining an information system. The most common technique for developing information systems is the systems development life cycle (SDLC), and it has the five steps shown in Figure 10-12. A high-level business planning process determines that a system is needed for some function; at Fox Lake that function would be to reserve facilities. Given that system need, the development team would then refine the system definition, determine requirements, design system components, and then implement the system. This development process makes business processes a poor step-child of the information systems development process. The focus is on hardware, software, data, procedures (for using the system only), and user training. Some aspects of business processes will be constructed as part of the system implementation, but, as you saw in Figure 10-9, business processes can include many activities that are not part of the information system. Those activities are unlikely to be considered when the system is constructed. Another Factor: Off-the-Shelf Software A missing factor in this discussion is off-the-shelf software. Few organizations today can afford to create computer programs and design databases in-house. It is unlikely that Fox Lake, for example, will do so. Instead, most organizations attempt to license software off-the-shelf and adapt it to their needs, or adapt their needs to it. So, if an organization knows that it will most likely license off-the-shelf software, is it better to design processes first or to develop information systems first? Unfortunately, again, there is no demonstrably correct answer. If an organization starts with business processes first, it is likely to choose a package that will work well for the processes being developed, but that may not work well for other processes that may come along later (like golf operations wanting to reserve golf tee times). However, if it starts with information systems and collects all the requirements, it is likely to find a package that will work better for all users, but, again, business processes will receive short shrift. And the Answer Is . . . In theory, it is better to start with business processes. As discussed in Chapter 3, business processes are closer to the organization's competitive strategy and other goals and Business Planning Process System Need Define System Project Plan Determine Requirements Approved Requirements Design System Components Design portions of business processes here, as needed to use information system System Design Implement System Maintain System Information System Problem or Need for Change System Users Figure 10-12 Classic Five-Step Systems Development Life Cycle 343 344 CHAPTER 10 Business Process and Information Systems Development objectives. Starting with processes and working toward systems is more likely to result in processes and systems that are aligned with the organization's strategy and direction. In practice, however, the answer is not clear. Organizations today take both approaches. Sometimes the same organization takes one approach with one set of processes and systems and a second approach with a different set. The factor that overtakes all is off-the-shelf software. The vendor of the software knows the features that are most commonly needed by its customers. Therefore, if an organization starts with business processes and selects an application that works for those processes, it is likely that the application will also include features and functions that will be needed by other business processes to be designed in the future. At Fox Lake, an application that can be used to reserve buildings and rooms is likely to be adaptable enough to also reserve golf courses and golf facilities. Most likely, an application software vendor will include procedures for using that software as part of its offering. So, the procedure components in Figure 10-9 (shown in blue) are most likely part of the package. However, the entire business process in Figure 10-9 is unlikely to be part of the vendor's package. Therefore, in most cases, if an organization is likely to license an application from a vendor, it is better to begin with processes. This rule is not ironclad, however. You should expect to find both approaches used in organizations during your career. Not Possible to Buy Processes or Systems Off-the-Shelf Before we continue with systems development, do not be misled by the last few paragraphs. It is possible to buy an off-the-shelf computer application that will fulfill the Facilities Application role. Laura, and possibly others, will most likely search for just such an application rather than creating it in-house. However, it is not possible to buy an information system off-the-shelf. The procedures for reserving facilities, confirming reservations, and so on all need to be integrated into Fox Lake's business processes. Employees who fulfill process roles need to be trained on those procedures. The most we can say is that the hardware, software, and database design components can be purchased off-the-shelf. The database data, the procedures, and the people are all provided in-house. Furthermore, even if the vendor of the application includes business processes as part of the package, as ERP vendors do, those business processes are not yours until you have integrated them into your business and trained your employees. Keep this in mind when you manage a department that is to receive a new information system or an upgrade. You need to allow time for such integration and training, and you should expect there will be mistakes and problems as the new application is first put into use. Q5 What Are Systems Development Activities? As you just learned, systems development can come before business processes or it can be a result of business processes. Given this uncertainty, how can you study systems development activities? Examine Figure 10-12 again. It shows the basic phases of the systems development life cycle, the most commonly used process for creating information systems. If we put those phases into the context of Figure 10-11, we will obtain the diagram in Figure 10-13. Whether you use the process in Figure 10-12 (systems first) or the process in Figure 10-13 (processes first), the same basic activities are involved in creating IS components: Define the system. Determine the requirements. Design system components. Implement the system (Figure 10-12). Q5 What Are Systems Development Activities? Business Process Modeling Stage Figure 10-13 BPM Provides Requirements for Systems Development BPM Create Components Stage System Need Project Plan Define System Determine Requirements Approved Requirements Design System Components System Design Create & Test Components System Components BPM Implement Processes Stage Assess Results Stage 345 Create and test components and implement the system (Figure 10-13). Maintain the system (Figure 10-12). Assess process results (Figure 10-13). So, if you learn the nature of the work for each of these activities, you will be well prepared to participate as a user, manager, and business professional in development activities regardless of which approach your organization takes. As indicated, there are some important differences in the implementation and maintenance/assess activities, but we can deal with those differences as we go. So, consider the nature of the work for each of these activities. Define the System In response to the need for the new system, the organization will assign a few employees, possibly on a part-time basis, to define the new system, assess its feasibility, and plan the project. In a large organization, someone from the IS department leads the initial team, but the members of that initial team are both users and IS professionals. For an organization like Fox Lake, the team would most likely be led by an outside consultant like Laura. Define System Goals and Scope As shown in Figure 10-14, the first step is to define the goals and scope of the new information system. Is the goal of the new system only to implement the elements BusinessPlanning Process System Need System Definition Define system goals and scope. Assess feasibility (cost, schedule, technical, organizational). Form project team. Plan project. The cost of a project can be determined in a number of ways. For a discussion of a few of the ethical issues relating to cost estimates, see the Ethics Guide on pages 346-347. Figure 10-14 SDLC: System Definition Phase Project Plan Requirements Analysis Ethics Guide Estimation Ethics A buy-in occurs when a company agrees to produce a system or product for less than it knows the project will require. Laura could buy-in at Fox Lake if she agreed to build the system for, say, $50,000, when good estimating techniques indicate it will take $75,000. If the contract for the system or product is written for \"time and materials,\" Fox Lake will ultimately pay Laura the $75,000 for the finished system. Or, Fox Lake will cancel the project once the true cost is known. If the contract for the system or product is written for a fixed cost, then Laura will eat the extra costs. She'd use the latter strategy if the contract opens up other business opportunities that are worth the $25,000 loss. Buy-ins always involve deceit. Most would agree that buying in on a time-and-materials project, planning to stick the customer with the full cost later, is unethical and wrong. Opinions on buying in on a fixed-priced contract vary. You know you'll take a loss, but why? For a favor down the road? Or some other unethical reason? Some would say that because buying in is always deceitful, it should always be avoided. Others say that it is just one of many different business strategies. What about in-house projects? Do the ethics change if an in-house development team is building a system for use in-house? If team members know there is only $50,000 in the budget, should they start the project if they believe that its true cost is $75,000? If they do start, at some point senior management will either have to admit a mistake and cancel the project or find the additional $25,000. Project sponsors can 346 make all sorts of excuses for such a buy-in. For example, \"I know the company needs this system. If management doesn't realize it and fund it appropriately, then we'll just force their hand.\" These issues become even stickier if team members disagree about how much the project will cost. Suppose one faction of the team believes the project will cost $35,000, another faction estimates $50,000, and a third thinks $65,000. Can the project sponsors justify taking the average? Or, should they describe the range of estimates? Other buy-ins are more subtle. Suppose you are a project manager of an exciting new project that is possibly a career-maker for you. You are incredibly busy, working 6 days a week and long hours each day. Your team has developed an estimate for $50,000 for the project. A little voice in the back of your mind says that maybe not all costs for every aspect of the project are included in that estimate. You mean to follow up on that thought, but more pressing matters in your schedule take precedence. Soon you find yourself in front of management, presenting the $50,000 estimate. You probably should have found the time to investigate the estimate, but you didn't. Is your behavior unethical? Or, suppose you approach a more senior manager with your dilemma. \"I think there may be other costs, but I know that $50,000 is all we've got. What should I do?\" Suppose the senior manager says something like, \"Well, let's go forward. You don't know of anything else, and we can always find more budget elsewhere if we have to.\" How do you respond? You can buy in on schedule as well as cost. If the marketing department says, \"We have to have the new product for the trade show,\" do you agree, even if you know it's highly unlikely? What if marketing says, \"If we don't have it by then, we should just cancel the project.\" Suppose it's not impossible to make that schedule, it's just highly unlikely. How do you respond? \u0002 Discussion Questions 1. Do you agree that buying in on a cost-and-materials project is always unethical? Explain your reasoning. Are there circumstances in which it could be illegal? 2. Suppose you learn through the grapevine that your opponents in a competitive bid are buying in on a timeand-materials contract. Does this change your answer to question 1? 3. Suppose you are a project manager who is preparing a request for proposal on a cost-and-materials systems development project. What can you do to prevent buy-ins? 4. Under what circumstances do you think buying in on a fixed-price contract is ethical? What are the dangers of this strategy? 5. Explain why in-house development projects are always time-and-materials projects. 6. Given your answer to question 5, is buying in on an in-house project always unethical? Under what circumstances do you think it is ethical? Under what circumstances do you think it is justifiable, even if it is unethical? 7. Suppose you ask a senior manager for advice as described in the Guide. Does the manager's response absolve you of guilt? Suppose you ask the manager and then do not follow her guidance. What problems result? 8. Explain how you can buy in on schedule as well as costs. 9. For an in-house project, how do you respond to the marketing manager who says that the project should be cancelled if it will not be ready for the trade show? In your answer, suppose that you disagree with this opinionsuppose you know the system has value regardless of whether it is done by the trade show. 347 348 CHAPTER 10 Business Process and Information Systems Development required for the processes in Figure 10-11? Or, is the new system broader in scope? Should the new system consider unscheduled maintenance as well as scheduled maintenance? Are departments other than wedding planning going to use this new system? Are there other needs for facility use data? Does Jeff, for example, want reports that show the utilization of facilities? These questions are asked and answered as part of the definition phase. Assess Feasibility Given the goals and scope of the new system, the next task is to assess feasibility. \"Does this project make sense?\" The aim here is to eliminate obviously nonsensical projects before forming a project development team and investing significant labor. Feasibility has four dimensions: cost, schedule, technical, and organizational feasibility. Because IS development projects are difficult to budget and schedule, cost and schedule feasibility can be only an approximate, back-of-the-envelope analysis. The purpose is to eliminate any obviously infeasible ideas as soon as possible. Technical feasibility refers to whether existing information technology is likely to be able to meet the needs of the new system. The new system at Fox Lake is well within the capabilities of existing technology. For more advanced systems, this is not always the case. Between 1995 and 2005, the IRS engaged in a 10-year information systems project disaster when it attempted to use new technology to revamp tax return processing without assessing the technical feasibility. Finally, organizational feasibility concerns whether the new system fits within the organization's customs, culture, charter, or legal requirements. At Fox Lake, for example, is a daily maintenance schedule appropriate? Are there union regulations that stipulate that workers need to have advanced notice of hours to be worked? Does the system need to prepare a weekly or monthly schedule to comply with these rules? Form a Project Team If the defined project is determined to be feasible, the next step is to form the project team. Normally, the team consists of both IT personnel and user representatives. The project manager and IT personnel can be in-house personnel or outside contractors. We will describe various means of obtaining IT personnel using outside sources and the benefits and risks of outsourcing when we discuss IS management in the next chapter. Typical personnel on a development team are a manager (or mangers for larger projects), business analysts, system analysts, programmers, software testers, and users. A business analyst is someone who is well versed in Porter's models, organizational strategy, and systems alignment theory, like COBIT, and who also understand the proper role for technology. As shown in Figure 10-15, business analysts work primarily with business processes as well as with systems development at a high level. Systems analysts are IS professionals who understand both business and technology. They are active throughout the systems development process and play a key role in moving the project through the systems development process. Systems analysts integrate the work of the programmers, testers, and users. Depending on the nature of the project, the team may also include hardware and communications specialists, database designers and administrators, and other IT specialists. As shown in Figure 10-15, systems analysts work with process design as well, but their primary focus is information systems development. The team composition changes over time. During requirements definition, the team will be heavy with business and systems analysts. During design and implementation, it will be heavy with programmers, testers, and database designers. During integrated testing and conversion, the team will be augmented with testers and business users. Q5 What Are Systems Development Activities? Business Focus Technology Focus Business Process Management Systems Development Database, Software, Hardware Development Business Analysts Systems Analysts Database Designers Computer Programmers Test Engineers Hardware & Network Specialists User involvement is critical throughout the system development process. Depending on the size and nature of the project, users are assigned to the project either full or part time. Sometimes users are assigned to review and oversight committees that meet periodically, especially at the completion of project phases and other milestones. Users are involved in many different ways. The important point is for users to be actively involved in and take ownership of the project throughout the entire development process. The first major task for the assembled project team is to plan the project. Members of the project team specify tasks to be accomplished, assign personnel, determine task dependencies, and set schedules. We will discuss this further in Q6. Determine Requirements Determining the system's requirements is the most important phase in the systems development process. If the requirements are wrong, the system will be wrong. If the requirements are determined completely and correctly, then design and implementation will be easier and more likely to result in success. Examples of requirements in Figure 10-9 are the contents of the Facility Use Report or the fields to be provided in the Facilities Needed data flow. Requirements include not only what is to be produced, but also how frequently and how fast it is to be produced. Some requirements specify the volume of data to be stored and processed. If you take a course in systems analysis and design, you will spend weeks on techniques for determining requirements. Here, we will just summarize that process. Typically, systems analysts interview users and record the results in some consistent manner. Good interviewing skills are crucial; users are notorious for being unable to describe what they want and need. Users also tend to focus on the tasks they are performing at the time of the interview. Tasks performed at the end of the quarter or end of the year are forgotten if the interview takes place mid-quarter. Seasoned and experienced systems analysts know how to conduct interviews to bring such requirements to light. As listed in Figure 10-16, sources of requirements include existing systems as well as the forms, reports, queries, and application features and functions desired in the new system. Security is another important category of requirements. If the new system involves a new database or substantial changes to an existing database, then the development team will create a data model. As you learned in 349 Figure 10-15 Focus of Personnel Involved in BPM and Systems Development 350 CHAPTER 10 Business Process and Information Systems Development Figure 10-16 SDLC: Requirements Analysis Phase System Definition Project Plan Requirements Analysis Conduct user interviews. Evaluate existing systems. Determine new forms/reports/queries. Identify new application features and functions. Consider security. Create the data model. Consider all five components. Approved User Requirements Component Design Chapter 5, that model must reflect the users' perspective on their business and business activities. Thus, the data model is constructed on the basis of user interviews and must be validated by those users. Sometimes the requirements determination is so focused on the software and data components that other components are forgotten. Experienced project managers ensure consideration of requirements for all five IS components, not just for software and data. Regarding hardware, the team might ask: Are there special needs or restrictions on hardware? Is there an organizational standard governing what kinds of hardware can, or cannot, be used? Must the new system use existing hardware? What requirements are there for communications and network hardware? Similarly, the team should consider requirements for procedures and personnel: Do accounting controls require procedures that separate duties and authorities? Are there restrictions that some actions can be taken only by certain departments or specific personnel? Are there policy requirements or union rules that restrict activities to certain categories of employees? Will the system need to interface with information systems from other companies and organizations? In short, requirements need to be considered for all of the components of the new information system. These questions are examples of the kinds of questions that must be asked and answered during requirements analysis. Design System Components Each of the five components is designed in this stage. Typically, the team designs each component by developing alternatives, evaluating each of those alternatives against the requirements, and then selecting from among those alternatives. Accurate requirements are critical here; if they are incomplete or wrong, then they will be poor guides for evaluation. Figure 10-17 shows that design tasks pertain to each of the five IS components. For hardware, the team determines specifications for the hardware that they want to acquire. (The team is not designing hardware in the sense of building a CPU or a disk drive.) Program design depends on the source of the programs. For off-the-shelf software, the team must determine candidate products and evaluate them against the requirements. For off-the-shelf with alteration programs, the team identifies products to be acquired off-the-shelf and then determines the alterations required. For custom-developed programs, the team produces design documentation for writing program code. If the project includes constructing a database, then during this phase database designers convert the data model to a database design using techniques like those described in Chapter 5. If the project involves off-the-shelf programs, then little database design needs to be done; the programs will have been coded to work with a pre-existing database design. Q5 What Are Systems Development Activities? Requirements Analysis Figure 10-17 SDLC: Component Design Phase Approved User Requirements Component Design Determine hardware specifications. Determine program specifications (depends on source). Design the database. Design procedures. Create job definitions. 351 System Design Implementation Procedure design differs depending on whether the project is part of a BPM process (processes first) or is part of a systems development process (systems first). If the former, then business processes will already be designed, and all that is needed is to create procedures for using the application (like those shown in blue in Figure 10-9). If the latter, then procedures for using the system need to be developed, and it is possible that business processes that surround the system need to be developed as well. With regard to people, design involves developing job descriptions for the various roles. These descriptions will detail responsibilities, skills needed, training required, and so forth. Implementation Activities The term implementation has two meanings for us. It could mean to implement the information systems components, only, or it could mean to implement the information system and the business processes that use the information system. As you read the following task descriptions, keep in mind that the tasks can apply to both interpretations of implementation. Tasks in the implementation phase are to build and test system components and to convert users to the new system and possibly new business processes (see Figure 10-18). Developers construct each of the components independently. They obtain, install, and test hardware. They license and install off-the-shelf programs; they write adaptations and custom programs as necessary. They construct a database and fill it with data. They document, review, and test procedures, and they create training programs. Finally, the organization hires and trains needed personnel. Design Components Figure 10-18 SDLC: Implementation Phase System Design Implementation Build system components. Conduct unit test. Integrate components. Conduct integrated test. Convert to new system. Installed System Users 352 CHAPTER 10 Business Process and Information Systems Development Testing the system is important, time consuming, and expensive. A test plan, which is a formal description of the system's response to use and misuse scenarios, is written. Professional test engineers, called product quality assurance (PQA) test engineers, are hired for this task. Often teams of professional test engineers are augmented by users as well. System Conversion Once the system has passed testing, the organization installs the new system. The term system conversion is often used for this activity because it implies the process of converting business activity from the old system to the new. Again, conversion can be to the new system, only, or it can be to the new system, including new business processes. Four types of conversion are possible: pilot, phased, parallel, and plunge. Any of the first three can be effective. In most cases, companies should avoid \"taking the plunge\"! With pilot installation, the organization implements the entire system/business processes on a limited portion of the business. An example would be for Fox Lake to use the new system for a few wedding events. The advantage of pilot implementation is that if the system fails, the failure is contained within a limited boundary. As the name implies, with phased installation the new system/business processes are installed in phases across the organization(s). Once a given piece works, then the organization installs and tests another piece of the system, until the entire system has been installed. Some systems are so tightly integrated that they cannot be installed in phased pieces. Such systems must be installed using one of the other techniques. With parallel installation, the new system/business processes run in parallel with the old one until the new system is tested and fully operational. Parallel installation is expensive, because the organization incurs the costs of running both the existing and new system/business processes. Users must work double-time, if you will, to run both systems. Then, considerable work is needed to reconcile the results of the new with the old. The final style of conversion is plunge installation (sometimes called direct installation). With it, the organization shuts off the old system/business processes and starts the new one. If the new system/business processes fail, the organization is in trouble: Nothing can be done until either the new system/business processes are fixed or the old system/business processes are reinstalled. Because of the risk, organizations should avoid this conversion style if possible. The one exception is if the new system is providing a new capability that will not disrupt the operation of the organization if it fails. Figure 10-19 summarizes the tasks for each of the five components during the design and implementation phases. Use this figure to test your knowledge of the tasks in each phase. What Are the Tasks for System Maintenance? Here, we will consider system maintenance in the sense of the process in Figure 10-12, only. The tasks that concern maintenance of business processes are subsumed under the assess results phase of the BPM cycle. With regard to information systems, maintenance is a misnomer; the work done during this phase is either to fix the system so that it works correctly or to adapt it to changes in requirements. Figure 10-20 shows tasks during the maintenance phase. First, there needs to be a means for tracking both failures1 and requests for enhancements to meet new 1 A failure is a difference between what the system does and what it is supposed to do. Sometimes you will hear the term bug used instead of failure. As a future user, call failures failures, because that's what they are. Don't have a bugs list, have a failures list. Don't have an unresolved bug, have an unresolved failure. A few months of managing an organization that is coping with a serious failure will show you the importance of this difference in terms. Q5 What Are Systems Development Activities? Hardware Software Data Procedures People Determine hardware specifications. Select off-theshelf programs. Design alterations and custom programs as necessary. Design database and related structures. Design user and operations procedures. Develop user and operations job descriptions. Obtain, install, and test hardware. License and install off-theshelf programs. Write alterations and custom programs. Test programs. Create database. Fill with data. T