How to Talk to an SAP Consultant (If You Must)
I discovered via last week’s post SAP Disrupts Everything that I am not the only one in the I/T Architect blogsphere who is craving information on the integration of SAP with the rest of the information technology world. It was by far my most popular post ever. (Thanks to everyone who visited and special thanks to those of you with widely read blogs that directed others to this post.)
I am just becoming aware that the package-world people and SAP people in particular don’t communicate very well with us custom development types.
A prime example is the use of the word “requirements”. You’d think this was an almost universally understood word in software development. Well... maybe not. When I think of requirements, I think of things like the answer to “What do you want your system to do?” or maybe a collection of use cases. Oh.. and don’t forget non-functional requirements like “if the database crashes we need to be able to recover in 4 hours or less”.
I am still trying to figure this out but it seems that to someone who has grown up in the SAP space, the word requirements takes on a very precise and specialized meaning. This is not a term used in the same sentence with open-ended, green field questions. SAP has something called a “business process hierarchy”. At the top level, this might include something like purchasing. At the next level down purchasing is decomposed into purchase requisition, purchase order, etc. At the next level down, it would be further decomposed into things like release of purchase orders, transmission of purchase orders, scheduling agreement delivery schedule, transmission of scheduling agreement, etc. This decomposition continues down to an excruciating level of detail, perhaps 6 levels down. A “requirement” then is which of these many low level business process are chosen out of the SAP-approved business process hierarchy which are identified as “in scope” for the SAP implementation in question.
In the newer versions of SAP, all of these many different business processes are loaded into a tool called Solution Manager which visually provides a hiearchial way to browse these business processes. This tool also provides a way to load things like the user roles and client’s organizational hierarchy. Maybe requirements becomes a slightly bigger term encompassing all the “in scope” items in Solution Manager. Not 100% on that so I’m open to comments or correction.
I’ll try to point out more examples of SAP-specific language and nuance as I bump my head against them.
No comments:
Post a Comment