Not everyone in your organization is an IT expert. Employees often find it difficult to understand exactly what to expect from a software project. Unfortunately, IT has a bad reputation for delivering successful projects and so there is a sense that these types of replacement projects are becoming too big and difficult to control. Using the Copy To Innovate method it is easy to explain what you get and how the size of the project can be controlled. The current system is being reconstructed and only functionalities that are not being used can be lost. Some functionalities cannot be implemented in the first phase. This strict approach makes it crystal clear to all stakeholders what software replication does and does not mean. Retrofit projects are therefore not large and complex, but easily manageable.
The pursuit of alignment between business users and IT administrators is difficult to achieve. Both have different views and areas of focus. By using the current application as a starting point, there is no discussion about the scope. There are some exceptions where you only use a small part of that system or where you use standard software packages for common processes. Basically, after decisions have been made about this, it means that if something is part of the old system, it must be part of the new system too!
A common mistake in software projects is that they want to make too many changes at once. On the one hand, the processes must be optimized and, on the other hand, the system must be updated from a technical point of view. For the users, this means that they have to work differently on another unknown system. For new organizations this is not a major hurdle to overcome, but for organizations where users have been working with the same applications for many years, it is.
All the knowledge that the users have about the current system is important. By first changing the technology and keeping the programs, functionalities and screens, people can reuse all knowledge of the current system. Complex processes can still be handled by these users and there is no loss of productivity for your organization. There is therefore no risk of failing business processes when going live and the lost turnover that often accompanies this.
Moving from your current system to a new system is a daunting task in itself. Ensuring that all your data can be converted to the new system is often considered impossible. This is because the data structure behind two systems can be very different, making it difficult to merge this data. Normally this means that unique codes or IDs for products, customers, suppliers, or delivery addresses, for example, must be changed, making it complex for users to recognize this data.
For example, if you have a product number, 1-03-005-02, which is changed or removed, it is quite difficult to know immediately whether you have chosen the right customer/product. In our software replication method, the data structures are kept the same in both systems. This leads to much easier data conversion projects and data on screens that are recognizable to your users.
Based on our experience in replicating complex systems (ERP, Planning or Calculation), we have developed software in recent years that can automate our own specific replication project approach. This enables us to reduce the risks and at the same time increase the speed of these projects. Part of this unique software is the Recorder. The Recorder is used to automatically collect data about your system. All this data is converted into information using complex algorithms. This information is then used to map the size and complexity of your current system. The collected information is generated to our low code platform where adjustments can be made quickly. In addition to the Recorder, we use very specific tools for software conversion projects that are able to automatically convert existing coding into new coding. This with the aim of increasing quality and significantly shortening the time required to modernize projects.
When you need to test a new system, it is difficult to decide if everything is working properly. There are new processes, new functionalities, and it is not always clear what the right outcome is. However, if both systems contain the same functionality and data, it is easy to validate whether the two systems work the same. You only need to validate whether the systems with the same input also have the same output. By involving key users in the testing, your project gets extra speed because they can immediately see whether something is going on on the screen. Remember that they have been working with the system for many years and recognize every little piece of data on the screen. If there’s an error in a delivery address, currency, or whatever, they’ll find it faster than you can test.
One of the most important aspects of implementing a new system is training all users. Making sure they know how the system works and how the system supports the new processes is vital. This can be a very time-consuming process, especially for larger organizations. Nor can you guarantee that all users really know how to work with the new system when it goes live. When replicating the application, all known programs, functionalities and screens are present and training is no longer a project in itself. Building the same know-how about a new system takes years. By replicating, we only need to train the users in how to make the best use of the new possibilities. This includes new ways to search, filter, share data or import / export data. In a few days, your users will be used to this and can handle all of your company’s processes.
Because the new system is very recognizable to the users, they can reuse all their knowledge of the current system to support their processes. For example, if a complex, unusual order comes in, they need to know that their special program is still there and working as expected. By also ensuring that the product codes or relationship codes have not changed, we ensure a smooth transition.
There is no risk during the implementation because both systems can continue to run side by side and the systems are behaving exactly the same way. Consistency checks can be easily performed on the new system and going live is no longer dependent on a fixed date, it can happen at any time. Usually going live means a final run of both systems with the users, by checking the main parts of important parts such as invoices and inventory management. After this, turn off the old system, and you’re done.
External factors such as customers, suppliers, or even external systems will not be affected as all information going to and from the system is and remains exactly the same.
Behind every successful project is a great team. Based on how many of your employees are part of the team and the different skills within your own organization, we put together a well-balanced project team. With our user-friendly tool set such as the Recorder, team members do not have to be skilled developers to add value to the project. Having a thorough knowledge of the old application is usually enough.
When developers join our team, we make sure to share the knowledge and train them in our tool set. This ensures that your developers are quickly informed and know how the application has been developed. Later they can play a valuable role in the support, change and innovation phase of the project. In this way, all the knowledge your developers have about your organization can be used.