The Art of Structuring SAP Implementation Team for Success
By Steven Zerby, CIO&VP, Owens Corning
A lot has been written about SAP implementations over the years. It is disappointing that it does not always seem that a lot has been learned.
However, leading information services at a company that adopted SAP almost 20 years ago-it does feel like we have learned a great deal.
SAP implementation is really a two- headed animal. On one hand, getting the system ready for deployment is an arduous task: planning, discipline, risk mitigation, and lots of engineering. On the other hand, getting “people ready” for a deployment is an art: change management, training, practice, building awareness, support, patience, and more patience.
Through dozens of large SAP deployments, I have seen Success and mistakes. The two biggest mistakes I see organizations make in implementations are:
1) Not having a strong internal IT team savvy in SAP–you cannot outsource your way to success.
2) Not resourcing your team with talent that can manage the people aspect and the system-build aspect of the implementation as two connected, yet unique, streams of work.
"Matching the talent to the task seems like quite a simple concept, and so does separating the two distinct pieces of an implementation"
In terms of unique streams of work, our learning has led us to what is still a unique SAP team model. Essentially, we have decided that the concept of a single implementation leader for such a broad continuum of activities is tremendously unlikely to succeed consistently. Our model has evolved to a select few leaders, accountable for distinct aspects of an implementation, governed by an executive steering team significantly raises the chance of winning. Quite often, we employ a “build lead”, a “deployment lead” and a “business lead”—all reporting to the steering team.
We declare a build lead that becomes the “overlord” of all aspects of the system build. This person is a SAP functional- savvy veteran, who can be authoritative, take decisions, drive engineering, and understand where business functional risk in a system build really manifests itself. A great build lead has a firm hand and demanding tone in all that they do.
We also anoint a “deployment lead” that manages the entirety of getting people (recipients of the implementation) ready. This is someone who understands change management in the human capital sense, builds training scenarios, user-validation testing, communication, practice, and go-live support plans, and oversees the execution of each. The deployment lead starts their work on the same day the build lead starts their work. No more getting the people ready after the build has lagged its schedule, and no more having those involved in the build miss their schedule by worrying about training scenarios, user validation testing, support processes, etc. A great deployment lead has a knack for listening, hearing real concerns, identifying users that are going to need extra time to learn, and is a great teacher.
The “business lead” is the most traditional role. Someone with the respect of the business to be implemented, with a small team of key process experts that can engage and lead the various decision- making processes inside an implementation. Quick and powerful, that is the business lead.
Matching the talent to the task seems like quite a simple concept, and so does separating the two distinct pieces of an implementation-build versus deploy-yet many learn the hard way.
Here is to no more learning the hard way.