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. In other words, there are business consequences for assuming software knowledge will somehow automatically cross-pollinate. Some of them include the following:

1. Paying consultants to do project task that the client could (and should) be doing. Without a certain level of software knowledge, it will be difficult for the client to fulfill even the most basic project responsibilities. Beyond that, what incentives do consultants have to transfer knowledge? Like I have said before, the less you know the more money they make!

2. Fostering resistance to change. When it comes to change management, many times we are our own worst enemy. It is not hard to imagine why employees refuse to buy into something they do not understand (no matter how great it sounds). When consultants are running the project (because the client team hasn’t learned a thing), understandably many employees will view the project as a ticking time bomb (and try to get as far away from it as humanly possible).

3. Software quality will suffer (and this is not just a perception). Lack of software knowledge limits the ability of the client team to become proactive in the design of new business processes and software. In this case, unless the consultant is superman (and they never are) it is a given something very important will slip through the cracks. On the other hand, a client that has a decent understanding of the system can at least ask the right questions or spot things that maybe wrong with the software.

4. Paying consultants to camp out for years after the initial go-live. After all, someone must hold the hands of untrained users and make simple software configuration changes required by the business. A similar issue exists with regard to the clients ability to implement new releases without an army of consultants.

5. The software remains static while the business needs change. The reasons: a) no one internally is aware of what the software is capable of doing; b) no one internally understands how to make the changes, c) the alternative of hiring consultants cost too much. In the end, this all boils down to a failure to leverage your software investment. In the meantime, users are told to live with the software and “work-around” the functionality issues.

6. As employees change jobs, leave the organization and new ones are hired, consistency in user procedures and knowledge of the system slowly erodes. This is inevitable considering no one can explain the big picture or the original software design intent. Therefore, new users are not trained correctly or simply do the best they can (we are now back to sub-optimization).

7. Modifications are made to the software to support needs that are already addressed by the software (right out of the box or with a few configuration changes).

8. After several years of struggling with the software, the organization finally hires an employee from the outside with the expertise to provide needed support. Unfortunately, if this was done prior to implementation, they could have saved themselves a lot of money and grief.

9. Outsource the application support with the hope that the problem goes away. Don’t kid yourself, if no one internally can make sense of user requests (from a software design and set-up standpoint) or, better yet, actually make configuration changes, outsourcing may cost more than you think (service or change orders).

Knowledge transfer is not a one-time event, but a project management “thread” that runs throughout the project cycle. It requires a strategy and attention to execution. In other words, the consultants and the internal team must be managed with the objective of knowledge transfer in mind. The following is a list of items to consider in any knowledge transfer strategy.

1. Select application consultants that have implemented their assigned modules on at least three other projects (with at least one in a similar industry, scope and degree of complexity). Otherwise, there may not be much knowledge to transfer. Also, they will spend most of their time trying to figure out the software(at your expense).

2. Select application consultants with good oral and written communication skills. Understanding software is one thing; but if the consultant does not communicate very well this is a real issue that undermines the goal of knowledge transfer. In addition, a consultant that simply does not say much may also be a consultant that does not know much.

3. Understand that rapid deployment or fixed price consulting engagements can work against you. These type of projects may (or may not) result in a faster or cheaper implementation; but they are definitely more consultant and date driven. This means the client may not have the chance, and the consultant may not have the time for knowledge transfer.

4. Put together an internal project team that has the desire and ability to learn the software. The core skill set includes understanding your business processes, business systems analysis skills (process oriented, logical thinker, problem solver), willing to roll-up their shelves and dig into the software. Like I always say, if you do not have employees with the right skills, get them. You will need them longer than you think.

5. Establish clear expectations with the team and consultants that knowledge transfer is a key priority, a shared responsibility and progress will be measured. For example, add a “knowledge transfer status” segment to the agenda of project team meetings and executive steering team meetings. Schedule one-on-one discussions with each team member and consultant to discuss specific issues and develop get well plans.

6. Do the “formal” project team training (but do not reinvent the training wheel). This training is normally conducted after the software is acquired but before the design phase. When done correctly, classroom style training for the project team is of considerable value since it lays a solid foundation for continued learning. However, when poorly planned or executed, it is a waste of time.

As general rule, for many reasons I prefer courses offered by the software vendor (not those delivered by the consultants you might have working on your project). First, vendor training programs are developed by those with expertise in both formal teaching methods and the software. These courses are also time tested; in other words your team will probably not be the first to take them. They are typically conducted by a professional trainer (who has done the exact same class many times before) with a pre-defined training agenda, lesson plan, data and supporting materials. This usually means a more comprehensive coverage of the software capabilities, consistency, smoother delivery, a software perspective other than that of your consultants, and access to up-to-date training materials.

On the other hand, when consultants deliver the lesson plan and training there is a greater risk that the opposite will be true (narrow scope, poor quality, etc). This is not necessarily an issue of bad consultants. The need to reinvent the training wheel is typically the reason for problems with this approach. Secondly, do not under-estimate the time required by the consultant just to prepare for a class. This is one reason why training delivered by consultants may end up costing much more than vendor training. Finally, many consultants are overly accomodating and are willing to customize the training beyond what is reasonable or advisable. Classes may be customized to the extent it is no longer really training, but instead a premature design or testing session. Remember, the goal at this stage is to learn the software capabilities and basic transaction processing, not test or determine how it will be used. The truth is no one at this point has enough information to design or test anything.

7. Plan courses to maximize learning for the dollars spent. When scheduling classes first take only the basic courses required for each module. After the team has have worked with the software for a while (with the assistance of your consultants), take the advanced functionality (if you need to). With this approach, the student has a chance to absorb and reinforce what was learned during initial training and, as a result, should be better prepared to take the advanced topics and probably will have more specific questions.

Finally, do not send a cast of thousands to project team training (the idea is the project team will train others). The key people to attend the courses for a given module include the module team lead, the power user (functional analyst), the internal consultant (if you have one), and the IT developer (supporting the module). Recognize it may be appropriate for a few others to attend such as the dept. manager (not formally on the team), power users from other highly integrated modules, etc. However, as a general rule, training only those on the project team is the best use of time and the training budget. That is why they call it “project team training”!

8. Take the software configuration classes. When offered, these courses get into the parameters; switches and setting that makes the software do what it does. The point is, most classes focus on end-user transaction processing, but the software configuration classes get into what is behind the curtain (but are not about writing programs). These classes are very important because if the goal is to wean yourself from consultants this will not be possible unless the team eventually understands how to maintain the software set-up. The list of attendees for these type of classes is shorter and includes the module team lead, power user and IT support.

9. Set-up a playground software environment. When the team returns from training, there must be an environment immediately available for them to reinforce learning and do some self-help follow-up testing. Taking advantage of the playground should not be optional but mandatory for the team.

10. Develop a realistic (yet aggressive), schedule to transition consultants into support roles. When developing internal software expertise, typically at first the consultant has primary responsibility for initial software set-up and other application activities (based on client input). However, as the internal team gets up to speed and confidence grows, there must be a plan to transition primary application responsibilities from the consultants to the client module team. At this point and thereafter, the consultants play coaching and support roles. This transition should occur as soon as it is realistic to do so and targeted for specific project milestones / dates. Depending on the client team, it is not unheard of to start this transition after the design phase or after the software is configured(construction phase). At the very latest, the internal team should take primary responsibility once formal testing begins.

11. Make sure the internal team (client team) is available for knowledge transfer. It is difficult for any consultant to educate a client that fails to show up for meetings.

12. Insist that consultants give homework assignments to the project team. The assignments should require the team to work with the software on their own with some meaningful expected outcomes (reviewed by the consultant). Most people learn by doing, struggling a bit and making a few mistakes. In fact it is good to have the client work on assignments when the consultants are not around. If the team does not have these type of experiences on their own, the consultant will become a crutch and an excuse for not doing anything.

13. Require the internal team (not consultants) to perform software demonstrations, design reviews, and management presentations. This is not about throwing your team to the wolves. However, if you expect nothing from the team that is exactly what you will get. These activities should be part of any implementation methodology and must start early and occur often. When the internal team knows they will eventually take the lead for these activities, it drives the perceived need to learn, gets them moving out of their comfort zones, expedites the process and is a good gauge of learning progress. These type of activities also helps the team build confidence in their own abilities.

14. Take advantage of all learning resources available for your specific ERP system. This involves some self-help (a very necessary part of learning) and includes web communities, memberships, and white papers (obtained from the consultants or software vendor). These type of white papers (not to be confused with marketing “white papers”)are very useful since they explain the step-by-step details of setting up the software to perform certain functions.

15. The client team should create most of the project documentation relating to software usage and set-up. Examples are work procedures, end user training materials and system documentation that include screen shots and explanations. The premise is if the client is required to do documentation (with the quality reviewed by the consultants), the client will learn many things in the process.

16. The client team is expected to train all end-users prior to go-live. Again, if you are to train many people you will probably feel the need to learn the software. Keep in mind, consultants play training support roles. (what is required to transfer knowledge to the end-user is a different topic).

17. Put the client team on the frontline of post go-live support. There is no better incentive to learn the software then knowing you will field the real world questions and issues once the rubber meets the road.

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

Reposted completely, and with permission from my friend and author Steve Phillips who runs a Blog entitled Street Smart ERP - Visit his site for great insight and commentary.

The original post can be seen here:

http://it.toolbox.com/blogs/street-smart-erp/erp-consultants-is-the-promise-of-knowledge-transfer-just-part-of-the-sales-pitch-36252

Even though the timing of Apotheker’s departure is a little unusual I can not say I am surprised by it.  If I look over the landscape of a CEO’s job responsibilities (sales, strategy, etc.) and compare that to Leo’s short tenure I don’t see any direction coming from the top.  Leo Apotheker came in at a difficult time, but even in the midst of a global economic downturn it is still possible to succeed.

Setting aside some of SAP’s maintenance fee mis-steps there just hasn’t been a compelling forward-looking vision for SAP.  SAP has done little to inspire the marketplace, and the introduction of alternative maintenance players like Rimini Street means that SAP MUST innovate and create a compelling message.  And even if some argue that SAP has provided some compelling message, I’m an SAP insider, working on SAP projects since 1994 and *I* don’t know what that message is.

To that end, I even penned a plea to SAP calling for innovation and market leadership.  That posting, entitled “Opportunities for INNOVATION SAP, HELLO?” [FN1] laid out some clear, but relatively simple application changes to the ERP flagship product from SAP.  Although well received by a number of SAP insiders it is doubtful that those in key decision making roles will adopt much, or even any of the application improvement ideas.

Where SAP is Missing a Key Business and Market Opportunity for Leadership

In reading through a post on the CIO Magazine blogs (“ERP Costs: 3 Signs Companies Are Wasting Less Money” [FN2]) on Panorama’s comparison of Saas with tranditional ERP it would appear that Saas is not all it is cracked up to be.  SAP has completely missed the boat here on not capitalizing on the GENUINE shortcomings of Saas ERP compared to on-premise ERP solutions like SAP.

Saas ERP is implemented over 35% quicker (11.6 mo v. 18.4), but cost only 10% less to implement (6.2 v. 6.9 ann. rev), and even though CEOs may be slightly more satisfied (< 3% difference, may be margin of error?), business is more disappointed (23.5 sat v. 42.9) and Saas is more often over budget (70.6% vs. 59%).  If this were a head to head comparison by the SAME measures on premise ERP applications have been measured by this would be considered an utter failure and an unmitigated disaster.  But the technology trade publications tend to be eerily silent on this.  Where is SAP’s market leadership in pointing this out?  And on top of that, what about the security issues involved as well?

• It is implemented over 35% faster but only costs 10% less?
• CEO satisfaction difference is marginal so that unless the sampling size is massive (which is doubtful) it falls within a margin of error.
• Businesses are about HALF as satisfied with Saas solutions as they are with on-premise solutions?
• Saas blows the budget about 17% – 20% MORE often than on-premise ERP?  (The % difference between 59% and 70.6% as a proportion of the 59% on-premise budget score).
• Off site (off premise) access and security troubles plague Saas and “Cloud computing” models.
• Another layer and level of contracts and service level agreements which must be correctly navigated.

When you look at the facts and strip away the hype on-premise ERP solutions win hands down.  Even with the on-premise ERP results, by comparison to Saas they look wonderful.

And SAP has done nothing to address this in the marketplace.  SAP has also done little to really address the usability of their software other than to provide a technical toolkit (GUI XT) to allow customers to create their own front ends.  MUCH more could be done. 

SAP could today “apple-ize” their user interface and end user experience to be more intuitive and more responsive to end users.  I’m not referring to an IPod, or IPad touch interface, but more of an intuitive look and feel that would make a user’s daily tasks simpler and less confusing.

What Does the Future of SAP Look Like?

• SAP will need to define and articulate to the marketplace a clearer message about its value proposition and its differences. 
• SAP should focus on end-user experience and a more intuitive user interface to help reduce the change management, adoption, and transition pain.
• SAP should refocus its application landscape messages, its sales messages, and its strengths on business solutions rather than package solutions.[FN3]  Too much time and attention is spent on application features by the SAP literature and sales force and not enough on what those features mean to business.
• SAP MUST develop an internal reference database of EVERY consultant who has ever taken a course, or been certified with them.  For far too long the company has allowed fakes, frauds, and cons to lie about certifications or training and SAP has not provided any way to verify these claims.  It is long past time for SAP to provide a “transcript” of courses and certifications for end-customer use when a potential employee or contractor comes to them.

These and many other straight forward solutions would help to generate marketplace buzz about SAP’s enterprise application suite and provide customers reasons for a purchase or upgrade.

[FN1]  http://www.r3now.com/opportunities-for-innovation-sap-hello

[FN2]  http://www.cio.com/article/531863/ERP_Costs_3_Signs_Companies_Are_Wasting_Less_Money

[FN3]  Over the years I have heard so many SAP sales reps and sales presentations that focus on this SAP application or that SAP application rather than addressing a business need or actual business requirements.  This is a classic sales No, No.  All these sales people do is describe features rather than explaining to the business what these features mean to the business in terms of benefit.  For way too long many in the SAP sales force have relied on the SAP name.

The CIO role in business has been changing almost as fast as technology itself for the last decade.  In the past it was enough to focus on business processes and automation.  It was enough to satisfy the business needs for operational excellence.  By doing this successfully the CIO was given carte blanche, often times large budgets and significant latitude in how best to apply technology budgets.  Those days are quickly fading and today many IT departments and IT organizations are becoming internal vendors to internal customers with “charge backs” to the internal organizations.  They are becoming little more than an internal cost center and “overhead” to the rest of the business.  And this re-alignment of the technology organization is creating significant budget pressures leading to staffing gaps.

Together with these pressures, the CIO and IT decision maker is being pressed to deliver more with less.  More than ever before there is pressure for all levels of IT decision makers to deliver business results–, those results that are focused on customer acquisition, customer retention, revenue growth, and innovation.  What this means is that the CIO or key IT decision maker must focus on being a bridge to the different sides of the business like never before.  The CIO who is able to properly partner with, and integrate into the business as a whole will rise above their peers and be successful.  Those who can not will find budgeting and staffing more and more difficult. 

Today’s CIO has a big job, as this Booz Allen insight article from 2002 [FN1] noted, to succeed they must:

• participate in corporate planning and strategy sessions,
• align and integrate technology initiatives in terms the business understands — speeding products to market, enabling growth, and reading costs and risks, etc.,
• make the case for technology spend and budgets, in business terms, with competing C-level executives,
• develop internal knowledge and collaboration networks.

There are answers, and there are solutions to the CIO quandary about business and IT integration, however, before getting to the heart of the matter let’s take a look at the different roles each position traditionally plays in the enterprise.

CFO (and COO) Alignment is Correctly Focused on Lagging Business Indicators

Intuitively and structurally the CFO role is focused on company finances and company health.  This would be a company’s lagging indicators in terms of business metrics where both operations and finance intersect.  If the company as a whole is doing well then these lagging indicators will show that after the entire process is complete and customer cash is collected and vendor bills are paid together with employee salaries, fixed expenses, variable expenses, etc., etc., etc.  They are lagging indicators, after the entire process is complete, of whether or not the business is healthy and headed in the right direction.  But these lagging indicators are not the best focus.  If you wait until you have ALREADY ARRIVED at your destination to figure out if you took the right path you may not be in business very long. 

To survive in today’s global economy a business must know early on where to make course corrections to stay on track.  Business no longer has the luxury of waiting until the financial results are in to figure out if things are headed in the right direction.

CEO Alignment is Focused on Strategy, Business Growth, Sales, and Marketing

Once again intuitively and structurally the CEO role is focused on future strategy, sales, marketing, and business growth.  This would represent a company’s leading indicators in terms of business metrics.  If the company has:

• New customer prospects in a healthy pipeline
• A steady stream of customers being converted from the pipeline into orders
• A growing backlog while process performance is static or improving
• Existing customers buying more or higher margin products and services

then these leading indicators of future growth and prosperity look good.  These kinds of leading indicators demonstrate future company performance and have been largely lacking from the technology equation.

The CEO, often through the interaction between the sales, marketing, engineering / product development areas also bears the responsibility for new products or services. 

What is the Proper Role of the CIO in the Organization for Business and IT Integration?

Enter the CIO, they have focused on process improvement, automation, and those items related to a company’s fiscal health and performance.  Few technology leaders or technology projects have addressed the leading indicator side of the business equation beyond installing CRM applications (mostly as huge and expensive contact management systems).

In a nutshell, the CIO role, and the IT staff in a properly aligned organization must be business-centric first and they must address business events from both a lagging AND leading indicator perspective.  The most successful CIO will become the bridge between the CEO and the CFO, and thereby integrate business leading and lagging functions with technology.  In other words the successful CIO must find ways to integrate the operational and sales side of the business.  And not just integrate them, but do so in such a way that technology investment and technology spend becomes focused more aggressively on the “demand” side (customer sales and innovation) rather than on the “supply” side (operations, processes, and automation) of the business equation.

This graphic shows not only the proper CFO/COO, CIO, and CEO level alignment, it also illustrates the burden that the most successful CIO and IT decision maker will carry.  Future CIO success with technology in the business will require a more holistic or complete focus on business demand.  The CIO role is becoming larger, and yet more difficult at the same time that the IT organization is under more and more financial and budget scrutiny.  What this means for the CIO, IT Director, or other IT decision makers is that if they do not have an MBA or other formal business training themselves they may wish to look at enhancing their IT departments and IT organizations with true business analysts who also know technology (or can learn technology).

IT organizations and technology budgets that fail to address both sides of the business equation (lagging AND leading indicators) experience:

• significant budget cuts,
• a move into “maintenance mode,”
• their organization support model converted to an internal vendor to internal customers with “charge-backs” for services provided to the organization,
• being closed out of partnership with the business.

As the business as a whole pushes back on what they see as a very expensive IT department they will find their own internal ways around the budget hits from IT.  Internal company departments will avoid budget hits from these “charge-backs” by doing things themselves whether that means manual processes or developing some measure of internal IT autonomy in some of their tech savvy departmental employees.

What Can IT Decision Makers Do to More Aggressively Address Business Needs?

There are a number of approaches that can be taken and a number of requirements that will be needed for a changing job role.

1. Engage the CFO / COO and the CEO in discussions about supporting their business needs.
2. Find ways to actively and directly integrate part of the IT staff into key business departments.  For example, should the Finance, Operations, and Sales departments each have their own dedicated IT staff members?  Or how do you take a limited staff and create a responsibility matrix to maximize business attention on these key departments?
3. Invest in business analysts, those with business degrees or a business focus, who know or can learn the key technologies to support the business.
4. Define and develop a technology strategy execution team consisting of at least one senior level VP or Director from Finance and Operations (appointed by the CFO / COO), Sales, Marketing, and Engineering (appointed by the CEO), and Technology (appointed by the CIO).
5. Have the strategy execution team work together with any of their own key resources to define top level KPIs for IT to business integration.
6. Revisit current KPIs, departmental goals, and metrics to ensure that technology and IT are aligned to these important business measurements.
7. Use the underlying metrics and business goals for the KPIs as the source for both reporting and technology initiatives.

[FN1] Boochever, J., Park, T., Weinberg, J., CEO vs. CIO: Can This Marriage Be Saved? Booz Allen Hamilton, Strategy Business Online, July 17, 2002, retrieved online February 6, 2010 at http://www.strategy-business.com/article/20571

Part 1:  What is the Proper Relationship for the CIO, CEO, and CFO?

In the first part of this series we looked at the changing business landscape and what it means to the CIO, IT Director, IT Manager, or other key technology decision makers.  From a high level the current global business competition, as well as economic issues are directly affecting the C-level executive requirements and the CIO – CFO – CEO dynamic.  This article reviewed how and where the CIO role is coming under tremendous pressure and how to change the current dynamic by more appropriately partnering with the CFO and the CEO.  This partnership is a critical business bridge between lagging business indicators of business financial and process health on the CFO – COO side of the business house and the leading indicators of sales and product or service pipelines on the CEO side of the business house. 

Part 2:  CIO, CFO, and CEO Alignment – Why ROI is Lacking from Today’s System Landscape

The second part was an overview of the current system landscape and its focus on business processes and the emerging trend of trying to focus on the customer.  This piece also looked at the future business landscape and how the technology focus and direction will be permanently changed no matter what happens with the economy and global competition.  Because the technology marketplace (business consumer) is becoming more sophisticated and more attuned to business / technology alignment, the IT dynamic is going through a structural change.  The whole technology sector is slowly moving away from the “operational excellence” value proposition to the “customer focus” and “innovation” areas of the business.  Very few of the consulting companies and few of the application vendors see this sea change and are doing little to address it.  This is the area of technology market winners and losers of the next 20 years.

Part 3:  Changing the Direction of SAP, ERP, and IT Applications to Focus on the Customer and Innovation

The third part in the series looked at current technology landscapes and how they are aligned and then looked at future technology landscapes.  A brief review of the supply side and the demand side of business shows that unless you have lots of customers (demand) to fill a bigger and bigger pipeline (supply) then your business model collapses.  While it is hidden during good economic climates, any disruption in those economic conditions which fails to fill the capacity pipeline points out the glaring insufficiency of the “operational focus” to technology.  During any economic disruption, or any reduction in demand from customers for your products or services the current technology model falls apart. 

Part 4:  Future Technology Landscape Alignment for the CIO, IT Director, or Key IT Decision Maker

The final part of the series looks at the emerging technology landscape and what the future holds.  It lays out an emerging technology landscape model which has some re-alignment and some components already in use by some of the world’s most successful companies.  A new alignment of technology with the customer facing processes, and the use of social or collaboration tools across the enterprise with a clear business objective is explored.  The driver for the future change will be because the business does not see the revenue generation prospects of technology–, they fail to see the possibilities of promoting customer retention, customer acquisition, innovation, and marketplace analytics.  The new technology model looks to change that dynamic.