October 1, 2014 at 14:21Is the company planning to introduce an EDMS? 10 recommendations for an IT professional
Good afternoon! My name is Michael. Having many years of experience in projects for the implementation of various automation systems (and document management, in particular), I often encounter with the fact that the company's unwillingness to implement a project at the very initial stage entails significant difficulties in its implementation. I would like to share my observations and give some recommendations to those who plan to implement document management systems. I could give a number of recommendations to integrator companies, but today I’ll focus on something else: what is worth paying special attention to the IT specialist on the part of the customer. Early identification of weaknesses (despite all their apparent obviousness) will help you avoid difficulties in the further implementation of the project.
I will cite a number of cases from my own practice (perhaps some readers will recognize themselves in the examples - but all coincidences are random!)
Very often, the IT directors of companies, the owner or senior management sets a task in the wording "I want electronic document management." I note that such a statement of the problem is quite correct, since the company's management has the right to set any tasks, and subordinates must solve them. Why the leadership wants this is often not voiced at all. Maybe they saw it from business partners, or maybe it really got enough to work with paper documents. In any case, the fact that the initial task very often arises on an emotional basis is a fact.
Recommend:try to isolate and solve precisely those key tasks that will be valuable to the business, do not try to “automate everything” at once, which is most likely utopian. Provide management with a step-by-step plan for the implementation of the project with the obligatory designation of specific tangible (possibly measurable) intermediate results.
Many believe that the workflow system will act as a wizard and organize all the processes itself. This is an erroneous opinion, since the system is just one of the means of streamlining and optimizing processes. In order to optimize something, the process itself must first exist. Before embarking on a project to introduce an electronic document management system, you need to make sure that this very process is ready for automation.
It is quite logical for implementation consultants to expect the application of their expert experience in organizing business processes, but you need to understand that this is a separate activity, in the general case, outside the framework of the project itself.
Recommend:recruit specialists for a pre-project survey of the company. Its result will be, at a minimum, proposals for organizing such a process model that would meet business objectives and be suitable for further automation. By the beginning of the survey, it is not at all necessary to choose one or another EDMS, it is just the requirements for it that can arise from the results of this zero stage.
In one of the organizations (with the number of employees more than 1000), we decided to just use the previous advice and start with a workflow survey. The IT director, with whom I had the honor of visiting specialists, was apprehensively knocking on each office and guiltyly asked the staff to allocate at least some time for a substantive conversation. Of the half of the offices he was simply politely (and sometimes not very) asked to leave and not to distract ... A situation that is completely not conducive to normal work.
Recommend:if you are the IT specialist responsible for the project at this stage - try to get official permission from the company’s management to carry out such work during business hours, notify employees in advance (by order or simply by letter). It would seem a trifle, but everyone will understand what is happening, and you will save time and effort.
As Napoleon said, “On s'engage et puis on voit”, that is, “get in, and we'll see.” Where Monsieur Bonaparte got involved, and what he saw there, is well known ...
A lot of projects failed due to the fact that at the time of their start, none of the parties understood what would be done within its framework. It is obvious that, without understanding the essence of the project, it is impossible to correctly evaluate and plan it. It is likely that you, as a customer, will express such requirements that the contractor simply cannot fulfill within the previously defined budget and timeframe. And everyone will be unhappy.
I recommend: it is possible to carry out the EDMS implementation project on the basis of framework agreements, but practice shows that even in this case, each “episode” should be clearly defined in its functional part.
I once conducted training for top managers of one of the largest Russian plants (scale - more than 5,000 employees). Serious men broke away from their main job for an hour. The natural excitement before showing the system to such an audience abruptly disappeared when the Leader in this organization with sincere admiration began to change the columns in the submissions on the documents ... Surprisingly, all his top colleagues were inspired, and subsequently the suspicious attitude towards the project was replaced by his active support.
I recommend: enlist the support of senior leaders. Then, believe me, the enthusiasm of the whole company in supporting and mastering the new system will grow.
6. “Everything will be as I said”
I once did a project in one fairly bureaucratic organization (about 500 users). The project took its normal course, experimental operation was carried out, nothing portended problems. Suddenly at one of the meetings we were introduced to a person who, on the part of the customer, will finally accept the work. After attentively watching the presentation of our system the next day, the distinguished customer representative was laconic - he handed us a maroon book entitled “Instructions for paperwork in company X” under his authorship and said that the system should work as it is written there, and nothing else . To say that the project team was in shock is to say nothing. In fact, the project was completed thanks to pure luck (namely, the transfer of the mentioned colleague to another job).
Recommend: not so much to the IT director as the head of the organization: if you want the project to be successful, you should not introduce new figures into it, especially at the final stages, even if they have tremendous experience in the subject area.
In almost half of the cases at pre-project meetings, customer representatives say that the management of their companies will definitely work in the system, fill out documents, issue orders, etc. The key mistake here may be that the entire system will be designed on the basis that managers really work in the system fully. It often turns out that managers simply do not have time to carry out all the functions planned for them.
I recommend: prepare a description of specific cases of using the system by your manager with a choice of specific ways to work with it and receive confirmation from the manager.
All parties to the project, of course, would like the requirements for the functionality of the created electronic document management system to be unchanged. But miracles do not happen, and even with the most high-quality pre-project examination, moments will surely come out that everyone will say “we did not assume that this could happen”. In my practice, there was even a case when during the project the automated unit was simply liquidated ... But now I already understand that it is not the units that need to be automated, but the business processes.
I recommend: to form an understanding with your team that change is a normal situation, which you need to respond to correctly, finding a mutually acceptable solution.
As part of the project, as a rule, user training is provided. Often, many users for the first time learn that a new system is being introduced, directly during training. It is clear that most of the students were not included in the design team on the part of the customer, and therefore did not participate in the process of forming requirements. Here the key role is assigned to the project manager by the customer. There were times when I was alone in front of a perplexed audience, and the discussions that arose translated training into another unconstructive discussion about the functional content of the system.
Recommend: it will be good if it is the IT specialist of the client company that will properly configure and prepare students for training, talk about why the system was made in this way, and not otherwise, what was the procedure for making certain design decisions.
Of course, the opinions of all employees are valuable for the project, but the degree of possible participation in the project does not always coincide with its needs. It happens that specific mid-level managers refuse in principle to talk about any automation with the participation of its employees, despite direct orders from senior management. Here you need to show wisdom - if you do not want, then do not. It is much more profitable to select a few people interested in the results in the project team than anyone who can (even theoretically) benefit him.
Actually, in one project this happened. One of the units had to be completely excluded from the automation circuit. After the end of the project, there was only one question from them: “What about us ?!”
Recommend:even at the stage of formation of the project team by the customer, it is important to choose its composition correctly.
Of course, there can be much more recommendations, but first I highlighted the situations that are most common and have a strong impact on the project and its results. If you need advice on organizing competent preparation for an EDMS implementation project, you know who to contact!
I will cite a number of cases from my own practice (perhaps some readers will recognize themselves in the examples - but all coincidences are random!)
1. “Automate us“ everything ”
Very often, the IT directors of companies, the owner or senior management sets a task in the wording "I want electronic document management." I note that such a statement of the problem is quite correct, since the company's management has the right to set any tasks, and subordinates must solve them. Why the leadership wants this is often not voiced at all. Maybe they saw it from business partners, or maybe it really got enough to work with paper documents. In any case, the fact that the initial task very often arises on an emotional basis is a fact.
Recommend:try to isolate and solve precisely those key tasks that will be valuable to the business, do not try to “automate everything” at once, which is most likely utopian. Provide management with a step-by-step plan for the implementation of the project with the obligatory designation of specific tangible (possibly measurable) intermediate results.
2. “We don’t know how to organize the workflow”
Many believe that the workflow system will act as a wizard and organize all the processes itself. This is an erroneous opinion, since the system is just one of the means of streamlining and optimizing processes. In order to optimize something, the process itself must first exist. Before embarking on a project to introduce an electronic document management system, you need to make sure that this very process is ready for automation.
It is quite logical for implementation consultants to expect the application of their expert experience in organizing business processes, but you need to understand that this is a separate activity, in the general case, outside the framework of the project itself.
Recommend:recruit specialists for a pre-project survey of the company. Its result will be, at a minimum, proposals for organizing such a process model that would meet business objectives and be suitable for further automation. By the beginning of the survey, it is not at all necessary to choose one or another EDMS, it is just the requirements for it that can arise from the results of this zero stage.
3. “Implement, I have an hour”
In one of the organizations (with the number of employees more than 1000), we decided to just use the previous advice and start with a workflow survey. The IT director, with whom I had the honor of visiting specialists, was apprehensively knocking on each office and guiltyly asked the staff to allocate at least some time for a substantive conversation. Of the half of the offices he was simply politely (and sometimes not very) asked to leave and not to distract ... A situation that is completely not conducive to normal work.
Recommend:if you are the IT specialist responsible for the project at this stage - try to get official permission from the company’s management to carry out such work during business hours, notify employees in advance (by order or simply by letter). It would seem a trifle, but everyone will understand what is happening, and you will save time and effort.
4. “Let's figure out what to do during the project, they are professionals!”
As Napoleon said, “On s'engage et puis on voit”, that is, “get in, and we'll see.” Where Monsieur Bonaparte got involved, and what he saw there, is well known ...
A lot of projects failed due to the fact that at the time of their start, none of the parties understood what would be done within its framework. It is obvious that, without understanding the essence of the project, it is impossible to correctly evaluate and plan it. It is likely that you, as a customer, will express such requirements that the contractor simply cannot fulfill within the previously defined budget and timeframe. And everyone will be unhappy.
I recommend: it is possible to carry out the EDMS implementation project on the basis of framework agreements, but practice shows that even in this case, each “episode” should be clearly defined in its functional part.
5. "WOW, you can rearrange the columns in places!"
I once conducted training for top managers of one of the largest Russian plants (scale - more than 5,000 employees). Serious men broke away from their main job for an hour. The natural excitement before showing the system to such an audience abruptly disappeared when the Leader in this organization with sincere admiration began to change the columns in the submissions on the documents ... Surprisingly, all his top colleagues were inspired, and subsequently the suspicious attitude towards the project was replaced by his active support.
I recommend: enlist the support of senior leaders. Then, believe me, the enthusiasm of the whole company in supporting and mastering the new system will grow.
6. “Everything will be as I said”
I once did a project in one fairly bureaucratic organization (about 500 users). The project took its normal course, experimental operation was carried out, nothing portended problems. Suddenly at one of the meetings we were introduced to a person who, on the part of the customer, will finally accept the work. After attentively watching the presentation of our system the next day, the distinguished customer representative was laconic - he handed us a maroon book entitled “Instructions for paperwork in company X” under his authorship and said that the system should work as it is written there, and nothing else . To say that the project team was in shock is to say nothing. In fact, the project was completed thanks to pure luck (namely, the transfer of the mentioned colleague to another job).
Recommend: not so much to the IT director as the head of the organization: if you want the project to be successful, you should not introduce new figures into it, especially at the final stages, even if they have tremendous experience in the subject area.
7. “The director will create documents in the system himself”
In almost half of the cases at pre-project meetings, customer representatives say that the management of their companies will definitely work in the system, fill out documents, issue orders, etc. The key mistake here may be that the entire system will be designed on the basis that managers really work in the system fully. It often turns out that managers simply do not have time to carry out all the functions planned for them.
I recommend: prepare a description of specific cases of using the system by your manager with a choice of specific ways to work with it and receive confirmation from the manager.
8. "However, during the journey, the dog could grow up!"
All parties to the project, of course, would like the requirements for the functionality of the created electronic document management system to be unchanged. But miracles do not happen, and even with the most high-quality pre-project examination, moments will surely come out that everyone will say “we did not assume that this could happen”. In my practice, there was even a case when during the project the automated unit was simply liquidated ... But now I already understand that it is not the units that need to be automated, but the business processes.
I recommend: to form an understanding with your team that change is a normal situation, which you need to respond to correctly, finding a mutually acceptable solution.
9. “Everything is completely wrong! Where did you get this? ”
As part of the project, as a rule, user training is provided. Often, many users for the first time learn that a new system is being introduced, directly during training. It is clear that most of the students were not included in the design team on the part of the customer, and therefore did not participate in the process of forming requirements. Here the key role is assigned to the project manager by the customer. There were times when I was alone in front of a perplexed audience, and the discussions that arose translated training into another unconstructive discussion about the functional content of the system.
Recommend: it will be good if it is the IT specialist of the client company that will properly configure and prepare students for training, talk about why the system was made in this way, and not otherwise, what was the procedure for making certain design decisions.
10. "Do not fit - it will kill!"
Of course, the opinions of all employees are valuable for the project, but the degree of possible participation in the project does not always coincide with its needs. It happens that specific mid-level managers refuse in principle to talk about any automation with the participation of its employees, despite direct orders from senior management. Here you need to show wisdom - if you do not want, then do not. It is much more profitable to select a few people interested in the results in the project team than anyone who can (even theoretically) benefit him.
Actually, in one project this happened. One of the units had to be completely excluded from the automation circuit. After the end of the project, there was only one question from them: “What about us ?!”
Recommend:even at the stage of formation of the project team by the customer, it is important to choose its composition correctly.
Of course, there can be much more recommendations, but first I highlighted the situations that are most common and have a strong impact on the project and its results. If you need advice on organizing competent preparation for an EDMS implementation project, you know who to contact!