INKAFARMA S.

Hace 18 años se apertura la primera botica de Inkafarma con la visión de “cambiar la historia de la
salud en las comunidades donde operemos, a través de la mejor calidad, el mejor precio y la mejor
gente.”

En el 2015 cerramos el año con alrededor de 900 boticas siguiendo con la misión de llevar con calidez
y optimismo: salud, bienestar y ahorro a todas las comunidades del Perú.

Para este año se tiene planeado incrementar nuestro número de boticas en 10% en comparación
del año anterior.

Nada de lo anterior sería posible sin el apoyo incondicional de nuestras áreas Administrativas
(matriz) divididas en las:

 Gerencias de Finanzas,
 Logística,
 Marketing,
 Ventas, RRHH,
 Infraestructura y Sistemas.

Por otro lado cuenta con un gran Centro de Distribución, el cual está a la vanguardia en equipos y
tecnología para la correcta distribución de mercadería que nuestros locales requieren.

Frente a este crecimiento la Gerencia General ha decidido reforzar la Gerencia de Sistemas

poniendo foco en el área de Servicios TI; para ello han contratado a un especialista en la Gestión de
Servicios TI, de esa manera refrescar la Jefatura (área encargada de soportar y velar por la
continuidad de los servicios TI brindado a las boticas).

Actualmente el área de Servicios TI está integrado por 17 personas; 2 coordinadores, 2 analistas de

Servicios TI, 11 analistas de Mesa de Ayuda, 1 Asistente administrativo y el Jefe del área.

A su vez se interrelaciona con las demás áreas de Sistemas como son:

 Networking,
 Base de Datos,
 Aplicaciones & ERP,
 Gestión de la información,
 POS,
 Logística de Sistemas y
 Soporte Técnico.
 A ellos tenemos que agregarlo la gestión que se debe realizar con los proveedores de
Servicios TI.
Los primeros mail que recibió el flamante Jefe del área de Servicios TI (aparte del de bienvenida)
eran las innumerables quejas por las incidencias atendidas a destiempo, los correos sin responder
de la bandeja de operaciones, las llamadas sin contestar por los analistas de 1er nivel, los casos mal
escalados hacia las demás áreas, etc.

Por otro lado, no se tenía registrada las atenciones de forma correcta; lo que dificultaba el análisis
de los casos en busca de patrones, tendencias, etc.

Todo hacía parecer que los integrantes del equipo no tenían mapeada cual era el core del área.
Obviamente la gerencia deseaba resultados en el menor tiempo posible.

Es aquí donde se impone la experiencia y un término escuchado por muchos, pero puesto en
práctica por pocos - ITIL.

El Jefe de Servicios TI sabía que la meta encomendada era empinada pero todavía viable, para ello
resultaba importante y necesario capacitar a todo el equipo en ITIL (Conjunto de buenas prácticas
para la gestión de Servicios TI), con el objetivo de estandarizar los términos y tener un panorama
algo más claro. Luego de semanas de entrenamiento el resultado fue el esperado, el equipo ya
hablaba de “incidencias y requerimientos”; el siguiente paso era definir el tiempo de atenciones por
cada categoría, luego de muchas reuniones con los usuarios y las áreas internas se definieron los:

 SLA (Acuerdo de Nivel de Servicio)

 OLA (Acuerdo de Nivel de Operación)

Finalmente ya se tenía elaborado el Catálogo de Servicios, el cual fue publicado a todos los usuarios.
Pero tener un documento firmado por los usuarios y las demás áreas no era suficiente, era necesario
hacer que esta información llegue a las boticas, sobre todo que cuando las boticas requieran de
ayuda para cualquier eventualidad sepan donde comunicarse, es allí donde se refuerza el anexo
7777, a este anexo se le fortalece enmarcándolo en un modelo de Servicio dónde Operaciones TI
sería el único punto de contacto (SPOC – Single point of contact) relacionado a los sistemas de cara
a los locales; en este modelo de Servicios se añaden los tres niveles de Soporte:

 1er Nivel – Mesa de Ayuda

 2do Nivel – Soporte
 3er Nivel – Soporte especializado y los cuadros de escalamiento respectivamente.

Luego de implementarse el SPOC las llamadas empezaron a incrementarse, es allí donde se

evidencia otra gran necesidad; no se contaba con una herramienta que nos permita gestionar las
atenciones, esto seguía golpeando en los tiempos de atención brindado a los locales y el
escalamiento a las demás áreas.

Esta realidad es escalada a la Gerencia de Sistemas y surgen dos alternativas:

1. Adquirir un software que permita gestionar la mesa de ayuda.

2. Analizar, desarrollar e implementar un software in house que permita gestionar una mesa
de ayuda.
En caso la alternativa 2, sea la escogida la Gerencia asignará los siguientes recursos para el
desarrollo del SW:
 1 analista de base de datos
 1 analista funcional
 2 programadores
 1 líder del Proyecto.

Requerimientos Funcionales:
- Existen tres formas por las cuales las boticas o usuarios de matriz pueden reportar sus
incidencias o requerimientos: RPM, vía Mail o vía web.
- Cada botica tiene como identificador un cód. de Local, nombre del local, tipo de local (Oro,
Plata y Bronce) asociado al volumen de ventas, etc.
- Para los usuarios en matriz (áreas administrativas) cada colaborador tiene como
identificador un cód. de empleado.
- Tantos los incidentes o Requerimientos están divididos:
o En una categoría principal de hardware o software luego de ello en
o Una segunda categoría que es el servicio afectado seguida de
o Una tercera categoría que es el C I involucrado y
o Una cuarta categoría que es la falla o solicitud reportada.
- Los tiempos de atención (SLA) están amarrados a la 4ta categoría y están en relación a la
urgencia e impacto del servicio atendido. (Urgencia e impacto= Crítico, Alto, media y baja)

- Cada caso registrado debe brindar un nro. de ticket, para poder registrar un ticket un caso
se requiere que se le asigne un especialista; los especialistas están en relación a las áreas
que integran la Gerencia de Sistemas y algunos proveedores de Servicios.
- Luego de llenar todos los campos solicitados y darle click en guardar, el ticket pasa a un
estado de registrado y empieza a correr el tiempo de SLA. Un ticket puede tener los
siguientes estados:
o Registrado: Ticket registrado y asignado a un especialista.
o En Proceso: Ticket en proceso de solución.
o Solucionado: Ticket solucionado.
o Cerrado: Ticket con la solución validada por el usuario.
o Tránsito: Ticket en standby porque se está enviando un repuesto.
o Anulado: Ticket anulado.

- Al finalizar la atención y seleccionar el estado Solucionado en el ticket, deberá llegar un mail

al usuario indicándole la solución e invitándolo a una encuesta relacionada a la atención
brindada bajo tres aristas: Tiempo, Calidad y Trato, esta información posteriormente será
consultada.
- Cada vez que un incidente esté categorizado en impacto y urgencia “Crítico” deberá enviar
un mensaje informativo a toda la Jefatura de Sistemas.
 - El Sistema debe permitir hacer búsqueda de tickets, así como contar con un módulo para
matricular los elementos de configuración y la base de datos del conocimiento.
- A nivel Gerencial se requiere reportes de Gestión visualizados en un dashboard (tablero
)donde se plasme lo siguiente:
o KPIs de SLA por día y acumulado de un mes. (Tiempo de atención de Tickets y
encuestas)
o Cantidad de tickets resueltos por grupo y especialistas.
o Tickets top.
o Locales con mayor nro. de tickets reportados.
o Lista de incidentes Mayores.
o Lista de incidentes top atendidos fuera del SLA.

Restricciones:
- Todo los tickets dependiendo de las categorías pueden resolverse en diferentes horarios.
Horario normal 24*7, horario de oficina 8*5, horario de químico farmacéutico 10*6.
- Un ticket solo puede estar asociado a un grupo resolutor.