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 application of ECM or EDMS for automating corporate business processes.
    image
    It so happens that life throws up tasks that you didn’t even intend to do when you designed your workflow system. You can, of course, proudly say "our system is not designed for this" and it will be a completely honest professional answer. And you can think soberly how to use the capabilities of the ECM in a new way and risk going beyond the boundaries of your own niche - you can satisfy the customer and gain new experience.

    If the ECM-system was designed with a good margin of flexibility and adaptability, the scope of its application can be safely expanded to many related tasks that go beyond the scope of clerical workflow. Automate the MTO process - logistics, encroaching on a traditional clearing ERP? And why not, if the customer requests it?

    The essence of the problem


    We live in a time when it is no longer possible to find a service or unit in a large organization, where the IT foot would not have stepped yet. Of course, the MTO department in the oil company SANECO (a subsidiary of Alliance Oil Company) was also once automated - there it was a separate 1C and lived its own independent life, without interfacing with the corporate accounting system in 1C as well. Buyers accepted applications from departments in Excel files, entered data to themselves, and then processed them according to 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 procurement department.

    As it usually happens, the developer of that custom configuration 1C for procurement management has long been gone and the trace has gone cold. Meanwhile, new requirements appeared, processes changed, integration with document management was required ... Actually, the last factor played a decisive role, because when working in two systems there was inevitably duplication of information and it was necessary to get rid of it.

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


    The logistics process begins with need. When an employee of the unit knows what he needs to purchase, he forms an application and includes the necessary positions in it. In fact, the application is a kind of container for many items to purchase. For example, a stationery application may include pens, notebooks, staplers, and so on.

    The prepared application is sent to the procurement department, where it is evaluated if necessary and returned to the initiator so that he can see whether he fits into the budget or not. Further, when the planned cost of the positions is approximately known, approval of the application begins, in which it passes through various services and is finally approved. The approval route is determined by the clerk of the MTO department, which receives all applications from the initiating units. He also checks the correctness of registration of the application and its classification as 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 fun 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 applications, a delivery plan is formed. Then tenders are held, winners are determined, with whom contracts are concluded, which are also subject to approval by the EDMS. An application is deemed 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 problems on one platform - since the main accounting system in the organization is built on 1C, then the logistics processes will be automated in it. But as always, the important is in the details. The fact is that corporate 1C is implemented at the holding level and is maintained centrally in Moscow, and it does not have a procurement module. In addition, this is not a box, but a highly customized solution, sharpened under the Alliance, and for the sake of one daughter, no one would make changes to the general system. The customer was absolutely not configured to save the “automation island” as 1C in the MTO department.

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

    Purely theoretically, the task of automating MTO processes can be implemented mainly both by ERP and ECM, transferring the burden of development to one or another system, and to ensure data exchange through their integration. 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 many users into the accounting system who initiate and coordinate applications? Let them do this in the workflow and do not go into finance.

    Expertise in the subject area is a business


    From a technical point of view, the new task looked complicated, but solved: add a new type of documents to the system, new routes, add business logic. In general, nothing unusual - if you have a good director, an expert in the subject area. It is clear that the company that is engaged in the implementation of the EDMS of internal expertise on the MTO processes was not. But on the customer side, there were people who knew their topic and were ready to risk acting as business analysts.

    In fact, both sides did this for the first time, stuffed cones together and grew up 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, firstly, this would significantly increase the project budget, and secondly, not the fact that would certainly lead to success . The main priorities were clear: get rid of an outdated unsupported system and build an end-to-end MTO business process based on the successfully running TESIS SED, and do it for a reasonable price.

    Having looked at the box solutions available on the market, it was found that even formally they solve the problem, but this was done so inconveniently 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 the THESIS EDS.

    How was it done


    The project started in the summer of 2012. In order not to shock users with innovations, they planned a gradual transition from the old system to the new one. First, we made sure that applications were created in THESIS, and not sent as files by mail. At the first stage, they were uploaded to the old 1C in a semi-automatic mode, but since there was a split of the bases - some applications were already submitted in THESIS, and some reached their way to 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. That, in fact, was done - after the new year, we completely switched to work in TESIS, and 1C could be buried.

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

    Non-standard project - incentive for product development


    It often happens that the features requested by the customer in an atypical 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 any radical innovations. That is, our tools for managing documents and business processes turned out to be enough for a task from a new subject area, which could not but rejoice.

    Perhaps, it was necessary to tinker with the reports - it was necessary to make an analytical report when such a large “chessboard” sheet is formed with dynamic columns and rows that grow depending on the data. At that time, our CUBA platform was not able to do this, and according to the results of the project in SANECO, we tightened the reporting.

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

    What gives us new knowledge?


    If sellers hear that a new solution has appeared, they immediately think “now we’ll quickly resell it to other customers, then we will release the box ...” But unfortunately, it’s not so simple - 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 for the time spent, if in the end some kind of useless, unclaimed knowledge is obtained. Where then to use it? It’s difficult to bring to the box, it’s stupid to compete head-on with ERP systems. But in this case, the understanding itself was valuable, that we can do this, that our platform allows us to implement such tasks, which are quite far from the usual workflow.

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

    Also popular now: