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@example.com.