Una propuesta "inversa" al momento de incubar proyectos de TI

A lo largo de mi experiencia con los clientes en el desarrollo de proyectos de TI, inumerables ocasiones (o casi todas ellas), se hace un desarrollo "tradicional" de estos proyectos pensando en la infraestructura que se requerirá (switches LAN, ruteadores, access points, IP PBX, equipos de videoconferencia, teléfonos, etc).

Se revisa aunque no en todos los casos y es importante hacerlo, lo que llamo servicios de soporte o componentes habilitadores del servicio, que es todo aquello que "proporciona la red" para que las soluciones de TI puedan ser implementadas en todo su explendor (servicio de DHCP, NTP, syslog, virtualización, management, respaldo de energía, entre otros muchos).

Entramos entonces, en las dinámicas también tradicionales de citar a proveedores o fabricantes para que muestren los nuevos equipos o soluciones que tienen para considerarlas en el proceso de evaluación, se llevan a cabo los famosos cuadros comparativos, se piden propuestas preliminares para establecer el costo probable de inversión, ajustamos el proyecto alrededor de ello, hasta llegar a un formal RFI o estudio de mercado con su siguiente RFP o publicación del concurso en forma, muchas veces, con un anexo del tipo "lista de súper" en donde se da santo y seña de los modelos, marca y cantidades de equipos requeridos (hardware, software y licencias).

Esta dinámica de trabajo, tiene al menos 2 inconvenientes:

1.- Primero, provoca el desarrollo del proyecto de TI de inicio a fin con una óptica puramente de ingeniería y se deja de lado el principal objetivo de la TI "proveer de tecnología o aplicativos a los usuarios de la organización (negocio)". Este enfoque lo llamo la estructura de pirámide tradicional y en donde el usuario queda en último lugar, el resultado es regularmente un simple "refresh" en donde pocas aplicaciones nuevas acaban en las manos de los usuarios.

2.- Segundo, los pocos servicios o aplicativos que llegan al usuario, comúnmente llegan a quedar "amorfos". Me refiero con el término "amorfo" a que el mismo servicio no puede convivir o comunicarse por caer en silos de TI diferentes (el servicio de comunicación llamemosle audiovisual, de la sala de videoconferencia no puede comunicarse por ejemplo con los dispositivos con este mismo servicio que estan registrados en el PBX IP, increíble! el mismo servicio y no tiene transparencia en su funcionamiento).

¿Cómo solventar entonces estos desafíos?

Qué les parecería invertir la pirámide anterior y pensar primero en los servicios a habilitar en los usuarios del negocio (aplicativos), después en los componentes de la red para hacerlos realidad de manera integral y solo despúes, poner atención en la infraestructura que se requerirá para llevar a cabo estos servicios. La propuesta quedaría así:

Tip

Recordemos que la palabra "servicio" la ocupo para describir la tecnología (aplicativos) a poner en las manos del usuario (aspecto funcional) y no para referirme al esquema comercial de adquisición de la tecnología (servicio de outsourcing).

Al realizar el mapeo utilizando la propuesta de pirámide inversa, garantizamos tener en mente la eliminación de los silos tradicionales en las diferentes áreas de la TI (y su proceso de unificación o convergencia), entregar servicios al usuario de negocio que serán parte del impacto en los procesos de negocio en última instancia y evitar las "amorfidades" tradicionales del servicio.

¿Le encuentran el valor?.