Selecting Your SAP Solution Stack Partners
The goal at this stage in
the sizing process is to now perform a thorough “Side-by-Side Sizing
Comparison” between the various SAP solution vendors that have made the
grade thus far, to ultimately select the best SAP Solution Stack
partners for your particular mySAP.com implementation. This final
evaluation involves the following:
A detailed sizing review
Verification that each vendor’s proposed SAP solutions are indeed supported by SAP AG
Verification
that you will not be the first customer to do something “new” (unless
that is part of a vendor’s value proposition and is consistent with your
company’s technology perspective)
Discussions with vendor-provided SAP Production references
A review of your TCO numbers
I cover each of these key concerns next.
Pulling Out “New and Different” Sizing Data
With your Sizing
Evaluation Team reconvened, the work of reviewing each vendor’s latest
iteration at sizing an SAP system capable of meeting your business needs
is necessary. Your first order of business is to be on the lookout for
“extras” that you did not request. It is generally in the best interests
of each vendor not to include these extras, as they tend to inflate the
vendor’s solution cost. Things like ITS servers, or a SAN rather than a
less-capable and less-expensive traditional direct-attached storage
system, and even extras like enterprise management consoles and domain
controllers need to be pulled out of sizings. In the end, each vendor’s
sizing should be similar enough to facilitate a true apples-to-apples
sizing comparison.
Of course, I have seen
cases where a customer failed to completely understand the technical
requirements of a requested solution, and therefore failed to request
required components or failed to understand that an “extra” was indeed
no extra at all, but more like a minimum requirement. In these cases,
it’s critical to verify that the addition is indeed required, and then
to share the new requirement with the other vendors so that they can
update their own mySAP sizings. You also need to be sure to give extra
points, so to speak, to the vendor who identified the shortcoming; this
speaks well of their SAP Competency Center, and needs to be duly noted.
Verify Support for Architected Solutions
More than a few times I
have seen an SAP technology partner recommend a solution component not
actually certified or supported by SAP. Further, I have seen ambitious
hardware partner account teams recommend SAP configurations not even
supported by their own SAP Competency Centers. It happens. Technology
changes quickly, but certification processes take time. Be sure to go
through each proposed solution stack with a fine-toothed comb, taking
care to review all recommended hardware and software components. If you
have doubts or know that a particular piece of technology is quite new,
don’t be afraid to check with SAP AG directly; leverage your SAP account
team or SAP project manager. And be sure to work with each vendor’s SAP
Competency Center to ensure that they, too, support the proposed mySAP
solution—hopefully, they drafted the sizing for you in the first place,
but this is not always the case.
In the end, the time spent verifying the integrity and supportability
of your stack is time well spent, as it not only helps weed out
troublesome or ill-prepared vendors, but also helps you avoid
nightmarish post-Go-Live support issues.
Verifying Your Risk Level
Even though a particular
solution or approach may be supported by SAP AG and its SAP technology
partners, someone has to be first—one company somewhere in the world
will be the first to implement a new technology or embrace a new
implementation methodology in their mySAP project. With this dubious
honor comes risk, of course, followed closely by potential reward. For
example, many technology companies offer significant discounts to their
customers “brave” enough to bet their business on new technology
solutions and approaches. My biggest concern here is simply in regard to
credibility. Ask to see previously used implementation plans or project
schedules. Seek templates, vendor-published white papers and best
practices, and other evidence of experience. Work with the vendor’s
Competency Center to gain a sense of their
feelings towards the risk versus reward equation. Finally, prepare to
spend time with the vendor’s reference accounts, too, discussed in
detail next.
Working with SAP Production References
Serious SAP Solution
Stack vendors maintain a list of reference accounts that they can use
to reinforce their credibility with potential customers. Your goal in
speaking with a reference account is to validate the following:
Your proposed solution stack is out there in the real world, running a production SAP solution.
Their
implementation and configuration experiences were in line with your own
expectations, and what you have been told by your potential SAP sizing
partner.
The system actually performs well.
Planned and unplanned downtime numbers are no surprise, or are explainable.
Ongoing operations and support are consistent with your expectations, too.
This is a good way of
checking on a vendor’s general past performance as well. If it’s
possible, I especially recommend meeting with a reference face-to-face
and spending time with a few members of their technical team, where you
can often get unofficial or “off the record” information in addition to
the usual data.
Revising Your TCO Analyses
Given everything that you
have learned over the last few weeks and months regarding SAP sizing,
it’s safe to say that something along the way probably changed. Perhaps
your original goal of a monolithic big-box solution fell apart. Or maybe
your best-of-breed strategy began to look too difficult to support
long-term. Whatever the reason, I am confident that at this point in
your SAP project, you need to revisit the topic of Total Cost of
Ownership and revise your own costing numbers. New numbers may well change your
plans, after all. Only with new TCO numbers in hand can you truly be
equipped to take the sizing process to the next level, and assemble the
SAP partners and products necessary to solve your unique business
problems.
Additionally, after the
final round of SAP Solution Stack vendor reviews is pending, pricing is
usually revisited as well. During this time, it’s business-as-usual for
vendors to take a fine-toothed comb to their overall solution pricing.
Even a few percentage points can add up to big savings in projects
ranging from hundreds of thousands to many millions of dollars. It is
also common for you to structure a holdback or price/performance
guarantee at this stage in the sizing process, too. In this way, your
solution partners will continue to be motivated to perform to the best
of their ability (and rapidly address inevitable integration,
performance or service issues) all the way until the day of Go-Live and
beyond.
Finally,
understanding hardware acquisition costs versus ongoing operational and
management/support costs for each potential solution needs to be
revisited. Why? Because the grass may indeed be greener one way or the
other. That is, over a three year life cycle, my own analysis has shown
that Wintel-based mySAP solutions generally provide a better return on
investment in most cases, for most customers. But I have also seen what
happens when business requirements change overnight, or when an
initially straightforward mySAP implementation grows to include many
components and a hundred servers. In the end, my colleagues who talk of
“pay me now or pay me later” acquisition versus management costing
philosophies have a valid point in these cases. So I stress that you
have this last opportunity to work through the numbers again before
making a final decision—treat this opportunity to measure your
end-to-end total cost of ownership seriously, and take advantage of it.
Selecting Your Core SAP Solution Stack Partners
With final pricing,
apples-to-apples solution comparisons, and a host of other solution and
partner-relevant data collected and analyzed, you can now work towards
selecting your core SAP Solution Stack partners with confidence. This is
often achieved by holding onsite vendor presentations, where any final
questions can be answered and each vendor has an opportunity to present
their overall value and solution proposition.
However, keep in mind
that there is no single best way to assemble your final SAP Solution
Stack. That is, in many cases I have seen an SAP customer select their products
first—the various solution stack components necessary to deliver on
their mySAP vision—and then select vendors. But in other cases, I have
seen customers select enterprise-savvy SAP technology and consulting partners
first, only later to fine-tune the actual combination of hardware,
operating system, database, and even mySAP Business Suite components
necessary to achieve their business vision. Either approach can prove
successful, though you place a lot more faith in your technology and
consulting partners in the latter approach—as you would expect, if they
are truly strategic partners.
Evaluating Specialized Solution Stack Vendors
With your core solution
stack products and partners selected, you are in a good position to
begin filling in any “holes” left in your solution architecture. These
holes may be the result of special high-availability requirements,
disaster recovery requirements, the need to support special types of
system accessibility, and so on. Thus, specialized or “niche” SAP
Solution Stack vendors like disk subsystem manufacturers, makers of
Internet-facilitating or load-balancing gear, test-tool vendors,
enterprise management and other specialty software vendors can be
brought in after your core SAP Solution Stack partners are identified.
The
key to assembling a smoothly working solution from multiple vendors,
rather than one or a few, is to first of all limit the players—if
similar solutions are available from two different vendors, lean towards
leveraging the vendor with whom you already use in your SAP or other
enterprise environment. Next, in cases where different vendors are
brought in, plan in advance how support issues will be addressed. In
other words, you will need to iron out all of the details regarding how
support is handled and how inter-vendor problems will be approached and
solved before you
ever arrive at a problem. SAP AG models the best support approach I’ve
ever seen by way of their PartnerPort facility in Waldorf—here, many
vendors work side by side with SAP AG and to some extent each other.
Outside of PartnerPort, the best SAP technology partners also host Joint
Escalation Centers, support relationships, and similar support
mechanisms between various hardware, software, and other vendors. I
suggest that you work to identify exactly with whom your core SAP
Solution Stack partners have their best relationships, and lean towards
taking advantage of these communication and escalation bridges whenever
possible.
Executing the SAP Infrastructure Planning Sessions
Now that your primary and
probably most of your specialized solution partners have been selected,
you need to commence the post-sizing implementation planning and
scheduling sessions. In my experience, all of your solution partners
should be engaged in the initial kick-off meeting, subsequent sessions
of which actually span a number of days. This includes your hardware
partners, OS and database (software) partners,
your SAP project manager, and any other project managers already
identified. Further, the data center manager and any key technical
resources should also be present at the kick-off meeting.
Initiating
the SAP infrastructure implementation represents a critical milestone
in your SAP project plan, and is indicated as so in the SAP
Implementation Project Plan (SIPP) found on the Planning CD. As such,
there are many tasks and related milestones of a smaller magnitude that
need to be identified, discussed, assigned, and managed.
Day One
Day One of
the infrastructure planning sessions revolves around introductions of
key personnel, review of the scope of work to be accomplished, review of
the key hardware and software vendor’s products and responsibilities,
and reiteration of how the infrastructure planning sessions fit into the
SAP implementation big picture. In the past, I have adopted an agenda
for Day One that looks like the following:
Introductions—Key
personnel from each solution stack partner, SAP, and the client’s
project team are introduced. Contact information is shared, as is a “job
description” for each organization and for each person assigned to the
project.
Vision
and Definition—The reason for implementing a mySAP solution is quickly
reviewed, followed by a high-level review of the scope of work to be
accomplished by the assembled team. Like the pieces of a puzzle, each
partner is made aware of how their own contributions augment every other
partner’s contributions, in the end making the project possible.
Project Sponsorship and Accountability—The role of each partner and the importance of each role are discussed. The term project sponsor
is used loosely here, as it refers to the individual person from each
partner organization tasked with responsibility for completing their
piece of the overall SAP project. Normally, the client has long ago
identified what they expect from each partner. At this meeting, though,
the partner comes prepared to put forth the name of their project
sponsor—a high-level single point of accountability representing the
partner’s interests in the SAP project.
Project
Management—Each partner must also come prepared to introduce their
incarnation of a project manager, another loosely used term that simply
refers to the single person charged with completing tasks relevant to
their role in the project. In my experience, it’s best to clarify these
roles as much as possible, especially with regard to expectations. The
skillsets and qualifications of each project manager are reviewed, too, as are the number of hours expected to be consumed in project-management-related activities.
Project
Structure—Here, the project reporting hierarchy is identified,
discussed, and usually revised. That is, the structure of the project’s
key players, in terms of who reports to who and how issues are
escalated, is covered. In large projects, it’s common to publish a
project organization chart along with a scope statement. Status
reporting, the use and timing of meetings, and other control and
communications processes are ironed out as well. Finally, a schedule for
regularly updating the master SAP Project Plan should be put in place.
Key
Milestones—As they are currently understood, key milestones are
identified and discussed. These are subject to change in the next two
days of meetings, but discussing them at a high level now helps to
prepare everyone for the project in general, and the next day in
particular.
Quality
Management—Processes for continuous improvement need to be developed
over the next few days and embraced by the team. These processes need to
be designed in, rather than “inspected” in. For instance, the use of
workflow diagrams, recipes and checklists, and Pareto charts (a bar
chart format useful in identifying tasks that fall into the 20/80 rule,
where 80% of a project’s issues are related to 20% of the tasks or
resources) represent quality tools. They promote feedback and continuous
updating of documentation, lending themselves to fine-tuning simply by
virtue of their use, rather than something that is performed once and
never used again.
Project
Administration—How to address time and expense reporting,
billing/invoicing, change control, and other administrative functions
conclude Day One. This might also include any contract administration
that remains to be addressed, including updating contracts to reflect
delivery and payment schedules, pricing, discounts, performance bonds,
and more.
As you can see, this
first session addresses the big picture. In doing so, it sets the stage
for the next two days, preparing you to turn your attention next to
project timelines with regard to the actual technology solutions and
system landscapes being implemented.
The Second Day
Day Two commences
with a quick synopsis of the previous day, and then the floor is turned
over to the client or SAP project manager who leads discussions
detailing the following points:
Go-Live
Date—By establishing the desired Go-Live date, an experienced SAP
project management team can “work backward” to identify when critical production
milestones must be accomplished and therefore when tasks supporting
these milestones must commence. This is a good way of constructing or
validating a high-level project plan, too, as it typically contains no slack time (free time between tasks) and therefore clearly identifies the project’s critical path
(project milestones spaced in time such that they represent the
shortest possible number of days in which a project can be completed).
This by no means results in a truly usable project plan, however!
Rather, it serves as a high-level template or perhaps simply as a tool
for developing the actual plan.
Critical
SAP System Landscape Milestones—After production’s Go-Live date is
nailed down, you can work backward to determine when other SAP system
landscape systems need to be in place, too. Thus, the need and timing
for implementing production, Test/QA, training, development, a technical
sandbox, and so on can all be determined based on your production
Go-Live and how much lead time needs to be given to tasks related to
other activities.
Key
Risks—Identifying risks to the project plan is an excellent method of
promoting and then refining timeline discussions. Any risk to
successfully completing a particular milestone related to each partner’s
set of responsibilities needs to be covered, and addressed or
mitigated. For key risks, a contingency plan needs to be developed as
well.
Landscape
Assistance—As each component within the system landscape is discussed,
it naturally promotes the discussion of how much assistance the client
thinks they will need in achieving SAP system landscape-related
milestones. For example, my team often gets involved with technical
sandbox and development implementations, but less so with other
environments (outside of production or at least a review of the
production environment prior to Go-Live). Why? Because after we train
our clients in how to plan for and install a mySAP component, and leave
them with a detailed recipe or checklist for repeating the installation,
they usually want to not only prove that the recipe works, but also to
train their own folks and save budget money by doing it themselves.
Identify
Realistic Timelines—With the critical path and key milestones
identified, and an idea as to which partners will be engaged to support
achieving these milestones, it is desirable to pencil in hard timelines
for Go-Live of each mySAP component to be implemented as well as each
landscape system. Add as much slack time as possible, and spread it out
among the various tasks (I like to see each solution stack partner
allotted some amount of slack time). Working backward with these
realistic figures should give you an idea as to when
hardware actually needs to hit the ground, and therefore when the data
center needs to be prepared. Everything else going forward can then be
filled in pretty easily on the third day.
Knowledge
Transfer—Before leaving for the day, work to clearly understand both
when and how much knowledge transfer needs to take place between the
various technology partners and the client. Assign names of responsible
parties, assign and document the actual tasks associated with this
knowledge transfer, and document the method by which the knowledge will
be transferred; hands-on training, written process/procedure
documentation, use of high-level or detailed checklists, creation of
Web-accessible content, and so on. In the consulting world, we call
these deliverables,
as they represent something tangible that my colleagues and I deliver
to our SAP clients prior to concluding our part of a project.
The second day of
planning sessions can run pretty long. I recommend that each partner and
the client come prepared with their individual project plans or
detailed timelines. In this way, the master plan can be more easily
updated, and valuable time is not wasted trying to recall how long
certain tasks take to complete, or how critical dependencies relate
between tasks. As an aside, it should go without saying that if your
partner cannot produce at least a template project plan based on
previous SAP implementations, you should be very nervous—if you are
paying for specific expertise in a particular mySAP component of
supporting technology, you deserve to benefit from other project’s
efforts. A previously and successfully used project plan is proof of
this experience, for example, and equates to at least a minimum level of
credibility in my eyes.
On the Third Day
Whereas the second day
of planning sessions focused on the timelines and the technology being
implemented, this final day concludes the planning sessions by assigning
names and responsibilities to project plan tasks. Thus, by the end of
the day, everyone leaving the sessions will understand not only their
own roles, but the roles of the entire team and how everyone’s tasks
relate to the project as a whole. And in doing so, you will conclude the
sizing process, taking it from inception through planning the
deployment of your physical SAP system landscape. Tasks to address on
the third day include
Put names to
Solution Stack technical roles—Each partner needs to be prepared to
commit the technical resources necessary to achieve their unique
solution-stack-related milestones. This will include SAP Basis/Web AS
technical leads, Server Hardware Buildout specialists, SAN/Disk Hardware
specialists, OS Installation/Tuning specialists, DBA/Disk Subsystem
specialists, mySAP Component SMEs, ITS specialists, and Front-End Client
specialists. A discussion of
the skillsets required to perform the work associated with each
partner’s tasks, and how their resource fulfills these requirements in
terms of experience and education, is standard.
Put
names to other technical roles—Each partner must also be prepared to
identify their resources satisfying other technical roles, like
High-Availability/Failover specialists, Stress-Test/Load-Test experts,
Functional Testing specialists, SAP Solution Tuning specialists for
their particular contributions to the SAP Solution Stack, and so on.
Identify
administrative key roles—More than just technology folks need to be
identified. Each partner’s project administrator or coordinator, account
manager, documentation specialist, and other support and administrative
contacts need to be documented and shared with the team. In small
engagements, it’s common to see these people wearing multiple hats,
perhaps even sharing technical responsibilities with administrative
ones.
Identify
client contacts—Although this varies, I tend to see most of the
following positions held strictly by my clients. Regardless, it’s
important to understand who is actually responsible for the following
areas that fundamentally support or underpin the SAP project:
environmental/datacenter manager and specialist, network infrastructure
specialist, data and application migration specialist, training
coordinator, operations manager, and help desk manager.
Refine
timelines—With the details surrounding the technical implementation
understood now, it should be possible to refine the timelines associated
with each task such that the hours and days expected to complete each
specific task are documented. This is called a Work Breakdown Structure (WBS) in project management circles, as it breaks down a project into smaller elements and then ultimately into work packages, which are simply tasks that can be accomplished in 80 hours or less.
Refine
and validate budgets—Although all partners can now provide their final
costing numbers, not everyone needs to be involved with reviewing the
budget numbers. Normally, this kind of activity is reserved instead for
project management representatives tasked with managing the project’s
financials. This exercise also helps validate how close each partner
came to estimating their costs, based on the imperfect information
provided to them during the sizing process.
Students
of project management have probably noticed that the three-day planning
sessions covered many core project management fundamentals. The sizing
process in and of itself represents a large subproject of your overall
SAP implementation. So it only makes sense that managing scope,
timelines, cost, quality, risk, procurement, human resources, and
communications needs to be given the same level of attention here as at
the higher overall SAP implementation project level.
Tools and Techniques
I
have included a slew of sizing-related documents on the Planning CD,
some of which facilitate number crunching, whereas others simply provide
for side-by-side sizing comparisons. Miscellaneous SAP/hardware
questionnaires have been included, as have sample tools and sizing
documents in Word or Excel format. I included a special document
entitled “LINK - Quicksizer SAP Solution Brief and Other mySAP Sizing
Links,” too, which points you to a variety of Web-based publicly
accessible SAP sizing-related documents and resources.
