The effectiveness of the implementation of information systems. Practice experience

I have many years of experience in the implementation and subsequent maintenance of information systems in various enterprises. Experience, in most cases, was successful - but here I want to talk, first of all, about the reasons leading to failure in this matter, to warn you against possible mistakes. I mean my own implementation method, which I used repeatedly and which helps to avoid most of them.

The first and most important reason for the failure: incorrectly set goal for the information system .

This is one of the main issues for any project at all. The customer often chooses a goal that has nothing to do with the information system, or only slightly depends on it. Examples: an increase in sales, the occupation of a larger market share, the creation of a different culture of enterprise management, etc. But if a company produces a product, the demand for which is falling, how will the information system help? The problem here must be solved by the marketing department. If you need to change the culture of the company - it is a matter of personnel management and the CEO. However, some people have hope that they should give money for the information system - and the problems associated with business organizations will be solved by themselves. The promises of salespeople who are “expensive”, foreign-made, repeatedly tested and built on “the world's best business practices” systems only strengthen this belief. But in fact, a company with an ineffective management style will remain ineffective, only with an information system. If demand has fallen for your products, it will not change either. True, the information system will allow you to quickly and accurately calculate the losses, including from its implementation.

Properly set the goal of implementing an information system - the key to the success of this implementation. Correct goals related to information processing: storage, data retrieval, tasks related to calculations, grouping, analysis. When implementing a system, all this requires less time. Remember, however, that speeding up failed processes will lead to an even more unfortunate result for the company than it would have been without a system.

Here is one of the recent cases in negotiations with the customer. The customer wants to change the configuration system of the product, hoping that it will streamline the work of production. In his words, the new system should provide only a limited selection of available product options. Then the production and approval department will be easier to work with, a set of standard solutions will appear. The customer, however, already has a configurator. Immediately the question arose: why change? The answer is amazing: another configurator “will make us work correctly”, create the necessary product documentation, change the order processing schemes and adjust the work culture with the customer. It turns out that managers understand what the problem is, but they sign in their own inability to change the situation and shift the difficulties in reorganizing business processes to a department that is not responsible for it. As a rule, such a project ends in failure or is delayed for many years.

Even if we assume that information specialists know how to change business processes (we have order with logic), they still do not have the necessary administrative resource, and the expected result depends, first of all, not on software. Here the effect and cause are clearly confused. Suppose there is an enterprise A with an ABC information system. The enterprise works stably, there is no rush job, there is confusion, orders are fulfilled on time, there is a planned activity of the debugged mechanism. It can be concluded that everything is good thanks to the ABC system, but this is not 100%. The presence of the ABC system in Enterprise A, of course, contributes to the business, but is not the key. If the management of a certain enterprise B decided to implement the ABC system in the hope that after its introduction, enterprise B will also work just like A, it will be a surprise. The money will be spent, but the expected effect will not come, because The method of work in enterprise B will not change.

Effective goals

I repeat - the goals that I consider effective in the implementation of an information system are related to the acceleration of existing business processes or the creation of new ones for data processing. It is not necessary to shift the tasks of other divisions to the information system, especially without the right to influence these processes.

The introduction of an information system allows you to start business processes that previously had no right to exist due to unacceptable deadlines. Moreover, I believe that the launch of new business processes is a prerequisite for the successful implementation of the system. Obviously, if earlier we used a file for performance of work, and now we have a machine, it will be a different process. If planning was badly adjusted, the machine, due to its performance, would bring the company an even greater loss.

So, with the goals we have decided, now it remains to correctly draw up a technical task.

Technical task

This is the second most important component of success in the implementation of an information system. Let me remind you that an effective goal is the acceleration of business processes that may not yet exist. The customer only in general understands what he needs. A good option is considered to be at the first stages of work to create a detailed multipage TK. This works, especially for the contractor. The customer signs everything, not fully understanding what the contractor will do. Meanwhile, for each new field or form that is not recorded in the TK, the performer will easily ask for more money from the customer. As a result, the customer will receive a process with incomplete or redundant data, although the contract was formally executed in strict accordance with the requirement. The customer will be unhappy and the second time this artist will not turn.

It turns out that it was not the customer who signed the inappropriate TK, but the performer developed and suggested something quite different - did not guess what the customer dreamed of. Do you notice a paradox? The performer writes for himself TZ, but at the same time he must guess what the customer actually wants. In principle, this is possible (for participants in the show “The Battle of Psychics”), but it is unlikely. I had experience in creating detailed TK, which at the implementation stage underwent changes of about 30%. The usual story: in the process of working on the project, the customer had new ideas, they had to be taken into account, abandoning previous decisions. Therefore I am not a supporter of very detailed TZ. They take a lot of time, but in the end will be adjusted at the stage of trial operation and implementation. If you do not make the adjustment, you can ruin the relationship with the customer. When you try to refer to the detailed TZ in response, you will hear - "well, you experts, you should have known everything yourself in advance."

I believe that only general blocks of work with a description of expected results should be reflected in the TOR. Let it describe with sufficient accuracy what the customer wants to receive and what the contractor should do. Adjustment of TZ is inevitable due to the fact that when a new tool appears, the customer will necessarily have new business processes. Attempting to preserve the previous business processes will lead to the failure of the project. Of course, not everything old is swept away completely, it is adjusted in accordance with the increased capabilities of the enterprise in the presence of an information system. The maximum that TK should stop at is lists of documents for the system to process with their samples. Thus, the compiled TK will not change in terms of general requirements; in fact, it will be refined in the implementation process, up to and including specific fields and processes. In this case, the contractor in any case knows the expected amount of work. For a successful project, 1-2 iterations are required: a certain amount of work is implemented, and according to the results, the customer coordinates the correction with the contractor. The time that could have been spent on overly detailed TK is much more efficient to use for iterative adjustments of the system in accordance with the result of test operation.

There is another option for the preparation of TZ: it declares the ultimate goal of the customer. And here you can immediately notice the contradictions with the previous test written. This is a case of drafting, in which the information system is only a part. I had experience in implementing an integrated management system for companies, where the principal amount of the contact was paid if the customer received a twofold increase in turnover. The question is, how is it? The answer is simple: the customer’s goal is to automate and optimize business processes for digging, speed up the process of working with clients, accurate accounting of contract costs, accurate calculation of bonuses to managers involved in contracts, financial planning. Based on the fact that all these tasks were not solved, I signed the contract. Unfortunately, it was not possible to achieve a 100% increase in turnover at the customer for 1 year, but 83% is also good. My reward was paid in proportion.

The next important document for successful work is the work schedule.

Work schedule

Schedule - a document containing a plan of specific works, which describes the actions that must be performed by both the customer and the performer . The schedule is needed for operational control over the work of both parties. As a rule, it lists all the systems and subsystems with their processes, documents, reports that will be developed and implemented. For example: customer actions related to the organization of workplaces, laying of communications, personnel training, etc. At each point of the schedule, the price and duration can be put down, this makes it possible to make mutual settlements between the contractor and the customer. Work, of course, can go in parallel. It is good to use Gantt charts or something similar, but not necessary.

Starting up the system

The launch of the system is preceded by testing by the system performer using customer examples. After receiving positive results, work begins on the actual implementation and launch of the system. If the trial operation is done only on experienced examples without the participation of ordinary executors of the customer, without using real tasks, it will not reach the goal. The goal is to collect comments that need to be eliminated for conversion to commercial operation. This stage would be more properly called extended testing with the involvement of customer performers. The actual trial operation begins after the introduction of the system with the participation of at least 50-70% percent of jobs.

The staff is trained, brief instructions are made for users. This stage can last from several minutes to several weeks. Extreme programming methods work well when comments received from the employee’s employees are immediately eliminated by the customer’s qualified developers, preferably at the customer’s site. Thus, in one, maximum two weeks, you can solve the bulk of the problems associated with the launch and adaptation of the system. Without a large-scale launch with the strict requirement of the customer’s management, commissioning may be delayed for many months. If there is no strict management requirement, people will work as before. With any innovations people only have the feeling that someone is stopping them from living.

After the stage of trial operation immediately followed by industrial. The difference between them is only in the number of comments that must be eliminated, and in the absence of critical problems, in the presence of which operation becomes impossible.

As a result, we get the following stages of launching and implementing the system:

• Testing with customer engagement using real-world examples;
• Trial operation with immediate elimination of emerging problems;
• Industrial exploitation.

This method has been tested by me many times in enterprises of various sizes. Employees of the company of the customer at some moments feel discomfort, as employees of the contractor. But, fortunately, this discomfort is quickly fading away, and the company goes into systematic work with a constructive approach to solving emerging problems.