What can SED outside the office: the automation of the treasury
We continue a series of articles on the theme " SED: the path from simple to complex ."
Is it possible with the help of EDS to automate the control of treasury activity in a company whose divisions and subsidiaries are located at a great distance from each other? It depends on your SED. We’ll immediately make a reservation: it’s not about reducing all business processes to shifting “pieces of paper” and simulating the work of all divisions according to the principle of office. By no means!
The fact is that a narrow-subject approach to the development of business applications, including EDS, is a long time in the past. Today, any decent system has a fair amount of flexibility and functionality, so it can be used to solve sometimes atypical tasks. This happened in the vertically-integrated oil company NK Alliance, where, due to intensive document flow and the need to organize effective interaction between users from different regions of Russia and Kazakhstan, the choice of SED TEZIS as a platform turned out to be more than successful.
For reference: The Treasury is one of the key divisions of a usually holding company that coordinates the work of all financial services of subsidiaries and divisions. The main objective of this financial structure is to ensure uninterrupted cash flow both with external counterparties and within the organization.
Each payment is an event, a transaction that needs to be calculated, agreed and executed. That is, it is a kind of document (or set of documents) that must pass along a certain route of approval and its execution must be monitored. Sounds very similar to the formulation of the task for the introduction of SED, is not it? Only the document itself is specific - not some kind of official memo there, but a complex object, with fields calculated according to certain business rules and communicating with other systems. That is, here we climb a little into the ERP glade.
In Alliance Oil Company a separate budgeting system was used, which did not suit the customer. We at that time worked with the organization and have successfully implemented the TEZIS document management system. In its composition there is a very decent tool for business process management and entity constructor inherited from CUBA (the platform on which SED TEZIS is written). Thus, you can create your own types of objects and set the rules for their processing. And the functions of the distribution of instructions and control are in principle invariant with respect to the subject domain, therefore our experience from the SED turned out to be quite applicable.
')
The golden rule “works - just don't touch anything” is applicable to a certain limit, as long as people are ready to endure the inconveniences of the old system and do not see other real alternatives. In our case, there were two annoying factors:
And more (it was found out already on implementation): During trial operation reports were prepared in two systems, the old and the new. In one of the reports found a discrepancy. Naturally, they announced this as a bug of the new system. However, when everything was carefully checked by hand, I had to admit that this was a mistake of the old system.
OK, all programmers are wrong, it happens. But one thing is logical errors that can be caught at the testing stage and another thing is errors due to unreliable architecture: what works well for one user does not always successfully scale in a distributed multi-user environment.
The old budgeting system had problems due to the use of the joint editing of tables — such a mechanism for entering primary data was provided, but it is difficult to control the integrity of the data. In the Thesis, all transactions immediately go through the server, and such a collision simply cannot happen.
It is impossible to automate a large organization with a single system, hanging all the tasks on it - this is the truth of life. Be sure to find tasks for which a functional customer will require to implement some special solution, and then you kindly provide end-to-end business processes! It certainly pleases integrators, and the customer's IT service is by no means always.
But what is absolutely unacceptable by modern standards is the presence of “islands of automation” - separate systems that cannot be included in the general information exchange. Alliance Oil Company faced just such a situation: the system used by the treasury at that time was completely isolated - it did not interact with the accounting department or with the SED.
Therefore, after a sober reflection, the customer decided to reduce the number of systems and abandon the previous solution, shifting his functional “duties” to the TEASIS. From an architectural point of view, such a simplification of the landscape is an undoubted benefit. If the problem can be solved by a smaller number of systems, it is imperative to do so.
Until the accountant creates a payment order in his 1C and sends this payment to the bank, the money will not go anywhere, be your application at least three times agreed and approved. If you bring it to the accounting department on paper or even send it as a document by e-mail, you will have to wait until the accountant clogs your data into your system. And these applications are darkness.
You, as always, need urgently, right? So help the accountant, complete the payment yourself. Do not know how to work in 1C? It is clear ... Similarly, the accountant does not want to study the extra systems. Therefore, in order not to strain anyone, we decided to bring all the processes of approval of applications into the TEZIS, and thanks to proven mechanisms of integration with 1C, to implement the interaction of companies in the holding.
“So in 1C there is a document flow!” - the attentive reader will say. And he will be right, but the customer received a negative experience with this product on another project, and did not want to risk it again. And the story with TEZIS developed quite positively - the document management system was already in industrial operation.
As a result, all the initiators of the payments themselves make applications for payment in the THESIS (most of which are based on templates), on the basis of which the bills are formed in 1C, and the accountant simply needs to check them and not fill them from scratch.
For example, the technical capabilities of the system allow you to do anything - even document flow, even the treasury, even seeds to trade - on the market or on the exchange. Flexibility - 100%. Essence and processes - whatever. But why do we see that companies, even equipped with universal tools, very slowly penetrate into new subject areas? Because in any case you need to build up expertise before it all becomes easy to do.
An application for payment is not an ordinary memo, which has only a number and date. In every new business there are nuances, so we had to redo the product as the requirements were clarified and knowledge accumulated.
Here, for example: at first they did it in a simple way - one application - one budget item. It turned out that this is not very convenient, because one application may be held under different articles, for example, when, within the framework of one agreement, services for its installation / implementation go along with some goods.
Taking into account the monthly financial planning, on the basis of which, ultimately, applications for payments are formed, the ability to work flexibly with these payments is extremely important. The implemented treasury control system based on the SED. The thesis reduced the time for working with financial applications due to the possibility of creating a single application, which is first included in the financial plan, and then immediately after signing the primary documents is sent for approval for payment, which is typical in 90% cases.
Employees of financial services, in turn, were able to split the application into several payments, transfer them between months and carry out lower-level planning using the payment calendar.
In general, the TEZIS team successfully completed the project. On the basis of the SED, a treasury automation system was built in a large holding company that provides work with the cash flow budget, checking limits, coordinating and planning payments, and tracking payment facts.
The customer is completely satisfied with the new solution. As is often the case, for some time during the implementation process, users have to work in parallel in two systems, and since people are conservative, the new one sometimes gets accustomed with difficulty, under administrative pressure. In NK "Alliance" this did not happen. (Again, due to the fact that treasury automation was essentially an extension of the SED functionality.)
The geographical factor often destroys the most correctly written plans, and remote communication does not always compensate for the living. And here, too, everything was successful. Judge for yourself: a functional customer in Moscow, a developer in Samara, and implementations throughout Russia. In this case, it took only two trips - to launch the project and to surrender. The rest of the time they communicated remotely, but very intensively, they even broke all records in the customer’s company for the duration of conference calls via Skype. Of course, they saved on business trips, but there is one more thing: high-ranking employees of the financial service, who are always very busy, would have to become users - it would have been possible to catch them around their offices all day, wasting our analysts time, while the Skype conversation could be scheduled at a convenient time for all.
Implementing the task of treasury management, we actually invaded the territory of ERP with its SED system. This was made possible thanks to the universal CUBA platform, and in principle there are no architectural and technical obstacles in order to develop a fully functional ERP on this platform.
Summing up the line, we can conclude:
Having in the hands of EDS, which is based on a universal flexible platform, you can get involved in a wide variety of projects that go far beyond the traditional workflow. The risk is not connected with the technical side, but exclusively with the competence in the subject area.
Of course, EDS will not replace ERP or CRM, in order to bring a custom solution to the product level, you will have to work a lot - and this will be a different story. If someone takes - welcome! A stopper here can only be a lack of relevant competences in the subject area.
The history of this project and customer feedback can be found here .
Is it possible with the help of EDS to automate the control of treasury activity in a company whose divisions and subsidiaries are located at a great distance from each other? It depends on your SED. We’ll immediately make a reservation: it’s not about reducing all business processes to shifting “pieces of paper” and simulating the work of all divisions according to the principle of office. By no means!
The fact is that a narrow-subject approach to the development of business applications, including EDS, is a long time in the past. Today, any decent system has a fair amount of flexibility and functionality, so it can be used to solve sometimes atypical tasks. This happened in the vertically-integrated oil company NK Alliance, where, due to intensive document flow and the need to organize effective interaction between users from different regions of Russia and Kazakhstan, the choice of SED TEZIS as a platform turned out to be more than successful.
Treasury is processing applications
For reference: The Treasury is one of the key divisions of a usually holding company that coordinates the work of all financial services of subsidiaries and divisions. The main objective of this financial structure is to ensure uninterrupted cash flow both with external counterparties and within the organization.
Each payment is an event, a transaction that needs to be calculated, agreed and executed. That is, it is a kind of document (or set of documents) that must pass along a certain route of approval and its execution must be monitored. Sounds very similar to the formulation of the task for the introduction of SED, is not it? Only the document itself is specific - not some kind of official memo there, but a complex object, with fields calculated according to certain business rules and communicating with other systems. That is, here we climb a little into the ERP glade.
In Alliance Oil Company a separate budgeting system was used, which did not suit the customer. We at that time worked with the organization and have successfully implemented the TEZIS document management system. In its composition there is a very decent tool for business process management and entity constructor inherited from CUBA (the platform on which SED TEZIS is written). Thus, you can create your own types of objects and set the rules for their processing. And the functions of the distribution of instructions and control are in principle invariant with respect to the subject domain, therefore our experience from the SED turned out to be quite applicable.
')
Why it was necessary to change the old system
The golden rule “works - just don't touch anything” is applicable to a certain limit, as long as people are ready to endure the inconveniences of the old system and do not see other real alternatives. In our case, there were two annoying factors:
- The isolation, because of which the curators had to work in two systems, and financiers - in three. The consequence of this was data inconsistency, re-entry and errors.
- Inability to work in a geographically distributed environment to ensure interaction between the holding's enterprises and data consolidation.
And more (it was found out already on implementation): During trial operation reports were prepared in two systems, the old and the new. In one of the reports found a discrepancy. Naturally, they announced this as a bug of the new system. However, when everything was carefully checked by hand, I had to admit that this was a mistake of the old system.
OK, all programmers are wrong, it happens. But one thing is logical errors that can be caught at the testing stage and another thing is errors due to unreliable architecture: what works well for one user does not always successfully scale in a distributed multi-user environment.
The old budgeting system had problems due to the use of the joint editing of tables — such a mechanism for entering primary data was provided, but it is difficult to control the integrity of the data. In the Thesis, all transactions immediately go through the server, and such a collision simply cannot happen.
Integration is good for integrator, but not always for customer
It is impossible to automate a large organization with a single system, hanging all the tasks on it - this is the truth of life. Be sure to find tasks for which a functional customer will require to implement some special solution, and then you kindly provide end-to-end business processes! It certainly pleases integrators, and the customer's IT service is by no means always.
But what is absolutely unacceptable by modern standards is the presence of “islands of automation” - separate systems that cannot be included in the general information exchange. Alliance Oil Company faced just such a situation: the system used by the treasury at that time was completely isolated - it did not interact with the accounting department or with the SED.
Therefore, after a sober reflection, the customer decided to reduce the number of systems and abandon the previous solution, shifting his functional “duties” to the TEASIS. From an architectural point of view, such a simplification of the landscape is an undoubted benefit. If the problem can be solved by a smaller number of systems, it is imperative to do so.
In 1C all users will not drive
Until the accountant creates a payment order in his 1C and sends this payment to the bank, the money will not go anywhere, be your application at least three times agreed and approved. If you bring it to the accounting department on paper or even send it as a document by e-mail, you will have to wait until the accountant clogs your data into your system. And these applications are darkness.
You, as always, need urgently, right? So help the accountant, complete the payment yourself. Do not know how to work in 1C? It is clear ... Similarly, the accountant does not want to study the extra systems. Therefore, in order not to strain anyone, we decided to bring all the processes of approval of applications into the TEZIS, and thanks to proven mechanisms of integration with 1C, to implement the interaction of companies in the holding.
“So in 1C there is a document flow!” - the attentive reader will say. And he will be right, but the customer received a negative experience with this product on another project, and did not want to risk it again. And the story with TEZIS developed quite positively - the document management system was already in industrial operation.
As a result, all the initiators of the payments themselves make applications for payment in the THESIS (most of which are based on templates), on the basis of which the bills are formed in 1C, and the accountant simply needs to check them and not fill them from scratch.
Not everything went smoothly.
For example, the technical capabilities of the system allow you to do anything - even document flow, even the treasury, even seeds to trade - on the market or on the exchange. Flexibility - 100%. Essence and processes - whatever. But why do we see that companies, even equipped with universal tools, very slowly penetrate into new subject areas? Because in any case you need to build up expertise before it all becomes easy to do.
An application for payment is not an ordinary memo, which has only a number and date. In every new business there are nuances, so we had to redo the product as the requirements were clarified and knowledge accumulated.
Here, for example: at first they did it in a simple way - one application - one budget item. It turned out that this is not very convenient, because one application may be held under different articles, for example, when, within the framework of one agreement, services for its installation / implementation go along with some goods.
Taking into account the monthly financial planning, on the basis of which, ultimately, applications for payments are formed, the ability to work flexibly with these payments is extremely important. The implemented treasury control system based on the SED. The thesis reduced the time for working with financial applications due to the possibility of creating a single application, which is first included in the financial plan, and then immediately after signing the primary documents is sent for approval for payment, which is typical in 90% cases.
Employees of financial services, in turn, were able to split the application into several payments, transfer them between months and carry out lower-level planning using the payment calendar.
Reason for pride
In general, the TEZIS team successfully completed the project. On the basis of the SED, a treasury automation system was built in a large holding company that provides work with the cash flow budget, checking limits, coordinating and planning payments, and tracking payment facts.
The customer is completely satisfied with the new solution. As is often the case, for some time during the implementation process, users have to work in parallel in two systems, and since people are conservative, the new one sometimes gets accustomed with difficulty, under administrative pressure. In NK "Alliance" this did not happen. (Again, due to the fact that treasury automation was essentially an extension of the SED functionality.)
The geographical factor often destroys the most correctly written plans, and remote communication does not always compensate for the living. And here, too, everything was successful. Judge for yourself: a functional customer in Moscow, a developer in Samara, and implementations throughout Russia. In this case, it took only two trips - to launch the project and to surrender. The rest of the time they communicated remotely, but very intensively, they even broke all records in the customer’s company for the duration of conference calls via Skype. Of course, they saved on business trips, but there is one more thing: high-ranking employees of the financial service, who are always very busy, would have to become users - it would have been possible to catch them around their offices all day, wasting our analysts time, while the Skype conversation could be scheduled at a convenient time for all.
Do not be afraid of new challenges, but do not climb on the rampage
Implementing the task of treasury management, we actually invaded the territory of ERP with its SED system. This was made possible thanks to the universal CUBA platform, and in principle there are no architectural and technical obstacles in order to develop a fully functional ERP on this platform.
Summing up the line, we can conclude:
Having in the hands of EDS, which is based on a universal flexible platform, you can get involved in a wide variety of projects that go far beyond the traditional workflow. The risk is not connected with the technical side, but exclusively with the competence in the subject area.
Of course, EDS will not replace ERP or CRM, in order to bring a custom solution to the product level, you will have to work a lot - and this will be a different story. If someone takes - welcome! A stopper here can only be a lack of relevant competences in the subject area.
The history of this project and customer feedback can be found here .
Source: https://habr.com/ru/post/264929/
All Articles