INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

SAP IT Governance – Achieve Business IT Engagement

October 24th, 2011 by
SAP Business IT Convergence

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:




Popular Searches:


  • sap governance model
  • sap project governance model
  • governance sap
  • IT governance team in SAP
  • SAP IdM governance model

Related Posts:

Effective Results from SAP Project Managers – SAP Program Managers

July 18th, 2011 by
SAP Project Success

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.




Popular Searches:


  • sap implementation plan
  • sap project manager roles and responsibilities
  • sap deployment plan
  • sap project manager responsibilities
  • sap implement plan
  • sap project manager role

Related Posts:

Overcome SAP-ERP System Integrator Sales Tactics 2

May 16th, 2011 by
SAP or ERP system vendor sales scams or shams

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:

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.”

Related Posts: