Une année d’Unifield

Bilan sur un projet en devenir

(in English here below)

Le mois prochain, cela fera un an que je travaille au sein de l’équipe Unifield de l’OCB en tant que MIO finance. J’ai décidé de ne pas renouveler mon contrat, c’est donc le bon moment pour faire un petit bilan.

UN PROJET AMBITIEUX
Le projet Unifield est un projet hors norme sous bien des aspects. D’abord, c’est un projet inter-section, il y en a peu chez MSF et on connaît les difficultés pour les mener à bien. Ensuite, c’est un projet interdépartemental qui doit amener le Supply et la Finance à partager un même outil, des mêmes données. Enfin, c’est un projet qui, coordonné au niveau des sièges, devra être déployé à l’ensemble de tous les projets MSF, impactant la manière de travailler de centaines de personnes.

UN PROCESSUS LONG...
Un tel projet s’étale sur plusieurs années. Après la phase d’initialisation du projet et une évaluation des besoins, les critères techniques de l’outil ont été définis par les référents techniques « finance » et « supply » de chaque section. Suite à cela, le software a été développé. Enfin, avant de pouvoir l’utiliser, il doit être testé, amélioré et avoir une stratégie de déploiement définie. Pour l’instant, le projet, qui a été lancé en 2008, est dans sa 5ême année.

...UNIQUE...
Le projet Unifield ne fait pas partie de l’ADN de MSF. Ce manque d’expérience dans la gestion d’un projet IT aurait dû entraîner des choix de gestion « standardisés »; un organigramme structuré, des lignes de communications claires,... Au contraire, aujourd’hui, l’équipe Unifield de l’OCB est un poulpe bicéphale, qui se mange la queue. Il existe pourtant toute une panoplie d’outils mis à disposition de tous les projets en termes de suivi RH, financier, de chaîne de communication, d’organigramme... Pourtant, à projet unique, on a voulu donner une structure unique... Pourquoi être parti en « freestyle » sans avoir capitalisé sur l’étendue de 30 années d’expérience de gestion de projet ?

... ET COÛTEUX
Tout au long de ce processus, des ressources humaines et matérielles ont été utilisées par les différentes sections. La dépense, à ce jour, toutes sections confondues, s’élève à plus de 6 millions d’EUR...

RÉSULTAT?
Aujourd’hui, après avoir été déjà reporté de près d’une année, le déploiement d’Unifield n’est pas encore acté. La raison ? Des phases de test sur le terrain pointant toutes vers de nombreux problèmes : lenteur globale de l’outil, inexistence des procédures, inadéquation entre les besoins du terrain et les possibilités de l’outil, complexité d’opérations clés, etc.

LA CHARRUE AVANT LES BŒUFS
Mon avis par rapport à ces problèmes est que MSF, dans sa grande tradition de l’action avant la réflexion (justifié dans beaucoup de contextes opérationnels), n’a pas su s’adapter à la gestion d’un tel projet, critique mais non urgent, impliquant des modifications sur des manières de travailler établies laborieusement par les équipes siège et terrain durant de longues années.

En effet, comment peut-on expliquer que, quand je devrais être en train d’introduire Unifield auprès des financiers sur le terrain, je suis à travailler, au siège, à la définition de propositions de procédures à suivre pour encoder un achat Supply, ou que je précise les options existantes pour la gestion des contrats de construction (avec chacune de lourdes lacunes), ou encore que j’essaie d’identifier la manière optimale d’archiver les pièces comptables ?

Pourquoi, alors qu’Unifield est développé dans l’optique d’un plan de comptabilité par nature (qui existe), l’agenda de déploiement actuel prévoit qu’il soit utilisé selon l’ancien plan comptable, empêchant de facto certaines opérations et complexifiant inutilement d’autres ?

N’aurait-on pas dû, avant de développer l’outil, définir la manière dont on souhaitait l’utiliser ? Aller se renseigner sur le terrain, comprendre les besoins tant en termes de gestion financière que de gestion opérationnelle ? Définir, avec le département Supply, la manière dont un achat serait géré, depuis la requête interne (IR) jusqu’au paiement de la facture ? Se réunir avec les départements Admin et LOG pour trouver des manières de fonctionner communes qui permette à terme, de simplifier nombre d’opérations (gestion des contrats de construction, encodage des remboursements médicaux, etc.).

Lors de notre dernière mission pilote au Malawi, le référent financier de l’équipe de développement est venu, pour la première fois, voir Unifield à l’œuvre sur le terrain. Cette visite a été une vraie bouffée d’oxygène pour nous, MIO, qui, depuis la première mission pilote, avions du mal à nous faire entendre sur bien des points, dont les rapports, pointant certains problèmes, nous semblaient, sinon dénigrés, du moins mis de côté car ne collant pas avec la vision obligatoirement positive et enthousiaste sur ce software.

Malheureusement, la machine est lancée, les millions sont dépensés. Alors qu’un tel outil pourrait être la promesse de simplifications majeures pour les acteurs de terrain et d’amélioration de gestion globale, il représentera, dans sa forme actuelle, un autre petit caillou dans la sandale d’acteurs de terrain déjà enlisés dans de trop nombreuses difficultés inhérentes à nos contextes d’intervention.

L’AVENIR D’UNIFIELD ?
Si on revenait à des préoccupations d’efficacité, et non plus de retour rapide sur investissement, je verrais son avenir se structurer de cette façon : D’abord, s’atteler à organiser le projet Unifield selon des méthodes éprouvées par MSF.

Ensuite, prendre le temps de décider, d’un commun accord entre tous les départements supports (Supply, Fin, RH, LOG) (et pourquoi pas toutes les sections également vu que c’est un projet intersection ?), l’ensemble des procédures que l’on suivrait pour chaque cas de figure : de l’archivage d’un achat supply au suivi d’un contrat de construction, de la gestion des avances à l’encodage des remboursements médicaux, de la validation des simulations au suivi budgétaire...

Puis, toujours dans le créneau de « on ne réinventera pas la roue », d’inclure dans le projet une série de travaux passés qui y ajouteraient de la cohérence (nomenclature harmonisée, paliers d’achats...)

Ce serait enfin, basé sur ces 3 étapes préalables, d’apporter des changements au software Unifield afin que ce soit l’outil qui soit adapté à la manière de fonctionner qui aura été définie plutôt que compromettre la cohérence des procédures à cause de limitations techniques.

Ce planning engendrerait encore des délais et demanderait certainement de mettre entre parenthèse le déploiement. Il serait courageux qu’au lieu de reporter de quelques mois en prétextant un changement d’agenda des développeurs de Genève, les équipes des OCs prennent les devants et fixent leurs règles de fonctionnement, en imposant un délai conséquent pour revoir de fond en comble tout ce que les pilotes ont pu mettre en exergue, pour apporter les modifications à l’outil afin d’obtenir un résultat abouti, pour tester extensivement l’outil parmi l’ensemble de ses futurs utilisateurs (alors que pour l’instant seul le terrain y a été confronté).

Pourtant, toujours guidée par je ne sais quels impératifs de rapidité, la réflexion actuelle est déjà concentrée sur le futur déploiement d’Unifield, laissant de côté la réflexion sur de nombreuses incohérences.

EN CONCLUSION
Ce projet est critique pour MSF car :

  • il touche à des points très sensibles (l’argent, les processus d’achat, la responsabilité du budget, etc.) ;
  • il va imposer des changements de fonctionnement dans le quotidien des équipes sur le terrain et au siège, qui ont travaillé durant de nombreuses années sous SAGA et Logistix ;
  • il présente des défis techniques liés à la nature de l’outil.

Ces raisons sont suffisantes pour imposer à MSF un devoir de précaution, de prise de recul, d’analyse critique. Unifield promet une vraie plusvalue. Pourtant, pour que cela se traduise dans les faits, il faudra, avant de le déployer, effectuer un travail de fond en y dédiant le temps et la volonté nécessaires !


A year with Unifield:
assessment of a work in progress

As of next month, I will have been working for a year in the OCB Unifield team as a Finance MIO. I have decided not to renew my contract, so this is the right time to make an assessment.

AN AMBITIOUS PROJECT
The Unifield is an unusual project in many ways. Firstly, it is an intersection project: there are few of these in MSF and we are aware of the difficulties in implementing them successfully. Secondly, it is an interdepartmental project which should result in Supply and Finance using the same tool and data. Finally, it is a project that is coordinated at the headquarter level that must be deployed for all MSF projects, impacting the way hundreds of people work.

A LONG PROCESS ...
A project of this kind spans several years. After the project initialisation phase and the assessment of requirements, the technical criteria for the tool were determined by the Finance and Supply technical advisors from each section. After this, the software was developed. Finally, in order to be able to use it, it had to be tested, improved, and have a deployment strategy developed. Currently, the project that was launched in 2008 is in its fifth year.

... THAT IS UNIQUE...
The Unifield project is not something that MSF is familiar with. The lack of experience in managing an IT project should have led to ‘standardised’ management decisions; a structured organisational plan, clear lines of communication, etc. Instead, the OCB Unifield team is a two-headed octopus, eating its own tail.

Nevertheless, there is a wide range of tools available for all projects for HR and financial monitoring, communication chains, organisation charts, etc. Even so, in a single project we wanted to provide a single structure... Why set off ‘freestyle’, without making use of 30 years of experience in project management?

... AND EXPENSIVE
Throughout this process, human and material resources have been used by the various sections. Expenditure to date, combining all sections, rose to over six million euros...

AND WHAT ARE THE RESULTS?
Today, after having already postponed it by almost a year, we still have not yet deployed Unifield. Why? Field test phases have all pointed towards numerous issues: general slowness of the tool, lack of procedures, tool options not meeting needs in the field, complexity of key operations, etc.

PUTTING THE CART BEFORE THE HORSE
My opinion is that MSF, in its great tradition of acting before thinking (which is justified in many operational situations) has not been able to adapt to the management of a project of this kind which is critical but not urgent. It requires changing working habits that have been laboriously set up by headquarters and field teams over many years. Why, when I should be introducing Unifield to field financial staff, am I working at headquarters to define the procedure proposals to be followed for encoding a Supply purchase, or clarifying existing options for managing construction contracts (each with serious shortcomings), or even trying to identify the best way to archive accounting documents?

Why, when Unifield was developed according to an accounting plan (which still exists), does the current deployment agenda expect it to be used according to the previous accounting plan, which prevents certain operations and needlessly complicates others?

Before developing the tool, should we not have defined how we wanted to use it? Should we not have gone into the field to understand the financial management and operational policy requirements? Should we not have determined, with the Supply department, how a purchase would be managed, right from the internal request (IR) up to the payment of the invoice? Should we not have met with the Admin and LOG departments to identify shared operating methods which, over time, would allow numerous operations to be simplified (management of construction contracts, encoding of medical reimbursements, etc.)?

During our latest test mission in Malawi, the finance referent from the development team came, for the first time, to see Unifield used in the field. This visit was a real breath of fresh air for us MIOs. Since the first pilot mission, we have found it hard to get people to listen to us about numerous issues, including reports, revealing certain problems with the tool. It appeared to us that, if not abandoned, they have at least been put to one side due to them not fitting the obligatory positive and enthusiastic vision for this software.

Unfortunately, the ball has been set rolling and millions have been spent. While a tool like this could make things much simpler for people in the field and lead to improvements in overall management, in its current form it will be just another irritation for field workers who are already bogged down in the countless difficulties already present in intervention contexts.

THE FUTURE OF UNIFIELD?
If we were to return to focusing on efficiency, instead of a rapid return on investment, I see its future being organised as follows:

  • First, get down to organising the Unifield project according to methods that have been proven by MSF.
  • Next, take time to decide, by mutual agreement between the support departments (Supply, Fin, HR, LOG) (and why not all sections, given that this is an intersection project?) on all procedures to be followed for each scenario: from the archiving of a Supply purchase to the monitoring of a construction contract, from the advance management to the encoding of medical reimbursements, from the validation of simulations to budget management, etc.
  • Then, always trying to avoid reinventing the wheel, add prior work which will increase consistency (standardised nomenclature, purchase levels, etc.).
  • Finally, based on these three steps, make changes to the Unifield software so that the tool can be better adapted to the determined operating method, rather than compromising the consistency of procedures due to technical limitations.

This plan would result in further delays and would certainly require setting deployment to one side for a spell. Instead of delaying for a few months under the pretext of the developers in Geneva changing agenda, the courageous thing to do would be for the OC teams to take the initiative and determine their operating rules, forcing a delay to overhaul everything that the tests have identified, to make the changes to the tool in order to obtain the ideal result and to extensively test the tool with the future users (where currently only those in the field have come face-to-face with it).

Instead, it is currently being guided by some inexplicable need for rapid progress, with thoughts already focused on the future deployment of Unifield and the numerous inconsistencies being left to one side.

IN CONCLUSION
This project is critical for MSF, as:

  • It deals with very sensitive areas (money, purchasing processes, budget responsibility, etc.);
  • It will force operational changes in the daily activities of teams in the field and in headquarters who have worked for several years with SAGA and Logistix;
  • There are technical challenges related to the nature of the tool.

These points alone are enough to mean that MSF needs to take care, take a step back and make a critical analysis. Unifield promises real added value. However, for this to become a reality, the groundwork needs to be done before it is deployed and the necessary time and dedication needs to be devoted to it!

By: Antoine Demey