The Infallible 2-by-2 Matrix and the Magic Quadrant

A long time ago I worked for one of the big consulting firms where every interaction with the client seemed to involve a 2-by-2 matrix.  It got to the point that some of the consultants and most of the client laughed whenever one of these was pulled out.  It became a contest to create 2-by-2 matrices for everything and at one point in my life I aspired to publishing a book of 2-by-2 matrices to enable and empower everyday people to make good life decisions.  I think someone beat me to it at least in spirit.

I think the world has become conditioned by 2-by-2 matrices such that the goal is to always be in the top right hand corner – the so called magic quadrant – whereas being in the bottom left hand corner shows how much progress you still have to make.  As highly paid consultant I am supposed to help you find the path from where you are to where you want to be.  The funny thing about 2-by-2 matrices is that you can make them do whatever you want to serve your needs.  Take the example of where I should go for dinner tonight:  If I plot on one axis how likely the bill will conform to the client expense policy and plot on the other axis how well the restaurant menu prices align with my per diem I get something that looks like the graphic below.

If I follow this chart and adopt the recommendation of the magic quadrant I’ll be eating fast food every night because it’s cheap.  Unfortunately, I’ll feel like Morgan Spurlock in no time.

If I look at this chart with a more skeptical eye the two axes are showing similar information, so the whole thing is pretty bogus.  If you are going to use a 2-by-2 matrix to make a point with a client make sure it serves a useful purpose.  One of my favorite matrices plots employee/consultant willingness against ability as shown below.

In an ideal world all workers fall in the magic quadrant, i.e. are both able and willing to perform a certain task (could this be the nirvana of a low maintenance, competent and talented worker?).  The individuals who fall into other quadrants are potentially much more interesting and I would wager that not every worker falls in the same quadrant all the time.  After all, I’m not a big fan of “busy” work: I am able to do it but not very willing because I don’t value it.  But when it comes to blogging I am both willing and able (obviously!) [Ed. Note: You, sir, are a very able blogger!].  Workers who are able but unwilling present a special set of challenges for project management (you can lead a horse to water but you can’t make him drink), whereas workers who are willing but unable may be lacking skills they want to acquire.

The takeaway here is that there is a place for 2-by-2 matrices in conveying a message: stating an objective; starting a discussion, etc. but use them sparingly and only when it is relevant.

In the meantime, send me your suggestions for 2-by-2 life decision matrices and I’ll see what I can about giving you a credit in my forthcoming publication: Top Right Sure Beats Bottom Left.

It Depends

I don’t know anyone working on SAP projects that doesn’t laugh or roll their eyes when someone says “it depends”.  As much as I mock it, the response does have some merit.  For example, if a client asks you how SAP processes purchase orders it is difficult to give a single definitive reply and “it depends” is a great cop out.  Purchase orders: would you like an account assignment with that?  Do you want to use info records?  Do you have quota arrangements?  Do have to have requisitions for every PO?  And so on.

It is critical to make a rapid transition from the non-value adding “it depends” to a discussion of what matters to your client.  This is where your knowledge of their business and prior project experience come into play.  I would hope that during the project scoping and requirements gathering phases you gained enough of an understanding that you only suggest SAP processing options that are applicable to your current situation.  After all you wouldn’t discuss logistics invoice verification if you are only processing A/P invoices directly through the FI module.

This Happens on Every Project

This phrase shows up in various forms and the two most common variants I’ve heard are “Every project runs into this kind of thing” and “I’ve seen this before on other projects”.  If you find yourself making statements similar to these pause for a moment about how your client will perceive it.

I have only come across these phrases being used when a project has gone astray and has run into a crisis of some sort: testing is revealing a whole new set of requirements that weren’t captured during blueprinting; test scripts don’t have enough details; functional specifications lack detail; too many overlapping yet dependent activities, etc.

The best comeback I heard to “This happens on every project” was from an exasperated client who asked: “Just so I’m not surprised when it happens, what other things happen on every project that I should know about?”.  (Thank you Patrick!)

In short “this happens on every project” can often be traced back to an earlier failure of project management.  Sometimes the situation is unavoidable, for example, despite your guidance about not moving on to the next project phase because of incomplete deliverables your client insists on going forward because the timeline says it is time to move forward.  Sometimes, key milestones are met but the sign-off is far more conditional than it should be.  Regardless of the underlying circumstances your client probably sees you do one of two things:

• Reactively tell them this happens on every project and then describe how every project goes through some level of fire drill and triage to get things back on track
• Proactively manage their expectations and make clear the potential problems the project may run into: for example, designing and developing while integration testing is never a good idea.  In this way you provide leadership, not just management, and set a course to avoid a fire drill.

Typically a client does not like surprises and pro-active behavior is better than reactive.  I like to think that as a project manager I exist to prevent forest fires, not to fight them.

Consulting Catchphrases Conclusions

My underlying thought is that the consulting clichés have an element of truth and validity to them and you should strive to use them as a springboard to bring value to your client.  Think about where the clichés came from – usually a negative experience – and see if you can anticipate where you might feel compelled to use these catchphrases on your project and (ahem, forgive me!) avoid them like the plague.

Please let me know if you have any favorite overworked project phases and I’ll do a follow up posting if I get a good number of responses.

How much data to move? How much data to leave behind? What to automate, and what to execute manually?  How to gracefully orchestrate and execute a data migration cutover from one system to another?  Where and how to fit the data migration plan into the overall business implementation plan?  How to continue to run the business during the data migration phase of the business project implementation? These questions are all part of the planning fun!

Data Migration Testing

Processes that we have exercised and continue to exercise on a regular basis are no big deal, do not cause anxiety, or raise any blood pressures.  The daily report, the custom transaction, the interface that runs several hundred times a week – they are all second nature now.  They happen, and no one notices.

But reflect back to the very first time these processes went live.  This is precisely where you are with data migration.  For most, it is a once in a lifetime event.  It is important, then, to raise confidence levels, and reduce anxiety levels surrounding this activity.  This is achieved by practice, practice, practice.

Typically, I like to see at least three data migration test cycles executed in an isolated data migration client.  This allows for several attempts at exercising and fine-tuning the data migration plan; collecting nominal run time statistics to have some idea of how long the data migration might take; identifying and fixing any data migration program object defects; identifying and fixing any data mapping and content defects; and identifying and fixing any functional configuration issues. Each of these tasks are done with the goal of significantly improving the fallout rate with each data migration test cycle.  These data migration test cycles also give us the opportunity to practice our legacy extract skills, our fallout analysis skills, and our fallout manual cleanup skills.

Source Data Quality

Each data migration test cycle begins with the legacy or source data extract.  An important activity between data migration test cycles is the cleanup of the legacy or source data.  The data migration process will most likely discover many data problems.  Customer and vendor address data alone are enough to bring your bolt-on tax jurisdiction determination software to its knees – that zip code that is too short, too long, or just plain incorrect when combined with the associated city and state; the various abbreviations used in place of the actual city name; the city and state entered in the same field when they should have been entered into separate fields; etc.   If the source data is not fixed, your data migration test cycles will begin to look like the movie Groundhog Day.

Source data provisioning and cleanup could very well be problematic, especially in an acquisition or merger scenario where the providers are part of a different organization and have no incentive to participate in your project.  If you encounter this scenario, you will most likely need to engage the appropriate management level from your organization to have a serious discussion with the appropriate management level from the providing organization.  Recognize this, be in control, and raise that flag early.    Do not sit around for several days waiting for data to arrive, as this will only set your project behind schedule.

Data Migration Support for Other Testing

In any business project scenario, the development team will salivate at the thought of testing their customizations against your real data in the conversion test cycle box.  Likewise, the functional team will be chomping at the bit to use your real data to test configuration scenarios.  And the interface team and the data warehouse team can’t ever get enough data to play with.

While working within your three data migration test cycles, just say NO.  You absolutely need a controlled environment for data migration test cycles, and these other teams will not respect that.  They have a different focus and purpose which requires changing and manipulating degrees of freedom that you need held constant.

But, we are all on the same team trying to move the project to the finish line within the expected project timeline.  So to help your other team members, plan for additional data migration cycles to provide this data to these teams.  That’s more data migration practice for you, and it gives everyone else what they need.

The Perfect World of Data Migration

In a perfect world, for each data object to be converted:

1. The functional specification and mapping documents are well-written and clear.
2. A data load file is built exactly in conformity to the well-written functional specification and mapping documents.
3. The data migration ABAP objects are built exactly as specified by the well-written functional specification and data mapping documents.
4. No one is insisting that we move a square peg into a round hole.

In a perfect world, for each set of data that is to be migrated:

1. The legacy system data has been thoroughly cleansed.
2. The providers of the legacy data are genuinely interested in providing accurate data on time.
3. Server-resident load files in a Unicode system are correctly encoded to UTF-8.
4. A delimiter other than comma has been specified for the load file.

In a perfect world, the data migration test cycle client:

1. Is built in a box that is not the development box.
2. Is configured exactly like the client where the data migration ABAP objects were built and tested.
3. Is not open for configuration, unless by design.
4. Is not part of a transport path. to prevent the current cycle of conversion testing from being blindsided by any new configuration changes.
5. Is locked down so that only data migration and data validation tasks can be performed.
6. Is configured to handle a more background and update processes and fewer dialog processes.
7. Is built in a box that has enough disk space to be the repository for the primary load files and any intermediate processing files needed.

In a perfect world, at the project level:

1. There is an overall business cutover or implementation plan into which you can assimilate your data migration plan.
2. The data migration plan integrates nicely into the overall business cutover plan.
3. There is a strategy in place to bring the data current between the time the cutover freeze is enforced and the implementation date.

Stay Tuned!

In the real world, the fun is just beginning.  Those perfect world scenarios just never seem to happen.   But stay tuned!  In my next blog post in this series, I will discuss the details of the Data Migration Plan.  After that, in subsequent posts, I will drill down into some real world scenarios that I have encountered and discuss how I dealt with them.

This is good functionality and once your business scenarios, processes and steps are in SOLMAN you can use them as a baseline for additional projects.

Consider the “global template” scenario that crops up in companies today: a core set of business processes are designed and rolled out on a global basis – the only deviations allowed are those mandated by local legal requirements (a.k.a. localization).  On top of this there are the business scenarios that fall outside of the business template.  You don’t want to build a standard implementation project from scratch each time for the core business processes.  This is where template projects save you time and effort.

SOLMAN Templates and Business Process Templates

Using SOLMAN and template projects you can capture that global template with its common business scenarios and then extend it for local variations and non-standardized business scenarios.  Let’s work through an example.

Template Project Definition (SOLAR_PROJECT_ADMIN)

Consider a template project (ZTPC300) with some business scenarios defined in the template as shown below.  In this template I initially defined three templates: one for order-to-cash (OTC), one for procure-to-pay (P2P), and one for financial processes (FIN).  From a global business template perspective let’s assume that there are common processes in OTC, P2P and FIN that need to be rolled out in each country (or business unit or division or legal entity… you choose).

Having created these templates in the project administration I go over to project maintenance with transaction SOLAR01.

SOLMAN Project Maintenance (SOLAR01)

Now, in this transaction you can see where business scenarios have been assigned to the templates from the project definition.  In this example the OTC transactional scenarios and the OTC master data scenarios have both been assigned to template ZTPC_TEMP001.

As discussed in my previous post there is further detail at the business process and step level within the SOLMAN project.  This is where I would expect to find detailed descriptions of transaction execution, business rules, etc.

Implementation Projects & Template Projects

At this point you might be wondering what the point is of this set up.  Having invested the time identifying the content of my template project that constitutes my global business template I can use it when I want to build a new implementation project for the next part of my global roll out.

Now when I go to transaction SOLAR_PROJECT_ADMIN and create a new implementation project I see a curious thing under the SCOPE tab in the project definition (see below).

The three template areas from my template project are made available to me and, if I want to, I can further select at the business scenario level to include or exclude the transactional and master data scenarios.  In this case I have selected transactional scenarios only.

If I now save my project and view it with SOLAR01 I see a project that includes the transactional components of the template project along with the lower level details.

This means I don’t have to build out all this content because it was brought in for me from the template.  Pretty neat.

One Implementation Project from Many Templates

In one of the graphics earlier you may have noticed that the templates available to me when I was building my new implementation project included the OTC, P2P and FIN components but there were two other components available: Z_EMS_001 and Z_SDSO_001.  How did that happen?

One of the neat features about building an implementation project is that you can pull in components from multiple templates.  In this example, I have two template projects with available components which means I can select from both template projects to build my implementation project.

This could be useful if, for example, you had templates for historical reasons for common financial processes, common HR processes, common procurement processes and you wanted to roll these out together in one project for a new business unit.  The SOLMAN functionality allows you to pull the required template components from the three source projects and combine them into one implementation project.

Hints & Tips

If you want to start using template projects getting the sequence of events and status changes in the right order will save some frustration, so here’s what I recommend:

• Create the template project with SOLAR_PROJECT_ADMIN
• Build out the project structure with SOLAR01
• Identify the nodes on the project you want to use as template components
• Create the template components with SOLAR_PROJECT_ADMIN and leave them in private status
• Update the project nodes using SOLAR01 with the appropriate template component.  If the template components are in a public status this step is not possible
• Use SOLAR_PROJECT_ADMIN to change the template component status from private to public.  This makes the component available when you build a new project.

Summary

This method in SOLMAN to build implementation projects from template projects is a terrific time saver.  It allows you to re-use and update project artifacts giving you a jump start on value adding activities that should bring value to your business.

Nowadays SAP wants you to use SOLMAN to manage your landscape and use it as the main conduit to interact with the mother ship in Walldorf.  Lots of SAP installations use SOLMAN as a way to generate developer keys and as a document repository: valid uses, but only a small fraction of the available functionality.  Let’s explore some more of that SOLMAN magic.

SAP Business Process Design

An ongoing SAP mantra relates to taking a business process based perspective: rather than look at point functions and optimization of individual steps you take a more holistic view of the entire business process and attempt to optimize the whole.  With SOLMAN (and encouraged by SAP) you can take a hierarchical approach from business scenarios to business processes to business process steps.  For example, you can have an order-to-cash (OTC) business scenario and within that you have a standard material order fulfillment process made up of several process steps.  In SOLMAN you can build a structure that looks something like this:

Within SOLMAN you can identify the specific SAP transactions executed in the steps (both custom and standard transactions).  You can attach descriptive documentation at any level, for example, an overview of the OTC business scenarios as executed within your organization.  At the business process level you may want to provide one overview of the order fulfillment process for standard material delivery orders, and another for a services order.  Finally, at the process step level you can provide details about how a transaction is executed as part of the overall process.  These steps don’t have to be SAP transactions: they could be manual offline activities or steps performed in another application.  You can also include development objects that have to be incorporated into the process flow.

Here’s the point: laying out the scenarios, processes and steps in SOLMAN creates a structure that can be pulled directly into the SAP test workbench using transaction SWTB_2.  This transaction automatically takes your SOLMAN project content and creates test plan content.

SAP Test Plan Content Creation

And what is even better about this step to pull information into the SAP test workbench is that you can pick and chose the elements you want to include in your test plan.  Once you have a test plan, you can create test packages with tester assignments and test sequencing.  The graphic below shows a test plan structure created automatically based on the SOLMAN project structure shown above.

In this graphic you can see that the transaction codes and the supporting documentation have been pulled into the test plan.

Now that I have my test plan content I can create test packages and assign testers to the packages.  In the graphic below you can see four test packages and the assignment of testers.

Now within that test package I can sequence the tests and supporting documentation and assign testers to each step as shown below.

This can be pretty powerful stuff.  With some forethought and preparation I can generate a test plan based on the contents of my SOLMAN project.  I can pick and chose the pieces I want from SOLMAN to build my test plan content and further pick and chose what I want to include in my test packages.

Test Execution

Now when the project goes into test execution each tester assigned to a test package can execute transaction SWTB_WORK to see all the packages where she/he has been assigned as a tester (see below).

Clicking on a specific package drills in to show the detail test steps, the sequence, the assignments along with other useful information, for example, the status of each test step (see below).  Not only is this information all available in one place but the transactions can be invoked by clicking on the check mark and, assuming the correct technical set up, the system will automatically log you on to the test system ready to perform the test.

Test Reporting

On top of the test plan preparation and execution the SOLMAN tools also support overall test reporting.  The SAP Solution Manager Work Centers transaction (SOLMAN_WORKCENTER) includes some delivered reporting capabilities to allow centralized monitoring of test plan and test package execution for a project.

The reporting allows you see report test status across test packages within a project and supports drill down capability to see the details associated with each test including documentation for test results and any test defects reported.

Summary

The SAP SOLMAN tools allow your project to be used as the basis for your test plan content and automatically include your project documentation in your test plan.  The inherent integration means that you can use SOLMAN as a document repository for business process design, key decisions, test case identification, etc. and use as much of that as you want when you build your test plan.  One source for documentation and information; no need to organize and use different tools.

Clearly the example case I used here is something of a simplification and I am not going to underestimate the thought that needs to go into test planning content, but whichever tool you use for testing you have to put in this effort regardless.  I hope this example serves to illustrate some of the capability available in SOLMAN and reveals some of the potential available in the tool.

However a key point to note is that the SOLMAN Test Workbench allows you to build test content, but it does not offer the capability to schedule the tests.  Again this is something you need to do regardless of the tool you use.

What’s Next?

This blog discussed use of SOLMAN project content to automatically generate test plan content.  In my next blog I’ll discuss how you can use template projects to rapidly create implementation projects and save huge amounts of project preparation time.

The build of an SAP system during upgrades or cutovers will change during Integration Testing.  Additional kernel patches, support packs, OS or DB patching (Microsoft vulnerability, Oracle security, etc), interface architecture (filesystem mountpoints and system connectivity), and functional transports drastically change the environment between QA and Production Cutover.

Items such as bandwidth issues due to other systems activity or backups, bad install package or kernel file, low disk space in filesystems, transport conflicts or failures due to bug fixes, project plan sequencing issues, and system dependencies are some items that can be discovered prior to production cutover activity.  Many of these are not discovered during the build of QA due to a more relaxed timeline, only working during normal business hours, and changes as a result of formal integration testing, and basis administrator resource changes.

Here are a few guidelines for a successful practice activity.

• Use hardware that is close to your SAP production system (location, networking, CPU speed, OS and DB version)
• Perform a SAP system copy from Production to the practice server to establish baseline
• Run the practice as close to ‘reality’ as possible (day of week, time of day, location of administrators)
• Use same upgrade package that will be used for production
• Use same technical process for applying the patches (terminal server, downtime minimized)
• Follow the production cutover plan for this activity (not capturing timing for backups or file transfers can add hours to a cutover plan)
• Use the practice to monitor and create a ‘watch list’ for long-running support packs or transports
• Practice a SAP system restore activity to understand contingency planning and timing

In this post I’ll do a combined discussion about the use of offshore resources in an upgrade project as well as share some experiences working with remote resources.  My colleague, Mike Salvo, has already discussed ABAP customizations in an upgrade in this post.  Now that you’ve found these customizations, what do you do next?  Actually Mike provides loads of good advice about what to do next in terms of sorting out what is in the overall pile of objects that need to be examined.

What I hope is that you have documentation related to these objects: information that tells you why they were created, what they do, where SAP functionality is deficient in the current release and how you worked around the shortcoming.  This should be helpful in making the evaluation about whether you can remove a particular object or if you need to make sure it works in the new release in a way that satisfies your business and/or technical need.

I going to assume that you have been through the “bag of rocks” analysis described in Mike Salvo’s posts and now have a collection of pebbles, stones and boulders to work through.  This is where you can make good use of offshore resources to help out: there’s a lot of discussion about the use of offshore resources and you can use them really well or really badly.  Let me digress.

SAP Offshore Development Resources

I’ve heard many complaints regarding offshore resources, but the two biggest complaints that are trotted out as a serious offset to the expected cost savings are:

• The time difference makes turnaround time longer than projects plan for or like.  For example, if you work with resources in India you have to synchronize working schedules and often this means team members either work way late or very early in the day.
• The accuracy and completeness of what you ask for determines the quality of what you get back (a.k.a. you get what you ask for, not necessarily what you want): the difference in time zones makes it difficult to get clarifications and address questions quickly.  Consequently, development life cycles can be extended even if the hourly cost is lower.

A straightforward way to address the first issue is to work with an offshore partner in a time zone closer to yours.  In this respect I’ve worked with development partners in South America where the offset with US time zones is small.  This helps address the second complaint: by being in similar time zones it is much easier to either pick up the phone and address questions or send e-mail and get a quick response to a question.  I’ve been on projects where a quick answer to a question had to wait a day because of time zone and work schedule difficulties.  There may be a slight premium for using an offshore team in South America, but the turnaround time and responsiveness usually makes it worthwhile.

How does this digression help your upgrade?

Once you’ve sorted your bag of development rocks you can go through another level of review to rank the objects in terms of complexity and/or difficulty of remediation for the upgrade.  In general, I’d recommend keeping the most difficult work items close at hand and have onshore resources work them.  Any questions about what the object is supposed to do, any business process impacts can be addressed readily with end users and business analysts.  Objects that are less complex can be worked by the offshore team: you stand a good chance of getting what you need by providing clear documentation (all those project artifacts you maintain) and explicit instructions around what you think the remediation entails.  You should also set expectations around what comes back from your offshore partner: code that is free from syntax errors isn’t going to be enough, some level of testing and documented results are more likely what you want.

SAP Upgrade Onshore and Offshore Resource Balancing

I can’t tell you or even estimate how many onshore and offshore resources to engage in an upgrade project without knowing more about your environment and object analysis.  However, I would definitely recommend two key onshore roles:

• Development Object Remediation Lead: an individual who has responsibility for coordinating and prioritizing the objects sent to the offshore team and managing the associated sign out and sign in process.  This person also has the unenviable task of serving as the quality control checkpoint and enforcer of expectations with the offshore team.  There should be a corresponding role in the offshore team, too.
• Development Object Remediation Senior Consultant: one or more individuals with the expertise to address the complex objects

Smart use of offshore resources has the potential to reduce development object remediation cycle times and that should lead to direct cost savings.  Any steps that accelerate your overall upgrade project time line and contain costs should be viewed as a good thing.  Try it – you just might like it!

In short, if you have done a good job with your earlier implementation activities you should have a plethora of materials that can be reused.  Remember that after an upgrade your basic goal is to still be able to do what you could do on the previous release along with anything new you are introducing.  The way you execute business functions may be slightly different, but the underlying objective should be much the same.

For more on SAP Upgrades download the white papers:

SAP Upgrade Checklist

Customization Risk Analysis in an SAP Upgrade Project

SAP Project Artifacts for Upgrades

In short, don’t reinvent the proverbial wheel if you have one available to you already.

As you went through your initial SAP implementation and ongoing support work you probably generated piles of documentation and if you managed this well throughout the ongoing project lifecycle there is a good chance that you can reuse it.  In essence, the better job you have done identifying, capturing and testing the functionality used in your SAP system the easier it should be to reuse those artifacts to confirm continuity of business processes in the new release.  It sounds easy, but it is a rare project that consistently maintains and updates project documentation as functionality is introduced through point releases, production fixes, etc.

Whatever information you have is worth reviewing to see if it can be reused or at least used as a basis for building out the scope of testing for the upgrade.  In addition to the testing scope, you may have test plans, procedures and protocols that can be adapted.  Typical project artifacts for consideration include:

Functional Scope

Any SAP project starts with an initial functional scope which grows over time.  This is a great start point for defining what you need to test and circling back to find where you implemented non-standard functionality.  The standard functionality is likely to stand up to the upgrade and work straight away, whereas the non-standard stuff is where you want to pay special attention.  In this scope you want to make sure you capture any special periodic processing, e.g. daily, weekly, monthly, quarterly and annual processes to be tested

Business Process Procedure Documents

In conjunction with your functional scope, you probably have business process procedure documents that provide detailed step by step instructions on how to execute job functions.  You can use these as a tool to verify whether business process steps have changed.  In the event that the steps have changed it is clear what documentation needs to be updated.

Technical Objects Scope

Similar to the functional scope you should have a catalog of technical objects, e.g. reports, custom programs, user exits, SAP modifications (if you went down that path), etc.  This provides a list of objects to examine and evaluate as part of the upgrade.  This is a topic covered in depth in a separate blog posting.

Test Plans, Scripts, Procedures and Tracking

Now that you have a functional and technical scope defined you can also revisit any test plans you have.  Testing comes in many flavors (click here to discuss some flavors) and you probably have prior test artifacts for functional testing, end-to-end testing, security and authorizations testing, etc. which are worth a review.  On top of this any regression test scripts and automated test tools may be re-deployable in support of upgrade testing

On top of this most projects have established procedures for tracking issues, resolution steps, and progress reporting.

Testing Organization

In conjunction with your test plans you probably have documented roles and responsibilities, test team organization structure, escalation routes and sign-off procedures.  Again, reuse all that you can.

Partner Systems, Interfaces, Batch Processing, Performance Metrics and System Outputs

Very few SAP installations are islands of functionality, instead there are numerous partner systems that interface with SAP as well various outputs in both electronic and hardcopy forms.  An inventory of these items provides another checklist for testing and identifies both internal and external partner systems you need to include in your upgrade test cases.

System performance is often critical for interfaces and batch processing and any historical activity that identified and tested these elements provides a potential guide for ensuring no degradation of these things as a result of the upgrade.

SAP Upgrade Go-Live

Again the experience from other go-live events may form a good basis for building the upgrade production implementation plan.

Supplement these artifacts with additional content for new functionality and modify for anything that has changed because of the upgrade.

Get Organized for Your SAP Upgrade

By no means am I saying that everything you have built and accumulated over the lifetime of your SAP installation is going to lend itself easily to being recycled in support of your upgrade activities.  However, I am saying that you put in a lot of work to get to this point, you already have a good idea of how to test SAP, you know the quirks and nuances of your organization, so don’t feel like you need to start from scratch.  Cast a careful eye over what you have in your project inventory and see what make sense to apply and what to discard.

And if your SAP project inventory is not a robust as it could be, think about how to strengthen it ready for the next time you have go through an exercise like this.

The choice to upgrade your company’s SAP platform is a very important business decision.  Many criteria need to be considered when determining if an SAP upgrade is the right move and, if so, what type of upgrade needs to take place (ECC 6.0, Enhancement Packs, etc.).  A successful SAP upgrade requires the determination of your upgrade requirements, proper planning, and an assessment of technical and functional risk.  Below is a sample of our SAP Upgrade Checklist white paper:

Determine Your Upgrade Requirements

1. What are the business reasons for upgrading? Support from the business for an upgrade project is most important.  If there are no business reasons for upgrading, then you should probably not do it.  Included here are the business risks incurred by not upgrading.
2. What are the technical reasons for upgrading? Included here are the technical risks incurred by not upgrading.  (Posture increasing maintenance fees for old versions or complete support withdrawal as a business risk – not a technical risk.)

For the complete list, download the full white paper:

SAP Upgrade Checklist

Related Links:

1. SAP Upgrade Project Plan
2. SAP Upgrade Project Management Considerations
3. Contact Us

Excuse a note of skepticism about the end-of-upgrades-as-we-know-them, I suspect the path and the mechanism to get new functionality will change.  The text book methodology and approach will change, but I suspect SAP customers will be hesitant to let go completely of previous approaches to upgrades.  Sounds like a topic for a future blog post.

In these posts I’ll address some of the upfront considerations before you embark on an upgrade, then progress on to ways to leverage some of your existing assets to make the process as successful as possible.  Along the way I’ll discuss the impact on your SAP landscape, non-SAP systems, and other ongoing projects you may have in motion.  As a wise man I once worked for said–and I’m paraphrasing–“we don’t want to rebuild the plane in midair.”  Trying to get it in the hangar without passengers onboard is a noble goal, but perhaps not completely realistic.

This discussion is pitched at a fairly high level although an in depth discussion is easily set up by clicking here to contact us.

For more on SAP Upgrades download the white papers:

SAP Upgrade Checklist

Customization Risk Analysis in an SAP Upgrade Project

As always, comments and feedback are welcome, but I ask you to be civil.  Your experiences are not the same as mine, I can learn from you and I hope you can learn a little from me.  Let’s begin.

SAP Upgrades: Start with the End in Mind

There are plenty of reasons why you want to upgrade your SAP system and those reasons will probably drive your approach, how you position the project and execute.  Influencing factors include, but are not limited to:

• The current release is old and is either on extended SAP maintenance or is about to go on to extended maintenance
• Recent changes in SAP licensing are an incentive to upgrade
• Other parts of your systems environment and infrastructure are changing and an SAP upgrade makes some of these changes easier or enables them
• New functionality is required to support acquisitions
• New functionality is required to decommission legacy systems
• New functionality is required to expand the SAP footprint in your organization
• Custom development is becoming too cumbersome to maintain and can be decommissioned by standard functionality in the new release

In short, there are likely to be several reasons why you want to upgrade and your organization has other considerations over and above those listed.  By identifying the drivers for your upgrade you should be able to work out who most wants it to happen as well as those who are not supporters.  On top of this you work out who has the most to gain from it in the short, medium and long term. All this is useful for putting together the pitch

SAP Technical Upgrade versus SAP Functional Upgrade

There is much discussion around the pros and cons of performing a technical upgrade versus performing a functional upgrade.  To some extent I view this as a false choice: a technical upgrade is always going to involve some functional upgrade work – it is a matter of degree.  (The only escape clause here might be if you have truly installed SAP with no custom code, but I have yet to find an installation with no custom code).

The big selling point of a technical upgrade is that it is the quickest option and the least intrusive.  All true, but nonetheless you still need to go through the upgrade process several times to ensure it works without problems and you need to test the upgraded system to ensure that you can still run your business processes.  Even an SAP system with limited amounts of custom code needs to report out on the custom code forcing you to do some work and make decisions about it.  Typically the work and decisions have one of several possible outcomes:

• The custom code is still needed because the new release does not support the required functionality, hence you have to keep the code and test it with the new release.
• The custom code is no longer needed because the new release delivers the required functionality.  Consequently, code is decommissioned and you have to test the standard process.
• The custom code has to be modified in some way to work with the new release.  Again this leads to some testing and business process verification

Each custom object should fall into one of three buckets outlined above and this starts to identify work plans and activities.

A note of caution on the identification of custom objects: development environments often contain half-finished and abandoned objects, work-in-progress, and objects that never moved.  These objects can unnecessarily inflate the list of objects that need to be reviewed, so getting a list from production or the QA system can produce a more accurate list.

So even in the context of a technical upgrade I’ve run into the need for some functional work.  If my overall upgrade project objectives include deployment of new functionality I have the same considerations as a technical upgrade but now I have to scope, design, develop, integrate, test and deploy the new functionality.  Clearly this means more work, more time and more expense before the upgrade goes live.

In short, I like to think about technical and functional upgrades as two overlapping circles in a Venn diagram: the size of the overlap is what I am trying to control when I label my project a technical upgrade or a functional upgrade.

Finding Your SAP Upgrade Path

Another factor when planning the SAP upgrade is where you are starting from and where you want to get to.  There may not be a direct migration path from your current SAP release to your target release, in which case you need to identify the interim stepping stones and the impact that has on overall elapsed times and complexity.  Based on the uniqueness of your environment there may be actions you need to take at the interim release before you can get to the end release.

Making the Pitch for an SAP Upgrade

In my experience there is rarely a single concise driver for making an upgrade and each SAP installation has different factors influencing the decision.  Finding the right pitch with a convincing cost justification is pretty tricky: a (mainly) technical upgrade is often pitched as a precursor to greater things (delayed gratification, if you like), whereas a functional upgrade delivers value more quickly.

Addressing the demands of your decision makers and your budgets is always challenging, but you should also remember that upgrades are part of the TCO with SAP.  At some juncture you need to upgrade and finding a time in the business and IT calendars to focus resources on the project is unavoidable.

Next Steps Preparing for an SAP Upgrade

In my next post on upgrades I’ll discuss how you can leverage and re-use some of the work done on prior projects that can accelerate your upgrade.