Paperwork

Right back at the beginning of our project, I talked to the SI about the need to provide us with detailed information concerning what changes they had made to the system. To me, this is just good practice – any time that someone makes a change to a system, it should be documented. There are a number of reasons behind this – people are not always available to confirm what has been done, jobs change and people move, security and audit issues etc. so good documentation is really important, especially before you start making other changes.

The SI promised that we would have full documentation, and they did indeed send us a document once we had gone live. However, it contained almost no actual information on the changes made, other than some flow charts to show processes and was quite a small document compared to the work done. I queried this at the time, and was told that this was standard SAP documentation – when I pushed a bit harder, the guy concerned got really snotty with me. His view was that this was the same format provided to everyone else implementing SAP, and those people had no issue with it, so I should just accept it and stop complaining.

I spent quite a bit of time trying to see if I could find a way to uncover what config chnges had been done, but I must confess that with all the other work going on at the time, I simply could not keep track of what was happening. It also became pretty difficult to maintain details of who was working on what, when, why and what they did. We had an issues list, and for the most part, this is now our primary resource for determining what work was carried out.

As it happens, when we applied a number of support packages, we found several issues. After investigation, it was determined that some of these (not all of them) were down to config changes having been made, and this caused a number of delays until we could complete various work to deal with the situation. It definitely took much longer to do the updates than it should have, and the delays impacted other work.

However, about a year after we went live, we had another consultant on site for a few weeks. When he left, he handed over a really detailed document that we still have – it gave information on what he had done, what changes, what code even. The file was everything that we had previously asked for, and exactly what was needed. It ran to a couple of dozen pages, and was really helpful as we could then refer to it when there was a question about an issue a few weeks after he had gone.

As you can probably tell, I think that this is a very sensible and professional way to work. I raise the subject because there is a particular consultant that has been doing quite a lot of work on our systems, and a couple of weeks ago, we found out that he has now left the SI. The trouble is that he has documented nothing – and I mean absolutely zip. No-one at the SI can talk to the guy, and they have no idea of what he had done, or how far he has got with the work he was doing other than at a pretty basic level.

OK, we will survive – but it is not the best way of working. It’s just another example of bad practice, and when you are paying about $1500 a day, I think that you are entitled to expect a certain level of professionalism and I am not convinced that we’ve seen that from some of the people that we have had working for us on our project.
Having said all that, I would understand if anyone then turned the criticism back on us. The systems are ours, and it would not be unreasonable for someone outside of the company to suggest that it is our responsibility to maintain records of what work is done. As it happens, we do keep some records for various reasons and we can point to a number of audit trails that show we are attempting to maintain a level of control.

The problem is of course that in many ways, the SI and the consultants working for them were working in the way that they want to, rather than in a way that matched what we want or need. I suspect that for most of the consultants concerned, this is the same way that they have worked on all of their projects, and they know no different. Our project leader should have forced the issue (and he freely admits that) but he was taking advice from the SI on how the project should run. But we will probably never know all of the configuration that has been done.

Well it’s too late now – just got to keep going as we are.