Incidentes

Los incidentes reflejan problemas en el sistema de trabajo que requieren una evaluación
para encontrar que es lo que los generó y una propuesta de solución.

Incidentes de soporte:
Un incidente de soporte se genera ante un reclamo de un cliente.
Para su correcto seguimiento se generan un comprobante de proyectos con codigo
INSOKR ( incidente soporte Kropol )
Los incidentes pueden ser ingresados por: Alguien del área comercial, responsable de
soporte, responsable de implementación, atención al cliente.
El incidente se relaciona al proyecto y se asocia al responsable de soporte con anexo2=
“PEN”.

Responsable Soporte
Deberá investigar en un plazo no mayor a una semana, la causa del problema, registrarla
en el incidente y proponer una solución para que el problema no vuelva a repetirse.
Completa el anexo2 con “ARR” y en fecha finalización, completa la del día de
finalización.

Dirección:
Evalúa si esta conforme con la solución planteada. En caso positivo da por terminado el
incidente completando en anexo2 con “…..”
En caso negativo devuelve el proyecto al responsable de soporte ( paso anterior ),
asignandoselo en anexo1, y poniendo en anexo2 con “…..”

Incidentes de Desarrollo:
Un incidente de desarrollo se genera ante un error en el sistema de algo que funcionaba
correctamente, ante una nueva programación que no cumple las condiciones para haber
sido dada por terminada ( ver documentos correspondiente ), ante una programación
incorrecta por análisis deficiente.
Para su correcto seguimiento se generan un comprobante de proyectos con codigo
INDEQU ( incidente Desarrollo Quilate )
Los incidentes pueden ser ingresados por: Responsable de testing, responsable de
desarrollo, responsable de implementación.
El incidente se relaciona al proyecto y se asocia al responsable de desarrollo con
anexo2= “PEN”.

Responsable Desarrollo
Deberá investigar en un plazo no mayor a una semana, la causa del problema, registrarla
en el incidente y proponer una solución para que el problema no vuelva a repetirse.
Completa el anexo2 con “ARR” y en fecha finalización, completa la del día de
finalización.

Dirección:
Evalúa si esta conforme con la solución planteada. En caso positivo da por terminado el
incidente completando en anexo2 con “…..”
En caso negativo devuelve el proyecto al responsable de desarrollo ( paso anterior ),
asignandoselo en anexo1, y poniendo en anexo2 con “…..”

Incidentes de Testing:
Un incidente de testing se genera ante un error en el sistema que detectó en una versión
liberada a los clientes.
Para su correcto seguimiento se generan un comprobante de proyectos con codigo
INTEQU ( incidente Testing Quilate )

Los incidentes pueden ser ingresados por: Responsable de testing, responsable de

desarrollo, responsable de implementación.
El incidente se relaciona al proyecto y se asocia al responsable de testing con anexo2=
“PEN”.

Responsable Testing
Deberá investigar en un plazo no mayor a una semana, la causa del problema, registrarla
en el incidente y proponer una solución para que el problema no vuelva a repetirse.
Completa el anexo2 con “ARR” y en fecha finalización, completa la del día de
finalización.

Dirección:
Evalúa si esta conforme con la solución planteada. En caso positivo da por terminado el
incidente completando en anexo2 con “…..”
En caso negativo devuelve el proyecto al responsable de testing ( paso anterior ),
asignandoselo en anexo1, y poniendo en anexo2 con “…..”

Incidentes de Implementación:
Un incidente de implementación se genera ante un reclamo de un cliente relacionada a
la implementación ( consumo excesivo de horas, no cumplimientos de las fechas,
procesos incorrectamente implementados ). Para su correcto seguimiento se generan un
comprobante de proyectos con codigo INIMQU ( incidente implementación Quilate )

Los incidentes pueden ser ingresados por: Responsable de testing, responsable de

ventas, responsable de implementación.
El incidente se relaciona al proyecto y se asocia al responsable de implementación con
anexo2= “PEN”.

Responsable Implementación
Deberá investigar en un plazo no mayor a una semana, la causa del problema, registrarla
en el incidente y proponer una solución para que el problema no vuelva a repetirse.
Completa el anexo2 con “ARR” y en fecha finalización, completa la del día de
finalización.

Dirección:
Evalúa si esta conforme con la solución planteada. En caso positivo da por terminado el
incidente completando en anexo2 con “…..”
En caso negativo devuelve el proyecto al responsable de Implementación ( paso anterior
), asignandoselo en anexo1, y poniendo en anexo2 con “…..”

Incidentes de Ventas:
Un incidente de ventas se genera ante un reclamo de un cliente de funcionalidad que no
contiene el sistema y fue prometida en la venta.
Para su correcto seguimiento se generan un comprobante de proyectos con codigo
INVEQU ( incidente Venta Quilate )

Los incidentes pueden ser ingresados por: Responsable de desarrollo, responsable de

implementación o Responsable de ventas.
El incidente se relaciona al proyecto y se asocia al responsable de ventas con anexo2=
“PEN”.

Responsable Ventas
Deberá investigar en un plazo no mayor a una semana, la causa del problema, registrarla
en el incidente y proponer una solución para que el problema no vuelva a repetirse.
Completa el anexo2 con “ARR” y en fecha finalización, completa la del día de
finalización.

Dirección:
Evalúa si esta conforme con la solución planteada. En caso positivo da por terminado el
incidente completando en anexo2 con “…..”
En caso negativo devuelve el proyecto al responsable de Ventas ( paso anterior ),
asignandoselo en anexo1, y poniendo en anexo2 con “…..”