Empresas ágiles

21 julio, 2016

Las empresas de todos los sectores están importando últimamente modelos de gestión basados en la organización de la informática en la empresa y, en particular, en las organizaciones cuyo producto es la informática: negocios de internet, fabricantes de software, gestores de plataformas de contenidos o de infraestructura. No sé si es una buena idea, si se tiene en cuenta que los informáticos no son especialmente «organizados», jeje. Como decía Cusumano, una cosa es hacer software y otra cosa es gestionar una empresa de software.

De hecho, primero fue al revés: la informática copió la estructura estandarizada y predecible de los procesos industriales, el famoso PDCA, mediante sistemas de gobierno como COBIT, ITIL o CMMi. Era una forma de intentar superar, con moderado éxito, las organizaciones funcionales clásicas basadas en silos de expertise: los de desarrollo, los de infraestructura, los de operaciones, los de atención al usuario…;  los de SAP, los de Siebel, los de Java, etc.

Muchas organizaciones empezaron a trabajar por proyectos o, al menos, la forma proyecto servía para gestionar iniciativas de compañía más transversales y complejas. Aunque en realidad la gestión de proyectos venía de las empresas industriales: un proyecto es la creación de una planta de producción, un barco o un puente. Los modelos de gobierno de gestión de proyectos, como PMBoK, se usan en las ingenierías y en los departamentos de informática. Como dijimos aquí una vez, la gestión de proyectos no es construir buen software o hacer un puente que no se caiga (que también) sino que es una profesión en sí misma, con reglas, procedimientos, criterios de admisión, métricas y habilidades propias.

En el nuevo contexto económico y corporativo, más digital e informatizado, pero también más impredecible y desesperado, las empresan miran a la tecnología no sólo como una condición para el éxito de su transformación empresarial, sino también para escalar modelos de diseño organizativo que la informática ha probado antes. Las compañías aspiran a ser ágiles o bimodales: necesitan el músculo y la seguridad para manejar su negocio sin fallos y necesitan a la vez la rapidez de respuesta, el derecho al error y las estructuras planas y colaborativas que reclaman los proyectos de creatividad e innovación.

Aquí hemos publicado algunas cosas sobre metodologías ágiles. Y acabo de dirigir, con José Julio López, el trabajo final de uno de nuestros estudiantes de Máster, Alexandre Maravilla, que es un método para gestionar proyectos ágiles de business intelligence.

En su artículo clásico y premiado sobre el diseño de nuevos modelos organizativos que sirvan para acelerar la innovación y el crecimiento, Kotter (2012) dice que las empresas tienen «sistemas operativos» (sic), formados por jerarquías, procesos y sistemas de premios que conforman una cultura. Kotter aboga por la necesidad de trabajar con dos sistemas operativos a la vez: uno que soporta los procesos clave del negocio, «lo permanente» de la empresa; y otro, modelado conforme a los principios ágiles, o lean, dirigido al diseño y la implantación de la estrategia (en la informática, y en la empresa). «Una organización, dos estructuras».

Jim Highsmith, uno de los autores del «manifiesto Ágil«, va un paso más allá. Las empresas, como los desarrolladores de software, aspiran a responder rápidamente a los retos de la competencia y de los clientes y, a la vez, hacerlo con los menores costes posibles. La eficiencia en costes y la capacidad de respuesta parecen dos objetivos complementarios, pero no lo son en realidad. Uno se consigue necesariamente a costa del otro: hay una compensación, lo que en inglés llaman trade-off. Más de lo uno es siempre menos de lo otro.

Su solución, bastante lean, es que para que ésto funcione uno de los dos debe ser el motor (el driver, el objetivo), y el otro debe ser la limitación (una restricción, constraint). Todas las organizaciones necesitan manejar ese desequilibrio, como criterio de diseño: aguien empuja, alguien recoge, como en la navegación a vela. «Las restricciones», dice, «ayudan a conducir las compañías, pero son diferentes de los objetivos y no deben confundirse». (¡Un procedimiento no es un objetivo de empresa; es sólo un procedimiento! De la misma manera que un desarrollo ágil de software no se puede «controlar» o, al menos, no se puede controlar como siempre.) «La capacidad de respuesta (responsiveness) es una estrategia de negocio. La agilidad y adaptabilidad permiten alcanzar esa estrategia». El libro de Highsmith se llama Adaptive Leadership y os lo recomiendo como lectura de verano.

¡Menos management y más leadership!, reclama Kotter para las empresas que se quieran «ágiles». Aquí discutimos sobre ésto hace unos meses.

 

(Visited 144 times, 1 visits today)
Autor / Autora
José Ramón Rodríguez
Profesor de Dirección de Sistemas de Información, Gestión de Proyectos y Business Intelligence de los Estudios de Informática, Multimedia y Telecomunicación de la UOC y consultor de empresas independiente.
Comentarios
Alex Ballarin23 julio, 2016 a las 10:03 am

Hola José Ramón,

ese TFM de Alexandre Maravilla, ¿está publicado en algún sitio? Los equipos de BI tienen restricciones respecto al resto de los proyectos, y me interesa conocer la aportación de Alexandre.

Excelente blog, como siempre.

¡Saludos!

Responder
josé ramón23 julio, 2016 a las 11:01 am

Hola Alex, muchas gracias.
Publicaremos el trabajo de Alex en el repositorio institucional O2
http://openaccess.uoc.edu/webapps/o2/
De todos modos, os he puesto en contacto via mail.
Saludos.

Responder
Deja un comentario