Hace ya más de seis años que me estrené en este blog y uno de los primeros post que escribí trataba sobre uno de los palabros de moda por aquel entonces: DevOps. Luego hubo ocasión de familiarizarse con este acrónimo con ayuda de las películas del oeste, de la mano de un compañero. Más tarde llegaron AIOps, DevSecOps o NetDEvOps. Pues bien, si pensabais que vuestra compañía ya había aplicado todas las posibles conjugaciones del Ops, os faltaba el FinOps.
Uno de los principales problemas que históricamente han tenido los modelos de pago por uso, principalmente asociados a la provisión cloud, ha sido su gestión económica por el riesgo e incertidumbre asociados. Y es que eso de que la nube siempre es más barata es un mito alrededor de cloud.
Realizar inversiones financieras en lo que a activo se refiere siempre ha sido mucho más sencillo para poder medir su rentabilidad. Bastaba con indicadores como el ROI o el coste total de propiedad.
Recelo a los modelos de pago por uso
Sin embargo, el pago por uso o pago variable, asociado normalmente a un modelo de suscripción, resulta mucho más difícil de gestionar. Las suscripciones multiproducto o con precio variable en catálogo, como suele ser el modelo de créditos, complican la gestión en entorno empresariales grandes o multiproyecto. Solo se establece una línea base de consumo, definida a partir de una arquitectura inicial de proyecto, pero sin limitar la responsabilidad del usuario final en cuanto al uso de ésta.
Todos sabemos que los proyectos son entes vivos que se transforman y mutan. Según el área en la que se inscriban o el responsable de ésta, las prioridades pueden llegar a cambiar o desaparecer de la noche a la mañana. De ahí el recelo a los modelos de pago por uso desde el punto de vista empresarial, y sobre todo del sector público.
Orígenes del termino FinOps
Los orígenes del acrónimo FinOps se remontan a casi una década atrás, cuando algunas empresas como Adobe e Intuit empezaron a utilizarlo. Según relatan J.R. Storment y Mike Fuller en su libro “Cloud FinOps”, años más tarde compañías como Qantas y Tabcorp comenzaron a aplicar una práctica similar. Hacia 2017 BP o Sainsbury’s desarrollaron este mismo nuevo enfoque para la gestión financiera de sus proyectos en la nube.
Podríamos decir que lo que hoy conocemos como FinOps nació lentamente en todo el mundo, a medida que los desafíos financieros y de gestión de proyectos cloud se presentaban a escala en cada territorio.
A lo que hoy conocemos como FinOps hace años las empresas simplemente lo llamaban "gestión de costos de la nube" u "optimización de los costes de la nube". Más tarde, los proveedores de cloud comenzaron a hablar de "gestión financiera de la nube" y así llegamos a "FinOps". La elección del acrónimo, derivado de DevOps, pone de relieve el vital aspecto multifuncional y ágil de este enfoque de gestión de proyectos cloud.
Pero qué es realmente FinOps
Desde hace años existe una fundación, auspiciada por la Linux Foundation, para promover esta disciplina, así como la gestión financiera de la nube a través de las mejores prácticas, la formación y los estándares.
FinOps es, en definitiva, la práctica de llevar la responsabilidad financiera al modelo de gasto variable de los servicios cloud. Esto permite a los equipos distribuidos hacer concesiones comerciales entre velocidad, coste y calidad. Facilita el equilibrio entre la operación distribuida y el control de costes centralizado.
FinOps es el modelo operativo de la nube, que está dando lugar a un cambio que combina sistemas, mejores prácticas y cultura para aumentar la capacidad de una organización de comprender sus costes de la nube y tomar decisiones de negocios meditadas. FinOps pone en valor para las organizaciones el gasto en servicios en la nube. Reúne a los profesionales de tecnología, gestores de negocio y equipos de finanzas y control de gestión con un nuevo conjunto de prácticas y estándares en torno a la gestión financiera en la nube.
La búsqueda de la eficiencia como principio rector
Básicamente es un principio de libertad presupuestaría, que consiste en usar con cabeza el presupuesto propio para no afectar al del resto, con una medición, análisis y previsión del gasto del proyecto y el impacto sobre otros. Y es que la búsqueda de la eficiencia es uno de los principios rectores de esta filosofía de trabajo.
Una necesidad que se pone aún más de manifiesto cuando empezamos a pensar en entornos multicloud.
Las tres fases de un proyecto FinOps
Según la FinOps Foundation, cualquier proyecto gestionado bajo el enfoque FinOps debe pasar por tres etapas iterativas, que son: informar, optimizar y operar.
Informar en busca de una responsabilidad compartida
La primera de ellas, informar, busca ofrecer visibilidad para la asignación de recursos al proyecto. Con ella se trata de crear el compromiso del equipo en cuanto a la responsabilidad compartida del presupuesto, al mostrar al resto de los miembros del equipo lo que se está gastando y por qué.
Optimizar y consensuar los ajustes
Una vez que está claro qué se necesita y el gasto que requiere, llega el momento de los ajustes para conseguir ser más eficientes en operación y gasto. Ésta es la fase de optimizar, en la que los equipos deben tomar las acciones correctas siempre con un ojo puesto en los objetivos iniciales del proyecto.
Incluye el ajuste y reasignación de permisos sobre la infraestructura del proyecto, ya que los equipos que despliegan no han de ser los mismos que operan, el equipo de seguridad no tiene las mismas atribuciones que los gestores de base de datos, etc. Una vez que las cosas funcionan los ajustes o mejoras han de ser consensuados.
Operar a través de la mejora continua
Y, por último, la operación de los servicios, el gran olvidado de cualquier proyecto. En esta fase se ha de buscar la eficiencia, con el objetivo de perfeccionar esos objetivos compartidos que tienen los departamentos de TI, finanzas y negocios para centrar y ampliar los esfuerzos operativos a través de la mejora continua. Básicamente se trata de buscar el mínimo común denominador de los objetivos y necesidades de cada área para optimizarlo al máximo.
Y para todo este proceso y búsqueda del equilibrio en la gestión empresarial aplicada a los proyectos de la nube se podría aplicar la Teoría de Juegos no cooperativos de John Nash.
Veamos: en la búsqueda de ese equilibrio cada departamento conoce y ha adoptado su mejor estrategia y todos conocen las estrategias de los demás. En consecuencia, ningún departamento gana nada modificando su estrategia mientras los otros mantengan las suyas. Así, cada departamento está ejecutando el mejor "movimiento" que puede dados los movimientos del resto de ellos.
Imagen: Sustainable Economy Law Center
Soluciones y Sectores
Te puede interesar
-
Edificios sostenibles para un turismo más inteligente y competitivo
El sector turístico representó el año pasado el 12,2% del PIB en España. Se trata, por tanto, de un ...
-
La capacitación en industria 4.0, condición sine qua non para su transformación
Recientemente leía un artículo sobre “Desafíos de la industria europea en la nueva coyuntura socioeconómica”. En él se apuntaba, ...
-
Hospitalización domiciliaria: un nuevo paradigma en la gestión de pacientes crónicos
Como explicaba en un post anterior, asistimos a la transformación de la atención médica para mejorar la calidad de ...
