ITIL sin sobre-ingenieria: que adoptar y que dejar para empresas medianas

ITIL tiene 34 practicas en su version 4. La mayoria de empresas medianas que intentan adoptarlo completo terminan abandonandolo o generando burocracia que nadie usa. La version pragmatica es distinta.

El problema con ITIL puro

ITIL esta disenado pensando en organizaciones grandes con equipos dedicados a cada practica. Cuando una empresa de 200 empleados intenta implementar Problem Management formal con su rol especifico, la realidad es que la misma persona termina siendo agente, coordinador y gerente del proceso.

El resultado: documentacion que nadie actualiza, procesos que se saltan en la practica y equipos que ven a ITIL como enemigo de la productividad.

Lo que si adoptar

1. Incident Management. Es la base. Registro de tickets, categorizacion, priorizacion, resolucion, cierre. Sin esto no hay mesa de servicio.

2. Service Request Management. Separar incidentes (algo esta roto) de solicitudes (algo nuevo) cambia como mides y como priorizas.

3. Change Enablement. Una version ligera: toda modificacion a sistemas productivos pasa por una ventana, tiene responsable y plan de rollback. Sin CAB de 20 personas.

4. Knowledge Management. Base de conocimiento viva, articulos evergreen, ciclo de revision trimestral. Reduce tickets repetidos en 30-50%.

5. Service Desk. La funcion, no la herramienta. Punto unico de contacto, triage, escalamiento. Existe aunque no lo llames asi.

6. Service Level Management. SLAs por severidad, medicion automatica, reporte mensual a direccion.

Lo que adaptar

Problem Management se convierte en "reunion de causa raiz mensual". Una hora al mes revisando los 3 tickets mas recurrentes. Sin KEDB formal, con notas en la base de conocimiento.

Configuration Management empieza como CMDB minima de 5 tipos de CI, no como inventario exhaustivo de todo.

Release Management se fusiona con Change Enablement. Una sola ventana, una sola aprobacion, un solo proceso.

Lo que ignorar sin culpa

Para una empresa mediana tipica, estas practicas pueden esperar anos o no implementarse nunca:

• Service Portfolio Management formal
• Financial Management para IT como practica separada
• Availability Management con SLAs de 99.999%
• Capacity Management con modelado predictivo
• IT Asset Management con depreciacion contable

Si alguien te dice que "no puedes llamarte ITIL sin esto", la respuesta es: no necesitas llamarte ITIL, necesitas operar bien.

La adopcion realista

Mes 1-2: Incident y Service Request formalizados en Freshservice. SLAs basicos definidos.

Mes 3-4: Knowledge base con primeros 20 articulos. Change enablement ligero.

Mes 5-6: Reporte mensual a direccion con metricas reales. Ciclo de revision de conocimiento.

Mes 7-12: Problem review mensual. CMDB minima de CIs criticos.

Al ano, la empresa tiene el 80% del valor de ITIL con el 20% del esfuerzo. Eso es exito.

El criterio final

Una practica vale la pena si:

• Alguien la va a ejecutar con recurrencia
• Produce un output que se usa
• Tiene responsable claro
• Mejora una metrica que importa

Si no cumple los cuatro, esta de adorno. Y el adorno en operaciones no es gratis: confunde al equipo, esconde prioridades reales y da falsa sensacion de madurez.