Knowing process and having typed a lot of cones, I make in article several recommendations which will allow to approach the project of implementation of EDMS (as well as any IT system) prepared and more smoothly to implement it. My colleague already gave advice to the customer's IT specialists responsible for implementation. I will look at a question from a different angle and I will share a number of nuances which it should be taken into account the companies integrators. Especially, if the first project of implementation is necessary to you. I hope, article will be useful though it is all the same necessary to step on many "rake" sometimes independently, and ideal recipes in project practice do not exist.
On start …
And we will begin not with the project, we will begin with what goes to the project – discussion with the client of parts, preparation of the sentence and the conclusion of the agreement. Already there are a lot of things on what it is necessary to pay to attention since it is the first mortgaged brick which can exert then impact on stability of all building.
"And me promised …"
One of widespread big errors at a stage of discussion of the project with the client, to the conclusion of the agreement (especially often occurs at large integrators) — absence of the Head of future project. Without it there are some arrangements (about which he learns, it is good if not at the end of the project), different treatment of tasks and purposes of the project, etc. When it emerges, the customer begins to beat with fists a table and to say what to it was promised … Any promises can actually and not to be, but if the project manager at discussion was absent, then to understand, there were these arrangements or not – he will not be able any more.
I had several such cases. Once in the large company N where I did, in fact, the pilot project on a ready box solution, the Chief information officer suddenly decided that we will put "box", but we will do on it the big custom project because "agreed" about it. The fact that the price of custom development many times is more – it did not confuse. In it and similar cases if it was not possible to convince the customer by own efforts (and often so it turned out), I just suited a confrontation, bringing the one who "agreed". The main thing – not to give a weak point, and to the last to uphold the position.
Command of our youth
One more important issue – forming of command of the project. Not so much in respect of selection of people (it is important too, but here not about it), how many for representation of command to the customer and acquaintance to its command. As a rule, it is quite enough to provide commands in absentia. There has to be a document describing who and in what is engaged on both sides. General recommendation: do not hesitate to do and sign any pieces of paper with responsible representatives of the customer, at some point it can help you very strongly.
The plan is a subject simple …
Still "ashore" it is important to agree about structure of works. Of course, the speech not about detailed requirements to system, and about the top level list of project works. In one of projects I faced approximately such planned schedule:
At the experienced person, most likely, he will raise only questions. If not at once, then then, and you begin to explain why labor input of works of 200 hours while in command of the project 1 person why you will not hold any meeting with users of system, etc.
These labor inputs are necessary to nobody, the cost of the project is already known, here this information only suggests an idea …. The plan of works has to reflect the most detailed structure of works (the top level list) and the main stages of the project with a binding to dates in this stage, for example, so:
Quicker. Above. Stronger
Before the project it is necessary to discuss and record accurately the purposes and tasks, it can influence all further work. For example, to accelerate process of approval of agreements and to make this process transparent are absolutely different purposes and if it is simple "to automate" the purpose then can be understood 100500 such as these two. Having misunderstood expectations of the customer, you can seriously miss with an assessment of all project and, eventually, it unprofitable … it will become good still if at the same time the customer is satisfied. Surely detail too common goals, get to the bottom of an essence.
"And whether there was a boy?"
Right at the beginning it is necessary to know the answer to a question precisely: "And whether is what to automate?" Most likely, you learn about it when you are told: "We want to implement EDMS, and at the same time to optimize our internal processes". Often heard it? Until internal processes are optimized – you have nothing to do there if, of course, the first stage of the project is not consulting. Not without reason there is an ordinary expression "it is impossible to automate chaos" — automation goes only after optimization. If the customer wants to do such things in parallel, then it has to be the disturbing call for you meaning that it is necessary to approach process of the organization of the project extremely attentively. Now, looking back, I would not begin to be got involved in such project, especially any more if it was one of my the first.
I had one bitter experience connected just with this question. Business was in the large company Z and on start of the project installation was given that it is necessary to optimize processes at the same time … At the same time everything strongly was complicated by absence at the customer of the person making decisions (it to a question of command of the project and responsibility/duties of her members). But is more detailed about it is later.
"Once, during an ice cold winter time …"
… we conducted interview of users in the large company Y and came into an office of department of safety … We left it, having collected requirements of system, and also with good chances on it to finish the project. Representatives of a security police dropped a hint of doubt that the system and our company, conforms to their safety requirements, and in general declared that nobody asked them.
To what it I. Think attentively whom the project can mention, in advance you descend to them and discuss all controversial issues. At me as a result everything managed, the question was resolved, the system conformed to all requirements, and we continued work, but everything could be worse.
Who needs all this …
Often it is necessary to face that most of users perceives your system as something, imposed to them it is unclear for what. First I very much was surprised to it, earlier, implementing systems of accounting, never met it (but also it is not surprising, for accountants system – the main working tool, without it they in principle will not be able to work). It would seem that it, and as a result business can end with sabotage.
To avoid similar problems, it is desirable to get support of top management, or, at least, the beginning of the project has to be followed by release of the order on the company in which it will be specified as why is implemented who is obliged to participate in this process and what to be responsible for.
It is healthy if it is possible to carry out any propaganda work during which it is correct to inform of the purposes and tasks of the project ultimate users – to explain to them what they will receive as a result and why it is necessary for them. You will be able to get support at least of heads of divisions — you to yourself reduce quantity of problems.
Of course, there are cases when nothing from this is impossible, then all you can expect – skill of the project manager. As I already spoke above – do not hesitate to sign pieces of paper, any change has to be approved and recorded on paper, a heavy minute it can rescue the project.
We begin …
As a rule, implementation of EDMS begins with a design stage at which the detailed specification on future system prepares and will be approved. Perhaps, it is the least problem stage, you do not force the customer to work with what turned out yet, and here when this moment comes — then problems and begin.
They are connected, as a rule, with the fact that the customer sees result or on training, or already at a stage of trial operation, and sometimes and in general – at start of system in permanent operation. Before everything was only on paper, but letters are one, and megabytes – absolutely another.
What it is worth thinking here of?
To provide input training at an initial design stage of system. To show to key users, group of the project (these are the users acting as experts and creating structure of requirements to system) system, its main interfaces, opportunities, basic scenarios of work, a possibility of customization.
But it is not enough.
In one of projects I faced that the contractor, having made it, decided that all perfectly know now a product, and further process can be simplified strongly. In particular, all specification was the description of changes (settings) concerning what was shown. I do not recommend to do so, holding such event, you only (and that it depends on quality of carrying out and people) will try to find a common language with users further to understand each other. It is not panacea, you should not be mistaken and think that a week later someone from them will remember something.
It is more than interface for users. The practice described in the previous point for large implementations can not achieve the goal at all. Correct will communicate just more densely with users in process: To carry out small demonstrations, demonstrating and discussing everything and on "pictures", but not on "letters", to apply prototyping (it systems with the developed instruments of setup of interfaces, as, for example, Docsvision allowing to create the interface without any programming allow), well and, of course, to write the full specification.
Specification: to make detailed descriptions "for all". In addition to the aforesaid there is one more recommendation concerning a design of TZ. A thing, of course, especially individual, everyone writes in own way, according to the standards and rules admitted to the companies, in accordance with GOST, etc., but it is important not as and what is written. As very often this document will be approved by simple users (the clerk, for example), its writing in technical language can become an error. The settings described in such document and system configurations, maybe, will also approve, but definitely without understanding what was approved. There is a practice explicitly to select and describe 2 blocks: the first — the description of scenarios of work i.e. who, as as will do in system. The second – already the description of settings.
Think of the one who and as will perform further support of system. The more standard functionality of the selected platform and its regular customizers is used, the customer will be able to support the most part of all settings, the this support will be cheaper and simpler for him. When you are asked this or that completion, inform of this thought, having found out at the same time what specifically economic effect expects to receive the customer from this additional flazhochk. Having compared two digits, he, most likely, will refuse.
As promised above, I will tell what can happen at this stage if the customer along with implementation wants to optimize the internal processes. So, the large company X, we implement EDMS, and at the same time we redo internal processes which affect almost all divisions. At once I will tell that this project collected the most part of the "wrong", in my opinion, behavior of the contractor about which I write in this article, but another became decisive. The working group of the project was created, are assigned responsible, and even the order on the company is issued, but in this working group there was not enough one – the person making decisions. More precisely, formally it was, but owing to high employment was not always present at the infinite meetings devoted to requirements to system, and it seemed really infinite: we procrastinated the same questions on many times, methods everything were on the run thought out to simplify, and sometimes, on the contrary, to complicate, but as soon as it was necessary to approve something, all washed hands. We tried to formulate briefly what we agreed about and to approve it, but when it turned into the specification or meeting for discussion of the connected processes gathered, everything could exchange in a root again.I will give the chance to everyone to think what could be made in this situation.
Somehow to stop this process, I ran behind that LPR, trying this solution to receive or cause it on the next meeting. It helped, of course, but it was not the fastest option, everything strongly stretched. To start official correspondence between the contractor and the company I did not become as everything passed in quite friendly situation and no sanctions were expected while the return could cause deterioration in the relations.
Such behavior when nobody wants to take the responsibility for solutions, is peculiar to the few organizations, but meets, and to it it is necessary to be ready. Record LPR from the customer in the agreement, whenever possible stipulate approval terms, it though disciplines the customer a little and minimizes your risks on the project.
Somewhere on the middle of a way …
After completion of works on design the development stage of system follows. Here I can advise only one: do not turn this stage into "a black box". I had to work with contractors who consider that quite normally after approval of the specification to leave for a month and to appear with ready system already to train users and to bring it into trial operation. Most often it comes to an end with failure.
Frankly speaking, first I often so did, well or almost so (we after all did one preliminary demonstration in work flow).
Once in the large company Z I faced the user who wanted that EDMS itself painted for him instructions, etc., nearly in shop behind bread she had to run at his desire. During interview we explained, agreed about something as as will work, but when he approved the document, questions appeared again. This employee held rather high position and could exert strong impact on the project.Looking at what occurs, the Chief information officer of this company gave one simple advice. Even not council was, it insisted: to meet with users more often more often, to discuss, be convinced of what all equally understand, to hold demonstrations, users have to know us that if to ask someone who to you implements EDMS, told everyone: "Yes one runs here. To call Sergey."
So we also made in spite of the fact that I resisted, similar works were not planned and increased project cost, reducing its profitability. But I am grateful for this council — as a result only thanks to it and it was succeeded to hand over the project. With this user it is final to agree that it is necessary for him, we could not, but got support of all others, including the CEO.
Here earlier I generally spoke about users of future system, but do not forget and about the customer's IT specialists – correctly constructed relationship with them will play a considerable role too. Reflect what role they play – they prepare iron for your system, they provide operability of all infrastructure, perform technical training of all actions like training or trial operation, perform user support and many other things.
We built, built …
At last, everything is approved, configured, handed over, it is time to provide training and to bring system into trial operation. Here you, most likely, will face a question: on what data to carry out it – to start and process real documents or test? Perhaps, real, but parallel to a message their processing in paper form? Only there is no correct answer, but is over what to think.
If to select test documents, then users will be treats them as to something optional, as to something where it is necessary to click if only lagged behind. What it will lead to? Most likely, to anything good, and to what that something does not work or works not absolutely so you learn after start in permanent operation. Effects, I think, are clear.
If to speak about real documents, then there is no previous problem, but the situation when something went not so is possible, influenced document flow of the company and led to some effects. On the head you for it will not be stroked therefore at the choice of such option, it is necessary to be alert and if something sboynut, instantly to react.
The option with parallel processing of documents in system in the test mode and on paper has the right to life, but to it too not all agree and ultimate users as they should do double work protest, as a rule.
On me it is so necessary to select some intermediate option: for example, to use real documents, but to accurately define borders – to limit types of documents, not to start urgent, etc. Anyway, is what once you think at the beginning of and in advance to agree, it will be organized.
As for user training, the option when users just imitate real work in system under themselves, but not under abstract "educational" users very efficiently proved to be, starting processes and passing them completely from beginning to end. At the same time it is even possible not to give any theoretical part or to minimize it. Users can how to be in an educational class, and just to work at the places. The last will be, however, not really convenient for the teacher as he should run from the user to the user after the document.
Such method not always approaches and can be not always organized, but if it turns out, return will be, most likely above, than at other options, try!
It is possible to speak about what it is possible to face for a long time. I typed many cones, and will already not remember all. A lot of things depend on implementation scale, on a field of activity of the organization and other factors. But the main thing not it and not a platform which is implemented (I can tell with confidence that among what I faced there are no essential differences in functionality, but if to me suggested to select now what to implement, I would select Docsvision), and correctly organized process of implementation.
Interestingly, who what had more to face, let's expand the list and we will exchange experience. I wish all good luck in projects!
This article is a translation of the original post at habrahabr.ru/post/265185/
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: firstname.lastname@example.org.
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.