INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

SAP Change Management Program Success

July 30th, 2012 by
SAP Change Management

SAP Change Management

Lots of literature, information, and resources focus on change management for successful enterprise application projects.  To help address SAP change management the SAP ASAP Methodology provides lots of resources, tools, and templates along with guidance for Change Management during your SAP project.  This is one of the key reasons for Why to Use the SAP ASAP Methodology?

Even though the ASAP methodology and various other resource provide some great sources the high level guiding framework always seems to be a little vague.  For example, there is a constant message that people resist change and that it is so hard.  That is not true.  As I have often said, if people resisted change no new product or service would ever be sold.  No new invention, gadget, method, or anything else would ever be developed.  There would be NO innovation in anything.

People do NOT simply resist change–, they resist change they do not understand and change they perceive is a threat.

Applying Sales and Marketing Principles to SAP Change Management

If sales and marketing departments for every type of organization in the world manage to sell new products or services maybe we should look to them for what works.  For both marketing and sales there are four key phases for customers considering a purchase:

  • Awareness (Marketing)
  • Consideration (Marketing, sales)
  • Evaluation (Sales, marketing)
  • Purchase (Sales)

These four general stages or phases of buyer behavior correlate well to a solid change management program–, messaging, engagement, credibility, and commitment.  To be successful you must be committed to Leading Change (and Change Management).

1.  Messaging – This is the beginning of the stakeholder analysis process.  Exploration, active listening, and facilitation are critical.  At this stage messaging is outbound.

Product or Service Sales Phase

Awareness

Customers understand and can communicate their desire or problem or need.  What are your constituents facing?  What are their struggles and what will help them do what they need to do better?  If the change will add more burden to them then why is the change necessary? 

Enterprise Change Phase

Discovery and blueprinting

A good SAP or enterprise application change program must start right from the beginning of the project.  First the identification of the key stakeholders at all levels of the organization must be made.  Afterward a clear effort must focus on the benefits to the affected users.  You must focus on the WHY of Achieving Business Value from SAP Investment.

A system-centric blueprint which does not connect to user needs will only breed mistrust and fear.

Analysis

Surveys are distributed and results tabulated.

2.  Engagement – Deeper determination of the issues, active communication, and targeted messaging.  Stakeholders at all levels must be encouraged to participate and be heard.  At this stage communications and messaging just start to go both ways (inbound and outbound).

Product or Service Sales Phase

Consideration

Marketing and communications are directed at addressing customer desires, problems, or needs.  Assurances are provided that the product or service will meet those issues.  The customer begins to solidify whether or not to explore a purchase decision.

Enterprise Change Phase

System functionality demonstrations and stakeholder feedback

Key stakeholders have the first part of their issues addressed.  There are 4 key types of change categories each user fits into here.  They are:

  • Opposed
  • Unsure, anxious, or fearful
  • Accepting or willing
  • Promoting

This phase of the change process is designed to aggressively uncover and then address those who are opposed or anxious about the upcoming changes.  These key stakeholders must be heard and their concerns answered.  It is also where the key message around SAP Service Delivery versus Value Delivery is promoted.

Analysis

Survey results are synthesized, reviewed, and then communicated to the broader enterprise.  Action plans to address the survey results are developed.  Any evaluation metrics are defined.

3.  Credibility  – benefits messages, demonstrations, insight, and information.  Change activities must promote openness and clearer understanding of the reasons for change.  More of an inbound and outbound dialog begins to occur.  Communications are actively going both ways.

Product or Service Sales Phase

Evaluation

Understanding of key features of a product or service and how they are different or better than competitors occurs.  Price considerations are also important.

Enterprise Change Phase

Aggressive information sharing and open dialog

One way you can Achieve Business Benefit is Through SAP Prototype Demonstrations.  Part of the communication and benefits program involves live system demonstrations (demo days), active engagement of super users, subject matter experts, and key change agents throughout the organization.  Messaging would also include external web resources, links, presentations, and other information to help “sell” the organization on the coming changes.

The goal of this phase is to overcome objections, fear, and anxiety.

Analysis

Action plans from the surveys are communicated to the organization and execution activities are carried out.   Evaluation metrics are refined, communicated, and adjusted to the organizational requirements.

4.  Commitment  – full user participation is critical at this stage.  If they are not involved in the process all of the previous effort falls apart here.

Product or Service Sales Phase

Purchase

For the purchase of a car this is the test drive and price negotiation.  For services or other items it is the understanding of key differentiators and how the service will help or enhance the customer’s issue, customer references, and possibly case studies.

Whether it is a test drive, understanding differentiators, price negotiations, or the benefits of a product or service these are all directly related to building a level of trust which in turn produces commitment.

Enterprise Change Phase

Acceptance, Adoption, and Promotion

More user demonstrations, training, super user network, subject matter experts, and pilot processes are all important here.  This is where everything starts to come together. 

This is also where any changes to originally expected benefits or reductions in scope must be carefully managed.  Another key area is the Organizational Change Management Inside the SAP IT Support Organization.  A key component at this phase involves Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1 (and Part 2).

The goal of this phase is to produce acceptance and even promotion of the changes.  However acceptance, adoption and promotion are not possible if the stakeholders have not established trust in the coming change. 

Analysis

Execution activities are carried out and nearing completion.  Reviewing, analyzing, and then distributing the results of the previously defined metrics results occur.  Lessons learned are captured and communicated.

Conclusion on SAP Change Management for Business Application Project Success

Every phase of your SAP or enterprise application project must be wrapped in the appropriate change management processes.  Just as with sales and marketing people do not resist change as much as they resist change which they perceive as a threat or do not understand.  So the key is to learn to sell the change and its benefits so that the perception of a threat is removed.  In doing so you will help to transform your project and company into a winner, both now and in the future.




Popular Searches:


  • sap prototype
  • SAP Change Management Methodology
  • prototype sessions in ERP
  • how much change management for ERP
  • is there a prototype material in SAP?
  • open sap prototype
  • prototype invoice
  • prototyping and peer review in SAP
  • sap change management key messages

Related Posts:

Achieve Business Benefit Through SAP Prototype Demonstrations

July 16th, 2012 by
Imagine what is possible by showing what is achievable

Functionality Prototype and Demonstration

SAP Conference Room Proof of Concept Pilots

Proof of Concepts with frequent early prototyping drive project costs down.  It is like the old saying that “an ounce of prevention can avoid a pound of cure.”  Proof of concept pilots during the project is one of the rarely mentioned SAP critical success factors. 

Early in my SAP career I used to get a little frustrated by the disruption these prototype sessions, conference room pilots, or whatever you want to call them would cause.  My thought was I had a job to do and didn’t have time for this.  No one ever stopped to help me understand WHY these pilots and prototypes are important.

Before I get into the substance of this let me first be very clear about what I am referring to–, a prototype, pilot, or demonstration is ACTUAL system functionality set up in the application to demonstrate transactional business processing.  I have heard of some system integrators who call PowerPoint process flows these types of “pilots” and that is completely ridiculous.  That is just regurgitating SAP Blueprint process flows and is NOT a prototype, pilot, or system demonstration at all.

Stop the SAP Consulting Merry Go Round – Real Life Experiences

Nothing is more frustrating than trying to work through a complex issue and going around and around with meetings, discussions, process flows, etc.  At one client we had a very complex third party process which involved one foreign company code doing sales deliveries for a domestic company code, but the domestic company would bill the customer and collect the cash, the foreign company would do inter-company billing, etc.  There was not only third party processing involved, there was also foreign trade, batch, and serial number tracking required (YUCK!).

After getting a large and very expensive group of consultants together with key client resources we hammered the first pass out.  Then we did it again a few days later, and then again a few days later.  After about 4 or 5 weeks of this madness it turns out the consultants were the problem more than the client.  Several of the consultants essentially said this couldn’t be done.

To stop the complete waste of time I left the last meeting and spent 3 days setting up a prototype the consultants said couldn’t be done.  Now, in their defense it is complicated and it DOES involve setup in SD, MM, PP, FI, and EDI.  Very FEW consultants have ever done this type of integrated setup.  I scheduled a DEMONSTRATION with all of the key stakeholders and project leadership to put this issue to rest.  The SAP standard functionality covered approximately 90% of the overall requirement and we were now discussing small tweaks or changes that were required rather than trying to over engineer a customized process mess!

Reduce SAP Implementation Cost, Improve SAP Quality, and Manage SAP Scope More Effectively

Using Conference Room Pilots, or Functionality Playbacks is effective for difficult to understand processes system demonstrations.  This technique can significantly reduce meeting times and increase customer satisfaction.

Stanford professors Carleton and Cokayne spent seven years studying the user of physical prototypes in “foresight engineering” which is the ongoing development of products or services that are three or more product cycles in the future.  They studied the use of prototypes for “capturing and communicating a team’s opportunities inside the organization, connecting the company’s vision and strategy with… day-to-day [engineering design work], and helping teams to connect vision to research to engineering design.”  Carleton, T., and Cockayne, W., (2009) The Power of Prototypes in Foresight Engineering.  International Conference on Engineering Design, ICED’09/493, Stanford University, August 24-27 2009, page 1.

The use of prototypes has been found to “make ideas tangible, iterate quickly at a low cost, and develop a shared language” (ibid.).  These demonstrations are part of the change management process and can help to bring the broader organization along in the process. In the second half of the post on ERP, SAP, or IT Project Management and Prototyping for Success more detail is provided for the following items:

  • System demonstrations focus on delivering what is important while allowing for early adjustments.
  • Complex or difficult functionality demonstrations help reduce the overall amount of meeting time.
  • System demonstrations identify gaps and problems earlier reducing the number of testing defects and rework time.
  • Early demonstrations help ensure scope is properly accounted for and last minute process surprises are reduced.
  • Some performance problems are exposed.
  • Possible schedule and work completion issues may be exposed while they might still be manageable.

By doing a LOT of prototypes early in a project you also quickly separate the good IT resources from those who are not so talented or even those who are complete fakes.

Conclusion on Using SAP Prototypes, Functionality Demonstrations or Conference Room Pilots for Project Success

Just as the real world example I noted above shows, by using prototypes or demonstrations to understand where the real business requirement gaps are you may be able to avoid a major investment in custom development work.  And by avoiding that development you reduce ongoing maintenance headaches.

As for dealing with scheduling and work completion I have been on many projects where some of the consultants or team leads would simply lie about their status and completion.  By having a clearly defined pilot and playback schedule throughout the project for certain key functionality you help to ensure that what is committed is actually delivered.  Too many times the real status does not show up until testing starts, or worse still, items get taken out of scope because of misleading status.  By then it is too late.




Popular Searches:


  • www r3now com
  • success factor sap
  • Be an SAP Consultant in few days
  • factors for success of asap

Related Posts:

SAP System Vendor Project Success Criteria & Factors 3

November 15th, 2010 by

SAP drives business performanceThe other day I made a post to SAP’s Community Network on making sure customers get the best SAP business software integrator for their money.  One of the comments to that post suggested I was advocating for customers using ONLY SAP as their system integrator.  My response made it pretty clear that my goal is to encourage SAP customers to get educated so they actually achieve value and ROI from their SAP business software projects.  My response sums up why I started this site and what the posts here are all about.

Don’t waste money on consultants who cannot help you implement business software in ways that improve your business!

And to that end we will look at the implementation of SAP or other large business software applications.  Continuing this series of posts on shared success criteria, please see the table below for more information.

No. SAP or ERP Critical Success Factor Company Integrator
5 Experienced SAP consultants   A
7 SAP implementation strategy z A
8 SAP project management A z
9 SAP tools, templates, and resources   A
10 SAP scope development z A
11 SAP scope management A z
12 Strong SAP project and business communication (inward and outward) A z
13 SAP change management A z
15 Sufficient SAP training (user and project team training) A A
16 SAP system vendor and customer trust   A
17 SAP system design decisions z A
18 Amount of custom ABAP or other SAP coding z A
19 Appropriate SAP software configuration (system settings) z A
20 SAP system change control process   A
21 SAP data analysis and conversion A z
22 SAP test planning A z
23 SAP test development z A

Legend

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

16.  SAP System Vendor and Customer Trust

I place this SAP critical success factor (SAP CSF) clearly in the SAP system integrator column.  I can’t say it any clearer than you are writing the checks for an SAP system integrator who needs to deliver value, otherwise what are you paying for anyway?

Trust, but verify – Why would you pay an integrator or their consultants who do not deliver business value?

SAP System Vendor “Trust but Verify

There is a Russian proverb which states “trust, but verify” or, its English equivalent, “better safe than sorry.”  The phrase gained popularity in the United States during the presidency of Ronald Reagan.  He often used the phrase when dealing with the Russians about nuclear weapons.  When the U.S.-Russian INF (Intermediate Nuclear Forces Treaty) was signed, Mikhail Gorbachev commented to Reagan that he used the phrase at every meeting, to which Ronald Reagan replied “I like it!”

How does this relate to you and your SAP project?  The whole idea behind the proverb as used during the Nuclear Treaty discussions was the ability to monitor compliance with the treaty details.  Just like this nuclear weapons discussion was critical to the relations and operations of the two nations, and even the world, so is an SAP implementation to your company.  A business software system project is critical to competitive advantage, efficiencies, operations, innovation, and even customer acquisition and retention.  A properly implemented SAP business software system is critical to navigating a hostile competitive global business landscape. 

Progress monitoring, deliverables verification, and QA assessments must take place throughout the project lifecycle.

See the list of SAP ASAP Methodology deliverables by project phase.  Your SAP sales rep or SAP system integration vendor will have access to the most recent ASAP methodology and can provide you with the SAP standard version of the requirements.  Unfortunately because of the way the SAP copyright is written on the material I am unable to directly distribute it legally.

How do you “trust but verify?”  Here are some tips for ensuring this:

  • Ensure that you consistently communicate your expectations to the system integrator
  • Make sure your integrator provides a clear project plan with key project milestones (from the ASAP methodology).
  • Ensure that there are deliverables that have a connection back to the project activity being completed (again, from the ASAP methodology).
  • Verify that the vendor has a complete set of deliverable templates they can show you and explain ahead of time how they will work and how they are used to track SAP project progress.
  • Perform a “mini-audit” at each project milestone with business stakeholders making the determination whether the deliverable(s) were sufficiently addressed and whether the upcoming deliverables templates appear sufficient for the next milestones.
  • At the end of each project phase ensure that you perform a QA check of that phase before continuing with the next.  This is a standard SAP methodology process but is rarely followed by many consulting firms.

17.  SAP system design decisions and

18.  Amount of SAP ABAP custom coding

Both of these topics are directly related and with SAP in particular they are pretty much interchangeable.  The academic literature breaks these two critical success criteria items out because SAP is not the only business software package that is evaluated.  With SAP in particular the depth and breadth of business software functionality is so significant that custom coding should only be used if there is no close fit from standard functionality.

Before you begin your SAP project it is imperative for you as a customer to decide whether or not you want to do software engineering or business process engineering.  This post explains the differences, what the consequences are, and when it might be appropriate:

SAP Implementation Focus, Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering

The amount of custom-coding and software engineering you engage in will have a dramatic affect on your overall SAP TCO (Total Cost of Ownership).  This will also have a significant impact on the amount of budget you allocate to critical change management activities and to ongoing software support and maintenance.

  • Set a project expectation with the system vendor that everything you had in your scope must be delivered with standard functionality.
  • Create a change review board to address any scope change requests AND any custom coding requirements.
  • Create a contract provision with terms stating you will get ( x ) amount of a credit when a custom coded solution is proposed that had standard package functionality addressing ( x ) % of the business requirement.
  • Ensure that every custom coding decision includes a written justification with:
    • The standard functionality that was evaluated.
    • Why the standard functionality would not work (what were the gaps).
    • What the business justification for the custom coding is (is it business / mission critical?)
    • Alternatives considered (remove from scope, third-party software, manual process, etc.)
    • Business impact if removed from scope or manually performed.
  • If a decision is made to pursue the custom development then a standard functional specification must be completed.  A good template to start with can be found in the SAP ASAP methodology.  It should contain:
    • Detailed requirements.
    • Expected effort and cost.
    • All SAP module or other areas affected (in other words is this custom development going to be a huge project distraction by consuming too many of the consultants’ time and effort).

19.  Appropriate SAP Software Configuration (system settings)

The system integrator is hired to set up the SAP software.  Through the sales process they’ve convinced you their consultants have the experience you need for success and you hire them for your SAP project.  They are the experts and you have to rely on them because you don’t have the internal experience.

This is where good SAP consultants come into play.  The SAP ERP application contains so much functionality that nearly any business process can be addressed.

Appropriate software configuration is one of those things that is usually discovered at integration testing.  By that time in the project it may be too late to make significant corrections or adjustments without jeopardizing the entire project timeline and budget.

Make sure you invest in your own project team’s training

As a customer there are several things you can do to help ensure that the correct SAP software configuration and settings are made even though you as a customer may not know what they should be.  Here are the major ways to ensure good software configuration.

SAP Project Team Training

First and foremost to ensure appropriate SAP software configuration and to ensure you get good SAP consultants make sure you invest in your own project team’s training.  This critical training should be budgeted for right from the beginning and do not let any SAP system vendor talk you out of it.

An educated client is a sophisticated client, and sophisticated clients usually have the best implementations.

Some system vendors will try to convince you that they can teach your project team rather than having you send your people to independent SAP training.  That is a great way for them to “control the message” you receive about SAP’s functionality and the consultant’s level of skill.  Often times the “pitch” they use to try to sell you on the idea that they should be training your people instead of you sending them to training is that it is cheaper.  But if you do the math for the consulting hourly rates and then factor in the consultants’ time away from value added implementation efforts it doesn’t add up.  Often it is less expensive to send your project team to formal training and even if it isn’t, you still need that independent oversight.  Only independent training ensures your people really know what they need to know.

SAP Prototyping and Proof of Concepts for SAP Project success

I personally favor the prototyping approach.  The reason is that if you are a customer who wants to make sure you have the resources you are paying for this is the easiest way to find out.  By requiring a baseline proof of concept no later than the end of your Blueprint phase you will quickly see which consultants have real experience that the SAP system vendor has provided.  By contrast you will also see those who lack the experience as well.

In the SAP ASAP methodology one suggestion is that the initial baseline prototype (the first one done right at the end of blueprint) might cover 50 – 80% of the business requirements. 

For more information on prototyping and the steps for ensuring project success please see the post ERP, SAP, or IT Project Management and Prototyping for Success at http://www.r3now.com/erp-sap-or-it-project-management-and-prototyping-for-success  

Be sure your system integrator’s consultants do FULL END TO END process prototypes.  For example just doing a single transaction is not enough to demonstrate the system will meet the business needs.  By the end of Blueprint a seasoned and experienced consultant should be able to demonstrate these simple, straightforward, and standard processes.

  • In the SD area (Sales and Distribution) an order, and then delivery with picking and goods issues, and then an invoice must be created.  You may wish to have them post cash and then review the material and accounting documents as well.
  • In the PP area (Production Planning) maybe you want to see independent requirements run through MRP and then convert the results into the purchasing and production documents.  From there you may wish to have them do the receipts, and the confirmations of the production on a material, and even shows costs.
  • In the MM (Materials Management) area you may wish to integrate this with PP (or not) and have the consultant show you the requisition to PO to Goods Receipt to Invoice receipt and then application of cash payments to the vendor.

In other words a skilled SAP consultant can do the setup work to do at least a first pass at all of these processes by the end of Blueprinting.

Significant benefits of SAP Prototyping and Proofs of Concept

I strongly favor SAP prototypes and functionality demonstrations throughout any SAP project.  Prototypes can quickly expose process gaps, potential integration problems, business process issues, and ensure that testing is smoother.  One of the significant advantages of prototyping is that it places an emphasis on overall business processes.

By relying heavily on prototypes and functionality demonstrations throughout an SAP project you help to ensure that the project team works more closely together, that only the best consultants are provided by the integrator, your internal client project team acquires more knowledge sooner in the process, and a better go-live.

Related Posts: