/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsERP or other substantially sized IT projects can be spooky. If the word ‘spooky' has spooked you a bit, wait till you hear what some industry experts pick out.
We won't be talking about the sheer investment of resources and money that goes into big projects. We are not going to mention their big ticket upkeep fees either. Yet, there's so much around that can ‘creep' out an apparently normal ERP project.
A survey by Panorama Consulting, a Denver-area company that provides ERP implementation and software selection services, found how 61 per cent of respondents reported over-scheduling of with only 28 per cent finishing on time.
The pattern has not changed much. A Panorama's 2010 survey pointed to the same gravity showing that ERP implementations take longer and cost than expected. Not only that, many ERP implementations under-deliver business value.
The pattern may haunt but ironically the scariest part is the revelation that as per this study is about users and not vendors. Not many found the actual ERP software so culpable, as per the recent survey data. It seems that just four percent of respondents cited "vendor functionality issues" as a reason for project delays, and technical issues were pointed by 14 per cent only.
What takes the blame then? Scope creep as blamed for slowdowns by 29 per cent of survey respondents? Or "Organizational issues" that came next with 20 per cent, followed by "data issues" and "resource constraints" with 17 per cent apiece?
The Panorama's survey found that nearly a third of respondents are still waiting to leverage any financial rewards from their projects. Some 30 per cent cited a minimum pay back period of three years for any realizations.
Notably, Dynamics came on the top for overall implementation times, averaging 13 months to SAP's 17 months and Oracle's 18 months, according to the survey.
On an average, SAP and Dynamics projects ran on average two months past schedule. Same way, Oracle implementations averaged four-month overruns, as per the survey.
2012 is not a surprise year. The irony may seem huge but even experts suggest that there are too many skeletons in internal closets to be confronted to leave time for chasing external reasons.
While both contribute to letting a big fat ERP wedding go awry, there's a lot that can be handled internally.
In short - Watch your step.
1. Pull up your socks, tighten your processes
One of the few strongly scary things for Eric Kimberling, managing partner, Panorama Consulting is the issue of internal processes.
Citing how Knight Capital recently lost a sum as huge as over $400 million because of glitches in its trading software, Kimberling advises to fully simulate and test your business processes prior to go-live.
Separating what looks good on paper versus the real operational kinks is very critical.
Make tweaks to the business processes, ensure process and training documentations is complete and accurate, and ensure that the business processes will actually work in a real-life operational settings, he stresses.
As he writes in his blog, "When you factor in other implementation risks, such as unaccounted for assets due to the inability to accurately track data, lost customer orders because of botched inventory planning, and/or revenue shortfalls due to shipping problems, the damage caused by ERP failures increases dramatically."
The elephant and the blind men scenario keep resurfacing. Even though your tech team thinks that the enterprise system is in good order, do not let your business process go out of kilter.
2. Time and CEOs wait for no one
Surveys indicate an average time of "16 months" for most ERP implementations. The Panorama study shows that 40 per cent were on schedule but per cent had a time creep.
Before jumping to the sacred area of rigid adherence to time boundaries, consider a Dr. Dobb's Report from 2007 where Scott W. Ambler conducted a survey and which threw up surprising pockets. Some 61.3 per cent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time. Being strictly on schedule vs. being really ready has a lot of difference.
While cost and time over-runs are not hard to shrug off, apparently internal teams, specially developers and IT managers might incline to the approach of being completely equipped to deliver. A time spillover is not that serious in that context, for the executing teams.
In an ASUG forum, David Hannone beautifully analogized ERP creeps and potholes.
"ERP implementations often get delayed. It will happen. That fact in itself is not very useful to those implementing ERP systems, other than to serve as a vague warning. Knowing why they get delayed is more useful to ERP project teams because they can be avoided."
This brings us to the next important bump.
3. Scope it out before you plate it up
Panorama Consulting report attributed 29 per cent of ERP implementation delays to scope changes. Usually the scope expands too much. And interestingly, when one glances over nine more reasons for delays, the top five are organizational issues, data issues, resource constraints and training issues. Again, internal reasons.
It's either about being greedy or being confused. Being vague in a good sense helps, but one needs to have a reasonable level of clarity on how much to expect and assign while deploying a new system. Romes can not be built in a few days, even in this era.
The burden of this clarity lies on senior managers and project owners but a very important piece in this cycle is the part of user expectations.
As Shrikant Kulkarni, CIO, KPIT Cummins reckons rightly, user readiness is a big parameter to take care of. The customer should also have a clear idea of the suite being deployed. Both these factors can make a lot of difference in ensuring lesser creeps.
Let's not also forget the revelation that Dr. Dobb's report threw up.
Remember that 87.3 per cent said that meeting the actual needs of stakeholders is more important than building the system to specification.
4. Control and Premises
The verdict is still awaited on this issue but one can not ignore an interesting layer in the survey findings. On average, SaaS and hosted solutions were found to be implemented in less time (11.6 months for SaaS vs. 18.4 months for on-premise). Not only that, this happened at a considerably lower cost (6.2 per cent vs. 6.9 per cent of annual revenue), plus with a level of executive satisfaction (52.6 per cent vs. 50.0 per cent) than traditional on-premise solutions.
Yet, according to the Panorama report: "SaaS implementations are significantly less likely to deliver the expected business benefits (23.5 per cent vs. 42.9 per cent) than on-premise solutions, and SaaS implementations are significantly more likely to exceed budget than on-premise initiatives (70.6 per cent vs. 59 per cent for other delivery options)."
What can this paradox be translated into? May be your partners and vendors matter a lot where interfaces and control issues come up.
Let's see this in light of the next area.
5. No Cut Copy Paste here
As Kimberling has rightly opined, one of the most common misperceptions in the ERP industry relates to the role of "as-is" and "to-be" business processes in implementation. In order to downplay the risk, cost and effort associated with their products, ERP vendors and their system integrators will commonly sell their prospective customers on the misguided notion that their solution has best practices baked into their software, thus minimizing the need to define business processes.
Isn't it nice to hear when he highlights this? "However, most ERP software is so flexible that even the simplest business processes can be defined in a multitude of ways using basic configuration."
The ball is again in your court. It is all about picking a letting a software consultant work like a wedding planner, with a lot of bells and whistles but may be at the cost of real insight.
Or put your own house in order first with well-defined business processes before the implementation talk begins at all.
A lot of cost can be mitigated and many risks of ERP implementations avoided if one segregates roles well. Let the technical consultants focus on what they're good at, as Kimberling suggests.
Business process and requirements etc can not be completely thrown away out of internal radius.
6. DIY but Do it Smart
As much contradictory as it may sound to what we accentuated earlier, it's the same thing turned upside down. Like an IT anagram. There are some internal strengths and nuances that can not, and should not be, forked away. But answering this question frankly matters. "Can you really handle a big implementation without any help?
Outside expertise can be handy. It brings in many complementary pieces like the suite's knowledge, BPM (business process management) parts or, organizational change management and complex program management.
7. The matching pair of shoes
Hardware support or all the other accessories that go along with a massive software upgrade are usually not visible upfront. They have to be ruthlessly dug out of the fine print or blindfolds during the initial stages only.
It can be a massive infrastructure requirement or a data-related need of new boxes or new storage or interface points. If one knows everything before hand, even at a rough level, surprises do not give expensive heart attacks. They can be accordingly tackled with the vendor and SLAs. This is important as 79.6 per cent can still feel that providing the best return on investment (ROI) is more important than delivering a system under budget, as per Dr. Dobb's report. Also, when 87.3 per cent opine that delivering high quality is more important than delivering on time and on budget.
"Technical issues" are at number six on the Panoroma list though.
8. Don't turn, we are changing
Change management is the most hammered and beaten-down word in any project discussion.
But the brutal truth is that it is still not tackled as it should be.
Strong organizational risk mitigation and change management were some major issues cited in the survey. "Project planning, resource deployment, segmented communications, targeted training, strong data conversion plans, and so forth serve to minimize the negative effects of change, decrease the durations and increase the success of implementations." It pointed well. Some 63 per cent of surveyed companies "experienced difficulty in addressing process and organizational change issues"
9. Customise smartly
The best lines noted in the report are probably these: "Companies are doing themselves a great disservice if they believe that software selection is the ‘hard part' and that all the functions and capabilities of the software will instantly be realized if they just choose the right one."
The study showed how 41 per cent of respondents changed business processes to accommodate ERP functionality, whereas 27 per cent changed or customized ERP functionality to accommodate current business processes.
The cost of customization though needs to be assesses deeply, and for the long run. It can have implications on SLAs, indirect access violations and to a lot of extent on the support and upgrade cycles.
Testing and pilots can play a great role in ensuring that the customer knows what comes along with a bespoke model.
10. Learn from your mistakes
Or from those of others. Share as much as you can. What goes around, comes around. Like we said - Don't be afraid.
While both contribute to letting a big fat ERP wedding go awry, there's a lot that can be handled internally.
In short - Watch your step.
One of the few strongly scary things for Eric Kimberling, managing partner, Panorama Consulting is the issue of internal processes.
Citing how Knight Capital recently lost a sum as huge as over $400 million because of glitches in its trading software, Kimberling advises to fully simulate and test your business processes prior to go-live.
Separating what looks good on paper versus the real operational kinks is very critical.
Make tweaks to the business processes, ensure process and training documentations is complete and accurate, and ensure that the business processes will actually work in a real-life operational settings, he stresses.
As he writes in his blog, "When you factor in other implementation risks, such as unaccounted for assets due to the inability to accurately track data, lost customer orders because of botched inventory planning, and/or revenue shortfalls due to shipping problems, the damage caused by ERP failures increases dramatically."
The elephant and the blind men scenario keep resurfacing. Even though your tech team thinks that the enterprise system is in good order, do not let your business process go out of kilter.
Surveys indicate an average time of "16 months" for most ERP implementations. The Panorama study shows that 40 per cent were on schedule but per cent had a time creep.
Before jumping to the sacred area of rigid adherence to time boundaries, consider a Dr. Dobb's Report from 2007 where Scott W. Ambler conducted a survey and which threw up surprising pockets. Some 61.3 per cent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time. Being strictly on schedule vs. being really ready has a lot of difference.
While cost and time over-runs are not hard to shrug off, apparently internal teams, specially developers and IT managers might incline to the approach of being completely equipped to deliver. A time spillover is not that serious in that context, for the executing teams.
In an ASUG forum, David Hannone beautifully analogized ERP creeps and potholes.
"ERP implementations often get delayed. It will happen. That fact in itself is not very useful to those implementing ERP systems, other than to serve as a vague warning. Knowing why they get delayed is more useful to ERP project teams because they can be avoided."
This brings us to the next important bump.
Scope it out. Very well
Panorama Consulting report attributed 29 per cent of ERP implementation delays to scope changes. Usually the scope expands too much. And interestingly, when one glances over nine more reasons for delays, the top five are organizational issues, data issues, resource constraints and training issues. Again, internal reasons.
It's either about being greedy or being confused. Being vague in a good sense helps, but one needs to have a reasonable level of clarity on how much to expect and assign while deploying a new system. Romes can not be built in a few days, even in this era.
The burden of this clarity lies on senior managers and project owners but a very important piece in this cycle is the part of user expectations.
As Shrikant Kulkarni, CIO, KPIT Cummins reckons rightly, user readiness is a big parameter to take care of. The customer should also have a clear idea of the suite being deployed. Both these factors can make a lot of difference in ensuring lesser creeps.
Let's not also forget the revelation that Dr. Dobb's report threw up. Remember that 87.3 per cent said that meeting the actual needs of stakeholders is more important than building the system to specification.
The verdict is still awaited on this issue but one can not ignore an interesting layer in the survey findings. On average, SaaS and hosted solutions were found to be implemented in less time (11.6 months for SaaS vs. 18.4 months for on-premise). Not only that, this happened at a considerably lower cost (6.2 per cent vs. 6.9 per cent of annual revenue), plus with a level of executive satisfaction (52.6 per cent vs. 50.0 per cent) than traditional on-premise solutions.
Yet, according to the Panorama report: "SaaS implementations are significantly less likely to deliver the expected business benefits (23.5 per cent vs. 42.9 per cent) than on-premise solutions, and SaaS implementations are significantly more likely to exceed budget than on-premise initiatives (70.6 per cent vs. 59 per cent for other delivery options)."
What can this paradox be translated into? May be your partners and vendors matter a lot where interfaces and control issues come up.
Let's see this in light of the next area.
No Cut Copy Paste here
As Kimberling has rightly opined, one of the most common misperceptions in the ERP industry relates to the role of "as-is" and "to-be" business processes in implementation. In order to downplay the risk, cost and effort associated with their products, ERP vendors and their system integrators will commonly sell their prospective customers on the misguided notion that their solution has best practices baked into their software, thus minimizing the need to define business processes.
Isn't it nice to hear when he highlights this? "However, most ERP software is so flexible that even the simplest business processes can be defined in a multitude of ways using basic configuration."
The ball is again in your court. It is all about picking a letting a software consultant work like a wedding planner, with a lot of bells and whistles but may be at the cost of real insight.
Or put your own house in order first with well-defined business processes before the implementation talk begins at all.
A lot of cost can be mitigated and many risks of ERP implementations avoided if one segregates roles well. Let the technical consultants focus on what they're good at, as Kimberling suggests.
Business process and requirements etc can not be completely thrown away out of internal radius.
As much contradictory as it may sound to what we accentuated earlier, it's the same thing turned upside down. Like an IT anagram. There are some internal strengths and nuances that can not, and should not be, forked away. But answering this question frankly matters. "Can you really handle a big implementation without any help?
Outside expertise can be handy. It brings in many complementary pieces like the suite's knowledge, BPM (business process management) parts or, organizational change management and complex program management.
Do not underestimate or over-splurge on matching earrings
Hardware support or all the other accessories that go along with a massive software upgrade are usually not visible upfront. They have to be ruthlessly dug out of the fine print or blindfolds during the initial stages only.
It can be a massive infrastructure requirement or a data-related need of new boxes or new storage or interface points. If one knows everything before hand, even at a rough level, surprises do not give expensive heart attacks.
They can be accordingly tackled with the vendor and SLAs. This is important as 79.6 per cent can still feel that providing the best return on investment (ROI) is more important than delivering a system under budget, as per Dr. Dobb's report. Also, when 87.3 per cent opine that delivering high quality is more important than delivering on time and on budget.
"Technical issues" are at number six on the Panoroma list though.
Change management is the most hammered and beaten-down word in any project discussion.
But the brutal truth is that it is still not tackled as it should be. Strong organizational risk mitigation and change management were some major issues cited in the survey.
"Project planning, resource deployment, segmented communications, targeted training, strong data conversion plans, and so forth serve to minimize the negative effects of change, decrease the durations and increase the success of implementations." It pointed well. Some 63 per cent of surveyed companies "experienced difficulty in addressing process and organizational change issues"
Customise smartly
The best lines noted in the report are probably these: "Companies are doing themselves a great disservice if they believe that software selection is the ‘hard part' and that all the functions and capabilities of the software will instantly be realized if they just choose the right one."
The study showed how 41 per cent of respondents changed business processes to accommodate ERP functionality, whereas 27 per cent changed or customized ERP functionality to accommodate current business processes.
The cost of customization though needs to be assesses deeply, and for the long run. It can have implications on SLAs, indirect access violations and to a lot of extent on the support and upgrade cycles.
Testing and pilots can play a great role in ensuring that the customer knows what comes along with a bespoke model.
Or from those of others. Share as much as you can. What goes around, comes around. Don't be afraid.