¿Cómo elaborar un PETI? Guía práctica para directores de TI

Un Plan Estratégico de Tecnologías de la Información, conocido como PETI, no debería convertirse en otro documento que se prepara para cumplir un requisito y termina archivado en una carpeta que nadie vuelve a consultar.

Cuando está bien construido, el PETI se convierte en una herramienta de dirección. Permite entender dónde está la organización en materia tecnológica, qué necesita cambiar, cuáles son las prioridades y cuánto puede costar llevarlas adelante.

Para un director de TI, CIO o responsable de tecnología, la pregunta central no debería ser únicamente qué sistemas hacen falta o qué infraestructura debe renovarse. La verdadera pregunta es:

¿Cómo debe evolucionar TI para que la organización pueda cumplir mejor su estrategia?

Desde esa perspectiva, elaborar un PETI implica mucho más que hacer un inventario de computadores, servidores, aplicaciones y contratos. Requiere entender el negocio, identificar problemas reales, establecer prioridades y convertirlas en una hoja de ruta ejecutable.

Tabla de contenido

1. ¿Qué es un PETI?
2. ¿Para qué sirve un PETI?
3. 1. Conocer la organización antes de hablar de tecnología
4. 2. Realizar un diagnóstico de TI
5. Inventario tecnológico que debería analizarse
6. 3. Identificar las brechas
7. 4. Definir la visión de TI
8. 5. Definir los objetivos estratégicos de TI
9. 6. Convertir las necesidades en iniciativas
10. Cómo priorizar proyectos de TI
11. 7. Construir el roadmap tecnológico
12. El presupuesto dentro del PETI
13. 8. Definir KPIs
14. Gestión de riesgos tecnológicos
15. Gobierno y responsables del PETI
16. Marcos y estándares que pueden apoyar el PETI
17. Errores frecuentes al elaborar un PETI
18. 9. Aprobar, ejecutar y actualizar
19. Estructura recomendada de un PETI
20. Checklist para revisar un PETI

¿Qué es un PETI?

El PETI es el instrumento mediante el cual una organización define cómo quiere desarrollar y gestionar sus tecnologías de información durante un periodo determinado.

Su función es conectar la estrategia institucional o empresarial con las decisiones relacionadas con tecnología.

En términos sencillos, un PETI debería permitir responder preguntas como:

• ¿Cuál es la situación actual de TI?
• ¿Qué necesita realmente la organización?
• ¿Qué problemas tecnológicos están afectando la operación?
• ¿Qué riesgos deben atenderse?
• ¿Qué capacidades tecnológicas hacen falta?
• ¿Qué proyectos deben ejecutarse primero?
• ¿Cuánto presupuesto se necesita?
• ¿Quién será responsable de cada iniciativa?
• ¿Cómo se medirá el resultado?

Por eso, un PETI útil no se limita a describir tecnología. Debe explicar por qué una inversión tecnológica tiene sentido para la organización.

¿Para qué sirve un PETI?

Uno de los principales problemas de las áreas de tecnología es trabajar permanentemente en modo reactivo. Llega una solicitud, aparece una falla, un sistema queda obsoleto, un usuario necesita un desarrollo y TI responde.

El PETI permite cambiar progresivamente esa dinámica.

Sin planeación estratégica	Con un PETI estructurado
TI responde principalmente a solicitudes.	TI trabaja sobre prioridades estratégicas.
Los proyectos compiten por recursos.	Los proyectos se priorizan con criterios definidos.
El presupuesto se construye de manera reactiva.	Existe una visión de inversión tecnológica.
La tecnología puede crecer sin arquitectura.	Existe una dirección tecnológica.
Los riesgos aparecen cuando ya ocurrió el problema.	Los riesgos se identifican y gestionan anticipadamente.

1. Conocer la organización antes de hablar de tecnología

Un error bastante común consiste en comenzar el PETI haciendo una lista de tecnologías que deberían adquirirse.

Servidor nuevo. ERP. CRM. Inteligencia artificial. Migración a la nube. Aplicación móvil. Ciberseguridad. Automatización.

El problema es que ninguna de estas tecnologías debería ser una prioridad por sí misma.

Primero hay que comprender la organización.

El director de TI debería conocer los objetivos estratégicos, los procesos críticos, los servicios que presta la organización, los principales problemas operativos y las necesidades de las diferentes áreas.

Una buena práctica consiste en realizar entrevistas con:

• Dirección general.
• Finanzas.
• Recursos humanos.
• Operaciones.
• Comercial.
• Marketing.
• Servicio al cliente.
• Compras.
• Jurídica.
• Seguridad.
• Usuarios clave de los sistemas.

Muchas veces, el problema tecnológico no está donde TI cree que está.

Un área puede pedir una nueva aplicación cuando en realidad el problema es un proceso mal diseñado. Otra puede solicitar automatización cuando primero necesita limpiar y organizar sus datos.

2. Realizar un diagnóstico de TI

Después de entender el negocio llega una de las partes más importantes del PETI: conocer el estado real de tecnología.

El diagnóstico debería cubrir, como mínimo, infraestructura, aplicaciones, servicios, seguridad, datos, procesos, proveedores y talento.

Áreas que debería cubrir el diagnóstico

Área	Aspectos a revisar
Infraestructura	Servidores, redes, almacenamiento, equipos, conectividad, nube y centros de datos.
Aplicaciones	ERP, CRM, software interno, aplicaciones web, móviles y sistemas heredados.
Datos	Fuentes, calidad, integridad, disponibilidad, gobierno y analítica.
Seguridad	Controles de acceso, vulnerabilidades, copias de seguridad, monitoreo y respuesta.
Servicios	Disponibilidad, soporte, niveles de servicio y experiencia del usuario.
Procesos	Gestión de incidentes, cambios, proyectos, activos y proveedores.
Proveedores	Contratos, costos, dependencias, niveles de servicio y riesgos.
Talento	Capacidades, perfiles, cargas de trabajo y necesidades de formación.

Inventario tecnológico que debería analizarse

El inventario es mucho más útil cuando no se limita a decir qué activos existen. También debería permitir conocer su estado, criticidad, costo y dependencia.

Activo	Información recomendada
Servidor	Ubicación, capacidad, sistema operativo, antigüedad, criticidad y soporte.
Aplicación	Propietario, usuarios, función, tecnología, costo y dependencia.
Contrato	Proveedor, valor, vencimiento, SLA y condiciones.
Base de datos	Motor, información almacenada, tamaño, criticidad y respaldo.
Equipo	Usuario, características, antigüedad, garantía y estado.
Servicio cloud	Proveedor, consumo, costo, responsable y nivel de criticidad.

3. Identificar las brechas

Una vez conocida la situación actual hay que compararla con la situación que la organización necesita alcanzar.

Ahí aparecen las brechas.

Una brecha puede ser tecnológica, organizacional, de seguridad, de procesos, de información, de talento o incluso presupuestal.

Las preguntas fundamentales son:

• ¿Qué tenemos?
• ¿Qué necesitamos?
• ¿Qué diferencia existe entre ambos escenarios?
• ¿Qué riesgo representa esa diferencia?
• ¿Qué esfuerzo requiere solucionarla?

Situación actual	Situación objetivo	Brecha	Posible iniciativa
Aplicaciones desconectadas	Información integrada	Falta de interoperabilidad	Proyecto de integración
Procesos manuales	Procesos automatizados	Alta intervención humana	Automatización
Datos dispersos	Información centralizada	Ausencia de gobierno de datos	Plataforma de datos
Controles de seguridad básicos	Modelo de seguridad maduro	Riesgos tecnológicos	Programa de ciberseguridad

4. Definir la visión de TI

La visión responde a una pregunta sencilla pero importante: ¿cómo queremos que sea TI en el futuro?

Dependiendo de la organización, la visión puede estar relacionada con modernización tecnológica, transformación digital, automatización, datos, inteligencia artificial, seguridad, movilidad, nube, gobierno o mejora de servicios.

La visión debe ser suficientemente ambiciosa para orientar la transformación, pero también suficientemente realista para poder convertirse posteriormente en iniciativas y presupuesto.

5. Definir los objetivos estratégicos de TI

Los objetivos de TI deben estar conectados con los objetivos de la organización.

Esta diferencia parece pequeña, pero cambia completamente la forma de construir el PETI.

En lugar de preguntarse:

¿Qué tecnología podemos comprar?

La pregunta debería ser:

¿Qué problema queremos resolver y qué valor generará la solución?

Objetivo organizacional	Objetivo de TI	Resultado esperado
Mejorar servicio al cliente	Modernizar canales digitales	Mejor experiencia y menor tiempo de atención.
Reducir costos	Automatizar procesos repetitivos	Menor esfuerzo operativo.
Expandir operaciones	Escalar infraestructura y aplicaciones	Mayor capacidad operativa.
Reducir riesgos	Fortalecer ciberseguridad	Mayor protección y resiliencia.

6. Convertir las necesidades en iniciativas

Una vez identificadas las brechas, estas deben transformarse en iniciativas concretas.

Una iniciativa puede ser un proyecto tecnológico, un programa de transformación, una actualización de infraestructura, una implementación de controles o una mejora de procesos.

Cada iniciativa debería tener una ficha mínima.

• Nombre.
• Problema que resuelve.
• Objetivo.
• Alcance.
• Responsable.
• Áreas involucradas.
• Prioridad.
• Presupuesto estimado.
• Beneficios esperados.
• Riesgos.
• Dependencias.
• Fecha estimada de inicio.
• Fecha estimada de finalización.
• Indicadores.

Cómo priorizar proyectos de TI

Uno de los puntos donde más valor aporta un PETI es la priorización.

En muchas organizaciones todos los proyectos parecen urgentes. El problema es que los recursos no son infinitos.

Por eso conviene utilizar criterios objetivos.

Criterio	Pregunta
Impacto estratégico	¿Qué tanto contribuye a los objetivos de la organización?
Urgencia	¿Qué sucede si el proyecto se retrasa?
Riesgo	¿Reduce un riesgo importante?
Beneficio económico	¿Genera ahorro o nuevos ingresos?
Experiencia	¿Mejora la experiencia del cliente o usuario?
Complejidad	¿Qué esfuerzo requiere implementarlo?
Dependencias	¿Existen otros proyectos que deban ejecutarse primero?

7. Construir el roadmap tecnológico

El roadmap transforma el PETI en una secuencia temporal.

No basta con decir que durante los próximos años se implementarán veinte proyectos. Hay que establecer en qué momento tiene sentido ejecutar cada uno.

Horizonte	Enfoque habitual
Corto plazo	Riesgos críticos, continuidad, problemas operativos y proyectos de alto impacto.
Mediano plazo	Modernización, integración, automatización y fortalecimiento de capacidades.
Largo plazo	Transformación, innovación, arquitectura futura y nuevas capacidades digitales.

El roadmap también debe mostrar las dependencias. Por ejemplo, no tiene mucho sentido implementar analítica avanzada si previamente no existe una estrategia para mejorar la calidad de los datos.

El presupuesto dentro del PETI

Un PETI sin presupuesto puede convertirse fácilmente en una lista de deseos.

Cada iniciativa debería tener una estimación financiera que permita a la dirección comprender cuánto cuesta ejecutar la estrategia tecnológica.

El análisis puede separar:

• Inversión inicial.
• Licenciamiento.
• Infraestructura.
• Servicios profesionales.
• Desarrollo.
• Operación.
• Soporte.
• Seguridad.
• Capacitación.
• Migración.
• Costos recurrentes.

También es recomendable diferenciar entre costos CAPEX y OPEX cuando la naturaleza financiera de la organización lo requiera.

8. Definir KPIs

Si el PETI define iniciativas pero no establece cómo se medirá su avance, será difícil determinar si realmente está funcionando.

Los indicadores deberían medir resultados y no solamente actividades.

Indicador	Qué permite conocer
Cumplimiento del roadmap	Avance de las iniciativas estratégicas.
Disponibilidad de servicios	Continuidad de plataformas críticas.
Tiempo de resolución	Eficiencia del soporte tecnológico.
Incidentes de seguridad	Comportamiento del riesgo tecnológico.
Ejecución presupuestal	Control financiero de TI.
Satisfacción de usuarios	Percepción sobre los servicios tecnológicos.
Automatización	Procesos que han sido digitalizados o automatizados.

Gestión de riesgos tecnológicos

Un PETI moderno debería incorporar explícitamente la gestión de riesgos.

Los riesgos pueden estar relacionados con ciberseguridad, continuidad, proveedores, infraestructura, aplicaciones obsoletas, pérdida de información, dependencia tecnológica, cumplimiento normativo o falta de talento especializado.

Riesgo	Impacto	Tratamiento
Aplicación obsoleta	Alto	Modernización o reemplazo.
Dependencia de proveedor	Medio/alto	Plan de contingencia y alternativas.
Pérdida de información	Crítico	Respaldo, recuperación y continuidad.
Vulnerabilidades	Alto	Gestión de vulnerabilidades y controles de seguridad.

Gobierno y responsables del PETI

El PETI no debería ser responsabilidad exclusiva del director de TI.

La estrategia tecnológica afecta a toda la organización, por lo que las áreas de negocio deben participar en su definición y seguimiento.

Una estructura puede incluir:

• Alta dirección.
• Comité de tecnología.
• Director o CIO.
• Responsables de arquitectura.
• Responsables de seguridad.
• Responsables de datos.
• Finanzas.
• Representantes de las áreas usuarias.

Esto ayuda a evitar que el PETI se convierta en un documento creado exclusivamente desde el departamento de tecnología.

Marcos y estándares que pueden apoyar el PETI

No existe una única norma que sea equivalente al PETI. Dependiendo del contexto, pueden utilizarse diferentes marcos y estándares como referencias.

Marco o estándar	Principal utilidad
COBIT	Gobierno y gestión de tecnología de información.
ISO/IEC 27001	Sistema de gestión de seguridad de la información.
ITIL	Gestión de servicios de TI.
TOGAF	Arquitectura empresarial.
ISO/IEC 38500	Gobierno corporativo de tecnología de información.

La elección del marco depende del tamaño de la organización, su nivel de madurez, los requisitos regulatorios y los objetivos que se quieran alcanzar.

Errores frecuentes al elaborar un PETI

Hay varios errores que se repiten en organizaciones públicas y privadas.

Hacer el PETI sin consultar a las áreas

TI puede conocer perfectamente la infraestructura, pero no necesariamente conoce todos los problemas del negocio. La participación de las áreas usuarias es fundamental.

Convertir el PETI en un catálogo de tecnología

Un listado de servidores, licencias, aplicaciones y equipos no constituye por sí solo una estrategia.

Prometer demasiados proyectos

Un roadmap con una cantidad excesiva de iniciativas puede parecer ambicioso, pero también puede ser imposible de ejecutar.

No calcular los costos recurrentes

El costo de una solución no termina cuando se compra o implementa. Licencias, soporte, infraestructura, seguridad y mantenimiento pueden convertirse en gastos permanentes.

No considerar la seguridad desde el principio

La seguridad no debería aparecer al final del proyecto. Debe incorporarse desde la planificación.

No actualizar el PETI

La estrategia empresarial cambia. También cambian las tecnologías, los riesgos, los proveedores y los presupuestos. Por eso, un PETI debería revisarse periódicamente.

9. Aprobar, ejecutar y actualizar

La aprobación del PETI marca el comienzo de la ejecución, no el final del trabajo.

Una vez aprobado, cada iniciativa debe pasar a una etapa de ejecución y seguimiento.

El director de TI debería establecer mecanismos periódicos para revisar:

• Avance de proyectos.
• Presupuesto ejecutado.
• Indicadores.
• Riesgos.
• Dependencias.
• Cambios en la estrategia empresarial.
• Nuevas necesidades.
• Cambios regulatorios.
• Evolución tecnológica.

Si aparece una nueva necesidad crítica, el PETI debe tener la flexibilidad suficiente para incorporar cambios sin perder el control de la estrategia.

Estructura recomendada de un PETI

Aunque la estructura puede variar dependiendo de cada organización, un documento estratégico puede organizarse de la siguiente manera:

Sección	Contenido
1. Introducción	Alcance, propósito y contexto.
2. Contexto organizacional	Estrategia, objetivos y procesos.
3. Diagnóstico actual	Estado de TI.
4. Arquitectura actual	Aplicaciones, datos, tecnología y servicios.
5. Análisis de brechas	Diferencias entre estado actual y objetivo.
6. Visión de TI	Estado futuro deseado.
7. Objetivos estratégicos	Metas tecnológicas alineadas con la organización.
8. Portafolio de iniciativas	Proyectos y programas.
9. Roadmap	Secuencia temporal.
10. Presupuesto	Estimación de inversiones y costos operativos.
11. Riesgos	Riesgos y estrategias de tratamiento.
12. KPIs	Indicadores de seguimiento.
13. Gobierno	Roles, responsables y mecanismos de decisión.

Checklist para revisar un PETI

Antes de presentar el documento a la dirección, conviene realizar una revisión final.

• ¿El PETI está conectado con la estrategia de la organización?
• ¿Existe un diagnóstico claro de la situación actual?
• ¿Se identificaron las principales brechas?
• ¿La visión tecnológica está claramente definida?
• ¿Los objetivos de TI son medibles?
• ¿Las iniciativas tienen responsables?
• ¿Existe una priorización?
• ¿El roadmap tiene fechas razonables?
• ¿Se identificaron dependencias?
• ¿Se estimaron costos de implementación y operación?
• ¿Se contemplaron riesgos tecnológicos?
• ¿Se definieron indicadores?
• ¿Existe un modelo de gobierno?
• ¿Las áreas usuarias participaron?
• ¿Existe un mecanismo para actualizar el PETI?

De la estrategia a los resultados

La lógica de un PETI puede resumirse en una cadena bastante sencilla:

ESTRATEGIA → NECESIDADES → DIAGNÓSTICO → BRECHAS → OBJETIVOS → INICIATIVAS → ROADMAP → PRESUPUESTO → KPIs → RESULTADOS

Cuando esta relación está clara, tecnología deja de ser vista únicamente como un área encargada de computadores, sistemas y soporte. TI comienza a participar directamente en la generación de valor, la eficiencia operacional, la gestión de riesgos y la transformación de la organización.

Para un director de TI, el verdadero reto no está en producir un documento extenso. Está en conseguir que el PETI sea utilizado para tomar decisiones reales: qué hacer primero, qué financiar, qué tecnología retirar, qué riesgos aceptar, qué capacidades desarrollar y dónde debe concentrarse el esfuerzo del equipo.

Un PETI bien construido debería poder ser entendido tanto por el equipo técnico como por la alta dirección. El CIO necesita hablar simultáneamente de arquitectura, seguridad y aplicaciones, pero también de costos, riesgos, productividad, experiencia del cliente y resultados empresariales.

Ahí es donde el PETI deja de ser simplemente un plan tecnológico y comienza a funcionar como una verdadera herramienta de dirección.

Etiquetas: PETI, Plan Estratégico de TI, Gobierno de TI, Gestión de TI, CIO, Director de TI, Transformación Digital