Pondering over prospects of ERP platform integration into your business, you need to understand precisely which tasks you are planning to use it for.
- Do you evaluate your manufacturing processes as inefficient and requiring modernization?
- Are you satisfied with the processes, but lack integrated accounting, analytics tools and transparent reporting?
The thing is — ERP systems are not that simple.
The point is ERP systems are positioned as tools for automation of processes (production, buying, financial planning processes, human resources, payroll, etc.). These are systems which embody algorithms of these processes.
Therefore, you need to answer the question: Do you need the processes already implemented in the system or do you need an automation of your own processes?
- Do you consider your own processes inefficient and requiring optimization?
- Do you have normal working processes, but are lacking an accounting of processes and transparency in an integrated financial reporting form?
After all, what is a “platform”? A while ago, it did not exist. A while ago, there was a process which programmers described as a form of an accounting system. They created a data structure for it and some handlers which do something with these data – complement, enrich, structure them into a life cycle and output them into a certain reporting format. Then they wrapped it up nicely, called it a “platform” and started selling that to everyone.
SAP is a good example. Their products have well-established and quality processes.
In particular, SAP automated logistics processes for PepsiCo (and they were the best at the time), then depersonalized these processes and started to sell them as a logistics module.
If your business has many logistics processes, then this module will be the cheapest solution for you. However, you have to understand that having taken a ready-to-use module which implements an algorithm of logistics processes without further modification, implies adaptation of your own logistics processes for pre-intstalled ERP structure.
When we talk about investment activities, such an approach is used mainly in the West and not so often in Russia. If an investor, who is competent in a certain field, buys distressed assets, then quickly optimizes them by installing an ERP system with quality processes and establishing actual processes strictly following ERP structure, this means the platform is not modified, but is filled up with data and roles, then the working process starts.
Therefore the biggest myth on the market which businessmen do not realize is that “if they buy a platform, they buy an automation of their own processes”.
So, what happens when you decide to integrate a ready-to-use platform in your business?
- Management reporting: dashboards work well in the context of original processes, but for your processes you need to modify.
- Business processes seem good, but if you look carefully, they are a bit different – need to modify.
- A platform has certain role models in a process. In other words, it has certain allocation of functions among participants, but your case is different – need to modify.
- Some external systems: for example, primary accounting systems where documents of your business processes appear do not meet your expectations – need to modify.
Finally, if we take an overview, almost all processes require modification.
The question arises – what do you pay for when buying the platform? You pay for an external constructor which requires serious modification.
The second myth about platforms is a myth about the monolithic character of a platform. There is an established opinion that a platform is one entity. However, if we look at the platform from a technological angle, we will find many different components and modules working with different data types, different processes and types of reports. In other words, a developer sees a “zoo of modules” which somehow interact with each other, but for a person far from the IT sphere, this is a product wrapped up with one cover, installed on one hardware, and is perceived as a monolithic entity.
Actually, from a technological point of view, both “monolith” and “zoo of systems” are still “zoo”, and from both support and customization points of view, the system is complex. Oftentimes, it is easier to support a “zoo of systems” because a monolith is so interdependent that a change in one place causes many other changes, even sometimes not so obvious. Therefore, additional unobvious pressure comes while working with big complex monolithic platforms. It’s called regression testing after changing one module, you need to test all other processes, data quality indicators and results in all other modules. It means while purchasing a monolith, you need to keep in mind that you depend on technology chosen by a particular development company; how this company understands the processes and how to work with them. You depend on automation tools, environment and languages chosen for the implementation.
A typical case is a 1C system. The technological tools chosen for the development of their ERP platform make it quite complicated to quickly create visual presentations for mobile devices.
Now everything comes to the conclusion that the module nature of monoliths transfers into a concept of creating separate specialized systems which are called “micro-services”, each solving one understandable task. Changing one service does not require regression testing of the entire landscape and allows changing of the technologies.