Pour aller numérique, la finance doit fonctionner différemment

Partie 3 de la série Finance Automation

Les entreprises passent au numérique à travers des programmes de transformation à grande échelle, et ce n'est pas différent pour la fonction finance. Dans le deuxième blog de cette série, « Une feuille de route pour la transformation des finances numériques des CFO », Bart et moi avons décrit les différentes technologies que la finance peut utiliser dans sa transformation numérique. Cependant, vos méthodes de travail traditionnelles ne sont peut-être pas la meilleure façon de les mettre en œuvre et de les intégrer dans votre modèle d'entreprise. Les programmes de transformation à grande échelle de trois ans ne fonctionnent tout simplement pas pour le numérique parce que la technologie aura évolué de façon significative au cours de cette période. C'est pourquoi vous entendez parler d'entreprises qui ont besoin de devenir «agiles». Mais que signifie vraiment agile dans le contexte de la mise en route de votre transformation numérique? C'est ce que nous allons explorer ici.

Agile!?! N'est-ce pas juste un consultant de fantaisie – parler avec peu de sens?

Il ne sera pas facile d'amener votre fonction financière à travailler de façon innovante pour passer au numérique. Mais correctement expliquées, vos équipes peuvent comprendre la nécessité de ces façons de travailler pour accélérer la livraison de produits numériques dans votre fonction financière, qu'il s'agisse de BI, d'automatisation, de robotique, etc. Nous aimerions en porter deux à votre attention: le design thinking et DevOps

Design thinking: comprendre le problème

Le design thinking est un concept relativement nouveau. Une approche commune de la pensée de conception est de suivre un certain modèle. C'est celui que nous recommandons

Empathize: Mettez-vous dans la peau des utilisateurs qui font face au problème. Asseyez-vous avec eux pour comprendre leur expérience.

Définir: Sur la base des entrées collectées auprès des utilisateurs, créez un personnage. Cela devrait être une personne fictive. Décrire les points de la douleur, le rôle, les besoins et les émotions du problème.

Ideate: Faire un remue-méninges sur les solutions potentielles. Ici, il est important que vous vous demandiez si la solution proposée va être souhaitée par les utilisateurs, si l'idée est réalisable et si elle est viable. À la suite de cet exercice, il devrait répondre aux résultats des étapes 1 et 2. Sur la base de la solution proposée, commencer à construire une conception d'expérience utilisateur (UX) basse-fidélité. La conception basse-fidélité est à nouveau partagée avec les utilisateurs, et vous obtenez des commentaires. Basé sur les commentaires, vous ajustez votre conception. Ce processus doit subir plusieurs itérations jusqu'à ce que vous puissiez créer un design final, également connu sous le nom de design UX haute fidélité.

Prototype: Une fois que votre conception est prête, demandez à une petite équipe d'ingénieurs ou de développeurs de construire un prototype. . Démontrez régulièrement votre prototype à vos utilisateurs finaux pendant le processus, ce qui ne devrait pas prendre plus de quelques semaines. Le prototype ne vise pas à répondre à toutes les normes architecturales et à satisfaire à toutes les autres exigences internes, mais à prouver que la solution proposée pourrait fonctionner.

Test: Une fois le prototype terminé, commencez à le tester pour qui vous construisez le prototype. Après des tests réussis, passez-le à DevOps pour passer du prototype à la production

DevOps: accélérer la solution

Dans les projets informatiques classiques, l'une des méthodologies de gestion de projet les plus courantes est l'approche waterfall. Cette approche comporte certaines phases, telles que la collecte des exigences, la conception, la mise en œuvre, le test et le déploiement en production. Cependant, les exigences sont définies au début du projet et ne peuvent pas changer pendant le projet. Ceci est, bien sûr, un défi, puisque vous recevez des commentaires des utilisateurs finaux seulement dans la phase de test ou pire, dans la phase de déploiement.

DevOps utilise une approche agile comme les mêlées et les sprints, dans le but de réduire considérablement le délai entre l'apparition d'un problème et la mise en place d'une solution numérique. Le but de la mêlée est de recueillir les commentaires des utilisateurs dès que possible et est basé sur le concept du produit minimum viable (MVP): limiter les exigences au minimum qui offre de la valeur à l'utilisateur.

Comment fonctionne Scrum? D'abord, vous formez des équipes de mêlée, qui ne doivent pas comprendre plus de huit pour être efficaces. Ces équipes sont composées d'ingénieurs, d'ingénieurs d'assurance qualité, d'un propriétaire de produit et d'un scrum master.

La tâche principale du propriétaire du produit, qui représente les utilisateurs finaux, consiste à hiérarchiser l'arriéré. Dans le backlog, tous les éléments de liste complète qui pourraient être créés par cette équipe sont conservés. Dans un sprint, ce qui devrait prendre de une à quatre semaines, vous récupérez des articles de l'arriéré. Le but de chaque sprint est de fournir de la valeur à l'utilisateur final et de déployer la solution dans un environnement productif. Lors d'un sprint, certains éléments sont développés et testés. À la fin du sprint, dans la session de révision de sprint, la solution est présentée aux utilisateurs finaux pour leur feedback.

Sur la base des commentaires, le propriétaire du produit peut hiérarchiser les sujets à prendre en compte dans le prochain sprint. Il est conseillé de planifier un projet dans plusieurs sprints puis de le déployer en production. Avec chaque sprint, vous recevrez des retours des utilisateurs finaux, et votre solution finale sera de meilleure qualité avec une plus grande satisfaction de l'utilisateur.

Conduisez toujours une rétrospective de sprint dans l'équipe Scrum pour discuter de ce qui s'est bien passé. et créer des actions pour améliorer Ceci sera bénéfique pour la collaboration d'équipe et la qualité du travail.

Ceci est "agile" expliqué en termes simples: comprendre les problèmes, concevoir une solution recherchant des retours fréquents, produire le design à travers les sprints, et déployer. Même la fonction finance peut le faire!

Mais rappelez-vous, juste parce que vous allez agile et mêlée ne signifie pas que ce sera facile. Au contraire, vous devriez penser qu'il échoue rapidement à réussir plus tôt!

Notre prochain blog explore les facteurs au-delà de la technologie à considérer lors de votre transformation financière.

Pour plus d'informations sur ce sujet, voir La feuille de route de la transformation numérique d'un directeur financier .

<! – Commentaires ->