Proyectos IT versus Servicios IT

Es un hecho cada vez más reconocido que las organizaciones están dependiendo cada vez más de las tecnologías de la información para alcanzar sus objetivos corporativos y sus necesidades de negocio. Para alcanzar dichos objetivos las organizaciones realizan trabajo, y las labores que realizan los sistemas de información o sus departamentos IT se pueden considerar como una parte muy importante de ese trabajo. Como cualquier tipo de trabajo realizado por una organización, este se puede clasificar de forma general en operaciones y proyectos. Puede haber casos en que ambos se superpongan, como en el mantenimiento evolutivo de una aplicación de software empresarial; pero también hay casos en los que existe gran confusión respecto a sus dominios de aplicación: referirse a algo como un proyecto cuando en realidad es una operación, no delimitar claramente cuando un trabajo deja de ser un proyecto y pasa a ser una operación, etc.

Así pues, esta clasificación del trabajo entre operaciones y proyectos no es para nada un asunto académico sino que tiene unas consecuencias prácticas muy directas a la hora de tener éxito y alcanzar los objetivos corporativos. Porque, aunque tanto operaciones como proyectos sean realizados por personas y estén planificados y controlados, la forma de organizarse, asignar recursos, planificar el trabajo, desde un punto de vista metodológico en definitiva, son diferentes. En esencia las operaciones son continuas y repetitivas mientras que los proyectos son temporales y únicos. No es lo mismo planificar una línea de montaje que fabrica lavadoras en serie (operaciones) que construir toda la infraestructura que constituye la propia línea de montaje (proyecto). De la misma manera, no es lo mismo implantar un CRM que utilizarlo en las operaciones diarias del negocio. La finalidad de las operaciones es mantener el negocio. En cambio, la de un proyecto es alcanzar sus objetivos y, aunque muchas veces parezca mentira, terminar. La explotación de un CRM mantiene o ayuda a mantener el negocio formado parte de las operaciones diarias a partir de unos procesos de negocio predefinidos y repetitivos; su construcción es un proceso que se inicia y se finaliza cuando se han alcanzado los fines para los que se decidió su construcción. Posiblemente, antes de la implantación del CRM, existían otros procesos operativos diferentes para la gestión de clientes que han sido sustituidos después. Así que aquí tenemos otra gran diferencia: los proyectos provocan un cambio. No por capricho. Si el entorno no cambiara, si las necesidades de los consumidores y clientes siempre fueran las mismas, los productos y servicios tampoco lo harían y, por tanto, el propio negocio y su mantenimiento permanecerían de forma indefinida. Pero el entorno cambia, los productos y servicios cambian, y por ende los objetivos de las operaciones cambian con el tiempo, aunque continúan adoptando otros. Esos cambios en las operaciones son provocados por los proyectos: con el advenimiento de Internet el sector bancario tuvo que vincular sus entornos HOST y bases de datos, en los que residían los cimientos de las operaciones bancarias, a las nuevas infraestructuras y transacciones realizadas a través de Internet.

Desde un punto de vista gerencial también existen diferencias. Las operaciones, que llevan un mayor recorrido desde el punto de vista metodológico y organizativo –y a pesar de que no sean más antiguas, proyectos se han realizado desde los albores de la civilización-, se sustentan mediante una estructura organizativa funcional, mientras que los proyectos deberían sustentarse mediante una estructura más orientada a proyecto. Y digo deberían porque en la mayoría de los casos perdura la más afianzada estructura funcional. Ejemplos de estas diferencias los encontramos en los aspectos que deberían caracterizar a un gerente de proyecto frente a un gerente funcional. Aspectos como pueden ser el enfoque, el estilo y la responsabilidad. Mientras que un gerente funcional posee un enfoque analista especializado en su área funcional, un gerente de proyecto debería tener un enfoque más generalista debido a que un proyecto suele abarcar diferentes áreas funcionales. El estilo del gerente funcional es el de experto de su respectiva área funcional, en cambio el del gerente de proyecto debe ser un estilo facilitador: no puede ni debe ser un experto en todas y cada una de las áreas funcionales que abarca el proyecto, pero debe conseguir que los verdaderos expertos tengan lo que tienen que tener en el momento preciso para que puedan realizar su trabajo. Finalmente, la responsabilidad del gerente de proyecto es la de asegurar los resultados del proyecto a diferencia de la de un gerente funcional que es la de la tecnología y recursos de su área funcional.

Como vemos, la diferencia entre operaciones y proyectos no es trivial. Por ello se uitilizan, o debería, metodologías diferenciadas para abordar cada caso, como pueden ser ITIL para operaciones de servicios IT y Prince 2 para proyectos IT, por citar un par de ejemplos muy fashion en estos tiempos. Esperemos que no se queden muy old fahsioned en poco tiempo, como muchas otras modas pasajeras del managamet, si se me permite el uso indiscriminado de anglicismos tan de moda, por cierto, en nuestro entrañable y castizo management.