Salon SQOP Brest : temoignage (3/3)

Voici le dernier article consacré au témoignage d’Auris Solutions au salon SQOP de Brest. Vous pourrez trouver la version complète de ce témoignage en version pdf en cliquant [ ici ].

Les unités d’œuvre : formalisation du lien processus / organisation / technologie
Si nous reprenons l’exemple du service de GRC illustrant cet article, il est possible de montrer comment on aurait pu formaliser et chiffrer a priori la création du service métier demandé (ceci n’a pas pu être totalement fait à l’époque).
La première étape consiste à décliner les services métiers en services techniques standard. Par exemple « saisir des informations/contrats concernant un prospect/client » peut se décliner techniquement par (en simplifiant):

• assurer un service technique d’infrastructure machine back-office base de données et un service technique applicatif de base de données (i.e. une machine et un logiciel de gestion de base de données)
• assurer un service technique d’infrastructure machine middle-office serveur d’application et un service technique applicatif de  serveur d’application
• assurer un service technique d’infrastructure machine front-office serveur http et un service technique applicatif http
• assurer un service technique d’infrastructure machine utilisateur (poste de l’agent) et un service technique applicatif métier

NB : la déclinaison en services techniques était à l’époque un peu différente.
Cette étape est important car elle fait le lien entre l’objectif métier, la technique (comment on va le faire) et l’organisation (qui est compétent pour le faire).
Dans notre exemple, le service n’impliquait en gros que trois processus :

• un processus de gestion du changement qui qualifiera et produira les développements spécifiques,
• un processus de production des services,
• un processus de support aux services

Le but des unités d’œuvre est, à partir des livrables intermédiaires standardisés, de fournir des informations de contrôle de gestion du projet sous la forme :
une UE = { un service technique, un délai de réalisation, une charge en jour-homme, un coût, des indicateurs de reporting }

Par exemple, pour le service examiné ici, en imaginant que le service nécessitera la mise en place de deux environnements de production, d’un environnement de pré-production, d’un environnement de recette, d’un service technique « service d’application », d’un service technique base de données (par environnement recette, pré-production, production)

Le cinquième service technique (celui du poste utilisateur) est outsourcé.

Au total

Donc si la DSI est correctement industrialisée, les délais, charges et coûts sont chiffrables dès que l’étape de qualification est validée. Par ailleurs, à chaque étape un tableau de bord peut être produit pour vérifier la conformité de l’avancement. La difficulté étant d’arriver à un niveau d’industrialisation pertinent, ce qui est le plus difficile pour l’étape « études & développements » à moins de passer par des contrats extérieurs en mode SaaS par exemple.
Hélas, dans notre expérience, l’industrialisation était loin d’en être arrivée à ce stade et la progression du projet fut beaucoup plus laborieuse et moins cadrée.

Conclusion
Retour d’expérience : le service obtenu
Le service métier avait été clairement énoncé et décliné en services techniques. La DSI, ayant appliqué les bonnes pratiques ITIL, avait créé son catalogue des services. Il aurait dû donc être aisé d’arriver à un SLA en bonne et due forme. Hélas, ce ne fut pas le cas. Pourquoi ?
Le SLA doit par nature être la réponse à un besoin exprimé par le client et le catalogue des services doit répondre à ce besoin, donc s’adapter. Or ceci demande une vraie culture du client alors que notre entreprise avait une double identité culturelle administrative pour l’organisation et très technophile. Au final, et malgré les réels efforts en matière de bonnes pratiques, une bonne partie du contrat de service s’est conclue par un « best effort », ce qui est l’engagement a minima. Si les objectifs réels de l’organisation ne sont pas la satisfaction d’un contrat de service, celui-ci a peu de chance d’être rendu de manière optimale, même s’il y a eu une réflexion sur les processus, même si les technologies sont adaptées.
Dans le cas de notre assureur, le résultat n’était guère satisfaisant mais cela ne l’empêchait pas de faire son métier. Cependant, cela ne permet pas d’attendre une qualité de service et des performances optimales. Pour que cette mission aboutisse complètement, il aurait fallu être mandaté pour conduire préalablement un management du changement visant à faire évoluer la culture des équipes vers une culture du service à rendre, ce qui leur aurait permis de s’affranchir des définitions trop administrative des tâches assignées, mais ce qui n’était pas notre mission. Une vision de la DSI en terme de service à rendre, de projet à conduire implique que les acteurs soient plus libres et responsables de leur travail et que les critères de réussite soient fixés par la satisfaction des clients en regard du service rendu.
Synthèse générale
Processus, organisation et technologie sont les trois éléments essentiels permettant de créer la chaîne de livrables aboutissant à la production d’un service métier. Pour un fonctionnement harmonieux, il est nécessaire de comprendre lequel des trois éléments est structurant et adapter les autres.
Dans une DSI correctement industrialisée, cette chaîne peut être contrôlée par des unités d’œuvre qui permettent de quantifier le délai, la charge et le coût du changement, de la production ou du support du service produit, et de les associer à des indicateurs de qualité et de niveau de risque.
Si les directions sont en possession de ces indicateurs, elle pourront a postériori mesurer la performance et la qualité du travail réalisé en fonction du service effectivement délivré.

Philippe RIS,
fondateur d’@uris Solutions