Davenport had a range of problems to solve for the Beverly Hills, Calif., provider of hair restoration services. These included the need to reduce maintenance costs, gain disaster recovery capabilities and centralize data for consistent business intelligence reporting.
The project began in the early 2000s and is still ongoing, as IT reviews the portfolio of applications running on servers as part of a move to virtualization and more energy-efficient boxes. But already the company has reached significant milestones, such as ending $20,000-a-year maintenance contracts and replacing core internal systems with applications obtained via Software as a Service (SaaS).
"IT has to be the steward of the applications," Davenport said. "We can't maintain everything forever; we have to move forward eventually. But you need to give the business viable alternatives as you move forward."
Here are some of Davenport's best practices for application consolidation and the decision criteria his organization used in the process:
1. Make time for planning up front. At Bosley, of the eight months from project conception to retiring of old systems, three to four months were spent in the planning stage. Bosley also engaged a project manager from the SaaS vendors. "The vendors have the project management experience and should drive each piece of the project and bring their piece together with the other vendors,'" he said.
2. Compare the cost of supporting each system with its business value. At Bosley, if the business value was not sufficient to justify system support -- and some systems cost $20,000 per year to maintain -- the system was axed.
One exercise that can help stakeholders assess an application's business value is a cost-and-performance diagram. The diagram lets you analyze the cost of the underlying modules or functions of an application against the performance of the group using that function or application. At an insurance company, for example, an application can be broken down into policies, claims, inspections and so on.
Participants then highlight the performance of the functions in red (as in a red flag), yellow and green to show users within a given group the costs of maintaining that application function.
"If a group is fighting you [on the project] and they have a red line all the way across their performance [and the performance of the application function], you can say, 'Well, your application [function] is a cost center, so you need to bring some money in, or other groups that are making money need to shift some money around if you want to continue to support that application, or if you want a new system," said Phil Murphy, an analyst at Forrester Research Inc.3. Look for low-hanging fruit, but don't rely on logs alone to determine whether you can shut software off. Talk to all the business departments to see if anyone still uses an application. "Invariably, you find out that someone needs it, so you need to have a plan for how to maintain at least the piece of functionality that person needs before moving forward," Davenport said. "Once a system is shut down, information could be lost and you will find yourself scrambling." 4. Similarly, make sure that the business understands what the application consolidation plan involves: which systems stay and go, what information is in those systems, and what data will and will not be transferred to a new system or remain accessible in a data warehouse.
As part of its consolidation effort, Bosley decommissioned an old customer contact system, but Davenport still sometimes gets requests to tap into the system's data. "Some systems never seem to die, but when this one does break we will not fix it," he said. "It will officially be retired."
5. Figure out the financial side: who gets the funds from applications that are decommissioned, and who pays for new ones that replace them. Gartner Inc. proposes that each consolidation activity define the sources of savings and exactly whose budget is positively affected by those savings.
Ditto for any costs associated with application consolidation, Murphy said. "If IT fails to put the project in a context that the business understands, and IT fails to do this time and again, the business users push back because they're hearing about an infrastructure improvement and saying, 'Why should I fund it?'" Murphy said.
Bosley's IT team built adapters from the SaaS vendors' data center to its own data center to integrate and aggregate information from the various SaaS applications into a central Siebel CRM system.
This information is then replicated in the company's SQL Server 2008 database that has a homegrown reporting system built on top. Davenport is looking to replace the homegrown business intelligence reporting system with SQL Server Reporting Services in the future.
"The [licensing and maintenance fee] path we were on was very expensive," he said. "We are now always working on the latest version of everything [as far as applications], paying for it on a subscription basis, and we no longer have to maintain the applications or the hardware."
With data gathered in a data warehouse repository from the central Siebel system, Bosley has also gained consistency across areas such as scheduling. Previously, customers were sometimes double booked.
What can not be measured in dollars is the business uptime the company is now able to achieve. "In the last two years we had power outages here all the time that disrupted inbound and outbound dialing," Davenport said. "With those systems now in the cloud, we can still take calls by logging on from anywhere we are."
Let us know what you think about the story; email: Christina Torode, Senior News Writer