Chapter 7

Application Systems Implementations

and IT Governance
THE APPLICATION SYSTEMS DEVELOPMENT
PROCESS
• was once a major concern for IT organizations. That was the time
when most IT programming and systems development functions
designed their own new systems, coded the programs using IT
department resources, and implemented and then tested the major
program components of new applications.
• This development process sometimes led to a hall of horrors for some
enterprises. The new homegrown IT applications frequently were
delivered much later than promised, were poorly tested, and did not
meet their stated objectives.
• Despite the move today from in-house developed applications to a
greater emphasis on vendor-supplied purchased software, there is
still a need for an enterprise to develop, build, and test some of its
own application systems or to custom modify purchased applications.
• This is particularly true when an enterprise today implements one of
the complex multifunction and linked databases known as enterprise
resource planning (ERP) systems. These complex vendor-supplied
systems have the ability to link virtually all application functions on
one set of interlinked databases.
• For example, when an ERP system is installed in a manufacturing
system’s environment, an order for a product can update
manufacturing and production systems, place a supplier order if
additional materials are needed, and otherwise complete production
sales and shipment processes.
• As a key element of good IT governance processes, an enterprise
needs to have strong IT systems development processes in place,
whether building applications in a more traditional manner or
licensing from a vendor for a cloud implementation.
THE SYSTEMS DEVELOPMENT LIFE CYCLE: A BASIC
APPLICATION DEVELOPMENT TECHNIQUE
• The very early years of IT applications development were filled with
new systems disasters in many enterprises. Typically, a senior
manager—often the organization’s financial controller—would tell the
head of IT that he wanted a new application to fulfill some need.
• Without too much further analysis, a programming team would then
be assembled to write programs to meet that need. The results were
often failures. The new application, if it worked and was delivered in
any reasonable period of time, often did not meet management
requirements and expectations.
• IT governance concepts were certainly unknown in those early days of
mainframe systems, COBOL programs, and primarily batch-oriented
systems, but there certainly were a lot of application development
failures. To place some order in this systems development process,
the major hardware and software vendor in those days, IBM,
launched a systems development methodology known as the systems
development life cycle (SDLC).
• Although many others have developed variations of the approach, the
SDLC approach has become a key process to develop effective IT
applications.
• Once the new application has been approved, it should move to a
formal application design and programming phase. Each of the new
system’s programs and components
• should be developed, documented, and then unit tested. We then
move to a total systems testing and implementation phase, leading to
the system implementation.
• The whole concept behind the SDLC process is that once we have
implemented the new application, IT and enterprise management
should be monitoring its success and progress. This may lead to a
need for system revisions or a totally new application. Thus the SDLC
is a continuous improvement process for development and ongoing
monitoring of new IT applications. Historically, it went back to
mainframe and batch systems and required detailed approvals and
documentation of each process step.
• Even though we now have moved to rapid development, and
prototyping application development processes largely rely on
vendor-supplied software, these basic SDLC elements should be in
place for any IT new applications development process. That is, new
systems applications should always go through some formal system
requirements analysis, formal application launches, and processes to
improve and retire them in their later lives.
IT RAPID DEVELOPMENT PROCESSES:
PROTOTYPING
• The use of formal SDLC processes made a lot of sense in the earlier
days of IT systems, when enterprises fully developed and
programmed their own applications and when there was a need to
document and formalize new application development processes.
PROTOYPING
RAPID APPLICATION DEVELOPMENT
• The RAD process starts with the development of preliminary data and
business process models to define preliminary requirements. Using
one of the powerful report generator software tools available today, a
sample or prototype version of the application can be created. The
prototype model is then verified against the requirements to refine
the data and process models.
• These stages are repeated iteratively; further development results in
a combined business requirements and technical design statement to
be used for constructing new systems.
• RAD approaches often entail compromises in functionality and
performance in exchange for enabling faster development and
facilitating application maintenance. The RAD systems process
consists of the following four phases:
1. RAD requirements planning phase. Enterprise IT should use some of
the same elements found in the systems planning and systems analysis
phases of a traditional SDLC process as outlined in Exhibit 15.2.
However, under RAD, the users, managers, and IT staff members
discuss and agree on business needs, project scope, constraints, and
system requirements. This phase ends when the team agrees on the
key issues and obtains management authorization to continue.
2. RAD user design phase. Here, users interact with systems analysts
and develop models and prototypes that represent all system
processes, inputs, and outputs. The RAD groups or subgroups will
typically use IT department application development tools to translate
user needs into working models. This user design phase is a continuous
interactive process that allows users to understand, modify, and
eventually approve a working model of the system that meets their
needs.
3. Construction phase. This RAD phase focuses on program and
application development tasks similar to the SDLC. In RAD, however,
users continue to participate and can still suggest changes or
improvements as actual screens or reports are developed. Its tasks are
programming and application development, coding, unit integration,
and system testing.
4. RAD cutover phase. This final phase resembles the final tasks in a
SDLC implementation, including data conversion, testing, changeover
to the new system, and user training. Compared with traditional
methods, the entire process is compressed. As a result, the new system
is built, delivered, and placed in operation much sooner. Its tasks are
data conversion, full-scale testing, system changeover, and user
training.
• The RAD systems development approach was initiated at about the
time that enterprises and their IT functions began the transition from
classic mainframes to client–server systems, during the growing
predominance of desktop and laptop systems and most significantly
the Internet. Going back to the mainframe SDLC days, many
enterprise IT users had expressed frustration with the slow
development processes, new system failures, missed budgets, and a
host of other problems.
ENTERPRISE RESOURCE PLANNING AND
IT GOVERNANCE PROCESSES
• Typically employing a comprehensive database as an information
repository, ERP systems integrate internal and external management
information across an entire enterprise, embracing their
finance/accounting, manufacturing when appropriate, sales and
service, customer relationship management, and so on. ERP systems
are complex databases that automate this activity through an
integrated software application. Their purpose is to facilitate the flow
of information between all business functions inside the boundaries
of the organization and manage the connections to outside
stakeholders.
• We can think of the functions of an ERP system through the process
of manufacturing where some product part needs to be designed,
resources ordered to build the part, part costing and marketing
processes established for the part, material orders placed, and
production started, and then the entire stream of production and
operational processes for receiving a customer order, shipping, and
billing for the item. These processes and others involve a series of
separate but interrelated activities that were once managed by a
series of separate IT applications such as receiving, inventory control,
production scheduling, shipping, accounts receivable, and more. An
ERP system ties together all of these activities and more into a tightly
linked series of database functions.
• An ERP system attempts to integrate all departments and functions
across a company onto a single computer system that can serve all its
different departments’ particular needs. This can be a tall order to
build a single software program that serves the needs of people in
finance as well as the people in human resources and in the
warehouse. Prior to ERP, each of those departments typically would
have its own computer system optimized for the particular ways that
the department does its work.
• But ERP combines them all together into a single, integrated software
system that runs off a single database, allowing the various
departments to easily share information and communicate with each
other. That integrated approach can have a tremendous payback if
companies install the software correctly.
• There are many ways to describe an ERP system, but Exhibit 15.5
shows basic accounting data flows for an enterprise business,
including purchase orders, accounts payable, and other typical
business systems processes that would be part of an ERP system.
These are the elements of the systems requirements to build a
manufacturing part, described previously, and were traditionally
separate systems processes with key data and transaction fi les for
each as well as links to other key applications, such as the general
ledger system. While this exhibit shows a series of manufacturing
distribution processes, such as traditional accounts receivable and
accounts payable functions, a complete ERP application for an
enterprise would include a much larger array of systems, such as
marketing and human resources. They would all be tied together
through common data descriptions and links.
From an IT governance perspective, there are some key points
to consider when implementing an ERP database for an
enterprise:
• Define ERP objectives and requirements. This is a relatively new IT
systems concept; there is much published hype about what a
comprehensive ERP database might accomplish. However, based on
their knowledge of what a comprehensive ERP database might
accomplish, project initiators should develop strong objectives and
requirements for a new ERP implementation project.
• Build a cross-functional project team. An ERP database is more than
just a new IT system but will involve many members of an enterprise.
A cross-functional team of IT and members of the user community
should be appointed to lead the upcoming ERP project.
• Recognize the costs and time requirements to implement ERP. For a
single-unit enterprise with 25 to 1,000 employees, a smaller ERP
database software package can cost up to $250,000, while for a larger
multi-unit enterprise with up to 5,000 users, the basic ERP software
may cost up to $2 million. An enterprise should develop realistic
expectations of the time requirements for this level of project and
assume that such a major IT project will require at least one year.
• Select an ERP software product. There are a large number of vendors
offering ERP software, with major providers such as SAP, Oracle, and
Microsoft, as well as less familiar vendors such as Epicor. To avoid an
endless stream of vendor meetings and glossy promotional materials,
the selections team should stand firm on their defined requirements
and budget objectives as well as the enterprise’s current software
environment. Any viable ERP software vendor should be able to
supply a representative test version of their ERP product.
• Apply formal project management techniques to the ERP
implementation. Chapter 16 outlines formal project and program
planning techniques. Since an ERP is a major undertaking, an
enterprise should develop and follow formal project planning
methodologies for a major ERP endeavor.
• Establish a test database for the ERP and begin phased
implementation. Once it is up and running, the enterprise ERP
application will impact a large number of regular applications.
However, care should be given to launching a phased implementation
on an application-by-application basis, using the test database in the
earlier stages of the project.
• Provide extensive user training. The new ERP application may involve
new transaction formats and other sometimes small but subtle
systems changes. As part of the project plan and as a responsibility
for the ERP implementation team members, there should be a strong
user training program.
• Establish project budgets and closely monitor ERP system costs.
Beyond the license fees for the selected database software, an ERP
project can be an expensive undertaking for an enterprise. Project
team members as well as others involved with the effort should be
required to log their hours as well as charging any direct expenses to
the ERP project. These charged expenses should be closely monitored
and questioned when appropriate, however. As a really fundamental
IT governance concern, it can sometimes be a problem when staff
members charge their hours to a project even though they are not
really performing direct project activities.
• Establish an exit strategy, if necessary. A well-planned and well-
executed ERP implementation can yield some major tangible and
intangible advantages to an enterprise, but things can sometimes go
wrong. For example, some of the ERP database vendor’s software
features may not quite work as promised or expected, there may be
technical problems with systems interfaces, or any of a host of other
potential problems. As the old expression goes, rather than throwing
good money after bad, the ERP team should develop an exit strategy
to gracefully end project efforts and return to normal IT and business
operations.