Let's get SAPpy

When we actually started the work on the implementation, it was agreed to have a project team of senior managers to cover the main functions within the business. This makes a lot of sense - however, I was bit concerned that they didn't want to get input from the staff. After all, these are the people that are actually going to use the product on a daily basis - they will often have a far better idea of what work they do and what problems they face than the managers.

As I have studied Requirements Engineering, I had previously carried out an elicitation process to determine some of the needs of the business. This data was presented to the consultants, but it was clear that they had no interest in that information. Their arguement was that they provided "best practice" in operations and would ask us to examine our processes to make them more efficient. Now I understand this view and don't entirely disagree with it; it makes sense to streamline processes before the new system goes in, as it won't happen after.

However, I would suggest that what they define as "best practice" is nothing of the sort. Basically, they have written some variations in their software for various large organisations (who have paid a great deal for this) and they take various bits from different companies that they think are a close match for the business that the customer business is in, and install those. They then try to persuade you that what they have provided is the "best practice" for that function. In some cases this may be true, but from what I have seen so far, the processes are generally clunky, long winded, and very inefficient.

Anyway, so away we went - meeting after meeting after meeting. Death by PowerPoint. I made a point of taking notes at all the meetings I attended; subsequently, I typed them up and published them on the company intranet for all to read. I noted that at several of the meetings, we had more than one consultant present, but they seldom took part - all of the talking was done by one person. They took no notes at all - their agendas were often just 2 or 3 bullet points, and they never published an action list. (I also noted that the spare people were busy emailing other customers of theirs; but we were paying for their time!)

Later, I questioned some decisions that they took and they insisted these had been agreed at meetings. I showed my notes and asked for theirs - of course they had none. They objected to my typed notes saying that they were invalid - I presented my hand written notes to back up the more formal ones. Needless to say, this went down like a curse in a church. They subsequently insisted that I should not be involved in any meetings - I was not then invited to attend any more. In fact, I later made a point of sitting in on a couple later and the consultants' director objected to this - he told my company that my presence was "disruptive".

They referred to this initial stage as the "blueprint" phase - I understand from others that this is a common process with SAP. It's portrayed as providing a proof of concept for the developed product - but they don't actually provide the software at the end of it which seems strange to most developers. What you get is - you guessed it, a series of PowerPoint presentations which indicates the processes from a high level. But as many have found, the devil is in the detail.