Roadmaps to SAP Implementation
Written from parallel business, technical, and project management perspectives, SAP Implementation Unleashed provides you with a high-level roadmap in conjunction with the necessary level of detail across multiple disciplines to set you up for SAP implementation success. We've accomplished this by bringing together matters of business, technology, and project management in one book. We outline these roadmaps in the following sections.
Let's face it, the reason an organization introduces SAP has nothing to do with a love for cool technology or global projects. SAP implementations are about satisfying the business's need for business functionality by deploying a business application. For this reason, it's imperative that the business weighs in on the implementation up front as well as throughout the project. Up front, the business must ensure that its needs are being heard and understood by executive management and translated into an appropriate business vision.
After a valid business vision is established and agreed upon, it's time for business software experts to marry the firm's business vision with an application (or suite of applications) capable of actually delivering on the vision. For example, if you have a vision of real-time collaboration and visibility into your product lifecycle (your business vision), application architects and other experts should be able to translate that vision into specific SAP applications and components (or applications and components from Oracle, Microsoft, and a host of midlevel and niche players in the business applications market).
Beyond the initial business vision development and alignment, it remains paramount to an SAP implementation's success that this vision be validated and tweaked as the implementation progresses. Why? Because we don't live in a world where things stand still for the year or two it takes to introduce a complex business application. The marketplace will change, after all, as will the firm's financial, market, and other positions. Strategic vendors and suppliers may change. The firm's appetite for business transformation may change, too; for example, the firm might change its strategic direction or be acquired by another firm with a different view of the future. In all of this, it is therefore important to validate that the implementation's progress lines up with the initial vision plus or minus any changes made down the road. Just as critical, the intersection of the firm's business requirements and strategic technology architecture deserves attention, the latter of which is outlined next.
Just as business requirements need to be not only understood up front but validated and tracked as they change, so too do a firm's strategic technology architecture decisions. Why? Because technology enables firms to conduct business. And just like the business, technology changes over time (as does a firm's appetite for and ability to digest new technologies). Therefore, deploying SAP business applications is impossible without a proper understanding of and commitment to the system's underlying technologies and infrastructure. The combination of these technologies is called by some the SAP computing platform, SAP solution stack, or simply the SAP technology stack. Others refer to this collection of technologies by an old SAP term, SAP Basis. Regardless, all of these terms refer to the technology foundation as well as the actual SAP technical installation upon which all development activity and productive operations rely (and for our purposes here, these terms should be treated as interchangeable).
To be sure, many of the challenges related to how an SAP implementation is perceived after go-live fall back to the technologies that have been deployed and how well they've been brought together to provide a well-performing, highly available and agile business system. Integrating all the technologies necessary to pull off a successful implementation is a major achievement. These technologies come together to create an implementation-unique SAP technology stack; the stack is essentially the various "layers" of infrastructure and technology that sit one atop the other in support of an SAP solution, like the different tiers or levels in a three-layer cake. Of course, the SAP "cake" is much higher than simply three layers, and includes the following:
- Physical facilities, such as a computer room or other data center hosting site
- Power, cooling, and other utility-based core service layers
- Physical hardware mounting and racking layer
- Server and disk subsystem hardware layer
- Firmware layers associated with specific hardware
- Operating system (OS) layer
- OS drivers, service packs, updates, patches/fixes
- Database layer
- Database drivers, service packs, updates, patches/fixes
- SAP application layer, which in and of itself consists of multiple layers
- Internet-enabling layer
- SAP accessibility layer, including desktops, laptops, and other devices used to access an SAP solution
Each of these layers can be further broken down into more detailed layers. For example, server hardware covers the individual servers supporting an SAP solution. Drilling down deeper, we find specific memory, CPU, I/O, and other server hardware subsystems or layers, too.
Furthermore, multiple solution stacks typically exist in any given solution. For example, an SAP ERP solution hosted in a data center might consist of IBM Regatta servers running the AIX operating system underneath an Oracle 11g relational database, which in turn hosts an SAP NetWeaver BW business application. In the various front offices, the system's end-user community might rely primarily on a laptop-based technology stack composed of an HP Pavilion running Microsoft Windows Vista, Internet Explorer 7, and the SAPGUI version 7.1. Some of the offices might leverage a Citrix-based solution for SAP access and thus depend on a specific Citrix XenApp technology stack to gain access to the same SAP NetWeaver BW system. Obviously we are interested here in SAP's technology solution stack, but you can apply this same approach to any technology or solution. That is, Microsoft Exchange Server 2007 has its own unique solution stack, as does an Oracle CRM solution or a custom mainframe-based billing application. The enterprise solution differs, and the technology stack will certainly differ, but the approach to building a supported and well-performing solution remains constant.
As you might guess, technology stacks not only are all around you, but are as numerous as they are complex. Perhaps the greatest challenge and greatest achievement is assembling a particular technology stack that both is supported by all the various technology vendors involved in the solution and operates well. Assembling such a supported configuration is by no means trivial! This is one of the reasons why so much time is put into vendor and overall technologies selection—minimizing the number of technology players while bringing together a supportable and well-performing end-to-end solution is the ultimate goal. For these reasons, developing and managing a sensible business-enabling technology roadmap plays a central role throughout this book.
Project Management Roadmap
The project management roadmap serves to wrap up the business and technology roadmaps necessary to implement SAP. It's the glue that cements everything together in a cohesive, manageable manner. Project management enables process discipline, schedule management, and resource management to be effectively applied to an SAP implementation. Together, all three of these roadmaps pave the way to a successful implementation. But it is the project management processes inherent to the roadmap that give the project shape, make it manageable, and therefore make a successful implementation achievable. As such, the project management roadmap is without a doubt the central or most important roadmap—nothing good is possible without it.