SAP PI Dilemma: How to Get Production IDocs for Testing

Every SAP developer/consultant knows that to be able to test new programming logic and/or configuration efficiently and thoroughly, sufficient test data is required to ensure quality. I have worked on several SAP PI projects and have run into the issue of not having great test data (or, for that matter, any test data!) in my development/test environment. If you’re ever in a spot where you need to test IDocs from a different system, here is a step-by-step guide on how to get them without having to perform much setup.
[Read more...]

Upgrading your SAP System – Pitfalls and Processes for Success

Why Upgrade?

What compels a firm running multiple versions and multiple products of SAP to upgrade its ERP and other usage types? The (not always) obvious reason is the need for new functionality, which can better support company business needs and help them thrive in an ever growing competitive landscape. Basically, they want their business to run better than other businesses in their market. So a brief note on the release strategy for SAP applications, which follow a “5-1-2” maintenance concept: “5″ years of mainstream maintenance; “1″ year of extended maintenance at an additional two percent of the maintenance fee; and finally, “2″ years extended maintenance at an additional four percent fee. Not cheap, but it may be cheaper than a big upgrade project. After that, if you still don’t want to let go of the SAP release, there is always customer-specific maintenance, which is expensive.

I am sure that most of the decision makers are not aware of this information, and that is why I’m  writing this post.  SAP customers need to know of the additional investment they would have to make to keep their SAP system, running status quo.  I would encourage you, and your bean counters, to do the math on considering your SAP installations. After that, I am sure you would be compelled to focus on the upgrade (if not now, when?).

New Functionality

The main reason for upgrading has almost always been the additional functionality.  There are other reasons as well, like instance consolidation, virtualization, and requirements based on hardware, software and O/S.  Every SAP release brings new features, challenges and opportunities.  The need to upgrade is mostly driven by business needs, which in turn require new functionality in your SAP environments.  This empowers your company by transforming your processes and moving your company to higher levels of efficiency, richer reporting with new and improved analytic tools like BIA and HANA, and ability to make timely and informed business decisions.  The choice must be made whether to implement and develop the new functionality or perform an upgrade. This is not always an easy evaluation and the amount of customizing you do will certainly drive this decision.  This is the so-called “solution gap” and you have to ask, is the solution gap large enough to justify the SAP release upgrade?  And since SAP upgrades are time consuming and usually complex, is it worth investing time, money and resources to address this solution gap with an upgrade?

Yesterday’s Technology

SAP systems need to be constantly customized and enhanced in order to support evolving business needs. The time will come when the installed instances will no longer be able to suit your needs.  Staying on the same release is unsustainable from an infrastructure point of view as you will be required to stay on older hardware, software, and O/S.  If you have systems with many external touch points, it becomes more difficult over time to keep these working, especially if you are running much older SAP software. [Read more...]

SAP Go-Live Lessons Learned

In real estate the key factors in making the sale are location, location and location.  In an SAP project I’m coming round to believing that success requires testing, testing and testing.

A Short Selective Retrospective on Key Constituencies

All project events and project success stem from testing and testing well.  I’ve written about various types of testing before and how that can lead to some confusion because of issues with definitions.  Here I want to discuss some areas where testing really can make or break a project and ideas for how to minimize the chances of things turning out badly. [Read more...]

SAP Mid-Month Go-Live: Got the T-shirt

Conventional wisdom says you don’t go-live with SAP financials in the middle of the month (strictly speaking I should say the middle of the accounting period, but I’ll say month as a generic term for the posting period).  I recently went through a mid-month SAP financials and logistics go-live and so far it has been a success.

Initially the project team had the expected you-can’t-do-that reaction when the idea of a mid-month go-live was suggested.  We took three main steps to determine whether or not we were crazy or had a viable go-live option:

  1. We asked SAP.  As one of the main participants on the project we got them to do an internal review with some platinum consultants with the objective of telling us why we could not go-live mid-month.
  2. We asked our project team, both client and consulting resources.  Again, the goal was to tell us why we couldn’t do it.
  3. We Googled like maniacs to find something to support and justify the conventional wisdom.  We failed to find anything substantial that would deter us.

Armed with the conviction that there was no reason we couldn’t go-live mid-month we set about defining the details of how we would pull it off.

[Read more...]

SAP Project Management Consulting Clichés – Part 2

Following my previous post I got a couple of responses from folks out on the interweb and decided I’d steal their suggestions and expand on their consulting clichés.  After all repetition and overuse are the start point for any cliché and this means I’m doing my part to sustain the cycle – reuse, recycle, renew!

Is Your Project a Hotbed of SAP Consulting Clichés?

I felt compelled to come up with a 2-by-2 matrix to help you decide whether your project is cliché generator or a cliché consumer.

[Read more...]

SAP Data Migration – The Data Migration Plan (Part 2)

If you are responsible for the success of data migration, you will want to build a detailed plan that will walk you through all of the three phases of data migration: pre-data migration preparation, the data migration itself, and post-data migration cleanup.  I like my data migration plan to contain detailed steps that ensure that I don’t forget anything.  Each step lists a specific named responsible person along with their area of responsibility and contact information.  Unless I am responsible for executing the task myself, I prefer the named person to be a client employee (i.e. the business owner of the process) rather than a project consultant.    This is where the responsibility should be, and it requires that the business process owners actually participate in the activity rather than sit on the sidelines and watch.

[Read more...]

SAP Data Migration – Answering the Important Questions (Part 1)

It is data migration time on your SAP business project.  Whether your project is implementation, acquisition, or merger, the goal is pretty much the same: the seamless inbound acquisition of master and transactional data from one or more external data sources while ensuring that this activity has minimal impact on the rest of the business.  This is where we attempt to move years of neglected master and transactional data from a loosely structured, anything-goes legacy system into a very tightly integrated and highly structured SAP system.  You must consider the likelihood that the concept of master data management had not been invented yet when the legacy or source system providing your data was implemented.

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!

[Read more...]

SAP Upgrades, Solution Manager, Test Plans, and Testing

In this entry I’ll pull together a few threads from previous posts (testing, documentation, upgrades and offshore development) and throw in some Solution Manager (SOLMAN) functionality.  These pieces can be fitted together to help accelerate a project and testing preparation via use of the SAP Test Workbench.

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.
[Read more...]

SAP Cutover Practice for Risk Reduction

SAP system upgrades, support packs, or data conversions into production can be a very stressful and time-consuming activity.  A good way to remove some of the negativity and gain confidence is for a ‘SAP Cutover Practice’ activity.  Although this does require additional hardware (at least temporarily), the benefits from this activity are well worth the cost.

[Read more...]

SAP Testing Preparation – Due Diligence

This entry sounds like project management 101 and can be summarized as: don’t assume because when you do… and you know the rest of that one.  The trick is to uncover your implicit assumptions, the explicit ones are easier to identify, whereas the ones lurking in your subconscious may only want to come out when they can trip you up.

[Read more...]