SAP & ERP Consulting from the Customer Point of View

SAP implementation ROI, SAP architecture, & SAP business solutions

SAP Consultants for High Speed SAP Projects

August 1st, 2011
SAP consultant results

SAP consultant results

 

No matter what size company or organization you have the type of consulting experience you choose will have a huge impact on the results of your SAP solution.  For high speed projects consultants with several small or mid-sized SAP project experiences tend to be more well rounded.  They have skill at delivering the more difficult SAP solutions with standard functionality and at a faster pace than their counterparts with significant amounts of large project experience.

 

Why are SAP Consultants with Many Small and Midsized Projects Uniquely Qualified?

The small and midsize business segment of SAP implementations use smaller teams, smaller budgets, and tighter timelines.  Contrary to popular belief a small or mid-sized company’s SAP implementation often has the same process requirements, similar industry needs, common competitive pressures, and all of the other issues that go with doing business.  In other words, their business software application requirements are exactly the same as their larger counterparts.  However, they must deliver similar or better results than their larger counterparts with fewer resources.  Consultants who deliver solutions in this space must know their area of responsibility well because they are often one deep, without others to fall back on.  They have to cover the integration touch points and other project activities together with their own module.  This type of effort is usually performed by other groups and numerous other consultants on larger projects.

Consultants who have worked in the small and mid-sized space don’t have the luxury of the big consulting firms, on their mega projects, where they can specialize in one little component of a module at a time. They don’t have the luxury of massive numbers of people coordinating small, discrete components of an overall effort.  Small and midsized SAP implementations often don’t have the resources or budget for large change management and training staffing, separate data conversion groups, separate testing staff, or other key areas of the project.

The consultants with many years of small and mid-sized business exposure are able to do in a few hours, or possibly a few days, what takes consultants with less exposure weeks to figure out. Even if it is a bit of a stretch, they have enough background, enough exposure, and enough experience to be able to start immediately with 80% or more of the solution. From there it is just detailed testing of different settings to be sure you have just the right combination and the process or transaction behaves exactly like you planned.

Small and midsized business consultants are less likely to need lots of custom coded solutions because they can figure how to do it with standard functionality, or how to “re-purpose” other functionality for your company’s particular need.

An SAP Project Examples of Complex Standard Functionality that Helped Avoid Blown Budgets and Timelines

I’ll provide one example here of many SAP experiences I’ve had where this experience made a huge difference in the SAP project result.  The SAP experience helped save the timeline, stopped the continual circular meetings, and finally moved the process along.

SAP Cross-Company Supply

I was on a very large project that had cross-company supply issues that no one had been able to resolve for about two months when I joined. There were weekly meetings, and weekly arguments, and no one could agree on the solution.  There was third party cross-company supply where one company would take the order, transfer the requirements to a separate company who would actually carry out the delivery and bill the other company who then billed the end customer and collected the payment.  This was also being done in different countries, with different currencies, cross-company pricing markup, and foreign trade.  After a few weeks of this dragging on after I arrived on the project as the SD team lead  I knew something had to be done.  All of the “Big x” consultants claimed this could not be done without mountains of custom code and that standard SAP would not work.  These consultants did not have a lack of years in SAP, or large projects doing SAP, it was a lack of experience having to deliver results on a compressed timeline with standard functionality.

The SAP Blueprint was over and we were still in design on a key set of processes.  After several discussions where it was mentioned this was standard functionality and strong disagreements together with claims that only custom coding would work I had enough.  I took a couple days to set up and prototype the entire solution.  The standard SAP functionality did over 90% of everything that was needed for every process and transaction they needed. After the prototype was set up, and without telling the other consultants who insisted it wouldn’t work (and claimed they wouldn’t support it if it did), I set up a meeting with all of the key stakeholders and the client project manager to demo the new functionality.  It was a huge success and the ridiculous arguments and endless discussions to flow out processes for unneeded custom ABAP solutions finally stopped. The solution was nearly complete with almost all standard functionality. [FN1]

Big SAP Project Experience Effects on Compressed Timeline and Budgets

When you want to do a compressed timeline project with resources (consultants, managers, coordinators, etc.) who come from big SAP projects you end up with unnecessary struggles.  Their “experience” has conditioned them to believe these types of projects cannot be done, they rely on too many middle layers of coordination / management, they struggle with the intense need for integration coordination, and undermine attempts to gain momentum because they are not used to the pace.  These large projects often provide the “luxury” of deferring discrete components of an area to others.  They provide big budgets, lots of time, each delivery area broken down into little tiny “chunks” and then handed off to others.  Some (though certainly not all) of these consultants and managers from larger projects are so uncomfortable with the pace and demands that they spend more time making excuses for lack of results and look for others to blame. The idea of delivery “ownership” over an entire area is a foreign concept to them.  Some of these consultants from larger implementations, with slower paces and many layers of coordination are lost without someone managing each tiny aspect of what they do.

~~~~~~~~~~~~~~~

[FN1] In fairness to the other consultants who thought this could only be done through ABAP custom coding, it does require a major amount of setup in SD, MM, FI, and EDI to work correctly. While it is all standard functionality, consultants with experience on very large projects have limited exposure to even their own module of expertise. As a result it is unlikely that the full breadth of this and other functionality has been seen outside of the small and midsized business space. In the small and midsized business space the consulting teams are smaller, and out of necessity are more knowledgeable within their module area, and because of the integration requirements with other modules they tend to gain greater application exposure to standard functionality options.

Related Posts:

How “As-Is” Process Mapping Can Damage Your SAP Project

January 3rd, 2011
Business Process Engineering or Software Engineering

SAP ERP business software implementation

Not only can the “As-Is” process mapping damage your project, it also adds significant amounts of unnecessary cost.

After over 20 SAP projects since 1994 I’ve participated in the “As-Is” and “To-Be” processing mapping exercises many times.  Along the way I learned a few key lessons.  First, the old “As-Is” process mapping approach was (and is) critical for software engineering projects.  As-Is process mapping efforts have very limited application to an SAP implementation, or for that matter any true Commercial Off-The-Shelf (COTS) business software project.

If you’re buying a COTS application like SAP, Oracle, JDE, or any other major ERP business software package you generally go into it with the idea that you are replacing custom-built applications with “standard” off-the-shelf package solutions.  This generally requires an expectation that you will change your busines to match application functions and processes.  To keep the application as close to standard as possible you will do business process engineering rather than software engineering (see SAP Implementation Focus, Software Engineering or Business Process Engineering? ).  As that post points out, there are times when software engineering is justified, but those are exceptions.  Software development or software engineering with a COTS software package may be justified when there is a clear business justification, not just a “convenience” issue to resolve.

“As-Is” process mapping was critical for software engineering but it offers little value to an SAP implementation

If you have made a firm commitment to the business process engineering then the “As-Is” process mapping exercise not only wastes time but it keeps your business stuck in the old ways of doing things and creates a high likelihood of demands for custom development.  Correct SAP blueprinting methods will automatically review the “As-Is” processes but only briefly enough to ensure that the future state covers all of the requirements.

Effectively Mapping Business Processes to the SAP Future State (To-Be)

The correct SAP ASAP approach, which is focused on business process engineering rather than software engineering, relies heavily on a good process scope.  From that process scope you conduct your requirements workshops to map the old processes to the new SAP “best practices” and determine any gaps.  If the process gaps are business-critical they may justify some amount of custom development to meet an actual business need.  At the same time doing full-blown “As-Is” process mapping can create serious problems.

Being committed to business process engineering rather than software engineering makes the “As-Is” efforts throw away work.

By focusing on the “To-Be” process state a good SAP consultant will walk through the “As-Is” processes to ensure they have captured all of the future state requirements. In other words, during the blueprint process I may map out the current process on a white board but ONLY to ensure I have sufficiently captured all of the required blueprint details for the future process.  Unless there is something very unusual or business critical I only map the future state (To-Be) processes with all of the existing business details.

By mapping processes in your SAP scope to the existing business processes you are only looking for process gaps and process differences that may need to be addressed through change management.  You are NOT wasting your time and effort, or expensive consulting resources on mapping “As-Is” processes.  You are reducing the amount of time your consultants and your own employees are immersed in something you want to change.

The ASAP Approach that Saves Money, Time, and Reduces SAP Total Cost of Ownership

Because of the huge expense in custom coding and in ongoing support and maintenance of custom coded solutions your SAP Total Cost of Ownership (TCO) can be dramatically increased by getting immersed in the “As-Is” paradigm (see Lower SAP Application Support Costs – TCO – by Reducing Custom Solutions ).  Think about it, if your project focuses on the current state rather than the future state you are keeping your employees and project leadership immersed in current ways of doing things.  That mindset leads to project team members who believe they must get everything custom coded to match exactly what is done today.  Very little business process engineering is done and more money is expended for an army of coders to engage in a software engineering project rather than a business process project.

There are times when custom-coded software solutions are necessary but they must serve a clear business purpose beyond a convenience or desire to do things the “old way.”

Being committed to business process engineering rather than software engineering makes the “As-Is” process mapping efforts throw away work.  By reducing the time and effort on “As-Is” processes and focusing on the future state you reduce project costs and TCO by avoiding a huge investment in what will eventually become garbage.

Conclusion on the Dangers of “As-Is” SAP Process Mapping

By spending too much time and energy on the “As-Is” state your employees stay focused and attached to all of the old ways of doing things.  Because of this focus they will naturally see more need for custom software engineering rather than business process engineering (i.e. change management). So in the end not only do you pay for the wasted time doing unnecessary “As-Is” documentation but you also get the “bonus costs” of software engineering. Your total cost of ownership for a COTS application goes through the roof.

By focusing the project on the “To-Be” state right from the beginning you won’t eliminate all custom coding but you will reduce it.  In this way you reduce meetings and meeting time, reduce the amount of time and effort in blueprinting, and you focus on value-added efforts.  By insisting on a forward looking focus on the future state and using a “To-Be”  review as an analysis to ensure the project scope is complete enough you will reduce the amount of time employees are enmeshed on the “old ways” of doing thing.  This type of expectation setting is critical to a successful business process engineering project enabled by SAP business software applications.

Once again I will clarify, there are times when custom-coded software solutions are necessary but they must serve a clear business purpose beyond a convenience or desire to do things the “old way.”  So there are some times when the current way of doing business might justify the “As-Is” approach.

Related Posts:

SAP System Vendor Project Success Criteria & Factors 5

November 29th, 2010

High Performance SAP ProjectThis is the final post in the series on SAP project shared success criteria.  Doing this entire topic justice has been more of a challenge than I had originally anticipated and at some point I will put it all together in a PDF e-book. 

This series leaves you with a lot to digest but over the years these items generally make up the foundations for a very successful project that is able to transform your business.  This series has been challenging but interesting and I am glad it is complete. 

In a few more weeks I will be coming back around to try to wrap up my series on SAP reimplementation for little more cost than a technical upgrade.  That one turned out to be more challenging than I had originally expected.  Until then, here is the final installment in this series on project success criteria.

No.SAP or ERP Critical Success FactorCompanyIntegrator
5Experienced SAP consultants A
7SAP implementation strategyzA
8SAP project managementAz
9SAP tools, templates, and resources A
10SAP scope developmentzA
11SAP scope managementAz
12Strong SAP project and business communication (inward and outward)Az
13SAP change managementAz
15Sufficient SAP training (user and project team training)AA
16SAP system vendor and customer trust A
17SAP system design decisionszA
18Amount of custom ABAP or other SAP codingzA
19Appropriate SAP software configuration (system settings)zA
20SAP system change control process A
21SAP data analysis and conversionAz
22SAP test planningAz
23SAP test developmentzA

Legend

A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

21.  SAP Data Analysis and Conversion

One of the major activities of an SAP project is the data analysis and conversion. On many projects there are too many new data requirements or data changes needed after the system goes live.  One way to avoid so many of the data correction in a live production system is to ensure that you have sufficient integration and cutover testing.  We will look at testing in a moment.

The primary responsibility for data conversion is generally on the customer.  Customer primary responsibilities include:

  • Identifying legacy and other data sources
  • Cleaning or scrubbing the data
  • Ensuring the converted data meets business processing requirements
  • Defining sufficient test plans to validate data is properly converted
  • Provide sufficiently skilled employees to work the data
  • Make as many data corrections as possible in legacy systems before conversion
  • Ensure there are sufficient hardware resources available for meaningful data conversion tests

I’ve developed a short list of the common data conversion risks as adapted from the SAP ASAP 7.0 Data Migration and Risk Assessment Template.  That template, provided by SAP, contains a sample issue and risk log, and includes some suggestions on how to manage the following common data conversion risks:

SAP Data Conversion Project Management Risks

  • Improper estimates of data migration effort and activities
  • Client side skills gaps on data migration
  • Deferring data corrections until after go-live
  • Knowledge of and access to data sources
  • Insufficient or incorrect change control processes
  • Insufficient participation from key functional project team members (client and consulting)
  • Improper management of dependencies between functional areas or modules. 

SAP Data Technical Conversion Risks

  • Lack of agreement on system of record, data definitions, standards, transformations, conversion methods, etc.
  • Data migration tool(s) not well defined or settled
  • Hardware sizing and data volume are inconsistent
  • Requiring historical data conversion (rather than using legacy systems for historical purposes)
  • Multiple legacy sources of data for single master record loads in SAP.
  • Data gaps – no corresponding data record for SAP conversion
  • Different data structures between legacy systems and SAP.  For example SAP may have structured hierarchies and the source data may not.
  • Poor data quality – errors, duplicates, inconsistent use of fields

Preparing conversion programs, or more specifically, using SAP’s variety of conversion tools and resources is a vendor responsibility.  Together with that the vendor, who has set up the system with the master data requirements is also responsible for providing data load templates as well.  Further the vendor’s functional consultants must participate in the data conversion design and development activities because they are the ones that set up the system and know the master data requirements better than anyone.  The only exception to this is if you decide to bring in consultants who do knowledge transfer to your implementation team and your own internal team does all of the system setup.

For an overview of the various data transformation methods in an SAP project please see the following post:

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2

SAP Blueprint Master Data Requirements

As a final note, a system integrator should be able to provide a first pass at basic master data requirements by the end of the Blueprint phase.  In fact your SAP Blueprint should contain a technical blueprint section with significant amounts of detail. 

  • It should include each master data type (Material Master, Vendor, Customer, Routing, Sales or Production BOM, Work Center, Chart of Accounts, Profit Centers, Cost Centers, etc., etc., etc.)
  • And it should include each master data SUB type, using just the Customer Master as an example it should contain the requirements of sub-data types, for example you may need Ship-To Customers, Sold-To Customers, Bill-To Customers, Payers, Agents, Freight Forwarders, Carriers, one-time customers, web shop or online customers, etc.  This type of breakdown and segmentation should be done for every data type so that you know what data conversions are necessary.  And this level of detail MUST be contained in a sufficient blueprint.
  • At the end of the blueprint, to ensure that you have all of the master data requirements covered as well, your system integrator SAP blueprint document should contain the specific details of every transaction data type.  That transactional data requirement will be a key part of the data conversion.  For example using the Material Master and inventory movements SAP provides the blueprint document should contain the specific types of inventory movement transactions you perform.  Simple goods receipts, goods issues to production, goods receipt from consignment stocks, issues to consignment stocks, scrapping, shipping / distribution goods issues, receipt into restricted / quality hold, move into unrestricted from quality hold, transfer from plant to plant, transfer from storage location to storage location, etc., etc., etc.

 If your SAP system integrator Blueprint does NOT have this level of detail then it is not sufficient to set up the system and perform the necessary master data conversion.  Further, if it lacks this level of detail you may want to fire your system integrator and demand a refund of at least part of what they bill.

By having this level of detail at the end of SAP blueprinting (process details, master data details, interface requirements, forms, reports, etc.) you can immediately move into setting up the system. If you lack this level of detail you may find yourself forever in design mode (revisiting normal blueprint requirements) and blowing both the budget and the timeline.

I suggest you add this summary of the type of detail you want by the end of the blueprint phase to your contract.

22.  SAP Test Planning

You will have to determine who needs to perform what testing, when, and where.  Together with that you will also want to use this as an opportunity to get both “power users” and non power users involved in the testing.  This becomes the early part of knowledge transfer as well as user acceptance testing.  Inevitably the additional resources from outside of the project team will discover gaps or items that might need to be addressed. 

The Test Planning responsibility is primarily on you as the SAP customer.  Your primary goal here is to ensure that every process you put in scope is represented in some type of testing script. For example, in your order to cash process you might want test scenarios that include credit processing with and without product returns; third party drop shipping to the customer direct from the vendor; pro-forma invoice processing and then follow-up commercial invoice processing; interfaces to and from various external systems; online order entry processing with and without manual intervention; backorder processing and sourcing from other facilities, etc.  At a high level you will be responsible for ensuring that you cover all of the key processes that need to be tested.

SAP Test Strategy and Testing Approach

  • SAP Test Management
    • Test planning, scheduling, and logistics / coordination
      • Identify users to perform testing
      • Identify who will coordinate testing activities
      • Location and equipment logistics for testing
      • Method for communicating test schedule to participants
      • Test data – common master “data sets” to use for testing.  This is different than the converted data testing.
  • Types of SAP Testing and Methods for Testing (whether manual or automated)
    • Unit testing (single transaction)
    • Business Process testing (unit test strings within the same functional module like SD, MM, PP, FI, CO, etc.)
    • Integration testing (Business Process testing including the integration points with other functional modules)
    • Interface testing
    • Data conversion testing (test the data load programs)
    • Converted data testing (test the converted data at performing various functions)
    • User Acceptance Testing
    • Regression Test
    • Batch Job testing (test batch programs, timing, and sequence)
    • Security Test
    • Performance / volume testing
    • Any positive and negative testing requirements for security or transactions
    • Ad hoc testing of unplanned variations and variants
  • Testing Toolset (various spreadsheets, or automation tools for building and managing the testing process).
  • SAP Test Reporting and Analysis
    • Test Metrics
    • Defect Management

Change Control Process (for an overview and details of the SAP change control process see SAP System Integrator Shared Success Criteria Evaluation 4 which focuses critical success factor on #20 on this list of “System Change Control Process”). 

As for a test script, I have included an example one which is a modified version of the standard options SAP provides as part of the older ASAP methodology.

EXAMPLE SAP TEST SCRIPT with Ad Hoc or Variant Section information.

23.  SAP Test Development

As for test development this is clearly a vendor primary responsibility.  Unless you use SAP’s integrated Solution Manager resources for testing this is probably one of the areas where you will have to rely heavily on your SAP partner. The reason this is primarily a vendor responsibility is that as an SAP customer “you don’t know what you don’t know.” 

Unless you have adopted an approach where you require the implementation vendor to act as pure consultants, where your own project team does all of the system setup, you will not know the detailed testing requirements.  As a result a vendor must be able to walk you through the transaction strings and dependencies.  They must be able to take the entire process-related solution they blueprinted from master data creation through cash processing and any interfaces or manual steps in between. 

Because of time, budget, and limitless possibilities there is only so much testing in a project.  These limitations create a requirement that only a “limited universe” of testing can be accomplished and SAP system integrators will usually require someone to sign off on those limited tests. 

There are a few things to beware of here:

1) When the tests have been “gamed” to support only a successful outcome and not to actually test the solution.

2) When a system integrator pushes back on testing variations that they may not have documented in the “formal” test scripts.

3)  Any vendors who engage in hard push back against additional ad hoc, variant, or converted data testing.  Unfortunately I have seen a couple of the major SAP system integrators KNOWINGLY push trash on their customers.

For a thorough testing program you should always ensure your tests include any of the custom development objects as well as manual processing steps.  For example, a thorough test process must include testing of any outputs (forms), interfaces, enhancements, and reports.  Data conversions should also be tested but may be done separately.  However, one strong word of caution here, once converted data is available, even if you do not do formal testing, be absolutely certain to do as much process testing as possible with the converted data.  Testing with converted data will reveal a number of potential problems that can be corrected or resolved before you go live.

Related Posts: