Summary

We have covered quite a bit of material in this chapter, much of which will be explained in further detail throughout the remainder of the book. I started off with tactical and strategic reasons for implementing SAP in the first place, wrapping up the first few sections with real-world stories of success and failure. Then we looked at the tasks and activities that tend to keep the Steering Committee and Project Sponsor busy in the first few weeks after the decision is made to implement SAP. This included high-level critical tasks like promoting buy-in, nailing down the real business requirements to be satisfied by SAP, determining realistic SLAs, an exercise in estimating ROI early in the project, translating business requirements into technology drivers, nailing down something of an initial budget, and more.

Then I spent some time analyzing the SAP Solution Stack, discussed the workings of an SAP system landscape, and covered basic tenets of solution sizing, all of which need to be understood at some point to take us to the next level. A discussion on change control, the emerging role of the SAP TSO, and assembling the high-level project plan wrapped up this chapter.

In the next chapter, we will build upon what we discussed here and address the “SAP Solution Vision,” where the general technical requirements are fleshed out to reflect actual necessary SAP components and products, including factors that influence the design of your SAP system landscape. And I will devote quite a bit of time analyzing outsourcing as an alternative to hosting your SAP solution in-house.