Additional Blogs by Members
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
0 Kudos


Hello SCN Community members,

Before skipping the introduction, ask yourself the following questions:

How often do you read the manual of a product you purchased? If you actually do start to read how far do you read it? Will you check each small part of the manual to make sure you didn't miss anything or do you check the index and choose which parts you will read?

Panasonic DMC-G10

picture 1.1

I recently bought myself a Panasonic DMC-G10 (see picture 1.1) which is a micro system digital camera which can take pictures and record video. I checked out reviews on the internet to know which one had a good price/quality. If it would be a crappy product, you would have to read through the manual because the interfaces and controls wouldn't make sense. If your product is at least average or above the manual is less referenced (not less important).

I doubt most people start reading through the whole manual before starting to use a product. When using the camera you have preset scenarios which set the right options; you even have AI (artificial intelligence) at work nowadays (face recognition etc) which automatically configures the options so why should I start by reading the manual first?

I will start reading the manual when I want to perform actions which are not possible through the preconfigured scenarios and AI. I would call it more advanced use of the product where it's no longer part of common sense or the touch a few buttons and it works philosophy.

It does make sense to read a manual (or at least part of it) if you get something you have never seen in your life which isn't straight forward.

Time is money

Let's consider a meeting takes place, the project leader has some critic on a technical consultant, one of the steps involved to set up a SAP system failed and some time was lost fixing the issue. His criticism is that the technical consultant could have foreseen the fact that it would fail by reading through the documentation of SAP.

Now the project lead has a valid point, in theory that is. It just doesn't work that way in real life. Business is focused a lot on money, the age of the factories (more employees that cost as less as possible to produce as much as possible to make a profit) is not yet over. Guess it will stick around until it becomes no longer profitable (which is not anywhere in the near future).

I have seen technical consultants print out the full installation guide, all relevant SAP notes, all related known issues that SAP has, all relevant information related to the topic. I have seen them mark the important words, bundle the content in maps and carry the papers home (although I sometimes suspected some of them to have a stove at home). In the end it takes too much time and the operation becomes too expensive. As a result the technical consultant looses his contract.

Perhaps the quality of the work performed was better than others who didn't read all the documentation but in the end the consumer doesn't care that much when the bill arrives. I'm not saying they shouldn't care. Let's take a look at it in another context.

For example you want to buy a television and in a nearby store which costs 2000 Euro. It's a brand new technology and the television is the first in his kind. They deliver the television at your home and the delivery guy has to configure the numbers of the television channels twice because he made a mistake in his first attempt (he briefly checks the appropriate section in the manual the second attempt). It took him 20 minutes. You pay 50 euro additional because the television was delivered and configured at your home.

Now imagine someone else buys the same television, the same price 2000 Euro. The delivery guy starts reading the manual for two hours and marks the important words. He configures the television channels and everything works in the first attempt (which is not a guarantee because he read the manual). You pay 150 euro additional because he spent time on reading the manual but you are sure (at least you would think) it's done correctly.

Which one would you choose? Do you really care if he delivery guy has to configure the television channels twice? In the end he was done after 20 minutes and compared to the second case you could spend time an hour and forty minutes doing something else with the 100 Euro you saved.

In this example the price difference isn't huge but rest assure in business situations the price difference can be huge.

The information age

In my opinion, we are heading for the information age, where it becomes less and less important that you know everything by heart. It is also becoming nearly impossible to know everything about SAP because the areas are spread widely and they keep on spreading the area each day.

In the past and still in the present, there are experts who have an extensive knowledge on a specific topic. They are almost irreplaceable (but then again no one is irreplaceable). Today it's becoming harder and harder to become an expert because of the internet, the widely spread knowledge and the because of the visibility of persons.

People are starting to share more and more knowledge because face it, you can really help each other out and create added value for everyone. Communities can have a strong influence on the products success. It is a fact that SCN keeps growing, along with the growth more people will start to share knowledge.

I strongly believe in the information age and keeping knowledge to yourself doesn't make you stronger. It's a sign of weakness, a fear that you will be replaced once you share your knowledge. They will replace you anyway if it suits them, even if you have certain knowledge no one else has. In my opinion being active on SCN by sharing your knowledge, learning new things and connecting with people can keep you one step ahead of your competition (for now that is). The exceptional from yesterday is the standard of today.

My answer to the question, what is the market looking for (on my evaluation for 2010) is purple cows. For those that are not familiar with Seth Godin's book "purple cow" it means something has to be remarkable to be noticed. No one will stop to check out a normal cow at the side of the road but for a purple cow they might stop. I see this is also becoming the case for hiring consultants. More are entering the market, good is not good enough anymore, you have to be remarkable.

The dark side

The danger in having all this information online (detailed instructions of every little step) is that people stop thinking and only perform what is presented to them.

I still have a customer message open at SAP in which I have a six page blog post attached. During my work day I noticed a performance issue in a SAP system. Because I had other (more urgent) tasks at hand. I checked the issue in the evening at home. Since I found it to be an interesting issue, I decided to start writing a blog on the topic. On page six of my blog I came to the conclusion that I was back at the point where I started after following a bunch of SAP note instructions, performing SQL statements and so on.

How come it was not noticed before? The instructions are not new at all. They exist for some years already. I notified it but I haven't yet received an answer to why this is the case. If I do get a logical answer to the question, I will post the blog online.

Another example is the Earlywatch reports for Java. I pointed out in one of my blogs that the numbers in the Earlywatch report are simply impossible. When the data capturing is broken at some point, zero values are written into Solution Manager and they end up on the Earlywatch report. The problem is they end up on the report with a green status stamp on it which says: "your system is running fine" while you actually have no clue at all if it's the case. How come many didn't notice it?

The same problematic situation arrives when troubleshooting is called for. In my opinion troubleshooting is also a form of art; you can read one of my previous blogs on the subject: The art of troubleshooting. What makes it a form is art is the fact that it's not all noted down, you have to search, use logical sense and put the pieces of the puzzle together.

I have a lot of respect for the people working on the support backbone of SAP. It's not an easy task as some might think. Sometimes it is hard to get people to realize that it's impossible to find information online on a problem. Someone has to be the first to encounter a specific problem. If they don't place the solution online after the problem has been solved, the second person who encounters the problem will not find the solution online, and it is as simple as that.

Writing, an art form

Manuals and documentation are written by many different persons. Not everyone is as strong in writing manuals. Exceptional writing can also be considered a form of art.

What is happening is that community members start to rewrite manuals. Some parts of the official manuals are unclear, other parts are written with words that cause confusion and other parts are simply not understandable. Blogs, e-learning content, forum questions, pod casts and so on slowly fill those gaps where the manuals are unclear, where there are parts missing and this makes them valuable.

It doesn't mean the manuals shouldn't be revised or changed, it means it becomes more feasible to perform operations due to the knowledge that is available online.

I don't mind sharing knowledge and my documentation will show that. Instead of leaving parts out to confuse the competition (other consultants from other firms in my case) I add parts so they could use it as a reference for a similar (yet different) scenario. Sharing knowledge makes you stronger, don't believe it? You should try it out for yourself.


I received some messages from a young SAP Basis Administrator who had some questions for me after reading some of my blogs. One of the questions concerned SAP documentation and notes, whether it is important to have read all the content or even remember the content. In my opinion it shouldn't be a goal to know documentation or SAP notes by heart.

When you perform a SAP system installation for the first time, it makes sense you use the installation guide as you have never done it before. If you have installed SAP systems several times already, you might only use the index and check some post processing steps, specific to the product you are installing. The installation wizard screens doesn't change that much over time and if it does change, you can look it up if needed at the moment that you are actually performing the installation.

Basically there is no golden rule when to use a manual and when not to use it. You have to feel this yourself, is it straight forward enough for you to continue without reading or do you have to read because you have no clue what to do next?

I can say that as a consultant if you spent too much time on it and others don't and they deliver the same quality of the work in the end, it's very likely the customer will end your contract in the long run. But when you look at it from another perspective (television example), you would probably do the same thing.

For me personally, I will not start marking lines in documentation. I start the operation and I use the documentation as a reference guide when the operation stops being logical or when it becomes too detailed (specific parameter settings for a product you have never used which you have to look up). I don't think learning documentation or a SAP note by heart is the way to go, my method is absorbing the knowledge by performing the actions which works fine for me. Of course not everyone uses the same method or should do so, what works is personal.

For SAP notes I would advice to use the "my favourites" option in SAP Service Marketplace. That way you can keep a list of important SAP notes at your disposal. You can create folders to bundle them on a product or topic to keep the list small enough to retrieve the correct SAP note very fast. I don't keep track of SAP notes that are really product version specific (for example bug fixes for a problem in a specific SPS stack). I keep track of more generic SAP notes like the SAP note on Oracle parameter recommendation. It's not useful to use a favourites list if you store all SAP notes in it you encounter.