In case of detection of various errors in the operation of the MIS, which impede its use, the administrator can report this to the technical support service, which will check the information sent and, if the problem is confirmed, will transfer the task to the developers to eliminate this malfunction (error).

An error is understood as a discrepancy between the operation of the MIS and what is described in the documentation for it.

The error message must be formatted in accordance with the specific requirements described later in the current document. Only those who meet the requirements for reporting errors are accepted for work by the TP service.

When an error message is received, the TP service is obliged to investigate it. First, the TP employee must try to reproduce this error on a regular copy of the software installed in the TP service. If a TP employee confirms this error, it is recorded in a special database called the "Developers' Log" (access to it is provided to customers through the technical support site) and immediately passed on to the developers for elimination.

If the error cannot be repeated, the TP service employee communicates with the MIS administrator, trying to clarify the specifics of the system operation, up to a request to provide a remote connection to the KIIS Software and a demonstration of this error. If in the course of such work it is not possible to demonstrate and repeat the described error, this appeal is closed, and no further actions by the TP service will be carried out on it.

In order to select an adequate response time to a confirmed error correction, the following criteria apply:

impact degree: how much the detected error affects the deviation from the normal level of the MIS operation, depending on the number of users or business processes affected by the problem.
urgency: the acceptable delay in fixing an error for a user or business process.
Impact and urgency can themselves change over time, for example, as the number of users experiencing the same error increases or at critical times.

In order to accommodate both criteria, all errors are classified by priority. The priority is characterized by 2 indicators:

Value (status);
Regulated deadline for elimination.
Submitting a Proposal for Change
As part of the technical support service, the MIS administrator gets the opportunity to collect from users and send to the Contractor an appeal with a proposal to change the KIIS software.

Within the framework of one appeal, one proposal is accepted to change any function or module of the MIS.

If an employee of the TP service accepts a properly formulated proposal for revision, it is drawn up in a special service database - "Journal of KIIS Developers" and can be taken into account by the developers when creating new versions of the MIS software.

Each proposal is analyzed, and the Developer reserves the right to decide whether or not to include user proposals in the MIS development plan.

There are several possible responses to proposals for the completion and improvement of the IIA:

The offer is accepted. If in the course of researching a formulated proposal, the developer's specialists do not find unrealizable requirements in it, if it is formalized correctly and enough for understanding, this proposal receives the status of "accepted" and remains in the "Developers' Journal" database. When planning the release of new versions and changes in various MIS subsystems, developers actively use these records to make decisions about the implementation of changes and improvements.
The proposal is included in the revision plan. If the proposal is regarded by the developer as in need of ongoing implementation, then it can be included in the development plan without additional payment from the customer. The implemented proposal is included in the serial version of the MIS and will be available to all users. Inclusion in the plan of the revision on a gratuitous basis does not impose any obligations on the "Developer" in terms of the timing, method and conditions for the implementation of this revision.
The offer can be implemented on a reimbursable basis. If the proposal is of a specific nature, or its implementation requires significant resources, or for some other reason does not fit into the development strategy of the K-MIS Software, the Developer can accept this proposal for implementation on a reimbursable basis. In this case, a technical assignment is agreed with the customer and the proposal is implemented for payment under a separate contract.
Refusal to implement the proposal. If the proposal requires resources or technologies for implementation that the Developer does not have, or the proposal contradicts the MIS development strategy or plans for its development, including disagreement to the implementation of such a change by other customers, or for any other compelling reasons, K-MIS reserves the right to refuse to implement this offer. In this case, the refusal will contain a description of the reasons (motivated refusal).

For more information about: what is an enduser