I have many years of experience in deployment and subsequent maintenance of information systems in companies of all sizes. In most cases, the expected result from the deployment of information systems has been obtained. In this article, I want to show the main reasons that do not allow obtaining the expected effect of the information system deployment.

The first reason and perhaps the most important: an incorrectly set goal to information system implementation. This is one of the major issues for any project not only for the implementation of the information system, but also any other one. Often as a target for information systems implementation is selecting target, which is not related to the information system or depend on it slightly. For example, the increase in sales activity, greater market share, creating a different culture of enterprise management, etc. Information system bears not much relation to it. If a company manufactures a product for which demand falls, how can help information system? In this situation, the marketing department should resolve the problem. If you need to change the culture of the enterprise management, it is a matter of personnel management and the CEO. But some people hold out a hope that as soon as money is paid for the information system, then all problems associated with business management go away by themselves without any effort, especially if a system is expensive, foreign-made, repeatedly tested and under statements of sellers built on "the world's best business practices". The similar purposes are not related directly to information system. If the company has inefficient management style, it will remain ineffective, only this time with a management information system. If demand for your products has fallen, it does not change. However, information system will allow you quickly and accurately calculate the losses, including from its deployment. Therefore, the correctly set goal of information system deployment is the key to success of its deployment. Good target for the system is information processing, such as storage, retrieval and processing of various information, any problems associated with the calculations, grouping, analysis of available information, and consequently, these processes will require less time. One has only to remember that the acceleration of inefficient processes can lead to even more inefficient general result in the company than it was before the deployment of the system. A clear idea of what needs to be done - this is the main key to success in the deployment of information system. One of the recent cases from my experience of negotiations with the customer: customer wants to change the product configuration system, hoping that it will order production process and coordination departments. According to him, the new system should provide only a limited selection of available product options; thereby producing and coordination departments will be easier to work using more solutions that are standard. The customer already has a configurator. Immediately the question arose, why do change it? The answer is awesome, while changing to another configurator, it will force us to work properly, create the necessary documentation for the product with valid options, change orders processing and to adjust the entire culture of working with the customer. It turns out that the managers already understand what the problem is, but acknowledged their powerlessness to change the situation, shifting all the difficulties with the reorganization of its own business processes on the department, responsible for information technology. Typically, such project will be ended in complete failure or has been delayed for many years. If we assume, that IT professionals know how to change business processes on the basis of understanding how systems operate, then they still do not have sufficient administrative resources to change business processes of the enterprise, but the expected outcome depends primarily on this and not on the software. In this case, clearly confused cause and effect. I will explain. Suppose there are A company, which uses information system ABC. The company is very stable, no rush job, confusion, orders are fulfilled on time; there is a systematic activity of organized mechanism. It is possible to draw a conclusion, that it’s due to the system ABC, but it is 100% wrong. The presence of the ABC system in the company A contributes to its business, but it is not the key reason. Consequently, when the company B management decided to implement the ABC system in the hope that, once implemented, it will also work as stable as company A, then it will be a surprise, the money will be spent, and there will be no the desired effect, as operating procedures in the company A remain the same.
I repeat, the purposes, which I consider effective for information system deployment should be connected with the acceleration of business processes or the implementation of new business processes related to information processing. No need for shifting the tasks of other units on information system without giving the rights to influence these processes. If a goal that goes beyond the capabilities of information system is important for a company, then the project should be created for this goal, where the information system deployment will be a part of this project.
Deployment of an information system can afford to launch new business processes, which just could not exist because their duration would not be acceptable. Moreover, I believe that the launch of new business processes a prerequisite for the successful system deployment. Clearly, if we use a file to perform a work, it was one process, if we now have a machine, it will be the different process. If it was bad planning established, the machine, because of its performance can bring more loss for the company than the old file! So, we have defined goals, now left to draw up the requirements list.

Requirements specification.

It is the second most important part for success in project of information systems deployment. I repeat that the effective purpose is to accelerate business processes, which cannot yet exist. Customer only in general understands what he needs. A good option is considered in the early stages of contract work, to make a detailed, multi-page specification and it works, especially for the contractor. Customer shall sign it, not fully understanding what will be done and that the contractor for each new field or form, not recorded in the specification, can ask for more money. As a result, customer can get the processes with incomplete or redundant data and remain unsatisfied, although the formal contract is executed in strict accordance with the technical specifications and the customer is obligated to pay for all. For the second time, the customer do not apply to this contractor. Indeed, it turns out that it is not the customer has signed not suitable technical specification, but the contractor developed and offered to the customer incorrect specification. The contractor did not guess of what the customer dreamed. Notice the paradox that the contractor writes technical requirements for himself, but must anticipate that the customer really wanted. It is in principle possible, but unlikely. I had the experience of creating a very detailed technical specification that in the deployment phase underwent significant changes about 30%. As often happens, over the course of working the customer had completely new ideas and they had to be taken into account by refusing the previous assumptions. From all the above, you can guess that I am not a supporter of very detailed technical specifications, they require a lot of time and as a result will be adjusted at the stage of trial operation and deployment. If not to do correction, it can damage the relationship with the customer. When you try to refer to the detailed terms of reference (TOR), in response can be heard - you experts themselves and had to know everything in advance, such as psychics. I believe that the TOR should reflect only large blocks of future work with the description of the expected results. In the TOR, it is necessary to strike a balance between too much detail and common words. The TOR should accurately describe what the customer wants and what the contractor should do accordingly. As I have written, TOR correction is inevitable because there is a new tool, and the customer will surely have new business processes. Attempt to preserve the old business processes, especially those that were when paper technology was used leads to project failure. Of course, not all the old processes are swept aside completely, but almost all are adjusted according to the new opportunities of the company based on the availability of the information system. Maximum on what should stay the TOR, it is lists of documents, which should handle the deploying system with their samples and reports. Technical specification drawn up in such a way does not change in terms of the general requirements and expectations and actually specified in the real work on the deployment of the system down to specific fields and processes. In this case, the contractor shall know his upcoming workload. The successful project requires 1-2 iterations, i.e. you need to deploy a certain amount of performed work and according to the results, the customer coordinates a refinement of the deploying system with the contractor. Time that could be spent on excessive detail technical specification is much more effective to spend on the iterative adjustment of the system, based on the results of the test operation.
There is another way of technical specifications writing. This is when the TOR declare ultimate goal of the customer. Then you can immediately notice the contradiction with the previous written test, but it is just a case of drafting where the information system is only a part. I had the experience of implementing an integrated company management system, where the main sum under the contract should be paid if the customer will increase money turnover twice. The question is, how can this be? The answer is simple. In this case, it was clear that the goals of the customer - is the automation and optimization of company business processes, speeding up the process of working with clients, accurate accounting of contracts expenses, accurate calculation of bonuses for managers involved in the contracts, financial planning. Based on the fact, that all these problems had not been solved, I signed the contract. Unfortunately, the customer did not achieve 100% increase in turnover for 1 year, but 83% is good too. My reward was paid proportionally. The next important document for the successful execution of works is the work schedule.

Work schedule.

Work schedule is a document, containing plan of specific works, which describes the actions that both customer and contractor must perform. The work schedule usually lists all systems and subsystems with their processes, documents, reports to be developed or implemented, as well as customer actions related to the organization of workplaces, communications, personnel training, etc. At each point of the schedule may be marked its price and duration. It gives the opportunity to make settlements between the contractor and the customer. Work, of course can be done in parallel. It is good to use Gantt charts or something similar. Work schedule is a document of progress operational monitoring. If the requirements specification drawn up in general terms, the definition of specific activities and timelines are set by work schedule. In this case, the schedule becomes necessary first of all for the contractor.

Launch of the system into operation.

Customer test examples should precede launch of the system into operation. The work on the actual deployment and launch of the system begins only after obtaining the positive results of these tests. If the trial operation do only experimental examples without participation of ordinary frontline workers of the customer and without the use of real-world problems, it will not reach the goal - to collect the necessary observations and problems that must be fixed in the system for its industrial operation. Such a step would be more correct to call the advanced testing involving customer frontline workers. Actual trial operation begins after the deployment of the system on at least 50-70% percentage of workplaces with an appropriate amount of staff. If it is necessary, the personnel is trained and short instructions for users are formed. This stage can last from several minutes to several weeks. Extreme programming methods work well, when qualified contractor developers immediately solve the problems, received from customer staff, preferably directly on the customer side. Thus, for one, maximum two weeks one can solve the bulk of problems associated with the system start-up and adaptation. Without massive run with strict requirement of the customer management to work on the new system, the launch of its operation can be delayed for months. If there is no strict requirement of the management, people will work as before; it is more habitual and there is a feeling that someone they simply prevents to live. After all, earlier also everything was fine. After the pilot operation phase follows immediately industry one, the difference between them only in the number of comments that should be addressed and in the absence of critical problems in the system, under which the operation becomes impossible or difficult. So, there are start-up and deployment stages, test operation involving customer employees using real-world examples, experimental operation with immediate solving of emerging problems, and then industrial operation. I many times test this method in companies of all sizes. Customer employees may experience considerable discomfort at some point, as well as contractor staff, but it ends quickly and goes into regular work.