SLA Control Refactoring
The modeling and screens that parameterize the SLA time were modified, in the items that have the control of Ticket and Problem.
The acordoservicocontrato table is no longer used to parameterize the SLA time of activities. The tempoatendservicocontrato table was created to define this relationship, which is now created by linking the servicocontrato directly to the acordonivelservico (Service time); that is, before an SLA is defined for an activity the service level agreement it must be defined for the activity in portfolio registration or maintenance screen.
Update scripts were included in the system that will load data into the table tempoatendservicocontrato, at the time of updating and respecting existing relationships.
Therefore, after this update, the system must continue to apply the previously parameterized SLAs.
The service time screen has been redesigned and changed to no longer define contract targets and activity for service time. This responsibility was passed to the portfolio screen and portfolio maintenance.
The concept of Global SLA, by customer and specific, no longer exists in the system. Now all are SLAs specific, defined directly in the portfolio of activities. The seasonal SLA concept remains, well as a definition of VIP priorities.
It is possible to relate, only, a single service time (Service Level Agreement) main to an activity, however, as many times, of the seasonal type, are necessary.
The portfolio screen has been changed to record servicocontrato relationship with service agreements level of service, which can be applied to tickets, the choice of SLA will be in accordance with what has the highest priority, respecting the priority of the service level agreement, calculated by the impact and priority of the service time, the priority of the unit, the priority of the employee and the requester's group.
The time setting will be chosen from the highest priority.
The flow definition and service time components have changed position and type, now the flow definition is of the “select” type and the service time definition is in a table format, as this is what needs to be added records and not the flow that is only one per activity.
The possibility to define the SLA time for multiple activities was included, using the Portfolio Maintenance. Another important change is that we can now update information, in batches, from activities already related to the contract, the rules are as follows:
- When linking activities to the contract or contract to activities, the system will add new relationships and update the existing ones, with the information fed into the final step of linking, where the user can define the flow, service time, calendar, date of start…
- Only the information that is filled in in the final step of the link will be applied, one being record inclusion or update;
- If one or more activities are linked to the service contract, that is, performing an insertion operation in the database, if some obligatory information is missing, the operation will not be completed and the user will receive a message requesting them.
- Priority calculation using or not parameter 104;
- VIP priority setting;
- Seasonality control;
- SLA definition algorithm for all modules – This code has been refactored, but without changing business rules;
- Definition of SLA per task;
- SLA compliance calculation.
- Ticket
- SmartPortal
- ExperienceCenter
- TemplateSolicitacao
- AcaoIncidenteRequisicao
- Problema
The following methods have been removed:
- AcordoNivelServicoService().findANSSazonalByIdServicoContrato
- AcordoNivelServicoService().findANSIncReqProcByIdServicoContrato
- AcordoNivelServicoService().findANSCliente
- AcordoNivelServicoService().findANSGlobal
- AcordoNivelServicoService().getIdANSSazonal
For this knowledge, the SQL file with the script used to load the data to define the SLA is attached to the Tasker-14847.
