General support

Help Desk
A help desk operation is where people respond to questions and problems
from employees. You can have a help desk with a narrow scope responding only
to systems and technology problems, or you can broaden it to include building
problems, equipment problems, and any other nonemergency request.
Should you staff a help desk with employees? Clearly, these positions are
junior level because almost all complex problems have to be referred to more
technical people. It takes time to establish a help desk function. Start with defining the scope of the help desk. You need to find the people to whom you will
refer calls. You will require time to build a database of frequently asked
questions (FAQs), and software to track calls must be obtained. Then you must
put the word out to employees that the help desk exists.
What are some of the risks of outsourcing the help desk? The basic concern is
that quality of service is maintained. Another risk is that the estimated workload
understates the actual workload by a substantial amount leading to increased cost.
Some suggestions for handling the help desk are as follows:
• Set up the help desk with internal employees first. This will provide you
with a better understanding of the workload. In this way, you avoid the
expensive setup costs of having a vendor establish the help desk.
• Implement a quality measurement program in which you follow up with
people who have requested help to determine the level of service.
• Ensure that you have a personnel replacement condition in the contract so
that if a contract person is not performing, there can be rapid replacement.
PC and General Computer Training
PC and general computer training include training in word processing,
spreadsheets, graphics, electronic mail, and basic database management systems.
In the early 1980s, companies conducted this training with internal staff. As that
decade came to a close, most of it was outsourced to companies or local univer-
sities. Now, some companies require software expertise. Many others offer
videotaped instructions, CD-ROM, or other training.
What mistakes do firms make in outsourcing training? One mistake is that they
outsource training in more specific and technical software to general firms who
just teach courses. This is part of a bigger mistake when a company wants to out-
source everything to one vendor, often resulting in average to poor levels of train-
ing. For example, some instructors stand up and read materials. People could
probably get more out of a manual. It is also very difficult to determine if the
training is successful. People evaluate a class at the end, but then they may or may
not use the material right away. Material not used for a long time is generally lost.
Application System and Other Training
There is a wide range of training that is possible. Examples lie in database
management systems, the internet, general management training, and so on.
Another area is the software application system if you purchase a software
package. For most of these topics, you would consider using outside help. Man-
agers often make mistakes in outsourcing this training. Following are some of
the pitfalls to avoid:
• The company specifies the training requirements only generally. The train-
ing that is delivered is not really suited to the company.
• The company fails to work with the training firm in the preparation and re-
view of materials.
• There is no formal review of the training after it is given.
• The expectations of the company and the attendees are not matched by
what is delivered by the vendor through a lack of forward planning.

NETWORK RELATED

Network Planning and Management
Network planning is important to the business. There is an ongoing role in
measuring the network, determining what steps to take to improve performance,
and planning for upgrades, replacement, and expansion. Unless an organization
is quite small, this role is often performed by internal staff. This role also over-
sees contract work in installation and testing. The role has been expanded to ex-
tranets and linking to the internet as well as handling internal networks. Growth
in internet use has made this position more significant.
Network Installation and Testing
You are not going to install and test a network every day. Network installation
and upgrades are done as discrete tasks. Installation requires specialized equip-
ment in terms of cabling tools, crimping tools, and so on, and network testing re-
quires special monitoring equipment. These functions are also generic and not
company specific, which make them suitable candidates for outsourcing.
Network Operation and Troubleshooting
With the increased reliability of networks, there is less of a need for internal
staff to be assigned to troubleshoot network problems. For large organizations, it
makes sense to have this function performed internally, allowing for identifica-
tion of the problem prior to contacting a vendor to do repairs. The effect is to
reduce overall cost and the mean time for repairs.

THE OUTSOURCER’S VIEW OF THE WORLD

What makes a firm enter outsourcing as a business? A firm decides to enter
outsourcing in a particular area because they believe they have expertise in that
area, possess excess capacity so that they can serve new or additional clients,
and obviously make money doing it. The long-term nature of the contract is also
an incentive, along with an almost virtual guarantee that unless they really screw
it up or the business changes, the client will remain with them How does an outsourcer make money? They have to do the work that you do
at lower cost, they have to provide added value, or achieve some combination of
these. Here are some specific steps taken by outsourcers:
• Achieve economies of scale by sharing resources (hardware, network, facilities, software, people).
• Provide smarter or lower-cost resources to do the work.
• Charge for add-on requests and services that were previously done internally and taken for granted.
• Use more modern or more capable tools and methods that increase effectiveness and efficiency.

Assess Outsourcing

INTRODUCTION
Outsourcing
occurs when a company contracts with a supplier or vendor to
provide specific services and support for multiple information technology (IT)
activities. Note that outsourcing typically refers to services and not purchased
products. Providing an ongoing service means that there is a need for both a
managerial and technical relationship between the supplier and the customer
firm. Another observation is that most outsourcing agreements cover several
years (up to 5– 10 years in some cases). Why this long? Because of the time it
takes to come up to speed and become efficient as well as the practical infeasi-
bility of switching suppliers quickly.
Outsourcing of information systems (IS) has been going on much longer than
you might imagine. It began in the 1960s with facilities management. Compa-
nies had no IT or IS organization and did not know what to do. Therefore, they
contracted with firms such as IBM, Computer Sciences Corporation, and others
to run their computer center. Firms such as these also provided programmers and
systems analysts on-site to do work on a time and materials basis.
Another example was the use of service bureaus. Companies who required
data processing but could not afford their own computers used service bureaus.
They brought their data to the service bureau who processed it and returned out-
put to the company.
A third example was external timesharing. Computers inside companies in
the late 1960s and early 1970s were batch processing machines. To get access to
online systems, you had to use a service bureau or timesharing firm. Charges
were based on usage. This was extremely expensive, but firms had little choice.
Outside timesharing for some firms ate up 10% of their IT budget.
As the 1980s progressed, companies eliminated outside timesharing and
service bureaus and expanded their internal IT organizations. The height of this
centralized model was probably from 1979 to 1982—just prior to the introduc-
tion of the personal computer (PC) into corporations. With the introduction and
spread of local area networks (LANS) and more PCs, IT groups started to
outsource basic training, hardware maintenance, and some support. In the late
1980s the use of software packages increased as their capabilities rose and the
underlying fourth-generation languages improved. Outsourcing of business
activities began in this decade.
The 1990s saw the continued rise of the use of packages (a form of outsourc-
ing) as well as expanded outsourcing of specific tasks and work. The use of con-
tractor and consultant resources expanded. For some firms, more than 40% of
the overall IT headcount consisted of contractors. The 1990s also experienced
major attempts at outsourcing all the IT activities to one or several companies.
Some of these failed miserably and the firms had to bring IT back into their
organizations. In other cases, the firms began to contract out more narrowly
defined activities. Companies also focused on core business activities and
increasingly outsourced business functions.
What do these observations show? First, there is a substantial body of experi-
ence going back to before the late 1950s in outsourcing. This should be used to
help you today. Second, several basic findings can be noted:
• Although outsourcing in IT may be worthwhile, outsourcing of other busi-
ness activities may yield more benefits due to the size and nature of the
work being performed. Mundane activities, such as shipping, telephone and
utilities, and so on, are often outsourced. Many banks outsource their teller
operations.
• It is valuable to develop a strategy and approach for outsourcing due to the
complexity and interrelationships among IT activities. It is also important
because of the requirement by vendors to have multiple-year agreements.

REDUCED SCHEDULE AND COST APPROACH

This chapter has defined a great deal of work. If you attempt to do it alone,
you will never finish. If you attempt to be too precise, you will fail. The first sug-
gestion is to involve people in the business, IT, and your current vendor staff to
help in the analysis. This needs to be a collaborative effort. If they participate,
then there is more likelihood that they will support the results and be committed
to the project.
A second recommendation to speed things up is to generate outlines and
structures for documents and presentations at the beginning of the project.
Then esh these out as you go. A related idea is to market the results in an infor-
mal way to managers as you go. This will reduce the time it will take later for
them to understand what you have done and subsequently the time to gain
approval.
EXAMPLES
Millenium Manufacturing ultimately selected to do their own development.
Their decision was based on the fact that even though the new process simplified
the current process, there were still unique features that could not be addressed
by any existing software package.
Secour Retailing selected a package but did not do the analysis of the first step.
They roughly estimated costs and benefits and gained management support. The
package was later acquired and then found to be lacking in key features. The
result was extensive customization.
Roberts Agency, the transportation agency, performed the steps and
concluded that they would have to do both development and package
acquisition. There was no package that could handle certain functions; however,
if those functions were excluded, there was a package with a close fit.
LESSONS LEARNED
• Concentrate on no more than five sample transactions in defining the new
process. The detailed analysis for all transactions will be performed later.
• Identify the shadow systems and workarounds early. Get recognition of
these from the business department. This will gain their support for the new
process. Give attention to these in presentations to illustrate the shortcomings of the current system.
• Obtain a list of people who can review what you have done early on. This
includes a business staff member who can review the process work you do and the benefits and an IT person who can review architecture, technical
approach, schedules, and costs.
SUMMARY
In this chapter, you defined the overall new process along with requirements
and benefits. You then proceeded to develop estimates for costs, schedules, and
project plans. None of this will be complete. However, these are essential to make
the decision on what direction to take.
This chapter has defined major steps that must be taken prior to plunging into
development or software acquisition. If necessary, you should spend more time
here because every additional hour will likely save much more time later. The
steps have been defined in a linear way. However, you should consider starting
these in parallel and then building the end products in parallel.
WHAT TO DO NEXT
• For a current project that is underway—either a package implementation
or development project —review what has been done and what was done to
address the steps in this chapter. You will find that the steps were probably
not carried out overall. What impact has this had in terms of the project?
What surprises have surfaced?
• Practice carrying out the steps on a very small process within your depart-
ment. Walk through each step to determine what could be done. Ask the
following questions:
1. What political barriers would you face if you really did the work?
2. What is the condition of the current process and technology? To what
extent do business and IT staff recognize this?

WHAT CAN GO WRONG?

From past projects, here is a list of things that can go wrong:
• The software package is selected before the new process is even defined.
This will likely be very expensive because there are so many unknowns.
The effort to define a new process and proceed with the steps in this chapter
may stretch out the time but only entail labor effort. These steps greatly
reduce the risk.
• Parties overpromise what they can deliver. IT may promise to do develop-
ment but lack resources. Business departments may indicate that they will
pour resources into the project. Vendors may indicate that their software
will meet almost all needs without modification. Part of this stems from
people’s optimism. Don’t accept any of this. Reserve judgment until later.
• Management often attempts to pin down these cost and schedule estimates
as the final ones. This is impossible without further analysis. The estimates
are necessary to make a decision. Head this one off by stating repeatedly
that the estimates will be revised.

STEP 6: MAKE THE BUY OR BUILD DECISION

You are now in a position to make a fundamental decision. Should you at-
tempt to develop the application software yourself or with others, or should you
acquire a software package? Within this question are several others:
• If you develop it yourself, what types of tools will you use? Who will do
the work?
• If you acquire a package, what software modifications will be needed? Who
will make these changes? What vendor support will be required?
There are a number of factors in uencing the answers to these questions.
These include the following:

•
Availability of the current IT staff to do development
. The IT staff already is
filled up with work. Adding more work means that something has to give.
•
Skills and knowledge of the current IT staff
. If you have selected a technol-
ogy direction and architecture that are foreign to the staff, you must allow
for a learning curve if you do development internally.
•
Availability and skill levels of the vendor
. The vendor includes both the
supplier of the software package directly as well as the staff of the
underlying database management system or Fourth Generation Language.
•
Availability, skills, and costs of consultants
. These consultants can aid you
in implementing a package or in supporting new development.
Due to the importance of this decision, you should proceed discretely.

STEP 5: DETERMINE THE TECHNOLOGY APPROACH AND REFINE COSTS AND BENEFITS

In Step 2, you determined requirements for the new process. In some cases,
you can specify the technology at that point if the situation is relatively simple.
However, there may be a need for further analysis. The purpose of this step is to
define the new systems and technology and then update the costs and benefits for
the new process. You will then be in a position to make the decision to acquire a
software package or build a system.
The scope of this step includes all the hardware, network, and software components but excludes the application software decision. The application software
decision is directly affected by the direction you take here. If you select an
environment or
architecture
(technology structure) for which there are no off-
the-shelf software packages, you will do development. A guideline here is to
keep the architecture open to admit the potential of software packages. You will
be refining what you identify here as you get further into implementation.
In Steps 2 and 3, you identified general components and attempted to
estimate what was needed. This was prior to the management presentation (Step
4) where you garnered support and the endorsement to proceed. You are now in a
position to involve the IT group more directly in determining what specific systems and components are needed. The detailed list in the costing figure still applies and can be used as a starting point.

STEP 4: PRESENT THE RESULTS TO MANAGEMENT

Presenting the results to management sounds straightforward, but it is fraught
with political peril. You risk alienating staff involved in the process or IT staff
who support the old system, even if you gain management support. We divide
this step into actions.

STEP 3: IDENTIFY COSTS AND BENEFITS COSTS

You must develop as detailed a list of costs as possible. A big mistake people
make is the omission of certain critical costs. For this reason, a starting list of
cost elements has been provided in Figure 3.4. Where do you obtain the cost
Network
• Cabling
• Network facilities work and preparation
• Routers / hubs / gateways / bridges
• Network operating system
• Network management software
• Network security software
• Internet and remote computer access
• Leased lines
• Additional WAN components
• Additional LAN components
• Mobile communications
• Network testing and diagnostic equipment
Hardware
• File server
• Database server
• Application software server
• Fax server
• Electronic commerce server
• Firewall server
• Printers
• Scanners
• Mobile hardware
• PCs and workstations
• Test environment hardware
• Backup/recovery hardware
• Specific industry hardware
• UPS hardware and surge supression devices
Software
• Server operating system
• Workstation operating system
• Database management systems
• Fourth-generation language
• Internet software
• PC/workstation software
• Electronic mail software
• Groupware software
• Security software
• Backup/recovery software
• Utilities
Installation support
• Cabling and network support —office level
• WAN labor
• Hardware installation and testing
• System software installation and testing
• Interface support
• Testing support


information? You have requirements from the previous step. To get prices and
estimates of work, there are support groups in your company. You can also surf
vendor sites on the web and even contact vendors for general information. Be
careful here in that you may get the vendors too excited, and they may interfere
with your work.
Once you have determined the number and type of component needed for
each requirement, you are in a position to justify these. In this figure, the justification for the quantity of the item needed appears in the third column and the justification for the model or type of item is
in the last column.

STEP 2: DETERMINE REQUIREMENTS FOR THE NEW PROCESS

Requirements are specifications and features for all aspects of the new
process. They do not just apply to software and hardware. Here are categories of
requirements:
1. Organization
• Staffing—number of people, education, and experience; specific skills
• Management—number of supervisors, skills and knowledge of man-
agers needed
• Support requirements —roles and responsibilities of specific support
staff required
2. Process
• Policies — rules on what and how the work is to be performed
• Procedures —specific work ow steps
3. Infrastructure
• General location
• Offices and buildings
• Voice communications
• General office layout
• Access control
• Office equipment and furniture
• Other building and space requirements
4. Networks
• Local area networks (LANs)
• Mobile communications
• Wide area networks (WANs)
• Internet and international communications
• Network interfaces
5. Hardware
• Servers
• Workstations
• Portable computers and mobile equipment
• Mainframe and minicomputers
6. General software
• Operating systems
• Utilities
• Database management systems
• Fourth-Generation Languages
• Personal computer software
• Groupware
• Electronic mail
• Internet communications (browsers, web servers, firewalls, etc.)
• Scheduling and other collaborative software
7. Application software functions and features
• Input
• Business rules
• Processing requirements
• Output
• Interfaces
• Management control
What is the form of these requirements? A good format is lists. Each list has
several columns. The first column is the requirement, the second consists of
detailed or example specifications, and the third consists of comments on the
requirement. You might comment on the importance of the requirement or
provide additional detail in the last column.
As you identify these requirements, what do you do with them? First, you
have to ensure that they are really necessary. Evaluate this by constructing
several additional tables. Begin at the transaction level . Second,
build to the work ow level. In addition you will have general
requirements that cross all transactions.

These tables will be expanded when you consider costs and benefits in the
next step. The information in the tables shows how the new process requires
these items. Any later discussion of specific requirements can then be related
back to the transactions and the work ow. Defining these requirements helps
you to validate the new process

STEP 1: DEFINE THE NEW BUSINESS PROCESS

For a detailed step-by-step approach, you might consult a process improve-
ment book (see, for example, Lientz and Rea, 1998). Begin with a detailed
analysis of the business process. Your work should include shadow systems and
exceptions as well as the “run of the mill” work supported by the current system.
Your analysis must be carried out at the transaction level because benefits and
requirements build from here. Note that this approach is much more time
consuming than sitting down and making a feature list for new software —
thereby avoiding the process and focusing on the software. Until you define the
new process in detail, you really cannot build a feature or requirement list.
You can define the new process in terms of the dimensions listed as follows:
•
Organization.
Which organization will perform the new process? Will it be
the same department, another department, suppliers, customers, or anoutsourcing firm? The decision has an impact on the systems and
technology to be used. Wal-Mart transferred functions to suppliers as have
automobile manufacturers. Banks transferred functions to customers
through banking on-line and automated teller machines (ATMs).
•
Capture information.
How, when, and where will information be captured?
With a new process, consider capturing the data earlier in the process or at
the front end of the process. Perhaps, you can capture information through
electronic commerce, Electronic Data Interchange (EDI), or scanning and
imaging.
•
Output of process.
What happens to output from the new process? Don’t
restrict yourself to the current process and system. Be creative. Perhaps, if
the new system is based on a database management system or a Fourth-
Generation Language (4GL), you can cut down programmed reports.
Maybe you can establish an automated interface with later systems. Auto-
mated interfaces to following processes reduced data entry and errors by
more than 30% at Vision Insurance.
•
Who will do the work?
The first dimension determined the organization.
Here you define who will actually perform tasks in the process. If you are
thinking of providing a simpler, easier-to-use system, then you can lower
the personnel requirements.
•
Paper and tracking.
You should try to eliminate manual tracking and paper-
work in the new process. If the new system has work ow tracking when
you know where every transaction is, then you can cut out logs and forms
used to summarize production and track work.
•
Policies.
Every process is governed by policies of the organization. Policies
in turn affect the procedures, work ow, and systems. When defining a new
process, consider simplifying the policies. This will reduce your system
requirements and, perhaps, speed up implementation. Simplifying policies
also leads to eliminating exception transactions. In one bank, the policies
were changed so that 15% of the workload was reduced and the number of
exceptions reduced by 45%!
•
Location.
Where will the work be performed? Which offices and space will
be employed? How will the office space be laid out? In one case, the cur-
rent office space for data entry consisted of partitioned offices. It was too
hard to observe the work being done. This was replaced by open space with
the supervisors desk on a raised oor, allowing the supervisor to oversee
the work. Moving to a better location for a distribution firm reduced em-
ployee absenteeism and improved employee morale.
•
Systems and technology.
What new technologies are appropriate to perform
the internal work of the process? Can more of the process be automated
through these technologies? Such steps could eliminate some of the shadow
systems.

Defining the New Process, Benefits, and Requirements

INTRODUCTION
The process has been selected. A process plan and an implementation strategy
are in place, providing direction. Now you can get down to the details. Following
are the steps:
• Step 1: Define the new business process in line with the process plan and
strategy.
• Step 2: Determine requirements for the new process.
• Step 3: Identify generally costs and benefits of the new process.
• Step 4: Present the results to management for review and approval.
• Step 5: Define the technology approach based on requirements.
• Step 6: Determine whether to buy or to build a system.
• Step 7: Decide who will do the work. Outsourcing is considered here and is
the subject of Chapter 4.
Why go through all this work? Why not just start gathering requirements and
then move to Step 6? Because if you start with requirements, you will likely be
drawn to the problems in the current system and will concentrate on replacing it.
You will most likely ignore the problems in the process, the shadow systems,
and workarounds for exceptions. It is very possible that any new system built or
bought will not fit the process plan or strategy without taking the previous steps
because of the lack of knowledge.
Put these together and you can see that, if any benefits existed at all, they
would be greatly reduced. In some companies, a new system obtained without
going through the steps has made things worse.

The goals of the work here as follows:
• Define a new business process that is complete and that can be effectively
supported by systems and technology.
• Determine an implementation approach for the new system that will yield
benefits and be capable of being installed within budget and schedule with
minimal risk.
What are some of the risks? The technology selected may not be established.
The effort to interface the new system to current technologies and systems may
be greatly underestimated. You might miss some shadow systems leaving the
organization to struggle with these later.
The scope of the work can be viewed in four parts:
• Process —all aspects of the business process as well as interfaces
• Organization —all departments that provide support to the process
• Technology—both current systems and technology indirectly and directly
employed in the process
• Dependent processes —with every major process, there are typically lesser
supporting processes and activities
Leaving something out here can exact a high price later. If you do not involve a
specific department, you risk interface problems and hostility later. Omitting a
part of a process or technology may increase the interface effort. It is tempting to
exclude some processes to keep the scope of the project limited. You are then
going to pay the price later when you are forced to retrofit interfaces between
two processes.

WHAT TO DO NEXT

1. Select a small process with which you are familiar. Make two lists —one
of issues involving the process and the other involving some of the
transactions.
2. Now assume that you could apply any technology to improve the process
without regard for cost. Develop a work ow of how transactions in new
process would work. Compare these with the corresponding transactions
in the current process.
3. Based on the work in the first two exercises, define requirements for the
new process and system. Write down the changes that must occur to move
from the current process to the new process for the transactions you
specified.

SUMMARY

After reading this chapter, you may be thinking that there is a great deal of
start-up work to perform. Why not just get to the detail? Suppose that you do
plunge directly into the details of a process. People will wonder what the project
purpose and scope are and will question what you are doing. There is no
common vision or support for change. Some people do not want to change the
process. Others want a new system, but that is it. Still others want radical
change. If you spend the time up front, you will be more likely to gain support.

A more basic question is about you. Do you really want to work on a process
that has no direction or plan? This seems pointless without objectives and scope.
The plan, strategy, and systems are all interrelated.

REDUCED SCHEDULE AND LOW COST APPROACH

Do a lot of the work yourself up front. This will help to guide the structure
and completeness of the plan and strategy. It will also save time and money.
Increase the involvement of others in review and refinement. Develop successive
drafts of the plan and strategy in the forms of lists and bulleted items. Design
your transaction diagrams as quickly as possible because you want to get a
reaction and have people get comfortable with the detail. Use presentations
instead of documents. They are simpler and faster to create and modify.
To reduce any gap in time between the plan and strategy and between the
strategy and detailed work, you should concentrate on the strategy as soon as
you have defined your first version of the plan. Then you can work in parallel on
both. This will also give people a more complete picture of what is going on.
Another idea to reduce time is to market the results to managers as you go. In
that way, when the final products are complete, there will be no surprises. You
will be able to directly proceed to the next step in Chapter 3. We prefer informal
presentations in which you walk through the transactions first and then expand
management’s understanding of the general process from the bottom up.

LESSONS LEARNED

• In developing the process plan, select some sample transactions to validate
the plan and to show specifically what will happen with the new process.
Otherwise, the new process appears too theoretical.
• When defining the new transaction, go to where the work is being per-
formed and simulate it in terms of work ow. This will get people involved
and help make the new transaction more tangible.
• In presenting or documenting the individual transactions in the plan, use
simple owcharts that re ect current outcomes and future projections.
Then, to show the impact of the plan, illustrate the current outcomes with
the steps crossed out using the red universal “no” sign.
• In the plan, you identified specific issues pertaining to the current process.
Relate these issues to the individual transactions by showing to which steps
they apply. Then show how the issues are addressed in the diagram of the
new transaction.
• Seek out business staff participation in the development of the process plan.
Have them make part of the presentation related to transactions. They have
more credibility than you do because they are close to the action.
• In defining a process implementation strategy, define several alternatives,
including the three examples given in this chapter. For each alternative,
consider building a table such as the following for each alternative. The
actions are listed in the first five columns and the benefits are indicated in
the last column.

EXAMPLES

The method presented in this chapter was applied to Millenium Manufacturing, an Asian manufacturing firm. The firm had grown during good Asian times.
Seeing clouds on the horizon, they wanted to get new, more efficient systems
and processes. They had made one attempt at getting a package, but this fell
apart because the package appeared to have few benefits.
The approach was applied to 10 critical manufacturing and distribution
processes at Millenium. Here, the sales process is used as an example. Sales
crossed marketing, accounting, order entry, warehousing, and billing. Four trans-
actions were identified. One was the most common. A second applied to big
ticket items. The other two applied to exceptions. The diagram of a transaction
in the current process appears in Figure 2.1. The one for the new transaction appears in Figure 2.2. Note that the new process involves electronic commerce and
is quite different from the current process. An intermediate process was identified in Figure 2.3. The evolution is to proceed through Figure 2.3 and toward
Figure 2.2 from Figure 2.1. This model was the same for all transactions.
The next step was to show how the process, organization, systems, and roles
would change as work progressed (Table 2.1). In this table, the process is simplified in preparation for later implementation. Management fears of risk and
positive/negative impacts are eased through the organization and roles entries.
Atlas Bank had spent a lot of money on new software, and the staff claimed
to be happy and to think it was a success. Management saw little results from the
money. Productivity and staffing levels were the same. Customer service was unchanged. As a result, management was frustrated. At this point, they decided to
invoke a policy that all major systems expenditures had to be accompanied by
detailed, enforceable savings and benefits. It became readily apparent that the
business process would have to be changed to achieve this policy.
The first area of the bank to follow the policy was the credit card and lending
area. A process plan was developed for installment loan collections. The benefits
were great if changes were made in both the systems and the processes.
However, this was only a small part of the business unit. Parallel process
plans were developed for credit card, real estate, and leasing in the business
areas of application processing, servicing, collections, and charge-off/recovery.
With these process plans in place, an implementation strategy was devised.

WHAT CAN GO WRONG?

At this early stage in implementation, you would think that not much can go
wrong. After all, you have not spent much money. You have had little
opportunity to make any enemies. What can go wrong?
•
Resistance to change.
People see where the plan and strategy are going.
They see that they will lose political power or organizational clout. They think it
is easier to shut it down now rather than to wait until the implementation steam-
roller gets going. In some cases, they are correct. Where can resistance arise? We
examine several sources and suggest some countermeasures. Business unit staff
may be threatened by change. The best approach is to involve them in the plan
development. This will increase their confidence. Another source is middle-level
business management. This is one of the most difficult to deal with because
many changes will restructure their jobs and work more than those of the staff.
You might try minimizing the impact and stressing the details of change. Upper-
level management may have approved similar projects in the past that failed.
Indicate and stress the low risk and confidence in change.
•
The process selected for this is too large or complex.
You cannot get your
arms around the process plan. Nothing seems to work. People have a hard time
supporting something that is so large. What should you do? Segment the process
within departments and work on parts of the process. This bottom-up approach
will gain more support. How do you guard against getting less than dramatic
results since you watered the process down to the department level? After
performing the transactions at the department level, consider the overall process
across departments to show how it can be improved. This will also allow you to
indicate problems involved in interfaces.
•
Management fear.
Company management become fearful and embarrassed
because of the problems now visible with the process. How could this have
happened? Who let it happen? What can be done? They may wonder what other
problems exist. Here you must proved some perspective that this happens with
all processes over time. They need work and improvement.
•
Impatient for results.
The process plan and strategy appear to be okay.
However, managers want results faster. This will take too long. That is precisely
why some managers go for radical reengineering — to get a quick hit. You
should anticipate this and head it off by considering it an alternative and reject-
ing it because of the potential negative impacts. That is, good people will leave;
turkeys will stay. Without technology change, there is only so much that can be
done with the process.

HOW TO BUILD YOUR FIRST PROCESS PLAN

Start with a process that crosses two departments. Also, make sure that the
process is not politically active or embroiled in disputes. The key search terms
are “mundane” and “medium size”. The first time out is a learning experience.
You will have to do much of the work yourself because most people require a
trigger or model to demonstrate what they are after. This means that you should
develop a model, scenario, or “straw man” of the process plan and strategy.
These trigger reactions from people and get them involved. Do not just sit there
and ask them what they think. Many people are so involved in their daily work
that they have not had time to consider changes or improvement to any extent.
However, they can react.
After you collect information and build your first “straw-man” plan, seek
reaction. Show people how their input changes the plan. Get them involved in
defining benefits and issues. Make sure that you maintain almost continu-
ous contact.

OBSERVATIONS ON BUSINESS PROCESSES

We begin with a look at business processes. A
business process
consists of
activities that handle the processing of transactions or work and produce specific
results. Business processes can be informal or casual in that they lack formal
procedures or systems, or they can be very formal and structured. At one
extreme, they can be highly structured such as automated teller machine (ATM)
transactions. At the other extreme is strategic business planning that involves
creative thought. A business process often starts casually when a company is
getting started. As time goes by, the process changes to fit the situation. It has to
evolve to take on new types of work. Eventually, the process is shaped by many
factors, some of which are as follows:
•
People who work on the process.
Each new employee who works on the
process brings his or her skills and experience (or lack thereof) to the
process. That is, an employee’s previous practices have an impact on his or
her current work.
•
Training and procedures for staff.
If there are formal materials and training
that are implemented, then each new person learns the process the same
way. If, as in many cases, it is informal and learning occurs on the job, then
each person will learn differently and work will be done with greater
variation.
•
Changes in workload and types.
If a new type of work or transaction has to
be addressed, can the process handle it? If not, then what do people do?
Often, they will create a manual exception process. As these exceptions
increase, people may try to make them more efficient by creating a shadow
system. An example occurs when business staff requests changes for an
online system from an information technology (IT) group. Suppose they are
told that it will take too long. Desperate for a solution, they hire a student
intern to program something in a spreadsheet. Voila! A new shadow system
has been created. The longer this continues, the more dependent the depart-
ment is on the shadow systems, and the less real work is performed by the
basic system. Thus, if you just replace the basic system, you miss the
shadow systems where more than one half of the work is being done.
•
Management turnover.
Each manager may want to put his or her stamp on
the process. They may do this by organizing work differently or by creating
more bureaucracy and reports. There is cumulative overhead.
•
Other departments and processes.
If one department that feeds work into
your process changes their process, you will likely have to modify yours to
accommodate this new input.
Each of these factors can have both positive and negative effects on the
process. In many cases, if work is not performed to tune or improve the process,
gradual deterioration takes place. What types of deterioration can occur? Here
are some examples:
• The process becomes so specialized that only certain people can perform
certain transactions. If a person is sick, all transactions handled by that
person wait until his or her return. Knowledge is spread across many
people, and the process loses any economies of scale.
• The process has little central process. Every piece of work is classified as
an exception type. This is a nightmare.
• There is a lack of management will. The system appears impossible to
change; however, changing organization and staff are impossible options.
Thus, the process stays the same and things get worse.
• As workload and exceptions increase, the extent of manual labor increases
and the value of the procedures and training decrease.
Organizations knowingly can allow deterioration to occur. In a large bank,
management wanted to issue a new credit card. The IT group could not respond
fast enough, so management decided to set up a manual group, contrary to the
standard process. Eventually, the card only attracted 500 customers. This was
too small of a response to be automated but too large to be eliminated. Another
manual empire was created and sustained. Staffing grew due to the deterioration
of a manual process.
Why is the deterioration allowed to continue? It happens gradually. Many
managers are not attracted to these everyday events because there is no short-
term fix and because it does not appear exciting. So the process continues.
Radical reengineering can be attempted to identify and address these processes,
but many of these projects fail. Why? A major reason was that the reengineering
did not consider the technology and how it could integrate with the business
process. Reengineering also missed the shadow processes.

STEPS IN DEVELOPING THE PROCESS PLAN AND STRATEGY

Following are the steps for assessing the process and developing the plan
and strategy:

•
Step 1: Analyze the current process and develop a process score card.
This
gives you a good idea of the existing issues and opportunities that a new
process and system can address.
•
Step 2: Develop a general concept about the new process.
The concept out-
lines what roles of organizations and types of automation are appropriate.
•
Step 3: Develop the process plan.
The plan addresses how you will progress
in concept from the situation in Step 1 to that in Step 2.
•
Step 4: Define the business process strategy.
This defines how the plan is to
be achieved.

You could spend months analyzing every transaction in the process in great
detail. This would be a return to the 1920s industrial engineering. You should
instead cover only a sample of transactions and only 5 to 10 steps per transac-
tion. Gather information by being trained to do the process. Perform the process
yourself if you can, given health and safety considerations. As is emphasized in
Chapter 3, avoid interviews. They are too formal and rigid.
What are the benefits of this work? First, you will have an idea of the poten-
tial for improvement. Second, you can identify and eliminate those processes for
which there is little room for improvement or for which technology does not ap-
pear to have great potential. Third, you can raise the level of interest among
managers and employees in fixing the process in addition to the system. Fourth,
you pave the way for estimating benefits and gathering requirements. You are
likely to develop substantially more process plans than you will initially handle
for project work.
It seems obvious that you would not want to embark on getting a new system
without a process plan. Yet, people often approach it this way. Why? They think
inside the systems box. They do not consider the process to be part of their
puzzle. This is wrong.

COMMON PROBLEMS WITH PROCESSES

Although this is not a book about business processes, you should be aware of
some common problems with processes so that you can spot them when you
perform analysis. Following are 11 problems that have been encountered
repeatedly:
1. The process is chopped like a salad. Many different people handle a
transaction; thus efficiency is greatly reduced. You cannot find a specific
piece of information easily.
2. The current system is only used as an afterthought at the end of the
process. All the preceding work is manual and labor intensive. The
current system is of little value to the group.
3. The staff employs workarounds to the system. Data elements in the
system are used for purposes other than those originally intended. For
example, a fax number might be entered for a person’s middle name.
4. There are no formal procedures. That is, the process is not documented.
You can detect this if you see a bunch of yellow “sticky notes” hanging
on the office walls or in cubicles. Everyone has their own way of using
the system.
5. There is one person involved in the process who knows everyone and is
the base of knowledge about the process. If this person is sick, the
process takes a dive. Beware of this person. If you modernize the process
and system, their empire disappears.
6. Work is being performed in shadow systems. Data is entered twice —
once in the shadow PC systems and once in the regular system.
7. There is hidden rework. People routinely have to correct errors so that
most transactions are handled several times. Efficiency is lost. However,
because there is no automated tracking of this, there is no management
awareness of the extent of the problem.
8. People make manual log entries for each transaction as it passes their
desk. This is common in departments where there is fear of intimidation.
The motto is “Keep a record of everything so that you have your XXXX
covered.”
9. There is no measurement of the business process in terms of costs, errors,
throughput, processing time, and so on. No one really knows what is
going on.
10. Employees do not care. They have stopped requesting improvements
because past ideas have been met with indifference. How do you detect
this? Ask people what their oddest transaction was. If they look at you
with a blank stare, then you can sense a lack of interest.
11. Interfaces among departments are poor. Process work is split among
several departments. One department does its part. The output then just
sits on a desk or table for hours. So much for overall processing
efficiency. No one is in control of the overall process.
View problems such as these as opportunities for improvement. If there were no
problems, then you probably would not consider implementing a new system.

A REAL WORLD APPROACH

This discussion can now be placed in a framework that serves as the basis for
this book. The approach is based on the following:
•
Importance of business processes in implementation.
IT has limited resources overall. There are precious few when you deduct
the overhead for ongoing support of current technology. Therefore, IT must
focus its energy on those business processes that are critical and where the
tangible, strategic benefits are the greatest. At every stage of decision mak-
ing in implementation, the business process must play a role.
•
Continuous involvement by business unit managers and staff
in implementation
.
Hand in hand with the business process are the roles of the business unit managers and staff. There is no room for spectators. Business people must
be players. They must be involved in more than one half of the implementa-
tion activities. Through participation they can shape the system, and
through understanding they can define the details of the business process
that will fit best with the technology. Implementation is mainly a game for
two players —IT and the business. Fortunately, the modern tools and
methods support this by enabling many activities to be performed by
business staff.
Some of you, upon reading this, might say, “Good idea, but these people
are too busy,” or, “They are not interested.” Well, do you want to implement
something for someone who is not interested? If they are too busy to
determine their own destiny through participation, are they going to use
the new system after implementation? Probably, yes, but not with recur-
ring energy.
•
Comprehensive approach to implementation that includes
politics, organization, and process as well as systems technology and
procedures.
If you ignore the organizational or political factors, you are much more
likely to fail. You may suffer
midinstallation paralysis
in which resistance
results in inertia. Specific guidelines for dealing with these factors are
presented in each chapter. Note that this is not a book about total change
and upheaval (one definition of reengineering); rather, it is the implementa-
tion of a changed business process that totally integrates with the technol-
ogy. After success in implementation and process change, there can be
organization restructuring and change.
•
The need to implement technology in synchronization to the new
or improved business process.
You cannot design and implement a new system without regard to the busi-
ness process it is intended to support. The business process must be defined
in part in advance of the technology implementation and then in parallel
with it. It cannot be defined ad hoc at the end. You do not want to fit the
process around the technology.

WHERE ARE THE BENEFITS?

Forget about the intangible benefits. So what if it looks better or is simpler?
These qualities only become benefits if they can be translated into tangible
savings, revenue, or productivity. Thus, ease of use is translated into reduced
training. Table 1.1 provides a list of tangible benefits and suggests how they can
be measured. Table 1.2 provides a list of intangible benefits and how they might
be converted into tangible benefits. It is okay to mention the fuzzy benefits as an
afterthought but not as a central theme.
Why take such a hard line? Because you have to be able to cull out the re-
quests for new systems and prioritize future work in terms of its impact. If you
equate tangible and intangible benefits, you risk credibility for IT and jeopardize
future management support.


Examples of Tangible Benefits
Benefits Comments
Ease of use Less training, fewer errors
More of the process covered Fewer shadow systems and manual work
Simpler transactions Faster to do the work, productivity
Productivity higher Reduced time per transaction
Simpler work Restructured jobs and descriptions
Reduced staff required Reduced cost of work
Reduced errors and rework Higher volume of work/time (more throughput)
Faster processing of work Higher volume of work/time


Examples of Intangible Benefits
Benefits Comments
Simpler Ease of usee
Less complex transactions Lower labor cost per transaction
Friendlier system Less trained and experienced staff needed
Better fit with process Productivity higher
Easier to support Lower support costs

Everyone talks about benefits when people approve an implementation
project. Yet it is interesting that this is forgotten after implementation has been
completed. Is it because people fear that there will be no benefits? Is it because
the benefits at the start were overstated? Or, is it because they did not measure
the business process before they began the implementation? Whatever the
reason, it is not uncommon. How should you address this? Following are some
guidelines:
• Measure the business process that will be supported by the new technology
when implemented. This will provide a baseline for later comparison.
• Measure at the general process or department level, as well as at the detailed
transaction level. This will provide validation for general measurements.
• Measure the improved process and new system at the transaction level and
work your way up to the process. This will provide a basis for before and
after comparison

TECHNIQUES OF THE PAST

The early days of programming were complex and involved massive amounts
of labor that yielded little results when compared with those of today. Many
readers of this book are probably unfamiliar with what it was like. Although you
can imagine punched cards, batch processing, and time delays for getting results
from testing, it is difficult to imagine the pitiful editing, debugging, and testing
tools. Hours were spent reading a hexadecimal memory dump to see what hap-
pened with a specific program that blew up. Although COBOL and FORTRAN
helped, the problems persisted. This environment clouded the approach that was
taken in implementing systems.
First, there had to be a life cycle. That is, you had to nail down requirements.
That was because if you allowed later changes in requirements, the design and
programming would unravel. Months of work could be lost. So business units
had to sign off in blood that requirements were final —even if they did not un-
derstand them. Similarly, for purposes of control, the design had to be com-
pleted, and signed off by the users prior to programming. Aspects of the design
sometimes could not be implemented due to the limitations on the technology.
A second impact was on documentation. Because the source and object code
were difficult to read and understand, it was necessary to attempt to use various
documentation aids. Flowcharts, decision tables, and so on were developed and
used. However, due to the limited resources, little of this documentation was
ever maintained. Moreover, the designers were sometimes not programmers;
thus, when the programmers got the design, they would throw it out and start
over again (good design, but impractical).
Third, structured methods were in turn developed to try to improve efficiency,
exibility, and communications among the team of developers. Few of these
methods actually worked. Surveys show that of literally hundreds of methods
developed, few or none are in business use today. Why, especially because some
actually were beneficial? They were too hard to enforce and validate. In one case
of success for a programming method, the manager took all the code home over
the weekend and reviewed it. With this level of oversight, it is no wonder that the
staff followed the method. What is the lesson learned here? The lesson is that a
tool must be capable of being monitored and measured in use. Otherwise, how
can you determine its benefits or impact?
A fourth problem was business unit involvement. Previously, there was little
for business people to do on the project. They could not understand the code or
do much testing due to its complexity. When implemented, the system or technology would work side by side with the business process. Because the
system was so unwieldly, there was no real hope of merging or melding these
together. The classic movie example of this was “Desk Set” with Spencer Tracy
and Kathryn Hepburn, where departments were to be computerized and made
efficient through batch processing. It was a classic failure.
This limited discussion provides the background of why people behave in the
old ways and why belief remains strong in traditional methods. You know that
things have changed in terms of tools, methods, the power of the technology, and
attitudes of business. Yet, there are still old patterns and habits that are difficult
to break. After all, people still teach younger students the old methods.
However, not all of this can be thrown out. There is a need for an organized
approach. To an extent, it has to be somewhat sequential. But you will probably
agree that an overall approach should re ect modern conditions.

TRENDS IN KNOWLEDGE MANAGEMENT

Knowledge management was once viewed as consisting of data warehousing
and data marts, exclusively. The idea was that you gathered data into a
warehouse and then used fairly exotic software tools perform data mining. The
concept was that this would help to give you a competitive edge. For some firms,
this has worked successfully; for others, it has been a disaster. No one used the
data in some firms and the data were not valid or useful in others. Today, knowl-
edge management is wider in scope. It encompasses gathering lessons learned
and making this information available to others. It also means gathering
information on how to do work in a business process more effectively and
getting employees to use the experience across time and space.
Knowledge management represents a unique area separate from software
development and software packages that target operational applications.
Knowledge management software tends to have an impact on the more strategic
processes of an organization as opposed to standard software

TRENDS IN SOFTWARE PACKAGES

Software packages have lagged behind the software tools. This is to be ex-
pected because software vendors must rewrite their systems using the new tools.
This occurred with the vendors’ adoption of database management systems,
fourth-generation languages, client-server systems, and intranet systems.
Packages now have exibility through control tables and, to some extent,
through object libraries. The next wave of change in packages may be toward
object-oriented software packages in which an organization customizes an
application much more than is possible with tables.
The popularity of software packages is growing for several reasons. The
packages have more capabilities than in the past. Companies lack the internal
resources and time to develop the software on their own. The internal legacy
systems have aged to the point where many must be replaced (e.g., Year 2000
problems). Management views these packages as a rapid fix to both business
processes and systems —just shove the package and fit the process around the
package. Failure occurs often because of this last faulty assumption. Processes
are not rubber bands or silly putty that can fit anything. Instead, they re ect the
unique organizational, cultural, social, political, and industrial settings of the
firm at that time and place.
In the past, you could select a package and then modify it to fit your current
process. Many vendors now resist this for several reasons. First, customization
brings problems in keeping new versions of the software compatible with
various customized efforts. Second, vendors only make profits in overhead on
time and materials for customization. It is often more fruitful to devote these
resources to new releases and versions of the core software.

TRENDS IN SOFTWARE DEVELOPMENT

Traditionally, requirements were developed. After these were signed off, the
system was designed. After the design was approved, the system was built,
tested, and integrated—the traditional life cycle. How can this process be
different with modern technology? With the widespread use of Windows-type
software and Web browsers, user interfaces are more standard. Almost every
new system you implement must interface and integrate with other, existing
systems, further restricting what can be done. Some things, such as user reports,
are now obtained through files sent to spreadsheets. Development tools are more
modular, and there are software libraries.
So where is the creativity? What is the new process of development? Creativ-
ity lies in how you design the new business process through transactions with the
technology and process. Instead of performing the entire analysis, design, and
development, you pursue a parallel approach, where groups of transactions are
in various stages of development at any one time. This allows for reuse of the
design and code from earlier transactions.

CRITICAL SUCCESS FACTORS IN SYSTEMS AND TECHNOLOGY

Following is a list of some critical factors that you must consider in imple-
mentation:
• The benefits of systems and technology implementation lie for the most
part in the business process. The only benefits that lie in IT are cost savings
through technology replacement and efficiency. Because IT costs are small
in comparison with business costs and IT support costs for a business
process are small in comparison with that of the process, it is natural to
go to the process rather than IT for benefits.
• Given the cost and time of implementation, select the processes and
systems based on overwhelming benefits. If the tangible benefits are very
close to costs, then any rise in costs and extension of schedule will eat up
the benefits. The exception is when you are implementing a major upgrade
in technology infrastructure that will pave the way for major benefits in
several business units.
• The scope of implementation must include commitment by the business
units as well as the business process. If this is not done, then there will be
few guarantees that the benefits will occur because there will be little
pressure on business units to make changes. In some cases, middle-level
managers want to protect their territories and realms.
• Technology that is proven should be the technical base of the implementa-
tion. In addition, the importance of interfaces and integration can outweigh
the internal features of the software.
• Selection of software packages should be based on interfaces, fit with trans-
actions of the new business process, modularity as opposed to checklists of
features, and ability to customize the package. Ask the question, “Which
package fits the new process best?” Do not ask “Which package has the
most features?”

CHALLENGES FACING INFORMATION TECHNOLOGY AND MANAGEMENT

nformation technology (IT) faces a number of implementation challenges —
in part, generated by its success. Some challenges are addressed as follows:
•
How to deal with rising expectations of management for benefits
from technology.
Similar to the classic “child in a candy store,” once people realize benefits
from technology they want more. Listening to vendor marketing pitches
and advertising, it seems as simple as picking up the telephone. Obviously,
it is not. So what should you do? You will be including the change of the
business process within their expectations. You will find that this will shift
considerable management attention away from the technology and toward
the business process.
•
How to successfully involve business unit staff in implementation work.
Business people have to be motivated to become involved and stay involved
on their own. If you force them into implementation, it will not be effective.
Therefore, you will be provided with guidelines for getting and keeping
people involved in useful work.
•
How to implement new technology with changed processes on
a timely basis.
You can benefit from guidelines not only for what to do, but also for what
not to do. What are some of the steps that you could delete? As you will
see, this is a series of trade-offs. For example, how much and what docu-
mentation should be produced is a trade-off between benefit and effort. It is
similar for other activities.

TECHNOLOGY AND SOFTWARE TOOL TRENDS

People think of technology and its use as constantly improving and expand-
ing. However, this is not necessarily true. Much of new technology has to be
hyped as “products in search of problems to solve.” The electric light bulb was
that way in the 1800s. It took years to for Thomas Edison to convince people
that electric lights were a good idea. Do you realize today that almost one half of
the world’s population has never used an electric light? Getting technology
adopted is often more of a marketing problem than a technical problem.
Technology and, in particular, software have experienced positive trends that
relate to business and business processes. These include the following:
•
Improved price performance and reliability.
You have heard about this for
years. However the changes are now more integrated, occur faster, and have
a greater impact on society and individuals. Look at the sharp rise in tools
that use the Internet for voice communications and faxing.
•
Greater standardization.
With the earlier dominance of several hardware
firms and now with several software firms (one in particular), there is much
more standardization than was previously the case. What does standardiza-
tion mean? It means that you can more easily implement systems and have
less maintenance later.
•
Integration and easier interfaces.
This relates to standards in that the rise
of ODBC, OLE, and ActiveX have all supported simpler interfaces and
integration among systems. Without this there would be a need for much
more custom programming and development to establish and support inter-
faces.
•
Reduced learning curve for professionals to come up to speed.
Yes, current
tools require learning time. However, if you compare today’s tools with the
tools of the past (assembly language, APL, COBOL, etc.), you find that the
new tools are more modular and fully functional. People develop basic
skills and generate useful software more quickly, making them more pro-
ductive and providing a more nourishing environment.

BUSINESS PROCESSES AND TECHNOLOGY

Businesses depend on their critical business processes. A
business process
is
a set of interrelated activities that are performed to process specific work in the
business. Payroll, marketing, warehousing, and accounting are all business
processes. Organizations make or lose money depending on their processes.
This was recognized in ancient Rome where military and civil work was
systematically reduced to formal procedures. Business processes were created
and expanded throughout the Renaissance and during the Industrial Age, with
the railroads and modern logistics. Industrial engineering and “efficiency
experts” addressed steps in business processes in excruciating detail (e.g., hand
movements in performing work). From the 1950s to the 1970s, business
was preoccupied with expansion and other activities, and viewed computers
and technology as support to business processes. The clumsy technology
could in no way restructure the business process; it could only replace some
steps.
This changed with online systems in the 1980s. Transaction-based systems
changed the way people did their work. From administrative online systems to
automated teller machines (ATMs) to voice response systems, business
processes changed with the technology. The trend has continued with client-
server and intranet /Internet systems. Currently, most critical business processes
in a company are tightly connected to systems. In addition, it is hard to think of
systems that do not support business processes. Yet, where do things go wrong?
It is a matter of degree. If you spend money, time, and resources on critical
business processes, then you will be more successful. However, if resources are
drained to support minor maintenance and enhancement changes that have little
or no strategic impact, both money and time are wasted. The promise of technol-
ogy goes unmet.
Another major theme is that business processes such as technology evolve. As
time goes by, new situations arise. If the current process cannot handle them,
then people may create new, little business processes on the side. These are
called
shadow systems.
They may be procedures or PC systems that are not part
of the formal process. Shadow systems act to undermine the integrity of the
process. The situation worsens when there is turnover of business staff and the
new staff is not properly trained in the new process. New employees are told to
take their past experience and knowledge and just plunge in. And you wonder
why processes can deteriorate? A good combination of technology and process
reinforce each other and stave off, or at least delay, decay and rot.
Failure can occur if a firm adopts new technology too soon. An example is a
retail firm that adopted their own coding system for their merchandise, prior to
the development of bar coding. When bar coding became popular, the firm had
to use both the internal code and the bar code. The systems complexity over-
whelmed the business process, and inventory controls collapsed. Some stores
had excessive merchandise; others had severe shortages of the same goods.
However, if you adopt technology too late, you can lose in competition. Timing
is essential.

BUSINESS DIRECTION OF INFORMATION TECHNOLOGY

It is a cliche to say that business depends on technology more today than ever
before. Thus, we examine some aspects of the interdependence between the
business and systems and technology. In the early years of computer technology,
business received benefits by reducing the extent of clerical and support person-
nel required to perform routine tasks. Businesspeople often viewed technology at
this stage as a necessary, but largely unknown and mysterious, expense. With the
arrival of stand-alone PCs, the mystery disappeared, along with a lot of money.
The problem was that it was very difficult to justify the hardware and support
costs of stand-alone PCs for many employees. Data were reentered from
mainframe and minicomputer reports into PCs. People would show up at
meetings with contradictory data that they had entered. In one case, it was
recommended to a distribution firm that almost all stand-alone computers be
confiscated and warehoused. When this occurred, productivity immediately
improved and costs were reduced — a quick payoff achieved by reducing
technology.
The trend was reversed with the development of local and wide area network-
ing and, especially, with the Internet. Employees could perform online transac-
tions through client-server systems. Data were made available for analysis
through database management systems, and information could be shared among
staff. The Internet and the World Wide Web produced even more dramatic
change. First, widespread remote operations could be inexpensively linked with
headquarters units. Second, customers and suppliers could be integrated. The use
of electronic commerce and its predecessor, Electronic Data Interchange (EDI),
has increased dramatically.
What does this add up to? It translates into the realization of the dependence
of business on technology. It also raises the performance bar in terms of what
must be accomplished by systems and technology. The standards have been
raised. The system or technology not only must work, but also must mesh with
the business and produce concrete results. Firms are also more aware of disaster
stories and the problems with poor or faulty implementation. Two large discount
chains implemented the same technology over a period of years —satellite
communications with stores, point of sale (POS), scanning of bar coding, EDI,
shipping container marking, dynamic inventory, and so on. In both cases, the
systems worked. However, in one there was tremendous business success. In the
other, it was a disaster. Why the difference? Because the successful firm imple-
mented tight integration between the business processes and technology. The
processes were changed to take advantage of the technology. In the other firm,
the processes remained the same. The first firm made more money, had the exibility to expand faster and cheaper, managed inventory more tightly, and
could target specific market segments. The second firm received little benefit.
The lessons learned here are that technology implementation is too important to
be treated as a technical project and, to gain benefits processes and systems must
be integrated.