On the surface, moving to the new version may seem like it is an upgrade, but when you look deeper into the overall process and change to data, code and access, it is a lot closer to a re-implementation. As such, there are considerations that companies need to think of before undertaking the upgrade.
Since the upgrade process, though well defined, is essentially an abstract concept, I thought it would be easier - and a little more fun – to compare it to something more tangible. In this case, building a robot.
Before we get into building our mechanical friend, I would like to look at the very common practice of deviations.
What’s with the treads?
One of the most often seen deviations in robotics is around mobility. Traditionally, people think of robots being humanoid, with two arms, two legs, a torso and head. This helps adoption from a familiarity and comfort perspective, but the truth is walking on two legs is hard. Treads provide a more consistent - if not quite as flexible - solution to the vast majority of mobility issues robots face. However even a small set of stairs can cause an impediment. The point here is that deviations almost always come with a cost.
Making sure you understand the cost and the value of your deviation is critical when making the business decision about implementing it. If the robot you are building needs to track fish for example, then the question of legs VS. treads becomes irrelevant as a propeller or even tail will work best. Adding a tail to a home assistance robot is simply a waste of materials. Unless the robotics company has an ocean based theme, in which case it may be good marketing.
Many companies believe that they also have valid reasons for customizing their ERP environments, that their processes are unique. In some cases, they are correct, however for the most part, their processes are simply what they do because it is what they have always done. Perpetuating these processes can lead to a lot of unnecessary work, both in the implementation and in ongoing support. With enough deviation your ERP system ceases to be what you purchased and becomes an entity of its own. This increases the cost of ongoing support and may even preclude an upgrade in the future.
So as you read through this blog, I challenge you to stop and think about the customizations you have in place. Is it your process that makes your company unique, or is it the services/items you offer? If you are not reselling your processes it may be time to take a hard look at them and see if what Dyn365FO offers out of the box can actually work for you.
How to build a robot
The technology behind a basic robot is pretty simple. A set of gears and motors provide movement and a computer provides the ability to make decisions. Obviously this is highly oversimplified and the more complex the capabilities you need will drive most robot construction into the realm of highly trained specialists.
This Is not much different than an ERP system. In reality a few lines of code are all that is needed to balance a GL account, Excel can do it. However the more you try to integrate an ERP system into your daily activities, the more complex the code becomes and having someone who understands the impact of a change across the whole system becomes crucial.
Since most of us have not spent years working in robotics or cognitive services, we cannot actually construct a robot and so we take it on faith that they work as described. When you think about it, this leap of faith is not that different from running MRP. We have a set of common components (planning windows, stocking rules, etc.) and we have faith that if we set up the components correctly that we will get our desired outcome.
A metal body does not a robot make
The word robot usually conjures images of what we have seen in movies where mechanical people act and think like real people. While these are the types of robots that make the news, today’s robot reality is nowhere near this vision. Robots, for the most part, play a role in automating highly repetitive tasks with a great degree of accuracy. Probably the most mainstream image of robotics is the automotive manufacturing line. I can have a person spot weld the same 15 places on every car door, however a robot can do it more efficiently. From a business perspective then, robotics is simply another tool. The business could survive without the tool – a worker cold pick up a spot welder and take over if the robot failed, however it would leave the company at a significant disadvantage. An ERP system is no different. Your company would still be a company without an ERP system helping, though it will not be as efficient and would eventually be overtaken by those with the better tool.
Robotics as a field is not restricted to specific forms or functions, so the real challenge is in making sure that whatever design is created is as effective as possible for a given processes. With a system as flexible as Dyn365FO, the same challenge exists.
When designing robots it is very easy to get carried away and stray from what is realistic. Pie in the sky visions are common in upgrades as well, so make sure to keep reality in mind when you review your business processes. Many companies have documented procedures that they use to review and establish baselines like Sequence of Events (SOEs). An ERP system upgrade is a great time to compare those documents against what really happens. Too often companies find that the user community has implemented a faster or easier way to perform the same task and the document is not relevant. Instead of simply carrying those outdated documents forward, figure out what the best process is and take the time to make sure the user community agrees. Then implement that process in the upgrade. You may find that the uniqueness of your process was actually a hinderance.
When we talk about robots being autonomous we use the term Artificial Intelligence or AI. AI is what allows a robot to make decisions based on a series of logical pathways. I say pathways because AI is more than just simple if then else statements. Fuzzy logic and a host of other strategies allow AI to come pretty close to real intelligence. For the sake of this article and to avoid the heated debate that arises in almost any AI discussion, I am going to refer to autonomous decision making as Artificial Motivation. What compels the robot to do what it is doing? Thinking about the assembly line arm again, the motivation is pretty clear and simple. The door arrives in the right place, weld spot one, then weld spot two. Clear motivation leads to repeatable success. However if we were to take that same arm and place it in a different environment, say pool cleaning, it would clearly fail. The motivation (weld) does not match the desired outcome (a clean pool).
The same can be said for an ERP upgrade. Understanding the motivation behind the decision to upgrade can be the difference between success and failure. For example, faster, more accurate and more relevant data are all compelling reasons to do an upgrade, but they are not the only ones. Doing an upgrade for the simple reason that you can is not very compelling. Access to new features, taking the opportunity to clean up or focus data and even streamlining or reviewing existing processes to make sure they are still relevant are all great reasons to undertake an upgrade. Focusing on the motivating reasons behind the upgrade will allow your team to deprioritize the noise and ensure the right outcome is worked on.
Does that robot have a backpack?
An assembly line robot is hardwired to power, so there is little concern needed there, except to make sure enough current is available to meet the demand. For mobile robots, power becomes a real concern. The robot has to have enough current to be useful, but cannot carry so much capacity that the weight limits functionality. Getting this balance right is one of the more challenging aspects of robot design. During an upgrade, your power source is going to be the tool that will transform your data from it’s current state into something useful in the new system. The tool should not have to worry about how the data is going to be used. All of that planning happens outside of the tool selection. All the data migration tool should do is take the data from point A to point B. Some transformation may have to occur here and too much transformation may be counterproductive. There is a balancing act needed here.
Bringing all of the data is usually a desired outcome, however depending on the volume and complexity of the transformations needed, it may turn out to be time or cost restrictive. A true Information Management Lifecycle (ILM) process can hep with this, however implementing one during the migration is not a good idea. If you have not started the migration yet, it may be worthwhile to investigate and - at least at a high level – implement an ILM.
This data migration is the most important and potentially time consuming element of the upgrade. Without confidence in the data, nothing else will matter. Taking time to transform and test, however often is needed, must be done. Customizations will complicate this process as the functions using that custom data must also be migrated in order for true testing to occur.
Speaking of testing, this needs to include end users. Simply looking at the data in the underlying tables will not guarantee that it is going to behave as expected. Did an integer field, like an inventory count, accidentally get transcribed to an Enum field? The data will look ok from a raw value point of view. When a user tries to look up that information it will fail. Finding this out after go live would not be a good thing.
The data review is also a good time to understand how best practices apply – and when to deviate from them. After all, business processes exist only to support the collection and usage of data. Deviation is not bad, as long as it is really needed. Remember the robot fish tail?
The last thing to consider about data is points of integration. Third party systems, like EDI and web portals all need to be looked at. Access to the data is likely not going to stay the same. Understanding early in the process what is needed to modify those integrations will save a lot of headaches later on.
Form defines function
Searching the web for robots will yield a slew of results and for the most part no two robots will be the same. They may look generally the same, the form factor driven by the motivation of the robot. Even humanoid robots, outside of the two arms, two legs look can appear vastly different. Each of these form factors are designed for a specific, desired outcome. Significant modification to the form will inevitably modify the function. Proceed with caution.
Code is the form factor of an ERP system, and in the same way care must be taken in changing too much. There are valid reasons with clear benefits to modifying an ERP system, but diligence is in order if you want to be able to look back at what you did and say “we are still running Dyn365FO”.
We’ve already discussed the perception of a need for customization but it bears looking at again. I often say: “The best thing about Dyn365FO is that you can pretty much do whatever you want. The worst thing about Dyn365FO is that you can pretty much do whatever you want.” Without discipline, the path from a clean, useful form factor to a poorly performing kludge of parts is a slippery slope.
During the upgrade process a code review should be performed on any customization currently in place in AX 2012 or 2009. Dyn365FO has a significant number of new processes in place, especially when compared to AX 2009, so things that were missing in older versions may be present out of the box, completely eliminating the need for a customization.
For any customizations that are deemed required, a rewrite is likely in order. There is a tool, in LCS, that will review a code database and provide an output of customizations that can be brought in and those that will need to be rewritten. Even if all your customizations miraculously pass and you can just import them, how comfortable will you be telling the business everything works exactly the same as in the old system? When you couple the coding paradigm shift (overlayering to extending) with the potential in business process change, it should become pretty clear that any code you carry over should be reviewed and then thoroughly tested by your user community.
It’s all about focus
Robotics is not a quick science. Outside of the popular building brick kits you can buy, most robots are not built in a day. Dedication, focus and a strict adherence to the planned outcome are all required to get through the design, construction, testing and re-design cycle of creation.
An ERP system is no different. Each implementation is slightly different, even if run again in the same company, like during an upgrade. The people involved, both internal and from any third parties assisting, will imprint some of themselves in the final product. Rushing this process will ultimately lead to a poor or even failed project. Any team involved in the ERP upgrade process will need time to focus. Without it, all kinds of issues will ensue. You may get there, but it will almost certainly not be pretty.
I often tell people to think of an upgrade as moving day. It’s a perfect opportunity to leave behind years of clutter that you really don’t need. At the same time, you need to make sure you bring with you the things that are still important. Simply brining everything will usually result in a garage full of boxes that never get dealt with, wasting space and reducing your enjoyment with the new home.
Walking on the shoulders of giants
Anyone starting in a robotics career now has a vast collection of research and lessons learned to draw from. They are not going to have to start from scratch and reinvent the wheel. Obviously innovation demands questioning status quo, but attempting to redesign everything instead of just the attributes that will differentiate your creation will likely end up being a simple waste of time. Taking the time, and in some cases setting aside pride, to truly identify what someone else has done that will work for you can be the best course of action. It comes back to the same question we asked earlier: what really makes your company unique? Is it every piece of data ever used, or is it the data that you have carefully mined and isolated to drive your sales force? There is no downside to using the building blocks established by others as the launching pad for your success.
Microsoft is taking that wisdom to heart with the upgrade and deployment processes for Dyn365FO. Many existing AX customers have experienced the “AX is slow” complaint. I have spent a lot of time helping customers find root cause of the slow and it was actually out of the box AX in very few cases. Most of the time it was a component of AX that was not implemented following best practices. Underpowered or misconfigured SQL servers, poorly implemented coding changes and thick clients connecting across WANs are all things that I have seen. In order to prevent the perception of Dyn365FO being slow or bad, Microsoft is trying to enforce a deployment practice that it has tested and is confident will provide the user experience it desires. This should be your launch pad.
Despite Microsoft’s best efforts, Dyn365FO’s flexibility makes it so there are ways around this best practice upgrade. AX 2009 users can in fact import all of their data. It would not be through an unmodified Microsoft provided tool, but it can be done. They are just data packages after all. But what benefit would it provide having all of that data, manually transformed, live in the new system? Would having that data available in a data warehouse provide the same benefit? Would it be easier to implement? The answer is that it depends. How your company uses that data, what kind of audits you have to pass and even owner comfort are all factors here. There is no hard and fast right answer, but the guidelines and best practices provide a great place to start. Remember that best practice really only defines what works for at least 51% of companies. Your responsibility is to determine if you are part of the norm or not. Most of the time, companies are part of the norm, but admitting that can be difficult.
At the very least, when you start planning your upgrade process, take some time to evaluate Microsoft’s recommended path before deviating. You may find that it works out faster, cheaper and will provide the same benefit as anything custom you come up with. You may find that it doesn’t work at all and you need to do something different. If that happens, at the very least you will already understand what specifically failed and why, shortcutting the customization process.
Do keep in mind that the further you deviate from normal the harder it will be to find support, as most companies will need to spend time understanding what was done before they can start looking for resolutions.
In the end, though sometimes hard to believe, being unique is not all it is cracked up to be.