Incidentes

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 “…..”