Dsg best practice guide for net suite implementation success
Thesis defense presentation jve 2013.01.07
1. A method for Agile ERP
implementations
as a new Service for Zest
January 17, 2013 Master Thesis Jean Vercruysse
2. How it started
2010 : Zest’s competitive adantage : know-how in the
“power market”, particularly
Smart metering (cf. Smart grids)
lever for geographical growth :
January 17, 2013 Master Thesis Jean Vercruysse
3. Belgian power market
2010 : monopolistic (Electrabel) - even till
2012…
no innovating environment
no hard need for Zest’s know-how &
services
Shift from geographical growth
strategy to
Assortment growth strategy
January 17, 2013 Master Thesis Jean Vercruysse
4. Possible new services
• New market segment : Healthcare
• New activities :
– Zest Academy (training activities)
– Business-IT alignment improvement activities
January 17, 2013 Master Thesis Jean Vercruysse
5. Considered new services
• New market segment : Healthcare
• New activities :
– Academy (Training)
– Improving Business-IT alignment
Zest’s BPM-core skills Own experience with BPM
and ERP-projects (also @
(@ intersection between
intersection between
Business & IT) Business & IT)
January 17, 2013 Master Thesis Jean Vercruysse
6. Scope definition
Final focus : Agile ERP-implementations – why ?
• Too many ERP projects
are unsuccessful
www.freebalance.com/blog/?p=3372
• Agile methods allow
Better results in
Software Development
January 17, 2013 Master Thesis Jean Vercruysse
7. Agile projects – what
January 17, 2013 Master Thesis Jean Vercruysse
8. Contradictio in terminis
ERP’s integrational aspect ~ nervous system (of an
organisation)
Agile ERP = cutting it into pieces (sprints)
Wise to cut an integrative system ?
Do not “cut”, but distinguish entire processes and
process variants / cases as “sprints”
Ex.: Purchasing facilities <> purchasing raw
materials
January 17, 2013 Master Thesis Jean Vercruysse
9. Own vision on Agility
• Agility a “must” for any
– Industry,
– Business,
– Process ???
• However : a static process today may need to become Agile (and
vice versa) scenario’s / paths
• Maturity (business & IT-departments) must be acceptable
hereto also recommendations
January 17, 2013 Master Thesis Jean Vercruysse
10. ERP Agility Day
• Objectives:
– Sharing & communicating our vision
– Creation of awareness and
spotting potential candidates for pilots
• Results :
– Positive with regards to speakers : shared & supported vision
– Negative regarding participants : only 2 subscriptions
Cancellation of the event
January 17, 2013 Master Thesis Jean Vercruysse
11. Focus on methodology
• Change of approach :
Developing the methodology together with a pilot organisation
Developing the methodology to find a pilot organisation
• Agile methodology specific for ERP-projects based on DSDM
• Including
– Phases & steps
For more details :
– Techniques •Thesis document
– Deliverables • Methodology description
– Use of Process Mining document
January 17, 2013 Master Thesis Jean Vercruysse
12. Not alone…
After the “structure definition” of our method discovery:
SAP also busy with its own “Agile” method : ASAP 7.2
January 17, 2013 Master Thesis Jean Vercruysse
13. Future steps
1. Find a pilot organisation
– To assess, practice and further improve the defined
methodology
1. Monitor the pilot project very closely
– Report every
• project deliverable,
• important event
• meeting,
For evaluation purposes
1. Market the new service
– As a unique service proposition
– Stressing the value : less risk for unsuccessful ERP-project
January 17, 2013 Master Thesis Jean Vercruysse
14. Important tip(s)
Don’t consider Agile as a religion ; be pragmatic :
– Not black or white
– Not necessarily
the train OR the bike :
smartly combining them
allows you to get anywhere !
Forrester’s
“Water-Scrum-Fall”
Agility is – first and foremost –
thinking & acting the agile way
January 17, 2013 Master Thesis Jean Vercruysse
The subject was finally Agile ERP implementation, but as you will notice, the thesis project itself required also some Agility from us
In 2010, I had contact with Zest that was looking to develop its activities in Belgium From a strategy point of view, this perfectly made sense because Zest’s experience & knowledge in smart metering was very valuable for the Belgian market - and French market as well By the way: still today, Holland is one of the most efficient countries with regards to power distribution ; among others thanks to their lead in smart metering and smart grids Zest even had a framework agreement with GDF-Suez for consultancy services However…
The Belgian power market was very monopolistic ; even until 2012 it was strongly dominated by Electrabel No innovating environment Very tough to sell innovating services : Mr. Peter Gijbels, already active for ½ to 1 year, at that moment was asked to stop Hence, there was no more further need to work at a business project for Zest in Belgium The French power market was assumed to be even more monopolistic (with an even higher dominance by EDF) So, Zest had to review its growth strategy : Zest preferred to grow by enlarging its domestic market instead, and hence, considering an extention of its “assortment”
Some - rather vague - ideas about assortment extension existed at Zest : Healthcare : made sense, given growing needs for cost savings, and the “Electronic Patient File” standard coming up (at that time) Zest Academy (to share Zest’s experience in its core business : project management, BPM,…) Consultancy to customer intending to improve their Business-IT-alignment ; still an important and challenging topic for many organisations
Given the core competences of Zest and my personal experience and knowledge of the challenges with regards to “Business-IT alignment” in many organisations, the choice was quite obvious
Business-IT-alignment was still a large and vague subject. Although the scope definition lasted for a quite long time, we actually agreed on the final subject : Agile ERP-implementations, mainly SAP-implementations. Our belief rested on following facts: Our experiences with ERP-projects confirmed the too high rate of unsuccessful ERP-projects The knowledge about the success of Agile methods in software development A 3rd reason is also because Agile requires a much higher level of involvement by the business ; and this obviously was in line with Business-IT alignment Even tough we were aware of the fact that an ERP-implementation project is not very comparable to a software development project (ERP = “COTS” ERP-implementation = mainly the deployment of an already “packaged” software), we were – and of course still are – very convinced that applying Agile methods would help increase success rates of ERP-projects.
For those who are not that familiar with Agile software development, this slide simplistically illustrates the basic difference between Agile and traditional project management with regards to software development : in the more traditional approach (called waterfall) - from the drawing you may understand why it is called this way -, each project step has to be completed before starting the next phase. Notice that this entire cycle may easily last for 1 to many years for ERP projects ! Hence, by the time to “go live” (i.e. to put the system into production), the initial scope may be considerably outdated ! Especially in fastly changing business environments, which we find more and more these days. According to Agile , you should cut the total scope into iterations (called “sprints”). Each sprint is an smaller, but entire, cycle on its own. Important is that each smaller cycle ends up with a real product delivery ! And thanks to these short cycles, the business keeps much better involved in the project (not only in the discovery and testing activities). This obviously improve the Business-IT alignment !
Someone would doubt about the feasibility of applying Agile project management on ERP-implementation projects. Indeed, given the integrational aspect of ERP-software (often considered as the “nervous system” of an organisation), you may wonder whether it is wise to cut such a system “into pieces”. Therefore, we did not consider cutting the system into pieces, but rather to distinguish entire processes, and to consider either a business process, or even its process variants (or “cases”) as sprints. Examples of different process variants are the purchase of facilities (like office equipment) versus purchase of raw materials: though both are purchase processes, those may “flow” very differently through one and the same organisation. This way, we do not “cut” in the business processes, and the deliverable of a sprint is an implemented business process (or process variant) from A to Z. This is innovating, even if you would consider it with the traditional (waterfall) approach. Indeed, ERP-implementators today still think and act too often in terms of software modules, rather than in terms of business processes.
We also made some own reflections on Agility : like for ex. why and when should an organization or a business process be Agile Our vision is quite detailed in the Thesis document. Just let me illustrate 1 aspect with following analogy: you don’t take the train for small distances and specifically when you have to go to specific narrow places (like narrow streets in a village of Southern Europe ; on the other hand, you don’t take the bike for travelling from Amsterdam to Paris. the same applies for business processes : more standard processes like Accounting are very standard ; you do not even wish to make them Agile, because it would be conflicting with SOX-standards (to prevent fraud). On the other hand, Supply-Chain processes may need to be very agile to provide high service levels to customers. Moreover, a static process may need to become Agile OR an Agile process may evolve to a best practice (say a standard process) later on. Therefore, we conceived scenario’s for such evolutive changes. Also, the maturity of the organisation - or parts of it – may be quite different ; for this reason, we have foreseen some recommendations, particularly when this is the case between business & IT-departments
To test our vision and its potential, we took contact with professionals knowing about Agile methods and Business-IT alignment challenges. Remarkebly, all those people were willing to act as a speaker on the “ERP Agility Day” we planned in (the fall of) 2011. This was the positive result… Less positive is the lack of interest and subscribers for the event. We finally had to cancel the event to save considerable costs for only 2 persons who subscribed.
As one of the objectives of the Seminar was to find a pilot organisation, and given the fact that the seminar did not take place, we had to change our approach : instead of developing the methodology together with a pilot organisation, we developed it ourself, aiming to test it in an organisation willing to try it out, later on. Based on DSDM and on SAP’s “ASAP” method, I worked out an hybrid methodology, describing the phases & steps, also the techniques to be used and the aimed deliverables as well. We also incorporated the use of process mining, which would enable a much faster discovery of “as-is” business processes within the organisation (and the possible process variants used in reality as well). Process Mining would thus facilitate an even shorter implementation lead time.
A few months after we had defined the principle and structure of our (hybrid) methodology, we discovered that we were not alone with the idea of Agile ERP : SAP was also busy with its own Agile method, being ASAP 7.2 We noticed, however, that only one step – the “realization” – is iterative in their methodology ; hence, we could conclude that we went further in our Agile approach, as we had foreseen more iterative phases. Moreover , I seriously doubt whether SAP would consider processes (or process variants) as sprints, or if they would rather stick to be modular concept (based on SAP modules) as most SAP implementations occurred until today. But at least, this fact confirmed that our idea of applying Agile to ERP-implementation projects was not “that crazy”…
The Zest own methodology is well described (phases, techiques, deliverables). As next steps, I would recommend to try it out within an organisation willing to serve as “pilot”. This would allow to further improve it During such a pilot, it would be advisable to closely monitor and report progress and findings, so to evaluate the methodology and to suggest improvements. And once the methodology has been “proven”, the next step would then be to market this new Zest service. But this may be a next thesis subject…
To end with, I would like to give an important tip : do not apply Agile as something “to take or to leave it”. Back to the analogy with transport (train and bike) : it is not EITHER the train OR the bike ; you could use them both combined and thereby may get everywhere you want : yet very far AND in the smallest streets of a city To this comparison, by the way, Forrester recently found out the term “Water-Scrum-Fall”. Stressing the aim to smoothly evolve from the traditional Waterfall to a more Agile method (Scrum being one of the most popular Agile methods). Not only the method used should be Agile, but also the way of thinking. Just like you must not apply Lean management “obsessively”, you should not apply Agile blindly. It is not only a method or “recipy”, but also a philosophy. And like you do not obtain a fully Lean organisation in a few days, Agile may also be an evolutionary change to strive.
