Cómo implementar ITIL por etapas sin un proyecto de años
September 23, 2026
Todo líder de TI que ha investigado sobre ITIL se topa con el mismo muro: un marco de trabajo con docenas de procesos, cinco etapas de ciclo de vida y un vocabulario lo suficientemente denso como para llenar un curso de certificación por sí solo. La conclusión natural es que adoptarlo implica un despliegue de varios años con un departamento dedicado y, para un equipo de TI de tamaño mediano que ya está al límite, esa conclusión suele ser suficiente para archivar la idea por completo antes de que alguien compruebe si es realmente cierta.
No lo es. ITIL nunca fue diseñado como una lista de verificación de todo o nada, y las organizaciones que obtienen un valor real de él casi nunca implementan la biblioteca completa a la vez. Comienzan con dos o tres procesos que resuelven un problema que el equipo ya siente, demuestran el valor y se expanden a partir de ahí. La barrera con la que se topan la mayoría de los equipos no es ITIL en sí, sino la suposición de que adoptarlo significa adoptarlo todo simultáneamente. Ese simple cambio de enfoque, tratar a ITIL como un menú en lugar de un mandato, suele ser el único cambio necesario para que una iniciativa estancada vuelva a ponerse en marcha.
La idea de que ITIL requiere una implementación total proviene de cómo se enseña habitualmente, no de cómo debe utilizarse. Los cursos de certificación cubren todo el marco porque eso es lo que exige el examen, y los proveedores que venden grandes plataformas de ITSM han agrupado históricamente la "alineación con ITIL" como un interruptor de función única en lugar de un conjunto de prácticas independientes que un equipo puede adoptar una por una. El resultado es una suposición generalizada entre los directores de TI de que no existe una versión parcial, solo el cumplimiento total o nada. Esa suposición ha estancado más proyectos de mejora de ITSM que cualquier limitación técnica real, porque los equipos tratan un plan de un año como su única opción y deciden silenciosamente que no vale la pena empezar. Incluso los directores de TI que comprenden perfectamente el diseño modular de ITIL a menudo heredan este marco de todo o nada de un empleador anterior o de la propuesta de un proveedor, y desaprenderlo lleva más tiempo que aprender las prácticas individuales.
ITIL es un conjunto de prácticas documentadas para gestionar servicios de TI, no un requisito de certificación, ni un software, ni una secuencia rígida que deba seguirse en orden. Describe prácticas como la gestión de incidentes, la gestión de problemas, la gestión de cambios y la gestión del catálogo de servicios como disciplinas independientes, cada una de las cuales resuelve un problema operativo específico. Un equipo puede ejecutar una práctica madura de gestión de incidentes sin tener ningún proceso formal de gestión de cambios, y esa combinación es totalmente coherente con la forma en que se debe aplicar ITIL. Tratarlo como algo modular en lugar de monolítico es lo que hace posible la adopción incremental en primer lugar. Incluso las cuatro dimensiones de la gestión de servicios ampliamente citadas (personas y organizaciones, información y tecnología, socios y proveedores, y flujos de valor y procesos) están pensadas como una lente para evaluar cualquier práctica individual, no como una lista de verificación de requisitos previos que debe cumplirse antes de que se permita empezar a un equipo.
Tres prácticas ofrecen valor de forma constante desde el principio, independientemente del tamaño o el sector de la empresa, porque abordan problemas que todo equipo de TI ya tiene desde el primer día: tickets que llegan sin una estructura coherente, preguntas repetidas sin una respuesta compartida y falta de visibilidad sobre qué servicios están disponibles para solicitar en primer lugar.
Estas tres prácticas se refuerzan mutuamente: un catálogo de servicios de TI bien organizado reduce el volumen de solicitudes ambiguas que llegan a la cola de incidentes, y una base de conocimientos reduce la cantidad de incidentes que requieren que un humano los resuelva. Empezar por aquí significa que el equipo siente el beneficio en cuestión de semanas en lugar de esperar a que un despliegue de todo el marco se justifique por sí mismo.
La gestión de problemas, la gestión de la disponibilidad y los comités asesores de cambios completos son prácticas legítimas de ITIL, pero suponen un nivel de madurez de procesos que la mayoría de los equipos aún no ha alcanzado. La gestión de problemas, por ejemplo, solo da sus frutos una vez que hay suficiente historial de incidentes para detectar patrones que valga la pena investigar, y un comité asesor de cambios formal solo tiene sentido una vez que el volumen de cambios es lo suficientemente alto como para que la aprobación ad hoc empiece a causar retrasos o errores. Introducirlos prematuramente suele significar añadir reuniones y pasos de aprobación que ralentizan al equipo sin un volumen de incidentes o cambios lo suficientemente grande como para justificar el esfuerzo. Pasar directamente a estas prácticas antes de que los conceptos básicos sean estables también tiende a generar procesos por el simple hecho de hacerlo, creando informes y reuniones de revisión que documentan un problema que nadie fuera de la sala está intentando resolver todavía.
La secuencia correcta no trata sobre qué proceso es más "avanzado", sino sobre cuál aborda un problema que el equipo está experimentando realmente en este momento. Un equipo de TI pequeño que gestiona un flujo modesto y constante de tickets obtiene mucho más valor de un proceso de incidentes limpio que de un comité asesor de cambios que revisa actualizaciones que nadie ha registrado formalmente todavía.
Freshservice incluye módulos de gestión de incidentes, problemas, cambios y activos alineados con ITIL, listos para configurar en lugar de empezar desde cero, lo que elimina gran parte de la carga técnica de configuración en un despliegue incremental. Antes de comprometerse con una configuración específica, vale la pena dedicar tiempo a evaluar herramientas de ITSM en función de cómo el equipo planea realmente secuenciar la adopción, ya que una plataforma que solo admite un modelo de implementación integral va en contra del enfoque incremental que describe este artículo.
El portal de autoservicio y las plantillas de catálogo de servicios integradas de Freshservice permiten implementar la segunda práctica rápidamente, y su módulo de base de conocimientos se conecta directamente con la resolución de tickets, por lo que los agentes pueden adjuntar o sugerir un artículo al cerrar un ticket. Nada de esto requiere habilitar todos los módulos de ITIL que ofrece la plataforma desde el primer día. Un equipo puede activar la gestión de incidentes y el catálogo de servicios el primer mes, añadir la base de conocimientos unas semanas después y dejar la configuración de la gestión de cambios hasta que el volumen de tickets realmente lo justifique.
Existe una señal práctica para saber cuándo añadir la siguiente práctica de ITIL, y no es una fecha en el calendario. Que el volumen de incidentes aumente hasta el punto en que las mismas categorías se repiten constantemente es una señal de que la gestión de problemas sería rentable. Que las solicitudes de cambio se acumulen más rápido de lo que alguien puede rastrear informalmente de memoria es una señal de que un proceso de cambio ligero, no necesariamente una junta asesora completa, es necesario desde hace tiempo.
Esperar estas señales en lugar de seguir un calendario de despliegue fijo mantiene cada nuevo proceso vinculado a una necesidad real y sentida, en lugar de a una fecha arbitraria en un plan de proyecto, lo que también evita que el equipo vea el marco de trabajo como una burocracia impuesta por sí misma en lugar de algo adoptado porque resuelve problemas reales.
El modelo incremental no se detiene en TI. Una vez que la gestión de incidentes, un catálogo y una base de conocimientos funcionan sin problemas, la misma infraestructura permite que el servicio más allá de TI se extienda claramente a RR. HH., instalaciones y finanzas, absorbiendo cada uno las solicitudes a través del mismo catálogo sin necesidad de un despliegue por separado ni de una segunda plataforma que gestionar. Esa expansión ocurre porque lo que se construyó primero fue la práctica subyacente, no el proceso de un departamento específico. El único requisito previo real es que las tres prácticas originales sean lo suficientemente estables como para que otro departamento pueda confiar en ellas sin que TI tenga que apagar fuegos de su propio despliegue al mismo tiempo.
Tratar ITIL como una biblioteca de la que extraer recursos en lugar de un proyecto que completar cambia todo el cronograma. Lo que llevaría años como una iniciativa de todo o nada se convierte en una serie de pequeñas adiciones de bajo riesgo que se amortizan por sí mismas antes de que comience la siguiente, y un equipo nunca tiene que justificar una gran inversión inicial antes de ver algún retorno.
Si tu equipo ha estado posponiendo la mejora de ITSM porque "hacer ITIL correctamente" sonaba como un compromiso de un año sin espacio en el cronograma actual, vale la pena probar el conjunto inicial más pequeño descrito aquí, construido en torno a la gestión de incidentes, un catálogo y una base de conocimientos, frente a su volumen actual de tickets y tamaño de equipo antes de comprometerse con algo más grande o formal.
