It is with great interest that I was reading some passages from New-SAP-Blue-Book by Michael Doane, when I came across the following passages regarding SAP recommended practices, and principles around implementation:
When clients hire an SAP systems integrator, they are hiring the firm and their people. The core capabilities of the firm will remain over time – things like the methodologies, tools, partner networks, etc. The people, however, will change, as promotions, job changes, and retirements inevitably happen. Therefore, clients should place a strong emphasis on the systems integrators’ methodologies and tools during the selection process.
As someone who swims in the agile space, I found this quite fascinating that someone was has recommending processes over people. I then went on to read another interesting passage regarding the pitfalls of iterative development on SAP projects.
You do not want your team engaged in an iterative trial and error process in which you find yourselves moving between design and configuration across all modules until you are satisfied. Such a process will drain your budget and strain your nervous system. You should seek, where possible, to adopt best practices, especially those that are pre-configured.
What this means is that your organization will change to fit the system. This is, of course, not intuitive. Most firms believe that the software should be bent to fit their chosen processes. In some cases, this is a necessity but in many other cases it is simply organizational vanity.
Now, I have never had the pleasure of working on an SAP project, so all of my opinion is stereo-typical, third party, and not informed by experience or practical knowledge. But it did get me wondering what it would be like to work on this kind of project where the process was all important, and the business bent to the software (not the other way around).
Would there be a culture clash if you stuck a bunch of agilista’s onto an SAP project?
What would SAP experts think of agile’s free wheeling iterative nature?
Could the two co-exist on the same project and swim in the same swim lanes without bumping into each other?
I suspect the spirit of agile would indeed work on SAP projects. But the more I read the book, the more I became interested in understanding what, if any differences in attitudes there would be, between an agile and SAP team.
If you have any experience or comments on agile and SAP projects, please leave a comment.
I would love to hear more of your experiences.