Five simple words, spoken twenty years ago, which have stuck with me ever since.
I was the fresh-faced new recruit, very recently brought into a rather large, hugely successful, and rapidly-growing, contracting business, charged with leading a major business systems change project alongside Eque2 as the already-selected partner. We had just got to the end of the first day’s “Kick-Off Meeting” and my head felt like it was going to explode with all the things to think about, prepare, and research. I’d never been involved in a project as big as this before, and the Group Board and investors were expecting nothing other than an on-time, on-budget, major issue-free “go-live”. (Cue audible gulps).
As the meeting wrapped up, Nicholas leaned over to me, hand cupped over his mouth, and gently uttered the immortal words: “It’s all about the data …”. Then he leant away again, looked at me, and smiled and nodded reassuringly as if his job was done.
And indeed, it was.
The data perfection tightrope
All major business systems change projects will impact the way data is processed, analysed, reported, and stored. But all the blood, sweat, and tears invested in process mapping, system design, user acceptance testing, user training, and reporting strategies will be worthless if your existing data doesn’t make its way completely and 100% accurately from your old systems to your new systems. If the migration of data isn’t perfect, then expect chaos in lieu of your post-“go-live” party and a celebratory pat on the back.
In the construction industry, data migration is made all the more complex because of the need to transfer cumulative data, like “to date” job costs and revenues, and subcontractor and client certified values and retentions. It’s not just the relatively simple accounting entries like the profit and loss account, the balance sheet, and the list of unpaid invoices that need to be transferred over. In addition, you are likely to have redesigned your core coding structures to fully exploit the powerful functionality embedded within your new, modern systems such as those offered by Eque2. That means that you may be faced with mapping data from the old codes to the new codes in preparing your data for migration. That mapping might be a “one-to-many” or a “many-to-one” relationship, as well as more straightforward “one-to-one” translations. And you might need to add in new analysis (for example, codes for Departments, Divisions, Regions, etc) which didn’t even exist in your old systems.
So, is this apparent obsession with data migration worth the hassle? Absolutely! Imagine your organisation investing in new, core-business ERP software only to find that reporting and analysis outputs are compromised or unreliable on day 1 because some data was omitted from the migration, some wasn’t loaded with sufficient analysis, some had fields missing which is impacting on successful processing, and some was just plain wrong. The knock-on impact could be immense: for example, you could find yourselves experiencing problems reporting to shareholders and investors, making timely and accurate payments to suppliers and subcontractors, or raising accurate sales invoices. Confidence in the new system could vanish overnight amongst the user base and management, and the reputation of the organisation could be severely dented. Worst case, you might have no option other than to revert to using your old systems, and revisit the “go-live” at a later date when data quality issues have been resolved.
Practise makes perfect
Avoiding such a cataclysmic outcome is simple: Rehearse, rehearse, rehearse.
Practise a full data migration exercise at least once. Find out which bits are easy and which are really tricky. Time how long it takes so you know that when you do it “for real” how long your systems will be down for. Determine how you will extract data from your existing systems. Understand the format that data needs to be provided in so it will import seamlessly into your new systems without hitch. How will you gather data that is currently spreadsheet-based or held in disparate systems? Who will prepare the data? Do they have sufficient knowledge and understanding of the data? How will you check / reconcile it, firstly, when you’ve got the data out of your old systems, and secondly, when it’s arrived in your new systems? What evidence do you need to obtain for audit purposes? Discover the things which went wrong and learn from them, so everything is 100% right when it really matters.
Think also about how much data you’re going to migrate. You very rarely need to bring over every historical transaction, so why make a complex task even harder unnecessarily? But you also must consider how you will continue to fulfil tax and other legislative requirements, such as having data available for auditors, and for HMRC or CITB inspection or query. Will your old systems continue to be accessible for enquiries? The volume of data will also be affected by when you intend to “go-live”: for example, a system transfer as at the end of a financial year may eradicate the need to migrate P&L data, and a transition in April might mean in-tax year “to date” figures don’t need to be migrated when implementing new payroll software. My rationale has always been to migrate as little as possible whilst ensuring all the necessary data analysis and reporting can be done from the new systems. What you do migrate, migrate it with perfection. Work alongside your software consultants and your colleagues to determine what is “enough”.
Consider how you will “stop the music” in all the places where your existing data resides to ensure it’s aligned, especially if it is coming from different sources. For example, you wouldn’t migrate your unpaid supplier invoices, continue processing in your old system, and then migrate the general ledger control account balances because the two wouldn’t agree.
Data is ever-present
Finally, bear in mind that data migration will be the continuous thread that runs alongside every step of your implementation project, as it’ll be shaped by your early decisions on system structures, through the ability to effectively train users on data they recognise, to a successful, stress-free “go-live”.
So, was my major business systems change project a success? Yes, it was. And Nicholas’s advice was instrumental part in that success. Wise words indeed.
This is the sixth in a series of blogs about the systems change journey by Steven King, Eque2’s Head of Change Management. Steven is a Big Four-qualified Chartered Accountant with over 20 years’ experience in senior finance roles in construction businesses and groups. He has led major business systems projects within the industry several times, including at 4 of Eque2’s existing customers. Steven has the benefit of real-world implementation experience, super-user hands-on systems knowledge, and a record of success in delivering big change projects involving our solutions on-time and on-budget.
Read Now: Recognising the need for systems change within a construction business
Read Now: Making the systems change decision
Read Now: Fail to plan, plan to fail
Read Now: Monitoring the construction systems change journey
Next time: Testing, Testing, 123…
Eque2 provides modern solutions allowing all types and sizes of construction, contracting, housebuilding and maintenance businesses to manage the full lifecycle of a project from anywhere, on any device. For more information, visit www.eque2.co.uk or call us on 01628 702 702.