La función de tecnología a dos velocidades

Mayo 07, 2015 - by administrador

Carlos Ardila Arenas

Las áreas de negocios se quejan desde hace decenios de la lentitud del área de TI para implementar los proyectos que soportan la estrategia del negocio. Sólo cuando implementan una función seria de gestión de la demanda, logran mantener en un tamaño moderado la cola de requerimientos de mantenimiento a las aplicaciones existentes, pero difícilmente tienen tiempo para pensar en el futuro.

La razón es clara. Un área dedicada a mantener los centros de cómputo, sus servidores y redes operando de forma segura y con el desempeño correcto, tiene un ADN distinto al de las personas que están pensando cómo atraer clientes con aplicaciones móviles o interactuar con ellos a través de redes sociales o detectar patrones en las transacciones históricas, para mejorar la efectividad de las campañas de mercadeo.

El área de TI como la conocemos hoy, está focalizada en los procesos, el control, la disciplina, la efi- ciencia. Cada año le imponen nuevos KPIs y SLAs cuyo cumplimiento afecta incluso su remuneración. Están inmersos en una lucha para mantener operativo un enjambre de máquinas y software heterogé- neos e interconectados en una maraña compleja, que deben ser reemplazados periódicamente por su corto lapso de obsolescencia.

Pedirle a la organización tradicional de TI que soporte la innovación es tan frustrante, como pedirle a un tigre observando su perfección que vuele.

Por esta razón, hoy estamos partiendo las áreas de TI en dos. La primera, “change the business” y la segunda, “run the business”. El CIO (Chief Information Officer) “run the business”, el CDO (Chief Digital Officer) “change the business”.

Si su organización depende directamente de la tecnología, no dude en separar la función de TI en dos áreas, ambas dependiendo del CEO.

El área que cambia el negocio debe tener por lo menos un componente de innovación, uno de arquitectura y una PMO.

La función1 de innovación incluye la planeación estratégica tradicional, en la que se asegura la alineación de la tecnología con las implicaciones que generan los imperativos de la estrategia del negocio. Pero ahora además, debe preguntarse permanentemente cómo innovar el modelo de negocios con base en tecnología. ¡Son personas con una solución en busca de un problema! 

La función de arquitectura tiene a su cargo el diseño de nuevos servicios tecnológicos definidos por la función de innovación, asegurando una visión holística de la TI y vigilando que los proyectos que los implementen sigan sus lineamientos.

Un síntoma claro de inmadurez de una función de TI es su desprecio por la arquitectura; sienten que tomarse un tiempo pensando y documentando el “cómo” del nuevo componente informático es una pérdida de tiempo. Este sentimiento se ve agravado con frecuencia, por las expectativas irracionales de tiempo de las personas del negocio, generadas por su inexperiencia en proyectos de TI.

La función de gerencia de proyectos (PMO) debe ser fuerte en una compañía dependiente de la TI (casi todas en la actualidad). Debe estar conformada por líderes más que gerentes; por personas capaces de lograr que los proyectos se ejecuten a tiempo y en presupuesto. Capaces de motivar al equipo del proyecto y actuar como integrador con los proveedores, controlándolos con un nivel de rigor adecuado.

Su capacidad de liderazgo es más importante que su conocimiento del PMBOK y más trascendente que su certificado de PMP. Conseguir PMPs es relativamente fácil, conseguir líderes es difícil. Creer que alguien con un certificado PMP es un buen gerente de proyecto, es como mandar a una persona escogida al azar a una escuela de música y creer que regresará siendo un gran tenor.

Vale la pena considerar la ayuda externa de consultores con una trayectoria demostrada de éxito en proyectos complejos, que actúen como “shadow managers” apoyando y entrenando a los internos.

Es clave además, la participación activa y un compromiso real del sponsor; no arranque un proyecto sin un sponsor realmente comprometido con él, decidido a asistir puntualmente a las reuniones de seguimiento, durante las decenas de semanas que dure el proyecto. El sponsor debe ser una persona de las áreas de negocios, para quien el proyecto sea crucial en el logro de sus objetivos y debe responder por la captura de sus beneficios.

El CIO debe hacerse cargo de la operación, el soporte y la implementación de los lineamientos de seguridad, definidos por un área externa, tales como riesgo operativo, auditoría o cumplimiento.

En general, el CDO define nuevos productos y servicios basados en tecnología, los diseña e implementa. El CIO recibe los proyectos y los pone en operación asegurando su desempeño, seguridad y servicio al usuario interno y externo.

La definición de una interfaz clara entre las dos áreas es crítica. Es necesario definir la intensidad y oportunidad de la participación del área de operaciones en los proyectos y los mecanismos, para asegurar un nivel de calidad razonable; de lo contrario, el área de operaciones puede terminar haciendo rollout de aplicaciones inmaduras, plagadas de errores, que además no conoce.

Un último aspecto general que debe ser definido por el CEO, es la agresividad en la adopción de nuevas tecnologías. La adopción temprana de tecnologías de información implica riesgos asociados a su inmadurez y a la inexperiencia de los actores que la proveen y operan. Ese riesgo debe estar definido por componentes.

En un banco por ejemplo, el nivel de criticidad del sistema core, de su banca en línea y banca móvil, de su sistema de tesorería y de la bodega de datos, es claramente distinto. La decisión de llevarlos a la nube, por ejemplo, debe ser analizada individualmente y la estrategia de mitigación de riesgos, tales como pruebas de concepto y opacamiento de la información, debe ser definida por tipo de aplicación.

Si la tecnología es central en el desarrollo de su modelo de negocios, no pretenda que la gente dedicada a su operación segura y dentro de indicadores rigurosos, tenga tiempo para definir y desarrollar los proyectos que evolucionen su empresa.

Finalmente, no subestime la complejidad de los proyectos; asigne los recursos en cantidad y calidad adecuada, la tecnología tiene una habilidad particular para vengarse, a través de proyectos que duran y cuestan dos o tres veces lo estimado inicialmente.

1Hablo de funciones, no de áreas, pues dependiendo del tamaño y tipo de empresa, la organización de TI puede cambiar implementando las mismas función.

 

Carlos Ardila Arenas. Ingeniero Civil de la Universidad de La Salle con maestría en Ingeniería de Sistemas y Computación de la Universidad de Los Andes. Tiene más de 35 años de experiencia en consultoría, con énfasis en planificación estratégica de IT, selección de soluciones, arquitectura empresarial y de TI, QA y gerencia de proyectos de TI e infraestructura, en el norte de América Latina, Panamá y Estados Unidos. En 1981 fundó Compucentro, una de las primeras firmas de consultoría, que en 2006 se fusionó con Advantis, de la cual es Director. Fue profesor en la universidad de Los Andes y dirigió la Asociación Colombiana de Ingenieros de Sistemas (Acis) durante cuatro años.

0 Comentarios

Deje su comentario