UNIFIL: My thoughts on Go-Live

On July 1, 2013 Umoja went live; a bust of euphoria and happiness all over; I was observing that silently and wondering the whole process. I've been in similar situations; at least a dozen SAP implementations of similar nature (global rollouts) and this one seems to be a bit different. The go-live seems to be perceived that it went too well than it was in reality. I as cautious and at the same time trying to write down the key success factors for such perception.

First, the must need for any huge re-engineering projects, the UNIFIL top management had a great involvement and took a great deal of interest in transforming the commitment to every member of the team.

Second, the IT infrastructure was well built, managed and had a robust support infrastructure and knowledgable staff. Even though the support structure was not there for the SAP implementation; the commitment of the IT team in building the iNeed infrastructure, created the perception of the continued support structure and made the users confident and comfortable

Third, the training that the deployment team gave to the local process experts and end users to get familiarized with the live system.

This can be articulated as a base for the support system in three phases before, during and after SAP implementation. My take on the success of SAP project is not only how well we design and build the solution, but on the support structure we architecture and deploy!      

Ensuring the long-term success of your SAP implementation requires careful planning, preparation and support. From the moment we decided to integrate SAP into our business to long after your new business management software system goes live, having a team of experts (like me!!), is the key to sustaining success and getting back to business as usual.         

One of the biggest mistakes most organizations make when it comes to SAP support is to expect a standard distribution curve with just one spike when you first go live or put a significant piece of new functionality live (like Umoja Extension . They assume they can simply manage those increased support requirements and then stabilize from there. That assumption usually results in the removal of post-go-live SAP support at the exact moment when it is most essential.

The reality is every SAP implementation consists of TWO support requirement spikes and, without fail, the second is nearly always bigger than the first.

The reason is simple: at the moment your new platform goes live staff members are performing with a safety net of extended support coverage in place. They are following a script, learning the interface and starting to gain confidence. In effect, they are moving through the first stages of the learning process:

1.    Unconscious Incompetence -- They don’t know what they don’t know. At this stage of the learning process, your employees may not even recognize the benefits of your new SAP platform. They are a blank slate ready and waiting for input.

2.   Conscious Incompetence -- This is the stage at which users begin to understand exactly how much they don’t understand about Umoja and how that knowledge will benefit them in their roles. Mistakes here are common and, ultimately, helpful in furthering the learning experience.

As go-live Umoja support scales down and users start to gain more confidence in their ability to navigate the new system successfully, they move from the second, to the third and ultimately fourth stage of the learning process. This usually results in the second spike in SAP support requirements because your employees are moving away from the script and they have the confidence to explore capabilities and ask more complex questions.

3.   Conscious Competence -- By now, users have started to form a solid understanding of how SAP works with and for our business. They have begun to form the skills they need to take full advantage of the new features and functions at their disposal.

4.   Unconscious Competence -- At this point, the necessary skills have been developed to the point where they are becoming second nature.

While every SAP implementation is different and requires specialized support strategies, recognizing these phases exist allows you to better prepare and budget for them.

When reducing the Umoja support coverage, it is also critical we make it event-driven rather than time-driven. For instance, some business processes only happen once a month, so you need at least 60 days before you can accurately predict user behavior and overall system stability.

We should not make the mistake of eliminating or scaling back your support resources just because implementation is complete. In fact, in order to ensure complete Go-Live Satisfaction, it’s a good idea to increase the availability of those resources post-implementation.

My next section of this blog is how core IT staff can support SAP applications...expect soon