.svg)
Optimización del desarrollo y operaciones de la banca
En las publicaciones anteriores trabajamos sobre la distribución y gestión de los equipos. No obstante, para que estos aspectos funcionen necesitan alinearse con una arquitectura orientada a resultados.
Una de las áreas que tienen un mayor impacto en el banco es la de tecnología, por ello proponemos darle una mirada más profunda a estudiar cómo realizar tareas de optimización de desarrollo y operaciones (DevOps) en la banca.
Nos meteremos en este tema, pero antes recuerda que puedes suscribirte al newsletter de Ginko y recibir contenidos exclusivos cada mes en tu correo.
El objetivo del área de tecnología es aportar valor a sus clientes
La búsqueda del área reconocida como Tecnología es poner en marcha estrategias de negocio que busquen entregar una mejor experiencia a los clientes en los productos actuales y el desarrollo de nuevos productos.
Cuando tenemos la capacidad de moldear el desarrollo de una idea desde su concepción hasta el resultado final es «sencillo» obtener el resultado que buscamos entregar al usuario y, a su vez, que ese resultado haga sentido al modelo de negocio del banco.
Sin embargo, la división habitual en áreas dentro de un banco complican siempre esta tarea.
Una división que consiste en un desarrollo donde las diferentes áreas acostumbran a desentenderse del proyecto luego de terminar con su tarea y enviar el resultado. De esta manera, solo si la parte receptora entiende que hay que realizar cualquier cambio, se vuelve hacia atrás. Si no es capaz de identificar el potencial error, continuará hacia delante, aunque el error siga existiendo.
DevOps: un proceso necesario para el área de tecnología
En la imagen de la izquierda se puede ver la distribución que se realiza de forma habitual en las estructuras más tradicionales. Mientras que en la segunda se ven los equipos multifuncionales que cambiarán la manera de trabajar.
En la primera, la propia estructura hace que sea muy complicado lograr una comunicación con un propósito común porque cada uno trabaja de manera independiente. Son los famosos silos funcionales en los que cada parte juega su propio partido.
Parte del catalizador de la transformación está en la integración de las tres claves que Dan Pink desarrolla en su libro Drive (sentimiento de propiedad, autonomía y maestría) para comprender que es imposible plantear procesos si no existe una distribución de equipos correcta, gestionados por las personas adecuadas.
Sin embargo, en muchas ocasiones el área de tecnología no se compromete con el resultado final porque no es capaz de entender cuál es el fin de las acciones que realizan.
Ese es el motivo por el que necesitamos un proceso estratégico de DevOps. Una serie de prácticas para acercar el desarrollo a la operación del software.
Para desarrollar de la forma más efectiva el proceso de entrega de valor al cliente es necesario entender dónde hay que poner el foco.
En lugar de centrarse en qué tecnología hay que emplear, la meta ha de estar en obsesionarse con el problema a resolver. Es decir, es un cambio de perspectiva.
En lugar de partir pensando en qué tecnología empleamos, lo haremos definiendo cuál es la mejor opción para solucionar los problemas y desafíos que tenemos por delante.
De esta manera podremos encontrar la forma de maximizar la entrega del valor durante el proceso completo, ya que transformaremos la manera de entenderlo.
Cómo gestionar el trabajo para maximizar resultados
Como el tiempo es un recurso finito es fundamental gestionarlo de manera eficiente para convertirlo en valor.
A la hora de desarrollar la gestión del trabajo, Ginko construye parte de su pensamiento sobre la obra The Phoenix Project de Gene Kim, Kevin Behr y George Spafford.
Un libro que plantea la existencia de 4 categorías de trabajo que hay que considerar a la hora de desarrollar un plan de actividades.
- Trabajo planificado: se refiere a los nuevos proyectos y nuevas categorías del negocio.
- Proyectos internos: relacionado con todo lo que se puede unir a migraciones de servidores y actualizaciones de plataformas.
- Cambios y optimizaciones: con el objetivo de realizar mejoras en los trabajos que ya han sido realizados.
- Trabajo no planificado: acciones de soporte y actuaciones ante situaciones de emergencia.
A partir de estas cuatro categorías de trabajo se puede desarrollar un plan de mejora continua, que actuará como elemento clave del desarrollo del negocio.
Kaizen: la mejora continua como clave del desarrollo de negocio
En el proceso de desarrollo de software se pueden aplicar las prácticas empleadas por metodologías LEAN, que podemos resumir en tres pasos para maximizar el flujo de valor.
Flujo
Hay que limitar el trabajo que se tiene en curso al mismo tiempo.
Cuando se realizan actividades de forma paralela, aumenta demasiado la carga cognitiva y la complejidad en la gestión de proyectos.
Además, es importante eliminar las restricciones o los cuellos de botella para mantener el foco en lo importante.
Feedback
Los grupos de trabajo que reciben los insumos deben ofrecer un feedback a los emisores para mejorar el proceso de trabajo.
De esta manera, es fundamental sistematizar un proceso de feedback continuo para maximizar la eficiencia.
Aprendizaje continuo
Entender la idea de que, si bien nadie espera lograr la perfección, el objetivo será siempre mejorar.
Pequeños pasos continuos son suficientes, en vez de esperar implementar solo cuando se haya logrado algo perfecto.
El proceso de mejora continua comienza midiendo resultados
Disponer de información no sirve de nada si no podemos tomar decisiones con esos datos.
Por eso, igual de importante es gestionar los datos recogidos para tomar las decisiones adecuadas. Para ello se pueden utilizar los siguientes indicadores.
- Frecuencia de deploy: mide el número de ocasiones en las que se despliegan los cambios de valor a lo largo de un determinado período.
- Tiempo de deploy: indica cuánto tiempo se demora el proceso de deploy (cuanto más rápido se ejecute, más veces podrá realizarse).
- Tiempo de entrega: muestra cuánto se demora una idea desde que comienza su desarrollo hasta que se despliega.
- Porcentaje de deploy fallido: como su nombre indica, muestra el número de errores que ocurren durante el proceso.
- Disponibilidad: indica el tiempo que los servidores están funcionando y, como contraparte, cuánto tiempo están caídos.
Gracias a la información que se recibe con estos indicadores se pueden tomar decisiones para iniciar el proceso de mejora continua.
Como descubrimos en los artículos previos, el proceso de DevOps solo será efectivo cuando los líderes de la organización sean capaces de transmitir la visión del negocio y organizar los grupos humanos, y que estas acciones formen parte de la cultura organizacional.
No existe evolución tecnológica, sistema o proceso que pueda sustituir el aspecto de la visión y la organización. Y la realidad es que normalmente es el área de tecnología la que se encuentra «aislada» en todos los procesos sin saber el porqué de las peticiones que reciben.
Gracias a plataformas omnicanal como PSD se puede acabar con esa arquitectura tradicional basada en silos funcionales e integrar al área de tecnología en el contexto global del banco.
Una manera de aumentar la motivación, compromiso y alineamiento con los objetivos finales de la organización del área de tecnología y de cualquier otra que forme parte del proceso.
