Continuation of Confession from 20 NAV/BC Implementations. Part 2
From my last blog “20 Go Live” I confessed none of them were the same. I have experienced various Go Live weeks from a range of Small 10 user implementation in a beautiful countryside where I really enjoyed every evening eating dinner at the hotel with a glass of wine, Up to large implementations with hundreds of users in rural areas where every minute counted. Piles of non-processed papers grown rapidly every hour an experience for everyone involved that was stressful.
Similar applies to any NAV/BC system I have seen so far. Every time you see so many different things. Good or bad that’s the beauty of this work and the thing I enjoy the most. You see lot of different companies, environments, people and places. You learn, literally every day however you also learn what not to learn.
In my NAV/BC journey I wasn’t just working on the go lives and full implementation projects. I was doing one-off consultancies, one-off trainings, one-off onsite visits, sometimes bit of presale. Sometimes I have been introduced as the fire fighter to save the roof on fire (read as helping resolve mess in reservation entries). I also helped once to recover a system after ransomware from the excel spreadsheets. My experience is colourful from various phases of the ERP implementation lifecycle. The most complex process from my perspective is the go live itself because that’s where it goes only two sides: fail or success. Hence the confession!
In the project team for this stage of project, you need experienced people. It’s no longer cuddling, it’s live. It’s not for somebody to chill with coffee remotely, it’s hard consulting work onsite which especially after pandemic home-office patterns I see not many people really want to do.
What I have learned is that even if it doesn’t go as planned, the commitment, positiveness and goal attendance is the key attitude (regardless of if it means extra hours, little sleep, or complete change of plans). If we all cooperate, we can make it. If one part chain is falling off, we have a problem. We also need to understand that there is never thing as such as single person fault, it’s always team, who let it fail or succeed. So, we are back to key factor I talked about in first part of confession: The Teams. The continuity of the project teams and ability to develop trusted relationship between customer and partner, which can overcome any incoming obstacles makes it win or lose. Where people been changing in these teams regularly, resigned and left the team few weeks before go live or even on go live day (read as s*** their pants or not doing enough for team success before departure), for these projects it always took longer to get real benefits from the system (inevitably your go live is pushed back and budget blown over). Or these dreamed about benefits have never arrived (sometimes important things which compromise the end user benefit are pushed backed to future stages, which after implementation experience never going to happen). Was it anybody’s fault? No, team wasn’t strong enough. Or teams weren’t compiled strong enough, so the organisations are to blame, nobody in person.
Minimum viable product is what makes is so difficult. We can be talking about the solution for months or years and find innovative approaches even for non-critical processes, but let’s not forget somebody pays this activity. Get it live quick, cheap, that’s what everybody wants today.
Everything nowadays adds to the pressure. Stakeholders wants quick results, track progress daily, although to set deadlines expectations purely on Go Live Day and link bonuses with it never helps (e.g. we have to go live on day 1st of Jan as old system will be switched off; Really? Nearly any subscription can be extended). In my experience to set bonuses solely with Go Live Date is the most stupid thing ever, which can end up way worse than reversal to previous system (imagine links to mental health issues; RIP mate I wish could have done more). What should be regarded as the goals is not the dates, but outcomes and the organisational value adopted. If the users are not ready, or the solution is not ready by the date you were all aspiring for, somebody has miscalculated. In my experience most of the problems were caused by same things as I mentioned in previous blog post: greedy presales (imagine some of them that greedy they think nobody needs to approve their s*** even though they have 0 implementation experience) and useless project management (remote Prince 2 PM with zero implementation experience can’t be too much of help, can it? Person without business and implementation experience cannot successfully communicate with the project sponsor; everybody in this business should literally start on support)
Let’s come back now how to get through difficulties of go live tasks to succeed. Regardless of implementation size the logic of tasks which need to happen doesn’t differ too much.
I will describe typical todays scenario: New customer on d365 platform or NAV>BC Reimplementation with Inventory involved (forget old fashioned upgrades – it’s nonsense nowadays, you would be reinventing wheel as most of your legacy bespoke development is now MS out of the box or available on BC Extension marketplace; in cloud you pay per GB so why to bring XX years of history).
Task No 1: Import of opening Inventory balances - Stock take
You can’t sell or produce without having inventory in the system, right? This is the most complex part of the process as this not just the system task: The stocktake. Once you can master them, you are way closer to win this battle (guess where from the most problem of go live comes from - the data).
You can miscount so easily by scanning different barcode, different bin, we all know it right? It’s just not simple with so many variables that potentially go wrong. Some companies hire other companies to count for them. Personally, I do not see too much logic behind it. More indicates that something is wrong internally. You can get few handhelds yourself (few hundred pounds Android device) , some cool addon from Extension Market place and you can literally record transactions live. In few minutes.
As a part of Cut over planning, you will often hear from me: “You need to execute the stocktake on go live weekend”. Regardless of company size, I nearly always hear a negative response: “Do we really need to?”. To me that depends, if there is perpetual stock already in place, data in the system reliant, place is organised, then we can just take your opened item ledger entries from your NAV (or Bin Contents; or mix them both – that’s what varies depending on customers requirement and adds complexity; or import similar data from different system). If your place is the opposite, the data is a mess, company process doesn’t exist or is not in place, then my recommendation will be let’s invest day of manpower (and obviously the money; even if it means to stop a manufacturing plant for a day or two) to make it right at least once. Trust me, if you don’t do it, you might regret it one day that you haven’t done it when you could. Any ERP system doesn’t create the process. ERP system supports existing process or helps define new company process. Best practice is to leverage your process around system to take the most of advantages.
System wise, if you do Item Journal import (Including lot/serials; thanks to MS grounding change we don’t need to use Item Tracking for single Lot/Sn entry; big thank you), Warehouse Item Journal, or Physical Inventory Order, it does the same thing. Recently I have used Physical Inventory Orders and two different warehouse WMS addons and they both did a good job. One day I will post comparison of WMS products on the Extension Marketplace. Stocktake as first thing on go live on new handhelds? I don’t see any problem with that. It will be hard though and especially if you don’t have labelled stock or bins already.
Stock take is stressful for everybody involved, from staff counting stock to us completing. We need to reconcile both systems. If there are differences in counts, one or another system needs to have stock value adjusted as your task from audit perspective is to match the inventory old and new systems without differences (which sometimes can be impossible; one or another system needs to have stock provision posted through General Journals)
Key thing I always recommend customers on Go Live day 1 is to not account for posting sales shipments from new system in the morning of day 1. If you have some urgent shipments, pre-post in previous system on Friday before and prepare paperwork to allow smooth operation and ease the first day for everybody.
Task No 2: Open Documents (Sales Orders, Purchase Orders)
This is not necessarily mandatory, although you will very rarely hear: “Yes, we have no problem with manual creation of all outstanding documents”. Fortunately, nowadays we have RapidStart, which with right amount of experience, smoothen the whole process and you can have the documents from old system in new one quite easily. Note to say, when we talk about large data volume (10k+ records), it’s unbelievably slow. Literally, you must do it weekends. One thing Microsoft could look at.
There are rules you need to follow e.g. everything shipped must be invoiced in the old system, you bring only Outstanding Quantity from old to new one (e.g. you had 10 on sales order line, 5 shipped, your new sales order must have only 5 to not double orders). In general, it is manageable, I have done in past all type of Sales/Purchase documents, and even Production Orders (Did you know you can do Refresh Production Order as a bulk out of the box?).
Sometimes although it might not be that simple especially where you completely change system structures on large implementations. I did twice something called “Transitioning period”, where the systems were too big to just switch on and off. Both companies had a lead time in e.g 4 weeks for their products, so why would you create new orders in old system and in month and migrate them to new structures in four-week time? We smartly split activities which obviously then multiply difficulty of system reconciliation. Possible blog for a future post.
Task 3: What customer owes us -Account Receivables
If you have NAV as previous system, it is quite straightforward task. You populate the General Journal and post. If you don’t have NAV, you might need to work with signs, map Document Type but nothing major. In general, you can be consultant only if you friend with Excel.
Task 4: What we owe suppliers – Account Payables
This is same thing as Receivables. The General Journal posted against the Vendor.
Task 5: Fixed Assets Opening Balances
Fixed Asset Journal create opening balances without any impact on Chart of Accounts figures.
Task 6: Opening balances entries reversal & Trial Balance Import
To avoid duplicated entries, any impact on Chart of Accounts from previous steps needs to be reversed by single journal entry per G/L account to have zero Trial Balance. In the end we will bring the Trial Balance from the old system. This typically happens in the end of first go live week.
There are many ways how to make transition to new system happen. Use of suspense accounts instead etc. You can go live in the middle of the month, but that’s something I would not recommend. In my practise, best scenario is you start in the beginning of the month or period, your month end still runs in the old system, once closed, all entries from opening balances reversed and trial balance closing position from old system is backposted to end of last period 1:1 as opening position of the new system.
Conclusions
I don’t think there are many conclusions. Even you had five successful go lives in a row, next one can be disaster. I’m always trying to learn from mistakes and share these things for other people to not repeat the once I did. Hope you enjoyed the reading, please like/share to bring more success to everybody.
