The Real Story on IT Implementation Methodologies

Executive Summary

  • There are a number of IT implementation methodologies, but they are normally not evaluated for their effectiveness.
  • We cover SAP consulting company methodologies as well as SAP’s Rapid Deployment Methodology.

Introduction to IT Methodologies

IT methodologies are often presented as major differentiators for implementation companies. However, IT methodologies are not what they appear. You will learn the reality of IT methodologies and what consulting companies do not want their customers to know.

What Are IT Methodologies?

The implementation methodology is how a consulting company performs the implementation. This can be considered the steps as well as the sequence of steps or project phases.

“A product software implementation method is a systematically structured approach to effectively integrate a software based service or component into the workflow of an organizational structure or an individual end-user.”

Methodologies are used to appeal to clients, particularly during the sales process.

Most IT consulting companies will declare that they have some proprietary implementation methodology and that this methodology adds significant value to the project. However, most of the methodologies have roughly the same steps or phases.

These are the following:

  1. Project Preparation
  2. Design aka Blueprint
  3. Realization (which is the implementation of the design into the software — configuration, etc..)
  4. Testing
  5. Go-Live and support

Who Provides Some Information About SAP Implementation Methodologies

Basically the major SAP consulting companies as well as SAP provide very little in the way of information about their implementation methologies publicly. You have to either work for that company or be a client or prospect to receive access to these methodologies.

Problems with SAP Implementation Methodologies

One of the primary weaknesses of all methodologies offered by consulting companies. This weakness is that the methodology that is published is considered more important to help sell business, and as a proof to the prospect the consulting company should be selected rather than a competitor.

SAP implementation methodologies are not written by an implementer like me, but by senior members of the company, administrators, basically people that don’t have to actually do any of the work to meet with ASAP. When I worked on Deloitte’ methodology, there was a great focus to include things that Deloitte could sell into the methodology, which did not have really much to do with creating a coherent methodology as much as it was designed to support sales. I have called the Deloitte SAP implementation methodology the “wish list of things that Deloitte partners would like clients to purchase.”

Marketing SAP Implementation Methodologies Versus the Reality

These SAP implementation methodologies in most cases place an impossible standard upon project managers to cross every T on the methodology. But these things in most cases simply don’t happen on IT projects. If we look at SAP’s ASAP implementation methodology, conforming with all of the areas of ASAP would be very close to impossible.

On every project I have been on, I have never seen all of these forms and templates filled out on any project. Actually, it is impressive if even one can simply find quality functional specification documentation. In most cases the foundational documents are often poorly written or out of date.

Companies are not really willing to pay to have all of these things filled out, and when a project gets behind, the documentation is the first thing to go out the window. So how well do SAP implementation methodologies represent what actually happens on SAP projects. In my view, very poorly.

The Waterfall Approach Versus Agile Approach for IT Methodologies

This is a standard linear approach or waterfall approach to projects. But this is has been the same basic approach since systems were implemented, and other types of projects, such as projects not involving computer software implementation use roughly the same steps as well. It is not possible to do these steps in a different sequence. For instance, you can’t put testing ahead of design, and you can’t place design before project preparation. However, some implementation methodologies use an agile approach, which means there are multiple cycles of these same steps.

Along with the steps and the sequence, there is all manner of other dimensions that can be added to the methodology. For instance, Deloitte adds the use of a tool called ARIS which is for business process modeling. Often some accelerator is included in implementation methodologies, which holds the promise of allowing the software to be brought live more quickly and also less expensively. Methodologies are also constantly being reworked, but not with the concept of reflecting the reality of projects, rather instead to incorporate topic concepts so that the methodology appears to be leading edge, desirable and “relevant.”

And this gets to one of the primary weaknesses of all methodologies offered by consulting companies. This weakness is that the methodology that is published is considered more important to help sell business, and as a proof to the prospect the consulting company should be selected rather than a competitor, that it is to actual implementation. The evidence I can provide to this effect is if you look at who writes implementation methodologies, it is the most senior members of the organizations that create them. These are individuals who don’t implement projects as much as they sell projects. It would be rare to obtain very much involvement from active implementors in developing the implementation methodology.

Methodologies Per Consulting Company

Below each excerpt from a methodology document or article, I have included commentary that should help readers understand my observations of the material. This email is not a conclusion on what to do with the SAP implementation methodology information available to us but is more of an explanation of the exploratory research into the area. From this, we can determine what the next step is.

Now we will review the methodologies that I was able to find from SAP consulting companies as well as SAP. These consulting companies were chosen from Gartner’s Magic Quadrant, which lists the largest SAP implementation consultancies in the world. Most of them did not have anything even mentioned about an SAP implementation methodology. However, I would assume the virtually all of them have some private SAP implementation methodology. The question of whether they adhere to it is a separate question.

Deloitte

Deloitte has a methodology that they call BPM or business process modeling. It is focused on ARIS process modeling software. A screenshot from Deloitte’s methodology document is included below.

This shows being able to keep multiple process documents open. This provides Deloitte with better transparency and collaboration than using Microsoft documents saved to Sharepoint. Deloitte did not always use this as a counterpoint of their methodology.

Ten years ago, they did not use ARIS at all, but at some point between then and now they decided to become more tool-centric in their methodology.

IBM

IBM has a methodology called Innovative Implementation. According to IBM, it simplifies and Accelerates ASAP Blueprint, which is SAP’s implementation methodology. Therefore, IBM’s methodology is highly based upon SAP’s.

KPMG

Nothing found

E&Y

Nothing found

HP

Nothing found

Accenture

Nothing found

InfoSys

Nothing found

Tata

Nothing found

NTT

Nothing found

CSC

Nothing found

Cognizent

Nothing found

WiPro

Nothing found specific to its own methodology published publicly. However, WiPro does have an article where they refer to something called the RDS or rapid deployment solution.

The SAP Rapid Deployment Solution

This quotation is from an article from WiPro on the SAP RDS

“The flavor of the season seems to be RDS (Rapid Deployment Solution). But anyone familiar with the SAP marketplace will also be familiar with its earlier avatars-best practice templates, pre-configured templates and so on. Why this sudden fancy with RDS then? Well, I think it is a result of many factors.

Firstly, large ‘soup to nuts’ green field implementations have become a thing of the past, at least for the most part. Now, RDS as a concept is more amenable to be implemented in small chunks. Consequently, most RDSs are focused on sub-processes within various Lines of Business.

Secondly, SAP as an organization is pulling out all stops to promote RDS as a concept. The slew of RDS offerings in the marketplace needs to be seen to be believed. RDS solutions are not restricted to Line of Business solutions. They are cutting across processes, domain and technology. You have RDSs around HANA, mobility and even on something as new in the SAP stable as Crossgate.

Thirdly, everyone is rooting for low TCO, faster speed to market, low custom code, best practice templates, easy usability, agile implementation, et al. SAP is tapping into this mindset by aggressively promoting RDS as a concept across all its platforms. This is a win-win situation across the board. Customers get a deep and broad application like SAP at a lower cost and faster speed. After a quick launch and acceptance, they can expand the footprint in due course, budgets permitting. For SAP, it can effectively counter competition and reduce shelf ware.

I fundamentally believe that like HANA, Sybase and a couple of other strategic initiatives, SAP is beginning to get it right with RDS. For example, XML5 and other UI related initiatives eminently address usability needs HANA disruptively addresses performance needs Sybase and its tools are best in class mobility solutions; with Syclo in the bag as well, SAP has become the undisputed market leader in mobility Shorter software releases significantly transforms software upgrade and maintenance processes And now RDS.

To conclude, I think RDS might end up changing the way SAP and other tier 1 applications get implemented. The day may not be far when classical SAP implementation has to re-orient itself to an RDS based implementation methodology.”WiPro on SAP RDS

This article was written back in 2012. However, none of the things in this article came true. This is true of most articles written by people with a sales quota on SAP. These articles are designed to drum up interest in SAP and demonstrate competence, not to actually predict what will come true. RDSs were useless for improving implementation of SAP projects and were simply designed to give the impression to the clients into thinking they could get software implemented faster than the consulting company was willing or able to.

I analyzed several RDSs for a consulting company and my conclusion was that they were not helpful at doing anything but providing the inaccurate expectation that the SAP software module covered by the RDS could be implemented more quickly that it actually could be.

CapGemini

“iSAP is CapGemini’s SAP implementation methodology.

iSAP includes six phases: project preparation, blueprint, realization build, realization test, final preparation, and operate.

In each phase, we bring the extra value that makes iSAP singularly effective in delivering an SAP solution that works successfully, supporting your company in the achievement of its goals:”

  1. “Business process perspective — By focusing on how people and systems work together, we find measurable opportunities to improve end-to-end process performance through SAP-enabled changes and lean best practices
  2. Beyond-the-basics development — Because our methodology is robust with best-practice templates for the basics, we can quickly apply two added-value techniques — “Design by Acception®” and “critical path sequencing” — to make sure the new system really fits your business
  3. User-responsive data management — Industrialization enables optimized data migration
  4. Organization change management — iSAP provides change management tools for the SAP-enabled business transformation of people, process, and technology
  5. Project management — We work lean, always looking for and finding ways to incorporate the best, established standards and procedures for project management to achieve optimal productivity”

“What makes your business a success?

We care about that question, and we keep it top-of-mind during your SAP implementation.

For Capgemini, excellence is fundamental.We’re committed to client satisfaction, each and every time. iSAP is the newest way we’re proving our value as an SAP “Global Partner Service Innovator” and a recognized leader in SAP implementations around the world. The right methodology, at the right time — made to deliver more value, right now — that’s iSAP.”

In a separate document CapGemini states the following:

“When Capgemini invented iSAP it brought Lean manufacturing principles to the practice of implementing SAP rec projects. In doing so it also created an ideal solution for a problem that has challenged SAP project teams for a long time — how to apply Agile on an industrial scale. It turns out that the same methods and tools iSAP uses for Lean are also well suited for Agile. For example, they are designed to make highly visible those activities that either add value or contribute waste and also those critical decisions that customers and project leaders still need to make. (In fact, one of iSAP’s key practices is called “visual management.”) Once identified, that information is a natural input to Agile teams looking for rapid and holistic feedback — holistic in that the feedback may come from anyone on the project, especially customers who have new requirements. iSAP’s inventors call this Design By Acception®— focusing on the relatively few difference makers that truly add value for the customer — which is a turn on the Lean phrase of “management by exception” — which is to only focus on (and eliminate) things that make waste. Design By Acception® also dovetails naturally with Agile, which is all about finding opportunities for adding value in short iterative bursts of development. In both Lean and Agile, value is what the customer says it is, so the only way to know for sure is by asking the customer. Agile assumes that what the customer wants will constantly change in light of new information (including the arrival of new project deliverables). So by highlighting the “waste makers” iSAP can drastically enhance the quality of collaboration with the SAP customer and thereby drastically streamline Agile.”

This PDF document just continues in this manner. This document is designed to sell potential CapGemini on iSAP, not to actually explain what it is.

In order to access the actual methodology, it would probably be necessary to either work for CapGemini or to be a current client or prospect of CapGemini. One could contact CapGemini and ask, using the idea that one is conducting research implementation methodologies.

PwC

PwC has a very short document that describes its methodology. I have a few screenshots copied below:

As you can see this is very general information. PwC is communicating that the methodology is related to other factors. But once again this is at the level of generalization.

Neoris

The following quote is from Neoris’ SAP implementation methodology web page:

“S2OA (SUSTAINABLE SOA)

The SOA offer by Neoris responds to an integral approach that aligns processes and information technology with the business goals. Neoris considers the organization a system and articulates the technology, information and processes as components of an overall structure. Neoris can ensure that the SOA implementation is sustainable, manageable and profitable through an appropriate articulation and alignment of processes and business goals.

This does not make any sense. This document was written in 2015, but SOA is a technology approach that was promoted by SAP that is no longer a term that is even used. In practice, SAP is against SOA because it increases competition for them.

This Neoris implementation methodology explanation is pure marketing hyperbole that won’t have anything to do with an actual implementation.”

SAP

SAP has had its own implementation methodology for many years. ASAP was introduced roughly 20 years ago, and all consulting companies will state that their methodology is consistent with ASAP.

What follows is a high-level explanation of ASAP that is publicly available.

ASAP focuses on tools and training, wrapped up in a five-phase process oriented roadmap for guiding implementation.

The road map is composed of five well-known consecutive phases

        Phase 1 Project Preparation

        Phase 2 Business Blueprint

        Phase 3 Realization

        Phase 4 Final Preparation

        Phase 5 Go-Live and support

You can access the ASAP Methodology on the SAP Service Marketplace pages (login required).

Benefits of ASAP 8 Methodology include

“Reduced total cost of implementation by embedding the principles of SAP Advanced Delivery Management into a prescriptive, streamlined and modular implementation road map for ASAP.”

  • “Content-rich implementation accelerators, templates, and guides for implementation projects from strategy to operations
  • Transparent value delivery through consistent reflection of the business case.
  • Efficient project governance, quality management, and guidance for implementation projects and Business Process Management
  • An approach that combines user-centric design, business processes, and IT architecture
  • Coverage of the entire project lifecycle – from evaluation through delivery to post project solution management and operations.”

“Consistent content from Value Maps, Solutions, configuration to business process monitoring.”

“(the) Latest version of Solution Explorer and Solution Configurator to explore SAP solution capabilities, select appropriate solutions and determine best pre-assembled RDS for your project

Proven and scalable implementation methodology guiding your team through the agile implementation project and ensuring seamless setup of solution operations

Seamlessly integrated with SAP Solution Manager in both implementation and solution operations

Simplify implementation further — EVERY implementation starts with best practice content based on pre-assembled RDS ASAP methodology framework is provided to end users in four variants (pre-selections)) to support various deployment strategies for implementation of SAP system. The following ASAP 8 pre-selection variants are available for end-users in SAP Service Marketplace (and also in SAP Solution Manager starting with ST-ICO SP37 content package release level):

Simplified Rapid Deployment Solution Experience / Assemble to Order Project

The success of your SAP solution is to a large degree determined by the speed and the effectiveness of the software implementation to add value to your organization. That is why SAP has introduced the Simplified Rapid-deployment Solution Experience. It combines the ability to explore SAP solution capabilities, select the appropriate pre-assembled RDS as a starting point for your project, and implement the solution in your business with the help of structured implementation approach – ASAP 8 Methodology for Simplified Rapid-deployment Solution and integrated operation supported by SAP Solution Manager.”

  1. “Simplified Rapid Deployment Solution Experience / Assemble-to-Order Project Methodology Phases – The Simplified Rapid Deployment Solution Experience / Assemble-to-Order Project Methodology is structured into the following phases.
  2. Project preparation – This phase provides initial planning and preparation for the project. Each project has its own unique objectives, scope, and priorities. The deliverables described in this phase assist in completing the initiation and planning steps in an efficient and effective manner – like setup of project governance, project plan and project schedule are prepared at this stage.
  3. Scope validation – The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. It focuses on the rapid setup of environment that is available for validation workshop with business users to confirm scope and determine delta requirements that will be realized in the next phase to enhance the baseline provided by pre-assembled RDS.
  4. Realization – The purpose of this phase is to implement all the business process delta requirements defined during the Scope Validation phase. The team configures, develops, tests and documents the solution in series of time-boxed iterations. Before the solution is released to next phase it is fully end-to-end integration tested and accepted by end users.
  5. Final preparation – The purpose of this phase is to complete the cutover activities (including technical and load testing, end user training, system management and cutover rehearsal activities) to finalize your readiness to go live. The Final Preparation phase also serves to resolve all remaining critical issues. On successful completion of this phase, you are ready to run your business in your live SAP System.
  6. Go-live support – The purpose of this phase is to move from a project-oriented, pre-production environment to live production operation and provide sustained support to business users to aid their transition into the new environment
  7. Operate – The purpose of this phase is to fine-tune the application lifecycle standards, processes and procedures established during the project and align them with operation needs. The central operation platform is SAP Solution Manager, which leverages the documented solution for system operations.”

“ASAP has been adjusted over the years to account for various trends in software implementation. One of these trends in IT project implementation management it called agile.

Agile ASAP 8 Methodology

The success of your SAP solution is to a large degree determined by the speed and the effectiveness of the software to add value to your organization. That is why SAP has introduced Agile ASAP; a new, practical implementation methodology that allows you to implement operating functionality in short iterative cycles. In each cycle the team implements the most valuable and important functionality first. This enables you to generate results faster, gain immediate insight into the value, increase the flexibility of the implementation and improve progress monitoring.

Agile ASAP 8 Methodology Phases – The Standard ASAP 8 Methodology is structured into the following phases.”

  1. “Project preparation – This phase provides initial planning and preparation for the project. Each project has its own unique objectives, scope, and priorities. The deliverables described in this phase assist in completing the initiation and planning steps in an efficient and effective manner – like setup of agile project governance, project plan and project schedule are prepared at this stage.
  2. Lean blueprint – The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. It focuses on the rapid setup of solution validation environment for validation workshops with business users to confirm scope and determine delta requirements that will be realized in the next phase to enhance the baseline build of the system.
  3. Realization – The purpose of this phase is to implement all the business process delta requirements defined during the Lean blueprint phase. The team configures, develops, tests and documents the solution in series of time-boxed iterations – the most valuable functionality first. Before the solution is released to next phase it is fully end-to-end integration tested and accepted by end users.
  4. Final preparation – The purpose of this phase is to complete the cutover activities (including technical and load testing, end user training, system management and cutover rehearsal activities) to finalize your readiness to go live. The Final Preparation phase also serves to resolve all remaining critical issues. On successful completion of this phase, you are ready to run your business in your live SAP System.
  5. Go-live support – The purpose of this phase is to move from a project-oriented, pre-production environment to live production operation and provide sustained support to business users to aid their transition into the new environment.
  6. Operate – The purpose of this phase is to fine-tune the application lifecycle standards, processes and procedures established during the project and align them with operational needs. The central operation platform is SAP Solution Manager, which leverages the documented solution for system operations.”

“Standard ASAP 8 Methodology

Standard ASAP 8 Methodology takes a disciplined approach to project management, organizational change management, solution management, application life-cycle management and other disciplines applied in the implementation of SAP solutions. The Standard ASAP 8 Methodology is built around the SAP Advanced Delivery Management model and supports project teams with templates, tools, questionnaires, and checklists, including guidebooks and accelerators. Standard ASAP 8 Methodology empowers companies to exploit the power of the accelerated features and tools already built into SAP solutions.

Standard ASAP 8 Methodology Phases — The Standard ASAP 8 Methodology is structured into the following phases.”

  • “Project preparation – During this phase, the team goes through initial planning and preparation for SAP project.
  • Business blueprint – The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. In Standard ASAP 8 Methodology the result is the Business Blueprint, a detailed documentation of the results gathered during requirements workshops
  • Realization – The purpose of this phase is to implement all the business process requirements based on the Business Blueprint. The system configuration in Standard ASAP 8 Methodology is done in two work packages: Baseline configuration (major scope); and Final configuration (remaining scope). During this phase, the solution is also tested.
  • Final preparation – The purpose of this phase is to complete the final preparation (including technical testing, end user training, system management and cutover activities) to finalize your readiness to go live. The Final Preparation phase also serves to resolve all critical open issues. On successful completion of this phase, you are ready to run your business in your live SAP System.
  • Go-live support – The purpose of this phase is to move from a project-oriented, pre-production environment to live production operation.
  • Operate – During this phase the system is operated with the help of the central operation platform, SAP Solution Manager, with the documented solution based on the transferred project documentation.”

Each phase has a set of deliverables that are produced during the duration of the phase and serve as the input to follow-up phases. Each deliverable provides a list of outputs it consists of and methods that are used to produce the deliverable.

“Work Streams

The ASAP 8 Methodology is structured around the key project work streams that are outlined in the picture below. For each work stream, the methodology provides the number of deliverables that are to be produced in each phase of the project.

ASAP 8

ASAP 8 is available at a protected SAP portal that customers and consulting companies can access.

The sequence is the following:”

Project Preparation

  • Project Initiation
  • Project Governance
  • Project Charter
  • Kick Off Workshop
  • Scope Statement
  • Project Schedule and Budget
  • Project Management Plan
  • Project and Operational Standards
  • Execution, Monitoring and Controlling of Results
  • Organizational Change Management Roadmap
  • Project Training Strategy and Plan
  • Project Team Training
  • Business Process Map
  • Value Determination
  • Business Scenario Design
  • Prepare Testing Policy
  • Data Migration Approach and Strategy
  • Technical Requirements Design
  • Interface Inventory
  • Initial Hardware Sizing Proposal
  • Project Support Tools and System Setup
  • Phrase Closure and Sign Off Phase Deliverables
  • Project Start to Design

Business Blueprint

  • 2.1 Phase Initiation
  • 2.2 Execution, Monitoring and Controlling Results
  • 2.3 Stakeholder Analysis
  • 2.4 Change Impact Analysis
  • 2.5 Communication Plan
  • 2.6 End User Training Strategy and Plan
  • 2.7 Project Team Training
  • 2.8 End User Training Content
  • 2.9 Scope Validation / Fit-Gap Analysis
  • 2.10 Business Solution Design for Business Objects
  • 2.11 Detailed Design – Business Scenario #1 -n
  • 2.12 Detailed Design – Business Process #1 – n
  • 2.13 Value Realization
  • 2.14 Detailed Design – Configuration and Enhancements
  • 2.17 Visualization
  • 2.19 Legacy Data Migration
  • 2.20 Legacy Data Archive
  • 2.21 Technical Solution Design
  • 2.22 User Access and Security
  • 2.23 Development Environment (DEV)
  • 2.24 Testing Strategy
  • 2.26 Phase Closure and Sign-Off phase Deliverables
  • 2.27 MILESTONE: Design to Build

Project Realization

  • 3.1 Phase Initiation
  • 3.3 Execution, Monitoring and Controlling Results
  • 3.4 Organizational Alignment
  • 3.5 Educational Readiness Review
  • 3.8 Knowledge Transfer
  • 3.9 End User Training Delivery Enabled
  • 3.10 Configured General Settings and Organizational Structure
  • 3.11 Configured Master Data Objects #1 – n
  • 3.12 Core Configuration and Documentation – Process #1 – n
  • 3.13 Delta Configuration – Process #1 – n
  • 3.15 Enhancement Development – RICEFW Object #1 – n
  • 3.16 SOA / Composite Application Development #1 – n
  • 3.17 Business Process Procedure
  • 3.18 Value Audits
  • 3.19 Scenario Test #1 – n
  • 3.20 Quality Assurance Environment (QAS)
  • 3.21 MILESTONE: Build to Test
  • 3.23 Preliminary Cutover plan
  • 3.24 Approved Integration Test
  • 3.25 Legacy Data Migration
  • 3.26 Approved User Acceptance Test
  • 3.27 SAP Data Archiving
  • 3.28 Production Environment (PRD)
  • 3.29 Failover Environment
  • 3.30 System and Performance Test
  • 3.31 SAP Going Live Check
  • 3.32 System User Roles and Authorization Administration
  • 3.33 Technical Operations and Handover Plan
  • 3.34 Technical Integration Check
  • 3.35 Phase Closure and Sign-Off phase Deliverables
  • 3.36 MILESTONE: Test to Deployment

Final Preparation

  • 4.1 Phase Initiation
  • 4.2 Execution, Monitoring and Controlling Results
  • 4.3 Organizational and Production Support Readiness Check
  • 4.4 Pre Go-Live End-User Training Delivery
  • 4.5 Approved Technical System Tests
  • 4.6 Production Cutover
  • 4.8 Phase Closure and Sign-Off phase Deliverables
  • 4.9 MILESTONE: Production System Live

Go Live Support

  • 5.1 Phase Initiation
  • 5.2 Execution, Monitoring and Controlling Results
  • 5.3 Knowledge Support Strategy
  • 5.4 Post Go live End-User Training
  • 5.5 SAP Going Live Check – Verification Session
  • 5.6 Production Support After Go Live
  • 5.7 MILESTONE: Deploy to Run
  • 5.9 End User Acceptance Survey
  • 5.10 Project Closure and Sign-Off Project Deliverables
  • 5.11 MILESTONE: Project Complete

Each one of these entries has associated documents available at the SAP Service Marketplace. I will provide a few examples of what is contained within these entries.

Under Go Live Support

If we take the first entry under Go Live Support as an example, there is a document titled Project Start Up Check List. This check list contains four pages of tasks. This document has been attached to this email for the readers review.

Under Business Solution Design for Business Objects

Under the entry Business Solution Design for Business Objects the following accelerators are listed.

Under Technical Solution Design

Under the Technical Solution Design entry there is a document titled Design Thinking for IT Architecture Design. This is one of the many philosophies that influences ASAP. Design Thinking is a concept that has been used by SAP across multiple areas as I have also seen it as part of the sales training at SAP.

Interpretation of ASAP

I could go on explaining many parts of ASAP, the documents that come along with it, etc.. However the point should be taken that this a very large area to cover. Conforming with all of the areas of ASAP would be very close to impossible. On any project I have been on, I have never seen all of these forms and templates filled out. It is an accomplishment if even one can simply find quality functional specification documentation at a company after implementation. In most cases, the foundational documents are often poorly written, incomplete or out of date.

I have not found that companies are willing to pay for the time for such expensive resources to have all of these things filled out perfectly. When a project gets behind, the clients themselves will deemphasize things like documentation. Furthermore, if you look at projects that were implemented without a consulting company, such as internal client projects, they do not conform to such high standards as outlined in the ASAP methodology.

Now on the consulting company web pages, you would never have any company admit to this. This is true for any other consulting company. The reality of projects is much messier than the idea that every T is crossed on every document, or that what is the wide variety of documents, checklists, and rules that are part of ASAP will be followed.

Conclusion

The only complete methodology I have access to, without reaching out to people is SAP. This is because I have a login to their Service Marketplace, which is restricted to clients and those that work with SAP. SAP’s ASAP methodology is considered the source methodology, and all SAP consulting companies will state that their methodology is consistent with SAP’s ASAP.

The negative aspect of ASAP is that ASAP is so extensive that it sets an impossibly high standard that no project could meet. It is not written by an implementor like me, but by senior members of SAP, administrators, etc.. These are people that don’t have to do any of the work to be in conformance with the methodology. Instead, it is written or at least managed in its writing by people with a sales responsibility so the focus is less around the usability of the methodology. When I worked on updating Deloitte’s methodology roughly 10 years ago, there was a great focus to include things that Deloitte could sell into the methodology, which did not have much to do with creating a coherent methodology as much as it was designed to support sales. I have called the Deloitte SAP implementation methodology the “wish list of things that Deloitte partners would like clients to purchase.”

The issue with methodologies is that they are as much designed to help sell projects as they are designed to improve the implementation of projects. There is also not any evidence that following any of these methodologies improve the success of implementation projects. And there will never be. No company would ever admit that their methodology was ineffective.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

Accessing Honest Information on SAP

  • Want Honest Information About SAP?

    We can help you independently verify the information provided by major consulting companies and answer your SAP questions. Our work together can remain confidential too.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

References

https://empower.softwareag.com/images/Process%20Transformation_How%20Deloitte%20is%20Simplifying%20BPM%20with%20ARIS_tcm121-70670.pdf

https://www.slideshare.net/IBMgbsNA/sap-implementation-approach-using-ibm-bpm

https://home.kpmg.com/xx/en/home/services/advisory/risk-consulting/accounting-advisory-services/ifrs-conversion-services/kpmgs-ifrs-tools-methodologies.html

https://www.slideshare.net/Infosys/infosys-sap-implementation-methodology-integration-software

https://www.capgemini.com/isap-methodology

https://www.capgemini.com/resource-file-access/resource/pdf/agile_isap_improves_project_outcomes_with_richer_customer_collaboration.pdf

http://www.wipro.com/services/applications/services/enterprise-applications/sap/implementation-upgrade-and-rollouts/

http://www.neoris.com/wp-content/uploads/2015/02/SAP-and-Neoris_web_EN_1.pdf

https://blogs.sap.com/2013/11/15/basic-understanding-on-asap-methodology-for-beginners/

https://archive.sap.com/documents/docs/DOC-8032

https://en.wikipedia.org/wiki/Product_software_implementation_method

https://en.wikipedia.org/wiki/Application_Implementation_Methodology

http://www.softwareag.com/corporate/products/az/aris/default.asp

https://websmp104.sap-ag.de/asap

Frese, Robert, Saunter, Vicki Ph.D. Improving Your Odds for Software project Success, IEEE Engineering Management Review December 2014.        

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Who is the Most Accurate Source on SAP?

Want to find out? See... A Study into The Accuracy of SAP

>