How to Improve Knowledge Transfer on SAP Projects - Brightwork Research & Analysis

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Knowledge transfer is typically managed very poorly with SAP contracts.
A major problem is the declining quality of SAP documentation.

Introduction to SAP Documentation

I was recently asked how a company performing an SAP implementation can improve its understanding of SAP. This was within the company’s context, noting that some of its resources were not obtaining enough knowledge quickly enough. In this article, you will learn about SAP’s documentation.

How SAP’s Documentation Works

SAP is a complex topic that requires years to learn how to configure. I do not have any official statistics on this. However, I estimate that SAP’s overall code base and training documentation must be the most significant software library ever developed. The inherent complexity of SAP software means that SAP projects are some of the longest in the industry. However, the result is that, as with any other software, the company must come out of the process to run, troubleshoot, and understand the software. Many companies do not get the knowledge transfer from the consulting companies that they require.

I have a related article to this specific to a complex supply planning method and the lack of socialization that this method receives.

The Importance of SAP Project Documentation

One of the most critical parts of knowledge transfer is project documentation. However, there are essential but often undiscussed features of the criteria for project documentation discussed in this article.

Writing Criteria for Project Documentation

First, it must be logically written. It must be accurate and kept up to date. It can be effortless to “check the box” on the documentation without making very illuminating documents. Technical writing is generally not much lauded. Instead, we tend to hold up the skills of creative writers. However, excellent technical writing can be enjoyable to read. It is declining rather than improving because of a combination of a general reduction of attention span encouraged by electronics and media, of the number of foreign-born workers in IT, along with the “PowerPointification” of documentation.

Interestingly, NASA’s internal review of how it managed and presented information after the Columbia disaster concluded that its engineers had become over-reliant on PowerPoint and had lost their ability to write detailed technical documents. This decision related to determining the risk of the Columbia’s O ring that should have been straightforward, to be far more debatable. Edward Tufte, a data visualization expert, has observed that PowerPoint’s medium makes the “massaging” of information to meet the desired outcome of management easier than in a word processing document. A full explanation of these facts, along with Dr. Tufte’s analysis, can be found at this link.

The Common Issues with Project Documentation

It is critical for the successful implementation and maintenance of complex systems. Once written, many documents tend to age rapidly, as they do not change with the design. Long documents tend not to be updated. Therefore, when I arrive at many projects, I am told that the functional design documentation is out of date. As I write this, I currently have design documentation written by a previous consultant that is also out of date. Completely rewriting documents is time-consuming. However, adding notes onto existing documents is typically not. Many design documents can fall into the habit of taking stating what will be set up with too much certainty. One of the reasons that design documents tend to age so quickly is they do not explain the reality that some things are unknown, or several different approaches need to be tested. There are many dependencies. These dependencies should be stated in the order that the documentation reflects reality and explain that multiple pathways are available at the time of the document’s writing.

One cannot expect the documentation to be instantly updated when a design change is made. Therefore, flexible documents that describe the age of the options much better. Also, attempting to write overly definitively on unknowns is a problem in documents in many areas, not just in technical writing on software projects. Rigid documentation that makes a pretense of certainty of uncertainties reduces the understanding of the reader’s part. Also, when the reader then finds that major sections of the document say one thing, while the reality is different, the overall material’s reliability is called into question.

The Importance of Screen Shots

In application, the experience is, of course, essential. However, in the application, the experience is, by its nature, transitory. One cannot create notes on applications, markup application screens, insert logical flowcharts between screens, or do any of the things that can be done in a document format. Documents with screenshots can be saved and sent anywhere and do not depend upon people being available for demos. With SAP descriptions, words can only take a person so far.

Screenshots help fill out the rest of the story, and of course, are effective at showing readers where to go and what was set up. Besides taking screenshots and placing them into documents, marking up screenshots is also important and not often done. A marked-up screenshot tells the reader where the activity is happening. This is particularly important on SAP screens that have many fields. Below is one such example.

It takes very little time to markup a screenshot, and the benefit is quite significant. Reading through unmarked screenshots dramatically reduces the speed by which a reader can progress through the material, as their time is wasted attempting to figure out what the relationships are. However, many companies had stopped purchasing separate screen capture programs like Snag It (my personal favorite for PC is HyperSnap, while I use the excellent Skitch for Mac) when Microsoft introduced a built-in screen capture program for Windows 7.

The Screen Capture Program

This capture program does not allow mark up and means that people without a “real” screen capture program must move the screenshot into PowerPoint, mark it up there, and then retake the screenshot in PowerPoint with the markup and then insert it into Word. This is tedious and therefore tends not to happen that often. This is another example of bad IT decisions made by those without an intuitive understanding of productivity or what their employees need to do their job effectively. Companies save something like $20 (the price I estimate if purchased in bulk) per computer by removing a specialized screen capture program. Therefore, screen capture markup has decreased because of this development.

The Importance of Sources

Project documentation is strange in that it almost always lacks references. I recently read a white paper from Booz Allen Hamilton, which quoted several statistics, which also completely lacked sources. There are two angles by which to approach this topic. The first is from a standards perspective. A basic rule of writing is that any quote, idea, graphic, etc.. which did not originate with the author must be referenced. The many Booz Allen Hamilton papers on their website, which lack references, is a particularly egregious disregard for this rule because these documents are available for public download. However, internal documentation also needs to be referenced. This is where the second angle comes in.

Showing sources is the right thing to do but is necessary for the reader to determine which parts of the document were written by the author and which were primarily written by someone else. It tells the reader what part of the material is really customized for the project and which sections are how the software works. The problems with unreferenced works are too many to mention, and it is always a surprise to me that companies do not require all documentation to have sources included. In addition to a reference section, quotations must be explicitly defined. Imagine if I were to write a physics paper. Without a requirement for references, I could pass off my common knowledge of the topic to be much higher than merely by including others’ writing.

Another major benefit of quotations and references is that the reader can then, if they choose, go and check the quotation source. Unfortunately, some university professors discourage the use of quotations or the use of excessive quotations. They propose that too many quotations may weaken the document and that writers should paraphrase an author’s words and ideas. I’m afraid I have to disagree with this viewpoint and easily prove that the best policy is a clear delineation between the originator of the data and the concept.

Now that we have spent a good part of the article discussion documentation, the next topic I would like to cover is consultant selection. It will need to branch more broadly human development to provide the necessary supporting evidence for what I am proposing.

The Ways to Effective Knowledge Transfer

This article describes in practical terms what can help a company along the way to knowledge transfer on SAP projects. It will eschew the slightly soft orientation of many knowledge transfer articles to prescribe specific things that can be done but are most often not done. There are many areas to focus on knowledge transfer, but this article focuses on the following items:

Technical writing and documentation
Consulting resources description and selection

Understanding the Importance of Quality Documentation

Documentation has so many advantages on projects; it is hard to describe them all. Cultures can be very neatly divided into those that have a written language and those that do not. Society’s that lacked a written communication had a firm cap on the technological complexity they could achieve. When one thinks about historical examples, we can observe that definitive statements go back roughly to the Egyptians, which is 6000 years ago. This is because this was the development of writing combined with store writing (Sumerian tablets being the first “portable” surviving written objects).

However, humans have existed in a similar modern form for around 100,000 years. What happened to the other 94,000 years of history? Before the Sumerians, we are forced to look at cave markings/murals and unearthed physical objects. However, while this is a historical fact, many consultants overly rely on oral explanations, and too many companies accept verbal explanations. Oral explanations have a way of enhancing the consultant’s power because they are then the source of information, and this provides a degree of job security.

In addition to their transitory nature and practical inability to be stored, oral explanations have a strong tendency to hold back the development of a project and significantly reduce the knowledge transfer of a project. Because most consulting companies base their entire business model on extending projects and maximizing the number of billing hours extracted from their client, it is not surprising to me that companies like Accenture and IBM seem to orient their consultants around speaking in meetings and providing their clients with a lack of clarity. I was assigned as a module consultant as an independent and an IBM consultant who seemed to take the client through lengthy explanations of similar topics every few days that varied slightly every time the story was retold. It was quite impressive if one can be impressed with inefficiency. We never seemed to make much progress. On some occasions, I wondered if I was on an IT project or had wandered into group therapy. But, his confusing explanations of the functionality eventually made him indispensable. This approach is not restricted to software consultants is a rule in academics as well. One can be moderately successful as an academic with good ideas and reliable research, but to be an exceptional academic, one must be indecipherable.

Requiring the Writing of Effective Project Documents

Every project that I have worked on has various documentation, but not many projects have had what I would call proper documentation. There is a great deal of nuance that is required for documentation to enable knowledge management. Companies can control the quality of documentation much more than they think they can and much more than they do. First of all, they can set standards for how they want the documentation written. Secondly, they can hire a technical writer to improve, provide feedback, and ensure the documentation’s consistency.

With the expenses that an SAP consulting team is costing the company, it is a small price to pay to have a technical editor/writer go through the conformance to company guidelines. I have written several books, and I hire a professional editor to check and make suggestions on my manuscripts. A good author/editorial relationship often dramatically improves the author’s writing.

Some of what technical editors do is correct grammar, but much more of what they do is nudging the author to make the writing more clear and flow better. Technical editors can be in-house or hired from external sources. Having worked with several editors, I wanted to point out that the editor must have experience in the area. The editor I had worked on my books had several years of experience working in the IT industry.

To keep this article from getting too long, I have moved to other vital documentation areas out to this article.

The Importance of Sources

Project documentation is strange in that it almost always lacks references. I recently read a white paper from Booz Allen Hamilton, which quoted some statistics, which also wholly lacked sources. There are two angles by which to approach this topic. The first is from a standards perspective. A basic rule of writing is that any quote, idea, graphic, etc.. which did not originate with the author must be referenced. The many Booz Allen Hamilton papers on their website, which lack references, is a particularly egregious disregard for this rule because these documents are available for public download. However, internal documentation also needs to be referenced. This is where the second angle comes in.

Showing sources is the right thing to do but is necessary for the reader to determine which parts of the document were written by the author and which were primarily written by someone else. It tells the reader what part of the document is really customized for the project and which sections are merely how the software works. The problems with unreferenced works are too many to mention, and it is consistently a surprise to me that companies do not require all documentation to have sources included. In addition to a reference section, quotations must be explicitly defined. Imagine if I were to write a paper on physics. Without a requirement for references, I could pass off my common knowledge of the topic to be much higher than it is by merely including others’ writing.

Another significant benefit of quotations and references is that the reader can then, if they choose, go and check the quotation source. Unfortunately, some university professors discourage the use of quotes or the use of excessive quotations. They propose that too many citations may weaken the document and that writers should paraphrase an author’s words and ideas. I’m afraid I have to disagree with this viewpoint and easily prove that the best policy is a clear delineation between the originator of the data and the concept.

Specialization and Human Development

The first question to ask is how SAP consultants are selected and molded. In my view, both end clients and SAP consulting companies tend to take a narrow approach to select SAP consultants. They select application/configuration experience over all other skills, including communication, writing, explanation, and even truthfulness. I can say that selecting a single skill set over all others reduced the quality of implementations. One cannot have all things from a resource. This applies to the scope of knowledge as well. I once was sent a resource requirement from a cosmetics company for what looked like three roles in one. The cosmetics industry has enormous margins. The process flow is taking drums of commodity chemicals, placing them into small packages, and then selling dream, unsubstantiated concepts of anti-aging and beauty to women at an enormous markup. The chemistry is high school level, but the trick is marketing.

“The appearance of fine lines will disappear!”

With a 400% profit margin, it seems curious that this company could not afford to hire three resources directly. However, if we think more simply between various skills usually expected from a role, communication, writing, configuration, moderation, ability with graphics, etc.. they cannot be had in equal measure. This is because the background, aptitudes, and motivations that make a person a good configuration consultant does not make that person an excellent educator. Often I will see requirements that this consultant should have “excellent written and oral communication skills.”

The Training and Expectations of SAP Consultants

Only a tiny percentage of SAP consultants have excellent written and oral communication skills. In practice, clients prefer technical consultants who can answer their questions as quickly as possible. The way to develop this capability is to work for many years in your application area and not spend much time looking into other areas. In essence, it requires taking a narrow focus and spending less time socializing what you know and understanding what other connecting applications are doing. This is one reason it is so difficult to find proper solution architects. How do they come up? Therefore it is not at all surprising that clients often complain that their consultants focus too narrowly, do not understand how the applications connect in an “end to end” process and do not transition enough knowledge quickly enough. But it must be understood that their selection criteria are limited, and their “development” by consulting companies is also quite limited.

Therefore, these complaints should be partially seen as related to how SAP consultants are selected for getting onto projects and the types of skills that clients look for. Clients want every possible talent, but humans can only develop so many skills, and any human naturally only has so many aptitudes. With what we know about neuroscience, this should be better understood. The development of knowledge means the removal of neurological pathways that could have been developed in other ways. Once a human reaches a young age, they have more neurons than they will ever have.

As we gain experience and knowledge, the brain “kills” an enormous number of neurons and, therefore, neural connections. The pathways left to make up how we think, what we know, our aptitudes, etc. This is, of course, modulated by our genetic heritage, which further controls our potential in different areas. The specific term for the brain’s ability to adapt to new information is called neuroplasticity and only goes down as we age. This is why languages are so easy to learn when we are young and challenging to learn as we age. It explains why Arnold Schwarzenegger still speaks with a heavy Austrian accent even though he has lived in the US for over 40 years.

How to Understand Knowledge Transfer as a One Way Street in Consulting Companies

Consulting companies have a great emphasis on group cohesion, the necessity to meet after work to listen to the directors’ grand pronouncements (i.e., the generic self-aggrandizement of various con men or directors and partners in the consulting firm who all have narcissistic personality disorders). The stated purposes of these meetings are to improve communication among the team. But the length of the meetings points to another purpose, reinforcing the organizational hierarchy of the group.

“Sir, You Are Tedious”

One of the more tedious parts of dealing with consulting companies is when they feel compelled to tell you about their great history. I sometimes feel like stopping them and saying.

Look, your consulting company was started by several greedy individuals who then subordinated a number of less experienced individuals, sold them on the concept of a pot of gold at the end of the rainbow, and then became accustomed to living off the work of others and then bought some European branded automobiles for themselves. Stop me if I have missed any part of your story.

However, I don’t work for them because they typically want to mine sub-contractors for knowledge transfer. This is so on the next project, and they can staff positions internally. However, on the converse, I have found and discussed this in my book “Supply Planning with MRP, DRP, and APS Software,” that I have yet to see an effective knowledge transfer job performed by a consulting company their clients. I combine this with the fact that consulting companies’ amount of documentation is anything more than marketing literature in disguise, that consulting companies are entirely hypocritical when it comes to the topic of knowledge transfer. It is to be jealously guarded when they know it is a “trade secret.” However, when they don’t know, all of a sudden, the term “knowledge transfer” becomes one of the most popular in their lexicon.

Who is Actually Paying?

However, the hypocrisy goes further. When a company is hiring a consulting company, part of what they are paying for is knowledge transfer. Yet, with a subcontractor, the consulting company is paying the subcontractor with the client’s money. Furthermore, they add on a margin to the subcontractor, which can be anywhere between 50% to 100%. Therefore, they are making money off of the sub-contract resource every hour they work. If they are not paying the subcontractor, what right do they have to claim knowledge transfer from the sub-contractor? Secondly, let us all consider the effect on the knowledge transfer provided to the client if the subcontractor is also providing knowledge transfer to the consulting resources? My opinion is it goes down. Therefore, the most honest statement that could be made for this scenario is the following:

Take some of the knowledge transfer that you were going to provide to out client (and which we are talking up to them in order to convince them to let us bring you in), and then divert as much as you can to our own resources. Also, do not tell the client that you are doing this.

Who Deserves the Knowledge Transfer?

Ostensibly the subcontractor should be providing knowledge transfer to the end client, as they are paying the bill. However, consulting companies don’t see it that way. They believe that while the client is paying, the real necessary knowledge transfer needs to go to their consultants. This is the situation that software vendors find themselves in. Often a vendor will become a subcontractor to a consulting company that is prime. However, once the software vendor resources get on-site, they find that their role is to educate the client and educate the consulting company. Therefore, on multiple occasions, the consulting company is taking money from the client and not performing services with it but using the client’s funds to train their consultants. It is quite a tangled web they weave.

Give Me Free Information…..

The issues of consulting company information parasitism are not merely limited to working for them as a subcontractor. I have been contacted on several occasions by directors at consulting firms who “would like to have a conversation” about the SAP APO market and how they should improve their consulting practice, which is to get some SAP APO billings.

All of these requests have been without the offer to pay for this information. These directors seem to think that our charity’s best use is not giving to the United Way, but instead, it should be given to needy consulting companies.

However, when these consulting companies market their services, they seem to always charge for their services. You can imagine my confusion about the unwillingness of consulting companies whose directors need guidance on how to grow their consulting practice to pay money for this information. I get a request like this every few months. I am not sure why I would care either way. If they are successful, then I can work for them as a sub-contractor. They can put a margin on my rate and then control the opinions I offer the client? What a privilege. Their thought process seems to be “Help us get clients so that you can subordinate to us.” Even when consulting companies lack knowledge, they still think they should get a consulting business, and they will steal the information by any means necessary. This free consultation is on top of all the free information that we already give out through this website.

The Consulting Company Ethics Mambo: How Low Can They Go?

If I have learned anything, there is no floor to consulting companies’ ethics. Every time I think the bar is at one level, another experience drops the bar again. At once, I felt that this behavior was concentrated in just the major consulting companies, but I now realize that the smaller consulting companies are often just as sleazy. Many of the directors who manage large consulting companies were trained in large consulting companies. They did not leave because they were offended by Accenture or IBM’s terrible ethics, but simply because they were unsuccessful in those organizations. I have realized that they are mostly all the same. The only real difference is that large consulting companies are more powerful than smaller consulting companies, so they have more unethical opportunities.

Go to top

Conclusion

Many areas can be made a focus on knowledge transfer. I have selected two of the most important ones, in my opinion, which are optimizing documentation for knowledge transfer, and broadening out the selection criteria of SAP consultants to bring in broader skill sets. Just these two changes can make a big impact on improving knowledge transfer. Both of these approaches are only in scarce circumstances implemented.