Trial operation task is to test algorithms, programs and links technological process data processing in real conditions.
Trial operation of tasks is carried out on the basis of real information; at this stage, the developer trains personnel to work on a computer using a specific program.
Pilot operation of subsystems is carried out for the purpose of a comprehensive check of all its elements, the preparedness of the information base, debugging the technological process of collecting and processing information, training personnel to work in the conditions of the subsystem functioning. Trial operation of the subsystem should be carried out on the basis of the full amount of real information in the established mode of operation with the necessary duplication of work. The commissioning of the subsystem for commercial operation is carried out after the commissioning of the tasks of the launch complex of this subsystem for trial operation.
Pilot operation of the IS is carried out for the purpose of a comprehensive check of the functioning of the tasks of the system, checking the readiness of the supporting part of the system for functioning, final debugging of the technological process of collecting and processing information. Trial operation of the system should be carried out on the basis of the required amount of information about the activity of the object in the established mode of operation. After the completion of the trial operation of the system, a report on the implementation is carried out.
Pilot implementation consists of:
1. Preparation of initial operational data for all complexes of this project
2. Entering this data into the PC and performing software overclocking
3. Analysis of the results obtained to identify all errors and inaccuracies.
With positive results of trial operation, the system is put into commercial operation. In the course of commercial operation, the analysis of the functioning of the system is carried out, the effectiveness of the implemented design decisions in the conditions of its industrial operation, development of recommendations for the further development of the system and the formation of standard solutions.
Analysis of the functioning of the system provides for checking:
— Functioning of technical means
— Functioning of tasks and subsystems in conditions of automated processing
— The action of personnel in the conditions of the functioning of the system
The results of the analysis are used to assess the quality of the system and its actual economic efficiency. Work on the analysis of the functioning of the system is carried out by the developer in the order of field supervision on the basis of an agreement with the customer after a certain period of operation of the EIS. Author's supervision is carried out at the expense of funds allocated for the creation of the system. The analysis work program is drawn up by the developer and agreed with the customer. Analysis of the functioning of the system begins after the issuance of an order to carry out this work. The order indicates the terms and objects of the survey, as well as appointed by the representative of the customer involved in this work and the person responsible for the timely and complete submission necessary materials system developer. Collection of all data, filling in the necessary forms, registration in the journal is carried out by the customer's representative and controlled by the developer. The accumulated data is transferred within the time specified in the program by the representatives of the developers for development. The results of data processing for each investigated element of the EIS are recorded by the developer with the participation of a representative of the customer. Based on the completed protocols, the developer, after completing all the work provided for by the program, draws up a report on the analysis of the functioning of the EIS.
Delivery of a report on the analysis of the functioning of the system to the customer is the final stage of the developer's work. In the process of analyzing the functioning of tasks, subsystems and actions of personnel in the context of the implementation of EIS, work is carried out similar to the survey of an object in terms of the parameters of each function of the EIS subsystems, taking into account the complex of technical means used and the following factors:
- Timeliness of receipt of the necessary information to the management personnel;
— Increasing the reliability of information;
— Improvement of technical and economic performance of the enterprise.
The quality of functioning of individual subsystems is assessed in terms of reliability and timeliness of information, improving the quality of relevant management decisions. Based on the results of the analysis of the functioning of the system, proposals are developed for the further development of the EIS.
IT Management System: Three Components…
In the context of this issue, under the IT management system we mean an automated system for managing the activities of the IT department, built on the basis of specialized approaches, methodologies, standards and software solutions for the IT industry. The conceptual basis for building such a system is the "service approach", that is, the organization of the management of the IT service as a service unit and the orientation of all personnel work towards providing services to the business. Therefore, such a management system is often referred to as an "IT Service Management System", and its implementation is referred to as "Implementation of an ITSM solution" or "ITSM project".
The IT management system is, of course, not limited to automation tools. The end result of an ITSM project is a working turnkey IT management system. This is a combination of three components - "processes", "people", "automation tools". When we talk about commercial implementation or the provision of implementation services, all these components, as a rule, are included in the contract with the contractor (system integrator, consulting company) as formal delivery objects.
“Processes” is the so-called process documentation, that is, a whole range of organizational and administrative documents that describe and establish the rules for the work of IT department personnel, areas of responsibility and the procedure for interaction. Conceptual basis modern system IT management (along with the already mentioned service approach) is process management combined with the industry model described in the ITIL library. A specific ITSM project covers one or more interrelated processes, for which process documentation is being developed.
“People” are the people in the IT department who participate in the implementation process and then become users of the system. They are the bearers of experience and knowledge of specific technologies and practices of the organization and make a significant creative contribution to the design of the system.
"Automation tools" is a complex of technical and software tools that automate activities within processes. We will not pay special attention to the software itself, we will only say that there are many specialized industry-specific software solutions on the modern market.
For Jet Infosystems, the flagship solutions are (in alphabetical order) the BMC Remedy ITSM Suite and HP Software Service Management Center product lines. Thus, the implementation of an ITSM solution is a purposeful change in the three components of the IT management system: normative documentation, staff skills and automation tools for a limited number of activities (processes). After making a fundamental decision on the need to change the IT management system (launching an ITSM project), the planning stage begins. Here the key parameters of the project are set, its constituent parts (tasks) are identified, the required amount of resources is determined, the sequence of work is carried out, and the budget is set.
At this stage, the organization makes a number of important decisions. First of all: what forces to implement the project, independently or with the involvement of consultants? What software to use? To answer these questions, there are a sufficient number of sources to help the organization, including research, ratings and reviews of the owners of such systems. Common tools for finding the best solutions are requesting technical and commercial proposals from leading integrators, organizing technical presentations and demonstrations from various vendors, launching "pilot" projects to compare platforms.
With a careful approach of organizations to planning in terms of choosing software tools and a team of performers, in most cases the technological aspect of project planning remains behind the scenes: what will be taken as the basis of the system being created, to what extent and how this basis will be finalized to obtain the final result. As a rule, the question of choosing the method of development and implementation at the stage of project preparation is not raised explicitly, this method is, as it were, hidden inside the detailed project plans and remains at the discretion of the contractor.
In our opinion, an insufficiently clearly defined choice of development method entails high risks of unavoidable deviations from the plan (that is, those that require significant rescheduling and clarification constituent parts project). An open discussion and agreement on the expectations of the customer and the contractor regarding the implementation method will help to reduce the impact of such risks.
… and three implementation options
With all the variety of platforms and wealth functionality, presented on the market of specialized software tools of the "industrial" class, the organization has at its disposal only three alternative ways to use them to build a management system. Let's call them conditionally: "Decision from the manufacturer", " best practice” and “Individual solution”.
"Solution from the manufacturer" - installation of an automation system "out of the box" and the start of work according to the reference technological schemes of the manufacturer (with subsequent fine-tuning in the process of maintenance). This is the fastest and cheapest way to organize work in a new way.
“Best practice” is the installation of a standard solution, created in advance by the integrator company based on its experience. This is the most guaranteed way to get a really working system.
"Individual solution" - development of an individual solution, starting with the process model and process regulations and ending with the features of user interface settings. This method best allows you to take into account the wishes of employees and the developments available in the organization.
When choosing a solution from a manufacturer, the organization receives an automation system with pre-configured business logic and documentation included in the standard license delivery package. The integrator's work on setting up such a solution includes installation and testing on the customer's hardware complex, input of reference data on the location of service objects, organizational structure, services, users. It also integrates with the mail system to send alerts. This is usually enough to start training employees and operating the management system.
"Best practice" (the author's solution of the integrator company) provides, at a minimum, a convenient, not overloaded user interface and a set of automated functions sufficient for operation. In addition to installing and filling out manuals, the implementation of such a solution implies some adaptation of process documentation and refinement of the automation system, mainly with configuration tools, rather than programming. Key prerequisites for successful implementation: a correct assessment of applicability for a particular industry and customer, the presence of a simple and beautiful interface, high quality documentation and operational reliability.
The first two options ("manufacturer's solution" and "best practice") have much in common. These are ready-made solutions that are not developed within the framework of the project. Implementing them essentially starts with deployment and training. Implementation plans for such solutions are developed in advance, tested many times and do not change from project to project. If an organization has gone for one of these management system modernization options, the most critical project issues are choosing the right vendor (platform) and the right integrator.
Select "Custom solution". How will we do it?
The least predictable and therefore more interesting for consideration from the point of view of the project participants is the “Individual solution”, within the framework of which, first of all, the design and development of a system specific to a particular organization takes place. Projects for the implementation of individual solutions can vary significantly in terms of cost and timing. In our experience, the most significant factor here is the way the project is organized.
As methodological basis design and implementation of individual solutions, in general, project management standards, standards and basic regulations software life cycle management, as well as software design methodology from well-known manufacturers (Microsoft, Oracle, HP, BMC, etc.). Based on them, the integrator company forms its own profile of standards and methods that regulate the processes of design, development, operation and development information system. All these standards and methodologies are adapted and concretized in relation to certain classes of projects, in our case, ITSM projects.
Rice. 1. Product map
The result is a set of concrete guidelines, requirements, properties and quality indicators that characterize the way of organizing the development and implementation of the system. Another part of the characteristics of an individual solution - mainly functional and technical - is creatively determined by the customer and the contractor already in the development process.
Thus, even for an individual solution at the project planning stage, a significant part of the design decisions is predetermined and known to the contractor. Therefore, it makes sense to put the discussion of the development method on a par with such project preparation issues as the choice of platform (vendor) and the choice of architecture.
In what sequence will the results of the project be obtained? How will customer comments be formed and collected? In what order and to what extent will comments be accepted and eliminated? These and other questions that characterize the method of organizing the project used by the contractor can be put
at the planning stage, including in order to more accurately compare competitive offers and choose the best one.
The main question of the development method: how do we get the products of the project? In order to understand it ourselves, to tell the customer about it, and, the most difficult thing, to realize our plans, we use project product maps. A product map is a diagram of the intermediate and final results of design work, which determines what and in what order will be produced during the project (see). The methodological basis for building a product map is the Product based planning method from Prince2, which is used to develop the Work breakdown structure.
Our maps are "drawn" by the stages of the project, on which the products of the project are applied in the form of rectangles. Rectangles are connected by links, the links determine on the basis of which products the following products are developed. Thus, the product map determines the manufacturing technology of the control system.
All products can be divided into two groups. The first group is "external", which are provided to the customer. The second one is “internal”, which is necessary for the project team as a technological component, as a rule, in order to get one of the “external” products.
We use another classification of products: “mandatory” and “optional”. The “mandatory” products include products whose development is necessary from a technological point of view (without them, the final result of an ITSM project cannot be obtained). "Optional" refers to products that could be dispensed with. "Optional" products are included in the product card, as a rule, at the request of the customer.
The composition, sequence and interrelations of products that make up the main value of the map are determined heuristically, it is hardly possible to imagine a universal algorithm for compiling such a map. This is the result of many years of implementation experience, a huge number of mistakes, fundamental ideological disputes, sudden discoveries, trials that have passed the test of time and real projects.
Based on the product map, you can clearly show the main differences and features of the considered development method. Most of the projects we have implemented can be attributed to one of two ways of organizing work. Let's call them conventionally "Classic" and "Iterative" and consider each separately.
Each product example in the article is described in the following way:
- The form;
- Appointment;
- Content;
- Options, recommendations.
The "classic" way to implement an IT management system
The essence of the "classic" implementation method is the stage-by-stage development of the system, starting with research subject area and ending with the implementation of the turnkey system and further support. We highlight (and map) the following stages of the project:
- examination;
- Design;
- Development;
- Deployment;
- Pilot-industrial operation;
- Commissioning;
- Technical support and maintenance.
In the case of the “classic” method of implementation, the stages are very important, since the results obtained at the end of the stage (project products) form the basis of the next stage, and their revision is almost impossible without making changes to the project. Consider the main products of the project at each stage.
Stage 1: Examination
The objectives of the survey stage are two: to get an idea of the current practice in the subject area and to clarify the problem statement. The main output of the stage is the survey report. If you follow the map, the first product of the stage is the "Structure of the object of management" (another name is "Survey Model"). It is not issued to the customer, it is an “internal” product. In it, according to the same scheme “people - processes - automation tools”, it is fixed: what needs to be investigated as part of the survey, what documents to receive and study, with what people to interview, what automation tools used by the customer to consider.
survey report
The form
Text document (mainly), presentation.
Purpose
The survey report is the most interesting and interesting to read project document. At the beginning of the project, the report is useful for creating an atmosphere of mutual understanding in the joint project team "Customer - Contractor": consultants demonstrate an understanding of the specifics and priorities of the organization, and customer representatives accept and agree to use the terms and tools of ITSM projects, for example, "role process structure" and maturity level.
The second life of the "Report" begins at the end of the project, when it is required to demonstrate the effect of the introduction of a new system (it was - it was). In the future, after the control system is put into operation, it becomes unnecessary and is practically not used.
On the basis of which it is developed
Consultants prepare a report based on their notes made during the interview, as well as on the basis of the collected documents of the organization: regulations, instructions, and so on. Accuracy and quality are proportional to the qualifications of consultants and their number per interview (one consultant is bad). If a survey was conducted during the survey (which happens not every time), the results are processed and included in the report in an aggregated form.
A typical report is conditionally divided into three main blocks: general information, description of the current situation, conclusions.
General information is the stated objectives of the survey, the boundaries of the survey (organizational and functional), the list of documents used and the interviewees. It also provides a description of the survey methodology, including methods of collecting information, methods of grouping and generalization, methods and evaluation criteria.
The description of the current situation is a structured presentation of the current practice "as is", sometimes using graphic diagrams and drawings. For all surveyed areas of the organization's activities, a single description structure is used. For example, like this:
- Organizational and role structure;
- Process activities;
- Documentation support;
- Information Support;
- Means of automation.
Often, the section includes management requirements and suggestions for improvement collected during the survey, if possible, without changing the wording.
The “Conclusions” section contains the results of the analysis of the current situation. Almost always, these are the results of assessing the level of maturity of the processes, as well as the identified "bottlenecks" and the risks associated with them.
After the “Conclusions” section, it seems logical to have some recommendations, however, in the context of the ongoing ITSM project, this can be saved: the project has been launched, the budget has been approved, the requirements have been formulated - it's time to start designing.
The client's project team is often interested in the content of interviews that consultants conduct with senior IT management and business representatives. To satisfy such interest, it is recommended to coordinate with the management in advance the publication of the topics discussed in the report or the presence of the customer's project team leader for an interview.
Based on it, an intermediate product “Survey Plan” is developed, and the “external” product “Survey Schedule” is derived from it. The product "Inspection Schedule" is considered ready when it is agreed with the customer. At this point, we have a clear idea of how the examination will take place. Following on from the Survey Plan, the "internal" product is the set of materials that make up the Survey Results—everything that is collected as part of the survey. Next, a “Survey Report” is produced - the main result of the stage. The “optional” product “Presentation of survey results” can be derived from it.
Stage 2: Design
The purpose of the design phase is to propose and agree with the customer organizational and technical solutions that will form the basis of the IT management system being created. The main results of the stage are the “Model of the IT management system” and the “Descriptions (regulations) of processes” detailing it.
Process Model
The form
Text document, presentation (mostly).
Purpose
The process model is a set of key characteristics of the control system being created. These are the most costly design elements of a future system that need to be decided early in the project to avoid significant rework. The process model is compact, contains only what is important, and is convenient for discussion and agreement.
On the basis of which it is developed
The initial constraints in the development of the process model are the definition of the project in the organization and the corresponding provisions of the contract with the contractor. As a rule, the composition of processes - subsystems of the future control system - is predetermined. The goals of the project are known and approved, for example, “Implementation in the Department of an IT process approach focused on business needs. Implementation of elements of the global "best practice" of IT management".
The external sources used in the development of the model are accepted standards, “best practices”, and previous experience team members.
The main project source of development is the survey report, or rather a description of current practice and bottlenecks in it. The new model should retain well-functioning management practices and address weaknesses.
In describing the process model, it makes sense to rely on the widely used division of the system into three components - "processes", "people", "automation tools".
For each process, as a rule, the model captures the following decision elements:
- Terms and Definitions;
- Profile of applicable standards and management practices;
- Target maturity level and its characteristics;
- Process goals;
- Inputs and outputs (results) of the process;
- Information objects;
- Types of activities, the general scheme of the process.
The set of other key characteristics (in other words, “policies”) included in the model is specific to each process. For incident management, this can be the number of support lines, the organization of the help desk (centralized or distributed, resolving or logging), supported methods of contacting the help desk.
As part of the role structure of the system (“people”), the model defines the composition and responsibility of roles for the types of activities of the processes. For each role, the possibility of appointing or hiring staff should be assessed. If it is necessary to change the organizational structure, this must be explicitly indicated.
As for automation tools, if they have not yet been selected and purchased by this moment, then the process model includes a list of software tools planned for use and determines the need for and methods of integration with related systems (data sources about employees, inventory systems, mail program, etc.). .d.).To prevent the process model from becoming marketing material or, say, a project team self-report (which we would like to save money on), it is recommended to include those elements of the system for which alternative design options have been discussed.
The model is the central product of the stage. The development and approval of the model takes place in several iterations with the involvement of the widest working group of the customer. Mistakes made during the development of the model will definitely make themselves felt in the subsequent stages of the project. The price of the issue: at least a significant processing of already obtained results and customer dissatisfaction. On the basis of the agreed model, “Process Schemes” are developed as an intermediate step in the development of “Descriptions (regulations) of processes”.
Process regulation
The form
A text document containing graphic diagrams.
Purpose
After reading the regulations, process participants and interested parties (for example, auditors) should get an idea about the following things: for what purpose and what actions are performed in the process (without a detailed description of how exactly) and who is responsible for what.
On the basis of which it is developed
A semi-finished product for the development of regulations is a process model. Previously agreed activities are divided into procedures, the participants in the procedures and those responsible are determined. The procedures themselves, conditional and unconditional transitions between them are described, in more detail - at the points of transfer of control.
The regulation is a logically related formal description of the activities of the process with an indication of those responsible. Here is an approximate structure of the regulation (let's take incident management):
- Terms and Definitions;
- General provisions:
- Goals and objectives of the process;
- Process benefits;
- Scope and boundaries of the process;
- Inputs to the incident management process;
- Outputs from the incident management process;
- General scheme and description of the process;
- Process Tools;
- Roles and responsibilities of process participants:
- Functional roles;
- Responsibility Matrix;
- Process regulation:
- Reception and registration;
- Classification and primary support;
- Appointment;
- Permission, execution;
- closure;
- Ownership;
- Process Metrics:
- Components and reports provided by the process;
- Annex A - Classification Rules;
- Annex B - Rules for determining priorities;
- Appendix B - Escalation Rules.
In order for the regulation to be used for its intended purpose, that is, to be read to the end, it is recommended that all distracting details that violate a logically connected description be placed in applications or other documents (specifications and instructions).
Stage 3: Development
The purpose of the development stage is the creation of automation tools and the development of process documentation.
On the basis of "Descriptions (regulations) of processes" "Process specifications" are developed. For each management process in the system, three specifications are developed: "Workflow Specification", "Metrics Specification" and "Integration Specification". On their basis, "SA Testing Scenarios" are developed.
Process specification
The form
Text Document.
Purpose
The process specification details the provisions of the regulation. If the regulation establishes what and in what sequence is performed in the process, then the specification answers the question: how exactly and with what results the procedures are performed. As a design document, the specification contains the basic functional requirements for developing an automated system. In the future, it is used as the basis for compiling test scenarios and work instructions for process participants.
On the basis of which it is developed
The specification is developed on the basis of the regulation and details its procedures, taking into account the limitations and capabilities of the selected automation tools.
In the specification, process procedures are divided into a sequence of steps - elementary operations of process participants (system users). The structure of the procedure description is approximately the following:
- Procedure description:
- Number (identifier) of the procedure;
- The name of the procedure;
- Description of the procedure (from the regulations);
- Responsible executor (role);
- Entering the procedure (an event that activates the procedure);
- Operations.
For each operation, specify:
- Operation number;
- The name of the operation;
- Actions taken;
- Operation result.
After the introduction of the control system into operation, in order to reduce maintenance costs, it is recommended to make changes first to the regulations and specification, and then “cut” instructions and scenarios from the specification.
Parallel work in progress for the creation of automation tools: an intermediate product is created “CA Base Stand (automation systems)”, then “SA Work Stand” - by setting up the base stand according to the specifications. The “external” product “SA Experimental Bench” is obtained on the basis of the “SA Workbench” and the “SA Testing Scenarios” set: through the efforts of a team of testers and engineers, the automation system is brought to readiness for demonstration to the customer, training and trial operation.
Based on the specifications and the "SA Experimental Stand", a set of products "SA User Instructions" is being developed. The resulting "external" product of the stage is a "Demonstration of CA" to the customer's project team.
Optional "external" products at this stage can be: "Terms of Reference" (based on specifications), "Test Method" (based on "Test Scenarios"), "Scorecard Description" (based on a set of "Specifications of Metrics").
Stage 4: Deployment
The purpose of the deployment phase is to prepare the control object for an experimental or experimental industrial use automation systems.
Pilot (pilot) operation plan
The form
Text document, plan in MS Project.
Purpose
The document serves as a tool for planning and organizing joint actions of participants to ensure the achievement of trial operation goals within a specified period (usually from two weeks to one and a half months).
On the basis of which it is developed
The plan includes two major sections: the rules for conducting trial operation and the plan itself.
The pilot operation procedure answers the following questions:
- What goals are to be achieved?
- What is the time frame for trial operation?
- Which departments and employees are involved?
- What roles in the processes are assigned to them?
- What kind teaching materials available to members and where are they published?
- To whom and on what questions to contact, in what terms and how?
- In what mode are “old” systems and technologies used?
- Will changes be made to the system during trial operation?
The trial operation plan includes a list of stages and tasks indicating the responsible, duration and timing for each event. Examples of such activities can be “launching and testing the receipt of user requests using the Web interface”, “conducting a configuration audit”.
The results of this stage are mostly "external" - visible to the customer. If you follow the usual structure of "people", "processes" and "automation tools", these are the following products: "Trained personnel", " Organizational events” (to launch and start operating the IT management system) and “Automation Tools” deployed at the customer’s site. To obtain these results, a “Training Plan”, “SA Deployment Plan”, “Plan for Issuing Orders and Orders” on the start of pilot operation are developed and agreed with the customer. In parallel, in the interests of the next stage, an “external” product “Pilot Operation Plan” is being developed.
Stage 5: Pilot operation
The purpose of the pilot phase is to test the IT management system in working conditions at the customer's site. On the basis of the Pilot Operation Plan, during the stage, an “internal” product “Pilot Operation Results” is formed, on the basis of which the “external” products “Pilot Operation Report” and “Remarks and Improvements Protocol” will be prepared. An “optional external” product of the stage could be a “Presentation of Pilot Operation Results”.
Stage 6: Commissioning
The central event of the commissioning phase is the introduction of the IT management system in production mode. To do this, it is necessary to eliminate the comments formulated at the stage of pilot operation. On the basis of the “SA Experimental Stand” and the “Remarks and Improvements Protocol”, an “external” product “SA Industrial Stand” is being developed. The resulting stage and the project as a whole is the "external" product "Presentation of project results".
After the completion of the project: Technical support and maintenance
From the point of view of planning and organization of work, technical support and maintenance of the IT management system has a process rather than a project nature, and is built according to different rules. Therefore, on our map, the products of the project related to support and maintenance activities are not reflected.
Thus, with the help of the product map, we examined the technology for the implementation of the project for the development and implementation of an “individual solution” for an IT management system according to the “classic” scheme. It should be noted that for simplicity of presentation, the composition of the project products has been simplified. In the real maps that we use, several intermediate products can be provided for one product of the project. For example, the "Product" first becomes the "Product Draft", then, after internal acceptance, the "Product Design" and only after agreement with the customer - the actual "Product". In other words, the map can display not only products and their relationships, but also life cycles individual products.
Having compiled such a product map, you can proceed to drawing up a project plan, for example, using Microsoft Project. Project products in the plan will be presented in the form of milestones that need to be detailed design work. This requires each set of incoming product links to be formulated as tasks for manufacturing a product based on the previous ones. Estimating the duration of the resulting project tasks, we get the basic plan of the project.
"Iterative" way to implement an IT management system
The "classic" method of implementation is the most common on the market consulting services, is widely popular and time-tested. Nevertheless, it has one drawback, or rather a feature that in today's conditions is becoming increasingly important for both the customer and the contractor. It's about duration. Projects for the implementation of control systems in the "classical" way are rarely implemented in less than three months. On the contrary, it is not uncommon for such projects to last more than a year. During this time, the external conditions in which the company operates may change,
as well as plans, business priorities. The idea of IT service managers about how the management system should work is being transformed. All these factors, as well as planning errors, accumulate and lead to the fact that in the middle and late stages of the project there is an increased desire to reduce the backlog to the detriment of either the quality or quantity of the project products.
The "iterative" way of implementation significantly reduces the impact of these risks. It is aimed, first of all, at the possibility of adjusting the implementation progress, assuming a revision of future plans at each iteration.
It is obvious that the result of the "iterative project" on the formal objects of delivery should not differ from the "classical project". Let's bring general scheme formal set of delivery items:
- People:
- Survey participants;
- Participants in the design of the control system;
- Trained;
- Participants of pilot operation;
- Processes (documents):
- Survey report;
- Process Model;
- Schemes, descriptions (regulations) of processes;
- Specifications;
- Instructions for the system administrator, documentation for the automation system;
- Automation tools:
- Basic stand of the automation system;
- Work stand of the automation system;
- Experienced stand of the automation system;
- Industrial stand of the automation system.
All of these products must be obtained within the framework of the “iterative project”, just as they are obtained within the framework of the “classic project”.
Iteration implies repetition. In our case, the following groups of tasks will be repeated:
- Research (subject area);
- Determining the boundaries of the result of the iteration (release);
- Release development, which includes:
- Development;
- Testing the result by the developer;
- Testing the result by the task manager;
- Acceptance of the release by the task manager;
- Acceptance of the release by the customer.
Obviously, "acceptance of the release" both in the mini-development cycle and in the main iteration cycle leads either to a transition to a new iteration, or to a repetition (to some extent) of the current one in order to eliminate deficiencies.
So, we have described what needs to be obtained (products of the project) and how we are going to do it (one iteration cycle). It remains to show how many iterations the product will be developed, and to detail the work within each iteration. We believe that the optimal number of iterations will be three, the fourth and subsequent iterations may well be performed within technical support and maintenance of the IT management system. Just as for the "classic" development method, let's consider the logic of obtaining the main products of the project in the context of three iterations of the project.
Iteration 1: Development of a pilot release (1.0)
The group of design tasks "Research" within the first iteration includes a large amount of work that, in the "classic" development, is performed at the stages of survey and design:
- examination;
- Model development.
Then the group of design tasks "Determining the boundaries of the release" is performed, which will include the following works: - Definition of release boundaries in terms of workflow, metrics and integration;
- Reconciliation of release boundaries.
The tasks included in the "Development" group are performed to obtain a prototype of the system, ready for demonstration to the customer.
The first iteration of the development is completed by the group of design tasks "Acceptance", which will include the following works:
- Demonstration of the release to the customer's working group;
Thus, under predetermined conditions and restrictions, we get a kind of complete, working solution (pilot release), which includes the following products:
- Customer personnel involved in the survey;
- Customer personnel involved in the design of the control system;
- Survey report;
- Model;
- Process schemes;
- Specification set;
- Agreed release boundaries 1.0;
- SA work stand.
Iteration 2: Development of a beta release (2.0)
The group of project tasks "Research" within the second iteration has a significantly smaller scale than for the pilot release, and includes one task:
- Release Test working group customer.
The group of project tasks "Determining the boundaries of the release" consists of the following works:
- Reconciliation of release boundaries.
- Making a decision to refine the release or move to the next iteration.
The resulting products of iteration 2 are:
- Agreed release 2.0 boundaries;
- Experienced stand SA;
- Descriptions (regulations) of processes;
- User instructions for the automation system;
- Program and test methodology;
- Customer personnel involved in the testing of automation tools.
Iteration 3: Development of production release (3.0)
To obtain an industrial release, the “Research” group of project tasks is aimed at expanding the circle of participants for a deeper and better testing of the solution in conditions that are as close to real as possible.
Report on pilot (pilot) operation
The form
Text Document.
Purpose
The document records the results of the evaluation of the work of the pilot operation participants in terms of the goals of this stage of the project, and also demonstrates the current state of the control system, its readiness for industrial use and areas for improvement.
On the basis of which it is developed
The report serves to compare planned indicators with the actual, therefore, two groups of information sources are used in the development. The pilot operation plan and methodological materials for process participants (regulations, instructions, etc.) are considered as a basis for evaluation, and the actual data are formed by the pilot operation participants in the course of work and analyzed by consultants during the system audit.
A typical report contains three sections: general information, evaluation of the implementation of the pilot operation plan, evaluation of activities within the framework of the reorganized processes.
General information is, first of all, data sources and evaluation criteria used to generate a report. It is desirable that the selected criteria cover both the control of the processes and the execution of the process procedures, and the results of the implementation of the trial operation plan.
Evaluation of the implementation of the pilot operation plan is carried out for each item of the plan. In case of complete or partial non-compliance, the reasons are indicated. The section may contain some important quantitative and qualitative characteristics of the results, for example, the number of errors and comments.
Evaluation of activities within the processes is carried out according to the developed criteria with the formation of a generalized assessment of the success of the launch of each process and the management system as a whole. In this case, metrics and reporting tools that are part of the implemented system can be used. A useful component of this section of the report is a description of the identified deficiencies, the risks associated with them, as well as recommendations for reducing their impact.
When implementing a complex, functionally rich system over a large area (for example, when the operation is not experimental, but pilot-industrial), it is useful to prepare a short interim report one to two weeks after launch.
The group will include the following:
- Training of system users;
- Pilot-industrial operation.
- Formation of a list of improvements;
- Determining how to implement improvements;
- Reconciliation of release boundaries.
The group of project tasks "Development" in its content also repeats the previous iteration. The iteration is completed by the “Acceptance” group of design tasks, which will include the following works:
- Development of a program and test methods;
- Acceptance of the release by the Customer's working group;
- Making a decision to refine the release or move to the next iteration.
So the products of iteration 3 are:
- Administrator's manual;
- Description of automation system settings;
- Agreed release 3.0 boundaries;
- Industrial stand SA;
- Trained customer personnel;
- Customer personnel involved in trial operation.
Thus, the iterative implementation method ensures that all the key products of the project are available, creating additional value in the form of the possibility of constantly reviewing the progress of the project. A feature of the iterative method is that as a result of each iteration, the customer has a complete set of documents, automation tools and personnel. With this set, the organization has the opportunity to continue developing the IT management system in the light of new circumstances and in new conditions, up to the elimination of the services of a third-party provider.
Conclusion
In the article, we talked about several alternative options for implementing an automated system for managing the activities of an IT department. These are "Manufacturer's Solution", "Best Practice" and "Custom Solution", which, in turn, can be developed in both "classical" and "iterative" ways.
The considered options differ not only in qualitative characteristics. There is a significant difference in the timing and cost of the project for the customer between the basic setup of an automation system “out of the box” and the implementation of a several times proven “individual” solution.
There is no doubt that the additional time and resources spent by the organization on the analysis and choice of the implementation method during the project preparation stage is paid off by a more accurate “hit” of the project results in the planned budget and stakeholder expectations.
Good luck with your projects!
In the course of work on the creation of expert systems, a certain technology for their development has developed, including the following six stages: identification, conceptualization, formalization, implementation, testing, trial operation and implementation.
This article discusses the sixth stage: trial operation and implementation.
At the stage of trial operation and implementation, the suitability of the expert system for the end user is checked. Here the system deals with the solution of all possible tasks when working with different users. It is advisable to organize the operation of the system not at the developer's stand, but at the user's place of work. You should proceed to this stage only after the system, according to the expert, will successfully solve all the required tasks, so that errors in the decisions do not create a negative image of the system for the user. The suitability of the system for the user is determined mainly by the convenience of working with it and its usefulness.
Under usefulness The system is understood as the ability of the system during the dialogue to determine the user's need, identify and eliminate the causes of failures in work and satisfy the user's needs (i.e. solve the tasks set). In other words, it is important for the user to “bring to the consciousness” of the system his information need, despite possible mistakes allowed by him due to insufficient knowledge of the system. Of course, the completeness and correctness of the solutions are also important for the user, but these characteristics should be checked by an expert at the previous stage.
Under convenience work with the system is understood as:
- naturalness of interaction with the system, i.e. communication in a familiar, not tiring form for the user;
- system flexibility, i.e. the ability of the system to adjust to different users, as well as take into account changes in the qualifications of the same user;
- system error tolerance, i.e. the ability of the system not to fail due to erroneous actions of an inexperienced user.
Based on the results of operation, it may be necessary not only to modify the rules and data (improving or changing the language of communication, dialog tools, error detection and correction tools, customizing, etc.), but also changing the I / O devices due to their unacceptability for user. Based on the results of this stage, a decision is made to replicate the system. After the successful completion of the trial operation phase and the use of the expert system by various users, it can be classified as an industrial expert system.
In general, in the course of the trial operation of the prototype, the requirements for the system are clarified: developers and users have the opportunity to directly study and eliminate the consequences of the design decisions made. The principle of building an interface WYSIWYG(What You See Is What You Get - what you see is what you get) allows the user to directly evaluate the results of changes introduced to the prototype.
The creation of an information system begins from the moment of the first negotiations between the Customer and the potential Contractor and may never end, since good and useful systems are constantly being improved and developed.
preliminary stage
At this stage, it is necessary to understand the main goals and objectives of the future project. To do this, key representatives of the Customer and the Contractor organize meetings at which they discuss the concept of the information system, key technical points, the timing and scope of work performed, as well as the cost and sources of financing. The result of the preliminary stage, in addition to the agreed terms of the future contract, should be the first and most fundamental project document - project charter.
The project charter defines the following fundamental points related to the process of developing and implementing an information system:
- Brief description of the project, goals and objectives of creating an information system.
- General description of the scope of work.
- Project boundaries: terms, budget, list of automation objects.
- Product Description: List of supplied hardware and software, type and number of licenses, etc.
- Organizational structure of the project: the list and roles of the project team members on the part of the Contractor and the Customer, their responsibilities and duties, the project document management system.
- The main stages of development and implementation of the information system, an enlarged schedule for their implementation.
- The most significant risks of non-fulfillment of obligations under the project, as well as ways to minimize risks.
In other words, the project charter is precisely the charter that is developed by the project manager together with the main members of the project team, approved by the management of the Contractor and the Customer, and should not be adjusted during the entire time of creating the information system.
The completion of the preliminary stage can be considered the moment when the contract for services for the development and implementation of the information system is signed and the charter of the project is approved.
Gathering Requirements
At this point, all the key figures - project participants have been identified, and nothing prevents us from starting to collect and approve the requirements for the future information system. Representatives of the contractor communicate with future users and administrators of the system, as well as with their management. During the survey, not only the requirements and wishes for the implemented solution are systematized, but also the documentation is analyzed, which should become the source of the system's initial data, or the formation of which should be automated as a result.
This step should result in terms of reference for the development and implementation of the information system. The terms of reference should be based on the terms of the contract and the requirements set forth in the project charter and contain the following sections (for Russia, the structure of the terms of reference is regulated by GOST 34.602 89):
- Purpose and purpose of creating the system.
- Description of the automation object and the main automated business processes.
- System requirements: structure requirements; functions (tasks) solved by the system; requirements for technical and organizational support; requirements for reliability, safety, etc. etc.
- The composition and content of work on the creation of an information system.
- The order of control and acceptance of the results of work.
- Requirements for the scope of work for the preparation of an automation object for putting the information system into operation.
- Requirements for the composition of design and user documentation.
Completion of the requirements collection stage is the approval of the Terms of Reference by the Customer. In some cases, before the start of work on the project, the Customer already has a terms of reference (included in the tender documentation). In this case, the results of the survey and collection of requirements are recorded in private terms of reference, detailing and concretizing General requirements to the information system presented in the original terms of reference.
Design
At this stage, by the efforts of the Contractor, all scenarios related to the development and implementation of an information system on the territory of the Customer are designed in detail. This is done in accordance with the conditions of the information environment (system landscape) of the Customer and the requirements for the integration of the system being created with others already available and operated by the Customer. software products. The result of the design phase should be the design of the following sections technical (conceptual) project:
- Information system architecture.
- Description of information storage (database) structures.
- Design solutions presented by a detailed description of automation scenarios for all business processes affected by the implementation of the system.
- Scenarios for integrating the developed information system with external software products.
- Sources of initial data and options for the initial information content of the system.
- The concept of differentiation of access rights to data based on user roles, which determine, among other things, their powers.
- The concept of training users of the information system.
Implementation
The stage of implementation of all the requirements for the information system set out in the Terms of Reference and the Technical Design. During this period, the Contractor develops all the necessary software components, creates database structures, installs, configures and tests all components of the information system on its territory, simulates integration scenarios, etc. etc. The completion of the implementation phase is confirmed by the appearance of such project documents as a guide for installing and configuring the system, program and test procedure system, as well as a database template and a register of all completed software developments.
Preparation of the information system for operation
All work of this stage is already being carried out at the Customer’s site and includes installation and configuration of all system components in the Customer’s information environment, preliminary testing, development of user documentation, user training, loading of initial data, testing in accordance with the program and methodology, and other preparatory work.
By the time all the preparatory work is completed, the operating procedure for the system should be developed and approved. The regulation, in particular, should define users and their roles in the system, in accordance with their job responsibilities.
Pilot operation
The last stage in the development and initial implementation of an information system, the task of which is to successfully conduct a trial operation of the system for a certain time, and the goal is to confirm that the created information system is exactly the result that the Customer expected.
During this period, users begin to operate the system in accordance with the regulations developed at the previous stage. During the pilot operation, errors are fixed and the necessary improvements are agreed. The Contractor eliminates errors, performs improvements and, provided that the system begins to function in accordance with all the requirements presented to it earlier, at the end of the established period, receives a protocol on the successful completion of pilot operation.
With the completion of the pilot operation, as a rule, the contract for the creation of an information system ends. The system itself goes into commercial operation, and the Contractor, if the Customer is interested in this, concludes a separate contract for its maintenance, for the period established by the terms of the contract.
Maintenance and development of the system
Industrial operation may reveal that some requirements for the created information system contained inaccuracies and require a different wording or additions, and the system itself needs to be improved. Not every Customer has staff in its staff that is able to independently introduce all changes dictated by the real situation into the system, therefore, it concludes a separate agreement with the Contractor for the maintenance of the information system.
Users of the information system begin to communicate with representatives of the Customer's support service, who receive requests from them for improving functionality and eliminating defects, transfer requests for work, and periodically notify users of the status of their request. The list of possible improvements and the procedure for processing applications is determined by the terms of the contract. If there is a need for work that does not fit into the essence of the contract for support, then the Customer and the Contractor draw up a separate contract for this species work, which can already be attributed to the work on the modernization and development of the operated information system.
Preliminary tests
EIS preliminary tests can be autonomous and complex.
The program of autonomous tests indicate:
list of functions to be tested;
description of the relationship of the test object with other parts of the EIS;
conditions, procedure and methods for conducting tests and processing results;
· Criteria for acceptance of parts based on test results.
An offline test schedule should be attached to the offline test program.
Prepared and coordinated tests (test cases) at the stage of autonomous testing should provide:
Full check of functions and procedures according to the list agreed with the customer;
the necessary accuracy of calculations, established in the TOR;
Checking the main temporal characteristics of the functioning of software;
Checking the reliability and stability of the functioning of software and hardware.
The results of autonomous tests of EIS parts are recorded in the test reports. The protocol must contain a conclusion on the possibility of admitting a part of the EIS to complex tests. If the conducted autonomous tests are found to be insufficient, or a violation of the requirements of the regulatory documents on the composition or content of the documentation is revealed, the specified part of the EIS may be returned for revision and appointed new term tests.
Complex tests EIS is carried out by performing complex tests. The comprehensive test should:
be logically connected;
· to provide check of performance of functions of parts of EIS in all operating modes;
· to provide check of reaction of system to the incorrect information and emergencies.
The test results are reflected in the protocol. The work is completed with the execution of the acceptance certificate for trial operation.
In the program of complex tests of EIS indicate:
a list of test objects;
the composition of the submitted documentation;
a description of the relationships to be tested between the test objects;
the sequence of testing parts of the EIS;
· the procedure and methods of testing, including the composition of software and equipment required for testing, including special stands and test sites.
The integrated test protocol should contain a conclusion on the possibility (impossibility) of EIS acceptance for trial operation, as well as a list of necessary improvements and recommended deadlines for their implementation.
Trial operation is carried out in accordance with the program, which indicates:
conditions and procedure for the functioning of parts of the EIS and the EIS as a whole;
· the duration of trial operation, sufficient to verify the correct functioning of the EIS;
The procedure for eliminating deficiencies identified during trial operation.
During the trial operation of the EIS, a work log is kept, in which information is entered on the duration of the operation of the EIS, failures, failures, emergencies, changes in the parameters of the automation object, ongoing adjustments to the documentation and software, adjustment, and technical means. The information is recorded in the journal with the date and responsible person. The log may contain comments of the staff on the ease of operation of the EIS.
Based on the results of trial operation, a decision is made on the possibility of presenting parts of the EIS and the system as a whole for acceptance tests.
The work ends with the execution of an act on the completion of trial operation and the admission of the system to acceptance tests.
