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.

SAP Testing with Project Team Members

Unsung heroes abound on SAP projects and your client’s key business analysts can be fabulous participants or sacks of rocks you have to carry everywhere for no apparent benefit.  Always choose the former or trade up if you discover you got the latter. Engaged business analysts are great when they bring business knowledge, a willingness to learn SAP, insight to the hot-button, day-to-day issues and the understanding that the consulting team may know a lot, but not necessarily everything.  Partnership between consultants and business analysts can be very fruitful at teasing out mainstream, what happens 90% of the time, business scenarios and building coherent test cases.

These key project team members can provide a sanity check when you try to bring prior experiences and findings from other clients to the project.  A crazy design you built on the last project may not be relevant here and your BA can save you from any tendency to over engineer a solution.  Conversely, your BA might be the one who sets you down the path to an unusual design.  Either way, it has to be tested and between you and the BA the bases should be covered.

I’ve found that the BA’s on a project are usually there for one of two reasons: either a motivated high performer with knowledge and credibility; or someone found the SAP project was a place to dump a personnel problem.  Fortunately, the latter is rare these days as more and more people turn into high performers out of necessity.  Consequently, your BA is going to know key areas of process and functionality that must work for the project to be a success and he/she drives you to deliver.  Never be afraid to let a BA talk about the business, what it needs to be able to do and what needs to be tested.

However, the BA probably isn’t going to be using the system as an end user on a day-to-day basis and can only get you so far with the completeness of testing.  This is where you need to branch out from the immediate project team and into the realm of the end user.

SAP Testing with End Users

In an ideal world, the systems we build would be foolproof, but there are some smart fools out there and they don’t always behave the way we want them to.  As you probably know, SAP is not the most intuitive system to navigate and use (would an overhaul of the GUI make system adoption quicker and easier?) and people don’t always do what they are told.  I know you are shocked to hear this!

If I had a lot more time on my hands I’d love to watch people using systems and seeing all the various ways people try to do things.  It’s a fairly dopey example, but I’m one of those mouse-and-menu people when I use MS Office.  The ALT, CTL, and SHIFT keys are a tiny part of my repertoire because I learned how to use these products a certain way, but I know some people who do almost everything with keyboard shortcuts.  I can scarcely follow how they do things, although I can see what they are doing.  The fun is seeing different ways to achieve the same end.  SAP is a bit like this in that there are different ways to approach a task: using menu paths; transaction codes; single session; multiple sessions; favorites list entries; and different entry points to get to data.  Unless you have really nailed down tightly how to execute tasks users will eventually find all possible ways, but more importantly, without nailing it down users will find ways to do it wrong and not realize it.  This is a potential disaster in the making.

Despite the best intentions of project team members (business analysts, consultants, trainers, supervisors) end users will use the system in ways you did not anticipate.  After all, the way you use the system works brilliantly, so no one would think to do it any differently, would they?  Except, they do use it differently.

Including a round or two of real end user testing on the QAS system is probably going to be quite revealing.  Ideally, after a dry run conversion and before going live you want to let loose on the system and do some serious day-in-the-life and periodic processing.  And you want to back off on your desire to hand hold.  This way you can see how a user actually uses the system, the steps they take when they get into trouble, and what they try to do as corrective actions.  The intuitive and natural screen flow you came up with?  Perhaps its not as intuitive as you thought.

Here’s the point: carving out time in a project to involve end users in testing is invaluable.  Initially they will stick to the script but after a short time they will extemporize and that is when you find out if you built a robust system that guides people down the desired path or a mess that allows mistakes and the attendant downstream problems.

It is better to take the time before you go live to ensure you don’t get downstream problems than to discover the chaos in production.

SAP Testing to Make Executives Happy

A final group of people with a vested interest in SAP project success is the executives.  These are rarely the folks who execute transactions on a daily basis; at best they might run a financial statement or a flash report of some description.  Nonetheless, these people along with departmental heads need to feel confident that the system works in an abstract way: a little like the way you know the engine in your car is working although you don’t really understand how all the various components fit and work together.  You’re pretty upset when the car won’t start, or the heater blows hot and cold intermittently, or you can’t tell if you have an almost empty gas tank.  Similarly executives get upset if they can’t get information that is important to them or they are unable to complete key tasks: for example, flash reports that don’t run or give “funny” numbers, not being able to close an accounting period.

These executives can be especially challenging to a project because they have so many things to worry about that they may only truly pay attention to an SAP project during times of crisis or around go-live.  At earlier times in the project life cycle they may have deferred to the PMO and existing management structure, but at crunch time things change.  Consequently, a conscious effort to find out from them what they need in order to feel comfortable with the system is critical: discovering what they need their organizations to do is critical.  Once you know what they want you can build it into project test plans and activities and show success.

This is one constituency that might be late coming to the party but you can’t ignore them or chastise them for tardiness – they are probably paying the bill!

Key Ingredients for SAP Success: Testing, Testing & (You Guessed It) Testing

It is stating the obvious (a core competence of mine) to say that an SAP project is a complicated endeavor.  I’d say there are no easy projects, only less difficult ones and testing is one of the most difficult areas to do well.

There are groups who judge testing success in different ways and with varying degrees of thoroughness.  A corner cut here and there might be acceptable, but too many cut corners and it all unravels.  By identifying key constituencies, identifying their needs, building test plans and strategies to address those needs, and executing against them greatly increases your chances of overall success.  And, if you do it right, you ensure their involvement and make them accountable for the results.

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.

Conventional Wisdom: Why You Don’t Go-live Mid-Month

My big disclaimer is that each SAP project has unique characteristics and what worked for us may not work for you, nonetheless I encourage you to keep an open mind and push until you find your insurmountable barrier, if it exists.  I would even contend that one of the biggest barriers may be your most experienced project team members and their gut reaction.  I admit my first reaction to the suggestion was “NO,” but as we drilled into the specifics of our project my inchoate objections crumbled.  The conventional wisdom is typically grounded in truth and experience, but conventional wisdom only applies to conventional situations.  To use a consulting cliché: challenge your assumptions.

In our research we found a consensus that there are three main areas that make a mid-month cut-over a bad idea.

Assets: I’m no expert on assets but the general word was that depreciation gets “messed up” if you cut over mid-month.  Owing to my limited experience in this area I’ll take that on faith, but this was not considered an issue as assets was out of scope for our project and asset postings will be done by journal entries.

Payroll: Again, I’m not an expert on payroll, but this was another situation where payroll was out of scope as the process is outsourced to a third party provider and journal entries are posted instead.  It was not considered a show stopping concern.

Year-to-Year Period comparisons: by cutting over mid-month some folks on the interwebs expressed concern that the month-over-month comparison for the go-live year would be no use until the third year.  Let’s say you go-live in the middle of June 2010 with partial balances in SAP (the remainder being in the legacy system), when June 2011 comes around you can’t compare the two Junes because one month is partial and one is complete.  You have to wait until June 2012 for a meaningful comparison.  This was not an issue for us because we converted three prior fiscal years of account balances with the go-live month balances being the balances as of the go-live date along with the transactional activity for the rest of the month.

Factors Leading to an SAP Mid-Month Go-Live

The ugly truth is that we went live mid-month out of necessity, not by choice.  Our original plan was to go-live on the first of the month, but we weren’t ready and a focused re-planning exercise identified that we could go live three weeks later.  Changing the go-live date to the first of the next month was not acceptable for a variety of reasons, including political considerations – it’s never a purely technical decision, so no surprise there.

Adapting the SAP Go-Live Strategy for Mid-Month Cut-Over

Once we knew we were going live mid-month we had to work out how to handle key areas of functionality: particular areas of interest were open A/P items, inventory balances, customer deposits, and the GR/IR account.  On top of this historical account balances needed to be loaded and we needed to ensure that FI conversions reconciled with logistics conversions.

Finance and Logistics Reconciliation

We came up with an approach that allowed us to readily identify differences between account balances converted by FI compared to the conversion by MM.  Consider the example of inventory conversion.

Standard SAP postings for the initial inventory balance with movement type 561 post to a pair of accounts similar to these:

• DR Inventory (135010)
• CR Conversion account (399175)

Instead of making this posting we changed the account determination for MM conversion to post as follows:

• DR Inventory (135010)
• CR Inventory conversion (135011)

Now when we converted historical balances into FI the inventory posting was:

• DR Inventory conversion (135011)
• CR Conversion account (399999)

The benefit of this approach was that any balance on the 135011 account meant there was a difference between what was converted via MM and via FI.  This became the basis of the work list that had to be reconciled.  The actual operational G/L account for inventory (135010) could be used immediately after the go-live without worrying about it becoming part of the ongoing reconciliation process.

Also, standard SAP does not allow direct posting to the inventory account (135010) and this approach allowed us to leave it as delivered.

We used a similar process, i.e. a conversion account instead of operational account, to support the cut over for accounts payable, customer deposits and the GR/IR account.

GR/IR Conversion

In our environment we are fortunate to have a situation where invoices are not received before the goods.  Consequently at the time of conversion there were purchase orders where goods have been received and not invoiced.  The typical GR/IR process is as follows:

Goods Receipt:

• DR Inventory (135010)
• CR GR/IR (211200)

Invoice Receipt:

• DR GR/IR (211200)
• CR Accounts Payable

At the time of conversion the good receipt has already happened and we did not want to reconstruct the PO processing so that we could use MIRO processing when the invoice is received.  Instead we converted historical balances for the GR/IR account by posting to a new account, 211201 as follows:

• DR Conversion account (399999)
• CR GR/IR conversion (211201)

Now when the invoices are received they will be posted with an FB60 transaction as follows:

• DR GR/IR conversion (211201)
• CR Accounts Payable

We know we are giving up some integrated capability for a period of time until these purchase orders and invoices wash through the system, but it means that once the GR/IR conversion account gets to zero we are done.  The typical life cycle for PO is 6-8 weeks so this is a temporary situation.  The true GR/IR account, 211200, will be used as intended and the benefits of MIGO and MIRO processing will be realized.

Month End Processing in the Old System

Going live mid-month also meant that the prior period was closed in the old legacy system and the month end balances were converted over in the same way as any other period.  It was a straightforward extension of our process to pull the mid-month account balances from the legacy system during go-live weekend and load them into SAP, too.

Financial Statement Impacts

The approach that we took meant we introduced several accounts to the chart of accounts for conversion only.  Consequently we had to update our financial statement versions to include these accounts and assign them to the correct positions in the report structure.  Clearly this is not a difficult task, but one that is needed.

SAP Mid-Month Go-Live Conclusions

I am skipping over some of the detailed considerations of how we made a mid-month go-live work for our project.  The details of how to make it work, the nuts and bolts of reconciliation, how we tested it (iteratively!), how we worked the differences identified between FI and MM/SD conversions, etc. aren’t here.  It wasn’t always easy and we had to do it in a short amount of time, but my key message is that we found a way to do it: the conventional wisdom wasn’t and isn’t necessarily wrong, just we found another path.