« Centre de service (Développement) Offshore » Une solution qui marche !

Cet article pour parler d’un sujet plus que jamais d’actualité dans une période de crise économique. L’emploi de ressources « Offshore » pour diminuer le coût de développement et maintenance des systèmes d’information.

Les métiers des systèmes d’information couvrent des domaines de compétences très variés et je ne parlerais pas dans cet article du coté hardware (Réseaux, Administration des machines…) qui sont depuis longtemps des activités opérables en mode Offshore.

Dans les possibilités de déploiement d’un partenariat offshore sur le logiciel, je vois surtout deux solutions possibles :

- L’externalisation complète d’un projet ou de la maintenance d’applications (Tout le cycle de vie)

- L’externalisation des travaux de maintenance et de développement en mode « Centre de Service ».

Sur la première solution les deux points clefs pour la réussite sont à mon avis d’une part la qualité de la période de transfert des applications/projets et de l’autre la mise en place d’un « Front Office » efficace.

Pour la deuxième solution, et c’est l’objet de mon article les gains pourront être très intéressant seulement si l’on adresse bien les aspects critiques de ce modèle.

Présentation succincte du modèle

Dans le graphique ci-dessous nous visualisons les activités du cycle de production qui de mon expérience seront les mieux adaptés pour le mode « Centre de Service » Offshore.


(cliquer pour voir en grand)


Le principe de fonctionnement est d’établir deux flux (Projet, Maintenance) de demandes de services à destination du partenaire Offshore.

Pour les projets : Il Faut s’organiser et réaliser une architecture permettant de segmenter la réalisation en tâches élémentaires (Ce que j’appelle UP : « Unité de processus » dans ma méthode d’estimation des charges).

Ensuite le développement de chaque UP, fait l’objet d’un dossier de spécification fonctionnelle transmis au partenaire, celui-ci après accord sur la charge et le délai réalise l’analyse technique, le développement et l’intégration technique. Le demandeur récupère enfin les composants documentés, réalise l’intégration fonctionnelle pendant laquelle il fera corriger par le « centre de service » les non conformités.

Pour la maintenance : Il s’agit de gérer un portefeuille de demandes d’évolution ou de corrections (non urgentes) par priorité. Les demandes de service sont transmises dans un flux régulier, le « Centre de service » acquiert au fil des demandes une autonomie fonctionnelle, il livre les composants modifiés/documentés .

Le demandeur intègre les composants en faisant corriger les non conformités, enfin il réalise la constitution des versions et la mise en production.

Maintenant que le principe du modèle est posé, regardons les 10 aspects critiques sur lequel il faut à mon avis porter toute son attention :

1) Adopter une approche TCO (Total cost of Ownership)

Il s’agit d’établir comme principe du déploiement du “Centre de service Offshore”, que l’objectif sera atteint si et seulement si le TCO global du périmètre concerné baisse.

Pour ceux qui ne connaisse pas trop cette notion quelques liens :

http://www.commentcamarche.net/contents/systeme-d-information/tco.php3

http://fr.wikipedia.org/wiki/Co%C3%BBt_total_de_possession

Sans non plus partir dans un calcul « Usine à Gaz » évitons au moins de laisser croire que déployer un partenariat offshore ce résume à baisser son coût de prestation externes de 50 à 70 % donc faire un gain de d’autant.

Quelques propositions d’éléments à prendre en compte dans le calcul

Les Pertes

• Coût de la phase de transition (compétences techniques et fonctionnelles)
• Coût additionnel dans le processus de vérification des composants.
• Perte de qualité durant la transition
• Coût de formations additionnelles : Langues notamment.
• Coût additionnels d’infrastructure (Environnements, outils,..)

Les Gains

• Coût moyen journalier des ressources
• Mode forfait avec objectif de gains de productivité.
• Gains apportés par la souplesse de monté et baisse de charge.
• Amélioration moyen long terme de la qualité des applications.

2) Courbe d’apprentissage, investissement Moyen/ Long Terme.

Vue les pertes liées à la phase de transition et les efforts qui seront nécessaires pour être à l’équilibre puis bénéficiaire il faut bien sûr considérer cette mise en place comme un projet « Moyen/Long Terme ».

On peut imaginer un rythme de croisière au bout d’une année.

3) La langue

Il ne faut pas sous estimer l’impact occasionné suivant les contextes par le fait de devoir travailler dans une langue différente de celle de l’utilisateur avec son partenaire Offshore.

Sur ce point, il faut à mon avis raisonner aussi Moyen/Long Terme, et il est préférable, d’investir dans de la formation en langue plutôt que dans des processus répétitifs de traduction.

4) Pilotage opérationnel de la relation et prévisions moyen terme.

Un pilotage formel et régulier sera déterminant dans la réussite du projet, on peut sur ce sujet citer deux instances incontournables :

Un comité Hebdo Opérationnel : Composé des chefs de projets, architectes, développeurs des deux parties. L’objectif étant de manière très concrète de balayer les travaux en cours et à venir et d’adresser les points de blocage.

Un comité Mensuel de pilotage : Composé des managers des deux parties. L’objectif à partir d’indicateurs concrets (Charge, Délai, Qualité) d’engager les actions nécessaires à l’amélioration du processus.

Il s’agit aussi, et c’est très important de donner au partenaire une vision glissante sur trois mois sur la charge à venir, cela lui permettra d’optimiser ses ressources et de garantir les meilleurs coûts journalier.

5) Le « Centre de service » est composé d’individus « intelligents ! »

Je présente cela sous forme de boutade , mais c’est bien un piège assez commun de ce lancer dans un processus ou parce que l’on considère (à juste titre au début) que l’on connais bien mieux l’aspect fonctionnel et technique des applications qu’il faut réaliser des documents de spécification hyper détaillée (voir avec du pseudo code).

Il faut toujours en revenir à une vision moyen terme et accepter la courbe d’apprentissage inévitable. D’ailleurs l’avantage du modèle que je propose et que grâce aux demandes de maintenance où le « Centre de service » réalisera petit à petit les analyses il gagnera en autonomie.

6)Estimation des charges

Le mode « Centre de service » implique un accord Charge/Délai pour chaque travail confié. Les travaux auront en moyenne une taille allant de 1 à 2 jours jusqu’à 20 jours.

On ne peut donc pas passer son temps à discuter des charges, de plus pour être capable de produire un indicateur qualité correct de la forme « Nbre de Défaut/Taille des travaux ».

Il faut mette en place une méthode d’estimation formelle par la taille, même si cela doit se terminer par un tableau Excel à deux ou trois entrées (Technologie, Nbre de écrans/données/visu, Complexité).

7) Le suivi des défauts

Les non conformités (Défauts applicatifs) sont le risque principal de surcoût pendant la courbe d’apprentissage, un suivi formel permettant de prendre du recul et de cibler des actions (Formation, Outillage, conseils de rédactions des spécifications,…) est obligatoire.

8) Formalisation du processus

D’une manière générale le préalable à toute montée en charge est évidement la définition d’un processus clair (Qui fait quoi et quand) ayant reçu l’engagement total des deux parties.

Ce processus devra faire l’objet d’un minimum de contrôle qualité (audit) et sera aussi revue de manière périodique pour prendre en compte les actions d’amélioration proposées.

9) L’environnement (Dev ,recette, production) de travail

Il ne faut surtout pas se mettre dans une situation où le partenaire Offshore (pour des raisons de sécurité) travaille sur un environnement avec des différences importantes.

De la même manière que si les développements étaient réalisés en interne il faut donner aux développeurs le moyen de tester ses composants avec des données au plus proche de la production.

10) La communication et les outils collaboratifs.>

Finissons enfin par un incontournable, la mise en place de processus formels (Estimation, Planification, Suivi des défauts) , la réalisation de comité (Opérationnel et pilotage) sera impossible sans des outils de gestion de projets efficaces.

Il faudra notamment veiller à pouvoir :

- Gérer dynamiquement un portefeuille des travaux en cours et à venir sur la base de Workflow entre les deux parties.
- Gérer le suivi temps réel des non conformités.
- Partager une version toujours à jours des points en suspens, décisions, actions des projets en cours .
- Produire de manière le plus automatisé possible les indicateurs clefs pour la gestion de la relation moyen/long terme.

Pour ceux qui veulent en savoir plus sur ce type d’outils, je vous propose de jeter un coup d’œil à la solution PM Views proposé par ma société qui adresse la plus part de ces points.

Ci-dessous un autre lien intéressant avec des conseils sur le même sujet orienté sur la gestion agile (beaucoup de choses se recoupent par rapport à ma vision)

http://blog.xebia.fr/2007/10/31/off-shoring-agile-cest-difficile-mais-ca-marche/