Déclinaison du service : processus, organisation, technique
Expression du service métier
Un service métier est à rendre. Dans le cas qui illustre cet article, le service métier à rendre était assez simple à formaliser à un niveau macroscopique :
- saisir des informations/contrats concernant un prospect/client
- produire des simulations personnalisées pour un
- prospect/client effectuer des actions techniques de mise à jour et de protection des données avec le système central de l’entreprise
Les contraintes n’étaient pas exceptionnelles :
- nomadisme de l’agent d’assurance travail en heures / jours étendus
- restauration à J-1 en cas de problème grave
Ce besoin est normalement formalisé par le métier (et approfondi du point de vue fonctionnel). Idéalement, cette expression est aussi le contrat de service final (après ajout d’éléments complémentaires sur le niveau de risque acceptable par exemple) et il est l’expression de besoin initiale qui va transiter au sein de l’entreprise en suivant les processus pré-définis.
Dans le cas étudié, cette expression a été rapidement traduite en « lançons un projet d’ERP GRC» (ce qui est significatif d’une approche technologique de la DSI et non d’une approche en fonction du métier de l’entreprise). Nous constations dès le départ un premier biais qui était que le métier de la DSI s’était substitué au métier du client final (l’agent d’assurance).
Le cheminement à travers les processus d’entreprise
Sans préjuger de la décomposition de ces processus, on admettra sans trop de difficultés que le premier traitement après la réception d’une demande de service métier, consistera à qualifier l’importance de ce service pour lui allouer des moyens (ou rejeter la demande).
Ce service métier démandé en entrée doit très fortement inspirer le livrable final. ITIL par exemple, va permettre à une entreprise n’ayant pas une DSI structurée de mettre en place les processus destinés à traiter cette demande via une cartographie « classique » de processus. Cette cartographie va permettre de préciser les étapes qui permettront de transformer la demande en réalité opérationnelle, c’est-à-dire de mobiliser des ressources humaines les plus qualifiées pour la réalisation de chaque étape de transformation et de créer les environnements techniques du système d’information. Dans le cas de notre retour d’expérience, les étapes « effectives » n’étaient en rien formalisées de la sorte. Ce sont les rapports des réunions conduites par le chef de projet qui étaient les marqueurs a posteriori de l’avancée du projet, des rapports qui traitaient finalement de deux choses : l’avancement technique et les difficultés organisationnelles d’avancement. Il faut noter que cette avancée était définie par le chef de projet et non les processus d’entreprise pourtant bien définis sur le papier. Ici, le cheminement était en substance le suivant :
- décision de démarrage du projet « gros processus libre » sous forme d’une conduite de projet
- en toute fin du projet, livraison à la production informatique (élément de l’organisation prenant en charge le « service delivery ») et au support.
La prise en charge par l’organisation
Dans un cas idéal, chaque étape doit correspondre un livrable standardisé en entrée et un livrable standardisé en sortie. Chaque livrable est pris en charge par un élément de l’organisation clairement identifié et identifiable. Le processus permet de définir le besoin de compétences et donc la fonction au sein de l’organisation.
Le livrable matérialisant l’échange est un maillon essentiel du résultat final, mais il permet également de mesurer l’avancement et la qualité du travail. En effet, si l’on adjoint des éléments de métrologie à chaque livrable (résultats de tests, documentation, conformité par rapport à des normes & standards, écart de timing, …) il est possible et facile de remonter des indicateurs de qualité.
Le processus induit-il forcément l’organisation ? La réponse est non en général. En effet, à moins de partir d’une feuille blanche et d’une société sans salarié, il faut optimiser au mieux un existant et comme il existe un lien fort entre processus et compétences humaines, il peut être nécessaire de construire ses processus à partir de l’organisation. C’est par exemple le cas pour des sociétés qui utilisent des profils de haut niveau pour la production des services (Service Delivery ITIL). Dans de telles sociétés, ces ingénieurs sont souvent également en charge d’une part non négligeable des changements et du support, voire dans des cas extrêmes, ce sont aussi parfois les clients du service.
Le cas de la société pris en exemple dans cet article illustre totalement le hiatus potentiel entre processus et organisation. D’un côté il y avait bien eu une réflexion méthodologique et des efforts pour mettre en place les bonnes pratiques ITIL. Mais de l’autre il y avait un fonctionnement en mode projet et une double identité culturelle : administrative du point de vue de l’organisation et fortement technophile. Or ce hiatus était source de heurts permanents dans l’avancée des projets ce qui non seulement rendait « épuisante » la progression du travail, mais aussi comme on va le voir plus bas, fragilisait l’obtention du résultat final, à savoir produire un service en fonction du contrat initial.
La réalisation technique
A chaque étape d’un processus, le livrable produit par l’organisation nécessite l’utilisation d’outils. Dans une démarche d’industrialisation de la DSI, plus ces outils seront standardisés, plus ils seront maîtrisés et plus la qualité est maîtrisable. Il y a donc un lien fort entre processus, organisation et outil si l’on est à la recherche d’une DSI efficace, de qualité à un coût maîtrisé.
Il est bien sûr possible, pour une demande particulière, de s’écarter d’un triptyque standard, mais à chaque fois le traitement sur mesure augmentera les coûts (compétences particulières, expérience plus faible, risque plus élevé). Ici aussi il est légitime de se demander sur le couple processus/organisation impose les choix technologiques. Et ici aussi, la réponse est « non, pas nécessairement ».
Il existe en effet des situations où le choix de l’outil est imposé par les nécessités du métier et dans ce cas, ce sont aux processus et à l’organisation d’en tenir compte.
Première conclusion
Le service à rendre est l’élément de référence de la DSI.
Entre une demande initiale et la production finale, il existe une chaîne de livrables intermédiaires créé par un triptyque processus / organisation / technologie.
La façon de construire cette chaîne est défini par l’élément structurant la société : processus ou organisation ou outil.
La standardisation de ces livrables est gage de qualité et de performance, il diminue le risque.
Philippe RIS,
fondateur d’@uris Solutions
