Calculating the ideal date to roll out a major change to business IT systems is always tricky. Can you get away with switching directly from one approach to the other? And if you do, what's the right time to do this?
I've spent a couple of days this week on the Gold Coast at the Perspectives 2011 for enterprise resource planning (ERP) software developer Epicor. One of the themes I was interested in was the decision-making processes involved in planning major changes, which are inevitable with ERP systems. As well as being inevitable, they're also often fiddly: moving from one version to another is invariably much more complex than just testing and running the relevant upgrade code. That's especially the case when customisations have been made to the basic system.
That challenge is being faced by Victorian engineered products provider Tieman. Last year, it moved one division onto version 8.03 of Epicor's Vantage system. This year, it is planning a much more comprehensive shift, moving the entire company onto Epicor 9.05. That will mean major changes to the financials and planning systems for every single division of Tieman, which employs over 300 people. When's the best time to do that?
Chief financial officer Barry Greig argues against the conventional wisdom that the easiest approach is to finish out one financial year with the old system and begin the new one with a clean slate. Instead, he favours aiming for a very specific time frame. As he told me:
The best time to do it is at the start of your second quarter of your financial period. Get the first three months of the new period out of your way, because then you're finishing off all your old stuff and you're setting up the new year. The start of the second quarter still gives you enough time to get something embedded in and you've got the majority of the year left. That's the rule of thumb I've come across through experience and trial and error.
While that's the target date, the other theme which Greig emphasised was that rolling out an incomplete system purely to meet a deadline doesn't make sense. If the system requires further tweaking, a different date will be chosen once that becomes apparent:
You've got enough time in the year. OK, if it slips into the third quarter, you've still got enough time to get the system bedded in. Forget the first quarter, forget the last quarter: it's somewhere in between.
What timings have you found most effective when you've had to make changes to systems that might affect hundreds of users? Insights are, as always, welcome in the comments.
Evolve is a weekly column at Lifehacker looking at trends and technologies IT workers need to know about to stay employed and improve their careers. Angus Kidman travelled to the Gold Coast as a guest of Epicor.