Comment gérez -vous la documentation technique de vos projets ?

[sjacquet]

La documentation des applicatifs métiers en entreprise est souvent une activité fastidieuse, nécessitant rigueur et ténacité. Souvent considérée comme importante mais finalement non prioritaire, celle-ci devient inéluctablement obsolète au fil du temps et des projets qui s'enchaînent.

Il en est généralement de même sur les projets ServiceNow. Une fois les clés de la plateforme confiées par l'intégrateur au client, les premiers oublis arrivent puis perdurent. Les impacts d'une documentation non í  jour se font ressentir lors d'un changement organisationnel (1), d'une période réversibilité de MCO, ou en présence de dysfonctionnements sur des applications critiques, nécessitant une intervention d'expertise, souvent externe.

La documentation considérée comme anecdotique í  un moment du projet, devient alors indispensable pour mieux comprendre le niveau de personnalisation de l'instance afin d'améliorer / corriger la situation et en reprendre le contrôle.

Trouver une solution permettant d'assurer la continuité de l'exploitation et la reprise en main de la plateforme ServiceNow constituent une contrainte majeure í  laquelle les administrateurs de la plateforme doivent faire face (turn over interne / externe) (2).

Aujourd'hui, nos retours d'expérience sur les projets ServiceNow en phase d'exploitation nous amènent í  la conclusion suivante : la documentation technique est un pré-requis pour quiconque désirant mesurer le degré de personnalisation d'une instance et éviter toute régression de paramétrage. Cette charge récurrente est évaluée í  4-5 jours par mois pour un ETP sur des projets d'envergure moyenne (socle ITSM + 1 métier avec 100 utilisateurs fulfillers).

La Solution

Il est nécessaire de repenser la forme et l'usage de la documentation. Face í  ces constats, pourquoi ne pas envisager de redéfinir le concept de documentation ou la manière de la générer et la maintenir ?

C'est exactement í  cette problématique qu'Atlantic Puffin apporte la réponse. L'application "doKument" permet de penser "information et connaissance" plutôt que document.

Un document n'est qu'un contenant. L'important reste le contenu ! Peu importe qu'il soit diffusé dans un format bureautique, un e-mail, des champs de stories. Ce qui importe finalement, c'est le cycle de vie de la fonctionnalité développée mais aussi de savoir í  quoi elle sert, í  qui elle sert et quand ? La finalité étant d'obtenir rapidement les cas d'usage de cette documentation.

Ainsi, la valeur de l'application réside dans le fait que chaque paramétrage, chaque personnalisation de scripts, chaque rédaction de stories, chaque incident ou demande d'évolution pourront être reliés í  un objet "paramétrage". Ce dernier, associé í  un lot de paramétrage, sera doté d'un numéro de version et contiendra la description technique du paramétrage réalisé (3).

Notes:

1. Le départ de personnes clés de l'équipe Admin devient également l'occasion de faire le point sur l'existant via un audit technique ou une rétro-documentation. Difficile alors de se replonger rapidement dans plusieurs semaines ou mois de paramétrages.
2. Passation, changement d'intégrateur, rachat / fusion d'entreprises etc.
3. Il est alors possible de s'affranchir des étapes de documentation "papier" décrivant une architecture, d'aider í  la prise en main des applications (passation entre équipes, changements d'intégrateur etc.), participer au maintien en condition opérationnelle des applications clés etc.