- SAP provides advice for remediating code for S/4HANA.
- We review the quality of this advice (as well as the organization of SAP content) for helping the client rather than helping SAP.
SAP has published its perspective on remediating code for S/4HANA. Both SAP has their consulting partners have consistently underrepresented the complexity involved in code remediation to customers in order to make the migration to S/4HANA seem to be less work and less cost than it actually is. In this article, we review the material on remediation without any SAP bias.
Background on this Research
The information provided by SAP as to code remediation is horrendously complicated. It is a disorganized assembly of information released without any rhyme or reason or any controlling entity coordinating the information.
- Our conclusion is that SAP’s degenerate organization of information around S/4HANA code migration is going to lead to inefficient code remediation projects.
- Whatever the actual level complexity of S/4HANA code remediation, SAP has made the issue far worse though how it has created tools and communicated how code migration works.
- Some of the information about code remediation is found in comments on SAP blog articles, which take a great time to read and also indicate a great deal of frustration or confusion as to how code remediation for HANA and S/4HANA is supposed to work.
How SAP views the overall migration.
The more that one studies this topic the bigger and more complicated it looks, a point emphasized by the following quotation.
“Migrating to SAP S/4HANA is almost always a longterm project because of the amount of work required for a Systems Conversion. Cross-referencing the 700+ pages of the Simplification List against every line of code in your current SAP systems is a huge job, even when automated. Working through the list of incompatibility issues is another thing altogether. There will potentially be hundreds of thousands, or even millions, of issues for your development team to manually fix, one by one – but there are ways you can make migration easier.
Simply looking through that many lines of code could take months. So imagine the time-frame when you include performing fixes and testing the new code. Not to mention all the time required for project management. And then, just when you think you’re done, there’s a pile of freshly-written code to go through.
We’ve literally seen these kinds of projects take years and require thousands of labour-hours. (emphasis added)
“ – GekkoBrain
Sounds easy right? So easy in fact, that PWC directors are commenting that it is quite natural to implement S/4HANA for 500 users or less in 6 to 9 months. The time required for the code remediation is one of the most obvious contradictory data points to the project estimates that are being proposed by consulting firms that are simply trying to sell S/4HANA projects that will be sold on pretenses and then lengthened out with change orders.
The following quotation is far too charitable, but the last part of the quotation is certainly correct.
“Although SAP’s tools do a great job of identifying the Simplification Items that are holding up your Systems Conversion, they offer very little to help you effectively manage your migration project.”
In order to make sense of it all, we created this article.
Analysis of Quotes on the Topic
Getting Rid of Unused Customization Code
“we recommend to get rid of your old unused custom code (custom code evaluation) and then analyze your custom ABAP code with the Simplification Database and find out which objects need to be changed to get adapted to the SAP HANA and SAP S/4HANA (SAP S/4HANA checks)” – SAP Blog by Olga Dolinskaja
This is in part true but greatly overstated by SAP and SAP consulting firms. This is in great part an attempt to make customers think that they need nearly no custom code. SAP has the continual position that customers can use standard SAP, which has never proven to be true in the history of SAP projects, except for highly regulated environments like pharmaceutical that for regulatory reasons cannot customize. And this is the problem in taking advice from a packaged software vendor, the advice is nearly always just use their standard functionality.
Something that SAP does not want to discuss is how much poor quality code is running at SAP customers. Much of this code was written by consultants who work for the major SAP consulting firms, which is one of the worst environments in which to perform any technical work. GekkoBrain covers the topic of code quality in the following quotation.
“One thing we’ve noticed in almost every SAP project we’ve worked on, is the sheer volume of unnecessary or under-performing ABAP code haunting clients’ SAP systems.”
But the following quotation seems to be widely accepted.
“Approximately 60% of all custom code is never used in the productive environment, so using the UPL feature to gain a clear picture of your unused custom code means you’ll likely be able to eliminate a significant portion of it with no effect to performance. This has the potential to hugely reduce the amount of custom code in your systems, resulting in less time spent searching for and adapting custom code that’s incompatible with HANA. It could mean around a 60% saving on the time and money your systems conversion requires.”
And from SAP..
“Do you know that on average 60% of your custom code is in reality not executed in your productive landscape? Especially in SAP Business Suite migration projects like to SAP HANA or SAP S/4HANA such amounts of unused code result in huge adaptation efforts. Therefore SAP’s recommendation is to clean up your unused custom code before migration. But how can you identify the code that is not used?” – SAP Blog by Olga Dolinskaja
These quotations declare specifics and why it makes sense to find and root out unused custom code.
The Simplification Database is Explained
The Simplification Database is according to SAP….
“SAP provides tools, based on the Simplification Database, that detect any custom code that needs to be adapted to SAP S/4HANA. The Simplification Database is a database table in the SAP S/4HANA system that contains all Simplification Items that refer to SAP objects simplified in SAP S/4HANA. Each simplification item describes changed or removed SAP objects and refers to a dedicated SAP Note that describes the impact of the change and how the related custom code can be adapted. To analyze the required adaptations, you need to set up a system based on SAP NetWeaver AS for ABAP 7.52
that operates as a Central Check System. Using this Central Check System, you can perform remote custom code checks in ABAP Test Cockpit (ATC) for one or more systems in your landscape.”
GekkoBrain connects to NetWeaver 7.52 and to the S/4HANA Simplification database.
It is Unnecessary to Perform Custom Code Evaluation?
“Please note: custom code evaluation is recommended but not obligatory. You can carry out your custom code adaptation process without it (e.g. in case if you don’t use CCLM in SAP Solution Manager).
Traditionally SAP customers developed over years so much custom ABAP code that it is not clear, which parts of it are still really productively used. Therefore it is recommended to monitor your system landscape for a longer period of time in order to do some housekeeping and eliminate the code, which is not used anymore within your productive business applications.” – SAP Blog by Olga Dolinskaja
What an odd thing to say.
SAP is essentially proposing that you can worry about estimating the work effort after you have already decided to implement S/4HANA. Does that sound responsible? And this quote again goes back to eliminating code. However, S/4HANA has a smaller functionality footprint than ECC, after all these years. And some functionality that companies rely upon has been eliminated. So that means companies will need to add extra custom code, but there is no mention of this fact at the SAP blog.
Adjusting ABAP to Run on HANA
This is one of the few areas where SAP admits where will be extra work.
“One reason is, that you possibly used native SQL of the predecessor database and these database vendor specific dependencies must be eliminated. Another reason is, that in some custom code implementations the SELECT statement without ORDER BY is used assuming that the data in a database table was already sorted (for example by key). According to the SQL specification when using SELECT statement without ORDER BY, you cannot rely on the sort order because it depends on the respective implementation of the DB vendor and therefore can cause unexpected behavior when the database changes (for example to SAP HANA) because the results of SELECT without ORDER BY return in a different order.
One reason is, that you possibly used native SQL of the predecessor database and these database vendor specific dependencies must be eliminated. Another reason is, that in some custom code implementations the SELECT statement without ORDER BY is used assuming that the data in a database table was already sorted (for example by key). According to the SQL specification when using SELECT statement without ORDER BY, you cannot rely on the sort order because it depends on the respective implementation of the DB vendor and therefore can cause unexpected behavior when the database changes (for example to SAP HANA) because the results of SELECT without ORDER BY return in a different order.
” – SAP Blog by Olga Dolinskaja
This is a good tip. The SQL must be evaluated for everyplace that SQL is written in the customization.
However, this is just the remediation, not the optimization phase. Notice the following quotation which explains that there is an optimization phase to getting the customization to work on HANA.
“After you did the system conversion to SAP S/4HANA and the system is up and running, you need to look which business processes can to be optimized on SAP HANA database since you can now make use of full power of SAP HANA regarding performance.” – SAP Blog by by Olga Dolinskaja
However, this point completely leaves out the conclusion of Brightwork Research & Analysis that performance of S/4HANA will degrade from ECC because HANA is a poorly fitting database for an ERP system. HANA has issues running MRP and is slower in transaction processing. We covered these topics in the article How to Understand Why HANA is a Mismatch for S/4HANA and ECC.
This optimization process is also commonly disregarded prior to engaging in a S/4HANA project. This is another reason we find the entire switch out of the row-oriented database for a 1/2 column-oriented database like HANA to be extremely wasteful. After all of this tuning and optimizing, S/4HANA customers can expect worse performance than they had under ECC for all things except reporting. SAP’s own development has a problem optimizing SQL for HANA, so this is an issue for any SAP customer. The proposal is that the migration is worth it, as expressed in the following quotation.
“ABAP was one of the first coding languages to introduce a high level of abstraction between business applications, operating systems and databases – now known as Logical Databases (LDBs).
Simply put, ABAP-developed applications copy information from a database, leaving the database itself completely untouched. The data is then processed and transformed by the application before the result is presented to the user.
The use of ABAP code ensured any SAP application was “database neutral” and could extract information from a range of databases because it didn’t depend on functionality unique to specific platforms.
One of the inevitable trade-offs that resulted from accessing the unique functionality of SAP HANA is that any custom ABAP code written specifically to interact with another database is now obsolete and could potentially interfere with your systems.
Innovations such as cloud computing, the Internet of Things and real-time analytics are no longer emerging technology – they’re business reality. And organizations who aren’t utilizing new technologies will quickly fall behind competitors.
HANA is SAP’s proprietary cutting-edge database and provides clients with access to some of these innovations and represents some some of the most advanced technology available.” – GekkoBrain
However, the problem with this argument is that other applications run multiple databases without having to use a language which processes the data and then later applies it to the database like HANA. And there is nothing particularly proprietary about SAP HANA. HANA was simply reverse engineered from other currently existing databases and was made up of several acquisitions that SAP had nothing to do with developing as we covered in the article Did Hasso Plattner and His Ph.D. Students Invent HANA?
Nothing in this explanation explains why SAP only ported S/4HANA to HANA. But that is the way it is for now. The following quotation explains why code that previously worked for multiple databases must now be adjusted to work for one….HANA.
“SAP HANA’s dramatically simplified data model means custom code that worked with other databases may not function optimally using HANA. This is due to changes in the underlying database architecture that is referenced by that custom code.
One example of this is the need for code that aggregates data. SAP HANA aggregates all totals and subtotals on the fly using its in-memory and column-based architecture, obviously, this means you no longer need ABAP code that performs this task.”
The first part of this quotation is not correct. The data model has not been simplified. But it is true that the custom code that worked with other databases will not function optimally or even function for HANA.
SAP’s Remediation Tools
SAP has introduced a series of S/4HANA code remediation tools like the Simplification Database and the Code Inspector. The tools we will cover are the following:
- The Simplification Database (which we already covered)
- The ATC with Remote Code Analysis
- The ABAP Call Monitor (SCMON)
- S/4HANA Migration Cockpit
- The Migration Object Modeler 1809
- Use the SAP Solution Manager Custom Code Lifecycle Management Tool
- The ABAP Test Cockpit
There are several problems with these tools.
- The tools duplicate one another such that it is confusing to know which tool to use. Part of this is because the coding remediation tools have turned over, and new ones have been introducing obsolescing the old tools. Some of these tools have been introduced too quickly and were not complete.
- These tools have not proven to be useful and apply more overhead to the analysis then they give back in efficiency.
- There is a central problem with all of these tools, in addition to the tiny amount of effort that SAP has put into developing the tools. And that problem is they mostly exist for marketing reasons. They are something that sales reps can say will “simplify” the analysis, when in fact they do not. A second issue is the constant use of the term “simplify” or “simplification” to describe anything that is involved in remediation. First, S/4HANA does not simplify anything, it is a major change requiring a major effort. Therefore, the information SAP provides is really not intended to help developers as much as it is to make it sound like the effort of remediation will be low. Once S/4HANA is sold on these pretenses, the SAP consulting firm can change order the account for a major code rewrite effort.
This graphic is nonsensical. S/4HANA running on HANA does not mean there are fewer databases. HANA is not a simpler database than a purely row-oriented database, as we covered in the article How Accurate Was SAP About S/4HANA and a Simplified Data Model. SAP published this graphic in the document Custom Code Migration Guide for SAP S/4HANA 1809, but without any explanation for why this graphic is true.
Notice the quote that is printed below this graphic.
“Some of your custom code objects are not valid anymore and either do not perform as expected or produce syntax errors or dumps (red objects in the picture). You almost certainly have other objects that do perform as expected and do not need to be changed (green objects in the picture).”
Does that explain the graphic? Does it actually sound more simple? The answer to both questions is NO.
While SAP uses the term “Simplification” this is a better way of thinking about code remediation for S/4HANA. SAP consulting companies go along with the absurd concept that the massive dislocation and expense of S/4HANA is “simplification.” It is important for SAP consulting companies to help SAP in misleading their customers.
Let us address this point. Keeping things the way there were would have been “simpler.” All of these changes implemented by SAP have greatly increased the complexity of the situation. At some point in the future, say 7 years from now it may be simpler, but then again it may not.
As for remediation being confusing, I provide the following comment on the SAP Blog by Olga Dolinskaja.
“Thanks for your description. But I am completely confused now. In the SAP Note 2271900 – Custom Code Management: Generation of Code Inspector Variant and SAP Note 2270689 – RFC Extractor for performing static checks SAP describes how to use the SAP Code Inspector to execute a remote check for the custom code analysis. These SAP Notes contain also How-To-Guides for the SAP Code Inspector.
But in your description, the ATC is the tool of choice.
What is the right recommendation for customers?”
Olin Dolinskaja recommends the ATC with Remote Code Analysis
Certainly, it is good to reduce the custom code if possible, but the custom code was written for a reason.
The ATC with Remote Code Analysis
This is the tool recommended for static quality checking and custom code checking for S/4HANA.
The ABAP Call Monitor (SCMON)
This is for analyzing the code usage. This is supposed to be used in conjunction with ATC.
“The purpose of the ABAP Call Monitor (transaction SCMON) is to monitor the execution (usage) of ABAP code (function modules, method calls etc.) in your productive system.” – SAP Blog by Olga Dolinskaja
From Olga’s blog.
This shows the programs and objects that appear from the SCMON From Olga’s blog.
Then one can review the request types and names. From Olga’s blog.
Overall, we would not rate SCMON as a very transparent tool. Most likely we would prefer to stay away from this transaction if possible. And this gets to one of the primary issues of the introduced tools — there is no evaluation of the quality of the tools. They are simply introduced as items that should be used.
S/4HANA Migration Cockpit
The following is from the presentation on Migration Cockpit for 1808/1809
This explanation gives us little confidence.
Notice the migration process is declared. Notice the “Lab Preview” label on the screen. This is fairly typical that the item is still in development. This document was written in Dec 2018, roughly 4 years after S/4HANA was introduced, and SAP has still not finished its development of it remediation tools. SAP has very happy to rush S/4HANA out the door, without having tools to support the remediation, and who knows when this screen will actually be complete and the functionaltiy ready to use?
One of the important topics to consider is how much success has SAP had with introducing “helpful” utilities like this. In our view very little. Therefore each of these tools that are being offered by SAP really needs to be analyzed, rather than simply used.
The Migration Object Modeler 1809 (This is actually part of the S/4HANA Migration Cockpit)
Here is a basic introductory screen.
This supposedly simulates how the value in the upload file will be imported to the S/4HANA target system.
This graphic seems to imply that two categories of data sources go into the Migration Cockpit, and are entirely organized and then sent to either on-premises or cloud S/4HANA. This is a massive oversimplification of what occurs. This is the type of graphic that is often put out by SAP marketing that is designed to make everything look easier than it is.
Use the SAP Solution Manager Custom Code Lifecycle Management Tool
“The SAP Solution Manager tool Custom Code Lifecycle Management (CCLM) can retrieve the usage data from your productive system and visualize them for your convenience. Based on the graphical presentation you get better transparency of the usage of your custom ABAP code and can easier analyze it then using only UPL technical data.”
The ABAP Test Cockpit
We have heard of little feedback on this tool, the image is from the article at SAP Blog.
The Simplification List
This is a list of changes that are updated per release. Again, it is misnamed. It has nothing to with what has been simplified and is about simply what has changed. However, one issue to consider is that Simplification Lists are extremely lengthy and very time consuming to read. This tends to be left out of any discussion around the list. Notice the complication involved in comparing to the Simplification List.
“Second, you need to fix SAP HANA and SAP S/4HANA findings. Adapt your custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results).Findings of SAP S/4HANA checks are related to S/4HANA Simplifications. Each simplification requires a different approach to solve findings. Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them.” – SAP Blog
Here it is expressed that each S/4HANA change needs to be checked against their own SAP OSS Note.
The SAP blog is good enough to include the major simplifications.
“2215424 Material number field length extension
2198647 Data model changes in SD
1976487 Data model changes in SAP S/4HANA Finance
2220005 Data model changes in Pricing and Condition Technique
2214585 Sales support is not available
2223144 Foreign Trade is not available
2206980 Data model changes in Material Inventory Management
2227579 Storage Location MRP
2226131 Public Sector specific fields in Business Partner
2296016 Removal of orphaned objects”
SAP’s Recommendation for Going Forward
“In addition, your custom code needs to be checked with ABAP Test Cockpit (ATC) against the SAP S/4HANA simplifications in the Simplification Database and for any SAP HANA related changes. The result is a list of findings where your custom code does not comply with the scope and data structure of SAP S/4HANA. At this step, you can estimate the required effort required to adapt the custom code to migrate to SAP S/4HANA.”
This is itself an oversimplification. This means only that the information is partially available to perform any analysis.
The Absence of the Legacy System Migration Workbench
SAP removed the LSMW as a migration tool, although it is still part of S/4HANA. This is covered in the following quotation from the note 2287723.
“The Legacy System Migration Workbench (LSMW) should only be considered as a migration tool for SAP S/4HANA for objetcs that do not have interfaces or content available after carefully testing for each and every object. The use of LSMW for data load to SAP S/4HANA is not recommended and at the customer’s own risk.”
Using Benchmarks for Remediation Estimation
One question that companies will face is how much effort to put into the remediation analysis. Companies normally will not want to fund a fully remediation analysis, but rather will want to determine an estimate of what that remediation will entail in terms of effort, time and money. Let us review these statistics from GekkoBrain.
“450 priority 1 issues
29,019 priority 2 issues.
After runtime usage filtering, we typically remove about 50% of the issues, which in the above case left us with 14,573 priority 1 and 2 issues.
With approximately 20 minutes per issue, this amounts to 607 days work!”
So this is very back of the envelope calculation. Here is the more detailed math. 14573 * 20 min = 291,460 minutes.
Now we take 291,460 / 60 min to get 4,857.66 hours. 4,857.66 hours / 8 give 607 days of work.
Now at this point, the project planning, of course, must include the identification of resources. Because we have to be careful with this next step so as to not simply project duration without knowing if the resources are available, and of course the productivity of each resource.
There are 260 workdays in a year. If three developers are used one ends up with .77 of a year, or 9.24 months. One of the things that can be appealing is to add more developers. But one cannot necessarily just add more developers to a job as is explained in the book the Mythical Man Month.
His observations on this topic are explained below:
“He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. He also made the mistake of asserting that one project—involved in writing an ALGOL compiler—would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called “The Bible of Software Engineering”, because “everybody quotes it, some people read it, and a few people go by it”. The book is widely regarded as a classic on the human elements of software engineering.
Brooks discusses several causes of scheduling failures. The most enduring is his discussion of Brooks’s law: Adding manpower to a late software project makes it later. Man-month is a hypothetical unit of work representing the work done by one person in one month; Brooks’ law says that the possibility of measuring useful work in man-months is a myth, and is hence the centerpiece of the book.
Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.”
As S/4HANA implementations become more common, estimation errors in code remediation will increase. And it is quite likely that the mythical man month will be applied yet again in order to try to push S/4HANA implementations to be performed earlier than they should be. At the forefront of this will be both SAP and SAP consulting firms that will make valiant efforts to have their customers to underestimate the time and complexity of code remediation.
A Two-Step Process
Therefore the estimation is a second part of the process after the initial data has been extracted from the SAP system.
- The information published by SAP on code migration is both not well formulated and filled with both contradictions and bad advice that has more of a sales/marketing orientation than a technical orientation. In the wide-ranging SAP analyses that we have performed, this is one of the most confusing areas. SAP’s terrible explanations about code remediation pose a major risk to S/4HANA implementations.
- Simply learning the tools and the effort involved in code remediation is its own mini project. One of the important topics to consider is how much success has SAP had with introducing “helpful” utilities like this. In our view very little. Therefore each of these tools that are being offered by SAP really needs to be analyzed, rather than simply used.
- The steps as explained by SAP are quite a lot of work. Testing of the tools presented by SAP show that they can often be more work than they are worth. They also create an unrealistic expectation on the part of the customer that the work will be faster than they think.
- The large amount of work in custom code remediation shows why the average implementation time estimates from SAP and their published case studies are so ridiculous, and why the Florida Crystals claim to have “upgraded” from ECC to S/4HANA as we covered in The Florida Crystal S/4HANA Case Study is pure fantasyland. Not only doing the work, by analyzing the work to be done is a serious research effort. There are many different ways of performing the remediation, and the first part of any remediation is figuring out what are the likely best methods to use to perform the task.
A rather surprisingly candid explanation of the task of code remediation is found in the following quotation.
“There’s no hiding the fact that this is an involved task. Almost every HANA-readiness project we’ve been a part of has required fixes for tens of thousands of incompatible code instances. Usually, it’s a case of months, or even years, rather than weeks.
Unfortunately, it’s impossible to say exactly how much time any individual instance of incompatible ABAP code will take to fix.
In our experience, the majority of issues take an hour or less to fix, but when you’re trying to plan a HANA-readiness project containing tens of thousands of issues, loose estimations will result in widely inaccurate forecasts.
For example, if you have 20,000 issues to fix but the estimation for each issue is out by just 15 minutes, it will result in your forecast being incorrect by over 150 working days.
The only way to gain an accurate estimation of how long it’ll take to fix your custom code and get HANA-ready is to go through and assess each issue individually – a time-consuming but ultimately worthwhile process to better plan the project. Staying on top of your HANA-readiness project can feel like a full-time job in itself. Just keeping track of which code items have been fixed, which are currently being worked on, and which are still unresolved isn’t easy when there are tens of thousands of issues that need to be adapted.
Any HANA-readiness project is extremely time-consuming and each one will take a different length of time – making it difficult to stick to pre-agreed budgets. However, using a tool like Gekkobrain can help reduce the pressure by automating some time-intensive tasks.
Although you’ll still need to manually adapt any incompatible custom code, Gekkobrain provides a clear list of code items that need fixing and an estimate of how long it’ll take, as well as giving you the tools needed to effectively and efficiently manage the project.
“ – GekkoBrain
And of course, we were not surprised to read the partner list on the GekkoBrain website and find that they are not a partner with SAP. This type of disclosure would not be allowed if GekkoBrain were an SAP Partner.
GekkoBrain provides an impact analysis of the different remediation issues. Notice some of the issues are SQL errors and notice also that the items or issues are coded by complexity level and by their impact.
Notice there is also an hour estimate per issue.
This shows the top right item, which is the original source, and the lower which is the code fix. Notice how the select statement has been significantly changed.
Customers tend to be surprised by how much code must be cleaned as part of an S/4HANA migration.
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.
The Risk Estimation Book
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.
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