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.

In my previous post I discussed various types of testing and alluded to what each type entails.  Implicit in each of the test execution activities was the assumption that the necessary preparations were complete.  The testing you are doing will determine the kinds of prerequisite preparation work you need to do and there’s no escaping the need for some upfront work.

I always think there is a level of theoretical abstraction that goes with project management because in an ideal world you can imagine a mechanistic approach where you have your tasks and your deliverables and as long as you sequence them correctly your project will complete.  Reality has a way of distorting theory and throwing a few challenges into a project.  I’ve not worked on many (any?) large projects where a the timing and coordination of deliverable completion has been perfect, so every project has to make a judgment call on whether enough of each deliverable set is available to meaningfully support the next set of activities.

Enough of the theoretical abstraction: let’s discuss an example.  I once worked on a project where the team wanted to do some real world simulation testing, basically a day-in-the-life test (DITL) in a pre-production environment.  The testing was to include functional configuration, reports, automatically executing interfaces, end user security and authorizations, master data extracted and converted and loaded from legacy systems, and overnight periodic processing.  Unfortunately, certain aspects of the design weren’t complete–report specifications varied from non-existent to in-development; interface triggers had not always been included in the design and construction; no data conversion exercise had achieved more than ~60% success; and the batch scheduled had not been defined. So, aside from these shortcomings everything was good!

Any one of these issues in isolation could probably be managed and worked around during testing–after all, most of us can get by without a report for awhile, but in the end so many piece parts required for the DITL testing were incomplete that the testing was seriously delayed.  In many respects the project became a slave to the timeline and the quality of the deliverables was allowed to slide until this testing activity late in the project lifecycle.  A more thorough and dispassionate ongoing review of each of the components required for testing would/should/could have revealed their status and enabled a better deployment of resources to get the deliverables designed, built, and individually tested.  Instead the project went through a period of triage to assess which were in the worst condition, which would take longest to fix, and which dependencies existed between the parts.  The happy ending is that some weekend work and some dedicated brute force and intellectual effort resolved the situation.

The Takeaways

1. When you get parachuted into a project situation and you are told that you need to go execute an activity, take the time to layout your assumptions and push to get them validated.  It is far better to spend a couple of days on due diligence than having the situation implode all around you.
2. If the required parts are not complete, you need to make a judgment call on whether you can proceed with testing on a smaller scale, go ahead regardless, or wait until everything is ready.  Generally, I’d recommend testing whatever you can, but only if you are proving out something that hasn’t already been shown to work in an earlier type of testing.
3. If you proceed with testing before all the parts are ready, you need to build in iterations of testing – a kind of regression testing – to ensure that as each new finished part (code, configuration, etc.) is introduced it does not break anything previously tested.
4. Be prepared for increased overall project phase elapsed times when you have staggered completion of deliverables that need to be part of your testing activities.

Each project has its own language and the way people refer to the various kinds of testing is a potential source of confusion.  On a certain level it doesn’t matter what you call your various flavors of testing as long as everyone on the project uses the same terms and means the same things.

I have come across the same term used on different projects to mean different things.  My goal here is not to provide definitive definitions, although I will take a shot at some loose definitions, but to make the point that a common understanding of what you mean on your project is what counts.  Your project team (SAP and non-SAP team members) will be much better off as long as you speak the same language and mean the same things.

For example, when I say integration test you might think I mean the same thing as when you say end-to-end test.  On some projects we would be right to agree and on other projects we should disagree.  Consequently I have found that short capsule summaries of the various kinds of testing you do can save a lot of debate and frustration.  Of course these capsules are tricky because there isn’t always a black and white distinction between one kind of testing and another, so some mental flexibility is helpful, but don’t be too flexible.

In general the type of testing is tied to a project phase or system environment, but project phases and system environments can be a hot topic, too (and a subject of future blog entries).  Who does the testing provides an additional clue where it fits in the overall project lifecycle.  What follows are a few broad definitions of testing types that I use.  You can accept, refine or reject these but I hope the underlying message sticks: create usable working definitions that fit your project.  And remember not every project will need to perform every one of these types of testing.

A short checklist to review when thinking about each type of testing:

• What systems (SAP, non-SAP) are needed?
• What environments (development, QA, training, etc.) are needed?
• What data (master data, transaction data, and historical data) is needed?
• Who does the testing (development team, test team, end users, etc.)?
• What are the testing success criteria?
• How are results documented and able to be audited?
• What test cases (positive and negative) are required?
• Who provides sign-off?

Without further ado, some loose definitions:

SAP Unit Testing

This tests isolated pieces of functionality, for example, creation and save of a sales order.  The test is done in the development by a configuration specialist and confirms that the sales order can be saved using the SAP organization elements (sales organization, company code, credit control area, etc.) along with the customer master data set up, partner functions, material master data, etc.  It establishes a baseline of SAP functionality.

For ABAP development, for example, unit testing shows that a report can be created from developer generated data.  Assistance in data generation may come from a functional consultant.

SAP System Testing

This is testing where elements of related SAP functionality are linked together in the development environment to ensure the pieces work together.  For example, a quote-to-cash flow would show that a quote can be used to create a sales order, a delivery can be created and processed from the order, the delivery can be billed, the billing released to accounting, and a customer payment applied against the accounting invoice.  Each of the component parts is unit tested ahead of time and the data used in testing is usually fabricated based on the knowledge of the project team.

SAP Scenario / String Testing

this tests specific business cases.  For example, there may be configuration and business process design that is unique to a certain customer set or a given product line or a set of services. Tangible products and services are processed very differently from each other, so you might have different scenarios you need to test.  Again this testing is usually done in the development environment to prove out a requirement – an argument can be made to say this is a test case you would cover in system testing.  Scenario testing can also happen in the QA environment, but I prefer to call that string testing.

This testing also includes execution of interfaces and other development objects, e.g. reports, with fabricated data.

SAP Integration Testing

This testing is similar to scenario testing except it is typically done in the QA environment and uses more realistic data.  Ideally the data has come from a near real data extraction, conversion and load exercise (not necessarily a full conversion) so the data has a certain familiarity to it for a business end user, e.g. recognizable customers, materials, pricing, vendors, contracts, etc.  The testing shows that the business process as designed and configured in SAP runs using representative real world data.  In addition the testing shows interface triggers, reports, workflow are working.

SAP Interface Testing

Testing of interfaces typically occurs at different points in a project so it is important to know what you are testing when.  During the project development phase isolated interface testing usually refers to unit testing activities where you confirm that your code can consume a file of your own making.  You might have two development systems – one SAP, one non-SAP – where you run a test to show that the sender can generate a file and the receiver can consume it.  In the QA environment interface testing might involve execution of business transactions on the sending system followed by looking for automatic generation of the interface output; this is then followed by the receiving system consuming that file and proving that a business process continues on the receiver.  Your interface testing might prove that the whole process runs automatically with business events triggering the outbound interface correctly, automatic transfer and consumption by the receiver.

This testing and its definition can become even trickier if you use a message bus where the idea of point-to-point interfaces doesn’t apply and you need to consider publish-and-subscribe models.

Whatever you are doing under the guise of interface testing, you need to be clear about the scope of the tests and the success criteria.  Typically interface testing becomes part of larger testing activities as a project progresses.  In my experiences interface testing shows that the triggering works, the data selection (and exclusion) is accurate and complete, data transfer is successful, and the receiver is able to consume the sent data.  Wrapped around this is showing that all the steps run automatically and that error handling and restart capability (e.g. data problems, connectivity failures) is in place.

SAP End-to-End Testing

This is similar to scenario testing in that a specific business case is tested from start to finish and includes running of interfaces, reports, manual inputs, workflow, etc.  In short it is attempting to simulate a real world business process and, in order to make it as real as possible, it is done using the most realistic data.  Ideally the data used was the result of a data extract, conversion and load process.  I would expect this kind of testing to occur in a QA environment: at some level it can be seen as a way of validating that the individual unit tests, scenario tests, integration tests and interface tests produced results that work together.

SAP End User Testing & User Acceptance Testing

I grouped these two together because they are closely related, if not identical.  The goal here is to ensure that end users are able to perform their designated job functions with the new system(s).  A crucial part of this testing is referring back to the business requirements (you have some of those, right?) and blueprint to ensure that the expected features, functions and capabilities are available.  As part of the project user involvement along the way should have been providing feedback to ensure the design met the requirements, so there should not be any big surprises.

Again this is activity that usually occurs in a QA environment with realistic data and the inclusion of end user security and authorizations.

SAP Stress / Load / Performance Testing

This kind of testing examines things like whether the system response time is acceptable, whether periodic processes run quickly enough, whether the expected concurrent user load can be supported.  It also identifies processing bottlenecks and ABAP coding inefficiencies.  It is rare for a project to have worked out all the system performance tuning perfectly ahead and to have every program running optimized code.  Consequently the first stress test on a system can be painful as lots of little things pop up that weren’t necessarily an issue in isolated testing.

The testing is geared towards simulating peak loads of activity, either online users or periodic batch processing, and identifies the steps needed to improve performance.  Given that the initial test reveals lots of areas for improvement you should expect to run through this a couple of times to ensure the results are good.

SAP Usability Testing

This testing is usually concerned with how many key strokes and mouse clicks it takes to perform a function; how easy and intuitive it is to navigate around the system and find whatever it is that you are looking for.  In an SAP implementation using the standard GUI there isn’t much scope for this kind of testing: end user training shows how to navigate, how to create short cuts and favorites, modify screen layouts, etc.  On the other hand a project that involves building portals may well need to perform this kind of testing, not just for reasons mentioned earlier, but also for consistency of look and feel.

SAP Security and Authorizations Testing

Ensuring that users are only able to execute transactions and access appropriate data is critical to any project, especially with today’s needs for SOX compliance.  This testing is typically done in a QA environment against near-final configuration and data from a full extract, conversion and load exercise.  Test IDs for job roles are created and used to both confirm what a user can do and what a user cannot do.  More often than not this kind of testing is combined with end user or user acceptance testing.

SAP Cut Over / Dry Run Testing

This kind of testing is simulating and practicing certain major one-time events in the project lifecycle.  Typically the terms “dry run” and “conversion” together to mean a full scale execution of the all tasks involved to extract data from legacy systems, perform any kind of data conversion, load the results into SAP (and any other systems) and fully validate the results, including a user sign-off.  Most projects have several dry run conversions which progress from an exercise in capturing all the steps, checkpoints and sign-offs in data conversion to a timed exercise to ensure everything can be accomplished in the time window for go-live.  Once it becomes a timed event a dry run data conversion readily rolls into a cut over test, where it is one component of an overall cut over activity sequence: a cut over test usually ensures that all the necessary tasks, e.g. importing transports; manual configuration; extracting, converting and loading data; unlocking user IDs; starting up periodic processing for interfaces, etc. are all identified and can be executed in the go-live time window.

Application Testing

This term can be construed as so broad it has no meaning as an “application” can mean a lot of things.  I have only ever heard it as generic blanket term for another kind of testing, e.g. SAP application testing, so it needs to be refined and given context to be of use.

SAP Day-In-The-Life (DITL) Testing

This is one of my favorite kinds of testing – it really is what is says it is.  Run the system the way you expect it to be run during a regular business day.  Real users, real data, real volumes, real authorizations, real interface and periodic job execution – the closest you can get to a production environment before you go-live with the system.

Not every day in business is the same so you might want to run a few DITL tests.  However these can be difficult to organize because of the need to have end users trained and available for extended periods of time as well as having all partner systems able to participate in the activities with real and synchronized data across the systems, real users, real data volumes, etc.

SAP Regression Testing

Each time you put a new release of code and configuration into your production system you want to be sure you don’t cause any changes in any processing beyond what you expect to change.  Hence the role of regression testing: test your existing functionality to be confident it still works as expected with the newly updated configuration and code base.  Clearly you don’t want to find you have issues in production after you make the changes, consequently regression testing in a QA environment that has similar data to production is a good test bed.  In some cases automated testing can be effectively deployed as a fast and regular method to ensure core business processes are not adversely affected by new releases of code and configuration.

Conclusion

As mentioned earlier I don’t claim to have perfect definitions for all types of testing, but I believe it is worthwhile having good definitions that are commonly understood and communicated across your project.

Welcome to my SAP project management and project observations blog.  I’m Tim Cooper, an SAP FI/CO certified consultant with a lot of project management experience.  My goal with this blog isn’t to make you PMP certified or to address all and any project management issues you may have.  Instead I’m going to share some of my experiences from various projects – some good, some not so good – with the hope that you can make your project more successful.  At times I’m going write about subjects that will feel like it is project management 101, but I haven’t stopped being surprised by how often my assumptions have turned out to be incorrect and need to be reconfirmed.

I hope this blog is helpful to consultants and non-consultants: it should help you understand some of each others’ expectations and make working together a better experience for you both.

Let me know what you think, but please be civil.

Leveraging SAP to Improve A/R to Cash Flow Conversion Efficiency, Lessons Learned

In this economic climate, staffing levels are decreasing and at the same time customers are paying later than ever.  Historically, increasing cash flow used to mean adding collections personnel. This option is simply not available in today’s recession. Learn how enhancing SAP accounts receivables workflows will immediately improve your AR performance.

Key Learning Points:

1. How to increase customer touches without increasing headcount.

2. Increase cash flow by ensuring that collection events are optimized to maximize cash flow.

3. Measurements and reports to highlight at-risk customers, late payment trends, and other A/R metrics including enhanced cash flow forecasting.

Speakers: Tim Cooper – Senior Project Manager – DataXstream, LLC.

Tim has over 20 years of SAP FICO experience with an emphasis on accounts receivable, deductions & collections processes.  As a senior project manager at DataXstream he has deployed & supported A/R solutions at Textron Greenlee, Ferrero & Intradeco Apparel.  Tim brings project management experience and a hands-on perspective to engagements.  His experience also includes large complex SAP projects at companies as diverse as Lucent Technologies, Armstrong World Industries, and Bayer Corp.

Speaker: Chris Caparon – President – Cforia Software

Chris graduated from the University of Michigan in 1987 with dual degrees in Computer Engineering and Electrical Engineering.  After graduating, he worked for seven years with several large distribution companies in a variety of management roles.  His areas of experience include:  Accounting; engineering; manufacturing; materials planning; quality; and sales.  Chris began business consulting in 1994 to leverage his broad range of business process  knowledge and technical background.  Over the next six years, Chris ran a 20 person consulting, sales and programming practice that focused on implementing ERP applications and business process reengineering.  He successfully ran over fifty projects across multiple business models.  As a result of his extensive experience in ERP software systems, Chris decided to concentrate his efforts on the weakest element in these packages, AR management.  Chris co-founded Cforia Software in 2000 with the goal of providing a best of breed application that streamlined the credit, collections and deductions processes to generate cash flow and earnings.   He has successfully implemented over 75 customers that include Napa Auto Parts, Citizen Watch, Teledyne, Stryker Medical, Seiko Watch, Sunrise Medical, and Ashley Furniture.