INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

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 may be 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 a custom solution may reduce some of the resistance to “change,” but there are longer term consequences.  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 management costs may be lower initially by changing the software, those costs are simply transferred to other areas of the project–, often 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 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, variable, or processing option that might occur.  When the development becomes even more complex it is 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, optional functions, or even regulatory / compliance issues have been addressed that you might benefit from.  Each application of these changes then requires more extensive regression testing because of the custom coded solutions.

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 a complete re-implementation may be too cost prohibitive in the short term.

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.

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

Good knowledge transfer techniques and plans require every small section of custom code to be extremely well documented.  In the example above,  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.  A thorough knowledge transfer process was carried out with the critical techniques and methods for their 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.

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,
  • SAP note support for fixes, enhancements, and even regulatory or compliance adjustments will be extremely costly,
  • 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 significantly 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,
  • to overall solution architecture,
  • and on to enterprise architecture,
  • and to executive leadership in a large consulting firm.

——————————-

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:

SAP Implementation Partner or Company Selection Criteria

June 5th, 2010 by

Organization Change Management and Vendor Selection

Project success depends on an implementation partner’s ability to ensure business transformation occurs.

Can the SAP implementation partner or company deliver business process engineering together WITH the new system? Or, as with so many of them, do they just install systems and call that an implementation?

Lately I’ve been focused on developing a solid and repeatable ERP software and vendor selection process. 

While reviewing the academic literature and reflecting on my time working with SAP (since 1994) I found an interesting study from Romania.  The study addressed software vendor selection criteria and methods related to the limited information they had within the country.  The opening abstract certainly lines up with my personal experience about whether or not you will ever see ROI from your software investment:

Successful implementation of an ERP system is the result of knowledgeable and dedicated people working together. It entails 1) company-wide commitment, 2) openness to change, 3) good planning and 4) experienced guidance.

These key ERP implementation success criteria help you realize significant return on investment (ROI) from an ERP system. Using these criteria as guidelines during the system selection process and subsequent implementation can ensure that the chosen system will support and enable the business improvements many SAP implementation partners claim during the sales process (Hurbean 2009, pg. 1).

SAP or ERP Software Installation or Implementation?

There is a lot of substance to this study, for example it notes that the software implementation strategy and methodology are critical success factors for both the project and the software vendor selection.  One of the important differences they identified for ERP or SAP implementation companies is the idea of companies that merely install the application (more of a technical exercise) and companies that implement the software (focus on business drivers and business change in addition to the technical exercise).

The point of failure for many software vendor selection processes is a focus on the “product features” and “less or not at all the implementation.”

This study reaches the conclusion I have been pointing out for a long time on this site; there is a significant difference between software installation (with “technicians”) and software implementation (with “experts”) (see CRM, ERP, BI, and IT Investment — Where Do You Find the Business Benefit?). 

The Romanian study provides a meaningful definition between the two “goal posts” of software implementation methods and processes (see Software Engineering or Business Process Engineering?).  The goal of a software installation is to move from one software system to another with a minimum of disruption. An implementation focuses on the business drivers and business goals through a transformation of processes with the right software (paraphrased from Hurbean 2009, pg. 2) and the right implementation partner.

Key Implementation Success Factors that Apply to the Type of ERP or SAP Implementation Company or Partner

The key vendor factors identifying the differences between an implementation and an installation were:

  1. Lack of training and education to the company (typically a part of the change management process)
  2. Lack of in house expertise (related to a knowledge transfer strategy)
  3. Lack of clear goals or business objectives (poor business to IT alignment)
  4. Lack of companywide support and involvement (change resistance – insufficient change management)
  5. Lack of top management commitment and support (critical success factors and the senior leadership imprint)
  6. Lack of data accuracy.

Only items 3 (goals and business objectives) and 5 (top management involvement) are directly dependent on the company who selects the ERP implementation partner.  And even those two items can be strongly influenced by an ethical SAP implementation company.  For item #5 I have been on a few projects where the vendor project manager refused to engage company leadership even though the leadership was more than willing to step up but just needed some guidance.  And for item #3 I have seen many implementation vendors who bring unqualified “con”sultants to a project who were incapable of helping a company align an SAP implementation to business goals and drivers.  And then I have seen companies where the internal political culture or the company project team prevented these two success criteria.  The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors is about another study I reviewed and wrote about which lines up with several of these key SAP implementation success criteria.

SAP or ERP Implementation Success Criteria

The study continues to provide some great insight into corrective actions that can be taken to ensure you more properly align your IT / ERP / SAP investment to your business goals and objectives.  They provided an overview of ERP implementation partner or implementation company selection criteria that helps to ensure SAP project success.  This site has addressed these key shortcomings in much detail.  Below you will see the numbered problem area from the list above, a summary explanation of how to address it, and then an in depth article on the topic or subject. 

  1. Lack of training and education – ensure you have carefully considered both knowledge transfer and training requirements (see e.g. Change Management and Knowledge Transfer for a Successful SAP Project)
  2. Lack of in house expertise – knowledge transfer and the best business employees to support your implementation efforts (see ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?)
  3. Lack of clear goals or objectives – if the project requirements are not carefully aligned to business needs even before you begin you will have trouble finding value and finding the right vendor (see e.g. Aligning SAP Scope to Meaningful Business Requirements and Business and IT Alignment – Integrating Technology and IT Spend with Business).
  4. Lack of companywide support and involvement – a solid change management focus and communication are critical which requires software implementation vendors who can help lead the change activities (see Leading Change (and Change Management)).
  5. Lack of top management commitment and support – senior leadership must be educated as to the business benefit and the business direction of the project, and the importance of their strategic imprint for success (see The Real Reason Executive Participation Creates IT Project Success).
  6. Lack of data accuracy – ensure that your vendors focuses on the right data migration strategy and using the right data transformation tools (see Planning For a Smooth SAP Go-Live: Part 2).

Doing the up front work to carefully understand your business requirements, and then to demand that an SAP implementation company or partner has the skilled and experienced consultants is critical to project success.

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

Hurbean, L. (2009). Factors influencing ERP projects success in the vendor selection process.  West University from Timisoara (Romania), MPRA Paper No. 14430, Faculty of Economics and Business Administration.

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

Note:  This post has been split into two key parts, this first part focuses on a review of the study and the second part More on Vendor Selection Criteria and Methods for ERP Project Success focuses on some specific methods or approaches for vendor selection.




Popular Searches:


  • implemenatation vendor evaluation creterion
  • implementation vendor selection
  • sap implementation partner selection
  • what are criteria used in selecting for sap company

Related Posts:

Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2

May 24th, 2010 by

Change management

People, organizational, and change management strategies on an ERP implementation are usually more difficult than the technology implementation. 

ERP implementation changes to the business cause employees from different departments to become more knowledgeable about business in general (Hall, 2002) (see also  The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors about interdepartmental cooperation and communication).  While this is good, it also presents a set of knowledge transfer process challenges that consultants without the depth of project and business skill may not be able to navigate.  They may not even be aware of knowledge transfer techniques (see Screening Methods to Find the Right SAP Consultant Part 2 about the required skills and communication requirements of a good consultant). 

The Critical Nature of Training and a Knowledge Transfer Strategy and Techniques in Any SAP or ERP Project

ERP applications like SAP have a “single source” of information creating a need to develop understanding of business processes.  Duplicate entry tasks are eliminated and the degree of data accuracy is increased. Organizational processing speeds increase over time (after the initial learning stage downturn) and the dependencies between departments increases requiring a level of cooperation that makes some tasks and jobs obsolete.  Employee skill level and performance increases (Scott and Sugar 2004) making knowledge transfer techniques, like training, a critical component for long term success.

Different Types of Training are Needed for SAP and ERP Project Success

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 training contains only a very limited focus on performing a small sequence of keyboard tasks to impart the understanding of a single transaction.  They generally do not transfer process related knowledge.  Often there is little or no knowledge transferred of:

  • 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 followup 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.

Current knowledge transfer processes, plans, strategies, techniques, or methods do not include these key activities even though they are important for long-term business success. Essentially users are trained on what tasks to perform but little or no training is done to help them understand why the transactions are being performed.  They have little or no understanding of the upstream and downstream dependencies within their own departments and across the enterprise (Wheatley, 2000).  The type of insight that would produce these kinds of knowledge transfer plans and techniques only comes from significant experience.

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.  This method is not good for long term business transformation or for high productivity.

Successful Change Management Planning Requires Multiple Strategies and Types of Training — A New Training and Change Management Model is Needed

A more complete change management process and plan, which some companies installing SAP or other ERP systems conduct, is an explanation or overview of processes and how the transaction fits into an overall process stream.  This is still not a sufficient change management strategy  or process to ensure you are doing the right knowledge transfer methods and techniques. 

A more complete list of knowledge transfer methods includes several components:

  1. Transactional processing (typical keyboard training).
  2. Business process understanding (some projects use this method with transaction flowcharts for showing dependencies).
  3. Master data dependencies (few projects do this level of end user training because it is generally the implementation consultants who have this level of understanding).
  4. Operational processing (fewer projects still do this type of training because this is the production support “troubleshooting” type of training that requires seasoned consultants to be on site long enough to help users work through the issues).
  5. Ongoing knowledge transfer activities such as ad hoc troubleshooting meetings with all affected users (work through problems as a group in a conference room).
  6. Continuing communication about tips and tricks after the system is live.

The first 3 items on the list above can be carried out by competent and skilled training professionals.  Or, as many companies do, they can also be done well by training team members.  Most consulting companies use a method called the “Train the Trainer” approach. This approach relies on teaching internal company employees how to teach, or train, the transactional (keyboard related) courses.  It relies on them to be able to walk-through carefully scripted and controlled user exercises of limited and discrete transactions.

The “Train the Trainer” approach is a good knowledge transfer technique or method for many companies if the staff they have provided is not stretched so thin that they have an opportunity to learn what they need to know.  For this to be effective it also requires the consultant to be skilled enough to transfer the critical understanding needed to be successful. If a consultant has deep experience they can transfer the transaction knowledge together with the data dependencies, key process understanding, and even troubleshooting tips.  If the consultants on the project are unable to do this then it is highly likely that they do not have the experience you may have been presented.  Your engagement agreement may be beneficial to include some type of language to support the knowledge transfer requirements, not just that it should be done, but expected results of that knowledge transfer.

If the consultants on the project do not have a good overall process understanding your trainers will struggle and the fourth item, the exception processing, will be nearly impossible.  For example a good consultant’s knowledge transfer plan should include the ability to transfer understanding of the entire process cycle of their area such as:

  • Order to Cash
  • Requisition to Payment
  • Plan to Produce
  • Etc.

My experience is that the “Train the Trainer” approach is the most effective method for knowledge transfer to internal employees.  And in turn, good knowledge transfer for internal employees helps to ensure longer term change management.  As a result of the need to understand the overall process cycle area the consultants must have deep experience in their respective area of expertise.

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

Hall, R.(2002), “Enterprise Resource Planning Systems and Organizational Change: Transforming Work Organizations?” Strategic Change, Vol. 11, pp. 263-270.

Scott, J. and Sugar, D. (2004), “Perceived Effectiveness of ERP Training Manuals.” Proceedings of the Tenth Americas Conference on Information Systems, New York, pp. 3211-3215.

Sia, S. and Soh, C. (2002), “Severity Assessment of ERP-Organization Misalignment.” Proceedings of the Twenty-Second International Conference on Information Systems, New Orleans, pp. 723-729.

Wheatley, Malcolm (2000), “ERP Training Stinks,” CIO Magazine, June.




Popular Searches:


  • sap change management

Related Posts: