Organization of information systems production processes. Part 4. Implementation of the information system

IX Implementation of the information system

Nothing is harder, more dangerous and uncertain than to lead the introduction of a new order of things, because every innovation has ardent enemies who have lived well the old way, and sluggish supporters who are not sure whether they can live in a new way.
N. Machiavelli

And here the part in the project that is interesting and saturated with creativity, projecting, creativity and creation comes to an end. Harsh everyday life begins to protect his decision in the real atmosphere of a particular enterprise, and not least, everything is also within the framework of current legislation.

To begin with, the realized product must be deployed on the equipment prepared for the organization of its trial operation.

1. Deployment of the system at the trial site

In accordance with the designed technological architecture reflected in the documentation, server, communication and other equipment, as well as system software, are purchased. The components of an information system are mounted in a single hardware and software system at the sites where it is planned to be used commercially.

Since large projects involve a large amount of equipment on which the software is scattered across nodes, nodes and even clouds, this process must be accompanied by full-scale documentation. For example, technical documentation includes tables with addresses of servers, workstations, access methods, etc. For visual presentation, component diagrams are used to give an understanding of the location of network nodes, the distribution of components of their interaction, and the like. But there must also be defined measures regulating all kinds of changes in the infrastructure, allowing to eliminate the consequences of failures of various elements of the system.
')

Figure 19. - An example of a technical description of the implementation phase

This is all extremely important, because the next stage at these operational sites will be pushed by a multitude of implementation and support team experts, and they do not have to get the information necessary for work from different sources, even if they are informed sources. Therefore, the documentation should be kept up-to-date and change simultaneously with changes in the system settings, changes in the architectural design, etc.

It is useful on the "combat" sites for the industrial operation of the system, to deploy and test benches that simulate work close to real. Well, suddenly there will be comments requiring the release of new releases. Of course, all the professionals, responsible people and all that, but still it is better to first update on the test bench. So just in case.

Meanwhile, 90% of the time has flown by ...

2. Training the customer’s staff to work with the information system

As has been repeatedly mentioned, in large projects special attention is paid to the quality of the documentation, including the instructions of the users of the system. Most often, user instructions are divided into segments by type of activity, specialization, etc. This allows you to focus attention on the document on important points and not load users with unnecessary information for them.

Since training can involve a significant number of different customer employees, who, in turn, cannot be trained at the same time to ensure business continuity, who should be trained in various functional duties and for other valid reasons, it is necessary to carefully plan the personnel training process . It is also useful to divide students into groups into categories requiring different approaches and depth of training, based on their level of initial preparedness. As a result, the training schedule should be agreed with all interested parties, and approved by the customer’s management as binding.



At the design stage, we warned that customer training was not only a very important task, but also very laborious ...

3. Identification of deficiencies and defects in the information system

Very often in large projects, testing the final release does not reveal all the problem areas of the solution. The reason for this can be: huge amounts of data in practice in “combat” conditions, manifestation of unique combinations of business rules in real business processes, features of specific equipment, specific combinations of system components, load balancing between distributed nodes, etc.

Often the situation is further complicated by the fact that the introduction of new systems in the initial stages in no way abolishes the need to perform work on old systems. That is, users duplicate data in both systems. Sometimes it is necessary to migrate existing actual data from obsolete repositories to new ones, and the structure and format of information is usually very, very different. For example, if the new data structure does not have enough information to fill in the mandatory details, they are filled with some data assigned by default, and then adjusted manually by users. And this is only a small fraction of what one has to face in real projects.

A separate topic is integration solutions in which there can be failures in a chain using various components developed by two, three and more teams. It is extremely difficult to find those who are guilty in this situation, since defects most often occur at the junction of integration elements, due to inconsistencies identified during the implementation. And here it is important not to look for those responsible for punishment, but to quickly and constructively agree on joint concessions to the developers of the components being joined, and to effectively solve the problem.

Considering all of the above, the stage of trial operation, most often, is saturated with emotional outbursts and mutual complaints, both between development teams and customers. In this case, the role of architects and system analysts is very important. They should promptly localize the problem, propose its solution and coordinate it with all interested parties. To perform such work, besides the basic professional skills, possession of the talent of the negotiator and knowledge of the basics of management are also required.

In the meantime, we have reached the bottom of the time allotted for the project ...

4. Coordination of changes in the implementation of the information system

If the work of some functional modules of the information system is not critical of the needs and expectations of the customer, and solutions are found to overcome these problems, then they need to be fixed and agreed with the customer.

The step of agreeing on a new solution is very important for at least two reasons.

First, if the volume of implementation of the changes exceeds the amount allocated for such risks in the project plan, then it is necessary either to conclude additional agreements, or the team of executors will work at a loss. Often, executors are urged to make changes in a prompt manner, and they say we will take them into account and settle for work on them later, in one package. But in fact, such cases usually lead to the fact that the customer afterwards completely forgets his promises, and announces the work done - with the correction by the performers of their own mistakes.

Secondly, any changes in some components of the system may entail an inevitable change in interdependent components, which requires careful analysis and, possibly, redesign of a whole chain of subsystems. Otherwise, the occurrence of defects in the operation of the system as a whole is inevitable. This may manifest itself, for example, in the refusal of the work of the module of the adjacent team of performers, and the customer has already declared them to be hackers and marketers. The truth of course will emerge, but the precipitator will remain.

And to paraphrase Jerzy Lec: “When we reached the bottom of the allotted time, we knocked on the bottom ...”



Since time is overdue, it is necessary to negotiate with the customer, and convince him that he was also not a gift in the project, and part of the blame lies with him.

5. Refinement of the information system on the basis of trial operation

If in the course of trial operation, decisions are made and agreed to make changes to the developed software and hardware complex, then on the basis of them, tasks are set for the implementers. The process described in Section 3. The implementation of the design decision is repeated. But…

If at the design stage of the system we discussed the negative impact of the full-scale use of the Scrum (1) methodology in large projects, then at this stage it fits perfectly. This is especially noticeable in projects in which the product transferred to the customer does not suit him for the most part of the indicators. In other words, it’s time to panic and very quickly, "headlong," to make changes to a product that is already being exploited.

As a matter of fact, the moment has come when the following conditions are relevant:

1. The customer has already begun to really work with the system, time has been allocated for this, and he now has a clear idea of ​​what he really needs. Accordingly, he is ready to work closely with the team of performers and he has this critical need;
2. Documentation for the most part is already ready and its change and addition can be no longer so prompt, but can be made out post factum based on the results of a successful implementation.
3. Improvements mostly occur in individual modules, subsystems, contours, which have a specific team of performers responsible for the segment. Therefore, communication between users and developers is already localized, it is easy to establish high-quality feedback;
4. Improvements and corrections must be carried out very quickly, in small queues with the transfer of the result to the customer who is vitally interested in them;

It is very important that, ultimately, the project documentation was brought into full compliance with the innovations, and the team could easily find in it the actual solution for analyzing and designing subsequent changes.


Figure 20. - The implementation phase of the information system

No comments…

6. Transfer of information system into commercial operation

When in the course of trial operation all disputable issues and misunderstandings about how the implemented system should function and how it corresponds to the contract for its development are resolved, the parties sign acts on the implementation of the contract. The customer carries out a full payment for the work performed. The contract for the development and implementation of an information system can be considered as fulfilled.

Implementation goes into the phase of industrial exploitation. These relationships are most often legally regulated by a separate contract or additional agreement for the maintenance of the industrial operation of the system. Within the framework of this contract, preventive work may be performed on diagnosing the performance of the system components, their interaction, eliminating minor failures, etc.

7. Section Summary

The stage of implementation of the information system represents the moment of truth of the whole process of its production and marks the start of the hardest period for all project participants. It may include the following activities:

1. Deployment of the system at the site of industrial operation, including the supply of equipment, installation of system software, installation of the actual release of the system being implemented, etc .;
2. Educating users of the system, including administrators, equipment maintenance specialists, etc.
3. Identification and elimination of deficiencies and defects identified during trial operation.
4. Coordination of changes in the work of the system and bringing it to conformity with contractual obligations;
5. Signing of documents on fulfillment of contractual obligations. The product of the full payment for the work performed;
6. Putting the system into commercial operation;