Service Desk functionality is delivered as part of SOLMAN for use as a ticketing system.  One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already.  In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP.  Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes, which obviously reduces the risk of transcription errors.  And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management.

Here are some SAP Service Desk scenarios I’ve come across.

1. New SAP Installation

If you are a new SAP installation and have no ticketing in place Service Desk is a great place to start.  As mentioned the functionality available allows end users to create tickets directly from SAP and have workflow set up to manage ownership and eventual resolution.  Alternatively, a URL can be made available to allow trouble tickets to be logged via the SAP Service Desk web front end.

In this case end users and technical support personnel learn a new tool as part of their go-live experience.

2. Migrating Non-SAP System Support to SAP Service Desk

Rather than SAP being your sole IT application it is much more likely that you have an existing portfolio of systems and an associated ticketing tool and procedures for ticket management, escalation and resolution.  A conservative approach when bringing up Service Desk is to use it initially only for SAP related tickets and deploy a limited set of functionality.  This allows you to go through the growing pains and adjustments as you learn how to best make Service Desk work for you.

In the longer term migrating ticketing for non-SAP systems to Service Desk brings it all into one system.  Using the Service Desk capability to create custom components and to build an organization structure that fully supports your users and systems facilitates consolidated reporting and the ability to monitor Service Level Agreements (SLA).

This approach works best if you have a fairly simple environment where the level of disruption is limited when decommissioning an existing ticketing.  The impact on people, process and technology is carefully managed and the working environment has some tolerance for the time if and when things aren’t quite as expected at first.

3. SAP Service Desk Integration with an Existing Ticketing System

In situations where there is a well established ticketing system, it is unlikely that that system will be easily displaced by SAP Service Desk—and it may not make sense to do so.  In this situation you can choose to not use Service Desk and forgo the system capabilities and instead use the existing ticketing tool to manage SAP issues.  This gives up a lot of delivered SAP Service Desk capability.

Alternatively you can integrate the existing ticketing system and Service Desk and reap the benefits of both worlds.  In this case you need to decide which system is the primary ticketing system and which is the secondary.  DataXstream has worked with CA (formerly known as Computer Associates) to integrate the CA Service Desk offering with SAP Service Desk and now CA delivers a packaged solution for this integration.

3.1 SAP Service Desk is the Ticket Initiator

In the scenario where the SAP Service Desk (SAP SD) is primary tickets are initiated in SAP SD and categorized either as SAP related or as non-SAP related.

SAP related tickets are managed to resolution in SAP SD, including any communication with the SAP mother ship, and the secondary ticketing system, e.g. CASD, receives only informational updates on ticket progress, if required.  The complete ticket lifecycle is managed and closed in SAP SD.

Non-SAP related tickets are transferred to the secondary ticketing system, e.g. CASD, where they are worked to their resolution.  In this case ticket status changes and informational updates all occur in CASD and these updates are relayed to SAP SD.

In either case SAP SD and CASD can have a full picture of the ticket status throughout its lifecycle, the main difference being which system “owns” the ticket and has responsibility for working it and closing it out.

Overall the established ticketing system continues its original function and ticket resolution process, the key change being where a ticket is initially created.

3.2 SAP Service Desk is NOT the Ticket Initiator

In the scenario where SAP SD is the secondary ticketing system SAP-related incidents originate in the primary ticketing system, e.g. CASD, and are relayed to SAP SD.  Now the SAP related incidents are worked in SAP SD where ticket information can be supplemented with all the SAP unique information that would be useful for analysis and investigation.  Similar to the earlier scenario any significant status or informational updates in SAP SD are relayed to CASD and the ticket is ultimately closed out in SAP SD.

Any non-SAP related tickets are not sent from CASD, for example, to SAP SD.

Summary: A Natural Progression: from Island to Integration

SAP Service Desk can be deployed in a variety of ways in an organization: it can be a standalone ticketing and support system; it can be fully integrated with existing support applications.  The role played and the pace of adoption is very flexible and is driven by an organization’s ability to manage the change and adopt new tools and procedures.

The general progression I have seen it to bring up SAP Service Desk as a standalone tool and then after a settling in period one of two things happens:

• Existing ticketing tools and functionality are migrated into Service Desk
• SAP Service Desk is integrated with another ticket management tool

In either case the outcome usually allows SAP related tickets to be created directly from SAP in order to capture as much detail as possible at the time of the incident.

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.

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.

Here’s a chart to gauge your progress

This is your guide to see if your project vernacular has made it to cliché status or is too localized for such weighty titles.  The matrix should be self-explanatory, and if it isn’t, then it isn’t much of matrix.  But let’s cover the bases and check we’re all working off the same playbook:

• If the phrase is only used by a few people on your project you’ve got yourself a clique but you haven’t got a cliché
• If the phrase is in widespread use across your organization but strangers check for their keys and wallets when you say it in public you’ve got tribal knowledge and a clear boundary between understanding and bafflement
• If the phrase is used in lots of projects but only by a select group – perhaps those geeky developers who speak something that sounds like a cross between Fortran and Klingon – you’ve got the beginnings of a cult going on (I appreciate you geeks, but I’m not sure my mother wants to meet all of you)
• If you hear the phrase everywhere and everyone knows what it means you have achieved nirvana: cliché status is yours to behold!  Jolly well done, splendid, attaboy!

What Does That Mean?

Here is a handful clichés submitted to me recently along with a short explanation of what I think they really mean.  If these aren’t familiar please do you best to over use them so that they do become clichés.

9 women can’t make a baby in a month

Translation: You have critical path issue on your project.  Assigning additional resources to the task isn’t going to help.  Better resources, perhaps.

This is an aggressive timeline

Translation: Get ready to develop a new plan.  An aggressive timeline usually assumes perfect execution, code is good, configuration is good, users are trained, security and authorizations are good, interfaces are good, master data conversion is good, transactional conversion is good, backup and restore is good, and everything works together flawlessly, without a hitch.  Or at least it will once we get through this exercise with no, well maybe minimal errors and rework.

This doesn’t work the way the old system does

Translation: I agree, it doesn’t work the same way as the old system.  It’s SAP and it works differently.  If it was supposed to work the same way as the old system it wouldn’t be SAP.  Now tell me again, why did your company choose to implement SAP?

That’s not what I wanted

Translation: But it is what you asked for.  In defense of the speaker I think it is very difficult to describe what you want in a clear and complete manner and very few people are good at distinguishing between what they want and how they think it should be delivered and operate.  Nonetheless on ERP projects there is always a tendency to want to make that Buick into a Bentley despite the fact that both vehicles can get you to your destination.

This is working as designed

Translation: The design is broken.  A fork is a good implement for eating some foods, but not all foods.  Is a spork the result you were looking for?

Let me get back to you on that

Translation: a) I have no clue, b) let me look on http://help.sap.com, c) I don’t understand what you’re asking, d) that makes no sense to me, e) why would you want to do that?  But seriously, this is consultant speak for I have no idea how to answer that question.  The good consultants figure it out and get back to you whereas the bad ones just hope you are too buried to remember to ask that question again.  You know pretty quickly whether you have good or bad consultants.

The End of a Humorous Interlude

I hope I managed to bring a smile to your day as you read this and the previous post – perhaps your assistant printed it so you can read it on the plane as you fly home from another week of project execution optimization driven by paradigms harnessed by unconventional quantum leaps into new challenges that seek to maximize ROI.  That won’t be a cliché any time soon, but the individual components are probably already active on a project near you.

Thanks for indulging me.

Service Desk functionality is delivered to you for use as a ticketing system.  One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already.  In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP.  Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes which obviously reduces the risk of transcription errors.  And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management.

Here are some SAP Service Desk scenarios I’ve come across.

New SAP Installation

If you are a new SAP installation and have no ticketing in place Service Desk is a great place to start.  As mentioned the functionality available allows end users to create tickets directly from SAP and have workflow set up to manage ownership and eventual resolution.  Alternatively, a URL can be made available to allow trouble tickets to be logged via the SAP Service Desk web front end.

In this case end users and technical support personnel learn a new tool as part of their go-live experience.

Migrating Non-SAP System Support to SAP Service Desk

Rather than SAP being your sole IT application it is much more likely that you have an existing portfolio of systems and an associated ticketing tool and procedures for ticket management, escalation and resolution.  A conservative approach when bringing up Service Desk is to use it initially only for SAP related tickets and deploy a limited set of functionality.  This allows you to go through the growing pains and adjustments as you learn how to best make Service Desk work for you.

In the longer term migrating ticketing for non-SAP systems to Service Desk brings it all into one system.  Using the Service Desk capability to create custom components and to build an organization structure that fully supports your users and systems facilitates consolidated reporting and the ability to monitor Service Level Agreements (SLA).

This approach works best if you have a fairly simple environment where the level of disruption is limited when decommissioning an existing ticketing.  The impact on people, process and technology is carefully managed and the working environment has some tolerance for the time if and when things aren’t quite as expected at first.

SAP Service Desk Integration with an Existing Ticketing System

In situations where there is a well established ticketing system it is unlikely that that system will be easily displaced by SAP Service Desk and it may not make sense to do so.  In this situation you can choose to not use Service Desk and forgo the system capabilities and instead use the existing ticketing tool to manage SAP issues.  This gives up a lot of delivered SAP Service Desk capability.

Alternatively you can integrate the existing ticketing system and Service Desk and reap the benefits of both worlds.  In this case you need to decide which system is the primary ticketing system and which is the secondary.  DataXstream has worked with CA (formerly known as Computer Associates) to integrate the CA Service Desk offering with SAP Service Desk and now CA delivers a packaged solution for this integration.

SAP Service Desk is the Ticket Initiator

In the scenario where the SAP Service Desk (SAP SD) is primary tickets are initiated in SAP SD and categorized either as SAP related or as non-SAP related.

SAP related tickets are managed to resolution in SAP SD, including any communication with the SAP mother ship, and the secondary ticketing system, e.g. CASD, receives only informational updates on ticket progress, if required.  The complete ticket lifecycle is managed and closed in SAP SD.

Non-SAP related tickets are transferred to the secondary ticketing system, e.g. CASD, where they are worked to their resolution.  In this case ticket status changes and informational updates all occur in CASD and these updates are relayed to SAP SD.

In either case SAP SD and CASD can have a full picture of the ticket status throughout its lifecycle, the main difference being which system “owns” the ticket and has responsibility for working it and closing it out.

Overall the established ticketing system continues its original function and ticket resolution process, the key change being where a ticket is initially created.

SAP Service Desk is NOT the Ticket Initiator

In the scenario where SAP SD is the secondary ticketing system SAP-related incidents originate in the primary ticketing system, e.g. CASD, and are relayed to SAP SD.  Now the SAP related incidents are worked in SAP SD where ticket information can be supplemented with all the SAP unique information that would be useful for analysis and investigation.  Similar to the earlier scenario any significant status or informational updates in SAP SD are relayed to CASD and the ticket is ultimately closed out in SAP SD.

Any non-SAP related tickets are not sent from CASD, for example, to SAP SD.

A Natural Progression: from Island to Integration

SAP Service Desk can be deployed in a variety of ways in an organization: it can be a standalone ticketing and support system; it can be fully integrated with existing support applications.  The role played and the pace of adoption is very flexible and is driven by an organization’s ability to manage the change and adopt new tools and procedures.

The general progression I have seen is to bring up SAP Service Desk as a standalone tool and then after a settling in period one of two things happens:

• Existing ticketing tools and functionality are migrated into Service Desk
• SAP Service Desk is integrated with another ticket management tool

In either case the outcome usually allows SAP related tickets to be created directly from SAP in order to capture as much detail as possible at the time of the incident.

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.

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.

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.