Beware—When SAP Projects Are Less Than Successful

Not all SAP implementations are roaring successes. In the following sections, I take a closer look at some “not best” practices, including in some cases what went wrong, and in other cases how the SAP project may have failed to meet the expectations of its stakeholders—end users, functional business-process-oriented organizations, and the folks controlling the financial purse strings. If you fall back on the scenario of the “car moving at 70 miles per hour,” it becomes evident here that there is truly a great deal of real risk that must be mitigated when tackling an SAP project.

“Not Best” Implementation Practices

Some of the “not best” practices my team has run into may be found in Figure 2.3 and are described in the following list. I suggest that you read these carefully and tuck them away for future reference under a big blinking neon banner titled “Lessons Already Learned by My FAILED Competitors”:

• Not willing to change current business processes. Usually, it is under the guise of keeping things simple so that the implementation goes well and goes quickly. In other cases, I found this to be the result of not having a strong executive order to make changes while simultaneously placing the wrong people on the project. Instead of staffing the project with decision makers, the business staffed the project with people who had merely requested that changes be made, often by superiors who found the current status quo comforting. In reality, though, not changing business processes actually represents one of the most common causes of failure for SAP development projects. And when it is coupled with a lack of current-process documentation, the problem is only exacerbated as the business works to figure out how things are done today, so that they can move the unutilized process to an SAP-enabled solution.

• Not learning from mistakes. Implementing SAP is an iterative process, in that implementing the various system landscapes and working on the various development and test clients offers an opportunity to improve upon even the limited IT processes already in place. A phased approach to implementing SAP (phased in the sense that Development is put in first, then Test, then perhaps Training, and so on) also lets you learn from your mistakes, so as not to run into the same issues as each new implementation wave begins.

• Ignoring sound change control practices. This one scares me the most, because it’s so common sense to put good change control processes into place, yet I see the results of not exercising good change control practices both before and after Go-Live. More mySAP Go-Live delays seem to result from this “not best” practice than any other reason, in fact, usually after something is changed in the system soon to become Production, without adequately testing the change first in another environment. Change control needs to be a mindset; without this mindset, it is only seen as an irritating pile of processes and paperwork, until an unplanned downtime event raises change control’s visibility again.

• Lack of sound project management. Although this may be considered a broad “do not do,” it’s actually common in a number of manifestations. To achieve sound project management, first, be sure to understand and document the desired state solution vision. Second, follow a proven SAP deployment methodology. Third, ensure that the objectives of the implementation are clear and managed to. And fourth, engage project managers with leadership, administration, and excellent people-management skills.

• Relying too heavily on third-party consultants. This is another no-brainer, but a very common dilemma. Having a whole lot of consultants on staff is not the problem (it’s the norm, actually). However, providing consultants with all of the opportunities or exposure to SAP at the expense of the company staff (who will be there long after the consultants leave) makes no sense at all. I also see a lot of projects where the third-party consulting staff hold too many key roles or positions. Again, the knowledge that these people acquire during the SAP deployment needs to be shared with the home team, not hoarded and carted away.

• Lack of documentation. Like reinventing the wheel, it’s expensive and ludicrous to have to learn over and over again how to do something properly. Documentation in regards to the SAP Solution Stack, and the installation, configuration, support, and operations of each layer of the stack, goes a long way toward improving productivity and increasing uptime. Yet a lack of solid documentation still rates as one of the top areas in which a company fails to measure up, ultimately putting the entire project at risk. This is the reason I provide so much in the way of documentation on the Planning CD—I want my readers to be able to take advantage of the many checklists and guides I have developed specifically for this book, or at least to use them as kick-start templates of sorts.

• Lack of buy-in. I have given the process of developing and securing buy-in quite a bit of attention in this chapter. Buy-in not only means gaining executive-level approval, but also the approval and a sense of ownership on the part of the folks who will ultimately use the system. This includes functional organizations and the end users themselves.

• Failing to test adequately. This is more common than most people think. Don’t misunderstand; the organizations guilty of this usually believe that they have done plenty of testing (and the hours spent in the name of “testing” often bear this out). However, what the numbers fail to reflect is that these failed or delayed projects skimped on either comprehensive integration testing, or end-to-end stress testing. This explains why each of these testing types merit their own chapters—integration testing is covered in Chapter 15, and stress testing is detailed in Chapter 16.

• Scope creep and “bolt-on” madness. Adding extra features, bells and whistles, and other nice-to-haves has pushed many projects beyond their originally published Go-Live dates. Not only does the add-on to the project lengthen time to implementation, configuration, and testing, it also impacts day-to-day operations as well as future support/maintenance needs.

The next sections illustrate a few true-to-life Go-Live disasters, to demonstrate how the problem areas I’ve listed have caused actual SAP implementations to fail or come close to failing.

Ignoring Change Control

This first SAP Go-Live near-miss has probably occurred a hundred times at a hundred different places. Tens of thousands of man-hours had gone into designing a robust SAP system landscape, preparing each system for its role in supporting Production, developing and customizing and testing, and so on. Everything seemed to be on track, and only minor issues had cropped up here and there over the last month or so.

Two weeks before Go-Live, the basis environment was frozen such that no changes would be made. Each server’s memory configuration had been specifically set up to take advantage of all 4GB of physical memory. Three gigabytes was to be used by SAP (through the use of Window 2000 Advanced Server’s /3GB parameter, which allows a process to access 3GB worth of memory address space). The remaining gigabyte of memory would be available to the Operating System and other processes. This configuration had been validated during stress testing.

The system had apparently been put into “lock down” too early, however, because it was clear that some major tasks still needed to be performed. For example, the technical team wanted to reload the entire OS, database, and SAP system from scratch to ensure one final time that their process for doing so was indeed repeatable. They also wanted to perform some final SAP tweaking, to further optimize a number of database and SAP-related buffers. After backing up the system to tape, the contents of each server’s disk drives were wiped clean, the OS was reinstalled, and the database and SAP installations were performed without a hitch. Late that evening, the system started up without incident, the senior SAP Basis analyst verified things looked good, and before sending the technical team home, started the master/golden client copy from development. The final memory-related tweaking would have to wait another day.

The next day, three days before Go-Live, the functional modules were locked down, and the system seemed ready for prime time. That night, however, an issue was discovered with the Production application servers after the memory buffer parameters were changed. It seemed that the SAP application server instances would die soon after being started. After careful analysis and troubleshooting, it was determined that the new memory parameters were not working because each server only registered 2GB of RAM, and the new parameters required more than this.

This was quite odd, though. In SAP stress-testing carried out a month beforehand, these servers had registered a full 4GB of RAM, the maximum supported by Windows 2000 Advanced Server. A quick look at the old profile parameters used in the stress testing also verified that the system had been set up to work with 3GB of RAM reserved for SAP memory-related settings. And a review of the old BOOT.INI settings confirmed that the /3GB switch was set, and things looked good. Somehow, something had changed though.

Another few minutes of poking around the system revealed the culprit. As it turned out, the (very!) junior SAP Basis analyst who asked to perform the OS reinstallation actually installed plain old Windows 2000 Server. Then he installed the database client, and the SAP application server instance as usual. The installation of the application server instance defaulted to a smaller amount of RAM than previously seen, but our unsuspecting junior team member failed to notice the discrepancy. He brought up the application server instance, which quickly connected to the message server, and walked away confident in his new-found resume-building experience.

In retrospect, several things went wrong:

• Even after the Basis system was locked down, changes were made to the system. What happened to change control?

• No checks were in place to catch the fact that a wrong component of the SAP Solution Stack was installed. A checklist or installation recipe indicating the proper OS to install, or the amount of physical RAM to be seen by Windows 2000 or the SAP R/3 application instance would have avoided this issue early on.

• No one verified the changes to the system in a timely manner. That is, a second pair of eyes was not brought in to review the changes until three days before Go-Live.

• Changes were made too close to the Go-Live date. There was simply too little time left for “what if” troubleshooting between the changes being made to the system, and the date the system was supposed to be turned over to the end-user community.

Bottom line, the end users serviced by this Production instance got lucky. Had the botched OS installation gone completely unnoticed, and the system de-tuned to take advantage of only half the RAM in each server, end-user response times would have suffered. It is likely that the business-driven agreement in regards to response-time SLAs (Service Level Agreements, covered later in this chapter) would have missed the target, too. The new system’s end users would have walked away at the end of the first day with a perception that the new system was slow.

Hiring an Inexperienced Implementation Partner

A recent SAP Business Information Warehouse (BW) implementation I helped to clean up after a less-than-impressive Go-Live seems to be a classic example of “you get what you pay for.” Here, a novice SAP BW consulting organization’s approach to implementation was the key to failure. But not all the blame could be pinned on this small implementation company. Consider the following points:

• The internal customer organization within the company implementing BW was not well-positioned to represent the needs of the entire company when it came to data warehousing. A successful implementation of BW requires close collaboration and agreement between and among all of the business areas involved, not to mention clear communication up, down, and across all of these organizations. An experienced BW consulting company would have known this.

• Although BW solutions address business requirements, they are still technology projects, too. Therefore, the implementation team requires a well-staffed technical subteam familiar with both SAP BW and the customer’s own unique enterprise environment. The customer thought they were covered, then, believing that their own internal IT organization would supplement the consulting partner’s business re-engineering and BW-trained folks.

• Implementing SAP BW benefits tremendously from a proven implementation methodology, like SAP’s ASAP (Accelerated SAP) or ValueSAP approaches. These methodologies, and the newer SAP Solution Manager-enabled implementation methodology, historically reduce the time needed to successfully deploy SAP by 10–50%, as compared to implementations performed without a methodology. In this case, no one thought to ask much about what the BW consulting organization actually knew of ASAP, unfortunately, nor whether they brought their own methodology to the table.

• SAP BW implementations are complex in terms of the number of players involved and in the various technologies and requisite skillsets therefore required. A closer look at the consulting organization’s “references” (we use the term loosely here) would have clearly removed them from contention. Two of the reference accounts were well-known names, but in reality our consulting organization under discussion had little to do with implementing the actual technology. And where they did have hands-on experience, the individuals who actually gained the experience had long since switched jobs.

This last bullet item is far and away the greatest problem faced by my customer. The other problems with the implementation and the incorrect assumptions on the part of my customer only exacerbated the bigger problem—the SAP BW consulting organization simply didn’t have the requisite experience.

To be fair, it should be noted that nearly 60% of firms surveyed in a recent Gartner study gave internal factors as the primary reason for failure—my customer in the preceding example is not alone by any means. What this meant in the end, though, was failure. They blindly followed their implementation partner into a minefield, without even knowing they were doing so. Key deadlines were pushed back several times due to technology issues (SAP BW extractor problems on a relatively new release of R/3, the need to provide reporting capabilities to remote users with slow network links, inability to uniformly stock cubes from which end users could run reports, and more). And even after a pile of budget money had been spent, the only thing the business could show for their efforts was a couple of inadequate cubes accessible only to local users in a single business unit. In hindsight, perhaps they should have characterized their efforts as an extended “pilot,” and moved on from there.

I came in after the fact, after Go-Live. Through a series of meetings and eventually a strategy workshop, followed up by gathering real requirements (again!), the new team helped turn the project around. It took actual experience with deploying SAP BW, knowledge and use of a proven implementation methodology, and a combination of careful listening/attention to detail to make this happen. Unfortunately, it also took a lot more time and money than the customer ever bargained for up front. After sharing this story with one of my colleagues, he remarked “This is the point at which somebody always says ‘why don’t we ever have time to do it right, when we always have time to do it over?’”

With examples of how not to approach an SAP deployment fresh in your minds now, let us turn our attention to the tasks awaiting a fresh deployment.