1. Implementation Methodologies for SAP Installations
I will begin by identifying
various implementation methodologies and how each relates to SAP
component or technology layer installations. I will then walk through
installing common underlying or integration products, such as SAP’s Web
Application Server and Internet Transaction Server, and then move into
detailed mySAP.com installations.
SAP’s first real implementation methodology was ASAP, or Accelerated SAP,
launched in 1997. The tools and methods introduced were primarily
template-based, but were a big improvement over the “one-off” approaches
leveraged for implementations until that time. In terms of actual
product installation support, however, ASAP was pretty weak; its
accelerators focused almost exclusively on functional configuration and
other tasks associated with what SAP AG termed Realization.
Only in one of the work packages associated with ASAP’s Blueprinting
phase was installation briefly mentioned. During this time, customers
turned to SAP technology partners and tools outside of ASAP (like SAP’s
SAPNET resource) to fill in the holes in the “installation gap.” SAP
technology partners in particular spent much of their time creating
custom technology stack checklists and recipes, leveraging SAP’s R/3
product documentation as a basic starting point.
ValueSAP and the Global ASAP Roadmap
With
the advent of SAP Basis release 4.6C in 2000, Global ASAP was
introduced under the ValueSAP framework, which was divided into the
three core phases of an SAP product’s life cycle. The middle phase, Implementation, was front-ended by Discovery and Evaluation and backed up by ongoing Operations and Continuous Improvement.
It was here in the Implementation phase that more attention was given
to SAP installation processes. ValueSAP’s tagline of “reducing time to
benefit” fit well with the still-new mySAP.com initiative, too, as more
and more global implementations sought to leverage best practices and
installation approaches to speed up implementations.
With regard to implementation support, the Implementation Assistant and Roadmap, backed up by a Q&A database and the SAP IMG, served as the primary tools for enabling faster mySAP solution installations.
Note
The IMG is a tool for configuring your system;
for each business area, IMG walks you through all the steps in the
implementation process. In doing so, it communicates the SAP “standard”
or factory settings, and describes system configuration activities. The
hierarchical structure of the IMG makes it valuable, as it reflects the
structure of each mySAP application component.
Included in these tools were SAP’s published
best practices and approaches to implementation, and something called
the “SAP Reference Model,” which identified processes and roles that
supported the delivery of mySAP solutions. Global ASAP was still largely
template-based when it came to installation methodologies, though,
updated and enabled to support global SAP implementations (compared to
the original ASAP methodology and its smaller scope). Still, attention
to the following issues helped to speed up the pre-installation tasks
necessary before actual SAP product installations could commence:
Implementation strategy
Global system topology
Organizational change management
Global business process standardization
Development of Global Elements, such as documentation templates, standard IMG structures and settings, master data formats and documents, and so on
Proper attention to these issues allowed systems
to be rolled in more of a “cookie cutter” fashion, based on global
reusable templates. By doing so, consistent implementation standards and
lower related costs were realized, and the overall quality of the
implementation increased.
Additional
new or improved tools were also introduced during this time frame, and
also helped to save time in installation and post-installation
processes. For example, the much-improved Transport Management System
(TMS) replaced the less-capable Change and Transport system, and SAP’s
Computer Aided Test Tool finally facilitated load testing as well as
functional testing. Site preparation got more attention, too, especially
with regard to providing training to the teams tasked with designing
and installing the mySAP system. Building a standard site-specific
training curriculum was promoted, and the idea of developing repeatable
local implementation processes finally took hold at the SAP Basis level.
Comprehensive installation and master implementation guides were
developed. All of this attention to speeding up an implementation and
therefore rapidly achieving ROI set the stage for the next wave of
implementation support to take hold of SAP—the SAP Solution Manager.
SAP Solution Manager for Implementation
According to SAP AG, by the end of June 2003,
ValueSAP/ASAP training will no longer be available. With the ability to
order ValueSAP CD-based content already a thing of the past, and SAP
Solution Manager (SSM) training related to implementation ramping up
throughout the first half of 2003, the writing on the wall is clear—SSM
will be the key service and support
enabler going forward (along with SAP Service Marketplace). SAP Solution
Manager is touted as both the implementation and operations platform
for mySAP solutions. The former is the topic of discussion here.
In terms of implementation, it is the technical implementation aspects
that we are actually most interested in; functional and
operations-enabling aspects are extremely valuable but do us little good
when it comes to the actual installation of mySAP.com components. Key
benefits of using SAP Solution Manager for Implementation include
SSM acts as a central point of access
and support for key implementation activities, and finally (!) includes
an “Enhanced Solution Management Roadmap” targeting the Technical
Implementation Team (SAP TSO, and its various technical consultants).
SSM
provides a process-driven approach to blueprinting, technical
configuration, and testing. Combined with standard implementation
scenarios, this streamlines everything from sizing through installation.
SSM
includes built-in project monitoring and reporting capabilities, and a
central repository for storing project documentation and issues.
SSM also identifies services and processes aligned to ensure both an uneventful Go-Live and excellent ongoing operations.
One way that SSM for Implementation delivers is through Ramp-Up Knowledge Transfer (RKT). With RKT, initial competence in delivering a mySAP solution is provided through Web-based and CD-based content. For instance, Solution Manager Learning Maps can be downloaded from http://service.sap.com/rkt-solman.
And a formal SAP-sponsored training class, SMI310, is available as
well, covering SSM’s implementation tools in detail. Another class,
TSML10, even addresses Solution Manager infrastructure and installation.
Other resources offered by the SAP Solution Manager for Implementation
are directly accessible from SSM:
The Enhanced Solution Management Roadmap and other Roadmaps describe how to organize and run your mySAP implementation project.
A
Business Process Repository outlines and describes your specific
mySAP.com solution (this is part of the built-in monitoring and
reporting capabilities).
Integrated
Business Content is available, offering scenario-based access to generic
technical descriptions and collaborative Business Maps.
Access and integrated use of customizing tools, along with best practices for implementing mySAP.com components, is available.
Both version 2.2 and 3.1 of SSM sit
atop Web AS 6.20. Support for RKT and Implementation was introduced in
SSM version 2.2 (the previous version 2.1 only supported Operations),
but with release 3.1 of SSM, Implementation and Operations are finally
wrapped up in one Web AS-enabled product. Given this, I look at SAP
Solution Manager now as just another core product that must be
maintained throughout a customer’s mySAP system landscape—a
“development/testing” environment is recommended (for testing
updates/enhancements and upgrades), along with a “production” system to
be used by the SAP TSO to actually support implementation and operations
processes. In terms of hardware needed to support this basic two-system
landscape, though, requirements are minimal. SAP recommends a
dual-processor server with 1GB of RAM and 50GB of disk space at minimum,
and in my limited experience, this seems more than adequate.
2. Rounding Out Your SAP System Landscape
We concluded our SAP Data Center activities by installing the Technical
Sandbox and Development systems. Actual database and mySAP component
installation details were not covered, though . Instead, the assumption was that we would finish
installing the rest of the SAP system landscape as dictated by
milestones outlined in the SIPP, our master project plan, spread
throughout the remainder of the project.
In my experience, a number of training systems or
instances are often installed fairly quickly after Development is
installed. These include the developer’s training system, and perhaps an
SAP Knowledge Warehouse or similar instance. Next, a month or two later
the Test/QA system is often installed, followed by another system or
instance earmarked
for end-user training. Finally, a Staging system and/or the final
production system(s) are installed after another few months. If a
staging system is put in place, it usually precedes production by a
couple of months; stress testing often takes place on the staging system
in this case (rather than production), the results of which tend to
change the production configuration. That is, after the stress testing
is concluded, the production system’s design is fine-tuned accordingly,
and the system is finally ordered from the hardware partner.
Speeding Up Your OS Installation Process
Installing each successive SAP system within the
system landscape takes time. Because of the repetitive nature of the
installation process, a cookie-cutter approach to installation makes
sense, as do tools and utilities that help speed up the process.
Scripted OS installations using Microsoft’s Setup Manager Wizard (setupmgr.exe,
found on the W2K Server CD under the Support folder) are popular for
Windows-based servers, as are disk imaging products such as Symantec’s
Norton Ghost and PowerQuest’s DriveImage. To connect your server to an
Installation Server containing your OS installation folder or image
files, though, you’ll need a bootable floppy or CD with the requisite
network, memory, disk management, and other drivers. These are easily
created, but can be time-consuming in and of themselves, which is
contrary to the mission at hand. So to speed up this process, I
recommend Bart’s Boot Disk Web site, accessible at http://www.nu2.nu.
Preparing for an SAP/Database Installation
After the hardware and operating system are
installed, the real fun begins, for now we can finally begin preparing
for an actual mySAP installation. Novices take note: an SAP installation
includes (and is very much tied to) a database load. Thus, when I speak
of installing a mySAP component, I am also including the database
layer. SAP’s products are database-specific; you order or download the
installation kit for R/3 Enterprise, for example, only after specifying a
particular database platform. As R/3 Enterprise is available for IBM
DB2, Informix, Oracle, SAPDB, SQL Server, and a few other database
platforms, you must specify R/3 Enterprise for SQL Server, for instance,
to receive the correct SAP and database-specific installation media.
Further, with very few exceptions, you must
actually use the database CD or media that shipped with your SAP
product. Doing otherwise (for example, using a vanilla off-the-shelf
copy of SQL Server 2000) will not work—SAP updates the database CD that
they provide to you, writing hooks into it to facilitate the
installation process. By the same token, even your SAP installation CDs
are also tweaked specifically for SQL Server. Thus, trying to install an
Oracle database with SAP R/3 installation media tweaked for SQL Server
will never work, either.
When
you have the correct installation media, exactly how do you go about
performing an SAP installation, though? The answer lies in SAP’s
installation tool, SAPinst.
System Landscape Implementation Manager—SAPinst
The SAP System Landscape Implementation Manager,
or SAPinst, is SAP’s installation tool of choice for new products and
mySAP components. Do not be tempted to simply execute the tool, though,
until you address all of the installation planning and preparation
required for a successful outcome. You might be loading SAP in a Windows
environment, but the process is a bit more complicated than
double-clicking a Setup icon and walking through a couple of “Next”
screens!
SAPinst appears similar to some of SAP’s older
installation tools in that it’s GUI-based and has much of the same
familiar look and feel. However, it offers quite a few advantages over
previous installation utilities and approaches, such as R3Setup (used to
install SAP Basis 4.0B through 4.6D systems) and R3INST (4.0A and prior
releases through 3x). For example:
- SAPinst
does not abort due to errors; instead, the installation stops and you
are given the opportunity to fix any issues. Afterwards, the system
installation is simply restarted where it ended (the point of failure).
- You
can also step “backward” at any time during the installation to correct
or change your entries, without having to restart the installation.
- The
installation is logged in a single log file (sapinst.log), rather than
multiple log files as has been SAP AG’s custom. In this way, it’s easier
to track and analyze installations after-the-fact.
- Because
the graphical user interface (GUI) portion of the installation tool is
Java-based, SAPinst has a very consistent look and feel across multiple
components and even operating systems.
Because the GUI is Java-based, a Java Runtime
Environment (JRE) must be installed before the actual component
installation can be started. This is accomplished by installing a Java
Development Kit (Java 2 SDK, Standard Edition). A JDK is unfortunately
not generally included with your installation CDs or media. I have
successfully used the JDK that ships with SuSe Linux Enterprise Server 7
(Blackdown JDK 1.1.8) for Intel-based installs, and heard good things
about 1.1.6 for Sun Solaris environments.
If you have a JDK upon which your
SAPTSO or general IT organization has standardized, I suggest trying
it—it will probably work just fine. To be sure, check with http://service.sap.com/platforms
and drill down into Availability for SAP Components in Detail > SAP
Web AS/Basis/Kernel > Planned OS/DB/JDK Releases. Note that the
specific location of and access to this Web site have changed a number
of times, and will probably continue to change with every release of Web
AS; worst case, execute a search for JDK from the /platforms site.
