Good afternoon, my name is Sergey and I am the head of the product line at DoxVision. During my work in the field of automation of electronic document management, I had the opportunity to participate in dozens of implementation projects, and in different roles (from an engineer to the head of the project office), from different sides (customer, representative of the implementation company, vendor) and with different systems (Docsvision and Directum ). I want to share my project experience with you.

Knowing the process and stuffing a bunch of cones, I give a few recommendations in the article that will allow you to approach the implementation project of the SED (like any IT system) prepared and more smoothly implement it. My colleague has already given advice to the customer's IT specialists responsible for implementation. I will look at the question from a different angle and share a number of nuances that the integrator company should take into account. Especially if you have a first implementation project. I hope the article will be useful, although many “rakes” still need to be attacked sometimes independently, and there are no ideal recipes in design practice.

On your marks…

And we will not start with the project, we will begin with what comes to the project - discussing the details with the client, preparing the proposal and concluding the contract. There are already many things to pay attention to, because This is the first mortgaged brick, which can then affect the stability of the entire building.

"And they promised me ..."
One of the most common big mistakes at the stage of discussing a project with a client, before entering into a contract (especially common with large integrators) is the absence of a future project manager. Without him, there are some agreements (of which he will learn, well, if not at the end of the project), a different interpretation of the tasks and goals of the project, etc. When it pops up, the customer starts to beat his fists on the table and say that he was promised ... There can be no promises in fact, but if the project manager was absent during the discussion, then he would not be able to understand these agreements or not.

I had several such cases. Once in a large company N, where I did, in fact, a pilot project on a ready-made box solution, the CIO suddenly decided that we would put a “box” on it, but we would do a big custom project on it, because that's what "Agreed". The fact that the price of custom development is many times more is not embarrassing. In this and similar cases, if it was not possible to convince the customer on my own (and often it turned out that way), I simply arranged a confrontation, leading the one who “agreed”. The main thing - not to give up the slack, and to the last to defend their position.

Team of our youth
Another important issue is the formation of the project team. Not so much in terms of the selection of people (this is also important, but here is not about that), as for presenting the team to the customer and getting to know his team. As a rule, it is enough to submit teams in absentia. A document should appear describing who is doing what from both sides. General recommendation: do not hesitate to make and sign all sorts of papers with the responsible representatives of the customer, at some point it can greatly help you.
')
A plan is a simple thing ...
Another "on the shore" is important to agree on the composition of the work. Of course, this is not about the detailed system requirements, but about the high-level list of design works. In one of the projects, I came up with about this schedule:



An experienced person, most likely, he will cause only questions. If not immediately, then later, you will begin to explain why the laboriousness of the work is 200 hours, while the project team has 1 person, why you will not hold any meeting with the users of the system, etc.
No one needs these labor-intensiveness, the cost of the project is already known, here this information only suggests ... The work plan at this stage should reflect the most detailed scope of work (high-level list) and the main stages of the project with reference to dates, for example:



Faster. Above. Stronger
Even before the start of the project, you need to clearly discuss and fix goals and objectives, this may affect all future work. For example, to speed up the process of negotiating contracts and make this process transparent are completely different goals, and if the goal is simply to “automate”, then 100,500 such as these two can be understood. Having misunderstood the customer's expectations, you can seriously overshoot with an assessment of the entire project and, ultimately, it will become unprofitable ... well, if the customer is satisfied. Be sure to detail too general goals, get to the bottom of it.

“Was there a boy?”
At the very beginning, you need to know the exact answer to the question: “Is there anything to automate?” Most likely, you will know about it yourself when they say: “We want to implement the SED, and at the same time optimize our internal processes.” Often heard this? While internal processes are not optimized - you have nothing to do there, unless, of course, the first stage of the project is consulting. No wonder there is a common expression “it is impossible to automate chaos” - automation goes only after optimization. If the customer wants to do such things in parallel, then this should be a disturbing bell for you, meaning that you need to be very careful about the process of organizing the project. Looking back now, I would not have become involved in such a project, especially if it were one of my first.

I had one sad experience associated with this issue. It was a matter of a large company Z and at the start of the project an installation was given that it was necessary to optimize the processes at the same time ... At the same time, everything was greatly complicated by the lack of a decision maker (this was about the project team and the responsibilities / responsibilities of its members). But more on that later.

"Once upon a time in the cold winter time…"
... we conducted interviews with users in a large company Y and entered the office of the security department ... We left there, collecting the requirements of the system, as well as with great chances to complete the project. Security officials expressed doubts that the system, and our company, met their security requirements, and generally stated that nobody had asked them.
What is it for me? Think carefully about whom the project may affect, go to them in advance and discuss all controversial issues. In the end, everything worked out for me, the issue was resolved, the system met all the requirements, and we continued to work, but everything could be worse.

Who needs all this ...
Often you have to deal with the fact that most users perceive your system as something imposed on them for some reason. At first, I was very surprised by this, because before, introducing accounting systems, I never met with this (but not surprisingly, because for accountants, the system is the main working tool, without it, they will not be able to work in principle). It would seem that this, but in the end the case could end in sabotage.
To avoid such problems, it is advisable to enlist the support of top management, or, at a minimum, the beginning of the project should be accompanied by the issuance of an order for the company, which will indicate what is being introduced and why, who is obliged to participate in this process and what to answer for.
It’s great if we manage to do some kind of campaign work, during which it is correct to convey the goals and objectives of the project to the end users - to explain to them what they will get in the end, and why they need it. You will be able to enlist the support of at least the heads of departments - you reduce the number of problems for yourself.
Of course, there are cases when none of this is possible, then all you can count on is the skill of the project manager. As I said above - do not hesitate to sign pieces of paper, any change must be agreed and recorded on paper, in a difficult moment it can save the project.

Getting started…

As a rule, the introduction of the SED begins with the design stage, at which a detailed technical task for the future system is prepared and agreed. Perhaps this is the least problematic stage, because you are not forcing the customer to work with what happened, but when this moment comes, then the problems begin.
They are connected, as a rule, with the fact that the customer sees the result either during training, or already at the stage of trial operation, and sometimes in general, when the system is launched into permanent operation. Prior to that, everything was only on paper, but the letters are one thing, and megabytes are another.

What is it worth thinking about?
Conduct introductory training at the initial stage of system design. Show key users, a project group (these are users acting as experts and forming the composition of the system requirements) system, its main interfaces, capabilities, basic work scenarios, customization capabilities.
But this is not enough.

In one of the projects I was faced with the fact that the contractor, having done this, decided that everyone now perfectly knows the product, and then the process can be greatly simplified. In particular, the entire technical task was a description of the changes (settings) regarding what was demonstrated. I do not recommend it, because by holding such an event, you just (and it depends on the quality of the event and the people) will try to find a common language with the users in order to understand each other in the future. This is not a panacea, do not be mistaken and think that after a week one of them will remember something.

More user interface. The practice described in the previous paragraph for large implementations may not reach its goal at all. It would be right to simply communicate more closely with users in the process: To hold small demonstrations, showing and discussing everything visually and in “pictures” rather than “letters”, apply prototyping (this allows systems with advanced interface customization tools, such as Docsvision, allow you to create an interface without any programming), and, of course, write a full technical task.

Technical task: to make detailed descriptions "for all." In addition to the above, there is another recommendation regarding the design of the TOR. The thing is, of course, purely individual, each writes in its own way, according to the standards and rules adopted by the company, according to GOST, etc., but it is not important how, but what is written. Since very often this document is agreed upon by ordinary users (clerk, for example), it may be a mistake to write it in a technical language. The settings and configurations of the system described in such a document may be coordinated, but certainly not understanding what exactly was agreed upon. There is a practice to explicitly identify and describe 2 blocks: the first is a description of work scenarios, i.e. who, what and how will do in the system. The second is a description of the settings.

Think about who and how will continue to support the system . The more standard functionality of the selected platform and its standard configuration tools are used, the greater part of all settings the customer will be able to maintain, the cheaper and simpler this support will be for him. When you are asked for this or that revision, convey this thought, finding out at the same time what particular economic effect the customer expects to receive from this additional checkbox. Comparing the two numbers, he is likely to refuse.

As promised above, I will tell you what can happen at this stage if the customer simultaneously with the implementation wants to optimize their internal processes. So, a large company X, we introduce the SED, and at the same time we alter the internal processes that affect almost all departments. I’ll say right away that this project brought together most of the “wrong,” in my opinion, contractor behavior, which I write about in this article, but something else became decisive. A project working group was formed, responsible persons were appointed, and even an order was issued for the company, but this working group lacked one thing - the decision maker. More precisely, it was formal, but due to high employment it was not always present at the endless meetings devoted to the requirements for the system, and it seemed really endless: we had the same questions many times, in the process we thought of ways to simplify everything, and , on the contrary, to complicate, but as soon as it was necessary to approve something, everyone washed their hands. We tried to formulate the thesis, which we agreed on, and agree on it, but when it turned into a technical task or a meeting was held to discuss related processes, everything could change radically again.

In order to somehow stop this process, I was running after the decision maker, trying to get this decision or call it to the next meeting. This helped, of course, but it turned out to be not the fastest option, it all dragged out. I did not start an official correspondence between the contractor and the company, since everything took place in a fairly friendly atmosphere and no sanctions were foreseen, while the opposite could have led to a deterioration of relations.

I will give everyone the opportunity to think about what could be done in this situation.

Such behavior, when no one wants to take responsibility for decisions, is characteristic of few organizations, but it does occur, and we must be ready for this. Fix the decision maker on the part of the customer in the contract, if possible, negotiate the terms of coordination, it disciplines the customer at least a little and minimizes your risks on the project.

Somewhere in the middle of the road ...

After completion of the design work follows the system design phase. Here I can advise only one thing: do not turn this stage into a “black box”. I had to work with contractors who consider that it is quite normal after agreeing on a technical task to leave for a month and appear with a ready-made system in order to train users and launch it into trial operation. Most often this ends in failure.

Honestly, at first I myself often did this, or almost so (we did one preliminary demonstration during the work).

Once in a large company Z, I ran into a user who wanted the SED to sign orders for him, etc., almost to the bread shop, she had to run at his will. During the interview, we explained about something we agreed on what and how it would work, but when he agreed on the document, questions again appeared. This employee held a fairly high position and could have a strong influence on the project.

Looking at what is happening, the IT director of this company gave one simple piece of advice. This was not even advice, he insisted: you need to meet with users more often, discuss, make sure everyone understands, hold demonstrations, users need to know us, so that if you ask someone who implements EDS, everyone said: Yes, running around here alone. Sergey call. "

So we did, despite the fact that I resisted, because such work was not planned and increased the cost of the project, reducing its profitability. But I am grateful for this advice - in the end it was only thanks to this that I managed to pass the project. With this user, we could not finally agree on what he needed, but we secured the support of everyone else, including the general director.

Here, before, I mostly talked about the users of the future system, but do not forget about the IT specialists of the customer - a properly built relationship with them will also play a significant role. Think about the role they play - they prepare the hardware for your system, they ensure the operation of the entire infrastructure, carry out technical training for all activities such as training or trial operation, provide user support and much more.

We built, built ...

Finally, everything is agreed, set up, put in, it's time to conduct training and launch the system into trial operation. Here you are most likely to encounter the question: on what data to carry it out - to launch and process real documents or test documents? Perhaps real, but in parallel to process them in paper form? The only correct answer is no, but there is something to think about.

If you select test documents , users will treat them as something optional, as something where you have to press a button, just to get behind. Where it leads? Most likely, to anything good, but the fact that something does not work or does not work quite so, you will find out after the launch into constant operation. The consequences, I think, are clear.

If we talk about real documents , there is no previous problem, but a situation is possible when something went wrong, affected the company's document flow and led to some consequences. You will not be patted on the head for this, therefore, when choosing such an option, you need to be alert and, if something fails, immediately respond.

The variant with parallel processing of documents in the system in test mode and on paper also has the right to life, but not everyone agrees on it, and end users, as a rule, protest, because they have to do double work.
For me, you need to choose some intermediate option: for example, use real documents, but clearly define the boundaries - limit the types of documents, do not run urgent, etc. In any case, this is something that you should think about at the beginning and agree in advance on how it will be organized.

As for user training , a very effective way was shown by the option when users simply imitate real work in the system under themselves, rather than under abstract “training” users, launching processes and going through them completely from beginning to end. In this case, you can not even give any theoretical part or minimize it. Users can either be in the classroom or simply work in their places. The latter, however, will not be very convenient for the teacher, since he will have to run from user to user after the document.
This method is not always suitable and can not always be organized, but if it turns out, the return will most likely be higher than other options, try it!

You can still talk about what you can face. I filled a lot of cones, I just don’t remember everything. Much depends on the scale of implementation, on the scope of the organization and other factors. But the main thing is not this and not the platform that is being introduced (I can say with confidence that there are no significant differences in functionality among those I encountered, but if I were now offered to choose what to implement, I would choose Docsvision) , and properly organized implementation process.

I wonder who else had to deal with, let's expand the list and share experiences. I wish you all good luck in the projects!