If you are looking to be among the fast-growing businesses, you may already have automated all or most of your business processes. According to a study, up to 80% boost in fill rates (demands met through stock availability) resulted from higher digitization levels.
You wouldn’t want to be falling behind your competitors—least of all by painful, time-consuming manual work. So, each of your departments may be using an application or software to automate their processes. While they deliver terrific results individually, the data stored in each of these systems remain disconnected, resulting in many repercussions. It can hamper your company’s productivity, data consistency and accuracy, visibility, and, thus, increase costs.
That is when you need an integrated business solution to streamline all your processes. However, this is a crucial project and needs to be implemented rightly to ensure you get maximum ROI. As we suggest to all our customers at To-Increase, going over your requirements before you jump on to implementation will give you a rough time estimation, helping you be well-prepared when you get started. You can consider these 7 things before investing in an application integration software.
Now, if you are wondering how much time would an implementation take generally, it depends on a lot of factors. There isn’t a fixed average time; each project is unique, and so is the time it takes.
In this blog, I will talk about the typical steps in all the integrations and the time taken in each to help you evaluate how long an integration implementation can take, usually.
Estimating implementation time by steps of integration
Analysis and Design
This is one of the most critical steps in implementing an integration as, here, you start to define where exactly you want to move your data.
The complexity of this task will be based on your integration requirement. Several things need to be considered before establishing the complexity level of integration. Let’s split them based on the two main integration categories: Import and Export.
Let’s consider the situation where you are importing data from an external source, files, or web services to Microsoft Dynamics 365 or AX2012.
The first question you’d have is: ‘What do I want to import or process from the outside world to AX/D365?’. This will help you determine how complex your integration project is.
Let’s assume you want to import customers from an external webshop to ERP (From now on, I will use the generic ERP word referring to both Dynamics 365 and AX 2012). Let’s now focus on the data itself without getting too deep into the technicalities. If it is simple raw data without any complex structure inside of them, then we can easily conclude that initializing this data inside the ERP will not be too complicated.
Now, let me explain it with an example with a few technical details, assuming that we are importing customers, using a JSON file format.
You have a customer with his generalities and a bank account, and here are two kinds of requirements you could have:
Scenario 1: I’m only interested in storing the IBAN for the bank account.
Scenario 2: I’m interested in storing the IBAN for the bank account as well as other card information such as card number, expiration date, CVV, etc. On top of that, I want to allow my customer to have multiple bank accounts or methods of payment.
When you compare the above two scenarios, in the first case, you just have one simple data record, containing the IBAN. In the second case, you have an array of objects representing a bank account or a method of payment.
We can, then, conclude that the more elaborate and complex structure your source document contains, the more time it will take.
Let’s now explore the export situation, where you are exporting data from Dynamics 365 or AX2012 to an external source, files, or web services.
Generally speaking, export projects are less complex.
We have seen in the import situation that making the data more readable to the system was one of the main factors in increasing the complexity of implementation. However, the complexity level can rise quite fast while exporting. This is why we need to dive on a generic level on how tables work on our ERP.
So, with an export, we start from the ERP system. We define which data we want to query from which tables, and then give it a structure. Usually, on the ERP, the data we see in forms, such as sales orders and purchase orders, are not stored together in one table—it is spread across several tables.
For instance, let’s say you would like to export a sales order, which contains inventory information and detailed item information.
Here, you would need to be more careful about selecting the right tables and fields. We don’t have to worry about the most challenging part, which is creating relations between different tables as it is done automatically by Connectivity Studio.
For instance, let’s say you would like to export a sales order, which contains inventory information and detailed item information. This will require you to query multiple tables, and you’ll need to be careful when creating relations between the different tables.
When you create a relation between two tables, an integration solution will automatically identify and take the fields that share any parent/child relationship between them. However, you can always overwrite the *default* fields used to create the linking.
To summarize, if the export message requires creating a complex query across several tables, we can then deduce that the implementation time will be longer.
Once you have a clear design, showcasing your source and target, the next step would simply be to get started with the implementation.
This shouldn’t be a complicated and lengthy task and can be done within a few hours—even for more elaborate documents.
Once the source and target are ready, the only step remaining, now, would be the data mapping.
Again, the time that this step would take depends on your requirement. If it’s a simple and straightforward mapping (i.e., data source field A goes to data source field B), the mapping process will take.
However, this might change if your data needs complex mapping, like if you need to apply some calculations, altering functionalities before mapping a field.
At this stage, the message should be finished and ready to be executed.
Testing is an energy-draining task; it requires a lot of focus and attention to small details, especially for more complicated integration.
Most leading companies are using BIS tools to make the testing process easier and more accurate. Consequently, they save a significant amount of time and money involved in cleaning up errors and re-work.
How to ensure a quicker integration implementation?
One of the ways to accelerate your implementation process would be to go over each step and estimate the time based on your requirements, as you have seen in this blog.
This gives you an overall idea of approximately how much time you would need to complete implementation and go live. Besides, you can also prepare yourselves for it so that you not blocked anywhere during the implementation process and delaying it further.
The market is laden with business integration solutions such as application integration, electronic data interchange, and master data management that take care of your integration on deeper levels ensuring you achieve faster implementation.
Connectivity Studio for Microsoft D365 and Connectivity Studio for Microsoft AX, our systems integration solutions simplify your overall integration implementation between your ERP and other business processes, speeding up your go-to-market time.