Business - IT Convergence

Proper SAP project governance is a function of the business in partnership with IT.  With the exception of a few of SAP’s technical applications (like parts of Solution Manager, HANA, etc.) the entire application suite is about business; business transaction processing and business processes. If key business resources are not directly engaged in SAP project governance you may never realize the SAP benefits you expect.

This brings me to the point of what benefits you expect from an SAP implementation?

From what I have seen there are generally 2 broad “buckets” of benefits on SAP projects.  The first “bucket” is focused on consolidating and eliminating systems while the second is all about transactional business execution.  Or, IT benefits and business benefits.

SAP Project Drivers in IT

The first benefit “bucket” is related to pure IT cost reduction with a focus on consolidating and eliminating legacy systems for many of the following reasons:

• reducing numerous applications’ license costs
• narrowing technical infrastructure needs
• simplifying technical architecture
• reducing system maintenance costs
• reducing legacy staffing needs
• standardizing on a single development platform

If your SAP project is more of a pure landscape play, around replacing legacy systems, then SAP project governance would fall more clearly under IT.  However these types of projects usually end up having the business user community demand that all legacy system functionality be meticulously reproduced in SAP.  In the end you will likely achieve some measure of savings but far less than you originally anticipated.  Any expected savings will generally be consumed through mountains of custom coded solutions which will need continual care, maintenance, and feeding after go-live.  These custom coded “solutions” are not supported by your SAP maintenance agreement and can eat you alive in post-production support costs.

SAP Project Drivers in the Business

The second benefit “bucket” is related to business processes and business transaction execution producing results such as:

• improved cycle times
• greater process automation
• inter and intra departmental integration
• unified reporting data
• improved inventory management
• better planning capabilities
• greater supply chain efficiencies
• faster, more accurate financial closes and statements
• better operational decision making tools

As you can guess, the list goes on.  The difference here is the focus is on direct engagement and active participation with the business.  This is the real challenge.  A business partnership in your SAP project requires more change management, greater flexibility, and a clear understanding that some business needs will override IT drivers and IT goals.  The goal of well executed SAP project governance is to achieve measurable benefit –, it is more about delivering business objectives and strategic direction. 

IT Governance of the SAP Enabled Organization

When the SAP enabled IT organization is able to deliver on business objectives and focus on strategic direction their role in the enterprise changes.  This SAP change moves the IT organization from being a mere “service provider” (a very expensive cost center) to a critical “value added” business partner. When the SAP IT department is seen as a “service provider” you quickly encounter budget and cost cutting pressure.  As I have previously noted:

In today’s competitive global economy, filled with international economic instability, no part of the enterprise can afford to move very far from what pays the bills.  If your SAP or IT organization is focused completely on technology solutions you lose sight of what is important to the business.  And what is that?  Customers! Customer retention, acquisition, loyalty, satisfaction, and experience.  Without customers there is no growth or revenue.  Without growth or revenue there is no need for that expensive SAP or IT investment…

Without a clearer focus on customers as well as innovation in the enterprise, or “how business gets done,” the SAP and overall IT organization becomes a very expensive operational support layer.  Without the genuine business focus the organization becomes a commodity to be outsourced (see SAP IT Convergence Beyond Business to IT Alignment).

SAP Governance Includes Business to IT Convergence

The whole area of governance and convergence is very closely related.  For effective governance the business direction and integration must be a key component of all SAP or IT initiatives.  When you have that involvement, over time, and with some effort, convergence happens.  It isn’t automatic but the environment for it to occur begins with direct business engagement. 

If the business isn’t in the SAP co-pilots seat you may be headed for a IT crash landing.

If you’re thinking to yourself this “doesn’t apply to me” then you might want to think again.  A recent IBM study found that many corporate lines of business are beginning to make their own independent technology purchase decisions.  And they are doing this outside of the SAP or IT organization.  Add to that Ray Wang’s recent Harvard Business Review Blog Post about the consumerization of [business] IT (see Integrating Business Stakeholders as Part of SAP IT Convergence) and you have a serious issue to contend with.  As his research noted, “corporate tech spending is up by 17 to 20%… [but] spending by IT departments is flat.. business leaders, not their IT colleagues… are driving purchasing decisions.”

Business decision makers are starting to use their own budgets to make their own IT decisions rather than making the contribution to what they see as a very expensive “service provider.” That integration or “convergence” with the business is more important than ever because in the end they have more influence over your budget than you may realize.

For more information on this topic please see these additional posts:

• Steps to Achieve SAP IT Convergence
• SAP IT Convergence is About Business Focused Integration
• Steering Committee Governance for an SAP Center of Excellence
• Using Your SAP Steering Committee for Business Transformation
• SAP & Business Convergence

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• Steering Committee Governance for an SAP Center of Excellence
• SAP Program Management Requires a Type of CMMI
• Steps to Achieve SAP IT Convergence
• Toward an SAP Center of Excellence or SAP Competency Center – PART 2
• Series on SAP Competency Center or SAP Center of Excellence

SAP Project Success

In all the years I’ve been involved with SAP I’ve often puzzled about what makes a really good project rather than some of the freak shows they call SAP projects.  After involvement in over 20 SAP projects I’ve seen a few of them go really well, a few that were more like horror shows, but most were mediocre.  I’ve often asked myself “Why?”  What makes the difference between a good project and one that is nothing short of a mess?

One key item that stands out is project management.  Even with the most talented and dedicated resources bad project management can ruin an otherwise great SAP project.

I don’t blame client project managers because if they had all of the resources they would not need outside help and guidance.

Before I get into this, let me define what I consider a “good” project.  A good project is one where there is a lot to do, but the stress level is not intense.  The timeline may be tight but it is achievable (maybe a little bit of a stretch).  The project is delivered on time, on budget, within scope and the result is high quality (a fairly smooth transition without a chaotic go-live).

Methodology Considerations for a Good SAP Project or SAP Program

The list below is from a synthesis of materials from SAP’s ASAP methodology, the PMI (Project Management Institute), and my personal experience over the years.  Much of this is contained in the SAP ASAP methodology in one form or another so you really have to wonder what any consultant is following if they claim to use it and these items are lacking.  In fact the latest ASAP Methodology version 7.1 includes a project start-up checklist to ensure key components are addressed.

Unlike several years ago when contract project managers had to rely on experience alone – the SAP ASAP Methodology is well-proven and mature today.

There are several key characteristics of a well managed SAP project which includes:

Early SAP Project or Program Management Activities (Before the Overall SAP Project is Fully Underway)

• Success criteria defined and communicated for the project.
• One of the first things that is defined for the project are the key roles, responsibilities, and tasks that will be performed by each participant group in the project.
• A clear, definitive project plan with WBS elements, networks, and activities planned for every major work-stream throughout the entire timeline.
• A clear list of deliverables, milestones, templates, and instructions on their usage are provided for the entire project.
• Deliverables are clearly tied to project value rather than useless administrative exercises (value added activities) (see SAP System Vendor Project Success Criteria & Factors 1 scroll down to Sections 8 and 9).
• Scope, time, issues, risk, cost, communication, and integration management plans, together with additional key components are defined.
• Various standards for the project are defined and documented, including but not limited to business process, development, configuration, enhancement, transport management, testing, etc.

If you are using outside contract project management resources and  these items are not substantially in place by the time you start your project you will likely have your timeline and budget destroyed.  Along with the blown schedule and budget your project will also be a pressure cooker filled with stress, anxiety, and frustration. These are also characteristics you find when an SAP project manager or SAP program manager is not qualified.  The chaos, tension, stress, and confusion caused by their inability to coordinate the many moving parts of the project are a direct result of their lack of experience and ability.

I don’t blame client project managers because if they had all of the resources they would not need outside help and guidance.

The project should be delivered on time, on budget, within scope and with high quality…

Conclusion on Effective SAP Project or Program Management Practices

You are headed for a project disaster when a contract SAP project manager or SAP program manager fails to ensure the following items are in place early in the project:

• responsibilities by group and role are defined,
• deliverables are well laid out,
• templates are properly prepared,
• forward looking expectations are set,
• coordination occurs between all project groups,
• etc.

I’ve only ever been on a few projects when the SAP project manager or SAP program manager failed to produce a properly detailed project plan.  Every one of those projects had one thing in common, they were absolutely horrendously stressful, difficult, and took more time and cost more than necessary.  Along with the failure to produce a proper project plan the lack of proper deliverables, proper roles and responsibilities, and all of the other things a good project plan would help you define were also missing.  If this happens to you FIRE those contractors, you are being bled dry and are headed for a budget and timeline disaster.

For much more detail on what happens when you have bad contract SAP project managers or SAP program managers see the post Some Reasons SAP Projects are Over Budget and Over Time.

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• More SAP Project Leadership Tips for Managing Conflict
• 5 Leadership Tips for Successful SAP Project Management
• SAP Project Manager – SAP Program Manager, Lessons from the Trenches
• SAP System Vendor Project Success Criteria 1
• More on Vendor Selection Criteria and Methods for ERP Project Success

ERP system vendor scams

This week we move into the live ERP or SAP sales process.  After your RFP and as you entertain all of those proposals this is where the sales games, scams, and shams really kick in.

As the process unfolds beware of the many tactics, schemes, tools, and tricks used by ERP system integrators to gain access to your checkbook. Like a magician with a bag of tricks and a potential million dollar deal or more (sometimes MUCH more) on the line, the show begins.  Software integrators load up on tricks, schemes, or other ways to separate you from your money.

As the SAP Sales Process Progresses

• Beware of gifts not directly related to making a decisions
  • ERP or SAP sales people have large expense accounts
  • They are practiced at entertaining, influence, and manipulation
• They often play “let’s change the subject” to divert your attention or distract you from what is important
  • They try to go very fast or distract you with something related but not what you asked for – you slow them down and use objective scoring protocols to counteract this.
  • Chalk talk – stop the “chalk talk” by asking “can you show me in the system” and if they cannot simply note that you will have to score them down on that item.
  • “Stump the chump” is a game they play by using techo–babble or just talking in terms that no one seems to understand but “sound” intelligent.  Simply ask them to “show me in the system” or “can you tell us all what part of the RFP are you addressing so we can be sure it is scored correctly?”
  • “Gee whiz isn’t that neat?” is a classic strategy to show you some unrelated but “cool” functionality to distract you from the key requirements you requested – Ask them “can you show me what section of the RFP you are addressing?” Tell them up front, in the RFP, to spell out in their presentation or demonstration exactly which RFP section they are addressing.
• Things are not always what they appear to be – Videotape the sessions
  • Reports – Be sure the application has some built-in report functionality
  • 3rd Party “add-ins” (beware here) – OS / Server / Hardware / DB will generally be required.  But other third party applications may not be mentioned by the vendor even though they are being used in demos.  Make sure it is clarified in the RFP and in the contract that the software is all-inclusive of what was demonstrated, or what was presented as “X” during the demonstration and it is videotaped.
  • “Vaporware” – You need on site, hands on time to evaluate the software. If they want the sale insist they provide you access to the software to put your hands on it yourself.
  • Custom screens or queries – Some vendors will do custom mock-ups to try to gain your business and then develop the REAL solution on your dime.  Think of these like facades, a pretty screen with no functionality attached.
• Application “consultants” who participate in the proposals
  • Are product experts
  • May be compensated on a sale
• Bait and switch
  • Consultants or their resumes may be presented during the proposal but suddenly have to “leave” the project or never show up
  • “In development” or “beta testing” usually means you will be paying to develop the product.

Strategies to Overcome Some of the Initial SAP System Integrator Sales Tactics

The following points were extracted from the post on Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP .

One of the most important things you can do is to develop a rational scoring protocol that addresses how well a vendor adhered to your RFP.  Score it section by section, and weighted to what is important for your company (a future post will address using the proven AHP method).

Make sure that the vendor provides live demonstrations of system functionality.  This helps ensure that the vendor brings knowledgeable consultants to the proposal — they will have to take time with some of their internal resources to be able to set up the demo and have some of their knowledgeable consultants available to show you system functionality and to answer questions.

Ensure that the vendor provides the implementation tools and samples of each of the templates and resources they use for the project.  Offer to sign an NDA to eliminate any of their arguments about “proprietary” information (see SAP Success Factors for Vender Selection – Responsibility Matrix 2, about 2/3rds of the way down the post is an RFI table).

If this is a vendor selection then the most important consideration are the consultants.  If it were my company I would tell the sales people to stay home and bring your proposed project team to do the proposal.  They are the ones that will deliver the solution, they are the ones that will be the greatest influence on your project success (or failure) and they are the ones that you will be paying for.  If you would like more information on this, please see the following posts:

• FIXING Stupid SAP Vendor – Partner Selection RFI – RFP Processes
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes
• Why SAP Vendor – Partner Selection RFI Processes are Stupid

Finally, make absolutely certain that any commitments made by the vendor during the presentation are documented or recorded, even if on video, so that they can be held accountable.  Be sure to work with your legal counsel to incorporate claims made by the ERP system integrator into the contract.  That contract MUST also contain penalties for breach.

In the end you owe it to yourself and to your company to protect your future and the company’s investment.  Invest the time and energy in this due diligence to help ensure that happens.

Stay tuned next week as we move “Deep into the sales cycle.”

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• Overcome SAP-ERP System Integrator Sales Tactics 7
• Overcome SAP-ERP System Integrator Sales Tactics 6
• Overcome SAP-ERP System Integrator Sales Tactics 5
• Overcome SAP-ERP System Integrator Sales Tactics 4
• Overcome SAP-ERP System Integrator Sales Tactics 3

Based on a combination of the academic literature [FN1] and my personal experience I have put together the following SAP and ERP Critical Success Factor Responsibility Matrix. The large “A” indicates a primary responsibility, a small “z” indicates a secondary responsibility, and a blank field indicates no direct responsibility.

This is part of the continuing series on managing the SAP vendor relationship to help ensure SAP project success.  This can be achieved by reviewing the SAP critical success factors, how responsibility is divided, and tactics for managing them.

You want success, they want your money, MAKE SURE THEY EARN IT!

The small “z” indicates that the party has a very strong influence over that factor but may not be in the position to ensure that it is successful. These small “z” areas are often the key areas where parties with more of a primary responsibility tend to try to lay blame on the other party when a project runs into trouble.

Legend

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

During your SAP or other ERP project it will be critical to pay very careful attention for you as a customer to those areas where the system integrator or consultants have a primary responsibility (the “A” areas) and where you share the responsibilities (the “z” areas). Those are generally the activities that many of the “con”sulting companies and unscrupulous integrators will take advantage of you and lay blame on you for activities they should be more carefully managing. If your project really goes wrong you can bet that in one way or another, you as a customer, will be shown to be somehow responsible for their primary area of responsibility.

SAP Vendor or System Integrator Responsibilities

On the other hand, you as a customer also need to be aware of, and careful about, the areas where you have the primary responsibility. And especially the areas where there is a shared responsibility with the system integrator and they only have a limited ability to influence your activities and success. Those areas should not be blamed on an SAP consulting firm or the consultants if it can be shown they tried to encourage you to do the important tasks to ensure success.  Keep in mind, at the end of the day, as the customer, you are always primarily responsible for your own success.  If risks, problems, or other issues arise and you as the customer do not take corrective action then no system integrator or consultant can change that.

SAP Customer or Client Responsibilities

For those shared responsibilities where the system integrator is tagged as a “z”, if they failed to let you know ahead of time, in a timely manner, a) what to expect, b) how to deal with it, and c) the risks involved, they may not have the experience they sold to you. Keep in mind that does not mean they will be able to spot every issue, every time, ahead of time or have the answer for every situation. But if that foresight is consistently lacking then caveat emptor, or, buyer beware in your engagement with that vendor.

List of ERP or SAP System Vendor Request for Information (RFI) Requirements

One great area to start out your SAP vendor selection process is with an RFI, or Request for Information from the vendors you are considering. I suggest you ask them to respond on how they will handle any and all of the key shared responsibility areas. In the table below you might want to reproduce it and remove the responsibility assignments (see the example below).

At the end of the day, as the customer, you are always primarily responsible for your own success

SAP system vendor RFI’s should include a list of each shared responsibility from the list above, who the vendor believes should “own” that responsibility (the large “A” or primary), and what resources they have to facilitate success.

Legend

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

You can use this table as a first pass method to disqualify ANY system integrators that are non-responsive and those vendors that attempt to avoid any accountability for what they deliver. If any SAP system integrator is going to try to make you solely responsible for the success of every facet and phase of the project what do you need them for? In other words, if they are not willing to “own” any of the responsibility for your project’s success maybe you should be looking for different vendors.

How to use the SAP Vendor RFI Shared Responsibility Matrix

Use this table for gaining insight into a vendor’s operations and project approach. For example you might wish to use it in the following way:

1. Send the proposed system integrator a list, similar to the one below, with BLANKS under the responsible party column and ask them to fill out who should be responsible for each success factor.
2. SAP ERP Critical Success Criteria Table for Vendor RFI processing.

Resource Y / N	SAP or ERP Critical Success Factor	Company	Integrator
	Experienced SAP consultants
	SAP implementation strategy
	SAP project management
	SAP tools, templates, and resources
	SAP scope development
	SAP scope management
	Strong SAP project and business communication (inward and outward)
	SAP change management
	Sufficient SAP training (user and project team training)
	SAP system vendor and customer trust
	SAP system design decisions
	Amount of custom ABAP or other SAP coding
	Appropriate SAP software configuration (system settings)
	SAP system change control process
	SAP data analysis and conversion
	SAP test planning
	SAP test development
	Additional Vendor SAP Success Criteria 1
	Additional Vendor SAP Success Criteria 2
	Additional Vendor SAP Success Criteria n…

3. Pay special attention to those vendors that might offer ADDITIONAL success criteria from what you send them. These vendors may understand and appreciate your focus on project success. If nothing else it will at least indicate they are giving it serious thought.
4. Indicate in your RFI that failure to adequately address the critical success criteria section of the RFI will automatically disqualify that vendor. Why deal with ANY integrator, no matter how cheap or how supposedly “experienced” they may be if they are not willing to focus on your project success?
5. Under the “Resources” column ask the vendors to indicate if they have specific approaches, tools, methods, or other resources to help ensure success.
6. In your RFI ask them to include in a separate sheet any of the “Y” answers, and to be ready to demonstrate those approaches, tools, methods, etc. during any future sales presentation.
7. For any Resource answer with an “N” (no resources) ask the vendor in their RFI to propose some method to manage the risk associated with not achieving that success factor.

In other words, this exercise does a number of things that are helpful to you as an ERP services buyer from an SAP system integrator or SAP implementation vendor:

• It focuses every vendor on project success criteria even before they engage in their sales pitches.
• It helps to separate some of the less reputable vendors from the process by exposing the vendors who do not believe they have any stake in your project’s success.
• This approach ensures that the prospective SAP system vendor or SAP consulting company provides tools, resources, methods, and approaches to mitigate risks associated with not addressing each of the success criteria.

As we continue through this evaluation of SAP software critical success factors in future posts we will look at methods, tactics, and strategies for managing each of them to promote success. After all, you want project success, ROI, and business benefit, they want your money so they should earn it. Take some time and review the following posts for more background on vendor selection and vendor evaluations.

• SAP Implementation Partner or Company Selection Criteria
• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
• Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
• Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results
• ERP and SAP Business Case for ROI, Business Benefit, and Success

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

[FN1] This table was developed from a combination of factors found in a graduate student’s submission, from peer-reviewed academic literature I’ve previously written about, and from my own experience with SAP since 1994 and business systems since the mid 1980’s.

Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School. http://www.r3now.com/literature/2009-Bhagwani-SAP-Project-Success.pdf .Somers, T., and Nelson, K., (2001) The Impact of Critical Success Factors (CSF) across the Stages of Enterprise Resource Planning Implementations. Proceedings of the 34th Hawaii International Conference on System Sciences. Somers, et. al., has been reviewed in detail on this site at:

The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
http://www.r3now.com/the-top-5-erp-success-factors-by-project-stage-from-22-critical-success-factors

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

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

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

Related Posts:

• SAP Success Factors for Vendor Selection – Responsibility Matrix 1
• Where do you Start with SAP Return on Investment or SAP ROI?
• SAP Implementation is an Investment NOT an Event
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• SAP ROI through Strategic Business Transformation