User group takes virtual tack for conference
Throwback: When IA-64's Arrival Got a Pass

Replacement rides on software selection

APM stepsMB Foster's latest webinar on Applications Portfolio Management included an estimate that 80 percent of applications in a migration can be replaced. Migrating app code to a new platform is usually only a solution for 15 percent of the software in a 3000 environment, and an unlucky 5 percent of applications will have to be rebuilt.

So if 4 out of every 5 apps should be replaced, what steps make up the best practices for software selection? The webinar indentified nine.

  • Add a detailed current workflow to the software assessment.
  • Look at three to seven packages for each replacement
  • Compare the selections to the app, to make sure you have no orphaned functionality
  • Understand the business process re-engineering tasks. CEO Birket Foster said "If you're changing applications, there will be certain rules where there's a different way to do things, and people will have to be retrained."
  • Make all data clean and ready, moving department by department

Then there's a step to plan for surround code, which can sometimes be the trickiest to replace.

There may be interfaces plugged into your current applications, Foster said, "that feed data into or out of the application. You have to find those and see how they integrate into the big picture — because if you pull the application out of the middle, these are the loose wires. When you put the new application in, you have to re-integrate those wires."

After all of that work, there's a test plan, a go-live plan, and a plan for decommissioning the 3000. 

"You have to have a plan if the computer is a system of record," Foster said. "Systems of record tend to require specific care and treatment when you're decommissioning them."

The webinar also listed a set of common mistakes during a replacement project. 

  • Not gathering enough information from each department
  • Going straight to the software demo stage "without actually building a scorecard," Foster said. "It's hard to do a comparison of 3-7 packages without an objective scorecard. People from each different workflow should participate, to help the weighting of different scorecard items." 
  • Not having a broad enough Request For Information process; this can reduce the need for details in a subsequent Request For Proposal.
  • Not appointing a software selection liaison — a person high up enough in the organization to bring all the company's stakeholders together
  • Skipping the appointment of conference room pilots, individuals who explain how workflows operate during a boardroom-level meeting. "If you skip those, nobody has an idea of what they're about to see, and so they don't ask all the questions they should," Foster said. "It's not all about price. A lot of the questions have to do with functionality."