Russian platinum: SED works even where bears go
Platinum is mined in the same way as gold - sand is washed, precious grains are collected, then melted down. As early as 1984, the Amur coal miners began regular platinum mining at the Conder deposit in the Khabarovsk Territory. As it turned out, the deposits of platinum are huge, as evidenced by the nuggets weighing from one and a half to three and a half kilograms. In 2007, the Russian Platinum holding was formed, which included the Amur artel and a number of other enterprises.
And when a holding occurs, the need for workflow automation inevitably arises, because business processes become complicated, thousands of kilometers share their participants, and not only with paper, even with e-mail and Excel spreadsheets for document registration, it becomes impossible to process the entire flow. In general, the Russian Platinum group of companies decided to implement SED TEZIS .
Any holding has a distributed structure, it is an axiom. Therefore, any system that claims to be corporate should be able to work in distributed mode. But we must take into account the nuances - the distributed mode can be implemented in different ways. If we take the SED in any holding, then most often it turns out that in fact there are several separate identical or very similar systems - in the head office and in the subsidiaries, which exchange incoming and outgoing documents with each other.
You cannot say whether this is good or bad - if the customer is so comfortable, then why not? Similarly, our decision was built in Alliance NC . Several servers were installed there, but local directories were used, which were different everywhere and the holding companies communicated with each other through incoming-outgoing ones. There was, however, a directory of global counterparties in the accounting system, which was synchronized with the SED. In order to provide users with transparency of work in a distributed environment, we made phantom cards (they were so called among themselves). This is when a card is created in the main system, it is displayed in all the lists and search results, and when you click on it, you fall into the child system. Thus, we managed to do without the replication of documents and subsequent collisions with their editing in different systems.
You can go the other way when a unified management system with end-to-end business processes is built, and documents are moved from server to server as needed. This decision - which configuration to choose - is entirely on the customer’s side; it depends on the adopted management model of the holding and on the degree of autonomy of the subsidiaries. Although we believe that, from an IT point of view, it is better to have a single base and common directories, this is not always possible - for technical or administrative reasons.
In the "Russian Platinum" everything is completely different, not like in the Alliance Oil Company. It was immediately clear that it would be necessary to build a distributed system with end-to-end processes, to install two servers. Unlike the previous project, uniform reference books appeared here, which are edited only in one place, in the center. Since the main economic activity is conducted in Khabarovsk, it is natural that all new counterparties appear there. A directory is stored on a central server in Moscow. How to be? To resolve this collision, a single user in Khabarovsk was given remote access via VPN to a Moscow server so that he could edit the directory. When a new counterpart is established in the central database, the replication procedure is started, and the data is copied to the Khabarovsk server.
')
At first glance, it looks too difficult - why not introduce local contractors to the local server, and then let the two servers understand each other. But then we would have to set up bidirectional mutual replication, because Moscow can also get new contractors, and this is actually more difficult than having one data source and just copying directories to other servers.
Therefore, we took the path of unidirectional replication of central server directories by region (except for Khabarovsk, there is also Norilsk) with the help of our XDBStream service, which allows replication of databases. Replication occurs when changing tables in the database (adding / deleting / editing a record). To configure replication, you need to specify the “credentials” of access to the databases and specify which fields in which tables you want to synchronize.
XDBStream is not just some kind of internal development, it is a registered computer program (!), That is, a completely mature solution that we use in projects, although we are not promoting it separately.
We replicated the document cards ourselves via web services. The logic here is this: suppose the performer in Khabarovsk decides to conclude an agreement with a certain LLC "Medved" for the purchase of a dump truck into the quarry. He creates the contract and first starts the internal reconciliation. It takes some circles, and as a result, the general director of the branch approves the contract. After that, if the contract exceeds a certain amount, conditionally speaking 100 thousand, it is necessary to coordinate it with Moscow. What happens at this moment in the system: the contract on the local server goes into a “technical state”, that is, is blocked for any changes. Meanwhile, the web service that hangs on the central server periodically polls the system - are there any new cards for me? As soon as such a card appears, he drags it along with the contents file to himself. Thus, the contract goes to Moscow. Further, in Moscow the process of coordination is launched.
Further in Moscow he walks in his own cycle of coordination. There is also another web service that shows Khabarovsk what is happening in Moscow with their contract - who is in charge now, what visas are imposed, etc. And when someone decides to send the contract for revision back to Khabarovsk, he freezes in Moscow (goes into technical condition) and comes to life in Khabarovsk, heading for a new round of agreement. This situation can be repeated several times, and at the same time data from one system can always be seen in another - where the contract is now located.
If you look from the technical side, then actually there are two independent thesis systems that combine the replication of directories and this is the mechanism for transferring contracts in the negotiation process. We developed this XDBStream-based mechanism specifically for Russian Platinum. Another advantage of this solution is that the document databases on the two servers are absolutely identical.
The time difference between Moscow and Khabarovsk is 7 hours, and the distance is 6 thousand kilometers. Routine work, when the business process is promoted to the next step through personal conversations, phone calls with such parameters becomes almost impossible. But the automated system must take into account such details that Khabarovsk people see everything in their own time, and Muscovites - in their own way. And all terms in the system are recalculated in working days in the native time zone for a participant in a business process. For example, in Khabarovsk, a document was sent for approval to an employee in Moscow - and there at 2 am. But his working day starts at 9 am, and even if the process costs three hours to agree on this document, the employee will receive it when he comes to work and the deadline is 12 hours in Moscow. It is logical that by 5 o'clock in the morning no one will agree on the contract.
It's good that we have a capital in the west of the country, and not vice versa! If the capital was in Khabarovsk and all head offices were located there, then in all large holdings an extra day would be lost for approval.
Everything in the world is subject to change, and software in particular. Then the customer will ask to add something, then the bug will be fixed, then some libraries need to be updated. When systems are so closely tied to each other one awkward movement can lead to unpleasant consequences. Not necessarily fatal - just something will disagree and stop working. Therefore, when operating the system in a distributed configuration, you need to take care of clear procedures for performing updates.
In our project, the configurations of both TEZIS servers - in Moscow and Khabarovsk - were identical, as were the document bases themselves. To preserve this identity, updates roll at the same time. Not absolutely synchronous, but one day. First you need to stop all replications, then stop the Khabarovsk server, update it, then stop and update the Moscow server. When this is done, you can restart the replication services.
From the standpoint of the usual urban logic of managers and consultants, the SED and other IT systems need to be brought to the final executor - in order to effectively automate business processes. Otherwise, they say, there is a gap - someone will run around with paper documents or drag files on flash drives.
We also decided to put jobs directly on the Conder deposit, despite the inaccessibility of this site and communication problems. The Internet is only when the satellite flies. And also bears periodically enter the trailer, so people have other problems there, besides controlling executive discipline :-)
But nevertheless, our CES Tezis has also earned in the taiga! First, through the terminal, the people connected to a computer in Khabarovsk and worked, then, after expanding the channel, they started connecting directly to the Khabarovsk server.
TEZIS has been operated in Russkaya Platina since 2012, and the customer did not require major changes during this time - sometimes they just asked to add a new field to the card or change the process.
Here I must say about one trick - there is a universal block of parallel-sequential matching in the THESIS. You can simply put it in the process designer and configure it to have as many stages and as many parallel and sequential blocks as you like. And if suddenly some internal regulations changed, or, for example, five people were fired and the way of coordination became faster, it is enough to change the settings in the process designer.
Thanks to this versatility and flexibility of the platform, TEZIS managed to live for three years without major modifications, although organizational changes took place at the customer.
In the ideal world picture, the introduction of a document management system and business processes should be accompanied by their substantial optimization - getting rid of paper, reducing approvals, etc. In life, this is not always the case; organizational change requires the will of management and pressure from competitors or the regulator.
No IT system alone can magically optimize a business process. IT specialists can only recommend something to managers, but usually do not have the opportunity to insist, so it is always so difficult to assess the effectiveness of the implementation of EDS and other similar systems. On the other hand, the availability of EDMS enhances the corporate culture of working with documents and tasks, sometimes clearly highlighting bottlenecks and ultimately creates the prerequisites for the productive work of management consultants.
In Russia, it is impossible to implement the SED and never face the requirement of integration with 1C. This competence - the ability to work with 1C, perhaps, should be considered one of the basic ones when choosing and evaluating the supplier of the EDS.
We have done integration with 1C more than once, including quite complex projects, including budgeting and logistics management tasks.
The customer had several disparate 1C bases: Khabarovsk, Moscow and Norilsk. Together with the implementation of TEZIS, there was a project to consolidate 1C, as a result of which all the bases were merged into one and cleared the reference books. However, they did it not simultaneously, but in several iterations, because of which we had to reload the data from 1C into our system several times, into our directories - and this is a rather lengthy procedure, several hours.
The task was to make sure that contracts in Moscow were not visible from Khabarovsk 1C, and everyone could see from the center. At first, we had an all-with-all integration, local servers could communicate with each other, and then they moved to a centralized one. The contract in 1C is in fact also a reference book, the table is from the point of view of the SED. There is a table of counterparties, there is a table of contracts subordinate to it. We enter into contracts and counterparties in our SED and then transfer them to 1C as master data.
As a result, they came to the interaction with 1C in the "point-to-point" mode: the central base of 1C in Moscow communicates with the TEZIS server. And each of the systems separately replicates directories and documents on regional servers. This is a typical approach for us, when the SED is a source of master data on contractors and contracts for accounting systems.
Progress does not stand still - communication becomes faster, more reliable and cheaper. This gives a technical opportunity to move from a distributed system to a centralized one, then it’s up to management.
A year ago, “Russian Platinum” decided to abandon the Khabarovsk TEZIS base and transfer everything to the central server, but so far they have only abandoned Chernogorka (Norilsk). In fact, it turned out to be easy, since the data in the databases are identical. At some point we simply redeemed the Norilsk server and redirected all users to Moscow. And there already have all their accounts, all documents, just a web link to the EDS server has changed on the desktop, the entire working environment has remained the same. Undoubtedly, the turn will come to Khabarovsk, because in the general case, the centralized system is easier to maintain than the distributed one.
If you take a hypothetical holding, where there is a central node and ten regional, and for each regional node you can hang ten more organizations, you get a hundred organizations throughout the holding. You look later - the Moscow-Yekaterinburg channel has improved. You take and simply "cut down" the local server, and everyone starts working through the center. That is, we can start implementation on a distributed configuration, and then go to a centralized one, and without any alteration or refinement of the system.
Each project brings with it something new - new functions, new solutions, integrations, etc. It often happens that some modules from the project are then included in the main branch of the product, contributing to its development. Or simply reused on other projects, shortening the development and implementation cycle.
If we talk about "Russian Platinum", then from this project nothing was included in the basic supply of TEZIS. However, it was possible to use some of the works for the second time on another automation project of the Samara branch of RN-Service. They had two divisions in Samara and several divisions in the 100-kilometer zone, and the same task was the need to coordinate the documents with the central office. What they did before the introduction of the system: collected signatures on the document, got into the car and drove to Samara. There they delivered papers to a lawyer, then they went to Auchan, packed up food, looked at the city, took their papers and returned. Total 200 km of the way and the whole working day for a couple of signatures.
Although the Samara region is not at all a bearish angle, the connection within a radius of one hundred kilometers from the city is still far from being so good. Therefore, in RN-Service, we used the same scheme of coordination with local servers, as in Russkaya Platina — and frequent trips to the city were no longer necessary.
And when a holding occurs, the need for workflow automation inevitably arises, because business processes become complicated, thousands of kilometers share their participants, and not only with paper, even with e-mail and Excel spreadsheets for document registration, it becomes impossible to process the entire flow. In general, the Russian Platinum group of companies decided to implement SED TEZIS .
Document circulation in a holding company - specific principalities or power vertical
Any holding has a distributed structure, it is an axiom. Therefore, any system that claims to be corporate should be able to work in distributed mode. But we must take into account the nuances - the distributed mode can be implemented in different ways. If we take the SED in any holding, then most often it turns out that in fact there are several separate identical or very similar systems - in the head office and in the subsidiaries, which exchange incoming and outgoing documents with each other.
You cannot say whether this is good or bad - if the customer is so comfortable, then why not? Similarly, our decision was built in Alliance NC . Several servers were installed there, but local directories were used, which were different everywhere and the holding companies communicated with each other through incoming-outgoing ones. There was, however, a directory of global counterparties in the accounting system, which was synchronized with the SED. In order to provide users with transparency of work in a distributed environment, we made phantom cards (they were so called among themselves). This is when a card is created in the main system, it is displayed in all the lists and search results, and when you click on it, you fall into the child system. Thus, we managed to do without the replication of documents and subsequent collisions with their editing in different systems.
You can go the other way when a unified management system with end-to-end business processes is built, and documents are moved from server to server as needed. This decision - which configuration to choose - is entirely on the customer’s side; it depends on the adopted management model of the holding and on the degree of autonomy of the subsidiaries. Although we believe that, from an IT point of view, it is better to have a single base and common directories, this is not always possible - for technical or administrative reasons.
Distributed but unified system
In the "Russian Platinum" everything is completely different, not like in the Alliance Oil Company. It was immediately clear that it would be necessary to build a distributed system with end-to-end processes, to install two servers. Unlike the previous project, uniform reference books appeared here, which are edited only in one place, in the center. Since the main economic activity is conducted in Khabarovsk, it is natural that all new counterparties appear there. A directory is stored on a central server in Moscow. How to be? To resolve this collision, a single user in Khabarovsk was given remote access via VPN to a Moscow server so that he could edit the directory. When a new counterpart is established in the central database, the replication procedure is started, and the data is copied to the Khabarovsk server.
')
At first glance, it looks too difficult - why not introduce local contractors to the local server, and then let the two servers understand each other. But then we would have to set up bidirectional mutual replication, because Moscow can also get new contractors, and this is actually more difficult than having one data source and just copying directories to other servers.
Secret Weapon - XDBStream
Therefore, we took the path of unidirectional replication of central server directories by region (except for Khabarovsk, there is also Norilsk) with the help of our XDBStream service, which allows replication of databases. Replication occurs when changing tables in the database (adding / deleting / editing a record). To configure replication, you need to specify the “credentials” of access to the databases and specify which fields in which tables you want to synchronize.
XDBStream is not just some kind of internal development, it is a registered computer program (!), That is, a completely mature solution that we use in projects, although we are not promoting it separately.
Khabarovsk - Moscow and back
We replicated the document cards ourselves via web services. The logic here is this: suppose the performer in Khabarovsk decides to conclude an agreement with a certain LLC "Medved" for the purchase of a dump truck into the quarry. He creates the contract and first starts the internal reconciliation. It takes some circles, and as a result, the general director of the branch approves the contract. After that, if the contract exceeds a certain amount, conditionally speaking 100 thousand, it is necessary to coordinate it with Moscow. What happens at this moment in the system: the contract on the local server goes into a “technical state”, that is, is blocked for any changes. Meanwhile, the web service that hangs on the central server periodically polls the system - are there any new cards for me? As soon as such a card appears, he drags it along with the contents file to himself. Thus, the contract goes to Moscow. Further, in Moscow the process of coordination is launched.
Further in Moscow he walks in his own cycle of coordination. There is also another web service that shows Khabarovsk what is happening in Moscow with their contract - who is in charge now, what visas are imposed, etc. And when someone decides to send the contract for revision back to Khabarovsk, he freezes in Moscow (goes into technical condition) and comes to life in Khabarovsk, heading for a new round of agreement. This situation can be repeated several times, and at the same time data from one system can always be seen in another - where the contract is now located.
If you look from the technical side, then actually there are two independent thesis systems that combine the replication of directories and this is the mechanism for transferring contracts in the negotiation process. We developed this XDBStream-based mechanism specifically for Russian Platinum. Another advantage of this solution is that the document databases on the two servers are absolutely identical.
Accounting time zones
The time difference between Moscow and Khabarovsk is 7 hours, and the distance is 6 thousand kilometers. Routine work, when the business process is promoted to the next step through personal conversations, phone calls with such parameters becomes almost impossible. But the automated system must take into account such details that Khabarovsk people see everything in their own time, and Muscovites - in their own way. And all terms in the system are recalculated in working days in the native time zone for a participant in a business process. For example, in Khabarovsk, a document was sent for approval to an employee in Moscow - and there at 2 am. But his working day starts at 9 am, and even if the process costs three hours to agree on this document, the employee will receive it when he comes to work and the deadline is 12 hours in Moscow. It is logical that by 5 o'clock in the morning no one will agree on the contract.
It's good that we have a capital in the west of the country, and not vice versa! If the capital was in Khabarovsk and all head offices were located there, then in all large holdings an extra day would be lost for approval.
Need to be updated carefully
Everything in the world is subject to change, and software in particular. Then the customer will ask to add something, then the bug will be fixed, then some libraries need to be updated. When systems are so closely tied to each other one awkward movement can lead to unpleasant consequences. Not necessarily fatal - just something will disagree and stop working. Therefore, when operating the system in a distributed configuration, you need to take care of clear procedures for performing updates.
In our project, the configurations of both TEZIS servers - in Moscow and Khabarovsk - were identical, as were the document bases themselves. To preserve this identity, updates roll at the same time. Not absolutely synchronous, but one day. First you need to stop all replications, then stop the Khabarovsk server, update it, then stop and update the Moscow server. When this is done, you can restart the replication services.
You can reach this edge of the taiga only by plane ...
From the standpoint of the usual urban logic of managers and consultants, the SED and other IT systems need to be brought to the final executor - in order to effectively automate business processes. Otherwise, they say, there is a gap - someone will run around with paper documents or drag files on flash drives.
We also decided to put jobs directly on the Conder deposit, despite the inaccessibility of this site and communication problems. The Internet is only when the satellite flies. And also bears periodically enter the trailer, so people have other problems there, besides controlling executive discipline :-)
But nevertheless, our CES Tezis has also earned in the taiga! First, through the terminal, the people connected to a computer in Khabarovsk and worked, then, after expanding the channel, they started connecting directly to the Khabarovsk server.
We change processes without changing the system
TEZIS has been operated in Russkaya Platina since 2012, and the customer did not require major changes during this time - sometimes they just asked to add a new field to the card or change the process.
Here I must say about one trick - there is a universal block of parallel-sequential matching in the THESIS. You can simply put it in the process designer and configure it to have as many stages and as many parallel and sequential blocks as you like. And if suddenly some internal regulations changed, or, for example, five people were fired and the way of coordination became faster, it is enough to change the settings in the process designer.
Thanks to this versatility and flexibility of the platform, TEZIS managed to live for three years without major modifications, although organizational changes took place at the customer.
IT and process optimization
In the ideal world picture, the introduction of a document management system and business processes should be accompanied by their substantial optimization - getting rid of paper, reducing approvals, etc. In life, this is not always the case; organizational change requires the will of management and pressure from competitors or the regulator.
No IT system alone can magically optimize a business process. IT specialists can only recommend something to managers, but usually do not have the opportunity to insist, so it is always so difficult to assess the effectiveness of the implementation of EDS and other similar systems. On the other hand, the availability of EDMS enhances the corporate culture of working with documents and tasks, sometimes clearly highlighting bottlenecks and ultimately creates the prerequisites for the productive work of management consultants.
Integration with 1C is an indispensable skill for the document worker
In Russia, it is impossible to implement the SED and never face the requirement of integration with 1C. This competence - the ability to work with 1C, perhaps, should be considered one of the basic ones when choosing and evaluating the supplier of the EDS.
We have done integration with 1C more than once, including quite complex projects, including budgeting and logistics management tasks.
The customer had several disparate 1C bases: Khabarovsk, Moscow and Norilsk. Together with the implementation of TEZIS, there was a project to consolidate 1C, as a result of which all the bases were merged into one and cleared the reference books. However, they did it not simultaneously, but in several iterations, because of which we had to reload the data from 1C into our system several times, into our directories - and this is a rather lengthy procedure, several hours.
The task was to make sure that contracts in Moscow were not visible from Khabarovsk 1C, and everyone could see from the center. At first, we had an all-with-all integration, local servers could communicate with each other, and then they moved to a centralized one. The contract in 1C is in fact also a reference book, the table is from the point of view of the SED. There is a table of counterparties, there is a table of contracts subordinate to it. We enter into contracts and counterparties in our SED and then transfer them to 1C as master data.
As a result, they came to the interaction with 1C in the "point-to-point" mode: the central base of 1C in Moscow communicates with the TEZIS server. And each of the systems separately replicates directories and documents on regional servers. This is a typical approach for us, when the SED is a source of master data on contractors and contracts for accounting systems.
Communication channels have improved - IT systems can be centralized
Progress does not stand still - communication becomes faster, more reliable and cheaper. This gives a technical opportunity to move from a distributed system to a centralized one, then it’s up to management.
A year ago, “Russian Platinum” decided to abandon the Khabarovsk TEZIS base and transfer everything to the central server, but so far they have only abandoned Chernogorka (Norilsk). In fact, it turned out to be easy, since the data in the databases are identical. At some point we simply redeemed the Norilsk server and redirected all users to Moscow. And there already have all their accounts, all documents, just a web link to the EDS server has changed on the desktop, the entire working environment has remained the same. Undoubtedly, the turn will come to Khabarovsk, because in the general case, the centralized system is easier to maintain than the distributed one.
If you take a hypothetical holding, where there is a central node and ten regional, and for each regional node you can hang ten more organizations, you get a hundred organizations throughout the holding. You look later - the Moscow-Yekaterinburg channel has improved. You take and simply "cut down" the local server, and everyone starts working through the center. That is, we can start implementation on a distributed configuration, and then go to a centralized one, and without any alteration or refinement of the system.
We replenish the treasury of knowledge
Each project brings with it something new - new functions, new solutions, integrations, etc. It often happens that some modules from the project are then included in the main branch of the product, contributing to its development. Or simply reused on other projects, shortening the development and implementation cycle.
If we talk about "Russian Platinum", then from this project nothing was included in the basic supply of TEZIS. However, it was possible to use some of the works for the second time on another automation project of the Samara branch of RN-Service. They had two divisions in Samara and several divisions in the 100-kilometer zone, and the same task was the need to coordinate the documents with the central office. What they did before the introduction of the system: collected signatures on the document, got into the car and drove to Samara. There they delivered papers to a lawyer, then they went to Auchan, packed up food, looked at the city, took their papers and returned. Total 200 km of the way and the whole working day for a couple of signatures.
Although the Samara region is not at all a bearish angle, the connection within a radius of one hundred kilometers from the city is still far from being so good. Therefore, in RN-Service, we used the same scheme of coordination with local servers, as in Russkaya Platina — and frequent trips to the city were no longer necessary.
Lessons learned
- We have learned how to easily turn a decentralized structure into a centralized one.
- Necessarily need single reference books, management NSI.
- Integration with 1C - must have. (Later we even made a sample module.)
- Optimization of processes is a matter of time. Let people work first as they are used to.
Source: https://habr.com/ru/post/270659/
All Articles