Ok.. so I've decided to take the plunge and try to make myself blog every once in while here. I'm not really sure how many people will really care what I have to say but I thought I'd give it a go. After over 15 years with working with SAP software I feel that I have at least some idea of what is going on. Of course my wife reminds me, (often), that only applies to the SAP world.
So what do I intend to write about here? I guess I'll find out as I do this. But I think I'd like to discuss some of the softer sides of consulting and especially in the QM world as that is pretty much my entire focus. Now I do think I know my way around some other areas of SAP fairly well, but QM has pretty much been my niche. Not that some technical issues might not be discussed but I don't want to concentrate on that. That's what the SDN forums and Wiki are really for.
I like to think I'm fairly good at what I do. I know I'm not perfect. I've screwed up a few things here and there in projects along the way. I probably have a few companies and/or employees complaining about the system I left behind. But that's part of what I think this blog should be about. Putting in a system or new functionality shouldn't be just be about flipping config switches and creating some user exits. Especially with regard to Quality Management.
It's not just about making the client happy. Sometimes you do have to make the client unhappy. SAP has tried to put in place certain best practices into the system. Now everyone can argue over the details of exactly what is a best practice but we all know there are certain things you should and shouldn't be doing. I find many of the questions posted in the QM forum relate to how to not do certain things. How to avoid certain things.
Clients often want the system designed to work a certain way. Except for when that one particular customer calls up. Or that one batch is JUST a tad off at 3:00 AM and the truck is waiting to load and they just KNOW the customer won't really care. That's not the way it works folks if you want to ensure top quality.
So I hope those can be some of the issues I can blog about and we'll see where it goes from here. Because quality consulting for the QM module shouldn't just be about knowing what switches to flip.
FF
