Page 57 -

24 Part 1 • SyStemS analySiS FundamentalS

ERP has taken root in many large companies and is spreading to small and medium-sized
enterprises as well. Thankfully, most of the lessons we as systems analysts have learned are
highly applicable to implementing enterprise systems. However, you as an analyst need to rec-
ognize and act on the similarities and differences between implementing networked information
systems and implementing an ERP.
One of the major differences is that rather than redesigning business processes based on a
logical analysis of those processes and how they support the business strategy, and then choos-
ing the IT to support those processes, a large installation of ERP can reverse this by requiring
the implementation of new business processes that are embedded in the technology provided.
Oftentimes you will be part of an internal systems team whose chief job is to look after the inter-
face between legacy systems and the ERP being installed.
Enterprise implementations are complex and intense endeavors that result in tremendous
organizational change. They can affect every aspect of the organization, including design of
employees’ work, the skills required to become competent in one’s job, and even the strategic
positioning of the company. What is clear is that implementing an ERP has become increasingly
complex. Many issues present important hurdles to clear if the ERP installation is to be declared
a success; these include user acceptance, integration with legacy systems, and the supply chain;
upgrading functionality (and complexity) of ERP modules; reorganizing work life of users and
decision makers; expanded reach across several organizations (as part of the IT supply chain);
and strategic repositioning of the company adopting an ERP.
Some areas to take particular note of include looking at the critical success factors (CSFs)
and the interplay among them when different ERP implementations, upgrades, and conversions
are approached. In addition, it’s good to consider what heuristics or rules of thumb have been
developed over time on the organizational, team, and even individual levels for how to do a suc-
cessful ERP upgrade or initial implementation.
New research has shown that while ERP implementations can result in making employees
more effective and efficient two or three years after the installation, it is in the planning and early
stages of ERP that a deep analysis examines how the new enterprise system will affect the daily
lives and jobs of employees involved in the new system (such as discussed in Chapter 14 on HCI
and usability issues). ERP systems are best considered as real game changers when it comes to
the job design of employees (including systems analysts) and as a moving force that can also
alter the strategic approaches to change that organizations take.

Depicting Systems Graphically
A system or subsystem as it exists within a corporate organization may be graphically depicted
in several ways. The various graphical models show the boundaries of the system and the infor-
mation used in the system.

Systems and the Context-Level Data Flow Diagram
The first model is the context-level data flow diagram (also called an environmental model). Data
flow diagrams focus on the data flowing into and out of the system and the processing of the
data. These basic components of every computer program can be described in detail and used to
analyze a system for accuracy and completeness.
As shown in Figure 2.4, the context-level data flow diagram employs only three symbols:
(1) a rectangle with rounded corners, (2) a square with two shaded edges, and (3) an arrow.
Processes transform incoming data into outgoing information, and the content level has only one
process, representing the entire system. The external entity represents any entity that supplies or
receives information from the system but is not a part of the system. This entity may be a person,
a group of people, a corporate position or department, or other systems. The lines that connect
the external entities to the process are called data flows, and they represent data.
An example of a context-level data flow diagram is found in Figure 2.5. This example repre-
sents the most basic elements of an airline reservation system. The passenger (an entity) initiates a
travel request (data flow). The context-level diagram doesn’t show enough detail to indicate exactly
what happens (it isn’t supposed to), but we can see that the passenger’s preferences and the avail-
able flights are sent to the travel agent, who sends ticketing information back to the process. We
can also see that the passenger reservation is sent to the airline. The context-level data flow diagram
serves as a good starting point for drawing the use case diagram (discussed later in this chapter).