It is with great interest that I was reading some passages from New-SAP-Blue-Book
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.
Tags: agile, culture, michael doane, process over people, SAP
Rasmusson Software Consulting 
March 13, 2009 at 4:58 pm |
First of all, I’m not an SAP expert but I came into a SAP implementation with a tiny little bit of custom Agile development background.
The first thing I learnt is there is no point spending ridiculous of money on hiring SAP SIs if you are not willing to bend your business processes to suit the pre-defined SAP business processes.
You heard right. I was absolutely flabberghasted at first. What do you mean? Isn’t the whole point of PAYING all this money is to get a system that suits your business?
To implement a system such as SAP
March 13, 2009 at 5:22 pm |
To implement a system such as SAP, you don’t just pay for the actual system. You pay for what is supposedly ‘best business practice’ that the system guides you. Supposedly, you do things the SAP way, your business will improve.
That is, of course, debatable (although SAP consultants won’t tell you that). However, if you have already decided to implement SAP (possibly because ‘everyone else is doing it’) then you have to be prepared to change your business to suit the system. Customising SAP solution unnecessarily is very very costly and will strain your project timing and budget.
Which brings us back to the Agile nature of implementation – I suspect what the author is saying is that by engaging in ‘trial and error process’ in SAP is unnecessarily costly because if you implement the system the way it should be implemented, there is no need for trial and error as this ‘best practice’ has already been tried and tested over the past years.
Of course, in the real world this is not the case. You will always need customisation. You will always need to do things your way (to whatever negotiable extent) and this still means Agile methodology still has its place. It’s just that the SIs want to steer you away from doing things the way they don’t want to do (let’s face it, in a large scale project, customisation is like a budget blackhole that’s hard on both client and SIs).
So your question is would Agile improve SAP implementation? I say yes and no. Customisation – absolutely. But configuration? Probably not so much. The challenge now is to get the best fit between the two because they will always go hand in hand and I think it’s possible but you’ll have to give them SAP SIs a bit of time to get their heads around.
March 13, 2009 at 6:23 pm |
Great comments. Thank you kat for sharing.
I agree. There probably is a space for agile to play on SAP projects. Like everything else, it will have to be tailored and made to fit.
Your experience(s) seem to jive with what I was thinking.
I am sure this will become more apparent as people get more experience working with the two side-by-side.
Thanks again for sharing.
June 30, 2009 at 5:19 am |
I found your blog on google and read a few of your other posts. I really interested and I just added you to my Google News Reader. Keep up the good work. Look forward to reading more from you in the future.Cheer!
August 17, 2009 at 7:53 pm |
ERP projects are often bad candidates for agile development because you can’t guarantee ongoing participation from your customers. If the customers are the employee in the business who are getting value from the software, you have to remember, they probably can’t get away from their “day job” for the length of the project. The ASAP methodology brings people together for workshops to create a global design over a couple of months. Then at least some of the customers can go back to working their regular job while the configuration happens. Without ongoing customer participation, you don’t have agile.
IMHO, Agile recognizes the fact that software development is a creative endeavor and provides techniques to allow the creativity to flow. SAP configuration is a procedural endeavor, and it really doesn’t have much of a creative element. So, for most of the activities of an SAP implementation, agile is probably not a good fit.
Agile can be used for business intelligence activities on SAP projects. And, as Kat says, on customization to SAP.
June 22, 2010 at 6:19 pm |
From my last few years of experience in AGILE and over 10 yrs of experience in SAP, I would say ERP applications like SAP, Oracle Apps, JDE are the best place to apply agile methodology. It will minimize the implementation time by at least 45%. Since ERP implementation has 4 different levels of steak holders like Business Supper User, Functional Analyst, Technical Analyst and Developers, it consumes lot of time to maintain communication and iteration of any discussion. This can be minimized in a big percentage by applying agile process.
Management likes to go for any ERP solution, the reason is not everybody implementing the solution, rather it’s more to maintain the Standards and Best Practice in the market and maintain race with the competitors. In a nut-shell if vendor and supplier both has SAP then it’s much easy and faster to do EDI communication between 2 entities and cost savings too. And we also have to keep in mind that it too 30-35 yrs to develop those solutions, so it’s a big challenge to implement the same quality customize software within a short project.
July 9, 2010 at 1:32 pm |
I would say that the project management method should be defined first, and Agile being more a development method does more apply on coding.
From a project management method, standard “Linear” method is suitable for classical ERP deployment when business know which business process they need. More adaptative project mgt method are more suitable for SAP projects when Business has no clear idea of what should the Business process be (CRM, SRM, …).
I would be inetersted in using Agile within an Adaptative project on SAP configuration (not coding). Any experience of that?
July 10, 2010 at 1:57 pm |
Hi Jean-Pierre,
No – I haven’t had a chance to apply or do agile on an SAP project before so I can’t comment specifically to what that would be like.
I just found it interesting how the culture of SAP was one of process over people. Meaning get the process right, and you should be able to swap out the people.
I have yet to be on a “linear” software project (all of mine have been highly non-linear). And because SAP projects seem to experience the same cost over runs and delays as other software projects, my gut would tell me they can be highly non-linear too.
Would be interesting to take an agile approach and apply it to an SAP implementation. Until I try however, I can only speculate.
Thanks for your thoughts – JR
July 11, 2010 at 5:27 pm |
Hi,
I found your blogg on google and i really enjoyed it. I would like to know what is the optimal maximum percentage of customization for an SAP ERP solution to be considered a “good fit” with a prospect requirements?
September 3, 2010 at 10:36 am |
Hallo JR,
I am an SAP consultant in Germany. Currently, I try to learn how agile development works and where the benefits over striclty linear processes are. Some of my thoughts:
a) Regarding SAP’s idea of process over people: Well, it’s somehow true. Imagine those big, ling-running implementation projects with well over 3 years. It’s very likely that you’ll have to replace part of your project team along the way. But this does not exclude agile, but to the contrary: I learned that the agile way with all its self-organizing teams will lead to wider spread knowledge of the overall project. So therefore, this just sounds like a good idea to be more agile in SAP projects.
b) I think in many cases, the customer would also benefit from more agility because most of the times, he does not know what he will receive after a 3years project. And most likely, some of the initial requirements don’t exist anymore. And new ones occured and have to be considered change requests right afterwards, which is quite costly.
c) With new implementations or big upgrades, however, you have some problems being agile: most of the times, the system needs to be “complete” in the meaning that you can hardly introduce a large-scale CRM system in an incremental way since they’re mostly in the middle of several systems, highly integrated. You need order processing, business partner handling, account management, billing, product data integration in order to run this system. The question therefore is, if you gain something if you develop agile but still deliver linear just once after 3 years when everything is done. Or the risk might be that you spend too much time testing all the same stuff over and over again.
d) To answer moe’s question shortly: The optimal maximum percentage of customization should not exceed 100%. No, to be true: there’s no such thing as an answer to this question. (At least not that I know of, please correct me if I’m wrong). This really depends on
– your specific environment
– your processes
– the size of your company
– what kind of business you do
To make an example: you might want to customize something different in an SAP for production planning at a company like Airbus than what’s needed when introducing SAP HR for a small-size retailer.
Regards,
Martin
March 14, 2011 at 2:26 pm |
It was interesting to read various experiences. I have been trying to implement agile in the SAP CE environment and stumbled across similar problems. Customisation can be expansive and senior management need to understand this. A solid business case and cost/benefit analysis is a must before committing to agile.
March 15, 2011 at 12:47 pm |
SAP R/3 is suited to the waterfall approach because the users don’t really have much say in how the software works. It works the way it works. What I would suggest is that a business involves more users in the selection process – which may result in the selection of a different products or vendor.
On the positive side, and in the newer SAP products (the so called “edge” products), configuration is being replaced by a collection of purpose specific “drag and drop” development tools. The traditional (and painfully slow) practice of selecting from large lists of pre-defined options is being replaced by building, activating, and assigning your own objects. In other words it is faster to build your own than to find a standard object or function that might or might not suit your needs. The balance of power has shifted from standard functionality to the development tools that empower functional consultants/analysts.
This trend lends itself to Agile – because what the users will eventually receive will be unique – not as unique as a ground up custom build – but much more unique than what is delivered by R/3. The build effort is also faster – so the iterations can happen more quickly.
Note that an Agile approach relies upon having on-shore developers – irrespective of software. In other words this new generation of tools from SAP leverages on-shore developers many times over. And note that the developers using these tools are the functional consultants/analysts – the same people who design the end result.
Finallly, these same techniques will find there way into parts of the so called “core” product – or alternatively – parts of the core product will be extricated from the core and incorporated into edge product lines.
March 22, 2011 at 6:48 pm |
Great insights and comment Matthew. Thank you for sharing.
I am not that close to SAP dev, but it’s good to hear things are getting more configurable.
Totally agree with your comment about SAP R/3 being waterfall driven as users don’t have much (any) say in how things work.
And yes, on-shore (co-location) always makes things easier.
Cheers
June 23, 2012 at 11:40 pm |
We have been able to develop a vary scalabable approach to implementing SAP project in an agile way.
I detail some of our experience on our blog:
http://www.bestxperts.com/blog/posts/running-sap-projects-the-path-from-waterfall-to-agile
Anton