Please answer and provide any reference citations. This is due Saturday Midnight Eastern
Standard Time. Reference Modules/Commentary provided at the end after test.
Instructions:
Use the Case Study presented here to answer the questions below. Your responses should
demonstrate your understanding of the course content and your analysis and critical thinking; you
are not expected to just re-iterate what is in the textbook and the course modules, but to integrate
the information and relate it to the Case Study. Answers will be in the form of a list or short
answers, as indicated in the questions. Proper APA style must be used for any citations and
references that you use. Your Exam will be graded on the accuracy of your responses and
whether you have appropriately tied your response to the Case Study. Responses that do not
mention the Case Study will receive very few points, if any. Each question is worth 10 points.
Case Study
Ellington Galleries, Inc. is a custom framing business with outlets in Maryland, Georgia and New
York. Tammy Ellington, the owner, started the business in Maryland with a small shop in a strip
mall. With her creative design solutions, her customer base grew quickly and she opened a
larger store nearby. Her frame supplier, Macklin Frames, is in Georgia, and during a visit there
she became aware of the opportunity to acquire a medium-sized framing store that also does
business with her supplier. Using proceeds from her lucrative business, she acquired her second
outlet, retaining the employees who had worked there for several years. Tammy orders the
special glass for her framed products from Virginia Glass Co., which specializes in light-reflecting
museum glass. Recently Tammy opened a framing shop in New York, which is managed by her
sister, giving Ellington Galleries a third outlet. Tammy’s business has grown so quickly that she
can no longer keep track of things. She now has several employees at the three locations,
hundreds of customers, and bills and invoices that she can no longer manage manually.
Rather than stock huge amounts of framing materials and glass, Ellington Galleries orders the
frame and glass at the time it receives the customer’s order. So, all of the Galleries need to know
what framing styles Macklin Frames has available and at what prices. Since the glass is cut at
the manufacturing facility (Virginia Glass), it must be custom ordered and shipped to the
appropriate Gallery to be combined with the item to be framed and the frame. Ellington Galleries
could reduce its shipping costs on both frames and glass if it combined orders to be shipped to a
specific store.
Tammy is sure that she could use information technology solutions to improve management of
her business in several ways. She has hired you to lay out some options for her. She has asked
for three different areas where IT could be applied and the value that each IT solution would
provide her. She has also asked you to suggest which one would be best to start with and why.
She has asked for a list of hardware and software that she will need for her office, where she will
keep the electronic files for her business. Finally, she wants to know what would need to be done
to implement your suggested solution.
1. Identify three areas where IT could be applied to improve management of Ellington
Galleries.
a. _________________________
b. _________________________
c. _________________________
2. Explain how each solution would benefit the Galleries, specifically addressing how it
could improve business intelligence (BI) and decision-making and/or overall management
of the business .
a. ________________________________________________________________
________________________________________________________________
________________________________________________________________
b. ________________________________________________________________
________________________________________________________________
________________________________________________________________
c. ________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
3. Identify which of the three solutions you would suggest be implemented first and explain
why you chose that solution over the others.
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
4. Name five IT best practices and methodologies and briefly explain how they apply to the
IT solution named in #3 above.
a. _______________________________________________
b. _______________________________________________
c. _______________________________________________
d. _______________________________________________
e. _______________________________________________
5.
Identify five hardware components that Tammy will need to buy for her main location.
a. _______________________________________________
b. _______________________________________________
c. _______________________________________________
d. _______________________________________________
e. _______________________________________________
6. Identify five software suites/programs that Tammy will need for her office.
a. _______________________________________________
b. _______________________________________________
c. _______________________________________________
d. _______________________________________________
e. _______________________________________________
7. Identify three different connectivity requirements – what locations or businesses need to
be connected and for what purpose(s).
a. _______________________________________________
b. _______________________________________________
c. _______________________________________________
8. Do some research and list four software products that Tammy can use to protect her data
and her systems. These are to be specific products available in the marketplace, not
general types of software.
a. _______________________________________________
b. _______________________________________________
c. _______________________________________________
d. _______________________________________________
9. Explain how Tammy could benefit from implementing SCM in her business. Be sure to
address the entire supply chain in your response.
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
10. List five things Tammy would need to add to her system and processes in order to
establish a B2C eCommerce capability.
a. _______________________________________________
b. _______________________________________________
c. _______________________________________________
d. _______________________________________________
e. _______________________________________________
MODULES PROVIDED FOR
REFERENCE
Module 1: Information Management
Commentary
Topics
I.
II.
III.
Introduction
Knowledge Management
Enterprise Systems
I. Introduction
As we explore information systems in organizations, we look for ways and
opportunities for technology to support or make possible those efficiencies. This
module, Information Management, addresses aspects of finding and evaluating those
opportunities through the effective use of information derived from the use of
information systems, as well as how the strategic use of information systems
supports those opportunities.
II. Knowledge Management
A. What Is Knowledge Management?
Knowledge management (KM) is defined as "a process that helps organizations
identify, select, organize, disseminate, and transfer important information and
expertise that are part of the organization's memory and typically reside within the
organization in an unstructured manner" (Turban, Leidner, McLean, & Wetherbe,
2008, p. 390).
Before we proceed, let's distinguish among data, information, knowledge, and
wisdom.
Table 1.1
Defining Terms
Value
(increases as
you go down)
Term
data
Definition
raw facts and details about events or items; this
transaction-based data can be in the form of facts,
measurements, or statistics
information data that have been organized, grouped, or otherwise
assembled into a useful form for humans; for example,
sales transactions may be categorized by product and
grouped by time periods
knowledge
the framework by which humans use information based
on insights and experience; this makes the information
contextual, relevant, and actionable
wisdom
using human intellect and experience to apply
knowledge to address problems or situations
Over the last several decades, organizations have become more and more adept at
capturing data and translating it into operational information; however, capturing the
knowledge within an organization and making it easily available to others has been a
much more difficult challenge. Keep in mind that not all information is knowledge,
and not all knowledge is valuable. Although information contained in corporate
databases and paper documents is useful for monitoring operations, its value
increases tremendously when combined with human brainpower for strategic
advantage. Organizations must identify where the value is in sharing certain
knowledge and how best to make it available.
B. Business Drivers for Knowledge Management
Today's competitive environment presents businesses with several challenges (US
Department of Defense, 2002, p. 2):
increased focus on creating customer value and improved customer service
increasingly competitive environment that requires rapid creativity and
innovation
need to do more with less (shrinking workforce, facilities, inventories)
decrease in amount of time employees have to learn new skills and
technologies
changes in workforce (baby-boomers approaching retirement age; an
increasingly mobile workforce that can lead to loss of critical organizational
knowledge)
C. Benefits of Knowledge Management
The benefits to be gained from effective KM vary from organization to organization.
Booz Allen Hamilton can use the best thinking of its employees and bring that
expertise to new client engagements, making their services more valuable and
unique, and therefore more profitable. Walmart can use the information from its vast
experience with superior supply chain management to continue to increase
efficiencies, both within Walmart and with its suppliers. Some of the benefits KM can
achieve include (US Department of Defense, 2002, p. 3):
faster, better, and more knowledgeable decisions
increased intellectual capital throughout the organization
facilitated free flow of ideas, fostering a culture of creativity and collaboration
reduction or elimination of redundant processes, streamlined operations, and
increased employee retention
improved customer service
increased productivity
D. Types of Knowledge
Knowledge can reside in many forms within an organization and can be
either tacit or explicit. A common metaphor is to show explicit knowledge as the tip
of the iceberg. This knowledge typically resides in various documents and is easily
accessed throughout an organization. Explicit knowledge has been called leaky
knowledge in reference to how easily it can leave a document or an organization
once it has been documented.Tacit knowledge lies below the surface and may not be
easily tapped and shared across the organization. The term sticky knowledge can be
associated with tacit knowledge because it is difficult to pull it away from its source
(Turban et al., 2008, p. 392).
Figure 1.1
Explicit and Tacit Knowledge
You can see from figure 1.1 that there is a huge resource lying below the surface of
organizations. Because explicit knowledge has been documented, it can be made
accessible and distributed to others easily. The challenge is to make the tacit
knowledge more easily transferable and relevant throughout the organization.
Gartner estimates that 80 to 90 percent of what an employee knows is never
captured (Logan, 2006, p. 5).
Earlier, we discussed the importance of analyzing business processes. To identify the
best solutions, it is important to understand exactly how things are accomplished;
however, a great deal of knowledge resides in workers' heads and in tacit sources
throughout the organization. Being able to retrieve that information to understand
accurately how a process works in detail can be challenging.
Let's use packing school lunches as an example. We can easily define the inputs,
process, and output of packing a child's lunch. But in this scenario, we will explore
the tacit knowledge. Mom and Dad plan a short vacation away from the kids, and
Grandma comes to visit. When asked to define the process, Dad omits several pieces
of information that are in his head. Assuming Dad is primarily responsible for making
school lunches, he knows where all of the necessary supplies are kept, the fact that
his son prefers chips and his daughter prefers pretzels, and that beverages are
provided at school. Grandma has been left a list of instructions (the process), but
important information is missing:
Where is the peanut butter kept?
What kind of cookies do the children like?
How do they prefer their sandwiches to be cut?
Do they want the crust cut off or left on?
Do they want something to drink with their lunch?
Now, how would this relate to a workplace situation? Every day, employees perform
tasks and complete processes in their organizations that are not fully or correctly
documented. This results in potential duplicate efforts, "reinventing the wheel," and
overall reduced productivity. It may also result in employees not being able to
effectively solve a problem because they lack access to expertise that resides
somewhere else in the organization. Knowledge management is about how to
capture that information and make it easily available to whomever needs it in the
organization. Knowledge management, then, is a set of processes by which an
organization can capture, store, exchange, and apply knowledge.
Figure 1.2
Example of Explicit and Tacit Knowledge in a Household
The model shown in figure 1.3 reflects a KM process that shows how an
organization's intellectual capital can be used effectively.
Figure 1.3
KM Process Model
Source: Based on Logan (2006, p. 3)
Knowledge management does not require an information technology component.
Several employees sitting around a cafeteria table exchanging their experience on
past projects, use of software development tools, or information on recent customer
problem resolutions is knowledge sharing. In today's global work environment,
however, with the amount of information in organizations, technology can certainly
facilitate the flow and exchange of information.
In the earlier days of knowledge management, the emphasis was on collecting,
storing, managing, and reporting on the explicit knowledge in an organization.
Although this benefits an organization, we now know that the real value in KM is
integrating explicit and tacit knowledge by using formal information systems for
access and dissemination. Therefore, knowledge management systems (KMS)
involve the use of current information technologies (such as the Internet, intranets,
extranets, applications such as Lotus Notes, various software filters, agents, and
data warehouses) to "systematize, enhance, and expedite intra- and inter-firm
knowledge management" (Ahlawat, 2006, p. 392).
As indicated in figure 1.4(a), below, KM represents that intersection of people,
processes, and technology within an organization. The intersection indicates that KM
is using what already exists in the other areas, and not creating some new, unique
entity.
Figure 1.4(a)
Knowledge Management
Source: Based on US Department of Defense (2002, p. 4)
Now take a look at Porter's Competitive Forces Model.
Figure 1.4(b)
Porter's Competitive Forces Model
From a knowledge management perspective, you can apply the value of an
organization's knowledge to the various factors of competitive forces. For example,
lack of knowledge can be a barrier to new market entrants because these potential
competitors may not have the resident corporate knowledge to enter the market
successfully.
Thinking back to how organizations respond to the competitive environment and
seek to make their supply chains more efficient, the importance of getting the right
information to the right people at the right time is critical in helping an organization
be more flexible and nimble. Improving the supply chain requires information from
areas such as marketing, manufacturing, warehousing, and logistics. It sounds
simple, but when you consider tacit knowledge and look at its sources, organizations
are challenged by how to capture this information and then share it across the
organization.
E. Types of Knowledge Management Activities
An organization can capture its resident knowledge and make it more accessible
throughout the organization in many ways. Below are just a few of these methods.
Note that they may or may not be technology dependent, but think about how
technology could facilitate this knowledge exchange.
collaboration—working together to find optimal solutions to business
problems; building expertise in new technologies, market innovations, and
research and development
information sharing—sharing effective processes, documented procedures,
and lessons learned; this can be accomplished with a corporate portal or
collaborative software such as Lotus Notes
centers of excellence—using deep expertise residing within a small group
for employees across the organization
best-practice sharing—video, audio, and graphical presentations
KM: MITRE Corporation—Did You Know?
F. Impact of Organizational Culture
Effective knowledge management may clash with an organization's culture in many
ways. Historically, employees have been rewarded as individual contributors, and a
prevalent belief has been "knowledge is power, or job security." Employees may not
embrace sharing what has made them individually successful. Senior management
must foster and reward a culture in which knowledge that is owned will be shared
across the organization, and the expectation is that employees will make information
and knowledge available to everyone in as many ways as possible. Building a KM
culture requires business process redesign and integration; cultural, organizational,
and behavioral change; and appropriate technology design, development, and
integration.
G. Implementing Knowledge Management
Although a full-blown strategy for implementing knowledge management is beyond
the scope of this course, below are several tips for getting started.
1. Start small. Identify a project in which information can be fairly easily
captured, organized, and made accessible to employees.
2. Prioritize your needs. Identify those areas in which you can get the biggest
return on your investment. With the abundance of knowledge in an
organization, it would be a huge undertaking to capture everything. For
example, a pharmaceutical company invests in a KM project that results in
reducing the years needed to bring a successful drug to market, then invests
in a KM project to capture drug trial data. This investment in KM would yield
large benefits for the pharmaceutical company and therefore would be a
priority KM project.
3. Pay attention to the cultural issues. Build rewards and recognition, and
create a safe climate in which people are encouraged to share ideas.
4. Use technology judiciously. Identify your requirements first,
and then select the appropriate technology solution, if needed. Do not let the
latest trend in KM software drive your project.
5. Build the business case. Show the tangible and intangible benefits, along
with the return on investment, of the proposed solution.
6. Identify KM best practices. Look at what other organizations have
successfully done.
III. Enterprise Systems
Although organizations frequently view data in a hierarchical manner, that does not
tell the whole story. The pyramid shown in figure 1.5 depicts the organization as four
clearly defined sections that correspond to the key departments in a business,
implying little sharing of information among them. However, information has
relevance for more than one department or area of a business in any of the three
levels—operational, managerial, and strategic. More effectively using information
throughout the organization can best meet the organization’s objectives. This
requirement for sharing is recognized in what are called enterprise
systems or enterprise resource planning (ERP) systems.
Figure 1.5
Examples of Information Levels
Enterprise systems can be defined as software that is "built around thousands of
predefined business processes that reflect best practices" (Laudon & Laudon,
2006, p. 265). The value of enterprise systems is integrating an organization's
business departments and functions into one IT system (or set of systems) to
support planning, management, and use of resources throughout the enterprise and
improve decision making. You will note that a common theme in these definitions is
the integration of processes and information for managing the enterprise.
Enterprise systems are a recent development in the business and IT landscape for
two important reasons: (1) organizational development/acceptability to the business,
and (2) the availability of appropriate technology. Time and technology, two of the
indirect variables that appear in figure 1.4(b) above, can be identified as variables
that caused the delay in the development of enterprise systems. Organizations had
to recognize the potential advantage of such integrated business processes (time),
and the equipment had to be available to support the systems that would support
the new processes (technology).
One outcome of the Industrial Revolution was the use of the bureaucratic
organization as the business structure to be used by successful businesses. This is
the traditional pyramid-shaped organization with clear chains of command
representing different business functions that did not coordinate with one another
and came together only at the highest levels of the organization. Figure 1.6 is a
representation of that type of organization.
Figure 1.6
Bureaucratic Organization
The organization shown in figure 1.6 is a simple example of a bureaucracy. It is
common for organizations to be much more complex than this, with more
organizations and functions across the top tier and many additional levels below the
various functions. In a bureaucratic organization, the lines between the different
departments should be viewed as impervious walls that separate the functions. This
kind of organization resulted in business processes designed to support only the
individual functions, resulting in duplication and loss of efficiency. This type of
organization was commonly called a silo organization, as shown in figure 1.7, and
each of its functions behaved as an autonomous organization with impervious walls
that protected it from outsiders.
Figure 1.7
Silo Organization
This led to a "we and they" environment and process designs that were inefficient
because they ignored the importance of the other functions. When it was necessary
for information or processes to cross business functions, the individual organizations
took ownership of the process and developed it to support their own objectives
without consideration of the other business functions. The invoice payment process,
for instance, would belong to the accounting silo, and although other business
functions could draw on much of the data used in that process, it was made available
to them in a form and at a time that would limit its usefulness. Often, when a
department that was not the owner of the process needed information on just one
occasion, it required a special request and caused the development of a new report,
which then became a standard periodic report.
This approach led to several problems. Frequently, the reports were generated on a
standard schedule rather than when the information would be most useful to
improve operations. Often, those standard reports were not read at all or, if they
were read, managers did not use the information effectively. As personnel changes
occurred, no one knew what to do with the reports they received and never canceled
them, adding work to the already overtaxed systems. In addition, the reports often
required interfaces between systems that were difficult to maintain, creating an
increased demand for IT support.
The early systems were seen as mere administrative tools, and their use was focused
on accounting and finance and human resources, because these organizations had
crucial administrative requirements: paying suppliers, billing customers, printing
checks, and paying employees. The early technology was inflexible and not very
powerful, but it was very expensive, complicated, and based on batch processing, in
which data were contained within the application programs. The accounting and
human resources business applications were periodic functions (payroll/financial
reporting) that batch processing could serve well, and their managers did not require
or expect information daily.
Production and marketing staff had to glean what information they could from data
designed for accounting and payroll. The head of the IT department may have been
a former finance manager rather than an IT professional, and may have lacked an
understanding of other business functions and an overall view of the entire business
operation. Typically, the accounting department "owned" the systems, and little was
to done to address the need to share information across business functions.
As the concept of relational databases was developed, data were separated from
applications and stored in a central database for each business function's
applications. The data requirements of the other business functions were met using
interfaces, which introduced a high level of complexity and were expensive to
develop and maintain. The database functional owner still controlled changes to the
data with little regard for the needs of other functions. This affected the consistency
and reliability of the data used in reports for all levels of the organization.
Figure 1.8 depicts the complexity of the interfaces used with the applications of the
various business functions. In our example of four business functions (accounting
and finance, operations and production, marketing and sales, and human resources),
each business function, in addition to its own database, required interfaces to the
other three databases to allow development of the information management needed.
In our simple example, 12 interfaces are required. If one of the business functions
added new data elements that the other business functions needed, three interfaces
would have to be changed, along with the originating business function's application.
Figure 1.8
Application Databases
Over time, new theories of organization and management pointed out the benefits of
changing organizational structure and the importance of inter-silo communication
and cooperation. Several tools (such as the Total Quality Management concept) that
had been successful in Japan became tools for US businesses that helped advance
the idea of integrating data to provide better information for managers. This
incorporated business process reengineering (discussed in module 2), which focuses
on the importance of process efficiency at all levels of the organization rather than
organizational structure. This approach is designed to break down existing barriers
by recognizing that processes are organizationally independent and focusing efforts
on process objectives.
At the same time organizations were changing, technology was becoming more
powerful, cheaper, less of a mystery to managers, and recognized as a tool that
could help effect change. Systems professionals, who could work with managers to
solve business problems or capture opportunities using technical solutions, became
available to organizations. Data became recognized as a corporate asset, requiring
management to ensure that its usefulness to the organization could be maximized.
The Internet matured into a true information source for competitive information and
a potential business tool. The concept of strategic partnerships became a powerful
tool for organizations, requiring integration of information and processes to
companies and individuals outside the firm.
When these circumstances came together in a business, a true enterprise system
could be implemented. A characteristic of the maturing organization was the
recognition that data are crucial to an organization's success. They should be
available to everyone associated with the organization to provide the information
required to meet business needs. The system must have an owner who is
responsible for the definition, format, and correctness of the data. Also, the
organization must provide the security necessary to ensure the enterprise system's
reliability and protect it from theft and misuse. In large organizations in which
affiliates or subsidiaries had their own systems, using their own codes and values,
implementing an enterprise system required code standardization. This activity can
lead to significant savings by identifying unnecessary duplication of equipment and
parts and increasing corporate knowledge regarding customers and suppliers.
In the traditional bureaucratic systems environment, redundant data were an issue.
For example, with the introduction of enterprise systems, all applications can use
an entity database rather than individual databases for customers, suppliers,
employees, and contractors. Because there is only one database, the need for
interfaces is eliminated and replaced with data integration, where all of the data are
collected and connected inone relational database.
Figure 1.9 is a depiction of an enterprise system that shows the partnering of
strategic suppliers and key customers with direct access to the systems, while
customers can order via the Internet.
Figure 1.9
Enterprise System
Once an enterprise system is in place, all parts of the organization benefit because of
the availability of more complete and timely information to support better operations
and decision making, which will ultimately improve profitability. To achieve these
objectives, enterprise systems require a great deal of planning in developing the
data requirements and granularity to permit effective planning and decision making.
The following example demonstrates the data required, at the transaction level, to
capture the details of what was planned and then what actually happened, so that
the data can be accumulated in various ways to satisfy the information needs of all
levels of management across the organization. A lot of the data used in this example
must be developed and loaded during the implementation of an enterprise system.
To help you visualize what these preloaded data are in the example, items have been
highlighted in yellow.
The maintenance shop is advised that the generator located in plant 22, sector 455,
has failed and needs replacement. The maintenance supervisor enters the
requirement into the work-order system, which does the following:
creates a work order for task to remove and replace (R&R) the generator
assigns John Smith, employee, to do the work
accesses the work-order data, which assign work order number 5550 to this
job
notes that R&R generator is task 5874 at plant 22, sector 455, which has
a standard time of 5 hours andrequires specific material and equipment items
links to the human resources, fixed asset, material, and equipment
masters to collect the details needed to produce a priced work order
sends the requirements for work order 5550 to the material and equipment
system, which captures the necessary information from the master
files needed to produce the required documents
Figure 1.10
Work-Order Process
Based on previously created standard data, work order 5550 will cost $1,377.75,
which is made up of manpower costs of $125, material costs of $1,202.75, and
equipment costs of $50. As the materials are removed fromWarehouse 19,
the inventory in the material master is decreased, and the accounting transactions
that decrease inventory value and charge work order 5550 are created in the
appropriate master files.
Figure 1.11
Completed Work-Order Data, Excluding Accounting Details
When the work order is completed, employee John Smith documents what actually
happened:
He took 3.5 hours to perform task 5874.
He used 8 bolts rather than 10 (2 were returned to the warehouse).
The forklift truck and driver were used for 14 minutes and arrived on time.
Generator 9999252 had 21,562 operating hours on it.
Failure code 66662, an internal short, was identified as the cause of the
breakdown.
These data would then be entered into the work-order system, providing the
following adjustments or updates:
The actual man-hours and material would be entered, which would decrease
the cost of work order 5550 by $37.90.
There is no adjustment in cost for the equipment because there is a minimum
charge of .5 hours.
The total cost for WO 5550 is $1,339.85.
The appropriate financial entries will be generated in the appropriate master
files.
Warehouse 19 will return the 2 unused bolts to the appropriate row and bin,
and the inventory will be updated.
WO 5550 and inventory accounting entries will be made.
These entries, planned requirements, and actual experience are crucial to the
business's budgeting and planning processes. If similar variations to the plans occur
repeatedly, it will indicate to management that the plans need adjustment. Those
adjustments will affect budgeting and manpower planning. The data are in the
system and, when collected into useful information and properly analyzed, will lead
to increased efficiency. This helps to emphasize the importance of planning for the
system and the training of employees, not only in system operation but also in
business analysis techniques.
It is important to note that WO 5550 contains a number of pieces of data that may
be important individually or may be significant only when they are accumulated to
provide information at the operational, managerial, or strategic levels. Figure 1.12
demonstrates how the organization could use this information.
Figure 1.12
Information Flow and Decision Support
Figure 1.12 is similar to figure 1.5, but the difference is that we have eliminated the
silos, removed the insular barriers, and added examples of the decisions that the
maintenance, material, and accounting organizations could make based on the
transactional data that are captured in the enterprise system database. There are no
interfaces to contend with, and all functions share the data as needed to best
support their areas. The data are created and stored in a common location and are
available in real time throughout the organization. Data redundancy and delays in
availability are eliminated, providing a common basis for decision making throughout
the organization.
A. About Enterprise System Development
A number of companies market enterprise systems that are designed around the
business requirements and best practices of individual industries. Most major
companies purchase these systems rather than undertake developing their own
because of business complexity, technology dynamics, and the business
environment. These dynamics require continuous changes and would be prohibitively
expensive for individual companies, but are more reasonably priced if the cost of the
changes is allocated over a number of companies. For a fixed annual price, the firms
that sell these systems offer maintenance agreements that furnish customers with
fixes for program bugs, enhanced capabilities, and technical upgrades that enable
customers to keep their software current.
Additionally, these companies make available industry user groups that meet and
discuss problems and enhancement needs for the product for their industry and
prioritize changes to the software based on industry consensus and the supplier's
capacity. This enables the software to represent, functionally, the combined thoughts
of the industry and ensures that best practices are updated as needed. Purchasing
the software and joining the user group provides a valuable resource to smaller
companies in the same industry, which do not have the internal resources to stay
abreast of the industry's newest process developments. They can share and benefit
from the experience and analysis of their industry's leaders. The software provider
benefits by having the input of the best business minds for little or no cost to keep
the software up to date with current business approaches. You can see a good
example of this at SAP's website.
An organization that implements an enterprise system solution recognizes that this
system becomes the heart of the organization's information systems and plays a
crucial role in the future profitability and survival of the organization. The reliability
and future viability of the software supplier is a key issue. Organizations must
evaluate vendors and consider the following:
Who owns the source code? Organizations must ensure that they can
continue operations and maintenance of the software if the supplier ceases
operations.
Financial strength of the software supplier—Does it have sufficient
resources to stay in business?
Maintenance—How often are upgrades issued? Are the upgrades readily
available?
Support and training—What level of these services is provided? Are they
included with the software purchase, or are they available only at additional
cost?
The purchaser needs some guarantee that if the supplier went out of business, the
purchaser would have access to the source code so it could continue operation and
maintenance of the software. In a case of software vendor bankruptcy, access to the
source code could be tied up in court for years, which would limit purchasers' ability
to change or modify the software. To eliminate this problem, software suppliers
make available to purchasers the ability to have the source code held in escrow by a
company with specific instructions regarding when purchasers will be given the
source code.
1. Business Continuity and Disaster Recovery
There must be a detailed plan for continued operations in the event of a disaster that
destroys the normal use of the enterprise system. This type of plan may also be part
of the vendor's enterprise software solution, and it must be designed around critical
business functions and the amount of time the company can operate without a
particular function. It is important that the backup plan is tested and that the
appropriate hardware and software are available at alternative sites.
2. Security
Because all of the firm's data are contained in one application, the security of that
data from unauthorized use (internal or external) is a critical issue and must be
thoroughly addressed. Although the data are technically available to all users, access
to see or change the data must be controlled based on business requirements. Based
on the roles of employees, their access may include the ability to view data, but not
to make changes. Other employees may be restricted from viewing certain
information. For example, few individuals in an organization would have access to
the CEO's compensation information. Although the president of a company may have
a need to read or query all of the data in the system, he or she will be permitted to
make only limited and special changes to the data, often in conjunction with a
second approving authority. This is a standard practice for division-of-labor functions
within generally accepted audit principles. In addition to controlling access to the
data, constant backup of the data is also required so that work is not lost or
duplicated during short-term outages.
Although these are normal concerns that surround all systems, even home computer
systems, their importance is magnified in an enterprise system because of the
importance and overall reliance on one system for the functioning of the business.
The size and integrated nature of enterprise systems increase the complexity of
addressing these areas. That complexity and increased importance lead to increased
total cost of ownership. Implementing an enterprise system is a huge effort and
expense, and it must be studied in detail to understand the total costs and benefits
to the company. The diversity, resources, and size of an organization would be
crucial to the justification and support of this type of system's implementation and
operations effort. Enterprise systems may not be applicable to all businesses in the
scope discussed here, but the concept of a shared database is applicable to most
businesses.
References
Ahlawat, A. A. (2006). Knowledge management. In E. Turban, D. Leidner, E. Mclean,
& J. Wetherbe (Eds.). (2008). Information technology for management:
Transforming organizations in the digital economy (6th ed.) (pp. 365–405). Hoboken,
NJ: Wiley.
Laudon, K. C., & Laudon, J. P. (2006). Management information systems: Managing
the digital firm. Upper Saddle River, NJ: Pearson.
Logan, D. (2006, February 3). Knowledge management is critical to organizing and
accessing a company's intellectual assets (Publication ID #G00137342). Stamford,
CT: Gartner Research. Available at http://www.gartner.com/
MITRE Corporation (2007). Corporate profile: About MITRE. Retrieved July 18, 2007,
from http://www.mitre.org/about/index.html
Pfizer Incorporated (2006). Research & development: Champions of innovation.
Retrieved March 1, 2007, from
http://www.pfizer.com/pfizer/help/mn_research_champions.jsp
Turban, E., Leidner, D., McLean, E., & Wetherbe, J. (Eds.) (2008). Information
technology for management: Transforming organizations in the digital economy (6th
ed.). Hoboken, NJ: Wiley.
US Department of Defense, Office of the Secretary of Defense (Comptroller) iCenter
(2002). Knowledge management: Maximizing human potential. Retrieved February
15, 2007, from
http://www.defenselink.mil/comptroller/icenter/learn/knowledgemanconcept.htm
Return to top of page
Module 2: Solution Building
Commentary
Topics
I.
II.
III.
IV.
V.
Introduction
The Information Technology Plan
Business Process Reengineering
Composition of the IT Infrastructure
Total Cost of Ownership
I. Introduction
In this module, we will learn how to link business strategy and information
technology, and how to coordinate the two to find solutions that will help a business
optimize its strategy.
The first thing you must learn to do (and, therefore, the first thing we will discuss) is
to develop an IT systems plan, which is a blueprint for the future. Then you will learn
about business processes, which must be as efficient as possible before you can
begin to build solutions. You must understand what the term IT
infrastructure means, because that is where all of a business's technical assets come
together to provide the framework for future business applications and technology
purchases. In other words, when we look at solutions, we must understand the
infrastructure, because that is where most IT dollars are spent. In addition, the
coordination of different elements of the infrastructure is an important consideration
when calculating the total costs of solutions.
With that in mind, we will begin module 2 by discussing an information technology
plan. We will see that this is the key starting point for the efficient use of IT
resources and the basis for budgets, project definition, and plans for the use of
corporate assets. It is where business strategy and IT strategy are coordinated.
II. The Information Technology Plan
Businesses have a strategy for achieving their objectives, and that strategy changes
over time based on any number of variables that can affect their ability to achieve
their objectives. The business objective is a "what"and does not deal with
the strategy, or the "how-to" steps that will result in achieving the objective.
The"how-to" road map is a strategic business plan (SBP), which is an approach
that management believes will
allow them to achieve their objectives
defines the assets needed
specifies how the assets will be used
So that we can better understand what this plan involves, we should use the
following general business model. The model, shown in figure 2.1, depicts all of the
areas that an SBP must address.
Figure 2.1
General Business Model
The center of the diagram shows that the business strategy is driving the business
toward the business objective and is designed to consider and incorporate the
variables, both direct and indirect, as needed. To implement the strategy, a plan is
developed that addresses many areas of the business, how various available assets
will be used, and the assumptions concerning these variables over a time period,
which could be up to five years. Because of the speed with which changes are
occurring in the worlds of both business and technology, the planning horizon is
constantly shrinking.
Figure 2.2, below, suggests that the strategic business plan connects or enables a
business to use its strategy to achieve its objective.
Figure 2.2
A Strategic Business Plan Connects Strategy to Objective
As variables change and the business objective is optimized, the business strategy
must be modified to meet this changing situation. Business strategy is never
constant, but always changes in response to changes in the variables that affect the
business's ability to achieve its objective. Figure 2.3 suggests this response.
Figure 2.3
Feedback Leads to Strategy Changes
This means that as feedback is received, changes are made in the business strategy
as necessary, and then the SBP must change. The SBP must be a living document
that is constantly reviewed and modified to reflect changes in variables so that the
business objective can be achieved; it cannot be locked away in a drawer until
someone decides to review it.
Figure 2.4
Evolution of the Strategic Business Plan
Figure 2.4, above, shows what actually happens. Changes in variables affect a
business's ability to achieve its objective with the current business strategy and,
therefore, with the current SBP. The plan is modified based on changes made in the
strategy, which should favorably affect the business's ability to achieve its objective.
This is not meant to imply that the changes happen with any regularity. A good
example is when a significant event occurs, affecting business strategy.
Most businesses review their SBPs annually in conjunction with their budget
development. The two are naturally connected, because spending (budget allocation)
must be available to support the plan. The strategic business plan review should
consider all of the variables we have discussed, and it should define specific actions
and budget commitments to those areas.
Figure 2.5
Strategic Business Planning Model
Figure 2.5, above, shows the SBP model and the possible changes to the variables
that would be considered when making or modifying the SBP. You can see that some
of the changes in variables may develop over time. When this happens, the SBP does
not require immediate adjustment, but the potential impact must be noted for future
action. Changes in other variables, however, require immediate attention and
changes to the plan. For example, the poor customer service that has been identified
as resulting in the loss of market share would require immediate action. If the reason
is identified as poor employee performance when dealing with customers, an
extensive training program or a drastic change in hiring practices may be planned.
Poor product quality may require improving raw materials and workmanship.
Think about the changes that you could make to the SBP based on the issues shown
above. As you do that, think about whether there would be a cost associated with
your action. Remember that there is only so much money for investment and other
resources available. The plan will direct allocation and scheduling based on some
guideline. This should help explain why this review and adjustment process is tied to
budgeting.
As we have said, the SBP is the "how to" of the business strategy. We have also said
that IT is an enabler used to help achieve the business objective. As the SBP is
developed or modified, then, it should be clear that the IT plan must be closely
aligned with the SBP done at the same time. Some authors have indicated that the
IT plan should actually be part of the SBP because of its close connection to the IT
infrastructure. (IT infrastructure is made up of five major components—hardware,
software, telecommunications, IT services, and facilities—all of which will be
discussed in detail a little later in this module.)
Moreover, information systems (IS) and the organization's IT infrastructure have
evolved into an 'IT fabric,' or 'nervous system,' inextricably entangled and
intertwined with the business processes and information processing activities
they support (Strnadl, 2001; Calvano and John, 2004; Field and Stoddard,
2004). Consequently, today's IT function is driven by the very same dynamics as
the enterprise itself (Krafzig et al., 2004). (Strnadl, 2006, p. 67)
Management's concern must be how this is done and what makes it a success. Booth
and Philip (2005) state:
Earl's (1993) research uncovered five factors that have an impact upon the
'success' of the [IT] planning effort. They are:
top management involvement;
top management support;
existence/availability of a business strategy;
study business before technology;
good IS [IT] management.
The emphasis here is obviously on facilitating an environment where business
drives technological innovations, and management is fully committed to using IT
to support business goals. (p. 394)
It is well-understood that if business efforts are to be successful, the first three items
in the above list are essential. The fourth item, studying the business before
technology, reinforces what we have been saying about the necessity of a close tie
between the SBP and the IT plan, with the SBP driving both efforts. The last item,
good IS or IT management, must be committed to a long-term systems architectural
approach in which, as Strnadl (2006) said, IT infrastructure has evolved into an "IT
fabric," or "nervous system," that provides the framework into which new systems
and hardware can be fitted as they are needed.
Further, IT management must be sensitive to the business and its needs, rather than
being in awe of or driven by technology. Kroenke (2007) indicates:
Technology is seductive, particularly to IS professionals. The CTO (Chief
Technical Officer) may enthusiastically claim, "With XML Web Services we can do
this and this and this." Although true, the question that the CIO must continually
ask is whether those new possibilities are consistent with the organization's
strategy and direction (p. 310).
The technology must also be consistent with the IT infrastructure. Management has a
responsibility to ensure that they are not buying a Rolls-Royce when a Toyota Prius
will meet all of their objectives. The Rolls-Royce will meet the objectives, but it could
create extra costs without any gain in benefits other than status for the owner.
Conversely, business managers must be aware that systems can and should be used
in the business to solve problems and improve the various functions, and that the
advice of IT management is essential to their success. This also implies that business
managers should be conversant with IT terminology and its possible uses if they are
going to achieve the maximum benefits of IT systems. It is in the best interests of
the organization that both business managers and IT managers recognize each
other's importance and strengths in maximizing systems' effectiveness in solving
problems. This will ultimately lead to better business solutions enabled by IT that will
lead to achievement of business goals and strategic objectives.
Figure 2.6 illustrates an IT plan and its integrated relationship with the organization's
strategic business plan.
Figure 2.6
IT Plan's Relationship to Strategic Business Plan
Figure 2.6 illustrates the close connection between the SBP and the IT plan, and how
business solutions can be produced or enhanced through the introduction of
technology to the business. It should also be noted that these new systems can have
ramifications for the infrastructure that may, in addition to the items noted, require
increases in infrastructure capacity or structure. Clearly, not all eventualities can be
predicted in the SBP or IT plan, but both must be flexible and responsive enough to
respond to changes in the variables.
During the planning cycle, potential projects are identified to address business
problems or opportunities. This is done at a high level at which not every detail is
available or known well enough to support the decision to select one project over
another or to commit resources. These potential projects, whether they involve IT or
are related to other business functions, are assigned to cross-functional teams for
detailed study. An outcome of that study could include business process
reengineering (BPR) and, ultimately, documentation in a business case, a tool used
to document the benefits and costs of a business decision.
III. Business Process Reengineering
Every organization is made up of hundreds or even thousands of processes, with
each process containing numerous tasks (individual steps taken to get the work
done). A process is defined as "a sequence of steps which transform some input—
from suppliers into a final output—which goes to customers" (Scholtes, Joiner, &
Streibel, 2003, p. 44). Processes can be completely internal or external. An internal
process is one in which the suppliers and customers are inside the organization, and
an external process includes either the customers or suppliers outside the
organization. A process can be represented by the suppliers, inputs, process,
outputs, customers (SIPOC) diagram, as shown in figure 2.7.
Figure 2.7
SIPOC Diagram
Source: Adapted from The Team Handbook (Scholtes, Joiner, & Streibel, 2003)
Before we deal with a business, let's return to our school lunch example from module
1. The output will be a peanut butter-and-jelly sandwich, a bag of chips, and cookies
for dessert, all in a small paper bag to be placed in a child's backpack.
The supplier is the supermarket.
The inputs are peanut butter, grape jelly, white bread, a small bag of chips,
a small pack of cookies, food wrap, a small paper bag, and a knife.
The process is collecting all of these items; selecting bread slices; spreading
on the peanut butter and jelly; putting the sandwich together; slicing the
sandwich; wrapping it in the food wrap; placing the wrapped sandwich, chips,
and cookies into the small paper bag (the output); and putting the small
paper bag into the child's backpack.
The feedback at this point is that you are low on peanut butter and should
buy more of it when you go to the store. The child (the customer) eats
lunch, and when he gets home, he provides additional feedback when he says
that lunch was great, but his sandwich needed more jelly.
This simple example illustrates the three main components of a process (input,
process, and output); the high-level steps in completing the process (in this case, of
making a school lunch); and the importance of feedback.
Now let's look at a business, which could be manufacturing a part, creating a
recommendation for a client, creating a customer invoice, or creating an employee
paycheck—all of which are processes. Each of these examples consists of many more
tasks or steps than our lunch example required. The tasks involved in creating an
invoice may include
locating a customer's record
confirming that shipment was made
calculating cost (price times quantity)
adding appropriate shipping charges and possibly sales tax
updating the customer's record and the accounts receivable ledger
generating hard copy of the invoice to be mailed
Back in the old (not really so old) days, a clerk manually performed the necessary
calculations, inserted a preprinted invoice (typically a multipart form) into a
typewriter, and entered the information. Then the original invoice was mailed to the
customer, a copy went to the accounts receivable department to update the ledger,
and another copy was filed in the customer's file folder. This typical manual process
provides numerous opportunities for human error along the way. It is also an ideal
situation in which to use technology to improve the efficiency of the process.
Certainly, having an electronic system that enables all of the parties involved to
receive updated information simultaneously would expedite the process. The current
process is cumbersome and inefficient, however, and automating it would mean only
that the invoice is now inefficiently created more quickly.
This is where business process reengineering (BPR) comes into play. Instead of
taking the existing invoice creation process and automating it, we look at what we
are trying to accomplish (the output):
We want to inform the customer of his obligation to our firm.
We want to update our accounting records so that we are aware of a
customer debt, update the customer record to document the sale, and get
payment from the customer. Our ultimate goal is to get payment from the
customer. The question now becomes, "How do we accomplish this goal more
accurately and efficiently?" rather than, "How do we automate an existing
process?"
A. What Is Business Process Reengineering?
Business process reengineering (BPR) is the analysis and redefining of processes,
both within functions andbetween functions, across an enterprise. In their bestselling 1992 book, Reengineering the Corporation, Michael Hammer and James
Champy argued that drastic redesign, starting with a blank slate, was essential to
reducing costs and increasing quality. They recognized that information technology
was a key tool, or enabler, for such radical changes (TechTarget, 2007).
Humans are creatures of habit, and many of you who have had new ideas have
heard "But we've always done it that way" as a reason to avoid making a suggested
change. It is likely that simplifying and streamlining processes alone may result in
some improvement and efficiencies, even before making further improvements with
technology, by focusing on the existing processes and tasks. But by focusing on what
we want to accomplish (the outcome), the blinders come off, and potential creativity
and innovation are encouraged.
Many existing processes contain redundancies and/or unnecessary steps. These
unnecessary steps may have crept in to solve some previous problem (a workaround) or to capture information for creating a documentation trail (for example,
date-stamping invoices). Assembling a team of people who are familiar with the
process will help identify bottlenecks and unnecessary steps. It's also important that
knowledgeable representatives from all of the involved business functions are part of
the team.
Starting with a new, efficient, and simplified process allows organizations to receive
the full benefits of existing or new technologies and information systems. After all, IT
is only a tool, or an enabler. The goal is to support the business in the achievement
of its strategic objectives. The business must identify its critical business processes,
evaluate those processes to ensure that it is using the right ones, and ensure that
each step or task in the process adds value and contributes directly to the desired
outcome. Once this evaluation has taken place, IT can work with the business to
identify, evaluate, and select the best technical alternative to improve the business
process.
Let's go back to our invoice creation process. If the desired outcome is to get
payment from the customer, then each step in the process must contribute to that
goal. What would ensure timely payment from the customer? The customer needs a
request with accurate information about what is owed and when payment is due, as
quickly as possible. Internally, the seller must record the debt and when it is due on
its books (accounts receivable) as an asset, and add this order to the order history in
the customer's record. The manual process described above is very linear—first one
step happens, and then the next. But why can't steps be done in parallel or
simultaneously? View figure 2.8 to see an example of how this process could be
reengineered.
Figure 2.8
Purchase Order Process
This process now enables the company to mail the invoice to the customer at the
same time the product leaves the shipping dock with the appropriate documents.
Some of you may say, "Well, the process is not optimized, because we could
eliminate the manually entered order and mailing of the invoice, using some
electronic tool like electronic data interchange (EDI) or a website; or a credit card
could be used for direct payment, eliminating the invoice." You are right—and now
you are getting the hang of process reengineering.
Now that the process has been redefined (reengineered), we can look to technology
to help meet our requirements. Requirements include an order entry system
connected to the warehouse or production systems, where shipping documents are
prepared. The data these systems create will allow the creation of an invoice that
contains all shipping charges that can be sent to the customer, and will also update
the accounts receivable and sales systems. For illustrative purposes, we have
simplified the list of steps involved in the process and highlighted only a few of the
major processes, but this should help you understand the significance of first
analyzing and modifying the business process (this is often called optimizing the
base case) before looking to IT for a solution.
Historical Note
In the early days of systems development projects, project development
methodologies required the first step to be defining the existing process
so that it could be replicated in the new system. There was little thought
of improving the business processes—except to make them faster—
because it was believed that they were perfect. This led to many
unsuccessful systems because the processes were illogical or inefficient,
failed to take advantage of many IT innovations, or required human
intervention to work, and the system could not do those things.
Because process evaluation and optimization is so critical, today's IT managers and
staff (IFSM majors) are developing a better understanding of business and process
modeling and are included on the teams that perform the process analysis. It is
critical that the business functions that own the business process being analyzed
participate in this process and own both the process analysis and the ultimate
process redesign. However, IT is a valuable business partner to work with the line
management for an optimal solution that takes technological improvements into
account.
Thus far, we have discussed the need to identify key business processes and perform
a thorough analysis to define the optimum processes for meeting business goals.
Now the organization may be ready to propose a technology solution to bring further
efficiencies to the process. Our next step is to examine the composition of the IT
infrastructure, or the tools at our disposal.
IV. Composition of the IT Infrastructure
As we have seen, the planning activities that we have been discussing are designed
to get the most from a company's resources in an effort to achieve its objectives
over some time period. The composition of a company's IT infrastructure is the result
of managerial decisions, based on the IT plan and its maintenance. As we noted
above, Strnadl (2006, p. 67) states that "information systems (IS) and the
organization's IT infrastructure have evolved into an 'IT fabric,' or 'nervous system,'
inextricably entangled and intertwined with the business processes and information
processing activities they support (Strndal, 2001; Calvano and John, 2004; Field and
Stoddard, 2004)."
We will redefine the major components of infrastructure as hardware, software,
telecommunications, services, and facilities so that they conform to the categories
that are standards for the industry.
It is imperative that all of these areas are coordinated so that they work together. As
new business requirements arise, the solutions developed must fit into that
framework and all facets must be adjusted accordingly so that they remain in sync
with one another.
We are all familiar with the concept of infrastructures because we use them every
day in our normal daily activities. Let's look at an infrastructure with which we are all
familiar but don't think much about—the electrical infrastructure, as shown in figure
2.9.
Figure 2.9
Electrical Infrastructure
We buy electrical devices or appliances, plug them in, and expect them to work. The
reason they do work is that there is a standard electrical infrastructure. This means
that there had been a plan put in place, with which everyone is familiar and the
design and procurement of new devices conforms. When an infrastructure exists, it is
because there was recognition that for a system (a group of equipment and
processes) to function efficiently, there must be a long-term plan with which the key
participants are familiar and comply. This is true for an electrical or an IT
infrastructure.
Figure 2.10 shows the five major components of the IT infrastructure that will be
used to support business strategy.
Figure 2.10
IT Infrastructure Components
For the infrastructure to perform its tasks, all of these elements must be present to
varying degrees based on the IT plan that is supporting the strategic business model
of a company. In order for the infrastructure to function optimally, the components
must be coordinated effectively.
The major components of the IT infrastructure are:
services—the people or organizations that run, support, and manage the
other infrastructure components; can be internal staff or external contractors
or service providers
hardware—devices that perform the input, storage, processing, and output
functions
software—instructions that enable the hardware to perform its functions,
enabling these assets to meet the needs of the business; includes (1)
operating systems that control the hardware, (2) data management software
that accesses and moves data to storage, and (3) application software, which
supports the business processes
telecommunications—the tools that provide connectivity and
communication among individuals, companies, governments, or hardware
assets; includes networking hardware and software and telecommunications
services, both audio and data
facilities—the buildings or spaces that house the equipment and staff that
provide service and support
We have selected these categories of components to facilitate your understanding
and because they are consistent with standard industry categories used by
the Gartner Group.
All IT infrastructures contain all five of these components, regardless of the
organization's size. Even in your home, you have an IT infrastructure, albeit a small
one, as shown in figure 2.11.
Figure 2.11
Home IT Infrastructure
Source: Cisco Systems, Inc. (2007)
Figure 2.11 represents a modern home with a true IT infrastructure containing all of
the components that the largest businesses use to support their business strategies.
Because you may own one personal computer and use it, you recognize the need for
stability and upgrading the equipment and software. You also know that it is flexible
because you can add a printer or an external DVD drive to provide backup of critical
data. You have also encountered devices that caused problems because they did not
provide a smooth upgrade path, like ZIP drives or devices that have only a parallel
port capability. You also are aware of the potential problems that may occur when
you make changes to your infrastructure, and probably plan them for times that will
have the smallest impact on your strategy, or objective.
The degree to which the actual components are used varies among industries and
companies, and it must be balanced to provide the greatest benefit to the
organization. Referring to figure 2.11, the home infrastructure became out of
balance because of the availability of music, movies, graphics, and games on the
Internet. Although hardware and software were capable of supporting these types of
information, users and hardware were constrained because they had to wait so long
for the communications process to occur with dial-up communication. To bring the
infrastructure into balance, telecommunications had to improve. This has led home
users to migrate from dial-up to broadband or DSL as their preferred method of
communicating with the Internet.
Because a business's IT infrastructure can be regarded as its "nervous system," it is
imperative that it be stable, robust, secure, and flexible so that it can support
business requirements reliably, especially in times of heavy usage. Before any IT
decision is made, it must be consistent with the infrastructure. The infrastructure
must be able to accept both changes in the business and radical changes in
technology.
This may sound contradictory, but think back to our electrical system model.
Radically different electrical or electronic devices are constantly becoming available,
but the electrical infrastructure stays relatively constant and the devices operate as
designed. Changes to a component of the infrastructure could require special efforts
and added costs if they are made. In the past, printers were connected to PCs using
a parallel connector, but today's new computers no longer have parallel ports. To
maintain the printing capability, you must purchase either a new printer that
connects using a USB port or an adapter that will allow the old printer to connect to
the new computer.
Because of the constant changes in technology, an infrastructure must change to
take advantage of those changes that will provide a business benefit to the company.
This must be part of the IT plan so that transitions to newer technology can be
integrated smoothly, with no disruption or degradation of service level.
Suppose a new computer is under evaluation to replace an aging computer to gain
the advantages of increased speed and more storage. The impact on all of the
components of the infrastructure must be considered:
Will our existing peripherals operate with the new computer?
Will our existing software work on the new computer?
o If it does, will it still permit us to achieve the benefits of the new
computer?
o If not, will new software have to be purchased?
Will our applications run on the new computer, or will changes have to be
made?
Will our communication protocols work?
Will our networks support the higher volume of data, or will there be a
bottleneck that will prevent the new computer from functioning as well as we
planned?
Will users or the technical staff require training to support the new computer
hardware and software?
The interrelationship that must be coordinated indicates just how important the IT
plan is, because the infrastructure cannot provide the support for the business
strategy without planning and coordination. We pointed out earlier that the planning
process must be coordinated with the budgeting process because businesses have
limited financial resources, and those resources must be allocated among prospective
projects based on the benefits to be obtained from the investment. This leads us to
our next section, in which we will discuss the costs of supporting the infrastructure.
Before moving to the next section, reinforce your understanding of IT infrastructure
concepts by answering the following questions.
V. Total Cost of Ownership
When we purchase items in our personal lives, such as new electronics or appliances,
we know that the purchase price is not the total expense of that acquisition. In most
cases, however, we never consider these ancillary expenses, although intuitively we
know that they are there. In some situations, we do explicitly consider them,
performing a business case analysis in our heads before the purchase by weighing
the total costs against the tangible and intangible benefits associated with the
acquisition. Sometimes we don't think about the business case until after the
acquisition is complete, and we experience "buyer's remorse" because we did not
consider all of the costs involved or do not realize all of the expected benefits.
To fully understand the financial ramifications of our decisions, we must consider the
total cost of ownership before we make any acquisitions. This concept is something
we are very familiar with when we are making a major purchase in our daily lives. In
general terms, the total cost of ownership (TCO) is the sum of all costs
associated with an acquisition that will accumulate over the life of the asset. One of
the personal acquisitions for which we use the TCO is the purchase of a new car.
Clearly, the purchase price is not the only consideration. Today, automakers
recognize the importance of the TCO to their customers; in their advertising, they
talk about gas mileage, resale value, length of warranty, free servicing over some
period of time, and special financing terms.
You can see an example of a basic TCO for a Toyota Prius in table 2.1, below.
Table 2.1
Total Cost Analysis for a Toyota Prius
Depreciation
$6,752
Financing
$3,458
Insurance
$7,696
State fees
$344
Fuel
$3,594
Maintenance
$1,444
(Detail)
Repairs
$524
Hybrid tax credit
-$1,575
Total five-year ownership costs $22,239
Vehicle class
Midsize
5-year ownership cost
$22,239
5-year cost, similar vehicles
$33,758
Difference
$-11,519
Source: Intellichoice, 2007
When buying a car, people use the TCO to help them decide among different vehicles
and manufacturers based on their needs and the benefits the vehicle will provide.
When we do this, we are comparing the TCO to thetotal benefits of ownership
(TBO) (business case analysis) before making a final decision. The TBO comprise
tangible and intangible benefits. The TCO also comprises tangible and intangible
costs.
It is important to note that determining the TCO and TBO is not an exact science
because neither the benefits nor the costs can be forecast with absolute certainty. In
many types of business analysis, this is recognized by assigning a probability to
factor into the analysis. A probability of 1.0 defines certainty, or 100 percent
probability, and is the highest probability value. Something that has a probability of
1.0 is that if, on Earth, you drop a large rock, it will move downward, toward Earth.
The other extreme is a probability of 0.00, which means that something will never
happen. Using the same example, there is a probability of 0.00 that if you drop a
large rock on Earth, it will move upward, away from Earth.
Most situations do not happen at the extremes of probability and have probabilities
somewhere between the two extremes. The probability can be used to determine an
expected value, or the validity of the value of the cost or benefit. To take this
concept into account, we use expected- value calculations.
In layman's terms, the expected value is a calculation that serves as the best
prediction of a value. In financial gobbledygook, it is the probability-weighted
average value of all possible outcomes. Understanding the expected value of a
possible future event allows us to make mathematically sound decisions. We can
decide if we want to make an investment. We can assign a reasonable price for
our services. We can prioritize requirements. We should use expected value
when we calculate return on investment, or ROI (Tyner Blain, 2006).
Think About It 2.1: Expected Value
Because there are many different components, structures, probabilities, and
interrelated cost alternatives, determining the TCO of IT infrastructures can be both
complex and difficult. Each alternative, with its TCO, also has TBO that must be
considered. The importance of this analysis cannot be overemphasized because of
the interrelationship and required coordination among the infrastructure elements
and the time span over which the decisions will affect the business. Figure 2.12,
below, depicts the IT infrastructure as it relates to the TCO.
Figure 2.12
IT Infrastructure Related to TCO
The colored circles in figure 2.12 represent the different elements of the
infrastructure, and the colored background represents the required coordination of
the elements, because coordination can have a significant impact on the costs
associated with any single element.
Table 2.2, below, identifies the cost categories of an IT TCO. Although the list in your
textbook may be more detailed, this list contains some of the often overlooked and
crucial costs that are important to understand.
Table 2.2
Cost Categories of an IT TCO
Cost Categories
Description
acquisition
the costs of acquiring IT assets, including research, travel, freight, and
tax
installation
the costs of making IT assets operational; could include building
modifications, increased cooling requirements, and increased utility
capacity
training
the total cost of training for personnel involved with IT assets; could
include users, technical staff, customers, or business partners
support
the cost of keeping the infrastructure functioning as planned; could
include a help desk, hardware technicians, telecommunications
specialists, programmers, and maintenance support staff
maintenance
the cost of keeping IT assets current and in a condition that can meet
their planned functions; could include maintenance contracts,
programmers, and telecommunications specialists
communications the cost of all communications, including network costs, wiring, service
provider fees, communications hardware, and software
downtime
the costs associated with the loss of an infrastructure service, including
user lost time, lost sales or business, loss of user or customer confidence,
and lost production
disaster recovery the costs of ensuring continued operation of the infrastructure, including
maintenance of a current plan, cost of backup sites and equipment, costs
of emergency power, and costs of practice exercises
security
the costs of ensuring security of the infrastructure, including security
software, usage monitoring, and facility security costs
other costs
the costs of non-IT resources needed for the operation of the
infrastructure, such as disks, tapes, paper, recruiting and contract
negotiation, and administration
coordination
costs
the costs related to keeping the infrastructure tuned to maintain optimal
performance when changes to an infrastructure element are required
Not all of the costs listed above are applicable to all of the infrastructure elements.
Figure 2.13, below, aligns the cost categories with the five elements of the
infrastructure where they would most commonly be found.
Figure 2.13
IT Infrastructure with Cost Categories
Most of these items or services can be achieved in different ways that can affect the
level of service and the costs, for example, outsourcing the entire IT function (or
some parts of it) to gain cost benefits. This adds to the complexity of managing an IT
TCO while ensuring that optimum TBO are achieved. This is an example of why
management of the IT infrastructure is a key component of both the IT strategy and
the operating budget in both the IT department and the business organization.
As we have seen, the actual components of the infrastructure can be contingent on
business structure and operation. Regardless of organization size or objective,
however, all of the elements will be present. If the architecture selected is
mainframe, the specific components of the infrastructure will be different from the
client server or enterprise Internet architectures; however, many of the decisions
that affect costs will be the same.
Support of the infrastructure and its components can be done with a mix of
resources (employees and contractors). These staff members can be on site or at
other locations, or even outsourced to a foreign country like India or the Philippines.
The actual mix that a company uses will be based on costs, service level required,
and reliability.
We have only to look at how we manage the costs of supporting our own home
computer systems to understand the costs of supporting an IT infrastructure in an
organization. For our homes:
We can purchase a computer, rent a computer, or perhaps rely on the public
library's computer system, our employer's computer, or UMUC's computer
labs.
If we own or lease the computer hardware, support will be required.
o We may decide that the computer will not likely fail, but if it does, we
will call a local technician.
o We may pay for a maintenance contract with the computer
manufacturer or a third party.
o We may even rely on our own skill to repair the hardware.
We make decisions about software that we need and our own upgrade policy.
o We may decide that we will never upgrade our software because we
know how it works and we need no additional features.
Think about what the impact of these decisions is when a business has to make
them, particularly when the business has critical systems, without which it cannot
function. For instance, Walmart's very competitive advantage lies in its supply chain
management system.
Try This 2.1: IT Infrastructure and Costs
References
Booth, M. E., & Philip, G. (2005, September). Information systems management:
Role of planning, alignment and leadership. Behaviour & Information Technology,
24(5), 391-404.
Cisco Systems, Inc. (2007). Linksys connected home solutions. Retrieved March 18,
2007, from
http://www.linksys.com/servlet/Satellite?c=L_Promotion_C1&childpagename=US%2
FLayout&cid=1156806458184&packedargs=site%3DUS&pagename=Linksys%2FCom
mon%2FVisitorWrapper
Intellichoice (2007). 2007 Toyota Prius. Retrieved March 16, 2007, from
http://www.intellichoice.com/reports/vehicleReport/vehicle_nmb/19453/section/own
ership/type/new/year/2007/make/Toyota/model/Prius
Kroenke, David M. (2007). Using MIS. Upper Saddle River, NJ: Pearson Prentice Hall.
Scholtes, P., Joiner, B., & Streibel, B. (2003). The team handbook (3rd ed.).
Waunakee, WI: Oriel.
Strnadl, Christoph F. (2006, Fall). Aligning business and IT: The process-driven
architecture model. Information Systems Management, 23(4), 67-77.
TechTarget (2007). Business process reengineering. Search CIO.com: CIO
Definitions. Retrieved January 10, 2007, from
http://searchcio.techtarget.com/sDefinition/0,,sid19_gci536451,00.html
Tyner Blain (2006, February 3). Definition of expected value. Retrieved April 4, 2007,
from http://tynerblain.com/blog/2006/02/03/definition-of-expected-value/
Return to top of page
Module 3: Solution Management
Commentary
Topics
I.
II.
III.
Introduction
Information Systems Development
Project Management
I. Introduction
Module 2 discussed different aspects of information systems and the importance of
aligning IT efforts with business strategy for effective solution building. However, the
success of IT projects often rests with effective processes for developing systems
and excellent project management.
Project management is covered in a separate course, and this module is not intended
to teach you everything you should know about it. Our focus here is on the human
aspects of project management that can help increase your chances of successfully
implementing an IT solution.
As with project management, software analysis and design is covered in a separate
course, and this module is focused on providing the basics of a structured
methodology for developing systems. Many of you will likely be involved in a
software development project at some point in your careers—this could be as an end
user, a business customer of IT, a software developer, a business analyst, or a
business owner—and having a basic understanding of what is involved in this is
important. SDLC is based on the concept that an information system must pass
through a series of phases during its existence or life cycle. In this module, we will
help you understand the life cycle methodology and the way SDLC is used to design,
develop, and implement information systems.
II. Information Systems Development
A. Purpose of the Systems Development Life Cycle (SDLC)
1. What Is SDLC?
The systems development life cycle (SDLC) is a structured methodology and process
that guides the development of information systems. SDLC is based on a series of
related activities that are combined into phases, sometimes called life cycle phases.
The phases represent states or stages in the life of an information system. Generally
speaking, an information system's life cycle proceeds from requirements gathering to
design and development, then to operations and maintenance, and on to
decommissioning. Each successive phase leverages the documentation and
knowledge gained from the previous phases. Figure 3.1 shows the general flow of a
basic SDLC.
Figure 3.1
Basic Systems Development Life Cycle
The main purpose of using SDLC is to promote quality during the design,
development, and implementation effort. When SDLC is used properly, information
systems are more reliable and cost effective because project activities are planned,
documented, tracked, and controlled. To ensure that the information system will
meet the stated requirements, SDLC also includes predefined reviews, inspections,
and audits for the life cycle processes and deliverables to identify variances and
recommend changes.
2. Using the SDLC Initialism
As with most initialisms, there can be some confusion associated with using SDLC.
Within the information technology industry, SDLC may also be used for:
Synchronous Data Link Control—This is a communications protocol that
divides network functions into clearly defined layers.
software development life cycle—Also known as software development
process (SDP), this is the set of life cycle phases associated with software
programs.
For the purposes of this module, SDLC will be used as defined in the previous
section.
3. Why Is SDLC Important for Information Systems
Development?
Information systems do not consist solely of the software and hardware an
organization uses. Effective use of technology is also highly dependent on having a
solid set of processes and procedures for meeting business objectives, delivering
products and services, and enabling continuous process improvement. Another
important component of an information system is the trained, skilled people who use
the technology, processes, and procedures to operate in and manage the
organization.
The relationships among the technology, processes, procedures, and people are
symbiotic; any change to one component will have some effect on the others. For
example, introducing a new human resources information system into an
organization without considering how it might affect the organization's processes and
procedures could doom the system to failure before it is fully deployed. A key aspect
of using SDLC is considering all components of an information system throughout the
entire project. This holistic approach is one of the main reasons why using SDLC is
increasingly becoming a critical success factor for implementing today's complex,
high-stakes information systems.
Because implementing these systems is an expensive, multiyear effort, SDLC is also
an important organizational tool to ensure that information system resources are
implemented in a fiscally responsible and efficient manner. A life cycle approach
ensures that there is a clear plan and process for
identifying and validating organizational requirements early in the project
designing and developing the system based on the approved requirements
deploying and transitioning the completed system to the user community
operating, maintaining, and updating the system once it is deployed
decommissioning the system when it is no longer required or when it is
replaced
B. The SDLC Phases
The SDLC phases are the sequence of activities associated with the life cycle of an
information system. Although the number of SDLC activities can vary depending on
the type and complexity of the information system project or the SDLC model used,
there are some common guidelines that allow the activities to be grouped into clearly
defined phases. These recommended guidelines are outlined below.
Complete a preliminary investigation, requirements analysis, and system
recommendation.
Specify a detailed design based on an approved set of requirements.
Develop the system according to the approved design specification.
Test the system, and gain user acceptance.
Install, operate, and maintain the accepted system.
Update or replace the system as organizational goals and requirements
change.
Decommission the system when it is no longer needed.
Document, report on, and approve each phase of the SDLC before beginning
the next phase.
Following these common guidelines helps mitigate the risk that the design and
development effort will get out of control through missed requirements, schedule
delays, or cost overruns. Because the guidelines require interaction with
stakeholders throughout the project, they also prevent surprises when the system is
rolled out to the user community. As you read through the approaches in the
following sections, see if you can identify these common steps.
1. Four-Phase Approach
This approach divides the life cycle into four major phases. It may be used when an
organization has a good understanding of its requirements or the type of information
system being implemented.
Figure 3.2 shows the four phases and some of the key activities associated with each
phase. To view the subsections of each phase, just click on the phase. At the end of
the exercise, you will see the complete diagram, showing all phases and key
activities. You can also see the complete diagram by clicking on the Show Me button.
Figure 3.2
Four-Phase Approach
2. Nine-Phase Approach
This approach divides the life cycle into nine phases. Table 3.1 shows the phases and
some of the key activities associated with each phase. As you read through the table,
compare it with the four-phase approach. Note that a more granular approach is
taken for the portions of the project that deal with preliminary investigation,
requirements analysis, and system recommendation.
Organizations may use this approach when implementing an unfamiliar type of
information system. The nine-phase approach is also more appropriate for
implementing information systems that will be used across all business units within
an organization.
Table 3.1
Nine-Phase Approach
SDLC Phases
Key Activities
initiation phase
develop business case
identify project sponsor
appoint project manager
develop concept proposal
review and approve concept proposal
system concept
development phase
analyze business need
form project team
plan project
develop project acquisition strategy
identify and analyze risks
obtain funding and resources
document phase efforts
review and approve phase documents
planning phase
refine acquisition strategy
analyze project schedule
document internal processes
establish agreements with stakeholders
develop project management plan
review and approve project management plan
requirements analysis
phase
define functional requirements
define technical requirements
conduct reviews and approve requirements
design phase
design system
design business processes
outline operations and maintenance manuals
outline deployment plan
conduct design reviews
SDLC Phases
Key Activities
approve system design
development phase
refine and complete software requirements
refine and complete software design
acquire and install hardware
code and test software
conduct hardware and software qualification testing
install software
test system qualification
complete plans and support documentation
test and review documentation
develop deployment plan
obtain approval and acceptance of all development
documentation
integration and test phase
conduct subsystem/system testing
conduct security testing
conduct user-acceptance testing
review and finalize development phase documentation
obtain user acceptance
implementation phase
communicate deployment plan
execute training plan
perform data entry, migration, and conversion
install new system
perform postimplementation evaluation
obtain approval to operate the system
operations and
maintenance phase
transition project to operations
operate system
perform data and software administration
perform system and software maintenance
identify problems, recommend modifications, and
update the system
monitor organizational changes, recommend
modifications, and update the system
3. Ten-Phase Approach
The US Department of Justice (DOJ) uses a ten-phase SDLC approach on its
information systems implementation projects. Like the nine-phase approach, this
approach emphasizes the project activities relating to preliminary investigation,
requirements analysis, and system recommendation. The main difference between
the DOJ approach and the nine-phase approach is that the DOJ approach also
includes a phase to dispose of the information system when it is no longer needed.
C. SDLC Models
1. Waterfall Model
The waterfall model is often used to represent the SDLC process. This linear,
sequential model is often considered to be the foundation and origin of today's SDLC
methodology. Although there is disagreement as to when the model was first
introduced, the general consensus is that it has been in existence in one form or
another since the 1960s.
Waterfall development is still widely used for software engineering projects because
it has distinct goals for each phase of the development and requires each phase to
be fully completed before the next phase can begin. Once the decision is made to go
to the next phase, there is no turning back. Like a waterfall, once the water goes
over the cliff (phase), it cannot flow back. Figure 3.3 shows how the waterfall model
works, using DOJ's ten-phase approach.
Figure 3.3
Waterfall SDLC Model
The advantage of waterfall development is that it allows for direct project manager
and management control. A timeline can be established with specific deadlines for
each phase, and a software solution can proceed through the development process
like a product through an assembly line, and if properly managed, be delivered on
time. Each phase of development proceeds in a predefined order, without any
overlapping steps or turning back.
The disadvantage of waterfall development is that there is no returning to a previous
phase. Once the software solution is in the design phase, it is very difficult to go
back and modify a feature or function that was not well-thought-out in the
requirements phase. Today's complex, cross-functional information systems require
a more iterative approach and development effort.
2. Fountain Model
The fountain model recognizes that overlap may be needed between some
development phases, and that previous phases may have to be revisited throughout
the development cycle. For example, planning may need to be fully completed prior
to beginning requirements analysis. Once planning is completed, the requirements
analysis, design, and development phases may have activities that must overlap to
ensure that the system is properly built. Like water in a fountain, details about the
information system are pushed up through the phases, but at any time, the details
may flow back through the previous phases to be refreshed and refined as more is
learned about the system. Figure 3.4 shows how the fountain model works, using
DOJ's ten-phase approach.
At first glance, the fountain model can be very confusing. If you have never used the
model on a project, you may not understand that the overlapping phases and curved
arrows demonstrate the highly iterative nature of this life cycle approach. Figure 3.4
will step you through an example of the fountain model. At the end of the exercise,
you will see the complete diagram of this model.
Figure 3.4
Fountain SDLC Model
The advantage of fountain development is that changes can be made to the
components of the information system as the project team learns more about what is
actually needed or uncovers gaps in the concept, requirements, or design.
The disadvantage of this model is that it may take more time and cost more to
complete the information system. Without strong project management, the
information system theoretically may never be completed if the project team gets
caught in a loop of ever-increasing scope and continuously changing requirements.
3. Build-and-Fix Model
Build and fix is recognized as the crudest, least structured model in the SDLC family.
In this model, the solution is developed without any proper preliminary investigation,
requirements analysis, or design. In essence, the solution is built and modified as
often as necessary until it satisfies the customer's needs. Figure 3.5 demonstrates
this model, which uses only the development and operational phases of the fourphase approach. Some of the study and design phase activities may be completed
during a highly iterative modify phase. At the end of the exercise, you will see the
complete diagram of this model.
Figure 3.5
Build-and-Fix SDLC Model
The advantage of the build-and-fix model is that it provides an efficient framework
for extremely small, low-priority development efforts that involve a single customer.
In some cases, it may be necessary to use the build-and-fix model when there is not
enough time for a more rigorous approach. The highly iterative nature of this model
ensures intense and frequent customer involvement in the development of the
information system.
The disadvantage of this approach is that the cost is usually greater than if a
preliminary investigation, requirements analysis, and detailed design had been
completed. This is an extremely open-ended, risky approach that requires careful
management and control. Organizations are strongly discouraged from using this
SDLC model except for small, low-priority projects.
4. Rapid Application Development (RAD) or Rapid
Prototyping Model
In most cases, RAD is used when developing a software solution that is heavily
dependent on the organization's business processes and the end users' knowledge
and understanding of those processes. In essence, the end users can provide better
feedback about the system requirements by examining a live system rather than
commenting on the associated documentation. It is analogous to working with a
tailor who is making a custom suit for you. At various stages of the suit's
construction, you may have to return to the tailor's shop, try on the unfinished
pieces, and provide feedback that is used to update the measurements and complete
the suit. The type of suit and the fit you expect may dictate how many iterations are
needed before the tailor's work is done.
RAD is made possible by significant advances in the software development
environment that allow for more rapid code generation and faster modifications to
application screens and other user interfaces. Figure 3.6 shows how the RAD model
works, using a modified version of DOJ's ten-phase approach.
Figure 3.6
RAD/Rapid Prototyping Model
The advantage of the RAD model is that it can result in a lower level of rejection
when the information system is placed into production. End users are given the
opportunity to work with the screens online in a production-like environment, which
means a significant number of design and development errors can be caught earlier
in the process. The model also allows end users to be heavily involved in the
software development effort and take ownership of the finished product.
The disadvantage of this model is that RAD could lead to cost and schedule overruns.
Another downside is the propensity of end users to increase the scope and add new
requirements during the development effort. Some end users may think that
because it is easy for the developer to produce the basic screens, it is just as easy to
add extra enhancements. Without strong project leadership, participants can lose
sight of the goal of producing an optimal, useful system, and instead attempt to
develop a gold-plated application that goes beyond the organization's requirements.
For this reason, the project team may use a blend of RAD prototyping and the
traditional waterfall approach.
D. Relationship between SDLC and Project Management
Project management is a profession and discipline that uses a systematic process to
plan, manage, execute, and control projects. Project managers are found in just
about every commercial and noncommercial environment, including construction,
education, financial services, government, medicine, manufacturing, nonprofit,
technology, and utilities environments.
The project management process uses the same structure and rigor found in the
SDLC models. A typical project management process may include the steps shown in
figure 3.7.
To view the subsections of each process step, just click on the name of the process
step. At the end of the exercise, you will see the complete diagram, showing all key
activities. You can also see the complete diagram by clicking on the Show Me button.
Figure 3.7
Project Management Process
Although many projects do not require an SDLC approach, the majority of IT-based
projects do. Specifically, when some form of information system is needed, SDLC is
required and project management is needed to plan, schedule, and control the
associated activities. As an information system moves through its life cycle phases, it
may spawn several projects. For example, there may be separate projects to
determine the business need
find, analyze, evaluate, and select a vendor
define what needs to be done to update an aging system during the
operations and maintenance phase
dispose of an information system that is no longer required
In most cases, the project ends when the information system moves into the
operations and maintenance phase. In all cases, it is project management that brings
order and organization to information system development efforts.
E. Summary
SDLC is the progression through a series of stages or states of an information
system. It lasts from the conception of the system to its disposition. The number of
life cycle phases can vary from system to system and according to the needs of the
organization. SDLC models are tools that allow project and development teams to
correctly follow the SDLC stages required to develop the various types of information
systems. Project management is used to plan, schedule, and control the SDLC
phases associated with a selected model.
III. Project Management
What is a project? A project is an effort with specific starting and ending points that
concludes with a result. Building a house is a project, completing a research paper is
a project, and planning a wedding is a project. Key characteristics of all projects are
a timeline, resources, tasks, person effort ("man hours"), and dependencies.
The Project Management Institute is an excellent resource for project management
information. Furthermore, PMI has a professional certification program that requires
certified project managers to update their knowledge of new developments in the
field of project management.
For our purposes, let's use the project we discussed in module 2: streamlining the
invoice payment process. Figure 3.8 shows the high-level scope of the proposed
solution (without technical details) to highlight its key elements.
Figure 3.8
Invoice Processing Automation Project
Rather than creating a detailed project plan, we will discuss general aspects of the
plan.
Elements
Details
timeline
January 3, 2008–September 30, 2008
resources
Budget: $675,000
effort
1,200 hours
dependencies (These would be detailed in the project plan.) Examples: Software cannot be
installed until the new file servers are installed, data must be standardized
across functions, user training cannot happen until the software application
is finalized.
tasks
(These would be defined in detail in the project plan.)
For our purposes, we will assume that the correct business process redesign
occurred and the best solution was chosen. So what do we need from a project
management perspective? It would seem easy enough: plan the work and work the
plan, and voilà! The solution is implemented on schedule and on budget.
Of course, anyone who has participated in a project knows that it rarely happens that
way. Building a house gets complicated because two solid weeks of rain delays the
pouring of the concrete. You thought you could conduct your term paper research on
Saturday, but a friend had a ticket for the big game and you could not decline his
offer; therefore, you didn't gather the information so you could begin writing your
paper on Sunday. And planning a wedding—there are so many potential issues
there—the bridesmaids hate their dresses, the caterer backed out, the organist broke
her wrist, and so forth. You get the idea; even the best-planned project will have
challenges.
Before moving ahead with our discussion of project management, it is important that
we define a few key terms.
Term
Definition
project scope describes the work that must be
accomplished to complete the project
Examples
three-bedroom, two-bath house
completed and occupancy
certificate obtained; research
paper submitted to professor;
wedding held
project
manager
"expert" responsible for planning,
managing, and controlling all aspects of a
project
construction manager; student;
wedding planner
project
management
"the process of scoping, planning,
staffing, organizing, directing, and
controlling the development of an
acceptable system at a minimum cost
within a specified time frame" (Whitten &
Bentley, 2008, p. 80)
the construction plan for
building the house; the "to-do"
list for researching and writing
the research paper; the wedding
planning notebook
project
deliverables
concrete, tangible outcomes, results, or
products generated as a result of a project
drywall completed on new
house construction; first draft
of research paper written;
wedding invitations printed
milestones
key dates when specific, critical tasks or
groups of activities are completed
March 15: electrical wiring
completed; May 1: research
completed; June 1: reception
hall booked
contingency
anticipating delays or problems, and
having an alternative solution or strategy
planned
backup plumber and electrician
identified in case primary
contractors are unavailable
Characteristics of a sound project plan include:
easy to understand—Tasks and deliverables are specifically presented in
commonly understood, well-defined terms.
readable—Graphical representation follows standard structure and layout.
communicated to all key stakeholders—Those involved and affected know
what the plan is.
appropriate to the project's size, complexity, and importance—The
plan is not overly involved or complicated for a minor, small-cost, short-term
project, and is not too general and abbreviated for a complex, high-cost,
long-term, high-priority project.
prepared by the team—Project team members contribute to the project
plan development, rather than a project manager developing in a vacuum.
Having a well-prepared project plan can help reduce the risk of project failure, but it
cannot eliminate thepossibility of failure. There are many reasons why even a well-
planned project can fail. Some common project problems result from
mismanagement (Whitten & Bentley, 2008, p. 81):
failure to establish upper-management commitment to the project
poor expectations of management (expectations of users and managers not in
agreement, or expectations change over the life of the project)
premature commitment to budget and schedule
overly optimistic
mythical man-month
inadequate people-management skills
failure to adapt to business change
insufficient resources
failure to work the plan
As you review this list, how many of these causes are related to hardware, software,
or other technology issues? Right—none! This indicates that it is frequently the
human aspect of projects that creates most of the problems and greatly increases
the risk of failure. Therefore, the importance of paying attention to the softer skills of
managing people in IT cannot be overemphasized.
A. Project Management Dilemma
Figure 3.9 shows four variables that provide a constant challenge and balancing act
in project management.
Figure 3.9
Project Management Variables
Mouseover the labels for more information.
If you look back at the list of causes of project failures, you will see that many
connect to one or more of these interrelated elements. For example, premature
commitment to budget and schedule will definitely affect the time and cost variables.
Let's relate this cause to our earlier examples.
Project
Cause of Failure
building a house
estimating the construction budget with insufficient research into the
current costs of construction materials, or assuming stable pricing
preparing a
research paper
planning your schedule to complete the paper without considering other
course assignments or personal requirements
planning a
wedding
establishing a budget for "dear old dad" without obtaining the costs of
catering the reception
A critical success factor for projects is having a sound project management
methodology; however, the specific methodology used is less important than having
a structured process (Dorsey, 2000). The project methodology provides the structure
and processes to define and plan a project, monitor its progress, and evaluate its
end result. A standard methodology also provides for consistency, allows the process
to be refined and improved over time by incorporating lessons learned, and increases
the transferability of skills among team members. Let's look at a project
management framework from the Massachusetts Institute of Technology's
Information Services and Technology Group's website.
Figure 3.10
MIT's Project Management Framework
Mouseover the center area to enlarge it.
Source: Adapted from Massachusetts Institute of Technology (n.d.)
An extremely important part of project management is monitoring (or tracking) and
controlling the progress of the project. The project plan provides the road map for
the project. The project manager is responsible for monitoring to ensure that tasks
are completed on schedule, resources are available as planned, and key milestones
and deliverables are met. Routine status reports are an important part of tracking
the progress of the project. This monitoring process helps the project manager keep
time, cost, and scope in balance.
Project managers must also address team issues to help guide the project team.
People should be recognized for their contributions and successes and held
accountable for failing to meet commitments. Far too often, members of project
teams know things aren't going well but bolster themselves by vowing to get caught
up next week. Addressing problems as early as possible in the project allows time to
make corrections and help keep the project on target.
B. Scope Management
Failure to manage the scope of a project will result in scope creep—the natural
tendency of projects to become bigger than originally intended, with detrimental
impact on cost, time, and outcome. For example, while building a house, we decide
to add a home theater in the basement; you decide to add a PowerPoint presentation
to your research paper; and the wedding reception entertainment changes from
Cousin George, the DJ, to an eight-piece jazz ensemble.
To minimize inadvertent scope creep, effective project managers define a change
management processspecifically related to the project. (This is different from the
organizational change management strategies that we will discuss later in this
module, which relate to generally managing the changes within the organization that
a new solution may create.) At the risk of oversimplifying this concept, for the
purposes of our discussion, we are talking about a structured process (part of an
overall project management methodology) to address changes in requirements or
expectations on the specific project outcome.
As you can imagine, changes affect resources. A change may require additional staff
hours, hardware and/or software costs, testing, systems configurations, and/or the
assessment of impact on related IT components. There are times when these
changes are necessary to maximize the intended business solution, address some
unforeseen problem, or meet a changing business strategy or requirement. Having a
structured methodology in place means that the change is treated as a potential
mini-project:
The requirements are documented and analyzed.
The impact (time, money, and other resources) is analyzed, and the effects
on budget and schedule are defined.
At this point, the business sponsor or project owner may make a
determination as to whether or not to proceed with the change.
In many larger organizations, a change control board (CCB) exists for just such
situations. Representatives from the affected areas review the documentation and
make a decision as to whether or not to proceed. If the decision is to proceed, the
additional impact is inserted into the project plan, and appropriate adjustments are
made.
In module 2, we mentioned an alternative in our invoice-processing solution of
having orders received electronically by using EDI. This may be a great idea and
provide maximum efficiency; however, it adds significantly to the original project
scope and cost. Applying a project management change process would include
evaluating the impact of this request and making an appropriate business decision as
to whether or not to proceed.
If we look back at our definition of project manager, it seems like this individual
bears most of the responsibility for making projects successful. Although he or she
may delegate various tasks, the buck frequently stops with the project manager.
Because of the many hats project managers wear, the variety of skills they must
have, and the constant juggling act they must perform, it is no wonder that highly
capable and skilled project managers can be scarce and are in great demand. Let's
look at the skills, or competencies, a good project manager must have.
Table 3.2
Project Manager Competencies
Competencies
business
achievement
people
management
Description
connects projects with corporate strategy and objectives
partners with and involves stakeholders throughout the process
provides quality perspective
communicates effectively
facilitates team process
coaches team members to work cohesively and fosters a spirit
of collaboration
provides resources and training to develop team members
prepares, monitors, and controls project plan—gathers input
and adjusts as needed
problem-solving
displays initiative to show creativity and innovation
calculates risks and prepares contingencies
applies critical thinking to problem resolutions
provides systems perspective
influence
understands and is sensitive to interpersonal motivations and
behaviors of others
is aware of corporate political landscape and can navigate it
self-management
effectively
understands the implications of project decisions and manages
risks
knows how to enlist cooperation and build consensus among
business managers, users, and IT staff
displays self-confidence, but with humility
"walks the talk"
has personal accountability
works well under pressure and adverse conditions
Source: Whitten & Bentley (2008, pp. 82-83)
Depending on the organization and scope of a project, there may be both a business
project manager and a technical project manager assigned. As we discussed in
module 2, it is essential that the business owns the solution. IT's role is to help the
business identify the best technology solution for the business problem. Regardless
of whether one or two individuals perform this role, the critical skills they need to
address the issues we have discussed are the ability to (1) manage people and
(2) manage the project effectively. The project team can be staffed with technical
expertise, but it is much more difficult, if not impossible, to make up for a project
manager's shortcomings in the areas of understanding the business and addressing
the human aspects. Project managers must also address any team issues that arise
to help guide the project team.
References
Dorsey, P. (2000). Top 10 reasons why systems projects fail. Retrieved April 9,
2007, from http://www.dulcian.com
Massachusetts Institute of Technology (n.d.). Information services and technology
project management. Retrieved April 21, 2007, from
http://web.mit.edu/ist/pmm/framework.html
US Department of Justice, Justice Management Division (2003, January). The
Department of Justice systems development life cycle guidance document. Retrieved
July 8, 2011, from http://www.justice.gov/jmd/irm/lifecycle/table.htm
Whitten, J. L., & Bentley, L. D. (2008). Introduction to systems analysis and design.
New York: McGraw-Hill.
Return to top of page
Module 4: Putting It All Together
Commentary
Topics
I.
II.
Building the Business Case
Putting It All Together
I. Building the Business Case
What is a business case? A business case is a tool used to support a business
decision, such as investing in any asset that would include a new information
system, a new network, or additional production or storage capacity; entering a new
business venture; or discontinuing a product or service. A business case is a
structured proposal that provides the necessary information regarding how the
proposed course of action would benefit the organization. Without a crystal ball, the
information in a business case cannot be guaranteed. However, good information
gathering; analysis; and the use of proven financial models, including a sensitivity
analysis that reflects probabilities, can strengthen the credibility of the business case
and provide management with the information they need to make an appropriate,
objective decision.
A key component of a business case is identification of the benefits of the proposed
solution. These benefits can be tangible or intangible. Tangible benefits are
benefits that can be measured objectively and empirically. An intangible benefit is
one that cannot be empirically measured with objective data but does provide
benefits to the business. We can use the example of purchasing a family car to
illustrate the difference between tangible and intangible benefits. The problem is that
the family's old, gas-guzzling truck has just passed 215,000 miles, needs a new
engine, and has other parts that are worn out and in constant need of repair. The
proposed solution is to purchase a new sport utility vehicle. The tangible benefits
would be to reduce maintenance costs and obtain improved gas mileage. The
intangible benefits would be the prestige of having a new vehicle, the peace of mind
that comes with having dependable transportation, and the smile on the buyer's
face.
A. The Components of a Business Case
A quick web search will reveal a variety of templates for a business case proposal,
and many organizations and agencies have a particular format that is consistently
used within their own organizations. However, we will present the main elements
that are essential to a thorough business case.
Figure 4.1
The Components of a Business Case
The scope of the information presented requires significant effort on the project
team's part. However, a strong business case provides decision makers with the
exact information they need to make an educated, well-informed decision. Without
this level of effort, senior management may lack sufficient information and therefore
delay making a decision, or in the absence of more complete information, they may
make a bad decision. A bad decision could result from approving a solution that is
not in the best interests of the organization, failing to take advantage of maximized
benefits in a more comprehensive solution, or failing to support a solution that would
meet the defined business need and add value to the organization.
B. Why Business Cases Fail
A business case can fail to gain approval because it fails to convince the decision
makers (senior management) that the potential benefits outweigh the costs and
risks. This could be due to poor analysis, insufficient or inaccurate information about
the benefits, or faulty assumptions being presented in the case. Overall, the business
case could lack complete information and sufficient data to support the proposed
solution. Resistance to change and other corporate cultural, political, or other
intangible concerns within the organization may overpower the tangible benefits
presented. It is imperative that the business case clearly identifies the assumptions
used in determining the benefits and the potential risks of both accepting the
business case and rejecting it. All of these areas are crucial to management
acceptance or rejection.
A business case is part art and part science. In other words, the developer has
assembled the business case in a way that is sensitive to management's desires and
expectations in simple, easy-to-understand language that is consistent with the
organization's culture and values. For example, presenting tangible benefits in a way
that closely aligns with management's expressed key business objectives works best
in some organizations. In other situations, emphasizing intangible benefits may
resonate more with senior management decision makers, in spite of the fact that
such benefits cannot be quantified. For example, if a company's public image has
recently been tarnished, emphasizing the intangible benefit of improved public image
could be a key selling point. The business case developer must present a compelling
argument, supported by facts, to sell the project and must also be prepared to
answer any questions and objections with solid, factual responses. Underestimating
this task can result in failure.
Schmidt (2005) presents some characteristics that deserve special attention, as
shown in figure 4.2.
Figure 4.2
Business Case Tips
It is important to emphasize that almost all companies have an available standard
template that includes specifications for required data and analysis techniques that
must be used because business case analysis crosses all departments and divisions
of a company. This is because the many business cases presented to management
are competing for the same limited funds and need a common system for
comparison so that the executives can make objective decisions.
In an article in CIO Magazine, Paul (2004) identified the need to "make the business
partner own the benefits" as a key to increasing the likelihood that your business
case will successfully promote your solution. This is a critical point for IT to
emphasize. Not only must the business owner see the proposed benefits as
achievable, yet realistic, but he must also agree to be accountable for them.
Let's say that you are proposing a new customer relationship management system
for the sales and marketing department. A projected benefit could relate to
improving customer retention and increasing the volume of sales per customer. Both
are plausible benefits of a CRM system for which the business owners must be held
accountable. However, IT cannot guarantee these benefits if the sales department
fails to effectively use the new information the new system will more efficiently
provide to target customers. However, the IT department can be held accountable if
the system operating costs are far greater than their estimates, negating all or part
of the benefit. Accountabilities must be allocated to the appropriate areas to achieve
the intended benefits.
A challenge in all projects, especially in IT projects, is clarifying who owns the
business case. The function that will benefit from and be held accountable for the
project benefits must be the owner of the business case. IT is a support function
within a business, as are the finance and human resources (HR) functions.
Support functions are necessary and are driven by the requirements of the business.
For example, HR should not drive a hiring increase, but it should be driven to obtain
the best prospective candidates required by the business function that needs more
manpower. The business unit must be held accountable for the benefits of the
increased hiring, while HR is held accountable for the quality of its recruiting
activities and the expenses incurred to hire the needed people.
If the sales and marketing department requires better information about its
customers, and access and integration of its customer data, then sales and
marketing—not IT—would be responsible for building the business case to implement
a CRM application based on the benefits it would achieve. Part of the business case is
the cost associated with the proposed solution, and IT would be responsible for
furnishing those estimated costs. The sales and marketing function would receive
and be held accountable for achieving the benefits (increased sales) from the
system. A significant part of the IT contribution to the case would be to address
technology alternatives (such as Seibel vs. SAS, infrastructure requirements, and
increased data management resources) and implementation components (such as
training, support, and ongoing maintenance). IT would be responsible and held
accountable for the IT costs that are part of the business case. You can read about
how one organization handles business case ownership and accountability.
II. Putting It All Together
Throughout these modules, we have discussed many elements of effectively
implementing information systems in organizations. The case study below is a realworld example that will provide an opportunity for you to put the pieces together by
analyzing a scenario. Read the case study and respond to the exercises at the end of
this module. You may refer back to the other modules as needed.
A. Case Study
Strategic Enterprise Management at WeCanMakeIt
Corporation
WeCanMakeIt (WCMI) Corporation, located in Old Sneaker, Ohio, manufactures
component parts for the commercial air conditioning industry. WCMI employs
approximately 2,000 people in five locations nationwide. Over the past three years,
as part of its ongoing expansion strategy, WCMI has acquired two additional
companies to expand its manufacturing and sales capability in the United States.
Like many organizations that acquire new companies, WCMI has retained the
previous management and are using their previous systems. Now WCMI is
challenged with collecting information for reporting purposes from three independent
information systems. Monthly financial reporting is compiled using a couple of quickly
developed interfaces that feed monthly summary data to headquarters. This
information is used for required financial reporting and provides management with
summary information.
During a recent annual strategic planning session held in conjunction with the annual
budget development, the CIO briefed the management committee on the challenges
and resulting increased expenses in the IT area due to the numerous hardware and
software platforms now requiring support. Expertise in the systems within the
subsidiaries resided with a few IT staff members. Due to job uncertainty and fear of
job loss created by the acquisitions, the CIO was concerned about the possibility of
these staff members leaving WCMI. The CIO was concerned that with insufficient
documentation of the newly acquired companies' systems, IT would be unable to
support these systems if the current staff were to leave, thereby exposing WCMI to
an unacceptable level of risk.
The interfaces that were implemented to allow WCMI to prepare its monthly reports
were based on the systems as they were at the time of the acquisition; however, any
change in requirements to those systems to bring them in line with WCMI's
processes, or additional requests for ad hoc reports, could not easily be
accommodated. The resources required to maintain this patchwork of systems
hindered the IT staff's ability to respond to strategic initiatives, such as implementing
new technology to assist the sales staff and exploring RFID technology that would
improve the supply chain management processes.
The CEO, after listening to the CIO's concerns, recognized the importance of
centralizing applications and updating the IT infrastructure across WCMI, including
the new subsidiaries. Her primary goal was to have an enterprise-wide information
system that would facilitate management, standardize processes, improve decision
support, and provide reports to all levels to assist with the operational decisions of
the various supervisors and managers. The CIO, in conjunction with the business
staff, set about developing the business case for the development and
implementation of an enterprise system. The business case had to identify business
process improvements and their potential benefits, tangible and intangible, as well as
the impact on the total cost of ownership of the IT infrastructure and the
development costs for the new system.
In early 2011, after receiving the board's approval, the CIO kicked off a project to
implement enterprise resource planning software, using SAP as the software vendor
and Deloitte & Touche to provide consultant support for the implementation. The
timeline called for an intense implementation effort involving all of the major
business functions (HR, finance, SCM, and CRM) going live in January 2012. To allow
the impacted departments to test functionality with test data based on the most
recent transactions, the schedule called for a prototype to be available by July 2011
for the business units' review. Complete data conversion was planned for November
30, 2011, to allow for parallel processing in the month of December before the
cutover to the new system in 2012.
The Deloitte & Touche consultants' roles included technical project management and
system configuration, based on their expertise in the SAP software and experience
with other similar implementations. In addition, training was outsourced to a thirdparty vendor who had participated in numerous other SAP projects, and who was
very familiar with SAP processes and understood the difficulties in this type of
implementation. Training was to include end-user classroom training and
development of online computer-based training that would be available to support
users moving forward. It was recognized that due to the effort required, both to
convert the existing data and to enter redundant data for the parallel processing,
temporary help would have to be hired in December 2011 to augment the existing
staff.
With great fanfare, a project kickoff meeting was held in February 2011, and the
team members began their project tasks. Because the regular job requirements of
various team members limited their availability to support the project, the prototype
was delayed and unavailable until early fall. This conflict meant that various business
functions could not begin their testing until late September. As the business process
reengineering study developed, it became obvious that decisions made early in the
project had to be revisited because the team members now had a better
understanding of industry best practices. This evolved as the WCMI team members
learned about the functionality and potential of the SAP system and the consultants
better understood WCMI's business requirements.
Not to be deterred, the CIO maintained her original timeline and began requiring
project team leaders from the various business functions to attend weekly meetings
to identify progress and problems, and to develop solutions and action plans. Finally,
those weekly reports made it apparent that full functionality could not be deployed in
early 2012. The scope was modified, minimizing "nice-to-have" functionality while
focusing on the "must-have" functions. Feedback from the prototype testing resulted
in additional changes to the design, which was expected. During the fall, other
department managers, who had not involved themselves in the project because of
other business needs, learned about the new system and expressed concerns about
the missing functionality and the risk of not meeting the implementation schedule.
As the deadline for data conversion and parallel processing drew near, data integrity
issues arose, due to keying errors by the temporary staff. The parallel operation of
the two systems was therefore delayed because it depended on the data conversion
providing valid data. As year-end bonus time approached, the CIO became
concerned about the project's progress and feared being blamed for the problems.
The CIO and the Technology Steering Committee had to make critical decisions
about whether to (1) proceed with the January 2012 implementation as scheduled,
or (2) delay implementation and conversion until appropriate testing could be
completed and all problems corrected.
Congratulations. You have completed the online course modules for Foundations of
Enterprise and Information Systems!
References
Paul, L. G. (2004, February 1). How to make your best case. CIO Magazine.
Retrieved July 11, 2011, from the LexisNexis Academic database.
Schmidt, M. J. (2005). What's a business case? And other frequently asked
questions. Solution Matrix Ltd. Retrieved January 11, 2006, from
http://www.solutionmatrix.com/downloads/Whats_a_Business_Case.pdf
Whitten, J. L., & Bentley, L. D. (2008). Introduction to systems analysis and design.
New York: McGraw-Hill. pp. 80-83.
Return to top of page
