Implementing tools and software rollouts to improve business and IT processes is a risky move, both financially and organizationally. Such implementations, when not considered with diligence and meticulous care, frequently end up providing the opposite of what management initially expects.
Case in point is the recent IT implementation problem that caused Philippine fast food chain juggernaut Jollibee, McDonalds’ top competitor and with thriving branches in the USA and other countries, to halt operations in 72 stores in Metro Manila. This botched IT upgrade, a supposed 0.5-billion peso (around $11.37 million) project, resulted to lost sales of 6% for just the seven days of August, which, in Jollibee’s 2013 revenue terms, is equal to roughly 92 million pesos.
In a 2013 report by the Wall Street Journal, Avon Products Inc. suffered the near-same fate when it launched a massive software program slated to take years in total rollout and acceptance time. The results were disappointing, to say the least, when the difficulty in learning to operate the system caused a significant number of employees to leave the company. This failed SAP implementation by Avon, as per Ben Kepes in a Forbes.com article, caused Avon to write down somewhere between $100 million and $125 million on its balance sheet.
To help avoid such dire consequences, here’s a list of key considerations when evaluating the potential ROI (return on investment) of software implementation:
- Clear project objectives
- User interface
- Employee buy-in
- Effective introduction, training, deployment, and pre- and after-installation support
- Proper planning
- Cost
Defining the scope and objectives of your project and business operations is the first preemptive step against the failure of a software rollout. Carefully study, discuss, and lay out the blueprint, like how complete and functionally broad you need the solution to be.
In a reply to the Avon software implementation debacle, an SAP media representative was quoted to have said that “its software was working as designed, despite any issues with the implementation of the project.”
The discrepancy between software design and actual usage is a costly problem. The IT vendor’s creation might work “as designed” but, upon rollout, may not have the desired effect on users’ take-up rates.
Making use of UI engineers or a software specifically tailored for each business department, with simpler yet more architecturally flexible design, may help turn the situation around. Also, there’s starting small, initially in one or two departments, and then slowly expanding to cover other business operations when implementation success becomes imminent.
Management may have all the best intentions when buying and trying to implement a new software, but not considering their employees, who will be the product’s major users, can be a crucial mistake.
In an article for CFMA (Construction Financial Management Association), Fred J. Ode, founder and chairman/CEO of Foundation Software, explains why users are the key to software implementation success. Including users in discussions regarding why a new software is needed, soliciting user input as to what features will be needed, as well as involving them in the software selection process, are essential and can eliminate the adverse consequences instigated by employees who feel blindsided by management actions, and hence, resistant to implementation.
As enumerated in a write-up in Faye Business Systems Group’s blog, insufficient training and support rank high among the top 10 reasons why software implementations fail.
In choosing the right software, barriers to implementation such as installation, maintenance and upgrades should be evaluated, as well as the pre- and post-installation training and support provided by the IT vendor. Implementation of the appropriate training format, such as employing trainers and support personnel for remote users and for those reporting in-house, for example, should be a key consideration.
Rob Prinzo of CIO.com lists setting realistic timeframes among his six best practices for ensuring software implementation success. Managers should take heed, as one surefire way to discourage users is to add considerable adoption time on top of their actual operating hours.
Management should budget the minimum time required for users to install, train and learn to use the product, as too much time away from actual operations isn’t a good business proposition. The projected deployment schedule should be realistic and flexible, considering also the employee learning and resistance-to-acceptance curve, and not just heavily based on management expectations.
The rhetoric of ROI may be good, but having an actual formula is the more important step in evaluating the ROI performance of a software implementation. A California-based IT solutions company, for example, Ayehu Software Technologies, shares the basic formula used to measure actual ROI resulting from task automation.
You can calculate your yearly savings (X) by measuring the amount of time spent per month on a manual task (a), the frequency per month with which this task is performed (b), the cost per hour (c), and then multiplying all these by 12 months.
In algebraic terms, you get a * b * c * 12 = X.
In Ayehu’s example, automating 18 monthly hours (4.5 weekly hours) of server maintenance at an average cost of $75 per hour and computing how much it would cost in 12 months led to a product of $16,200 in projected savings. Now, if you carefully analyze the number of repetitive tasks you can automate, these savings could rack up significantly. Having a real formula that is relevant to your business will give you a solid calculated projection of what ROI to realistically expect.
Whether as part of the IT landscape harmonization or complying with top management’s mandate to increase process efficiency, internal IT deployment of a new piece of software should be well-thought-out and planned before making it the default application. As aptly put by the same Forbes article referenced above: “Enterprise IT systems are supposed to make organizations more efficient, not drag them down into a quagmire of process and inefficiency. And they certainly shouldn’t result in a large exodus of workers from the organizations implementing them.”
