Chapter 4—Q and A Answers to End of Chapter Questions 1. Explain the difference between an As-Is and a To-Be system. The As-Is system is the combination of people, processes, data, and technology that currently perform the tasks and functions of the system under study. The As-Is system may or may not incorporate computers. The To-Be system is the combination of people, processes, data, and technology that will perform the required tasks and functions of the system under study. 2. What are the basic steps in the analysis process?  Understand the As-Is System - study the existing system and understand its strengths and weaknesses.  Identify Improvement Opportunities - look for ways to improve the current system, and use these ideas as the basis for the To-Be system.  Develop a System Concept - create one or more target conceptualizations for the To-Be system, including an outline of features and models of its basic design. Feasibility will be assessed, and a project work plan prepared. 3. Why are business skills important in the analysis phase? The goal of requirements analysis is to identify the necessary features and functions of the To-Be system. Business skills are important in focusing on what the new system needs to be capable of doing for the business users, regardless of the technology that Chapter 4—Q and A will be used in the system implementation. Technology itself cannot make the business successful; it must be used to address real business needs. 4. What are the principal components of a system proposal? The system proposal culminates the analysis process. In the system proposal, the development team presents a summary of their ideas for the new system. The proposal includes the vision and basic outline for the new system. One or more alternative configurations are described, including data and process models. Detailed feasibility analysis is included for each alternative, and the project workplan is revised for each alternative. 5. Compare and contrast the business goals of BPA, BPI, and BPR. These three business goals vary in the degree to which the basic business processes in the As-Is system are altered. With "Business Process Automation" the As-Is business processes are not substantially modified; computers are used to take over some of the tasks without significantly changing the way things are done. "Business Process Improvement" involves some evaluation and modification of the basic business processes, with a goal of making moderate changes to those processes within the new system design. "Business Process Reengineering" involves major revisions to the basic business processes, potentially making complete changes to the way the work is performed in the business area. 6. Compare and contrast problem analysis with root-cause analysis. Under what conditions would you use problem analysis? Under what conditions would you use root-cause analysis? Chapter 4—Q and A Problem Analysis and Root-Cause Analysis are two different techniques to be employed in Business Process Automation to determine improvements to the current system. The two strategies vary in the emphasis of the analysis performed. Problem Analysis asks the users and managers of the As-Is system to identify system problems and to suggest problem solution. Root-Cause analysis focuses on being sure that the problem's underlying cause is understood, rather than just assuming that cause is known. This emphasis helps ensure that solutions chosen will solve real business problems rather than solving a problem symptom. Problem analysis would be suitable when the problems being experienced with the As-Is system are relatively minor, and the changes needed are primarily 'touch-ups'. Root-Cause Analysis is appropriate when the problems of the As-Is system are more significant, and the team needs assurance that they are designing a solution that really solves the true problems. 7. Compare and contrast informal benchmarking, proxy benchmarking, and formal benchmarking. Benchmarking is an analysis strategy that uses ideas learned from other businesses and industries to form the basis of the new system requirements. The techniques of informal benchmarking, proxy benchmarking, and formal benchmarking vary in terms of the scope of the benchmark study. Informal benchmarking involves observing the customer-oriented systems/processes of another organization. Proxy benchmarking broadens the study to industries that have similar structures to the business processes under analysis, and attempts to generate new ideas from these comparisons. Formal benchmarking involves establishing a formal partnering relationship with other businesses, exchanging a thorough analysis of each partners' systems and processes. 8. Compare and contrast duration analysis and activity-based costing. Duration analysis and activity-based costing are techniques used in Business Process Chapter 4—Q and A Improvement to help identify system improvement opportunities. These two techniques focus on existing business processes in the As-Is system. "Duration Analysis" assesses the time requirements to complete a process. First, the total time required to complete a business process is determined. Then the process is broken down into individual steps, and the time required to complete each step is determined. The total time of all steps is calculated and compared to the total time of the process. If these totals are substantially different (total time of process > total time of process steps), then significant inefficiencies exist, and the process needs major revision. "Activity-Based Costing" assesses the costs required to perform a process. In this technique, the cost of each major process or each step in a business function is measured. The most costly processes are then the targets of the development team's improvement efforts. Although straightforward in concept, this technique is complex in practice due to the difficulty of determining the indirect costs to apply to the business process(es). Incorrectly assigned indirect costs may bias the results of the analysis. 9. Compare and contrast root cause analysis, breaking assumptions, and outcome analysis. The "Root Cause Analysis' technique is a part of the Business Process Automation strategy, while "Breaking Assumptions" and "Outcome Analysis" are Business Process Reengineering techniques. Root Cause Analysis is most likely to be applied when automating a system, while Breaking Assumptions and Outcome Analysis is used when reengineering a system (i.e., small to moderate change in business processes versus radical change in business processes). Root Cause Analysis seeks to define the new system requirements by identifying solutions to the true underlying problems found in the current business processes. Root Cause Analysis is generally an internally-oriented technique. Outcome Analysis, on the other hand, evaluates the fundamental value of the business process from the perspective of the customers of that process. Breaking Assumptions involves identifying the fundamental business rules that are assumed to apply to the business area under study. Each rule is then broken and the team identifies Chapter 4—Q and A how the business would benefit from the change. The team may identify radical new ways to redesign the business in this way. Outcome Analysis seeks to define the customer's view of the real goal of the business function, and is an externally-oriented technique. Outcome Analysis may help give the analysts a fresh perspective on how the business operates. 10. Compare and contrast technology analysis with root cause analysis. The "Technology Analysis" technique is a part of the business process reengineering strategy. Technology Analysis attempts to create new way of thinking about the business processes by focusing first on new and innovative technologies. The analysis team generates a list of promising technologies, then works through this list, generating ideas on how each technology could be applied to the business processes. By identifying beneficial new applications of technology, the team may create radically redesigned business processes around that technology. Root Cause Analysis seeks to define the new system requirements by identifying solutions to the true underlying problems found in the current business processes. 11. Under what conditions would formal benchmarking be important? Benchmarking is an analysis strategy that uses ideas learned from other businesses and industries to form the basis of the new system requirements. Formal benchmarking would be useful when external ideas and reference points would be valuable to a business, but informal or proxy benchmarks are unavailable or inappropriate. 12. Assuming time and money were not important concerns, would BPR projects benefit from additional time spent understanding the As-Is system? Chapter 4—Q and A No, the effort spent understanding the As-Is system in BPR only needs to be minimal since the goal of BPR is to eliminate current business processes. The team only needs a basic understanding of the essence of the As-Is system, and the quality of the BPR project would not be enhanced by spending more time and money looking at the As-Is system. 13. What are the key factors in selecting an appropriate analysis strategy? One factor is the potential value to the business. BPA and BPI both will add low to moderate value to the business because they strive to make incremental changes to the as-is system. BPS, on the other had, has the potential to add significant value to the business because it will make sweeping changes to the business's processes. The strategies also differ in terms of cost. BPR will probably have significant costs associated with it, while costs of BPA and BPI will be much more modest. The breadth of the analysis will also vary between the strategies. BPR will tackle a much broader piece of the organization, while BPA and BPI are narrower in scope. Finally, risk as a factor that distinguishes the strategies. BPR, because it attempts more broad, significant changes, is far more risky than the narrower, more limited BPA or BPI strategies. To select an appropriate strategy, the project sponsor needs to evaluate his/her goals for the project. If the problems being experiences suggest that radical redesign of business processes is necessary and the organization has the funding and can tolerate the risk, then a BPR project may be called for. If more moderate changes are required, or funding is limited, or high risks cannot be tolerated, then BPI is recommended. When only minor changes are needed because the existing business processes are acceptable, then BPA is the strategy of choice. Chapter 4—Q and A 14. Which do you think is most common today, BPA, BPI, or BPR? Why? Probably BPI is the most common. BPA may be the goal of many systems, but there are so many small ways to improve business processes during the automation that it is not infrequent that a project will slip into BPI. On the other hand, BPR is generally viewed as relatively high risk and many firms will want to minimize risk to the degree that they can. A good number of firms have used BPR or a combination of BPI and BPR for replacing a number of systems with ERP or enterprise resource planning systems that bring major transformation to firms. 15. What re the biggest challenges to success in BPA, BPI, BPR? The biggest challenge to success with BPA is that automating convoluted business processes will not bring the great advantages of computerization to bear. It is probably the most likely development approach to come in under budget and on time, but it is unlikely to deliver the benefits that most firms would seek in developing new systems. Similarly with BPI, if the overall thrust of the organization and its business processes are outmoded and outdated, there will not be sufficient return for the effort of new system development. BPR has the opposite problem. It is most likely to totally transform the organization, when it works, but BPR has an unfortunate record of inconsistency. Many organizational characteristics are need for success in this area. It is too easy to leave out critical steps that appear irrational in the old system, but are vital for the new system. It is also too easy to have such a large project bog down in massive numbers of detail. 16. What do you think are three common mistakes novice analysts make in conducting the analysis process? Chapter 4—Q and A (1). Spending too little time examining the underlying issues confronting the business (e.g. not performing root-cause and related analyses); (2) Failing to systematically develop organizational knowledge about prior projects for purposes of constant improvement in estimation; (3) Insufficiently identifying, tracking, and resolving the sources of risk in the project.
Pages to are hidden for
"Answers to End of Chapter Questions"Please download to view full document