Design and implementation of is. Transfer of the information system to commercial operation

Details Published: 07/14/2018 21:24 : the basic stages of the implementation of corporate information systems are considered. In addition, an overview of the design documents of each of the stages is performed, and the dependence of the data of a given phase on the documents of subsequent stages is also demonstrated.
Download: PDF.
Keywords: ERP system documents, documenting the implementation of corporate information systems, documenting information systems, documents in the information system, project documentation ERP systems, working documentation IP, technical documentation CIS, regulations information system, regulatory documents for the design of information systems, software implementation documents, information system implementation documents, software product implementation stages and documents, trial operation of information systems, GOST R 54869-2011, ANSI PMBoK.

Certainly, the most depressing of all possible situations is uncertainty. Ignorance of what will happen next on the issue that concerns you has an extremely negative effect. The process of implementing a corporate information system (hereinafter referred to as CIS) is no exception. Let's say you've just joined a project team with neither work experience nor theoretical knowledge. By completing specific tasks, we are like "blind kittens" waiting for tomorrow's thrills. Another no less illustrative example, a consultant solves a strictly limited range of tasks for several years, not wanting to understand for which higher processes they are relevant. In such cases, one should not be surprised when the task suddenly turns out to be completed “yesterday”. To exclude the above, it is necessary to clearly understand the sequence of stages of the CIS implementation and the documents prepared at each of the stages.

Goal and tasks

The purpose of this work is to consider the basic stages of the implementation of corporate information systems to ensure a better implementation process. Achieving this goal requires solving the following tasks:

• a review of the literature on the implementation of CIS;
• consideration of the basic stages of the CIS implementation;
• analysis of project documents and their dependencies on stages.

1. Overview of approaches to the implementation of corporate information systems

A corporate information system is represented by a set of information systems (hereinafter referred to as IS) that define a given subject area. There are several approaches to the implementation of IS, which are also applicable for the implementation of CIS (Fig. 1). Let's start the review with the approach declared by the state. We are talking about industry standards, in particular, GOST R 54869-2011, as well as international ISO standard 21500 . The documents contain a description of the stages of project management from the initialization process to completion, regardless of the type of system being implemented. Therefore, it is possible to use these standards for the implementation of technical, information and corporate systems. Code professional knowledge on project management, presented by ANSI PMI PMBoK, regulates the processes of planning, executing, checking and impacting from the stage of initiation to completion of the project. Similarly to GOST R 54869-2011 and ISO 21500, it can be used to manage the implementation various kinds systems.

Rice. 1.

Methodologies Accelerated SAP (hereinafter - ASAP), Accenture Delivery Methods (hereinafter - ADM), as well as Microsoft Dynamics Sure Step (hereinafter - MDSS) are used by SAP, Accenture and Microsoft, respectively, when implementing packaged CIS solutions. The approaches are focused exclusively on the implementation of CIS implementation projects. In the approaches discussed above, a cascade scheme for introducing CIS is mainly used. This scheme is characterized by a strict time dependence of the implementation of the project stages. Works for this stage can only be executed if all the activities of the previous phase of the project have been implemented. The name of the stages varies from approach to approach, however, the content of the work is unchanged. Therefore, it is quite possible to form single list both operations and prepared documents. Let us summarize the result of the analysis of approaches to the implementation of CIS by a list of typical stages of project implementation (Fig. 2).

Rice. 2.

2. Project documents of typical stages of project implementation

In the previous section, typical stages of the implementation of projects for the implementation of CIS were identified, including

• project preparation;
• design;
• implementation;
• preparation for pilot operation (hereinafter - OPE);
• OPE;
• transition to productive operation (hereinafter - PE)

and which are common to ASAP, ADM, MDSS methodologies and standards. The absence of a PEA stage is allowed, then the 4th and 5th phases of the project will provide preparation for the PE and PE, respectively. Let's consider the documents of each of the stages in more detail (Fig. 3).

Rice. 3.

2.1. Project preparation stage

The initial stage of the CIS implementation project is preparation. In the context of this phase, goals and objectives are formulated, as well as document templates and an enlarged project schedule are prepared. The main document of the stage is the charter that defines the goals of the project, as well as containing the functional, organizational, technical and methodological scope of the project. In addition, the document describes the participants in the project and sets the procedure for coordinating project documentation. A training concept for the project team is being prepared, including a proposed approach to training the customer's CIS implementation team. Document templates used to prepare documentation at subsequent stages of the project are formed here. The scope of the project contained in the charter is necessary to determine the timing of the project. The latter are reflected in an enlarged plan of the schedule, which is later refined for each phase. Thus, the charter is the dominant document of the preparation stage.

2.2. Design stage

Having completed the preparation of the project, we proceed to the stage of system design. The quality, interconnection and detail of the designed solutions are the determining factor for the success of the CIS implementation. Mistakes made at the design stage are difficult to eliminate. The beginning of the design phase is accompanied by the preparation of training materials and a training plan for the customer's team. The previously formed concept of training the project team contains only the superficial content of these documents. Further, the customer's project team, together with the contractor's specialists, participates in the survey of the client's business processes. The result of the process analysis is the functional and technical requirements for the system being designed.

Customer requirements are compared with a standard CIS solution (Fit-analysis) to identify functional deficits (GAP-analysis). A functional deficit requires the system to be finalized, for which development specifications are being prepared containing the problem statement and the proposed solution vector. The concept of roles and powers is being developed, which defines the list of user roles and the rules for their creation and assignment to employees. Standard CIS functionality, development specifications, and the concept of roles and authorities are necessary to form design decisions. Design solutions contain the customer's business processes in the "as is" and "as will be" models, indicating system improvements and user roles.

Design solutions are created on the basis of Fit / GAP analysis of the functional and technical requirements of the client. Project experience shows that solutions are most often formed for each customer's business process. In addition, solutions for maintaining master data, organizational structure and migration are highlighted separately. The issue of system historical data migration is considered separately in the corresponding concept. The concept includes a description of the data migration approach, the migration mechanisms used according to design decisions, and the proposed migration plan. Concepts for end-user training and transition to using the system are also created at this stage. The concept of user training determines the order and planned timing of training, the necessary training materials, as well as the list of exercises to be performed.

The concept of transition to the use of the system describes the procedure for applying the new CIS solution and the operation of the previous system, sets a list of steps to enable users to work with the new solution, and defines a set of manual operations performed by technical specialists in the CIS. All created documents of this stage are interconnected. Design solutions can be attributed to the most significant documents, as they are the basis for the implementation of the system, user training, data migration and transition to the application of the proposed CIS solution.

2.3. Implementation phase

The implementation of the system is carried out in accordance with the documents prepared at the design stage. Design errors inevitably lead to incorrect tuning and refinement of the system, which is why the design phase is so essential. Following the design decisions, development specifications and the concepts of roles and powers, the system is implemented, descriptions of the settings performed, the technical implementation of the specifications and the settings of roles and powers are prepared, respectively. Operations not included in the description of the performed settings require manual entry by CIS specialists. Therefore, a description of such operations is provided in the instructions for the transition to using the system, a reference to which is contained in the corresponding concept.

According to the concept of data migration, design solutions were prepared and implemented in the CIS at this stage. Instructions are also prepared here, including a description of the procedures for loading and controlling data, as well as examples of loading templates. The customized and modified system is used for internal testing. Testing is carried out by CIS specialists based on functional testing scenarios. Scenarios contain exercises that reflect the business processes of design solutions. The purpose of functional testing is to check the correctness of the work individual programs. Integration testing, unlike functional testing, allows you to consider the correctness of the interaction of programs involved in a single business process.

Both CIS specialists and key users of the client are involved in integration testing. Functional and integration testing errors are recorded in the issue log for later troubleshooting. The number of errors in the problem log is indicative of the depth of understanding of the customer's business requirements. If the log contains too big number criticisms, there is a high probability that the project will be suspended (since the comments must be resolved before the OPE stage).

2.4. Stage of preparation for pilot operation

The implementation of the system is complete, and the problem log contains a small number of comments. Preparations for the OP are underway. The primary task of this stage is the training of end users. Instructions for end users are being prepared (in the context of business processes or operations). Further, based on them, user training scenarios are formed, which are included in the final training plan. The intended learning plan was created earlier in the context of the learning concept. User training is carried out in conditions close to real. Therefore, it is necessary to prepare a list of participants and assign them real roles to complete the test exercises. Trainings are a kind of testing of the system, thereby updating the problem log.

Further, the comments received during the training are analyzed. The continuation of the project is possible if the problem log contains comments that do not hinder the implementation of the OPE. In this case, a list of users participating in the OPE is prepared, the necessary roles are assigned. A plan for the transition to the use of the system in the OPE mode is being formed, including a list of necessary steps to ensure the operation of the CIS and the timing of their implementation. The specific steps of the plan contain links to operations from the instructions for transitioning to using the system. The data migration plan is similar to the plan for transition to using the system, however, it contains links to instructions for migration. The client provides filling and validation of data in the download templates. The preparation stage ends with the introduction of users in the system for conducting the OPE, as well as the migration of master and variable data.

2.5. Stage of pilot operation

Pilot production allows you to test the performance of the system in real business operations using historical data from the previous system. Loading of variable data at the stage of preparation for the OPE is limited to one period. Therefore, the first thing that users perform in the system is to check the correctness of loading the balances. Next, employees enter material movements and account transactions based on primary documents of a given period. User comments when working with the system are recorded in the problem log. The OPE stage ends with the closing of the period in the modules of logistics, accounting and controlling.

2.6. Production Transition Phase

Successful completion of the OPE stage allows us to talk about the transition to PE. The main condition for the transition is the absence of comments in the problem log and updating all project documentation based on the results of correction of comments. Similar to the stage of preparation for the OPE, lists of system users, plans for the transition to PE and data migration are being prepared. The data load templates are being filled. Having created users in the CIS, having completed all the operations from the transition plan and data migration, work begins in the PE mode. Starting from this moment, the emerging comments and problems are resolved by the customer support team. At the stages of implementation, preparation for the OPE and OPE, system errors were recorded in the problem log and corrected by the contractor's specialists.

3. Dependence of the prepared documents on the stages of the project

Design documents are approved by the client at the design stage. In the future, during the phases of implementation, preparation for the OPE and OPE, the client's comments on the implemented prototype of the system are reflected in the problem log. Correction of the remarks of the problem log consists in updating and re-approving the documents, as well as reconfiguring and demonstrating the system to the customer. The figure below shows the document flow for the design, training, system transition, and data migration processes (Figure 4). Suppose, according to the results of the training, it was revealed that one of the training scenarios contradicts the requirements. What are the consequences?

Rice. 4.

First, almost all documents are subject to change, from design decisions to end-user training scenarios. Secondly, it is necessary to correct both the documents on the transition to the use of CIS and data migration. Finally, thirdly, re-execute end-user training. Such significant labor costs arise due to the fact that, on the one hand, the processes of design, training, transition to the use of the system and migration are rigidly interconnected, on the other hand, the later comments are formulated, the more difficult and expensive it is to eliminate them. That is why the quality of design solutions determines the success of the CIS implementation.

Results and conclusions

Consideration of methodologies for the implementation of CIS, identification of typical stages of system implementation, as well as a review of project documentation and the dependence of documents on project phases are the main results of the work. An analysis of the IS implementation methodologies made it possible to single out the phases of project preparation, design, implementation, preparation for the OPE, OPE and transition to PE, which are typical regardless of the chosen standard or project management methodology. The description of the design documentation is made for each typical stage of the CIS implementation and is clearly presented in the form of a cascade diagram (Fig. 3). Given short description documents and the procedure for their preparation. The main focus is on the purpose of the documents, not their content.

The dependence of documents on the phases of the project is shown. It is illustrated that a minor change in one document requires updating the documents used to prepare the original one (Fig. 4). This greatly increases the complexity of the work. A detailed description of typical works at each phase of the project, analysis of project documentation and identification of the main requirements for the content of documents similarly determine the promising direction for further research.

Literature

1. GOST R 54869-2011. Project management. project management requirements. - M.: Standartinform, 2011. - 10 p.
2. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. - NL.: Van Haren Publishing, 2013. - 148 p.
3. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013 – 589 p.
4. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. - NJ.: Sybex Inc., 1999. - 591 p.
5. Kress R. Running IT Like a Business: A Step-By-Step Guide to Accenture's Internal IT. - Ely: IT Governance Publishing, 2012. - 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. - Birmingham: Packt Publishing, 2011. - 360 p.
7. Information systems design: tutorial/ Gvozdeva T.V., Ballod B.A. - Rostov n / D .: Phoenix, 2009. - 508 p.
8. Kovalev S., Kovalev V. Secrets successful businesses: business processes and organizational structure. – M.: BITEK, 2012. – 498 p.
9. Stepanov D.Yu. Overview of logistics business processes on the example of the procurement activity of an enterprise // Logistics today. - 2014. - v.65, No. 5. – c.208-228.
10. Stepanov D.Yu. Formation of universal requirements for user programs when preparing a specification for ABAP development // Actual problems of modern science. - 2014. - v.78, No. 4. – c.258-268.

Implementation

It's hard to give advice on the implementation of module code, since each developer has some habits and his own code development style. When implementing a project, it is important to coordinate the group(s) of developers. All developers must comply with strict source test control rules. The development team, having received the technical draft, begins to write the code of the modules, in which case the main task is to understand the specification. The designer specifies what needs to be done, and the developer determines how to do it.

During the development phase, there is close interaction between designers, developers, and groups of testers. In the case of intensive development, the tester is literally “fastened” to the developer, actually being a member of the development team.

The designer at this stage acts as a “walking reference book”, as he constantly answers the questions of the developers regarding the technical specification.

Most often, user interfaces change during the development phase. This is also due to the fact that the modules are periodically demonstrated to the customer. Data requests can also change significantly.

It should be noted that for the assembly of the entire project there must be a dedicated workplace. These modules are submitted for testing. Interaction between a tester and a developer without a centralized transfer of parts of the project is acceptable, but only if it is necessary to urgently check some kind of edit. Very often, the development phase and the testing phase are interconnected and run in parallel. The bug tracking system synchronizes the actions of testers and developers.

During development, constantly updated repositories of ready-made project modules and libraries that are used when assembling modules should be organized. It is desirable that the process of updating storages is controlled by one person. One of the repositories should be for modules that passed functional testing, and the other for modules that passed link testing. The first one is drafts. The second is something from which it is already possible to assemble the distribution kit of the system and demonstrate it to the customer for conducting control tests or passing any stages of work.

Documentation is created throughout the development process. Once a module has passed link testing, it can be documented. If the modules change frequently, the description is only started when the module becomes more or less stable.

Processing of design results

At the development stage, as a rule, the atomicity of functions is checked again, as well as the absence of their duplication.

It is desirable that the "function-entity" matrix has already been built at the design stage. This is actually a formalized representation of what the company is trying to do (functions) and what information needs to be processed to achieve the result (essence). Such a matrix allows you to check the following points:

• whether each entity has a constructor - a function that creates instances of the entity (create);
• whether there are references to this entity, that is, whether this entity is used anywhere (references);
• whether there are changes to this entity (update);
• whether each entity has a destructor - a function that deletes entity instances (delete).

Often the role of the destructor is performed by a set of data archiving programs. Often in information systems, information is simply accumulated. This is permissible only if, during the entire period of information accumulation (and in fact, during the entire life of the information system), its performance characteristics meet the requirements of the customer. In practice, this is an extremely rare occurrence. This is mainly due to the growth of processed volumes of information. It should be noted that in this case it is impossible to rely only on the power of the DBMS or hardware, since such extensive methods of improving performance give a low estimated speed increase. In fact, the task of the system or its individual parts responding to the growth in the volume of processed data is the most probable task of testing. In this case, the testing group creates a module for generating (even abstract) data, selects a set of queries for which speed characteristics are critical, then measurements are taken and the dependence of the execution speed on the amount of data for each of the queries is plotted. Such a simple action will avoid serious errors in the design and implementation of the information system.

The specification of the modules must be made at the design stage, which is often simply ignored in real projects. And in vain - after all, due to the ill-conceived implementation of modules, any advantages of the database schema can be lost. So, neglecting the specifications of the modules, you run the risk of putting into the information system:

• uncontrolled growth of data volumes;
• Request threads with an inherently high probability of conflict, or request threads that will run "forever" (trying to execute a thread, detecting a conflict and rolling back all actions, trying again, etc.) due to conflicting threads;
• mixing system and interface modules;
• duplication of modules;
• errors in the placement of business logic;
• lack of implementation or incomplete implementation of the system functions required by the customer.

This is not a complete list of problems that will be discovered either at the stage of complex testing, or when putting the system into operation, and maybe even during the operation of the system (when the modules actually start to be used).

In addition, the absence of module specifications will not allow to accurately assess the complexity of each module and, as a result, determine the sequence of creating modules and correctly distribute the workload of personnel. The usual situation in such a case is “someone is waiting for someone”, while the process of creating an information system stands still.

System modules

It is often necessary to consider a large number of service or support processes that are not directly related to the formulated business function. As a rule, these are system functions available in any information system, such as:

• queue manager or task scheduler;
• print manager;
• means of accessing data and creating ad hoc queries (often these are report generators);
• management of directories and other resources of the file system;
• automatic backup;
• automatic recovery after system failure;
• means of regulating user access to the system (consisting of a means for creating users and a means for assigning privileges to them);
• means for setting the environment for the user of the information system;
• a means of changing the user's settings (including the password);
• application management tool;
• information system administrator environment.

Some of these functions must be performed by the operating system, but if it will work in a heterogeneous environment, then there is no guarantee that users will like the presence of different interfaces in different operating systems. Ideally, all client applications should run on the same operating system, but in practice, developers often have to deal with a whole "zoo" of different workstations at the customer's - the result of several attempts to automate the business. The goal of the developer is to bring the system to the most homogeneous state, or at least make the end user workstations similar.

The task of creating an information system in a heterogeneous environment significantly increases the requirements for code developers and for the chosen development tool. This is especially true for the development of system modules. Attention should be paid to modules whose code implementation depends on operating system. Such modules should be allocated separately for each of the operating systems into groups, for example, Win98, WinNT, etc. The modules of each group must have strict exchange interfaces - the data they transmit and receive is strictly defined, any deviation from the specification is punishable. None of the modules outside this group can use any other calls than exchange interfaces. In this way, operating system dependent modules are isolated from other modules.

Generally speaking, the practice of isolating system modules through strict regulation of their exchange interfaces significantly minimizes the cost of error correction and system support. In addition, it also facilitates testing, namely error detection and debugging. The other side of the issue is that the requirements for the code of the interface for the exchange of system modules are sharply increasing. This is what is debugged in the first place and should work very clearly.

Information system monitoring tools

If the information system is large, then the task of its administration from one workstation should be considered. It is necessary to take care not only of the end user of the information system, but also of the personnel who will serve it. Particular attention should be paid to monitoring critical areas of the information system, since a failure is often easier to prevent than to correct its consequences. Monitoring refers to those tasks, the need to solve which the customer, as a rule, does not think about and which are usually absent both in the analytical study and even in the design. The need for monitoring tools becomes apparent only at the stage of putting the system into operation, and this need is the higher, the more complex the system and the more critical sections it contains.

Developers and designers should evaluate the complexity of the system. If a decision is made to write a complex administration and monitoring tool that is not provided for by the terms of reference, then in this case the terms of reference should be changed, and not be led by the customer. In a complex system, you still have to track critical processes. It is very difficult to introduce such tools into an already finished system, since monitors often receive initial data from system modules of a rather low level. Changes to the database schema are also unlikely to be avoided here, and there is no guarantee that such a change will not degrade system performance.

The development of monitors is a rather specific class of tasks: on the one hand, they must process a sufficient amount of information, on the other hand, they must not significantly affect the operation of other components of the information system. This forces developers to approach the design of monitors with great care and write the code of their modules very carefully.

Interfaces

The end user interfaces are what the customer criticizes the most, due to the fact that it is these parts of the information system that he can evaluate more or less qualified - usually he only sees them. This means that interfaces are the most frequently changed element of the information system at the implementation stage.

The frequently changed component(s) of an information system should be isolated from the rarely changed components so that one change does not entail another. One technique for this isolation is to isolate data requests from the interface, as follows:

• each of the requests is encoded with an identifier or "closed" by a specific system function;
• the interface developer does not know anything about the data request, except for the parameters of the selection attributes - their type and, possibly, the number of rows in the selection;
• error handling in data requests is a separate module;
• error handling in query result interpretation is also a separate module.

When processing the results of data queries, you should also Special attention to pay attention to the issues of correspondence between the types of the host language and the DBMS, including the issues of the accuracy of numeric types, since their representation in different DBMSs varies significantly. Also, pay attention to data queries that use operating system-specific functions, such as attribute value byte and word functions (for example, these functions will work differently on Intel and SUN SPARC). Data types can be cast either explicitly in the query by cast functions and DBMS built-in functions, or in application program functions. Not for all DBMS, implicit type conversion gives the same result, so if the information system uses data from several databases controlled by different DBMS, then implicit type conversions should be avoided.

You should also establish fairly strict rules for the appearance of user interfaces. The impression of a single style for all components of the information system should be created.

Database versions

In most cases, the first version of the project database is created quite quickly - this is the implementation of a fully normalized structure, which is obtained at the analysis stage. The main purpose of this database is to provide prototyping, demos, some experiments for developers and designers.

The scripts for creating a database and filling it with start data are also the source code of the information system, and version control rules apply to it. It should be noted that maintaining database versions at the script level is still easier than at the level of data upload and download tools provided by the DBMS itself, since in the vast majority of cases such tools cannot provide several simple but necessary functions:

• control which data objects and data are in the download objects A and B, and load only the "difference" of A and B into the database (perform a version update);
• check if the changes that take place in the upload objects C and D conflict with the upload object A (merge versions).

CASE tools have database schema versioning tools, some have settings that allow you to also control the start data. This makes it possible to use these tools to provide database versioning.

It is more reliable to control versions of the source code of triggers and stored procedures by using the same version control system that is adopted for storing the source texts of the project itself.

Placement of processing logic

One of the important design issues is the way to place the data processing business logic: place it (and what part) either on the server in the form of stored procedures, packages, triggers, other integrity constraints directly on the database server, or in the form of functions on the client (in part of the client software). The location of the interface rules and data rules is specified exactly: the former are always located on the client, the latter on the server. Business logic rules in modern DBMS can be placed both on the client and on the server. Consider one of the examples of the simplest business rule:

• The value in the screen form field is entered by the user, not selected from the list, but the set of valid values ​​is strictly limited (for example, two or three different values).

On the one hand, the user requires an immediate response of the system to a data entry error, on the other hand, values ​​in the database field that are different from those specified (two or three) are invalid. In fact, two rules must be implemented in this situation. The data rule in this case will be organized as a check constraint, and the interface rule that prohibits entering values ​​other than the specified ones will exactly repeat the data rule, but will be implemented at the user interface level. It would seem that the implementation of a form with a list in this case is the ideal solution, but most operators prefer the set in the form, especially if the length of the input value is small. Forms with a large number of lists are difficult for end users to process. In the case of a set of values ​​in a form, care must also be taken to convert the case of character strings (where case is not significant) to uppercase or lowercase, at the application program interface level.

Templates

Using templates and libraries to build "similar" modules is a fairly common practice. What to use in this case - objects and classes or libraries - is decided by a specific group of developers. In most cases, it makes no sense to dictate the way of development, because the developer writes the code in the way he knows how or how he is used to. These moments are usually controlled by the project manager.

In any project, code copying is prohibited, since this leads to the occurrence of different versions of the same code in different fragments of the application program and, as a result, to difficult to detect and correct errors. A strict rule should be established: a function call is used, not a copy of it in the code; any deviation from this rule is punishable.

Testing

As mentioned above, testing teams can be involved in the early stages of project development. Comprehensive testing itself should really be singled out as a separate development stage. Depending on the complexity of the project, testing and fixing bugs can take a third, half or more of the development time of the entire project.

How harder project, the greater will be the need for automation of the bug tracking system. Such a system provides the following functions:

• storage of the error message (with mandatory information about which system component the error belongs to, who found it, how to reproduce it, who is responsible for fixing it, and when it should be fixed);
• a notification system about the appearance of new errors, about a change in the status of errors known in the system (as a rule, these are notifications by e-mail);
• reports on actual errors by system components, by time intervals, by developer groups and developers;
• information about the history of the error (including tracking similar errors, tracking the recurrence of an error);
• rules for accessing errors of certain categories;
• limited access interface to the bug tracking system for the end user of the information system, which is used as an interface for the exchange of information between the user and the service technical support systems.

Such systems remove many organizational problems, in particular, issues of automatic notification of errors.

Actually, system tests can be divided into several categories:

• stand-alone module tests - are used already at the stage of development of system components and allow tracking errors of individual components;
• tests of connections between system components - are used both at the development stage and at the testing stage and allow you to monitor the correct interaction and exchange of information between system components;
• system test - is the main criterion for the acceptance of the system. As a rule, this is a group of tests that includes stand-alone tests, as well as link and model tests. This test should reproduce the operation of all components and functions of the system, its main goal is the internal acceptance of the system and the assessment of its quality;
• acceptance test - used when the system is handed over to the customer. Here, developers often underestimate the requirements for the system compared to the system test, and in general it is clear why this is justified;
• performance and load tests - are included in the system test, but deserve special mention, since this particular group of tests is the main one for assessing system reliability.

The tests of each group necessarily include failure simulation tests. Here, the response of a component, a group of components, the system as a whole to failures of the following type is checked:

• failure of a separate component of the information system;
• failure of a group of information system components;
• failure of the main modules of the information system;
• operating system failure;
• "hard" failure (power failure, hard drives).

These tests make it possible to assess the quality of the subsystem for restoring the correct state of the information system and serve as the main source of information for developing strategies to prevent the negative consequences of failures during industrial operation. As a rule, this is the class of tests that developers neglect and then deal with the consequences of failures on a production system.

Another important point of the information systems testing program is the availability of test data generators. They are used to perform both system functionality tests, system reliability tests, and system performance tests. The task of assessing the characteristics of the dependence of the performance of an information system on the growth of the volume of processed information cannot be solved without data generators.

Operation and maintenance

trial operation overrides the testing process. As a rule, the system is put into operation not completely, gradually.

Commissioning takes place in at least three phases:

accumulation of information;

reaching design capacity.

The initial loading of information initiates a rather narrow circle of errors - mainly data mismatch problems during loading and the loaders' own errors, that is, what was not tracked on the test data. Such errors should be corrected as soon as possible. Do not be too lazy to install a debug version of the system (unless, of course, you are allowed to deploy the entire complex of the software accompanying the debugging of the information system on site). If debugging "on live" data is impossible, then you will have to simulate the situation, and quickly. It requires very qualified testers.

During the period of accumulation of information, the greatest number of errors made during the creation of the information system will appear. As a rule, these are errors related to multi-user access. Often, at the testing stage, such errors are not given due attention - apparently, due to the complexity of modeling and the high cost of process automation tools. testing information system in conditions of multiuser access. Some errors will be quite difficult to fix, as they are design errors. None of the best projects is immune from them. This means that just in case, you need to reserve time for the localization and correction of such errors.

During the period of accumulation of information, one may encounter the famous “base fell”. In the worst case scenario, it turns out that the DBMS cannot withstand the flow of information. If it's good, it's just that the configuration parameters are wrong. The first case is dangerous, since it is quite difficult to influence the DBMS manufacturer, and the customer really does not like links to the DBMS technical support service. It is not the manufacturer who will have to solve the problem of DBMS failure, but you - change the scheme, reduce the flow of requests, change the requests themselves; in general - there are many options. It's good if the database recovery time fits into the planned one.

When the system reaches its design capacity, under a successful set of circumstances, it is the correction of a number of minor errors, and occasionally serious errors.

Other App Development Approaches

Typically, end users and management feel that the design process has failed because there are no off-the-shelf components to "feel". Often the customer insists on carrying out the project implementation phase ahead of schedule in order to get some result and demonstrate it as soon as possible. In such a case, there is a strong temptation to opt for Accelerated Application Development (ADD) or Collaborative Application Development (CDA). Such methods involve developing a working prototype and then demonstrating it to users. Users mark what they like and what they don't. The designer finalizes the prototype taking into account the comments made, after which he again demonstrates what happened. And so on. The process is repeated until users like what they see and the prototype becomes a working application. Usually there is a time limit and number of iterations, otherwise users will be perfecting the prototype forever. Theoretically, this allows you to get the system that users require. In practice, this approach to application development is fraught with serious problems.

• All attention is focused on screen forms, and what concerns data processing rules and system functions, remains behind the scenes. There is a temptation to start working with reports, while the report is not a starting, but a derivative product of the information system.
• Users believe that if the prototype version is agreed, then the module is ready. In fact, it can be just a picture with a set of "stubs" for calling system functions and interacting with other modules.
• Modules are designed in isolation from each other (probably most of you have come across accounting programs where each workstation is autonomous and functions are often duplicated). The consequence of this is the contradictions of modules, duplication of functions and data, which can only be revealed when testing a complex of modules.
• Functionality grows in parallel in several directions, which means that the structure of the database must be tightly controlled. With RRP, the database schema becomes a junkyard where tables are hastily "molded", resulting in a set of inconsistent and duplicate data.
• Documentation when using the ERP method, as a rule, is absent, or rather, the need to document the system is forgotten, since the illusion is created that the user already understands what is happening. When the application starts to work differently than the user expects, a lot of problems arise.
• Handling of exceptional situations for each module is performed by its own.
• A complete system, as a rule, does not work out; most likely, it will be a certain set of automated workstations, hastily interconnected.

The methods of ERP and PSA can not always be used, but only if:

• the scope of the project and business requirements are clearly defined, do not change, and the project itself is small;
• the project does not depend on other business automation tools, the number of external interfaces that you have to deal with is limited;
• the system is focused on screen forms, data processing and system functions are a small part, the convenience of screen forms is one of the five most important factors for the success of the project;
• users are highly qualified and a priori positively evaluate the idea of ​​creating new software.

However, ERM is better for developing small and preferably autonomous parts of the project.

Currently, an attempt has been made to introduce another way to quickly write a project - the Extreme Programming method. The principles of this approach will be discussed below.

Planning stage (planning game). Based on the assessments made by the programmers, the customer determines the functionality and implementation period of the system versions. Programmers implement only those features that are necessary for the features selected in a given iteration.

As a result of such a decision, the development of the system remains “behind the scenes”, as a result of which, during development, it becomes necessary to build “stubs” and rewrite the code. It is not clear why the customer determines the implementation period, because in fact this is the direct responsibility of the design team. The customer, generally speaking, can only express his wishes regarding the timing (“I want it by such and such a date”), but only the designer can determine the deadline (“can be done in no less than such and such a time”).

Frequent change of versions (small releases). The system is put into operation within a few months after the start of implementation, without waiting for the final resolution of all the problems posed. New versions can be released at intervals ranging from daily to monthly.

Everything is fine, except for one thing: it is impossible to test a more or less complex component in such a period. The customer actually acts as a beta tester. In this case, he can see that the developers are working and even fixing bugs. However, reasonable questions arise: is it worth dedicating the customer to the workflow and is it necessary to experiment on working system? In addition to what has been said, it should be noted that a similar principle can hardly be implemented for parts of the project that require work in 24x7 mode.

Metaphor. The general view of the system is defined using a metaphor or a set of metaphors that the customer and programmers work on together.

On the one hand, this postulate seems not bad, but on the other hand, does it make sense to dedicate the customer to the internal affairs of the development group? What concerns the general view (interfaces, reports, etc.) may indeed be in the competence of the customer, but when we are talking about the features of the implementation of certain components, the customer can hardly be useful due to his lack of necessary knowledge.

Simple project (simple design). At any given time, the developed system executes all tests and supports all relationships defined by the programmer, does not have duplicate code, and contains the minimum possible number of classes and methods. This rule can be briefly expressed as follows: "Formulate each thought once and only once."

This idea is also good, but it does not quite agree with the principle of writing code quickly. Maybe you should still first think about how to make this or that module, a group of modules, and only then start writing code?

Tests Programmers write unit tests all the time. Put together, these tests should work correctly. For steps in an iteration, customers write functional tests that must also work correctly. However, in practice this is not always achievable. To make the right decision, you need to understand how much it will cost to ship a system with a known defect in advance, and compare this with the cost of delaying fixing the defect.

When writing tests by the programmers themselves (especially in overtime conditions), these tests are not fully functional, and even more so they do not take into account the features of multi-user work. Developers usually do not have enough time for more advanced tests. It is possible, of course, to build a development system in such a way that the same people will be involved in everything, but still you should not turn the project into an analogue of the TV show “Director for Yourself”. To what has been said, it must be added that system testing is by no means limited to tests of components (units); no less important are tests of interaction between them, the same applies to tests of reliability of work. Nevertheless, the Extreme Programming method does not provide for the creation of tests of this class. This is explained by the fact that such tests themselves can represent rather complex code (this is especially true for tests that imitate the real operation of the system). This technology also does not take into account another important class of tests - tests of the system behavior with an increase in the volume of processed information. With a high version change rate, it is technologically impossible to perform such a test, since its implementation requires a stable and unchanged project code, for example, within a week. Such times are generally not guaranteed due to frequent shift versions. In this case, you will have to either suspend the development of components, or create a parallel version of the project for the duration of the test, which will remain unchanged, while the second one will change. Then you will need to perform the process of merging the code. But in this case, the test will have to be created again, since extreme programming methods simply do not provide for the development of tools that allow predicting the behavior of the system with certain changes.

Reworking the system (refactoring). The architecture of the system is constantly evolving. The current project is transformed, while ensuring that all tests run correctly.

This is where the fun begins. Extreme programming assumes that it is always possible to redo it, and at no great cost. However, practice shows otherwise.

Pair programming. All project code is written by two people who use the same desktop system.

The question arises: has anyone seen two completely identical programmers, each of whom, moreover, at the end of the working day would have time to write documentation for a partner? Is it possible to find such twin programmers who agree on everything?

And most importantly, why do we need such a pair of programmers? The reason, in general, is simple: not everyone can withstand the high pace of work imposed during extreme programming, an outflow of personnel is inevitable. Such a couple can provide some kind of insurance - if one quits, then maybe the second will bring the matter to an end. True, the remaining one will fall into an even tighter time frame - after all, the amount of work will remain the same, and there will be no understudy, at least for some time. This is followed by a natural process of transferring information to a new understudy, which again takes time. And so without end.

Continuous integration (continuous integration). The new code is integrated into the existing system within a few hours at the latest. After that, the system is reassembled into a single whole and all tests are run. If at least one of them is not performed correctly, the changes made are canceled.

This postulate is at least controversial, since it is not clear who will correct errors, not only local ones, but also induced wrong code. After all, complex tests are not supposed to be carried out at this stage, in addition, changes remain even if an error is detected. At the same time, Extreme Programming does not provide for a bug tracking system.

Collective ownership. Each programmer has the opportunity at any time to improve any part of the code in the system, if he deems it necessary.

Does this remind you of anarchy? How to find the author of the changes in this case? When developing a large project, did anyone meet such a “jack of all trades” and how long would such a “craftsman” manage to hold out in his workplace? That's right, not too long.

Customer with constant participation (on-site customer). A customer who is in the development team during the period of work on the system.

This, of course, is good, but the goal is not clear: either to dedicate the customer to the essence of the matter, or to make him a co-author? It is unlikely that only the customer will find such a highly qualified specialist.

40-hour week (40-hour weeks). The amount of overtime work cannot exceed one working week in duration. Even individual cases of overtime, repeated too often, are a signal of serious problems that require urgent attention.

As the practice of extreme programming shows (despite a number of positive examples given by supporters of this method), overtime with this approach is the rule, not the exception, and the fight against problems in this case is a constant phenomenon. It intensifies during the period of replacement of the current raw version of the product with another, again raw, version. The customer, who is initiated into the process, experiences all the charms of the manifestation of system errors on himself. How long do you think the customer will have enough patience in this state of affairs? He needs the system to work...

Open workspace (open workspace). The development team is located in a large room surrounded by smaller rooms. In the center of the workspace, computers are installed on which pairs of programmers work.

Moreover, all this, judging by the previous principles, should be located on the territory of the customer, since he is very actively involved in the development process. The question arises: is such a fortunate combination of circumstances realistic?

Nothing more than just rules. Members of the Extreme Programming team are obligated to follow the above rules. However, these are nothing more than rules and the team can change them at any time if its members have reached an agreement in principle on the changes made.

Perhaps, in the end, one useful rule will be developed: "first think, then do." In this case, we will have a scheme that is very similar to a "waterfall". For some reason, supporters of extreme programming are convinced that when using the "waterfall" and its clones, the development cycle must be long. It is not clear what is the reason for such confidence. After all, it is not forbidden to split the project into stages. For some reason, it is believed that planning will necessarily be one-time and unchanged, although in fact this is not true, including in the case of a “waterfall”.

As a result, we get a method that is potentially highly adaptable to highly changing project requirements, but at the same time not free from a number of serious shortcomings. The latter circumstance does not allow us to recommend this method to application for the projects demanding high or at least sufficient reliability of work.

ComputerPress 2 "2002

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

And now the interesting and full of creativity, projecting, creativity and creation part of the project is coming to an end. The harsh everyday life of defending your decision in a real atmosphere begins specific enterprise, and what is no less important, everything is also within the framework of the current legislation.

To start sold product must be deployed on equipment prepared for organizing 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 the information system are mounted in a single software and hardware complex, at the sites where its industrial use is planned.

In view of the fact that in major projects, a large amount of equipment is involved on which software is scattered across nodes, nodes and even clouds, then this process must be accompanied by full-scale documentation. For example, technical documentation includes tables with addresses of servers, workplaces, access methods, etc. For visual representation, component diagrams are used, which give an understanding of the location of network nodes, the distribution of components of their interaction, etc. But the measures that regulate all kinds of changes in the infrastructure, allowing to eliminate the consequences of failures of various elements of the system, must still be determined.

Figure 19. An example of a technical description of the implementation stage

This is all extremely important, since the next stage at these operational sites will be a lot of specialists from the implementation and support team, and they do not have to scavenge the information necessary for work from different, even well-informed, sources each time. Therefore, the documentation must be kept up to date and changed simultaneously with changes in the system settings, changes architectural solution and so on.

It is not out of place at the “combat” sites for the industrial operation of the system to deploy test benches that simulate work close to the real one. Well, all of a sudden there will be comments that require the release of new releases. All of course are professionals, responsible people and all that, but it’s better to drive updates first on a test bench. So just in case.

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

2. Training of the customer's personnel to work with the information system

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

Since a significant number of different employees of the customer may be involved in the training, which, in turn, to ensure the continuity of business processes, cannot be trained at the same time, which must be trained in different functional duties and for others good reasons, it is necessary to carefully plan the process of personnel training. It is also useful to divide learners into groups into categories requiring the use of different approaches and depth of training, based on the level of their initial preparedness. As a result, the drawn up training schedule should be agreed with all stakeholders, and approved by the customer's management as mandatory.

And we warned at the design stage that training the customer’s personnel is not only a very responsible task, but also a very laborious one…

3. Identification of shortcomings and defects of 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 actual “combat” conditions, the manifestation of unique combinations of business rules in real business processes, the features of the operation 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 at the initial stages does not in any way eliminate the need to work on old systems. That is, users duplicate data in both systems. Sometimes it is necessary to migrate existing up-to-date data from obsolete repositories to new ones, and the structure and format of information is usually very, very different. For example, if there is not enough information in the new data structure to fill in the required details, they are filled in with some data assigned “by default”, and then manually adjusted by users. And this is only a small fraction of what you have to deal with in real projects.

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

Considering all of the above, the trial operation stage is most often full of emotional outbursts and mutual claims, both between development teams and with customers. In this case, the role of architects and system analysts is very important, who must quickly localize the problem, propose a solution and coordinate it with all stakeholders. To perform such work, in addition to basic professional skills, it is also necessary to have the talent of a negotiator and knowledge of the basics of management.

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

4. Coordination of changes in the process of implementing the information system

If the operation of some functional modules of the information system does not critically meet the needs and expectations of the customer, and solutions are found to overcome these problems, then it is necessary to fix them and agree with the customer.

The stage 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 amounts pledged for similar risks in the project plan, it is necessary either to conclude additional agreements, or the team of performers will work at a loss. Often performers are called upon to quickly make changes, but they say we will take them into account and pay for the work on them later, in one package. But in fact, such cases usually lead to the fact that the customer later completely forgets his promises, and announces the work performed - the correction of their own mistakes by the performers.

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 the entire chain of subsystems. Otherwise, the occurrence of defects in the operation of the system as a whole is inevitable. This can manifest itself, for example, in the failure of the module of an adjacent team of performers, and the customer already declares them to be hacks and scammers. The truth will certainly come out, but the settler will remain.

And to paraphrase Jerzy Leca: “When we reached the bottom of the allotted time, there was a knock from below...”

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

5. Refinement of the information system based on the results of trial operation

If in the course of trial operation decisions are made and agreed on making changes to the developed hardware and software system, then on the basis of them, tasks are set for the performers to implement them. The process described in Section Part 3. Implementation of the design decision is repeated. But…

If at the system design stage we discussed the negative impact of the full use of the Scrum methodology (1) in large projects, then at this stage it fits perfectly. This is especially noticeable in projects in which the product handed over 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.

Strictly speaking, the moment has come when the following conditions are relevant:

1. The customer has already begun to actually work with the system, he has been allocated time for this, and now he clearly understands what he really needs. Accordingly, he is ready to work closely with the team of performers and he has a critical need for this;
2. For the most part, the documentation is already ready and its changes and additions can no longer be carried out so quickly, but can be drawn up after the fact based on the results of successful implementation.
3. Improvements mostly occur in separate modules, subsystems, circuits, 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 in the end, the project documentation is fully aligned with the innovations, and the team can easily find an up-to-date solution in it for analysis and design of subsequent changes.

Figure 20. - The stage of implementation of the information system

No comments…

6. Transfer of the information system to commercial operation

When during the trial operation all controversial 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 makes full payment for the work performed. The contract for the development and implementation of the information system can be considered fulfilled.

Implementation is moving into the phase of commercial operation. These relationships are most often legally regulated by a separate agreement or additional agreement to support the industrial operation of the system. Within the framework of this contract, preventive work can be carried out to diagnose the operation of system components, their interaction, elimination of minor failures, etc.

7. Section summary

The stage of implementation of the information system is the moment of truth of the entire process of its production and will mark the start of the most difficult 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 current release of the system being implemented, etc.;
2. Training of users to work with the system, including administrators, equipment maintenance specialists, etc.
3. Identification and elimination of shortcomings and defects identified during trial operation.
4. Coordination of changes in the operation of the system and bringing it in line with contractual obligations;
5. Signing documents on the fulfillment of contractual obligations. Making a full payment for the work performed;
6. Putting the system into commercial operation;

The introduction of corporate IS, developed independently or purchased from a supplier, is often accompanied by a break (redesign) of existing business processes in the enterprise. We have to rebuild them to meet the requirements of the standards and the logic of the system being implemented. We note right away that the introduction of IP solves a number of managerial and technical problems, however, it gives rise to problems associated with the human factor.

The introduction of an information system, as a rule, greatly facilitates the management of an enterprise, optimizes internal and external information flows, and eliminates bottlenecks in management. However, after the system has been successfully installed, "run in" in operation and has shown its effectiveness, some employees show a reluctance to use IS in their work. As a result of the reengineering, it becomes clear that some employees largely duplicate the work of others or are not needed at all. In addition, the introduction of CIS is accompanied by mandatory training, but, as shown Russian experience There are not so many who want to retrain. Breaking old skills and instilling new ones is a long and difficult process!

It must be clearly understood that corporate IP is designed to simplify the management of the organization, improve processes, strengthen control and provide competitive benefits. Only from this point of view it is possible to evaluate the benefits of its implementation.

Following this logic, it becomes clear that although corporate IS is generally intended to provide all users with the necessary information, managing the development and implementation of CIS is the prerogative of the company's top management! Do managers understand this?

Here, too, we have to deal with tenacious stereotypes. "Why do I need an enterprise system if the enterprise is doing well anyway?" "Why break something if everything works?". But most of the time it doesn't need to be broken. At the first stage, it is only necessary to competently and correctly formalize and transfer the identified processes within which the enterprise lives to the corporate IS. Such formalization will only hone, polish successful marketing and production discoveries, optimize the process of management and control, and allow targeted changes to be made in the future.

Introduction of a new IS - difficult process lasting from several months for small IS to several years for IS of large distributed companies with a wide range of products and a large number of suppliers. The success of a project for the development (or acquisition) and implementation of IS largely depends on the readiness of the enterprise to conduct the project, the personal interest and will of the management, a real program of action, the availability of resources, trained personnel, and the ability to overcome resistance at all levels of the existing organization.

To date, a standard set of methods for implementing IP has been developed. The main rule is to perform the mandatory phases in sequence and not skip any of them.

The following factors are critical for implementation:

availability of clearly defined project goals and IP requirements;

availability of a strategy for the implementation and use of IP;

· conducting a pre-project survey of the enterprise and building models "as is" and "as will be";

planning of work, resources and control over the implementation of the implementation plan;

participation of senior management in the implementation of the system;

· carrying out work on the implementation of IS by specialists in integrating systems together with specialists of the enterprise;

regular monitoring of the quality of work performed;

· quick receipt of positive results, at least in part of the implemented IS modules or in the process of its trial operation.

Before starting the development of an implementation project, you must:

· maximally formalize the goals of the IP implementation project;

estimate the minimum necessary costs and items of expenditure;

· establish a high priority of the implementation project over other ongoing projects;

Give the project manager as much authority as possible;

· to carry out mass educational work with the personnel of the enterprise in order to bring to everyone the importance and necessity of the upcoming changes;

· to develop organizational measures for the application of new information technologies;

distribute personal responsibility at all stages of implementation and pilot operation.

It is also necessary to define functional areas implementation of information system modules:

· organizational management;

organizational and administrative support;

management of business processes;

management, planning, financial and accounting;

· personnel Management;

Documentation management;

· Logistics management;

Managing relationships with clients and the external environment.

In addition to what is listed above, it is necessary to set technological requirements for the implementation of IS:

system platform - implementation and adaptation ready solution from the manufacturer or development to order in accordance with the technical specifications of the customer;

Integrability - data is stored and processed in a single information space; this ensures their completeness, consistency, reliability and reusability; the system may include newly developed and already used technologies and applications;

adaptability - the system is configured in accordance with the requirements of the customer and the features of the information field of the customer;

distribution - the system can effectively function in geographically remote divisions and branches of the enterprise;

· scalability - the system can be implemented in the form of a frame containing basic modules, and supplemented in accordance with the requirements of a changing external and internal environment.

The main phases of the implementation of the information system

Phase "Preliminary work on the preparation of the IP implementation project". During the pre-project survey of the enterprise, detailed information is collected about the structural organization of the organization, functional relationships, management system, about the main business processes, about the flows within the enterprise (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), necessary for building appropriate models and selection of objects for automation. The terms, resources, types and volumes of work, the range and cost of software, hardware and telecommunications, the cost of staff training, etc. are estimated.

Phase "Project preparation". After the completion of the first phase, preliminary planning and the formation of project launch procedures are carried out:

· formation of project and expert groups;

distribution of powers and responsibilities;

determination of organizational and technical requirements for the implementation process;

clarification of specifications and customer expectations;

· training of the implementation group, consisting of specialists of the customer's enterprise.

For some reason, the last, very important point is often missed when drawing up an implementation plan. But the success of the entire project depends to a large extent on it! After the start of funding, the project is considered launched for execution.

Phase "Conceptual study of the project". During this phase:

a conceptual design is formed and approved;

· a mandatory unambiguous understanding of the intentions of all project participants regarding the implemented IS is achieved;

· clarifies and concretizes the goals and objectives of the project;

the dimensions of the system prototype are determined;

· the consolidated work plan, the sequence of stages and conditions of trial operation, planning, financial and reporting indicators are agreed;

However, all of the above actions without fail documented, agreed and approved by all interested and responsible parties.

Phase "Project implementation". During the main implementation work, the system environment is created, installed and configured, system administration procedures are determined, the main software and hardware systems and applications are installed. The system sets up the organizational and staffing and organizational and functional structures of the enterprise using such organizational units as a branch, department, department, working group etc.

Installation, configuration and configuration of network and telecommunications facilities is carried out, data is transferred from the previous local systems and the formation of interfaces with legacy and external systems. In this case, all created models, plans, working software products, documentation are placed in the end-to-end repository of the implementation project (Fig. 3). An important part of this repository is the documentation system formed within the framework of the project (Fig. 4).

Systemic security issues of the system operation in multi-user mode are being worked out. Applications, templates, reports, client access forms are created, user powers are distributed. All systems are being tested in "combat mode" with the participation of all interested parties.

After the end of the implementation phase, the implementation project is considered completed. The information system is put into operation.

7. Success factors and reasons for unsuccessful IP implementations

modeling information reengineering business

According to world statistics, only a third of projects for the development and implementation of information systems are successful. Nothing is known about similar studies in Russia, but it seems that things are even worse here.

A successful project is completed on time, within the planned budget, and the intended results are achieved. What happens to other projects? They either drag on much longer than expected, requiring more and more funding, or an automated system is created that no one needs, and no one wants or can work with it.

Unsuccessful projects are very similar to each other. They seem to copy each other, playing the same scenario. Years of observation of bad practices prompted me to write a few rules for business leaders to help them avoid the most common mistakes in the implementation of enterprise management automation. They are equally well suited for budgeting automation projects, management accounting, production management and other fields corporate governance.

It must be emphasized that these tips are addressed primarily to the top management of the organization, that is, the owner or general director of the company, who act as? customers? changes in the field of corporate governance, including the creation of automated systems. Misunderstanding by persons? upper echelon? its role in such projects is the main reason for the failure of such undertakings.

First. Define the purpose of the project

According to the same statistics, seventy percent of unsuccessful projects became such due to the uncertainty of their goals. In other words, the end result was not clearly defined from the outset.

An example from practice. The head of the information technology service of one large holding company receives an assignment from the general director to implement an automated system to provide the top level of corporate management with timely and reliable information. CIO looking for software suitable for solving the tasks, refers to consultants. To our question about what problems prompted the company's management to implement an automated system, the following answer is given:

Lack of a unified format for presenting management accounting data.

Lack of regulations for the formation of management reports.

lack of a unified information environment

It is clear that the first two?problems? are not related to automation, and the latter is not a problem, since the existence of a? unified information environment? in itself no practical use does not represent.

Acquaintance with the real state of affairs in the company led to the understanding that there is a problem of delegating the powers of the head of the corporation to the managers of business units. It should be solved with the help of controlling, based on regular planning and management accounting, as well as the correct motivation of managers. In other words, should we first of all talk about setting up management processes at the corporate level, and only after that? on the automation of these processes. Realizing this, the company's leaders saved a lot of money by abandoning pointless automation.

A deep understanding of the goals of the project may lead to the rejection of its implementation or the postponement of its deadlines due to the revision of priorities.

Automation goals need to be formulated not in terms of technical advantages but in terms of business interests. They can be defined, for example, as follows:

· reduction of stocks in a warehouse due to more exact planning of production and purchases;

Reducing accounts receivable information support work with debtors;

· implementation of a larger number of investment projects due to the exclusion of routine operations performed by qualified managers.

This definition of goals will allow you to understand why you are doing this, how much you are willing to pay for solving these problems, and, very importantly, to get project success criteria against which you can evaluate the final results.

Second. Open a project

Implementation of an automated system is a strategic project of the company. It must be opened by order of the General Director. The order defines the goals and deadlines of the project, appoints a project manager.

An example from practice. The head of a large bank instructs the manager of financial management to take up the implementation of a budgeting system. Despite the fact that more than a year has passed since the appointment, the appointed manager does not understand what powers he has in connection with this assignment, what results and in what time frames are expected from him. The project seems to exist, but things are not moving.

In other words, you need to clearly understand what the project? it is a full-fledged organizational structure, temporarily created within the organization to achieve well-defined goals.

The leader appointed by the CEO forms the project team. It should include heads of departments and specialists interested in the final result and competent in the subject area of ​​the project. So, if a budgeting system is being implemented, then the project team is made up of managers and specialists from financial and IT services, as well as representatives of production and sales departments. The project manager should be a manager who occupies a higher position in the organizational structure of the enterprise than any member of the project team.

Third. Provide the project with resources

Key Resources It's money and people. Therefore, it is necessary to approve the project budget.

Grade necessary resources- not an easy task, and yet at the project justification stage it is important to understand what budget is considered acceptable for development management technologies and introduction of an automated system. The fact is that the solution of any problem is a triangle: money - time - result. If the desired result is precisely defined, then it is possible to calculate the time required to achieve it and the budget. If there is no clear idea of ​​what is a “good result” (that is, the goals of the project are not precisely defined), then you can go from the budget and solve the problem in this form: what maximum management effect can be achieved if you invest a certain amount to set up processes management and implementation of information technology?

In addition, it is important to allocate a part of the working time of the people involved in the project to perform work related to the implementation of the system. Otherwise? turnover? ruin the business. It is a widespread practice that employees are assigned to implement new system controls? optional?. Since their main workload is not reduced, they treat additional work either as a hobby or as an annoying burden, depending on the degree of their interest. This attitude is quite natural, because the company's management, having entrusted them with unpaid extra work, demonstrated his own attitude towards her, as to something secondary.

Control by human resourses The project involves budgeting the time of the performers. Accounting for the actual time spent is needed not only for adequate remuneration of the performers, but also for the correct assessment of the costs of the project.

Fourth. Take care of motivation

Motivation- a key element of management, so you should carefully consider the motivation scheme for project performers. It does not have to be big bonuses for the successful implementation of the system.

Most often, the introduction of a new management system helps to raise the status of the participants in this work, increases their professional level. These are very significant incentives. The fact is that people of a creative warehouse consider work as a means of increasing their intellectual capital. Such specialists are the most valuable for any business related to innovation.

It is important for the manager who forms the project team to correctly understand the expectations of the performers associated with the success of this business. It could be career, salary increase, gaining new knowledge, reaching new heights in professional growth.

Fifth. Management support

Success is possible only if the project is strongly supported by the top management of the company. If CEO believes that the introduction of an automated system- this is only an IT service business, then nothing good will come of it.

implement information Technology- means not just installing programs on workplaces. Such projects are associated with changes in work and management processes, redistribution of responsibility and authority. These changes often come into conflict with the interests of certain heads of departments and employees. The result is sabotage or open opposition to change. Therefore, the head of the organization must clearly show whose side he is on and, if necessary, crush resistance with a firm hand, supporting the project team.

Sixth. Break the project into stages

Long term project is best"cut into pieces", and do not proceed to the next stage without making sure that the tasks of the previous stage are fully completed. It is very important to determine what should be the result of each stage of the project.

So, for example, when it comes to creating an automated budget management system, the sequence of steps shown in the figure is recommended.

You can proceed to the next stage only after the following three conditions are met:

· the project team has developed a common understanding of the results of the stage;

· this understanding is formalized in the form of a document;

The results of the stage are accepted by the customer, that is, the head of the enterprise.

This approach allows you to control the risks of the project, moving progressively towards the intended goal.

Seventh. Manage goals and expectations

The goals of the project can be adjusted or even significantly changed in the course of work. This is common practice. The situation changes, our understanding of the situation changes, and we come to the conclusion that our previous views are outdated, or were erroneous. Therefore, you need to regularly (at each stage of the project) return? to the origins? and critically examine all the underlying premises.

And the last. You need to have the courage to close the project if it becomes clear that he has reached a dead end. The project manager who initiated the termination of a hopeless project deserves encouragement as a responsible manager who prevented the waste of enterprise funds.

Phase "Preliminary work on the preparation of the IP implementation project". During the pre-project survey of the enterprise, detailed information is collected about the structural organization of the organization, functional relationships, management system, about the main business processes, about the flows within the enterprise (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), necessary for building appropriate models and selection of objects for automation. The terms, resources, types and volumes of work, the range and cost of software, hardware and telecommunications, the cost of staff training, etc. are estimated.

Phase "Project preparation". After the completion of the first phase, preliminary planning and the formation of project launch procedures are carried out:

formation of project and expert groups;

distribution of powers and responsibilities;

determination of organizational and technical requirements for the implementation process;

clarification of specifications and customer expectations;

training of the implementation group, consisting of specialists from the customer's enterprise.

For some reason, the last, very important point is often missed when drawing up an implementation plan. But the success of the entire project depends to a large extent on it! After the start of funding, the project is considered launched for execution.

Phase "Conceptual study of the project". During this phase:

a conceptual design is formed and approved;

a mandatory unambiguous understanding of the intentions of all project participants regarding the implemented IS is achieved;

goals and objectives of the project are clarified and concretized;

the dimensions of the system prototype are determined;

an enlarged work plan, a sequence of stages and conditions for trial operation, planning, financial and reporting indicators are agreed;

At the same time, all these actions are necessarily documented, agreed and approved by all interested and responsible parties.

Rice. 3. Approximate content of the implementation project repository

Phase "Project implementation". During the main implementation work, the system environment is created, installed and configured, system administration procedures are determined, the main software and hardware systems and applications are installed. The system sets up the organizational and staffing and organizational and functional structures of the enterprise using such organizational units as a branch, department, department, work group, etc.

Installation, configuration and configuration of network and telecommunications facilities is carried out, data is transferred from previous local systems and interfaces are formed with legacy and external systems. In this case, all created models, plans, working software products, documentation are placed in the end-to-end repository of the implementation project (Fig. 3). An important part of this repository is the documentation system formed within the framework of the project (Fig. 4).

Systemic security issues of the system operation in multi-user mode are being worked out. Applications, templates, reports, client access forms are created, user powers are distributed. All systems are being tested in "combat mode" with the participation of all interested parties.

Rice. 4 Approximate composition of documentation on the process of IS implementation

After the end of the implementation phase, the implementation project is considered completed. The information system is put into operation.