Consultants Versus Training Your Own Internal Resources
Two extremes exist in regards to staffing your SAP project. At one extreme, a horde of expensive money-hungry double-billing consultants may be brought in. You can find them quickly, and just as quickly start accruing enormous consulting fees. On the plus side, though, if they are managed and motivated properly (a really important “if”), a group of experienced consultants can take you through project preparation, planning, blueprinting, and implementation fairly quickly—many months perhaps, instead of more than a year.
On the other hand, pouring gobs of time and dropping maybe $20,000 in training on each of your high-potential, intelligent, and investment-worthy internal IT professionals can turn these folks into inexperienced though now certified and suddenly sought-after SAP professionals. This latter scenario is unfortunately even less appealing than the first, though. Why? Because you have practically no hope at all of actually achieving your solution vision, regardless of how much budget and time you’ve been granted. Certainly, a middle ground of sorts must be achieved.
Thus, it became business-as-usual many years ago to employ a staff of perhaps 4–9 consultants for every employee or long-term contract IT professional engaged on an SAP implementation. To put it into perspective, a mid-size company with 10 resources tasked with implementing and supporting SAP might also have another 40–90 consultants, depending upon the mySAP solutions or components being implemented, the complexity of the solution (like the need for the highest levels of availability, or the inclusion of a discrete disaster recovery system at a remote site), and the number of functional areas (like materials management, sales/distribution, financials, human resources, and so on) for which business processes must be defined and deployed.
In the next few sections, I will examine textbook reasons why both consultants and trained company employees make sense, and then delve into educational real-world examples.
Training Your Own Staff—Values and Headaches
Bottom line, when it comes to training your own staff of SAP professionals, what you lose in terms of time you gain in terms of employee satisfaction, increased loyalty, and long-term return on investment. Let’s look at the particulars, though, using the approach I used earlier when discussing organizational approaches in the real world—highs and lows.
Highs: Training your own staff (and doing your best to retain them!) serves to keep key technology and business knowledge inside the company. That is, consultants walk away after the implementation is over, but employees can be motivated and otherwise leveraged to provide maintenance and support changes to the SAP solution even after Go-Live. This practice directly impacts career progression, too, while simultaneously making the organization a better place to work. And as I said initially, the loyalty gained from investing in your people, and therefore the return on investment, becomes compelling indeed.
Lows: Training your own staff will not eliminate the need for consultants. And training does not provide the much-needed experience that truly makes an SAP IT professional valuable in his position on a project. Also, everyone needs to understand that training simply takes someone to a certain SAP release level, or level of functionality, or type of hardware platform, or version of a database, and so on. Training becomes a very expensive option if, in the middle of an implementation, a newer release or version of a particular SAP solution stack component becomes necessary. Think of it this way—if a consultant’s knowledge becomes obsolete, it may be pretty easy to replace him with a different consultant knowledgeable or experienced in the newer release. But this isn’t true with employees, where the employee then must be retooled, only to return to the project with a head full of knowledge but no practical application of that knowledge. This takes us to my final point. Resources that are trained but not experienced will typically take much longer to accomplish the same task than their experienced colleagues, often reworking the solution more than a few times until they get it right. If time is abundant, this could possibly be acceptable. But if, like most projects, timelines are pretty tight, the tradeoff in time versus cost may simply not make good business sense.
Hitting the Ground Running—Consultants Versus Your Budget
The training that your internal folks lack (and therefore their ability to meet stringent project deadlines) is more than made up for in general costs. A typical SAP Basis or infrastructure consultant will range from $60/hour for a junior self-employed contractor to maybe $125/hour for someone out of a fairly reputable SAP systems integrator, to over $300/hour for a senior enterprise architect from a Big 5 or “Enterprise” hardware or software SAP solutions partner. Figure that the least expensive resource is not capable of really meeting your needs, and even an inexpensive consultant will cost you $250,000 annually. And this does not begin to include the expenses typical of this kind of arrangement, which normally add another 10–15%, or $25,000–$38,000 annually in costs.
Highs: Using consultants will speed up your time to implementation, no question. But there is also a certain amount of flexibility that can be enjoyed in leveraging consulting resources, too. For example, niche technology areas can be staffed quickly via consultants and short-term contractors, allowing you to continue to meet deadlines even when priorities or business requirements change. Further, if you ever have a problem with a consultant—bad attitude, a history of showing up late, or a consultant incapable of actually doing the work, and so on—you have great recourse. Let him go! Fire him! And push hard to not even pay for his “time” that was wasted, or deliverables that were “under-delivered.”
Lows: Budget early, and budget accurately—as I have said before, assume that 65–80% of your overall costs will go toward funding your consulting staff alone. The costs are high, no doubt about it. But in the long run, thousands of companies have found that the costs of not implementing an integrated enterprise solution like mySAP are even greater. Can you really afford not to implement such a solution?
Compromising and Finding Organizational Balance
Compromising somewhere between staffing exclusively with consultants or exclusively with newly trained internal resources equates to how much you will benefit from keeping more of your SAP implementation knowledge inside the company, versus how quickly you will actually implement. That is, at a particular mix of consultants and internal staff, you will still maintain some level of control (via your own hand-picked staff) and at the same time leverage experienced experts in their fields (consultants).
Consultants Versus Internal Resources in the Real World
As we have seen, there are lots of reasons why it makes sense to use both consultants and internal resources on your SAP Project. But the real world provides infinite reasons why you need to achieve a certain balance between the two extremes, as I alluded to previously.
Bring on the Consultants!
I had one customer who started down the path to an SAP implementation two years ago. They brought in experts from one of the big consulting houses to cover most everything—project management, project coordination, blueprinting and design, functional consultants, ABAP programmers, SAP Basis, and other infrastructure consultants, and more. The customer named one of their senior managers as the Client Project Manager, but he still had other duties to oversee relating to the business, and could therefore be considered a part-time resource at best.
Within a year, this small company was averaging about $50,000 day in consulting fees and related costs. Annualized, this amounted to over $18 million, and did not even include budget money spent on hardware for development and test environments, and the SAP and database licenses themselves. For a project that never really got out of the blueprinting phase, they had literally spent a small fortune.
The project was way over budget and nowhere close to being on time. What happened? Changes in scope gradually crept into the project, unchecked by the customer and Client Project Manager. What started out as an R/3 implementation grew into parallel R/3, BW, and APO implementations. The business continued to feed requirements to the consulting team throughout the year. No one was truly in control, especially the client, and only the consulting firm was arguably coming out ahead.
In the end, the project was actually scrapped! Months later, SAP licenses and a pile of hardware in hand, I was asked to propose a new approach to implementing just the core R/3 component. No dice. Sadly, economic hard times and probably a deep-seated wariness towards SAP in general served to put this project “on hold” indefinitely.
Do It Yourself or Die Trying
Another customer of ours actually did successfully implement SAP R/3 with “barely” any consulting staff. In fact, the ratio of consultants to client staff was something like 2 to 1. The client took on 90% on the ABAP programming, all of the Basis and infrastructure, and most of the project management themselves. They brought in a second-tier consulting firm to help them for the first few months with general project planning and blueprinting, and leveraged free consulting resources from three different hardware and software vendors. Note that in all three cases, new and therefore not necessarily mature technology was introduced into the SAP solution stack—in exchange for providing references when presumably the project went live successfully, the client was granted consulting assistance gratis. It paid off for everyone quite handsomely, actually.
The project was not without its share of pain on the client side, however. The normal work week quickly grew to 60–80 hours (and then some), as the client painfully learned and relearned how to convert their business processes into ABAP and HTML code. New hardware, OS, and database platforms presented their own challenges, too, as the team scrambled to quickly learn and adapt their own operational and support processes to these.
Go-Live came and went without much more pain, and it came on schedule, which I believe amazed most everyone. Of course, the client’s team was exhausted from all of the hours put into the project. And they continued to struggle, suffering from “we don’t know what we don’t know.” Case in point, the production database quickly got out of hand, and then SAP tuning consumed all waking hours for nearly a month. All of this could have been avoided with carefully placed consultants tasked with providing good knowledge transfer before they hit the door on their way out. Nonetheless, the client struggled through all of this, and while it is debatable as to how much time they actually wasted, and what the state of the ABAP code is today, the end result was a live system. My team and I just hope they don’t have to upgrade for a long time!