Buscar
IMEF

Lectura 10:00 min

Nuevas finanzas para la transformación digital agilidad es la clave

La digitalización nos lleva a la transformación ágil de las finanzas y toma de decisiones para la selección y desarrollo de proyectos porque, en el mundo digital contemporáneo, el cambio constante es la nueva realidad. Ahora, los proyectos que tardaban meses para entregar un resultado son inviables porque cuando finalmente son una realidad ya no se necesitan, por ello se debe cambiar el paradigma: evolucionar a proyectos ágiles que entreguen resultados rápidamente.

Foto EE: Archivo

Cada año le pedimos a las áreas de la empresa que hagan su presupuesto de proyectos para el próximo año. Muchas veces se evalúan ideas generales y de alto nivel, pero hacer presupuestos anuales ya no se ajusta al cambio diario en los mercados, por lo que terminamos hacienda proyectos que están en presupuesto, pero que no se necesitan en la nueva realidad. Aun así, cada año las empresas gastan lo mismo en proyectos. El presupuesto en realidad no cambia mucho a nivel CAPEX y OPEX globales.

Sin embargo, los proyectos ágiles buscan entregar resultados rápidamente. No porque se programe más rápido, sino porque se parte de un mínimo producto viable, se prueba la idea en el mercado y de ahí, basado en el valor obtenido, se realizan incrementos progresivos. No esperamos 12 meses a terminar un proyecto. Procuramos el primer entregable productivo en tres meses y probamos cuanto antes la idea; si es exitosa o prometedora, se pueden hacer incrementos. El paradigma ágil implica que cada trimestre, y no cada año, las mejores ideas compitan por parte del presupuesto global.

Esta competencia se basa en los Objetivos de Negocio Comprometidos, así como en el resultado obtenido hasta ese momento, es decir, en épicas. Las épicas son entendidas como las grandes historias o logros que la empresa alcanza en su vida. Se miden con KPIs (Key Performance Indicators, por ejemplo, el porcentaje de usuarios atendidos en la aplicación móvil. Los proyectos se agrupan en programas que contribuyen a los KPIs requeridos por las épicas definidas por la estrategia.

Con el paradigma ágil se trata de fondear objetivos de programas y no proyectos. Se usa la bolsa anual para proyectos y cada trimestre se reparte la parte correspondiente para iniciar y continuar proyectos de acuerdo con su contribución a los KPIs de las épicas y a sus resultados comprobables. Los proyectos que no han demostrado valor se cancelan. En agilidad, los fracasos se celebran. Si vamos a fallar, hay que fallar cuanto antes.

Control financiero de un portafolio ágil

Los proyectos compiten por fondos cada trimestre. La bolsa de CAPEX y OPEX se reparte incrementalmente. Como es natural habrá más ideas que presupuesto. Existen dos formas de asignar este dinero: sobre una prioridad global de proyectos o sobre una prioridad global de programas y proyectos locales.

Para la primera opción, hacer una lista de orden cardinal de la prioridad de proyectos en una corporación de tamaño significativo es complicado y políticamente problemático. ¿Cómo reparte finanzas este dinero? La ventaja de que sea trimestral es que todos compiten a la vez. La empresa tiene más de un objetivo. Los proyectos aportan a más de un objetivo a la vez. El rank del proyecto debe estar basado en lo que aporte a los objetivos, moderado por el valor relativo de cada objetivo. El valor relativo de cada épico/objetivo corporativo es algo que corresponde asignar al Executive Board. La contribución del proyecto a cada objetivo le corresponde al portafolio. La multiplicación de ambos da un número que sirve para establecer un orden cardinal estricto. Una crítica tradicional al orden cardinal estricto es que la diferencia entre ellos tiende a ser circunstancial, por decimales. En realidad, es entender que solo hay dinero para hacer los primeros “N” proyectos y que una vez que se está entre esos, da igual el lugar. Lo importante es estar.

Un problema que se suele presentar en este método es cuando los objetivos menos atractivos no compiten con los comerciales. Por ejemplo, compliance vs. ventas adicionales. Cierto tipo de proyectos tenderán a nuca ser priorizados, aun siendo necesarios. Una solución es que se les saque de esta competencia y se haga una bolsa separada para ellos. La segunda opción es fondear programas y no proyectos. Al final, cada programa se compromete a alcanzar ciertos KPIs alineados a las épicas. El dinero se reparte a nivel programas con base a lo que se comprometen aportar a cada objetivo y el valor relativo de los objetivos. Pero una vez asignado al programa tiene la libertad de asignar este dinero a los proyectos que mejor considere. Aquellos que lo llevarán a sus objetivos comprometidos.

Cada trimestre se hace un QBR (Quarterly Business Review) para ver los resultados y avances de los programas y proyectos. Cuánto pidieron, cuándo se gastaron, qué consiguieron. En agilidad se hace de una forma más festiva, demo party, sobre software funcionando, pero en el fondo se hace una evaluación trimestral. Esta práctica es mejor que hacer un proyecto waterfall donde solo se evalúa el resultado al final del proyecto y durante la vida de este solo se evalúa si va a tiempo o no. Cuando un proyecto o programa no se consume el presupuesto asignado para ese trimestre, se revisa si tiene que hacerse un carry over al siguiente periodo, o si se puede reubicar a otro programa que lo necesite. Al final el carry over total es de trimestre vs. trimestre y no año vs. año. Lo anterior reduce a una cuarta parte el tamaño de carry over anual.

Liquidez de recursos

Un problema tradicional de los proyectos de tecnología es que requieren especialistas. No todos los recursos saben de todo. Sucede que tenemos empleados que saben de algo que ya no utilizamos y faltan los de especialidades nuevas que ahora necesitamos. Este desbalance causa que haya gente que se queda haciendo proyectos de muy baja prioridad porque no puede ayudar en los de más alta prioridad. Dejamos de hacer lo importante porque no tenemos recursos, pero hacemos lo no importante porque sobran.

Antes podíamos resolver este problema echando mano de terceros, pero cuando la posibilidad de tercerizar se estrecha, el problema se vuelve asfixiante. Lo que se puede hacer es una agrupación de los recursos por especialidad llamada gremios a los que, al igual que al dinero, cada trimestre se les asignan proyectos. De algunos faltan y de otros sobran. Los líderes de gremio tienen la responsabilidad de balancearlos. Una forma de medir la asignación de recursos en un trimestre es medir en que número del rank de proyectos faltó la gente para hacerlo, y a la vez cual fue el rank del último proyecto que se hizo. Por ejemplo, si en el proyecto 20 faltó gente y el 100 se ejecutó tenemos un problema de liquidez de recursos. La gente se asigna a un proyecto y cada tres meses recibe una evaluación 360 de todos sus compañeros, que se le manda a la persona y a su líder de gremio quien tiene la responsabilidad de que su gente esté bien evaluada.

Capex y Opex en agilidad

Uno de los retos del control financiero de proyectos es que llevemos la cuenta de las horas dedicadas a cada uno de ellos. Esto es particularmente complejo cuando un mismo recurso está asignado a múltiples proyectos en un mismo periodo de tiempo. Para llevar ese complejo control se han desarrollado herramientas que ayudan a llevar la cuenta y capitalizar adecuadamente los costos.

En los proyectos agiles, se busca que las personas que estén dedicadas exclusivamente al proyecto. Menos gente, pero más dedicada. Esto hace que las personas estén, cuando mucho, en dos proyectos, idealmente en uno y que, por lo tanto, el control de sus horas capitalizables sea más sencillo y exacto.

Tradicionalmente es discutible si el diseño de arquitectura o las pruebas de un sistema son capitalizables. En un proyecto ágil, el diseño y las pruebas son ejecutados por los mismos desarrolladores y son parte fundamental. Sin embargo, roles como el de Product Owner o Scrum Master siguen siendo parte del OPEX de los proyectos, así como el soporte de una implementación. El recurso más escaso en el presupuesto anual es el OPEX para proyectos, pues como sabemos, va directo al gasto. Si no se tiene un adecuado control del OPEX se puede llegar a terminar antes que el CAPEX y tendremos un problema de diferencia contra el presupuesto anual. Sin embargo, la solución no es dejar de hacer proyectos cuando aún tenemos CAPEX, sino tratar de capitalizar tanto como sea posible, y entender que hay proyectos que por su naturaleza requieren más de un tipo de recurso.

Entre las formas de convertir OPEX en CAPEX en un proyecto está el considerar que, durante el primer año del proyecto, algunos conceptos se pueden incluir como costo de producción. Por ejemplo, soporte o licenciamiento adelantados. Sin embargo, las nuevas tecnologías más flexibles han ocasionado que tengamos más OPEX. Por ejemplo, dejar de tener infraestructura on premises y tenerla en la nube hace que algo que antes podíamos depreciar ahora se incierte en un gasto mensual. Todos los términos de “aaS” como PaaS (Platform as a Service) o IaaS (Infrastructure as a Service) hacen este mismo efecto. Se reduce la inversión inicial, también la capitalización de proyectos.

El mundo ágil requiere de infraestructura flexible para montar ambientes donde vivirán las nuevas plataformas. Amazon (AWS) y Microsoft (Azure) son algunas de las plataformas cloud que están a disposición de los proyectos. Muchas de ellas con presencia nacional, lo que ayuda con algunas regulaciones que exigen que ciertos datos de los clientes no abandonen el suelo nacional. Junto con estas plataformas están las suites de herramientas que ayudan a hacer desplegados en producción más rápidos y en manos del mismo proyecto.

Agilidad significa que se liberarán funcionalidades a producción con mayor frecuencia, en cierto sentido más rápido. En vez de esperar versiones trimestrales hay empresas que cada semana, si no es que cada día, suben una nueva versión de sus sistemas. Sin embargo, entre más cambios hay más probabilidad de errores. Agilidad propone que, haciendo uso de tecnologías como el cloud, no todo dependa de una sola instancia. Las cosas pueden estar en múltiples instancias coordinadas, de manera que si una falla no todo se vea afectado. O que, si se introduce un cambio, este no sea en todas las instancias a la vez, para que, en caso de falla, se balanceen las cargas.

Un mundo ágil

La nueva transformación requiere también de más ideas y más innovación, pero probar más ideas en menor tiempo, y con menor presupuesto, implica que rápidamente nos quedaremos sin ellas. Si la única fuente de ideas son los jefes, y no los equipos, pronto se nos agotarán. La agilidad facilita el rebalanceo dinámico de recursos económicos y humanos. Nos ayuda a un control más cercano y no solo el anual. Nos incentiva a renunciar a las ideas malas y seguir buscan los buenas a un menor costo. La agilidad llegó para quedarse y es una transformación que tendremos que abrazar por el bien de las organizaciones y la sociedad.

*El autor es AVP Transformación Digital, AT&T México.

Temas relacionados

Únete infórmate descubre

Suscríbete a nuestros
Newsletters

Ve a nuestros Newslettersregístrate aquí

Noticias Recomendadas