At DataXstream, we create tailored solutions for SAP Retail that give retailers tools which allow them to capitalize on the retail revolution and achieve success in today’s business environment.  Our dedicated team of Retail-focused SAP experts, with specialties ranging from technical and functional implementation to custom configuration and strategic project management, enables our customers to realize the full potential of SAP Retail’s highly flexible, configurable, and powerful solution toolset.  Whether you are a food, hardline, or softline retailer, Dataxstream can help you achieve operational and supply chain excellence with your SAP Retail system.

I have been working with SAP for over 15 years.  This was my first SAP Retail project and once again SAP has proved to me that it can be successfully leveraged and become a competitive advantage for those companies that implement it.  Each time I start a new project in a new industry I think about the vast differences in how the new company will need to leverage SAP and the challenges that unique business will create for the SAP application.  Time and time again a reasonable solution path is achieved and SAP becomes a solid foundation from which the business operates.  The diversity of my own personal experience working with successful SAP customers demonstrates this point.  There are not a lot of similarities in how A Flooring Retailer, Rocket Manufacturer, Pharmaceutical Manufacturer operate, yet they are all very successful at leveraging SAP.

Project Background

A little bit about my background in SAP Retail.  I have played quite a few roles over the last 2 years.  I have been an Infrastructure Architect (Design Of Virtual SAP Landscape), Development Lead (Initial Implementation), Stabilization Lead (Post Go-live), and SAP Program Manager (2 Physical Inventory Projects, Implementation Of Canadian Operations, POS (Point of Sale) Redesign, and Store Receiving Redesign).  Through these various roles within this project I have learned some very important new lessons as well as proved out ones I already new.

Lessons Learned – Too many to fit in one post

I would like to break down my lessons into the various phases of the project, from start to finish I think there are valuable lessons to be learned.  I will start with a lesson learned that applies to all aspects of the project and you will most likely think “thanks captain obvious for pointing this out”.  Rule #1 – Apply Common Sense in all decisions you make and look to see that other decision makers are doing the same.  Yes this is obvious but more often then not common sense is not applied.  I will reference this theme as I point out specific lessons learned.  Many of my lessons learned apply to all SAP projects or any project in general.  I will try and highlight lessons that I feel are specific to a retail.

In order to keep this post manageable I am going to break the lessons learned up into a series of posts.  I will add a new post each week until I have covered all the areas that I think are important to cover.  So lets start with project resources.

Consulting Resources

• Eliminate Under-Performers Quickly – I personally am not very good at this.  It is in my nature to look to try and help develop an individual to be successful.  However when it comes to consulting resources, career development does not apply on a project team.  We had several resources (not on my team) that did not have the skills and/or could not keep up with the pace.  We worked around them instead of eliminating them.  DataXstream did have a contract resource we brought on to my team and within a couple weeks we could see that he had interviewed better than he executed.  It is never easy to say we made a mistake to the client but we did and we replaced him.
• Cheap Resources Are Not Always Cheap – You could also reference the lesson above because it usually applies here.  However decision makers managing budgets tend to try and make the numbers work instead of ensuring they have the right people or are doing the right thing.  If a resource does not have the skills, drive, attitude or lacks all of these then it does not matter if the numbers look good in Excel.  This is a common thread to all SAP projects.
• With Free Resources You Get What You Pay For – There are many free resources that consulting firms provide that add real value.  However it is important to recognize that not all do and some provide negative value.  Free + Negative Value = Expensive.
• A Good (Non-Retail Experienced SAP Resource) is Better Than A Bad (SAP Retail Experienced Resource) – An SAP Retail System is 95% the same as any other SAP system.  Yes, there are differences. A good resource will have worked in a divers set of industries in the past.  They will pick up retail differences.  A weak resource with Retail experience will continue to be a weak resource.

Here is an outline of my future lessons learned post topics:

• Week 2
• Client Resources - There Are Never Enough Client Resources
• Planning - Establish Planning Rules That All Decision Makers Agree To And Then Follow Them

• Week 3
• Design - If It Is Hard or Complex You Most Likely Are Taking The Wrong Approach

• Week 4
• Execution
• Basis - Size Does Matter
• Configuration - Prototype And Prove Out Approach Before You Commit To Process
• Development - RICEFW Can Not Be Developed In Silo’s

•  Week 5
• Testing - Testing Design Is More Important Than Solution Design
• Go-live Planning & Execution - Have An Implementation Methodology That Tests Your Go-live Plan As You Go
• Go-live - Big Bang Not A Good Idea For  An SAP Retail Implementation (Without A Pilot)

• Week 6
• Post Production Support - Figure This Out Prior To Go-live

Hope you have enjoyed this post and I will see you next week.

Discovering Direct Modifications of SAP Standard Objects – One Example

As I discussed in a previous post on this topic, direct modification of SAP standard objects within the SAP namespace carries a high risk in an upgrade project.  It would be very valuable to be able to identify some details about these objects, so that further analysis could be performed to determine their disposition in the upgrade.

Modification of standard SAP objects typically requires that a modification registration key be obtained for that object from the SAP SSCR facility.   The SSCR facility (SAP Software Change Registration) is a procedure which registers all manual changes to SAP sources and SAP Dictionary Objects.  With a valid and authorized OSS ID for an SAP system, you can go to the SAP Support Portal on the web and view the SAP objects that were registered for modification by that OSS ID.  If there are multiple OSS IDs for any SAP system, make sure that you check all of them to capture all objects registered by all of the authorized OSS IDs for an SAP system.  Press the “Objects Registered by Me” button to view a list of the registered objects.

Another place that you can look for this information is directly within SAP.  Table ADIRACCESS stores the registration keys which were obtained from SAP, and which were entered by the developer when the object was to be modified for the very first time.  This entry shown below from table ADIRACCESS shows that function group SCPRPS was registered with SAP for modification.

Registering an object for modification does not mean that the object was actually modified.
What additional evidence can we discover that would show that the object was, in fact, modified?   And, since a function group contains many objects, can we determine exactly which object or objects were modified?

With a little bit of forensic analysis, we can discover the specific object within the function group that was modified, the user name of the programmer who last modified the object, date of the last modification, and the line-by-line source code differences.

If you are familiar with the structure of function groups, you already know that they may contain many function modules, and that the source code for each function module resides within its own include file.  At the moment, we know that the function group name is SCPRPS, but we do not have the list of function modules within that function group.

To obtain that list, we can use the SAP function module FUNCTION_SELECT_TFDIR.
The result list is shown here:

So which, if any, of these has been modified?  To determine this, we need to find all of the rows in table TRDIR where the NAME field is equal to the PNAME entries listed above.

Here is an excerpt from SAP table TRDIR for SAP object names that begin with the characters LSCPRPSU:

Note that for all of these objects, which are not in the customer namespace, the Author Username field (TRDIR_CNAM) is ‘SAP’.  Also note that for most of the entries listed here, the Last Changed By user name field (TRDIR_UNAM) is also ‘SAP’, except for one row, where the Last Changed By username field is not ‘SAP’.  From this row, we can see that include file LSCPRPSU36 was last modified by user DXSDEV on 10/19/2009.

If we look back at the result list of FUNCTION_SELECT_TFDIR and find the row where the field PNAME is equal to LSCPRPSU36, we can see that the name of the modified function module is SCPR_PRSET_CT_IMPORT_INDUSTRY.

Exactly What Changes Were Implemented?

By going to the Version Management Utility for this function module, we can see what the various versions of the code contained.  The Version Management Utility will also show us the transport request numbers, date and time, and username for each version of the code.  The Version Management Utility also has a code comparison tool which will highlight the line-by-line differences between versions of the source code.

Here is an excerpt from the side-by-side source code comparison utility which shows the modified version on the left side and the original version on the right side.  Fortunately, in this instance, the programmer left excellent notes indicating that a correction instruction from an OSS note was being applied.

What Are the Discovery Possibilities?

The manual example described above showed how to discover and analyze customizations that had been applied to a single SAP standard object.  But what if the customizations number in the hundreds or even thousands?  What about all of the customizations that were built entirely within the customer namespace?

It is possible to discover hundreds or even thousands of customizations regardless of which namespace they were developed in.  The key is automation, understanding that this information already resides within SAP waiting to be discovered, and more importantly, understanding the meaning of the discovered information.  I have already developed an ABAP discovery program which will mine, analyze, and report data about the following customized objects:

More Discovery – Usage Statistics and Where-Used

Customization Usage Statistics

The goal of customization usage statistics analysis is to discover the usage frequency of customized objects.  The usage discovery may show usage anywhere from several times daily by key users, to none when analyzed over a long time period.   Since most companies really do not want to incur the cost and the risk of moving an unneeded customization into the upgrade system, objects which show no usage over long periods of usage history become targets.  Care must be used here, as some transactions are exercised only quarterly, semi-annually, or annually.  I always recommend letting the business process owner make the final decision to eliminate any customization object in the upgrade.

SAP keeps track of usage statistics, and this data is available for you to analyze.  You will need to check what facility is available for your particular SAP system, as the transaction codes and programs differ among various versions of SAP.   The amount of data stored within SAP is configurable, and is usually set to a small date range.  Some companies that want to analyze the statistics over longer time periods actually download and store the statistics data in their own external databases.

Customization Where-Used

Like usage statistics, the goal of customization where-used analysis is to discover customized objects that are orphan or not being used.  What about that custom data type that is not used in any table or structure?  What about that function module that shows an empty list when you click the where-used icon in the function builder?

To properly perform a where-used analysis, it is important to understand all of the various possible uses for an ABAP object.  For example, here is the selection screen of possible uses that is presented by the ABAP Dictionary when you click the where-used icon to determine the where-used list for a data table:

And what about that custom function module, which I alluded to earlier, which shows a completely empty where-used list?  Perhaps it is a remote-enabled function module that was installed by, and is currently being called by an external third-party package.   Or, perhaps it is linked to an SAP EDI inbound or outbound process code.  It is really important to be able to properly interpret the data being presented and to not draw any hasty conclusions.

ABAP Programs Where-Used Analysis Example

In the ABAP workbench, SAP provides a where-used facility, which reports the various areas where a single selected object is used.  For a discovery project, you may want to automate this facility to analyze groups of ABAP objects (e.g. all custom ABAP programs, all custom tables, etc.).

Here is an ABAP programs where-used analysis example to help illustrate how a where-used analysis might be utilized.

Your automated where-used analysis program to analyze custom ABAP programs reports fifteen custom programs which show no usage in any of the following areas:

A quick analysis shows that all of these fifteen programs are simple reports.  Since users typically execute their reports via transaction codes, you wonder how these fifteen programs could ever possibly be executed without transaction codes.

You further analyze the SAP job scheduler data as far back as possible and find that only ten of these ABAP programs were ever scheduled in a batch job.  Some of these were scheduled very recently, and some have not been scheduled for a long time (another thread of evidence that we will need to pursue).  This leaves five ABAP programs with no apparent means of being executed.

As further evidence, you perform a cross-check against the usage statistics report and find that two of these five ABAP programs show no usage.

Armed with this analysis, you are now ready to meet with the business process owners to discuss the disposition of the objects on your short list.

A salient point here is that you will need to gather your evidence from several different analysis sources to help paint the most accurate picture about the possible disposition of customized objects.

Summary

Throughout all three parts of this post, I have stressed that customizations, while necessary, add risk and cost to an upgrade project.  And customizations that are not necessary or built poorly without the constraints of best-practice controls can add high levels of risk and cost.  Here are some general guidelines to follow:

Many companies and their auditors consider a well-controlled and secure ERP system to be a fundamental component that is vital to the success of the business.   They recognize that an out-of-control ERP system can easily paralyze a company for extended periods of time.  With this in mind, implement and enforce best-practice controls and standards to make sure that future customizations are reviewed, approved, built, tested, documented, and implemented properly.  This may already be an internal or external audit requirement, so check with your inside and outside auditors to make sure that your controls meet the auditing requirements.

Periodically review, audit, and amend your best-practice controls to make sure that they are still effective in supporting the needs of the business; and that both internal staff and external consultants are in compliance of these controls.

Know your customizations.  Know where they are, why they are, and what they do.  Whenever feasible, it is most efficient to eliminate ABAP object customizations, especially any that were performed within the SAP namespace, and any that are not really needed because they can be implemented within standard SAP.

The degree of risk and cost depends on the specific type of customization that was performed.  Establish a formal review board to own the customization approval process.  Understand that approving a customization also means approving the risk and the cost burdens.  Some companies consider this to be so significant, that they include a high-level business executive as a default member of the review board.

Set and enforce a policy making ABAP object customization the last resort, only after all other options have been thoroughly researched and exhausted.  Here are some examples:

1. Research forums, blogs, become active in user groups, etc. to see how other companies might also be implementing the business function that you require.
2. Find and use customer and user exits instead of directly modifying objects in the SAP namespace.
3. Determine, for example, how to implement and maintain that complex pricing procedure using the pricing condition tables instead of writing custom code and building custom tables.

Share Your Experience.

Once again, I look forward to hearing from our readers to reply to this post with their own experience with customizations, best-practice standard and policies, and success stories illustrating how your company transitioned to best-practice controls.

[Editor's Note] This blog is third of a multi-part series:

1. Part 1
2. Part 2
3. Part 3

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.

SAP service desk is usually getting introduced in an environment in where an existing Third-party Service Desk is already in use.  Because of this, companies need to make a decision on how they will integrate SAP Service Desk with their existing Third-party Service Desk.

In this blog, I will describe Service Desk integration scenarios and DataXstream’s involvement in the Service Desk integration space.

Scenarios of how companies can introduce Solman Service Desk

There are many ways that Solman Service Desk can be integrated with other ticketing systems:

1. All tickets are managed in SAP Service Desk and existing ticketing system is retired
   • Easy for companies that don’t have an existing ticketing system
2. All tickets are managed in Third-Party Service Desk and SAP Service Desk is not used.
   • Easy for companies that don’t want to train and develop new processes
3. SAP Service Desk manages SAP related tickets and Third-Party Service desk manages general IT related tickets
   • Environment where it’s decided that the support is divided between SAP issues and General IT issues.
   • Integration between SAP service desk and Third-party Service is needed.  An SAP related ticket can be created in the Third-Party Service desk, Since it is an SAP related ticket, this ticket can be ‘sent’ over to SAP Service Desk for resolution or vice versa.
4. SAP Service Desk and Third-Party Service Desk both exist, but only want one Service Desk to contain all the tickets.
   • All of SAP Service Desk related tickets can be  synced over to the Third-Party Service desk ticket or vice versa.

Whatever the reason, many companies will need to integrate SAP Solution Manager Service Desk and a Third-Party Service desk.  Integration with SAP Service Desk is accomplished by being able to call the SAP Service Desk API’s.  These API’s can be exposed as WebServices that can be called by the Third-Party Service Desk.

DataXstream has made a conscious effort to make this integration as painless as possible.

How did DataXstream get involved in Service Desk of integration?

The following timeline highlights DataXstream’s involvement with SAP Solution Manager Service Desk integration:

• 2008: DataXstream was contracted by CA (formerly known as Computer Associates) to build a prototype to integrate SAP Solution Manager and CA Service Desk
• 2009: DataXstream was contracted by CA to turn the working prototype into a deployable product.  Multiple versions of the CA product were released from version 12.1 to 12.5
• 2011: DataXstream requested permission to CA to continue maintenance of existing installations and support and create a similar product.
• March 2011: DataXstream started development of a new Xstream Connector for CA Service Desk, an improved integration product, owned and maintained by DataXstream.

What’s Next?

DataXstream has decided to push forward with developing an improved Connector for CA Service Desk.

The following features included in Xstream Connector for CA Service Desk are new and/or improved over the standard SAP Solution Manager integration provided by CA Service Desk 12.5:

• Custom status mapping
• URL Linkage in Solution Manager ticket back to CA Service Desk
• Implementation of SAP enhancement framework to allow for interface customizations
• Enhanced ticket handling and resolution flexibility
• Real-time integration with non-blocking change propagation via Xstream Integration Broker
• Improved exception handling and logging
• Compatible with new and future implementations of CA Service Desk release 12.6
• Support for file attachments (available in future release)
• Ability to pass groups (available in future release)

Conclusion

With any new system that is introduced in a landscape, a decision will always need to be made about what to do with the current system that is in place.  By being able to integrate with SAP Service Desk API’s, offers flexibility to either keep or retire the existing Service Desk ticketing system.

Duration: 30 Minutes

Speaker: Steve Park, Senior SAP Interface Consultant, DataXstream

Click to Watch

This thirty-minute webinar will provide you with a synopsis of the strategic advantages of integrating your enterprise ticketing system into your overall ticketing process.  This session will highlight and discuss the business benefits, challenges and specific implementation details you need to know in order to successfully integrate SAP Solution Manager with a third party Ticketing System.  This webinar will also discuss the key business requirements that must be understood to build a successful integrated ticketing process as well as highlight some of the limitations and challenges of leveraging the SAP enterprise services. 

What Will Be Highlighted:

• Key knowledge learned while building the standard integration for CA Service Desk to SAP Solution Manager
• Challenges faced during specific customer implementations
• Specific configuration, import standard coding objects, and techniques used to adapt and enhance the standard integration

Going Virtual: How Lumber Liquidators Optimized Its IT Investments and Lightened the Demand on Its IT Organization

The April 2011 issue of SAP insiderPROFILES magazine will feature an editorial on the virtualization of Lumber Liquidators’ SAP implementation. The piece takes you inside the thought process of Lumber Liquidators’ IT team as they recount the factors that led them towards virtualization, the selection of DataXstream as their implementation partner, and how they feel today about about the decisions they made a year ago during the virtualization process.

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.