INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2

September 7th, 2010 by

SAP Upgrade

There are a number of important considerations in an SAP reimplementation that do not exist for a technical upgrade.  As a result the up front planning and evaluation time will be more involved.  For example you will have to consider any organization structure changes.  How will any new organization structure items map to old ones?

Then there is the analysis on how to handle old master data if the organization structure changes are so significant that they require a whole new master data paradigm.  If you have done a LOT of custom coding there may be a number of custom fields that you might want to handle differently.  Then you have to evaluate do you even want to bring those programs forward or do you want to use a “switched” framework that accesses the old data structures based on certain criteria but uses new or more standard functionality for newer items.  There are a lot of up front planning and evaluation considerations. 

If you are seriously considering an SAP upgrade and found this article, PLEASE take the time to get a little more key information about the upgrade options and considerations you have.  The following posts will help to clarify some of the direction to take on whether you should do a technical upgrade or a reimplementation:

Reduce SAP Application Lifecycle Costs by Going more “Vanilla”

One of the key goals of moving to more of a standard SAP system is to reduce application lifecycle costs by making upgrades quicker, easier, less expensive, and less risky.  Together with this the ongoing maintenance and additional functionality becomes less expensive to add.  When you don’t have all of that “software engineering” it is easier and less time consuming to add new functionality, easier to find knowledgeable consultants, and easier to find experienced employees for full time positions. 

One of the key steps in an implementation, or a re-implementation is to review the risk and cost of changes that have been or will be made.  You have to review all of that “software engineering” that was done rather than the business process engineering.  Since the focus of this post is on reimplementation we will look at the starting point for evaluating your upgrade project. The following development table, combined with the “frustration factor” (discussed later) will help determine if you are a good candidate for a reimplementation or a technical upgrade of your SAP system.

Start out by doing a careful evaluation of your current development and custom coding from your original implementation.  Then move on to understand where you have functionality gaps that you either expected from the original implementation or that the business found were important after you went live.

How do you know if you should consider an SAP Re-Implementation?

Probably the first sign you might be a good candidate for an SAP reimplementation is if you have an army of SAP support staff.  Some of the obvious indications you should consider a reimplementation rather than a techical upgrade are:

  • Your business probably has a massive IT department that looks more like a “full-employment” program for SAP skills.
  • You are highly dependent on contractors.
    • Contractors and consultants have become more like extended staff and staff augmentation rather than spot consultants.
  • Your SAP related support budget is beginning to approach the budget of some small countries ;)

Other things to consider that are not as obvious relate to the amount of business fit, custom coding, and business reporting requirements that we will look at next.

Evaluating custom development impact on your SAP upgrade

I have put together a table below related to development efforts (cost) and / or the risk involved with the development effort.  This table can be applied to a new SAP implementation or to an upgrade.  Whether that upgrade is a reimplementation or a technical upgrade this development table helps to understand the impact of a key part of the effort.

For an upgrade if all of your development efforts are in the Low to Average categories, and your “frustration factor” is low, you are probably a good candidate for a technical upgrade.  However, if there is much development work in the High category, or if the “frustration factor” is moderate to high then you are probably a good candidate for an SAP reimplementation.

Significant amounts of development in the High category (below) indicates that there may have been a number of custom coded solutions.  Unless these solutions were done to address a key business driver aligned with your company’s strategic direction or mission, and there were no other standard options you might want to reassess this type of development for a reimplementation.  This is especially true for any type of regulatory compliance requirement.  The reason it is critical there is because SAP maintains all of the system functionality to comply with the latest regulatory compliance requirements as part of your standard application support.  If a regulation changes SAP provides support and application changes for standard system functionality, not for custom coded solutions your system integrator invented.

Considering the frustration factor in your SAP upgrade

The other area to consider for evaluating a reimplementation or a technical upgrade is the “frustration factor.”  First, I’ll define the frustration factor as the failure of the SAP application to deliver on your business expectations.  This might be badly aligned organization structures that do not support easy reporting requirements; it might be partially implemented, poorly implemented, or not implemented at all functionality that supports a key part of the business; it might be any number of business reasons that the applications did not meet your business needs.

One of the other key areas where a reimplementation may be needed is if you are in a large enterprise with multiple SAP systems.  You may want to try to consolidate your SAP instances into a single system and a single enterprise-wide system.  The desire to consolidate systems onto a single application is one of the biggest reasons to consider a reimplementation, but this can also be one of the most challenging reimplementation types because of the amount of analysis of the delta in setup and design differences between systems.

SAP Technical Upgrade or Re-Implementation Conclusion

So, you’ve decided you are a good candidate for a reimplementation project.  You want to lower your overall SAP application lifecycle support costs; you want to ensure that future upgrades are less difficult and less expensive; and you have a pretty good idea of the delta of differences in your current system and what you would like to have; you also have a good idea of any additional functionality you would like to use.  So, where do you go from here?

Stay tuned, in a couple of weeks I’ll provide a post on the specifics and details of how to do a reimplementation in a fairly effective and efficient manner.

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


SAP ABAP Development Risk and / or Cost Table

Reports, Interfaces, Conversions, Enhancements, and Forms (RICEF or FRICE).

Note:  The following table provides some guidelines on how to judge the risk and / or cost of any development effort.  It is NOT meant to be a complete or comprehensive listing of the different scenarios or options.  There will always be other situations and circumstances which may fall into any of these categories. 

One other key consideration is that a piece of custom development may fall into the “Low” or “Average” area for actual development effort and cost but if it is mission critical, creates significant financial exposure, satisfies an external reporting reqiurement, or is related to a regulatory requirement it is automatically a “High” risk development.


RICEF or FRICE Object

Low

Average

High

Reports
  • Single table data extract (no joins)
  • One header description
  • Simple Ad-Hoc report
  • Minimal testing effort
  • A few input selections
  • A few header descriptions
  • Simple totals, subtotals, sums, or a few simple field calculations.
  • Simple table joins (generally 3 or less).
  • Data records and joins with one to one and in some cases one to many relationships.
  • Simple report layout
  • Simple Input / Output (I/O)
  • Moderate testing effort.
  • Mission critical; financial impact; external reporting; or regulatory impact.
  • Several input selections.
  • Several header descriptions
  • Complex totals, subtotals, sums, or field calculations.
  • Complex layout requirements.
  • Multiple headers
  • Complex Input / Output (I/O)
  • Complex or significant joins including many to many data relationships.
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well.
Interfaces
  • Simple change to an existing interface.
  • Manual trigger or simple batch processing.
  • Minimal testing effort .
  • Simple Input / Output (I/O)
  • Simple logic, little or no data transformation between interface points (i.e. no value lookup tables, no value substitutions, and few or no data value calculations within the interface).
  • Simple interface reporting requirements.
  • Single direction (inbound or outbound).
  • Single input or output record.
  • Moderate data volume.
  • Can generally be managed through periodic batch processing.
  • Moderate testing effort.
  • Mission critical; financial impact; or regulatory impact.
  • Complex Input / Output (I/O)
  • Complex logic with moderate to complex data transformation requirements (i.e. value lookup / reference tables, field value substitutions, field value calculations within the interface).
  • Multiple transaction formats
  • Complex calculations
  • Multi-directional
  • Real time interaction or involved batch processing (such as with batch job dependencies).
  • Average to High reporting effort (from above).
  • Moderate to high data volume.
  • Multiple input parameters
  • Multiple input or output records
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well.

Conversions

  • Inbound data is well defined
  • Single source of data
  • Data is clean or cleansed prior to conversion
  • Data mapping is straightforward and one-to-one
  • Simple reconciliation required
  • SAP ALE distribution directly from one system to another without any changes.
  • Low data volumes.
  • Possible candidate for manual entry because of low data volumes and simplicity.
  • Minimal testing effort .
  • Data source is defined but field data formatting varies from source to input.
  • Multiple sources of data for a single conversion
  • Cleansing is defined via conversion routines
  • Complex data mapping but still one-to-one data relationships.
  • Only data formatting changes but not data value changes.
  • Easy to moderate data transformation rules from source system to input system.
  • Multi-step reconciliation of data conversions.
  • Use of control totals for value fields and record counts for data conversions.
  • Moderate data volume
  • Moderate testing effort.
  • Both field data values and field data formatting need changes.
  • Multiple sources of data and possible multiple data transformation steps.
  • Significant time and effort for data mapping and conversion routines between systems.
  • Complex logic with moderate to complex data transformation requirements (i.e. value lookup / reference tables, field value substitutions, field value calculations within the interface).
  • Complex calculations
  • Multiple sources of data requiring multiple mappings, or multiple table joins, and potential manual logic input.
  • Data cleansing and data transformation values must be performed outside of the source system (either in an intermediate mapping and logic step or in the receiving system as it is imported).
  • Data mapping contains potential many-to-many relationships or complex logic which is dependent on multiple field values or multiple data characteristics.
  • Reconciliation tools or complex reports required
  • Large data volume
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well.

Extensions or Enhancements

  • Simple rules
  • Standard SAP supported enhancements completely contained in SAP OSS Note instructions.
  • Field default changes
  • Copying of logic to custom records or views
  • SAP Authorizations are not affected.
  • Simple form routines that are very slight variations of existing form routines.
  • Simple user exits with 1 or no loop statements and no table joins.
  • Minimal testing effort .
  • New table
  • New table structure with no more than 2 table references.
  • Simple data modification rules or simple coded business rules which influence data values.
  • Standard SAP enhancements such as extending field catalogs, creating pricing form routines, common delivered SAP user exit or enhancements (not necessarily supported by SAP OSS Notes), and other simple user exit or enhancement point coding.
  • Single User Exit or single Enhancement Point coding to achieve result(s).
  • Create or modify SAP Search Helps.
  • New data tables based on existing SAP table structures.
  • Custom info structure definitions (without coding).
  • Display screen field adjustments.
  • Simple adjustments to existing SAP programs / transaction and assigning new transaction codes.
  • Coding that requires 2 table joins or 2 loop statements.
  • Moderate or detailed program testing with multiple options or variants.
  • Mission critical; financial impact; or regulatory impact.
  • Creating significant portions of processing functionality with custom code.
  • Coding which involves a process string or chain of 2 or more data “transactions” or complete process exchanges.
  • Multiple new tables with multiple formulas.
  • Coding which requires multiple criteria, multiple data dependencies, or multiple table evaluations.
  • User exit coding which requires significant design effort where there is no standard SAP proposed solution that does not meet at least 80-90% of the requirement.
  • Coding which involves 2 or more user exits.
  • Coding which involves functionality in 2 or more SAP modules.
  • ANY Coding which involves direct table updates is automatically high risk (and should be avoided).
  • Development of new custom transactions with significant non-standard functionality.
  • User exits, enhancements, or custom program that require custom field additions to existing SAP tables for additional processing.
  • Custom screen requirements with new fields and processing requirements.
  • Coding that requires more than 2 table joins, or coding that requires more than 2 loop statements.
  • Custom development that requires enhanced or additional security authorization objects.
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well. Generally involves testing within and across a module or function.

Forms

  • Use standard SAP pre-delivered forms without changes.
  • Accept SAP form logic and coding, accept standard SAP print programs and make only minor layout changes to existing forms.
  • Single forms without any variants for each type of output processing.
  • Use standard pre-delivered forms but make minor logic and programming changes to form processing.
  • Can make form layout modifications, even significant ones, as long as they are based on an existing SAP form (not a brand new form developed from the beginning).
  • Use standard print programs but make minor changes to print program processing.
  • Up to 2 types of layouts (with only minimal changes in layout or logic) for each document type that needs to be printed.
  • Multiple types of variants or processing of forms but with minor adjustments to layouts or logic.
  • All logic or coding changes to both forms or print programs are within the same module / processing stream (not dependent on requirements from other transaction streams or other modules).
  • Can retrieve data from a single table outside of the standard print program processing stream and apply simple logic.
  • Any print program or form program changes which fall within the criteria and examples provided under the “Average” section of the “Extensions / Enhancements” section.
  • Moderate or detailed program testing with multiple options or variants.
  • Mission critical, financial impact, or regulatory impact.
  • End customer-specific, or end vendor-specific form layout requirements.
  • Pricing requirements that must be recalculated in the form logic (not able to use standard functionality).
  • Substantial layout modifications or creating whole new forms or print programs that are not based on standard SAP forms or programs.
  • Substantial modifications or alterations to standard SAP forms or print programs.
  • More than 2 types of layouts for any document processing type. For example, more than 2 types of invoice layouts, production orders, goods movement slips, etc.
  • Form or print program logic that requires data outside of the module or processing stream that is being transacted in.
  • Form or print program that requires any custom tables or customized rules for processing.
  • Multiple output streams from the same document or transaction process.
  • Data or logic criteria accessed from multiple tables not included in the pre-delivered standard print program.
  • Any print program or form program changes which fall within the criteria and examples provided under the “High” section of the “Extensions / Enhancements” section.
  • Substantial testing effort or multiple types of tests. May include positive and negative testing as well. Generally involves testing within and across a module or function.





Popular Searches:


  • sap cost to upgrade

Related Posts:

Technical SAP Upgrade or SAP Reimplementation

August 23rd, 2010 by

Business ApplicationsSAP’s application landscape has the depth and breadth of functionality to handle 90% (and usually more) of nearly any business requirement.  Regardless of this huge depth and breadth of functionality there is still way too much custom coding and redesign of the software (see e.g. SAP Implementation Focus, Software Engineering or Business Process Engineering?).

If you are an SAP shop considering an upgrade it may be time to take a hard look at whether you should do a technical upgrade or a reimplementation.  As you probably know, a technical upgrade means taking what you already have, the good, the bad, and the ugly, and then converting it all, as is, to a new version.  This includes the existing custom coding, processes, system settings, and all of the existing landscape.  If there were poor design decisions from the original implementation, or bad coding substitutions for standard functionality, together with security and authorization design problems then you carry all of that trash forward.

In many cases a reimplementation does not have to be much more expensive than a technical upgrade.

A reimplementation when done correctly, looks at the existing system landscape and evaluates the gaps.  You evaluate where the system could be redesigned to deliver on the original promise of SAP’s ERP application suite.

Considerations for an SAP Reimplementation

After you went live with the implementation, if you have heard lots of comments like:

  • “if only we had known X?” or,
  • “why didn’t the consultant tell us we could do Y?” or,
  • this is too slow, painful, difficult, complicated, etc.,

then you might be a good candidate for a reimplementation.

For example after being live you might discover that the original SAP Organization Structure did not provide you with key information you need for good reporting.  SAP standard LIS and SIS reporting provide you with little value because of this less than optimal organization structure.  You might find that the pricing implementation was less than optimal and has lots of restrictions.  After being live for a while you might discover that your supposed “experienced” consultants didn’t really know about SAP’s capabilities and that all of those pricing or order related processes they told you couldn’t be done are actually possible–, not easy, but can be done with fairly standard functionality.  The reasons why your original implementation was “less than optimal” may be limitless but you have learned a lot since then.

  • Maybe there wasn’t enough attention given to how the SD or MM org structures would impact reporting requirements. 
    • Maybe it has too much granularity or too little.  Maybe you needed geographical elements included in the org structure, or maybe product line dimensions, or maybe sales office / sales territory information. 
  • Maybe that “experienced” consultant had no clue about your GL Account Determination, or about complex pricing, and maybe they misled you and told you SAP didn’t support what you wanted to do with pricing or accounting because they didn’t have the level of expertise you paid for. 
    • Maybe the SAP “expert’s” design produced way too many pricing conditions, or huge amounts of master data to maintain.
    • Maybe they didn’t consider the live system master data maintenance requirements so the solutions they designed did not even consider the amount of ongoing support that would be needed
    • Maybe the consultants didn’t know how to segment and stratify customers for better sales and pricing processes, etc.
  • Is your availability checking terrible or non-existent and you have bad promise dates. 
  • Is the backorder processing difficult or non-existent?
  • Maybe the SD or MM or PP consultants were completely clueless about Sales and Operations Planning (S&OP) and left you with little or no forecasting and supply planning abilities.
  • You might find that your Materials Management (MM) consultant was clueless about MRP or about supply chain planning. 
  • Maybe the MM consultant didn’t have the critical experience for a good design around purchasing organizations, purchasing groups, PO pricing, material account determination, etc.
  • Maybe your Inter-Company supply processing is painful with full transaction processing for an entire sales and purchasing process when your “expert” never told you there is a simpler way with standard functionality.  Or, you might have to manually do eliminations for Inter-Company clearing but your “consultant” never told you there is standard SAP functionality to do this automatically.
  • Maybe your PP consultant told you that you couldn’t do in-process-subcontracting for subassemblies in the production process.  Or, maybe the MM consultant made a mess out of your subcontract process by setting up storage locations or plants to represent the subcontract vendor (rather than using standard SAP subcontract functionality).
  • Security authorizations are a mess and nearly everyone has their own “custom” authorization.  It is taking far too long to provision security and there are significant delays in provisioning user roles.

The number of dumb SAP design and implementation scenarios I’ve seen over the years are too numerous to list.  I could go on and on with different examples across the entire application. 

Your SAP Implementation Should Not Have Been So Painful

What it comes down to is your initial implementation was less than optimal.  You paid a FORTUNE for a  bunch of custom hacks rather than using standard SAP functionality, or a lot of functionality gaps for important business functions.  You may have ended up with overly complicated processes and difficult to manage data requirements.  There could be any number of issues or reasons, but let’s just say you’re not too happy with your previous implementation results.

If you’re not too happy with your results you are probably a good candidate for a reimplementation. 

Before you panic, there is a way to do a reimplementation on a reasonable budget, and without the huge pressures and stresses of your original project.  

SAP Technical Upgrade Considerations

If you are very happy with your system, and your user community has seen improvements and efficiency gains with the original implementation you are probably a good candidate for a technical upgrade.  Keep in mind that a technical upgrade is taking exactly what you have, without any significant changes, and then converting the system landscape to a new version.  Regression testing is done to ensure that previous functionality is not broken and that any custom programs still work as desired.

One other consideration for a technical upgrade verses a reimplementation is whether or not you kept the application fairly close to standard.  And by close to standard I do not mean that you didn’t do any user exits or with newer versions make use of any of the enhancement points–, in other words, your “experts” didn’t “invent” new custom-coded applications where a standard solution would work.

Even during a technical upgrade you may be able to make some adjustments and modifications, but they are more like minimal tinkering. 

Conclusions on SAP Upgrade or SAP Re-Implementation

At the end of the day, when you are considering your SAP landscape, the key issue to remember is the application is supposed to support the business and produce business value.  When you consider the huge investment and the impact to the business it is important to get real value from your SAP implementation.  As you prepare for your upgrade, that is the key time to evaluate, or re-evaluate the business drivers for your technology spend and consider what can be done to gain real return on investment.




Popular Searches:


  • sap re-implementation services

Related Posts:

Lower SAP Application Support Costs – TCO – by Reducing Custom Solutions

June 21st, 2010 by

Application SupportPreviously I explained the two primary types of implementations–, with SAP or any other ERP package you will do business process engineering or software engineering.  The differences in these two types of implementation approaches will have a major impact on your total cost of ownership (TCO) and your long term application life-cycle costs.

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to gain the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

——————————-

Software Engineering (SAP or ERP Custom Coding) Still Requires Change Management

If you choose software engineering you will still need change management processes but the transition will not be as extensive.  However by choosing the software engineering route (changing the system to match your business) up front development costs will be far higher, long term support will be far more expensive, and depending on the extent of the custom solution you will be tied into a particular vendor.

Generally less-experienced consultants choose the software engineering route over business process engineering because it reduces their experience requirements.  It is easier to insist that only a custom solution will work if they do not know how to use, setup, or support some standard functionality in SAP (see e.g. A Cautionary Tale About SAP Knowledge Transfer). This is also the “cop out” approach when some consultants (or system integrators) do not know how to guide a business through the critical change management and knowledge transfer efforts needed to accept new processes or concepts.

In some limited situations changing the software (or doing custom coding) to match your business is necessary.  If it is truly lined up with business goals and objectives, or if it addresses marketplace or competitive pressures so that it allows you to be a more effective business then the custom development is likely justified.  On the other hand if it is to avoid the difficult change management process in areas of the business that do not directly affect competitive pressures or reduce costs, etc., then it is probably not justified.  Instead you are better to engage in the intense change management strategies and processes to make the transition to a new way of operating.

In the short term custom coded solutions may “fit” your current business environment, and those custom solutions may reduce some of the resistance to “change,” but there are longer term consequences.  But there is a significant trade-off.  To the extent that you rely on custom coding and modify the system you are locked into your original vendor.  If you need something changed later, or if you want to add additional functionality you no longer have the option of selecting any number of qualified or skilled consultants from the general marketplace.  Therefore you have less leverage to contain costs (see ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?).  And while the change managements costs may be lower initially by changing the software, those costs are simply transferred to other areas of the project.  And often times at a much higher cost.  If you decide on modifying a package application like SAP then you will pay a higher cost for developer time than for the change management and training effort.  You will also have far higher support and maintenance costs making your entire application life-cycle far more expensive (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).

SAP Custom Coded Solutions Introduce Significant SAP Project Risk

As the number and complexity of development objects increases the risks to business operations increases.  This statement may seem obvious either before a project begins, during testing, or after a project is finished, but in the heat of an implementation it can easily be overlooked.  Along with this, to the extent that business operations are subject to risk so is a company’s financial performance.

Every time you custom code an SAP solution you introduce potential performance problems, additional processing overhead, potential coding mistakes, and worst of all, unforeseen process problems and gaps.  Along with these risks you do not have the benefit of the dozens, or hundreds, or in some cases even thousands of previous customers who have used, tested, fixed, and worked through the issues with new functionality offered by the application vendor.

It is all too common to find numerous bugs and fixes in custom programs once a system goes into the live production state.  Even the best coders can rarely account for every nuance, variance, or variable in processing that might occur.  When the development becomes even more complex it is even more important to evaluate whether there are standard system options which can handle some or all of the requirements.  Complex development often leads to much more significant bugs, including in areas that they might integrate to or transfer any data to or from.

Unplanned ERP Application Maintenance Costs Escalate Over Time

Once the custom coding is completed, if the software vendor (like SAP) releases patches or fixes to other functionality, or if you find a problem that the software vendor has a fix for you may in turn break some of your custom coded solutions.  Once those are broken, your business operations may suffer, and you are at the mercy and cost of getting the custom development fixed.  And on any large package application like SAP, you will likely be applying fixes (SAP OSS Notes) to the system from time to time for several years.  This doesn’t mean that the software is necessarily buggy, only that small nuances or optional functions have been discovered by some other customer that you might benefit from.  Each application of these changes then requires more extensive testing because of the custom coded solutions.

SAP or ERP Custom Solutions Still Need Sufficient Knowledge Transfer and Documentation

As part of my knowledge transfer techniques and plans in that situation I made sure that every small section of custom code was extremely well documented, and the entire solution was well-documented.  The client did the testing and was thoroughly trained on the custom solution, the dependencies, the master data requirements, the implications of master data throughout the process, the use of the coding, etc.  In other words, a thorough knowledge transfer process was carried out with the critical techniques and methods for the client’s long term independence.

There are times when a custom solution is necessary, but could you imagine a “con”sultant** trying to do this without deep knowledge and understanding of SAP’s Sales functionality?  This company had been told several times, by several “con”sultants** that what they wanted to do could not be done and there wasn’t an aftermarket product to support their need.

Custom Coded Solutions (Software Engineering) Limits Your Training Options

For the custom solutions and the customized functionality you no longer have the option of going to the SAP training programs to learn the system functionality (so you can configure it yourself).  You are tied into the original vendor at premium rates to maintain your system.  If the customizations are extensive enough, you will be pressed to use the original vendor to do any future upgrades or system work.  Essentially you have cut yourself off from competitive bidding because the cost of a complete re-implementation may be cost prohibitive.

Expect much higher application life-cycle costs.  Are you ready to be the only customer with that specific solution that is not supported by the application vendor (except at super-premium rates)?

An Example of a Necessary SAP Custom Solution With Business Justification

Don’t get me wrong, there are times when a custom coded solution is necessary.  While SAP’s application is very broad and very deep, it still has some gaps, or you may have some genuinely unique requirement.  For example I was at a client recently who wanted a Trade Promotion Execution solution.  Not just reporting or analytic functionality (like the CRM solution), but a true sales and marketing execution “cockpit”.  This cockpit had to be completely flexible so that they could do any mix of products, in any quantity they defined, to qualify for either additional free items or additional items at a discount, or some of the items ordered in that combination at a discount.  On top of that it had to be able to have limits so that as certain thresholds were reached, within a certain period of time, the customer would no longer be eligible for the promotion, or they would qualify for a different promotion.

The requirements and flexibility were so comprehensive that it would have entailed an entirely new application sub-module from SAP.  As a result I worked with them to design and implement a custom solution to handle all of these requirements.  This was mission critical for them, it was aligned with a key business need, and it was focused on customer retention and acquisition.  This was all done within the existing SAP provided order processing framework. On occasion I provide limited support for this custom solution (however they are fairly independent), but it was well documented, tested, and trained before I left.  In over a year in production there has only been a couple of minor issues with the entire solution and it has worked well for them with numerous creative order and marketing requirements.

Their sales and marketing programs have allowed them to profitably grow at a greater rate than any of their other competitors.  This growth and profitability has occurred during a major economic downturn.  I can’t say that my solution is completely responsible for that, but what I can say is that they were a sophisticated SAP shop who had clear processes and marketing requirements and the solution enabled them to be more efficient and effective with their marketing programs. This solution allowed them to reduce the previous 4 – 8 week development (custom coding), testing, approval, and roll out time line for each promotion or sales program to only a few days.   They also gained additional analytics of program and promotion effectiveness. This solution has allowed them to be very proactive in customer acquisition and almost instantly reactive to competitors for customer retention.  Their competitors have no competing solution and are subject to highly manual processes or long lead time custom solutions.

In this case the custom development was clearly connected to a specific business requirement that was mission critical and focused on customer and revenue growth.  In my opinion that is certainly an appropriate justification for a custom solution.

Conclusion on Custom SAP Solutions and Application Life-Cycle Support Costs

The costs and consequences of custom solutions to overall life-cycle support are generally far higher than they may initially appear.  For example there is the:

  • initial developer cost together with
  • the application consultant’s time,
  • additional documentation,
  • additional knowledge transfer,
  • additional testing beyond standard functionality requirements,
  • long term (unplanned) support costs with the incumbent vendor,
  • no standard or vendor provided training,
  • changes, fixes, or bugs are not included in vendor maintenance payments,
  • additional upgrade testing or “lock in”,
  • paid vendor maintenance may actually “break” custom solutions requiring additional rework,
  • etc.

If there is not a strong business justification for a custom solution you are much better off trying to make the standard system functionality work.  To the extent you do you will reduce overall long term support and maintenance costs.  One other key consideration is that by reducing the number and amount of custom solutions when it comes time for an upgrade your change management and testing time will be signifantly reduced.  You will have already made the initial process change requirements by changing to standard system options and you will not have to verify, fix, and extensively re-test all of the custom development.  Standard functionality is supported by the software vendors normal patches, fixes, or OSS Note based enhancements. 

In the end there should be a strong justification for custom coded fixes and solutions.  Carefully consider the cost / benefit ratio for any custom coded requirement.  Sometimes custom coded SAP or ERP solutions make good business sense, other times they are a train wreck waiting to happen.

Related Posts on SAP Change Management, Knowledge Management, and Training

——————————-

Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project
http://www.r3now.com/change-management-strategies-and-knowledge-transfer-processes-for-a-successful-sap-project
May 24, 2010

People, organizational, and change management strategies on an ERP implementation are usually more difficult than the technology implementation. One of the biggest problems in workforce preparation for ERP applications like SAP is the type of training they receive. The types of training you decide to use are all part of the knowledge transfer strategies, techniques, or methods to support business transformation.

Most companies only perform the traditional scripted keyboard training which consists of carefully controlled individual transaction exercises. The typical system implementation focuses on training individual transactions without the explanation of dependencies or processes. This works for initial exposure to the system–, for learning the user interface and the new data entry requirements. Typical training methods generally do not transfer process related knowledge critical for success such as:

  • The significance of the data that is entered.
  • Where that data is integrated into other parts of the system.
  • What the underlying data dependencies are.
  • What types of troubleshooting steps to take.
  • What interdepartmental impacts exist.
  • What part of the overall process is affected.
  • Etc.

Together with these common gaps in knowledge transfer techniques and methods there is little ongoing follow-up after the system is live such as:

  • Communications about maintenance or performance tips and tricks after the system is live.
  • Additional troubleshooting training or techniques as they arise.
  • Where to find key data and information for decision making.
  • Etc.

===========================

**  Please pardon my periodic references to the con artists (“con”sultants) in the marketplace.  My frustration with the frauds and cons in the marketplace is the amount of damage they have done.  Frankly I believe it is a testament to SAP’s ability to produce implementation methodologies and control structures that the sheer number of frauds in the marketplace have not destroyed far more implementations.  I’ve paid my dues and have worked my way through the ranks in:

  • training,
  • then to configuration,
  • to project / module lead positions,
  • through numerous full-cycle projects in multiple modules,
  • to project management,
  • and then out on my own as an independent contractor,
  • and then to trying to strategically grow a business with only the very best.

——————————-

Leading Change (and Change Management)
http://www.r3now.com/leading-change-and-change-management
May 17, 2010

While there is little debate that the successful implementation of change can create an extreme competitive advantage, it is not well understood that the lack of doing so can send a company (or an individual’s career) into a death spiral. Companies that seek out and embrace change are healthy, growing, and dynamic organizations, while companies that fear change are stagnant entities on their way to a slow and painful death.

Agility, innovation, disruption, fluidity, decisiveness, commitment, and above all else a bias toward action will lead to the creation of change. It is the implementation of change which results in evolving, growing and thriving companies.

——————————-

A Cautionary Tale About SAP Knowledge Transfer
http://www.r3now.com/a-cautionary-tale-about-sap-knowledge-transfer
February 3, 2009

Genuinely seasoned consultants recognize that the time they have spent “in the trenches” cannot be replaced by one project’s knowledge transfer; therefore, they are not threatened by encouraging your understanding. Many talented consultants thrive in an environment where they are challenged, and learning, and solving problems. It is a dimension of a successful consultant’s personality and character. So transferring knowledge is second nature to a skilled and experienced consultant.

Most often the truly skilled consultants with practical business and work backgrounds are the ones who can speak to issues in plain, understandable terms. They have been through the go-lives, they have done the production support for the user community, they have had to work through the complex or thorny processing issues, they’ve seen where things were done right (and not so well) and they have gained a solid process understanding. They do not have to rely on “fast talking techie speak” to keep you confused and in the dark. And if you’re not clear on what they are saying how are the project team and user community going to understand them?

——————————-

ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?
http://www.r3now.com/erp-consultants-is-the-promise-of-knowledge-transfer-just-part-of-the-sales-pitch
February 10, 2010

Most ERP projects are filled with promises of software knowledge transfer from the consultants to the client. Yet once a project is over, in many cases, the client is clueless when it comes to making software configuration changes, and may even struggle with performing basic transactions in the system. So what gives?

In spite of all the lip service given to knowledge transfer, the problem is there never was a real strategy to make it more than just a dream. Secondly, when push comes to shove this once important concept of learning suddenly becomes something we worry about later (and of course, it never happens). This is similar to consultants building a spaceship to get you to Mars with the understanding we will not plan the return trip until after you get there.

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to accomplish the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

——————————-

——————————-

Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering
April 29, 2010

There are two primary ways in which SAP (or any ERP system) can be implemented in your company; you make your company fit the software or you make the software fit your existing processes. These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them. They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project.

No matter which route you choose, there should be clear business justifications for the approach you take. In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace? If your processes are that unique to your business model are there other ways to accomplish the same process advantages? These types of key questions help to clarify whether or not there is a business justification for one approach or another.

Related Posts: