It's just an Upgrade, should be simple right?
Craig Watts
Believes Support is more exciting, dynamic and much more interesting than Implementation. But doesn't understand why others disagree.
I often get called a cynic, although I prefer to think of it as being pragmatic. Is that not the role of a Solution Architect? We design, structure and advise on implementations and upgrades, it would be remiss of us if we did not mention the possible pitfalls. The additional considerations, have you considered A, saw N tripped up by B once, might want to watch out for that one. If assessing and highlighting project risks makes you a cynic then I guess I have to put my hand and admit that I am, preferably not in a negative way. Although after the best part of 20 years in the IT Industry you tend to see a lot, good and bad, preventable and surprising, as I've always told my teams. 'Every day is a school day'
Decision made, we're going to upgrade. It's exciting and cannot wait to be able to use all the new features and remove the technical burden. That's going to be someone else's problem now. If your current ERP solution is all encompassing, in that all functional activities are performed within the one solution, it should be a pretty easy ride. Good luck, truly I mean that, there are many benefits to going with a solution like D365 F&O and I hope you realise as many of them as possible.
It's such a pity these pieces don't contain a pause function. It's at this point I would have invoked Harold Pinter and inserted a Pinter Pause. For any of you who have been following my recent articles the above seems to fly directly in the face of what I've been suggesting. While that is not necessarily true, the ultimate goal of these pieces is to assist you in entering the process with eyes wide open. So let's open some more eyes.
I've been racking my brain to think of ERP implementations I've worked on where all functional activities are performed solely in the ERP. Apart from a couple of small implementations many years ago it's difficult to think of any. In fact the larger the customer the chances are the more complex the ERP environment actually is. Everything from separate Warehousing solutions, maybe a Freight tool, Budgeting, even on occasion integrated CAD capabilities. Are these tools also cloud ready or do we retain a Hybrid model? If they are cloud ready, do we upgrade the base ERP and peripherals at the same time or do we stagger them, what is the impact of either approach?
Looking at the Hybrid model for a moment. Your internet connection just increased it's level of importance. Up until now it's primary use is likely to have been based around Office365, a bit of OneDrive and of course general internet activity. Now that connection is about to start coping with inbound and outbound transactional data as well as being the primary connection point for the ERP. You could question the latter given the recent enforced move towards working from home, which is true but it also comes with it's own set of interesting complexities, one of which being who controls and owns the link. That's a topic is for another time.
Here's a scenario, ERP in the cloud and Warehousing solution on-premise. The client is multi-site and run their on-premise solutions in an off-site data center. Company wide internet connectivity all runs through a single connection from the data center. All sites have a direct connection to the data center. Both solutions are highly transactional and as such heavily impacted by latency. As one of my former network engineer colleagues used to say, 'The only true restriction on latency is the speed of light'. What's that mean, in simple terms it means if you are latency dependent take the most direct route to your destination you can establish.
This a relatively simple scenario to deal with let's establish two connections per site. One to the internet and the other to the data center. Sorted and as I keep saying it's all about things which need to be considered. Let's break this approach down a little, the obvious items which need to be considered are cost, complexity and security. Starting with the last, for a change.
Security, every connection to the outside world can also be considered a point of access back in. Of course there are tools and devices to deal with this. These tools cost money and need to be maintained and monitored. Your network team are now transitioning from maintaining and monitoring a single outbound connection to multiple. It doesn't have to be a team btw, sometimes it's that guy, or girl, who sits over there in the corner, we're not sure exactly what they do but occasionally when they do speak you overhear words like subnets, QoS or, hopefully not, potential breach. This new structure is a little more complex than what it was, multiple connection points per site, additional inbound and outbound connections which in turn creates additional possible points of failure. No problem we can implement redundancy, but how exactly, do we ignore the latency requirement in a Disaster Recovery event and simply switch between our two connections? Or do we say latency is key and have standby links for each of our connections? Each choice will have cost and complexity considerations. It'll also likely depend upon the dynamics of the site in question.
Let me explain, for example I have six sites, Head Office, most of the administration tasks are done from here, ironically it's also the closest site to the data center. I also have two manufacturing sites with a combination of distribution requirements and some limited administration as well as three distribution warehouses which also house my localised sales teams. In this example while security will be a common consideration do we have to consider system usage as part of the upgrade from a cost and complexity perspective. Do we only look for redundancy on the most used link, be it internet or back to the data center? Does it increase the the complexity of network configuration and maintenance by having different profiles per site?
Of course latency is not the only consideration in this scenario but it can be a key one and hopefully it's gone some way to highlight some of the complexity behind the simple move of upgrading your ERP to a cloud based solution. As it turned out this piece ended up being primarily about networking, seems I had more to say about that topic than originally envisioned. There are additional considerations around the upgrade which need to be considered file servers, reporting, interfaces, document management....let us just say there are a few and I'll save them for another day.
'It's just an upgrade, should be simple right?'. Yes, of course it is let's just pull the trigger and get on with it. After all what could go wrong?
Senior Product Manager Automation - Sonic Healthcare
4 年Great article Craig, written by someone who has clearly walked the walk.
Director in Technology & Transformation | Digital Insurance Solutions
4 年Good article Craig and some good points. An ERP upgrade is never simple and should not be seen as a solution to any pre-existing challenges.