SAP & ERP Consulting from the Customer Point of View

SAP implementation ROI, SAP architecture, & SAP business solutions

ERP III – Is the Integration of Collaboration the Future of Enterprise Applications

February 11th, 2010

Corporate Collaboration

Back in the late 1990′s, while at Grant Thornton, and then later when the management consulting organization was sold to Hitachi I worked on a comprehensive knowledge management model (see the image below).  The model  has application and relevance to integrating collaboration tools into any enterprise application.

Carefully structured and planned integration of collaboration tools can produce great results,  but it is a challenge.  Finding ways to tie collaboration into the business technology for productive use in the enterprise is the goal of a lot of social media types but few of them have any idea how to do this.  Clearly there is a lot of hype around “Web 2.0″ interactive functionality but little in the way of productive business use.

By moving outside of the enterprise walls to integrate customer interaction and the extended supply chain the enterprise can gain valuable insight.  By using structured data gathering and organization techniques business value can be achieved.

In this post we will look at a few approaches I’ve taken over the years that have been effective and powerful for creating dynamic collaborative organizations.  They don’t use the trendy new tools like Facebook, or Twitter, or other communication mediums, but they do leverage the collaboration concept.  Maybe someone can create a use model for tools like Facebook or Twitter combined with enterprise applications.

Why Enterprise Collaboration Tools have Not Yet Taken Off

Too many organizations undertake the introduction of social media for the purpose of introducing social media into the enterprise.  In the Knowledge Management area this is like having information without any context of how to apply that information or the experience to apply it properly.  Information alone is NOT knowledge and social media or collaboration tools which do not have a specific business purpose are not very productive (if at all).  Without a specific “context” to apply social media tools, and the understanding of where they might fit, and how they will be used, they are more likely to be a distraction (see Social Media Fads and the Risk to the Enterprise ).

There are few methods, and even fewer tools to filter through all of the “noise” from social media tools to find what is meaningful.  From there, it is still even more difficult to distill what is meaningful into something useful.

So, for example, Facebook, MySpace, and Twitter may NOT fit in your enterprise.  However, being able to capture employee, customer, and vendor knowledge, suggestions, or criticisms (information) and then publishing this internally to the right people (the context of applying that information) may make a huge difference for your company.

Few social media “gurus” have any idea on how to start this type of structured information gathering dialog from an unstructured information source (see the graphic below).  They do not know how to develop a structured program to take advantage of the unstructured data by finding meaningful ways to apply that information.  There are few methods, and even fewer tools to filter through all of the “noise” from social media tools to find what is meaningful.  From there, it is still even more difficult to distill what is meaningful into something useful.

What do they say in response to this?  What is their excuse?  You don’t understand social media and it is all about building relationships and you haven’t spent enough time and you can’t apply old business rules and, etc., etc., etc.  Snake oil, snake oil, snake oil…  And I have lots of swampland in Florida that was never hit by the housing downturn and it is worth more now than ever!

All you get are excuses and that you’re not doing enough or spending enough.  Few social media”gurus” have any idea at all on how to generate real value from these new channels.

Why Consultants and Collaboration Evangelists Have Not Shown Much Progress

Neither consultants nor business have learned how to use social media to drive business value.  There are few consultants out there with a coherent or even minimally functional method for business to use collaboration or social media tools to propel a company’s key value propositions.  Even if you move down one layer beneath the value proposition to the competitive pressures in the marketplace these “social media mavens” there is still no coherent method for social media use.  Beyond things like video conferencing and webinars which help to reduce expenses related to travel and coordination, not much has been done to move social interaction in business to the next level.  There is a lot of hype, a lot of claims that this is the “next big thing” but not a lot of substance yet.

The real issue is not to use social or collaboration tools in the enterprise just to collaborate.  They must serve a business purpose and a business need.  The business enterprise is not a social club, but social tools can be used to serve the business purposes or goals.

In my prior post on SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration there are 9 steps noted toward the end of that post on exactly how to use open source forum software for developing a learning organization.  That integration doesn’t deal with the cool, hip, or trendy social media tools of today, but they are effective collaboration methods.  The same concepts in that post can be generalized and applied to knowledge capture activities around innovation or customer experience.  The way you use these forum type tools inside the company depends on what your goals are, but the instructions for use are there.  And properly used they can be very powerful business tools for competitive advantage.  Little if any of this type of direct, clear, and understandable use case information exists for the “trendy” social media of today.

Toward Transforming Information to Knowledge – A Working Knowledge Management Model

By using collaboration tools properly, or by finding meaningful ways to use the Web 2.0 tools in a more structured way, it is possible to make systematic progress to support business purposes.

Back in 1997 and 1998 I worked through the model and developed a systematic approach, by using primitive collaboration and social media tools, to convert consulting into knowledge centered learning organizations.

It relied heavily on:

  • collaboration,
  • cooperation, and
  • information dissemination.

This was done by using the tools that were available at the time.  A systematic process was developed to capture, then synthesize, organize and disseminate the information and knowledgeable individuals throughout the organization.  By doing this a collaborative learning organization was developed.

The knowledge management graphic and model I produced years ago (see below) was used to advance the concept of a learning organization because that was a clear business fit for consulting companies.  A consultant’s capabilities are directly tied to their knowledge, and that knowledge is a consulting company’s capital or stock in trade.  From that learning organization real business transformation and business benefit can be achieved.  A learning organization is more dynamic and adapts to change more readily.  As a result of the ability to absorb change, dynamic market conditions help ensure you are a leader rather than a laggard in the marketplace.

Early Collaboration and Social Media Efforts that Started to Produce Results Shortly After Y2K

Even the most knowledgeable, talented, and proficient consultants get stuck at times. The nature of complex business and technology problems means there are times you need a little help.  At Grant Thornton, and then later at Hitachi, we recognized the need to have dynamic but high quality tools, templates, and resources available to consultants.  At the same time we also recognized the need to be able to tap into other knowledgeable experts within the organization on a moment’s notice, even if the consultant who needed the help didn’t know the individual.  Outside of a consultant’s own personal network they didn’t know where to look for the specific skills or expertise they needed to resolve a particular issue.  The solution had to be simple and almost instantaneous.

It had to be, the right knowledge, right now!

We wanted a structured method that was simple and intuitive to create a collaborative environment.  After looking at our technology landscape right after Y2K we started to use MS Exchange Public Folders, Outlook Shared User Folders, e-mail, and MS Messenger.

A Simple Collaborative Solution Using MS Exchange Public Folders and MS Messenger

We developed an MS Exchange folder structure that matched our client project needs and sales force needs for tools, templates, resources and our own best practices on demand.  The beauty of MS Exchange was that the Web Access version allowed our consultants to leverage public folders through the web interface from anywhere, just like they were using MS Explorer / MS File Manager.  The public folder structure was the perfect fit because there was little to learn beyond the new folder structure of how we would store the data.  Dragging, dropping, and opening files in this MS Explorer like interface was intuitive and took no time to adjust to.  This was immensely helpful at some client sites where security is very high so that only the client’s computers or hardware were allowed on the client’s corporate network.  In other words, where access to internal resources would have been limited or non-existent this allowed for ready access to anything that was needed.  Add to this the MS Exchange folder permissions are robust so security was meaningful.

Together with this we used MS Messenger, but rather than just having an employee’s  name which was unknown to those outside that employees “circle” or network, we applied their key skill to the logon name.  From a standard list of key skill codes for SAP (SD, MM, PP, FI, CO, AM, CRM, SRM, APO, etc.) we placed that in front of the person’s name so that it automatically grouped like skills, and placed the skill reference first in a list of over a hundred resources.  In an instant if you needed some input from a seasoned Sales and Distribution person you would just look on the list for those names starting with SD_Employee_Name.  SAP practice users were then exposed to each other all over the United States and even in other countries by their skill codes so that even if they did not know the user, if they had a question of a colleague or peer they could just ask in real time.

There was also a regular weekly publication containing special “tips and tricks” for productivity or functionality.  This was simply sent through e-mail and a copy stored in the knowledge management folder in MS Exchange.  It could be referenced at any time in the future.  This created a reusable knowledge repository that allowed the quality of the tools, templates, resources, presentations, and other material to be continually advanced and quickly reused.

When I left we had just started on the internal forum posting initiative.  This was to provide a central location to capture knowledge sharing or information discussions in a searchable database.  Using open source content management systems and open source integrated forums our goal was to create a central communication collaboration hub to capture and exchange ideas, custom coded solutions, and best practices.  With the many available add-ons to the open source CMS systems we considered adding an internal high level project management status tracking system and resource request system for senior level managers to gain near real-time visibility to the status and resource needs of all of the many projects taking place all over the country.

This was a very practical way we leveraged existing social and collaboration technology by building the structure and processes to add business value.  It enhanced the customer value proposition by providing better and faster customer solutions, more customer focus, and better internal employee interaction.  In other words, this whole solution was low cost and used existing collaboration tools to advance business interests.  It helped to promote end client satisfaction because of the nature and ability to gain “the right answer right now.”

The real issue is not to use collaborative tools in the enterprise just to collaborate.  They must serve a business purpose and a business need.  The business enterprise is not a social club, but social tools can be used to serve the business purposes or goals.

Refinements, Enhancements, and New Dimensions to Collaboration and Knowledge Tools

As the efforts and my research on the subject matured I wrote a piece about my perspective on this issue as it had matured and called it SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration.  That article laid out a way to integrate social media tools like Forum software into the SAP help system.  What this means is that end users can capture real time information about the system, or shortcuts, or requests for simplification or other useful information and disseminate it to the organization.  This also provides a method for workers in any department or area, in real time, to provide feedback that focuses on the company value proposition or competitive pressures.  Here is the model I produced:

1)  Raw Information:  The unstructured data, ideas, “crib notes,” and thoughts that we all have.  However in this instance, it is the raw information surrounding the job or responsibility that the individual performs within the enterprise.  Sometimes these are the “workarounds” to get something done when you run into obstacles or roadblocks, other times they are just shortcuts, techniques, to perform a job or function.

Knowledge Management Process

2)    Organized Information:  This is the process of capturing and classifying that raw information.  This is where the “knowledge bases” and other types of information systems come in.  Many enterprises make it this far. Sometimes these are the “workarounds” to get something done when you run into roadblocks or obstacles.  Other times they might be the shortcuts or techniques to more efficiently perform a job or function.

3)    Acquired Information Experience: This is the interaction with the organized information.  This can be through search functions, employed taxonomies, reports, or other methods of accessing the organized information.  This is after the capture of the information in steps 1) and 2) above, and involves its wider availability than in the individual who originally developed or “held” the knowledge or information.  Few organizations or enterprises make it much further than this.  However, this is the beginning of the true learning organization.

4)    Applied Experience (Knowledge!):  This is the practical application of the organized information after it has been acquired.  Whether this acquisition is through word of mouth, training, or some type of information management system (that is wrong named a knowledge management system) or through a “knowledge base”. This is where the cost savings, revenue opportunities, continuous process improvement opportunities, and real competitive advantage begins to come to fruition.

5)    Refined Experience:  This is more of the inherent “knowing” what to do in a broad variety of contexts that may not be directly related to the task or issue at hand.  It is when an individual can draw on that level of inner experiences mixed with intuition and make the right decision or provide the right answers when there is not enough information to make such a determination under normal circumstances.  This can also be a type of “making the complex appear to be simple.”

This knowledge model I created in the late 90′s seems to be pretty well accepted today [Fn1].  Notice it is very different than an information model because knowledge by its very nature requires information together with the context of how, what, and when to apply that information together with experience.

The ERP III future will rely heavily on delivering on the value propositions of customer focus and innovation.  By moving outside of the enterprise walls to integrate customer interaction and the extended supply chain the enterprise can gain valuable insight.  By using structured data gathering and organization techniques business value can be achieved.

It is my belief that both of these pillars will occur through the use of corporate collaboration tools–, but only corporate collaboration tools that are focused on the business goals of capturing critical “knowledge” and information around these two key premises.

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

[FN1]  The knowledge model I produced was based on a synthesis of a number of sources I had studied at the time to try to bring some clarity around the confusion between “information management” and “knowledge management.”  At that time, or possibly earlier, there may have been someone else with the same ideas and a similar model but I couldn’t find it then.  Today I see too many variations of these terms but the same basic process all over the place.  If someone else can claim *earlier* authorship I won’t dispute it.  I produced my first version before Y2K.

Related Posts:

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

February 10th, 2010

Cloud ComputingIn reading through a post on the CIO Magazine blogs (“ERP Costs: 3 Signs Companies Are Wasting Less Money” [FN1]) 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, the Saas cloud computing results 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. I’ve written about some fairly ”easy” ways SAP could innovate their application environment with little cost or difficulty as well.  That article, entitled “Opportunities for INNOVATION SAP, HELLO?” provides insight from what I believe is a customer perspective on application usability and simplification. 

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.[FN2]  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.

This last issue of having some type of transcript or other reference service for consultants who claim to have taken SAP training can not be underestimated.  This has a direct impact on the quality of the implementations and the marketplace perceptions of the application.  Because of the widespread fraud in the marketplace and the constant claims of “certification” or training classes by those with fake resumes the value of the training is destroyed, and the quality of implementation solutions is damaged.  No wonder so many companies are frustrated with a lack of ROI. 

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.cio.com/article/531863/ERP_Costs_3_Signs_Companies_Are_Wasting_Less_Money

[FN2]  Over the years I have heard so many SAP sales reps and sales presentations that focus on this 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.

Related Posts:

ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?

February 10th, 2010

CEO CIO CFO AlignmentMost 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


Related Posts: