Chapter 4Q 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?

[1] Understand the As-Is System - study the existing system and understand its
strengths and weaknesses.
[2] Identify Improvement Opportunities - look for ways to improve the current system,
and use these ideas as the basis for the To-Be system.
[3] Develop a System Concept - create one or more target conceptualizations for the ToBe 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
will be used in the system implementation. Technology itself cannot make the business
successful; it must be used to address real business needs.

Chapter 4Q and A

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?
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

Chapter 4Q and A

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
Improvement to help identify system improvement opportunities. These two techniques
focus on existing business processes in the As-Is system. "Duration Analysis" assesses

Chapter 4Q and A

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
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

Chapter 4Q and A

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?
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

Chapter 4Q and A

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 4Q 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 4Q 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.