And when there is a holding, inevitably there is also a need for document flow automation because business processes become complicated, their participants are separated by thousands of kilometers and not that with paper, even with e-mail and the tables Excel for document registration it becomes impossible to process all flow. Generally, the Russian Platinum group of companies decided to implement EDMS TEZIS.
Document flow in holding — specific principalities or a power vertical
Any holding has the distributed structure, it is an axiom. Therefore any system which is laying claim to corporate has to be able to work in the distributed mode. But it is necessary to consider nuances – the distributed mode can be implemented differently. If we take EDMS in some holding, then most often it will turn out that actually some of separate identical or very similar systems – at head office and in subsidiaries which exchange among themselves the entering and outgoing documents work.
It is impossible to tell, it is good or it is bad – if it is so convenient to the customer, then why would be not present? Our solution in Alyans Oil Company was in this way constructed. There several servers are installed, but local reference books which were different everywhere were used and the companies of holding communicated among themselves through entering-proceeding. There was, however, a reference book of global partners in accounting system which was synchronized with EDMS. To provide for users transparency of work in distributed environment, we did "cards phantoms" (so they were called among themselves). It when in main system is created a card, it is displayed in all lists and search results, and click it – fail in child system. Thus managed to do without replication of documents and the subsequent collisions with their editing in different systems.
It is possible to go also on other way when the single system of management with end-to-end business processes is under construction, and documents move from the server to the server as required. This solution – what configuration to select – entirely on the party of the customer, it depends on the accepted model of management of holding and on degree of autonomy of subsidiaries. Though we consider that from the point of view of IT it is better to have uniform base and the general reference books, it not always works well – for the technical or administrative reasons.
Distributed, but a single system
In "The Russian platinum" everything is arranged absolutely in a different way, not as in Alyans Oil Company. At once it was clear that it is necessary to build distributed system with end-to-end processes, to put two servers. Unlike the previous project, there were here uniform reference books which are edited only in one place, in the center. As the primary economic activity is conducted in Khabarovsk, it is natural that all new partners appear there. And the reference book is stored on the central server in Moscow. How to be? To permit this collision, one user in Khabarovsk was given remote access on VPN to the Moscow server that it could edit the reference book. When in the central base the new partner is brought, replication procedure is started, and data are copied on the Khabarovsk server.
At first sight looks too difficult – why not to enter local partners into the local server, and then let two servers among themselves will understand. But then we should configure bidirectional mutual replication because in Moscow can bring new partners too, and it is actually more difficult, than to have one data source and just to copy reference books on other servers.
Secret weapon – XDBStream
Therefore we went on the way of the unidirectional replication of reference books of the central server on regions (except Khabarovsk there is also Norilsk) by means of our XDBStream — the service allowing to make database replication. Replication happens at change of tables in base (adding/removal/editing record). For setup of replication it is necessary to specify "attributes" of access to bases and to state what fields in what tables it is required to synchronize.
XDBStream – not just some internal development, is the registered computer program (!), that is quite mature solution which we use in projects though we separately do not advance.
Khabarovsk – Moscow and back
We replicated cards of documents through web services. Logic here such: let's allow, the contractor in Khabarovsk decides to sign the agreement with certain OOO "Medved" on purchase of the dump truck in a pit. He creates the agreement and at first starts internal approval. How many and that passes circles, and as a result, the CEO of branch approves the agreement. After that, if the agreement exceeds some sum, conditionally telling 100 thousand, it is necessary to approve it with Moscow. What happens at this moment in system: the agreement on the local server passes into "technical condition", that is is blocked on any changes. Meanwhile web service which hangs on the central server periodically polls system – whether there are no new cards for me? As soon as such card appears, it together with the file of contents drags it to itself(himself). Thus, the agreement goes to Moscow. Further, in Moscow the process of approval is started.
Further in Moscow it goes on the cycle of approval. There is also other web service which shows to Khabarovsk what there in Moscow happens to their agreement – at whom is now what visas are imposed, etc. And when someone decides to send back the agreement for revision back to Khabarovsk, it in Moscow fades (passes into technical condition) and comes to life in Khabarovsk, going to a new circle of approval. Such situation can repeat several times, and at the same time from one system it is always visible data in another – where now there is agreement.
If to look from a technical aspect, then two independent systems the Thesis which are integrated by replication of reference books and this mechanism of transfer of agreements in the course of approval actually work. We developed this mechanism based on XDBStream especially for the Russian platinum. One more plus of such solution is that bases of documents on two servers are absolutely identical.
Accounting of time zones
Time difference between Moscow and Khabarovsk – 7 hours, and distance – 6 thousand kilometers. Normal work when business process progresses on the following step by means of personal talk of phone calls at such parameters becomes almost impossible. But also the automated system has to consider such parts that residents of Khabarovsk see everything in own way time, and Muscovites – in own way. And all terms in system are recalculated in the working days in a native time zone for the participant of business process. For example, in Khabarovsk sent the document for approval to the employee in Moscow – and there 2 o'clock in the morning. But the working day at it begins at 9 o'clock in the morning and even if on process there are three hours on approval of this document, the employee will receive it when he comes to work and control term will be 12 hours across Moscow. It is logical that to 5 o'clock in the morning nobody will approve the agreement.
It is good that we have a capital in the west of the country, and not vice versa! If the capital was in Khabarovsk and there all head offices would be placed, then in all large holdings excess day on approval would be lost.
It is necessary to be updated accurately
Everything on light is subject to changes, and software in particular. The customer will ask to add something, the pofiksila bug, some libraries need to be updated. When systems are so closely tied at each other one awkward movement can lead to unpleasant effects. Not necessarily fatal – just something will be mismatched and will cease to work. Therefore at operation of system in the distributed configuration it is necessary to take care of accurate procedures of execution of updates.
In our project configurations of both servers TEZIS – in Moscow and Khabarovsk – were identical as well as bases of documents. That to save this identity, updates roll at the same time. Not that absolutely synchronously, but in one day. At first it is necessary to stop all replications, then stop the Khabarovsk server, update it, then stop and update the Moscow server. When it it is finished, it is possible to start replication services again.
To this taiga only by airplane it is possible to reach …
From positions of normal city logic of managers and consultants, EDMS and other IT systems need to be brought to the most final contractor – effectively to automate business processes. Otherwise supposedly there is a gap – someone will run with paper documents or to drag files on flasks.
Also we decided to put workplaces directly on the field Kondyor, despite inaccessibility of this site and problem with communication. The Internet is only when the satellite flies by. And still bears therefore there people have other problems, except control of performing discipline periodically come into a change house :-)
But nevertheless, our EDMS TEZIS and in a taiga earned! At first via the terminal – the people were connected to the computer in Khabarovsk and worked, then, after expansion of the channel – began to be connected directly on the Khabarovsk server.
We change processes, without changing system
TEZIS it is operated in "The Russian platinum" since 2012, and during this time the customer did not demand serious changes – sometimes only asked to add a new field to a card or to change process.
Here it is necessary to tell about one cunning – in TEZIS there is a universal block of parallel-serial approval. It is possible just to put it in the designer of processes and to configure that in it there were some stages and some parallel and consecutive blocks. And if some internal regulations suddenly changed, or, for example, dismissed five people and the way of approval became quicker, it is enough to change settings in the designer of processes.
Thanks to this universality and flexibility of platform TEZIS it was succeeded to live three years without large completions though organizational changes at the customer happened.
IT and optimization of processes
In an ideal picture of the world system implementation of management of documents and business processes has to be followed by their essential optimization – disposal of paper, reduction of approvals, etc. In life so occurs not always, for organizational changes the will of the manual and pressure from competitors is necessary or the regulator.
Any IT system in itself cannot optimize in a magic way business process. IT specialists can just recommend to managers, but usually have no opportunity to insist therefore it is always so difficult to evaluate efficiency of implementation of EDMS and other similar systems. On the other hand, existence of EDMS increases corporate culture of work with documents and tasks, occasionally obviously highlights bottlenecks and as a result creates premises for productive work of consultants for management.
Integration with 1C – obligatory ability for a dokumentooborotchik
In Russia it is impossible to implement EDMS and never to face the requirement of integration with 1C. This competence – ability to work with 1C, perhaps, should be considered as one of basic at the choice and an assessment of the supplier of EDMS.
We did integration with 1C not once any more, including quite difficult projects, including problems of budgeting and management of material support.
The customer had several separate bases 1C: Khabarovsk, Moscow and Norilsk. Together with implementation the THESIS, there was a project on consolidation 1C therefore all bases integrated in one and cleared reference books. However made it not in one step, and for several iterations because of what we had to upload several times data from 1C in our system, in our reference books – and it is quite long procedure, several hours.
The task was to make so that from Khabarovsk 1C agreements in Moscow were not visible, and from the center all could see. At first we had an integration "all - with - all", local servers could communicate among themselves, and then passed to centralized. The agreement in 1C is actually, too the reference book, the table – from the point of view of EDMS. There is a table of partners, there is a table of agreements subordinated to it. Agreements and partners we bring at ourselves to EDMS and then we transfer them in 1C as master data.
As a result came to interaction with 1C in the point-to-point mode: the central base 1C in Moscow exchanges data with the THESIS server. And each of systems separately replicates reference books and documents on regional servers. It for us standard approach when EDMS acts as a source of master data on partners and agreements for accounting systems.
Communication channels improved – it is possible to centralize IT systems
Progress does not stand still – communication becomes quicker, more reliably and cheaper. It gives technical capability to pass from distributed system to centralized, business in management is farther.
A year ago "The Russian platinum" decided to refuse the Khabarovsk THESIS base and to transfer everything to the central server, but so far refused only the Montenegrin (Norilsk). Actually, it appeared simply as data in bases are identical. At some point we just extinguished the Norilsk server and redirected all users to Moscow. And there are already all their accounts, all documents, just on a desktop the web-link on the EDMS server exchanged, all working environment remained the same. Undoubtedly, queue also will reach Khabarovsk because generally, it is simpler to support the centralized system, than distributed.
If to take a certain hypothetical holding where there is a central node and ten regional, and on each regional node it is possible to hang up ten more organizations, then hundred organizations in all holding will turn out. You look then – the Moscow-Yekaterinburg channel improved. You take and just you "cut down" the local server, and all begin to work through the center. That is, we can begin implementation on the distributed configuration, and then pass to centralized, and without any alteration or completion of system.
We fill up a moneybox of knowledge
Each project bears with itself something new – new functions, new solutions, integration, etc. Often happens that some modules from the project turn on then in the main branch of a product, promoting its development. Or are just reused on other projects, reducing a development cycle and implementations.
If to speak about "The Russian platinum", then from this project the THESIS nothing entered basic delivery. However some practices managed to be used for the second time on other project on automation of the Samara branch "RN-Service". They had two divisions in Samara and several divisions in a hundred-kilometer zone and the same task – need of approval of documents of the central office. That they did to system implementation: collected signatures on the document, got into the car and went to Samara. There delivered papers to the lawyer, then went to "Auchan", stocked up on products, watched the city, took away the papers and returned. Total 200 km of a way and the whole working day for the sake of couple of signatures.
Though the Samara region not some backwoods, communication in a radius of hundred kilometers from the city after all is far not so good. Therefore in "RN-Service" we used the same scheme of approval of local servers as in "the Russian Platinum" – and frequent trips to the city did not become necessary.
- We learned to turn easily decentralized structure into centralized.
- Uniform reference books, management of NSI are surely necessary.
- Integration with 1C – must have. (Later we even made the standard module.)
- Optimization of processes – business acquirable. Let's at first people work as they got used.
This article is a translation of the original post at habrahabr.ru/post/270659/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: email@example.com.
We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.