Ariba Deployment: What Happens after Go-Live?
There are a couple of important phases immediately after your SAP Ariba solution is deployed that are critical to its long-term success. The first is Hypercare, which starts on Day One of Go-Live and has critical and immediate support elements. The second is the Adoption and Stabilization phase, which, although not as immediately crucial, holds the key to long-term user adoption.
Crucial Post-Deployment Phases
In the first two blogs in our series on Post-Deployment Success, we talked about why your SAP Ariba solution can fail post-deployment during the time frame we call the Adoption and Stabilization phase. That’s the period that occurs after Hypercare. Hypercare begins as soon as your product goes live.
The early days after Go-Live and those two post-deployment phases are crucially important in the long-term success of your SAP Ariba solution. Here’s a deeper dive into what to expect during that post-Go-Live period.
What is Hypercare?
Hypercare is the immediate post-deployment phase that starts on Day One of your SAP Ariba Go-Live. Go-Live is always on a Monday and, typically, you’ll still have consultants from your deployment consulting partner on site from two to eight weeks after that to manage any kind of a critical issue that would affect your production system.
When we say “critical” we mean problems that can stop production or block the user from doing required tasks. These can’t be set aside; they must be dealt with immediately.
However, during Hypercare other, less critical issues can occur as well. These are typically issues that users encounter when they start using the system. It may be procedures that don’t work properly so they must figure out a work-around, or things they’d like to see added to make for a better user experience.
Because Hypercare focuses on immediate needs, these other, necessary – but not crucial – changes tend to be put into a backlog to deal with at some undefined point in the future. The problem is that if that “undefined” point is never defined, those issues will pile up until users become frustrated and stop using the system. In extreme cases, the backlog can become so significant that it will require a completely new deployment. And although not every single requirement can be met, there is a lot of continuous improvement that can be managed post-deployment to encourage and retain user adoption.
Addressing these necessary, but not immediately critical changes, is the point of having an Adoption and Stabilization Phase.
Adoption versus Stabilization
While Adoption and Stabilization are considered one phase, they’re also two separate issues. Upfront, there will be a lot of ADMINISTRATIVE support needed as users begin to use the system and need password resets and are simply in the initial training mode. That’s adoption.
Stabilization comes as users start to get used to the system understand how it works. That’s when they start asking questions and looking for improvements that are more process-improvement oriented. That’s where SUPPORT comes in, to deal with the backlogs created during Hypercare and make the system more user-friendly so you don’t get users getting frustrated by work-around and lack of improvements, so they stop using it.
The fact is that many companies don’t require their employees to use Ariba, they merely put it out there and say you SHOULD use Ariba, not you MUST use Ariba. In general, 75 to 90 percent of potential users will try it out, but if their requirements are not being properly supported, or they find the system confusing and cumbersome and they can’t get the right administrative support up front, that can drop significantly.
The Importance of Change Management
A lot of the issues we’ve discusses so far could have been mitigated completely with a change management strategy in place from the very beginning. Unfortunately, this is an area that’s often ignored during deployment because companies don’t realize how critical it is to success. If you don’t, it can cause a lot of problems with overall user adoption overall and can significantly increase the length of the Adoption and Stabilization phase.
Here are some common, but avoidable, problems we see when we come in to help “fix” an Ariba solution that’s not working:
- Potential users never heard the word “Ariba” until Day One of deployment.
- Some discussions were had around Ariba, but no training was offered.
- Because potential users were not included in the design, when they did start using it there were critical items are missing that hindered user adoption.
- There was a lot of “noise” around initial stabilization efforts because the users did not know the system, what they were supposed to do with it and what the expected outcomes were, so it seemed as if there were more problems than actually existed.
A lack of exposure and a natural resistance to new systems almost always results in pushback and poor user adoption. And, again, even if they eagerly adopt it and are willing to give it a go, if they can’t give hands on feedback until the Hypercare phase, there will be a lot more tasks added to the backlog. That can hinder user adoption because of the critical items that were potentially needed by the stakeholders were not included in the design.
In blog two of this series, Six Ways to Avoid SAP Ariba Post-Deployment Failures, we talked about how companies could avoid these problems by having the right administrative and support people in place from the very beginning.
If you don’t have the proper people in-house, finding an SAP Ariba consulting partner that offers ongoing support in the form of managed services can mean the different between success and failure. At CCP Global, our Ariba Managed Support (AMS) staff are experts in dealing with users and supporting both early adoption and long-term stabilization.
Need Post-Deployment Help?
We’re the experts.
