At the junction of ERP and ECM: how we automated the logistics process

We continue a series of materials that allow us to take a fresh look at the use of ECM or EDMS for the automation of corporate business processes.

It so happens that life throws tasks that you were not even going to do when you designed your workflow system. You can, of course, proudly say "our system is not designed for this," and this will be quite an honest professional answer. And you can soberly think about how to use the possibilities of ECM in a new way and risk going beyond the boundaries of the niche allotted to itself - to satisfy both the customer and a new experience.

If the ECM-system was designed with a good margin of flexibility and adaptability, then its scope can be safely extended to many related tasks that go beyond the office workflow. Automate the MTO process - logistics while encroaching on the traditional ERP field? And why not, if the customer asks?

The essence of the problem

We live in a time when it is no longer possible to find a service or a division in a large organization where the IT person’s foot would not go. Of course, the MTO department in the oil-producing company SANECO (a subsidiary of NK Alliance) was also automated once — there was a separate 1C there and lived its own autonomous life, in no way matching with the general corporate accounting system also on 1C. Buyers accepted bids from divisions in Excel-files, brought data to themselves and further processed according to the procedures known to them. For the rest, the system was a black box - in order to get information about the status of the application, it was necessary to ask the purchasing department.
')
As is usually the case, the developer of that customized configuration 1C for procurement management has long been gone. Meanwhile, new requirements appeared, processes changed, integration with document circulation was required ... Actually, the last factor played a decisive role, because duplication of information inevitably occurred when working in two systems and it was necessary to get rid of it.

MTO process: where do applications come from and what happens to them

The logistics process begins with a need. When an employee of the department knows what he needs to purchase, he forms an application and includes the necessary items in it. In essence, an application is a kind of container for a variety of items to be purchased. For example, an application for office supplies may include pens, notepads, staplers, and so on.

A prepared application is sent to the procurement department, where it is evaluated and returned to the initiator, if necessary, so that he can see whether it fits into the budget or not. Further, when the planned cost of the positions is approximately known, the approval of the application begins, at which it passes through various services and is finally approved. The reconciliation route is determined by the clerk of the MTO department, to which all applications from the initiating departments fall. He also checks the correctness of the application and attributing it to the cost items.

The approved application is returned to the MTO department for execution, where the employee responsible for it is appointed. This is where the most interesting begins: the positions within the application can be regrouped, you can consolidate applications from different departments or split the application into several parts. As a result, on the basis of all items included in the application, a delivery plan is formed. Then tenders are held, the winners are determined, with whom contracts are concluded, which are also coordinated in the SED. The application is considered executed when the initiator receives the positions ordered by him.

And why not do everything on 1C?

It seems to be logical to solve all accounting tasks on a single platform - since in the organization the main accounting system is built on 1C, then the processes of logistics support should be automated in it. But as always, important in details. The fact is that corporate 1C is implemented at the holding level and is supported centrally in Moscow, and there is no purchasing module in it. Besides, this is not a box, but a strongly customized solution, sharpened by Alliance NC and for the sake of one daughter, no one would make changes to the overall system. To keep the "island of automation" in the form of 1C in the MTO department the customer was absolutely not configured.

On the other hand, SANECO has already implemented an electronic document flow on the TEZIS , including the management of contracts. The concept of the MTO business process implied that the procurement contract must be agreed with the initiator, and this is more logical to do in the EDS than in the accounting system. Then the final version of the contract should be unloaded into the “big” 1C, where it is accepted by the accounting department for accounting.

Purely theoretically, the task of automating MTO processes can be implemented primarily by means of ERP and ECM, transferring the burden of development to one or another system, and sharing data by integrating them. But since we are not talking about a spherical horse in a vacuum, but about a specific customer, the option of upgrading 1C was not even considered. And what's the point of letting the multitude of users enter the accounting system who initiate and coordinate the applications? Let them do it in the document flow and do not climb into finance.

Expertise in the subject area is gainable.

On the technical side, the new task looked complicated, but solvable: add a new type of documents to the system, new routes, add business logic. In general, nothing unusual - if there is a good director, an expert in the subject area. It is clear that in the company, which is engaged in the implementation of the SED, there was no internal examination of the MTO processes. But on the side of the customer there were people who know their subject and are ready to take the risk to act as business analysts.

In fact, both sides did it for the first time, bumps were stuffed together and grew on this project together. Of course, it was possible to call business consultants who would explain how to properly build the process and how to automate it, but this, firstly, would significantly increase the project budget, and secondly, not a fact that would certainly lead to success . The main priorities were clear: get rid of the outdated unsupported system and build an end-to-end business process of MTO on the basis of successfully operating SED Thesis, and to do it for reasonable money.

Having looked at the boxed solutions available on the market, it was found that although they formally solve the problem, it was so inconvenient that it was hardly possible to get people to use it. In general, despite all the fears and risks, we decided to write a procurement management system on SED TEZIS.

How was it done

The project started in the summer of 2012. In order not to shock users with innovations, we have planned a gradual transition from the old system to the new one. First, we achieved that the applications were created in the THESIS, and not sent as files by mail. At the first stage, they were unloaded into the old 1C in a semi-automatic mode, but since this split the bases - some applications were already in the THESIS, some reached their way in 1C, it was difficult for users. Therefore, by the new year it was necessary to completely abandon the old system so as not to delay the transition period. What, in fact, was done - after the new year, they completely went to work in the TEZIS, and 1C could be buried.

Having no expertise in the subject area, we did not have the opportunity to manage the customer, to say that they really need to, and what can be discarded, to find inconsistencies in the requirements. Therefore, we had to listen to them and do what they asked for, and the customer, for his part, gradually began to think systematically. As a result, it was only after a couple of months of “living together” that an awareness of what information was really needed and how it should look in the system began to come. However, despite these difficulties, the project was able to withstand the timing of the project.

Atypical project - incentive to product development

It often happens that the features requested by the customer in a non-standard project then smoothly flow into the main product, thus contributing to its development. As for the automation of the MTO process, in principle, the standard capabilities of the platform were enough and did not have to invent some radical innovations. That is, our document management tools and business processes turned out to be enough for the task from the new domain, which could not but rejoice.

Perhaps, except that I had to tinker with the reports - it was necessary to make an analytical report when such a large sheet is formed - a “chess table” with dynamic columns and rows that grow depending on the data. At that time, our CUBA platform did not know how and according to the results of the project in SANECO, we pulled up the reports.

In general, we can draw the following conclusion: if we have a normal BPM and a good document management module, then we can take on any such accounting tasks.

What does new knowledge give us?

If the sellers hear that a new solution has appeared, they immediately think “now we will quickly resell it to other customers, then we will release the box ...” But unfortunately, everything is not so simple - a quick monetization of new knowledge may not happen.

In fact, when you take on a new project, it turns out that you invest a lot to understand in general what it is about, how everything is arranged in this business. And it becomes a pity the time spent if you end up with some useless, unclaimed knowledge. Where then to use it? It is difficult to bring to the box; it’s silly to compete in the forehead with ERP systems. But in this case it was valuable to understand that we can do this, that our platform allows us to accomplish such tasks, which are quite far from the usual workflow.

Customers all the time appear different - and such projects give confidence that potentially any task can be solved. In the management of an enterprise, procurement and financial activities are considered as one of the most complex processes, because they involve interaction between a large number of users, and not just in the coordination mode, but imply active work with information, consolidation, some processing of it, etc. Thanks to such projects, there is confidence that we are ready for larger and more complex tasks.