Please login or join to subscribe to this thread
did this for several clients, moving them from legacy to ERP standard solutions (we used SAP) for finance, sales, logistics, HR and many more. Did not do acquisition and property specifically.
The SAP system comes with a recommended approach, which I would call hybrid. It is a step by step approach and should be adapted to the situation.
In my view, the beneficiaries of such a modernisation are company executives, not the individual users. Users often consider such a project as a thread, and it may be that some loose their roles and power. Hence I think a change management part must be included and a step by step approach is helpful to make progress as you tick off results.
And awesome 2nd tip, i.e. using a change mgmt system for the transition. Action - check if anyone is losing their job or role.
Thanks very much Thomas. I appreciate your input.
happy if you found that useful.
Regarding change management, one option I saw in practice with a SAP implementation that everybody (including management) was fired and invited to apply to one of the new jobs.
As a result, much fewer people were lost during the process as usual, as it was seen as a fair process.
Is not a matter of method, is a matter of architecture. I have experience in the field and just to comment the project I led time ago received one of the PMI´s awards, mainly because it was innovative at this time because it was "pioneer" in the use of some technologies and approaches. After the solution architecture was defined (solution is equal to "the thing" to be created plus "the way" to create it) we use a multi-method approach. And just to comment: do not fall in the mistake that some people do and understand that Agile is an approach and can be used with any type of life cycle (waterfall, iterative, etc). Our general approach was use Agile and keeping the life cycle which was more confortable for everything to make the job. For example, for people that work in AS/400 in RPG using waterfall life cycle they continue to do that but we add Agile based approach to leverage it. Just talking about technical issues we keep all the core active using SOA and Service oriented architecture to leverage it and integrate it with the new things to create.
In my experience, this is a systems engineering problem, disguised as a software problem. You are trying to migrate functionality from a federated set of systems to an integrated system. The classic systems engineering approach is predictive, but also iterative in essentially a layered approach of Plan Do Check Act.
When I've done this type of thing with engineering systems, there was too much focus on a bottoms-up approach to converting all the data and then assembling it in layers, and not enough focus on delivering functionality.
By that I mean we spent more than a year converting underlying data (e.g. spreadsheets are converted to a database) before we learned the database wasn't structured in a way that fit HOW we used the data. We would have been better off working out the problems on a much smaller scale focusing on specific functions, and working out the bugs first, than focusing on all the data conversion first, and then having to fix it for all functions.
This was a case where a predictive schedule was needed to manage a multi year project, but more agility was required to ensure we didn't generate masses of rework at each subsequent stage of conversion.
If you really have a choice in choosing a methodology (I would check with Primary Sponsor, HR, and Accounting), then I recommend hardware & system implementation in waterfall, while desiging, software development, testing, bug/fixing in Agile. Overall project management as waterfall, while product in Agile.
Please login or join to reply