Role of IT team in UMOJA implementation

SAP is an application that took both business and IT world by surprise during late 90s and early 2000’s. The time was too short for these silos in an organization to own this and manage it. However the big six auditing firms quickly recognize the importance of this application and the impact that this was going to make during the Y2K issue was threading big corporations; forcing them to look for a sustainable alternative. They branded the IT solution a reengineering agent and started selling it to the CIOs and CFOs. Even though this happened decades ago, the mystery still remains, especially when it comes to the SAP implementation project. One factor that needs to be considered in this context is that SAP is an application similar to Microsoft office, but needs to be configured and enhanced to I fit to run your business better. There exists responsibility on all parts of the organization to carry it through equally and unequivocally.

In a typical situation, the business and IT usually end up having this conversation & mindset.

BUSINESS to IT: “I want this, this and this from our SAP systems. Go away and make it happen then tell me when it’s live. PS -- I’m not available to spec it out … I’m too busy to test … oh and it’s not coming out of my budget. And I need it tomorrow.”

IT to BUSINESS: “Sounds great, but you must have me confused for a mind reader. Am I supposed to have a crystal ball that magically predicts your needs and anticipates every issue before the solution goes live? Seriously, I just need to know where to start. My team and I are too busy to troubleshoot this entire project from scratch, only to find out you wanted something different. If you want me to take responsibility for its success, you need to give me the process requirements and insights we need to succeed.”

Does this sound familiar? While the dialogue above has been exaggerated slightly for dramatic effect, the basic scenario it describes is consistently played out at countless companies struggling to establish ownership and best practices for their SAP systems and including our own UN!

The problem here is there’s no clearly defined ownership. But what’s the solution? In order to get there, let’s take a look at the backstory. How’d we get to this point in the first place? We need to understand the perception and the actions following that

Many businesspeople make the mistake of considering SAP applications strictly as an IT domain, consisting of various programming tasks. (When those tasks aren’t automatically completed without their oversight, they think of IT as an obstacle to SAP success.)

IT people, on the other hand, don’t understand why the business departments won’t give them the information they need to make the organization’s SAP systems function efficiently and effectively. They see the businesspeople as the obstacle to SAP success.

The Solution:

The truth is somewhere in between. When it comes to optimizing our SAP systems, ownership should come from the top down. This means the DMS and the business experts should drive the entire implementation and optimization process through clear and comprehensive communication of all business requirements and parameters. When the business side of the organization owns the data and transactions, it has a vested and actively maintained interest in how the system processes fulfill their business requirements, including: master data, applications, transactions and reporting.

Where is IT’s role then? IT should be an enabler for the processes above. While ownership of the overall SAP systems belongs to the businesspeople, IT should be responsible for the infrastructure and architecture of the system. This means taking the requirements and data supplied by the business side and translating them into functional solutions that fulfill the company’s needs. IT also holds a great value addition to the process by keeping the application on the cusp of the technology curve and makes it adoptable to any new technological adoptions

One of the biggest mistakes most businesses make when it comes to their SAP systems is to treat them like a function of the IT department. It’s a fact: you can’t spell “profit” without IT. Of course, when implementing any IT business solution, you incur the overhead and business costs of supporting and maintaining your new system. And in practice I’ve seen the technical staff understand and adopt to business functions more comfortably than the other way.

When it comes to SAP implementation and optimization, you need to assess the costs of maintaining and supporting your new IT solution in terms of what it means for your business.

As a general rule, it helps to remember SAP (and IT in general) should be a function of your business, not the other way around. Only then will you realize the full value of your SAP system. The better the SAP implementation and optimization processes are at supporting and enhancing your business, the more value and ROI you reap.

 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