A Cautionary Tale About SAP Knowledge Transfer

I spent the first few years of my SAP career on SAP training and documentation. During this time, I covered most of the major SAP modules [FN1], which was an invaluable experience for me. That time in front of a classroom doing SAP courses helped me gain an understanding of the user perspective, the client perspective, and how to facilitate effective requirements gathering sessions.

Many SAP trainers do not have the luxury of specializing in a single module. Usually, you learn the transactional processing of whatever module you end up being responsible for on each project. As a result, many SAP trainers with a few years and a few project experiences have a fair process understanding of the application. When trainers complete knowledge transfer correctly, the team can achieve amazing results.

Experienced SAP Consultants and Knowledge Transfer

Genuinely seasoned consultants recognize that the time they have spent “in the trenches” cannot be replaced by one project’s knowledge transfer. Therefore, they can encourage your understanding without feeling threatened. Many talented consultants thrive in an environment where they are challenged, learning, and solving problems. Because of this, transferring knowledge is second nature to a skilled and experienced consultant.

Most often, truly skilled consultants with practical business and work backgrounds can speak to issues in plain, understandable terms. They have been through the go-lives. They have done the production support for the user community. They have had to work through the complex or thorny processing issues. They have seen where things were done right (and not so well). They have gained a solid process understanding. Ultimately, they do not have to rely on “fast-talking techie speak” to keep you confused and in the dark. After all, if they are not clear on what they are saying, how can the project team and user community understand them?

With this need for an experienced consultant in mind, one of the most important things a company can require of their software vendor is knowledge transfer. Done correctly, knowledge transfer leads to operational independence. Done poorly, or not at all, knowledge transfer leads to perpetual vendor dependence. Worse still, the long-term organizational change and acceptance of the new system, new processes, and new way of doing business is much slower and more painful with poor knowledge transfer. In some of the worst cases, the implementation may experience resistance and eventual failure.

More on SAP Knowledge Transfer and Process Communication Skills

Most consultants come to a project with resumes that claim years of full life-cycle project experience, especially in the following:

• leading requirements gathering sessions,
• developing blueprint documents,
• producing option assessment whitepapers,
• logging and troubleshooting complex issues with users,
• performing actual knowledge transfer,
• training client-side core team members,
• and conducting post-go-live support.

Many consulting companies deliver generalists to install SAP or other ERP applications. These generalists do not have the critical application and process knowledge to ensure that your company will gain critical operational independence. If the consultants you are paying are also learning on your dime, how you are ever going to acquire the knowledge transfer your organization needs?

SAP Knowledge Transfer Requires Good Communication Skills

How can a consultant fulfill any communication-intensive project requirements without strong native language skills? Any language barrier is a red flag that you may not receive the critical knowledge transfer you need for operational independence. If the consultant cannot properly complete a knowledge transfer, they may not have the level of experience required for quality results.

I have seen the results of projects where the vendor team could not effectively transfer knowledge. On the flip side, I have worked with projects that experienced a successful knowledge transfer. While a successful or failed transfer can occur for many reasons, a vendor or consultants who will likely cause transfer problems will not, or cannot, share their knowledge and move the dependent organization toward independence.

Some indications that a vendor or consultant may lack the ability or desire to successfully transfer knowledge include the following:

• Fast-talking “jabber” that sounds sophisticated but is difficult to truly understand.
• Jargon rather than plain language terms that will help the uninitiated understand (frequently this indicates a lack of experience because the individual has only been exposed to the technical material they have reviewed or are learning online).
• Lots of consultant-only meetings where client counterparts are not invited to participate (some of these, like weekly team lead meetings for consultants only may be necessary. However, excessive use of these is a red flag).
• Layers of bureaucracy for active or extended implementation team members to get answers from the “keepers of the knowledge” (again, some of this is necessary as a practical measure from the extended user community).
• Frequent failure to communicate changes in direction, or new requirements.
• Constant refrains such as “You don’t need to worry about that now” or “We’re not there yet” or “Don’t worry, we’ve got that covered.” Or worse still, “Why do you need that?” If you are receiving these responses without adequate explanations, you should consider this a danger sign.
• Or, the all time classic “I’m (or we’re) too busy to worry about that now.” While many projects are busy, vendors and consultants cannot neglect knowledge transfer.

Effective SAP Knowledge Transfer Requires the Ability to Make the Complex Seem Simple

Most importantly, those in charge of knowledge transfer need to make the complex, simple. Anyone can take the complex and keep it that way– or even make it more complex. However, those with real talent can help you understand what you need to know for success. They can often communicate in terms you will understand. When completely new and foreign concepts are introduced, quality vendors and consultants will have worked through it enough internally to present understandable explanations. Oftentimes, fast-talking consultants who sound brilliant but are hard to understand are the fakes.

These fakes are more common than many clients realize, and more damaging to your implementation than you can imagine. Even many vendors are duped and hire these consultants, who prevent you from gaining knowledge or meaningfully reviewing their work so they can hide behind their own lack of knowledge or experience. When they prevent meaningful review or criticism of the consulting work you are billed for, you may not truly know their level of competence and skill.

Knowledge Transfer Exceptions

In some projects, the client company (not the vendor) does not provide enough resources for the project, or will not commit enough of their core team member time. If this occurs, knowledge transfer becomes difficult. To achieve operational independence, a company must commit their resources to learning the system, and learning it well.

Trying to have core client team members do an SAP project while maintaining some additional responsibilities of their other job only hurts you (the client) in the long term. The reason is that once you go live, things will change. SAP will be your new system, and the old ways of doing business will not all be supported. As a result, the more knowledgeable and capable your core team is, the better and more productive your business will be.

Operational Independence Is the Key Success Criteria or Measure of SAP or ERP Knowledge Transfer

To avoid this problem, your vendor contract might include a provision where you commit to the number of resources and time (client staffing levels), while the vendor needs to reach a point of operational independence within a certain number of months after go-live.

Define operational independence as the client resource’s ability to troubleshoot and resolve transaction problems within the scope (or list) of implemented transactions. Also, the terms of your agreement might spell out that as of a certain date, the vendor agrees to support all client resources at “y” discounted rate (say 50% or less of the project rate) until you achieve operational independence. See how your vendor reacts to this. If they raise concerns, and want some contract language changed or modified to more fairly spread the responsibility, that is fine. But if they are resistant to such an arrangement without a clearly compelling reason, you may want to reconsider whether they are the right fit for your project.

Combat this throughout the project by building some of these knowledge transfer expectations into other parts or phases of the project. For example, by the time the project begins integration testing, the client resources should be able to configure or resolve “x” or “y” as part of the knowledge transfer.

How you resolve this is up to you, but let me assure you that knowledge transfer is a key component of every good SAP project. If your project is lacking in the knowledge transfer even though you have provided sufficient resources, you may want to take a long, hard look at your vendor and consultants. You may be headed for more problems and expenses than you know.

==========================

[FN1] I had trained classes on various parts of PP (Production Planning), SD (Sales and Distribution), MM (Materials Management), WM (Warehouse Management), and FI (AR, AP, GL, and Asset Management).