The decision to implement a software
package change in your business can
be an exhaustive process. When the contract is signed and the selected software provider starts working, the internal
team is often worn out and ready to say,
“Well, we’re done. Time for the package
people to take over.”
In some ways, the work is just beginning.
“What a new software package really represents is an organizational change initiative, not just a software package selection
process,” says Bill Russell, executive vice
president, Allegient.
Smart Business recently spoke with
Russell about preparing your company for
a new software implementation.
How can a company determine if it’s ready to
implement a new software package?
There should be a change readiness
framework or package readiness framework. This should include an organizational change management plan or a total project life cycle plan. The initial readiness factors to check include, for example,
whether or not there is an executive sponsor, a project manager, and the formation
of a steering committee or sponsor committee that is made up of the key stake-holders. Typically, in today’s businesses,
the new package won’t stand alone. It
affects other business processes and
departments that are related to it, and it
may even have to interface with them.
Finally, it’s extremely important that the
company fully understands its current
business processes that the package will
impact.
How can a business determine if software
customization is necessary?
If, by definition, the new software is the
future state, then it must be gap analyzed
against the current state. Building a classic
business process modeling description, in
graphical format with text definitions of
business functions, is essential. It allows
the company to understand the key inputs
and outputs of each of its key process
steps. Comparing these results to the package’s standard business processes exposes the pieces that don’t match the way the
company operates.
At this point the steering committee must
make a business decision about whether to
accept the way the package works, or if
customization is required. Incidentally, if
you wait until this point for the package
people to do the analysis, they’re going to
say, “Well, you need to define your current
state, we can do this for $175 per hour.”
You’re better off preparing for that gap
analysis and discussion before they come
in the door.
Is it better to conform or customize?
The axiom for a software package project is, “Do as little customization as possible.” They should be implemented vanilla
or right out of the box. In the end, it comes
down to the needs of the business versus
the cost of the software change or the total
cost of ownership. Every time you make a
change to the package you are moving
away from its standard implementation to
more and more of a one-off. There are
times when the needs of a business outweigh that, and you may choose to customize, but it should be minimized. You’re
better off changing the business process to
reflect what the package does, rather than customizing the package. Keep in mind
that if the software provider puts a new
release out next year and you want to
implement that new release, you’ve got to
change all of those customizations in order
to make the new release work.
How can companies get the most bang for
their software buck?
First, it should be viewed as an organizational change initiative, not a software
package implementation. A key part of the
initiative is training your people in the new
ways the process operates. Second, companies should execute a readiness framework because it’s more than just choosing
the best package. Third, as much prep
work as possible should be accomplished
before the selected package provider
comes in the door. Finally, do not underestimate the interfaces. If the package must
work in conjunction with others, that integration effort isn’t insignificant. The project plan should include an integration layer
substratum.
What is involved with testing a package
implementation?
Testing should be accomplished from
three fundamental needs. People got used
to putting in these packages with the mind-set that they have already been tested, so
they don’t need to test it. That’s a bad, bad,
bad approach. You have to test at the functional, or user, level to determine if the
package delivers the business value as
promised. The package also should get
tested for end-to-end functionality, particularly if it has to integrate with other
processes/systems. The third primary
focus of testing is for performance, i.e. for
response time, reliability, availability and
scalability. Many companies are negligent
in testing packages in the performance
area.
BILL RUSSELL is executive vice president of Allegient in
Indianapolis. Reach him at (317) 564-5701 or
[email protected].