Aujourd’hui je vous propose de revisiter les bases. Quoi de mieux qu’une bonne vieille RFC pour poser les bases du vocabulaire ?

Que cela soit dans le monde (feutré ?) du BPM ou dans l’informatique en générale, l’approximation peut causer des incompréhensions et ces incompréhensions sont à l’origine de conséquences parfois surprenantes : c’est l’effet papillon à l’échelle d’un projet et la théorie du chaos à l’oeuvre dans l’organisation.

Pour essayer de limiter ces problèmes, voici une liste de mot-clés essentiels pour exprimer des exigences qu’elles concernent l’architecture du système d’information où la manière dont doivent être modélisés les processus métier.

J’aurais aimé que ces termes soient enseignés dans les 3ème cycles.

Voici donc la traduction de cette fameuse RFC  2119 :

1. DOIT Ce mot ou les termes « EST REQUIS » ou « DEVRA » signifient que ce qui est défini est absolument nécessaire.

2. NE DOIT PAS Cette phrase ou la phrase « NE DEVRA PAS » signifie que ce qui est défini est une interdiction absolue.

3. DEVRAIT Ce mot ou l’adjectif « RECOMMANDE » signifie qu’il existe potentiellement des raisons valables dans certaines circonstances pour ignorer un élément particulier mais que ce choix ne doit se faire que si les implications sont entièrement évaluées et comprises.

4. NE DEVRAIT PAS Cette phrase ou la phrase « NON RECOMMANDE » signifie qu’il existe potentiellement des situations dans lesquelles le cas ou le comportement en question est acceptable, voire utile, mais que les implications précises et les conséquences qui en découlent doivent être comprises afin de déroger à cette partie.

5. PEUT Ce mot ou l’adjectif « OPTIONNEL » signifie qu’un élément est vraiment optionnel. Un éditeur peut choisir d’inclure un élément car un segment de marché particulier le nécessite ou parce qu’il pense que cela améliore le produit alors qu’un autre éditeur peut omettre ce même élément. Une mise en oeuvre qui n’incluent pas une option en particulier DOIT
être prête à interagir avec une mise en oeuvre qui, elle, inclue la-dite option, même si cela se fait par l’intermédiaire d’un fonctionnement dégradé. Dans le même esprit, une mise en oeuvre qui inclue une option DOIT être prête à interagir avec une mise en oeuvre qui n’inclue pas cette même option.

L’ensemble de ce vocabulaire est défini dans la RFC 2119 (1997).

Image par Feuillu

Popularity: 4% [?]

Voici 2 magnifiques posters pour vous aider dans la mise en place d’une architecture SOA :

un modèle de référence et des design patterns.

Vous pourrez ainsi avoir sous les yeux les questions à vous poser ainsi que les architectures à réutiliser, très pratique !

Télécharger les documents

Popularity: 12% [?]

L’entreprise génère-t-elle de la valeur avec son IT ?

Une enquête réalisée dans neuf pays sur 1 217 professionnels dans le domaine des technologies de l’information affirme que la moitié des personnes interrogées croient réaliser entre 50 et 74 % de la valeur attendue de leurs investissements en IT.

L’ISACA a récemment publié le résultat d’une étude menée autour du thème de la valeur et les résultats sont plutôt positifs.

[...]bien que la plupart des entreprises aient l’impression de produire de la valeur des technologies de l’information, peu d’entre elles comprennent clairement ce que signifie valeur, et encore moins d’entre elles la mesurent vraiment.

« La recherche suggère également que la plupart des décisions ayant trait à la valeur des investissements en IT sont subjectives et que ,bien trop souvent, elles sont basées sur la perception et l’émotion plutôt que sur des faits.

Fait intéressant, la France fait partie des pays interrogés avec 42 % des sondés qui ont déclaré qu’un projet IT a récemment été arrêté ou annulé avant son terme. Dans 33 % des cas, les besoins métiers avaient changé et dans 42 % des cas le projet n’a pas tenu ses promesses. La France s’illustre notamment par le fait que les répondants affirment avoir une structure ou des guides pour prendre des décisions IT.

Au niveau mondial, les bénéfices de l’investissement IT sont visibles sur 2 aspects principaux selon les répondants : pour 35 % d’entre eux, la qualité du service client est améliorée et pour 24 % d’entre eux les coûts sont réduits, notamment par l’amélioration de la productivité. L’aide à la décision et la sécurité sont les 2 autres résultats découlant de l’investissement IT.

Ce sondage soulève tout de même la difficulté que nous avons a évalué le retour sur investissement d’un projet IT.

Voir le résultat de l’enquête

Popularity: 13% [?]

Le choix d’un outil de modélisation apporte-t-il une méthode de modélisation ?

C’est une question qui est souvent posée par mes clients. Cela commence souvent ainsi : « J’ai choisi la suite … et j’ai commencé à modéliser mais au bout d’un mois tous mes modèles sont enchevêtres et je ne m’y retrouve plus, l’outil n’est pas censé apporter la méthode ? ».

Pour bien répondre à la question (de manière plus complète que ce qui peut-être fait au téléphone) voici le fond du problème.

Il nous faut tout d’abord commencer par le commencement : qu’est-ce qu’un outil de modélisation ?

Un outil de modélisation de processus est un logiciel qui permet de représenter et d’organiser les processus métier d’une entreprise. Il comporte une partie graphique pour représenter le diagramme et une partie textuelle pour décrire le graphique et les données associées. Un outil digne de ce nom est épaulé par une base de donnée relationnelle qui assure, entre autre, que chaque élément dans l’ensemble du référentiel soit unique (non, Visio n’est pas une suite de modélisation). L’objectif est d’assurer qu’une tâche générale soit décrite d’une seule manière et qu’elle soit réutilisée à de multiples endroits afin de faciliter les mises à jour : il suffira de modifier une occurrence de l’objet pour que toutes les autres soit mises à jour. D’autres bénéfices sont retirés d’une base de données relationnelle.

L’outil possède généralement de nombreuses fonctionnalités qui vont du « designer » qui sert à modéliser au « générateur d’état » qui sert à restituer le processus pour qu’il soit communiqué (PDF, Doc, HTML…).

Ce qui se cache derrière l’outil de modélisation est bien plus complet qu’une simple base de donnée relationnelle. L’outil contient toujours un ensemble d’objets prédéfinis pour décrire les processus ou le système d’information : un objet représente une tâche, un autre une zone du SI et ainsi de suite. Chaque objet est configuré selon 2 angles : les relations qu’il peut avoir avec les autres objets et ses attributs.

Par exemple, un objet tâche pourra avoir une relation avec un évènement mais non avec un objet tâche et il contiendra au minimum une description et un type précisant si c’est une tâche manuelle ou automatique.

Toute cette configuration est contenu dans le méta-modèle. Il va contenir l’ensemble des objets, leur représentation graphique, leurs liens possibles, leurs attributs ainsi que d’autres éléments conditionnant le fonctionnement de l’outil de modélisation.

Ceci étant dit, l’outil de modélisation contient donc des choix de méthode. Un outil permettra de relier une tâche à une autre alors qu’un second outil ne l’autorisera pas. Selon l’éditeur et le méta-modèle différents choix méthodologiques seront fait. En dépit de ces choix, il reste souvent beaucoup d’autres décisions que l’outil ne contient pas car il est livré indépendamment du contexte du projet du client.

Cela va plus loin que ça. Même avec un méta-modèle parfaitement personnalisé pour un client, l’outil ne dira toujours pas comment doivent être modèlisés les processus. Certains outils sont plus contraignants que d’autres sur le sujet et la finesse des contrôles peut être important mais dans l’ensemble, l’outil n’est pas la méthode.

Imaginez que vous achetez un logiciel pour faire de la musique. Vous pouvez cherchez si le LA doit être à 440 Hz ou pas et si vous souhaitez positionner une note de guitare acoustique ou de piano mais cela ne fait toujours pas de vous un musicien ou un compositeur. L’illusion est facile sur ce sujet et l’on peut rapidement être amené à croire que l’on va s’en sortir tout seul avec un outil et en lisant l’aide fournie (souvent la documentation du méta-modèle n’est pas fournie).

Une partie de la méthode est donc nécessairement comprise dans le méta-modèle de l’outil. Selon sa flexibilité, c’est soit on adapte le méta-modèle au besoin du client, soit… le client s’adapte au méta-modèle de l’outil (cela arrive plus souvent qu’on le souhaiterais!). Mais en dépit de l’aide apportée par le méta-modèle, il n’est reste pas moins que de nombreux éléments contextuels ne sont pas compris ici : manière de nommer les modèles et les objets, la manière d’organiser les modèles (hiérarchique ou non), la manière de décrire les objets…

Pire, l’outil ne sait pas si votre modèle est conforme à d’autres choix méthodologiques comme le nombre maximum d’objets par modèle, le nombre de niveaux ou de couches ou d’autres choix non présent dans l’outil.

Les outils évoluent naturellement vers l’intégration de plus en plus complète de la méthode de modélisation mais prenez garde car le diable se niche dans les détails !

La récupération d’un projet ayant été démarré sans méthode précise est toujours une tâche haletante car on ne souhaite pas perdre le travail fourni par les équipes ni vraiment faire passer le message comme quoi la méthode n’est pas viable tout en devant respecter une certaine rapidité d’exécution. Mieux vaut éviter d’en arriver là.

Popularity: 15% [?]

Il y a 2 grandes fonctions d’encadrement et de support qui me passionnent particulièrement et dont je parle dans ce blog : l’urbanisation du système d’information et l’approche processus.

Il est intéressant de voir que chaque entreprise possède sa propre manière de combiner ces 2 fonctions.

L’urbanisation du système d’information s’attache à définir, mettre à jour et faire respecter les choix de structuration du système d’information. Ainsi, les équipes d’urbanistes interviennent dans les projets liés au système d’information pour contraindre au respect des éléments définis mais aussi pour apporter de l’aide sur l’intégration au reste du système d’information. Bien entendu, la plupart du temps ce rôle sera vécu comme une contrainte par les équipes projets. Pour un urbaniste, tout est système.

L’approche processus consiste à modéliser, analyser et organiser l’entreprise sous forme de processus. Bien moins contraignant qu’il n’y parait, cette approche est le saint graal de bien des services/départements car elle rend l’activité régulière, compréhensible et prévisible. Pour un business analyst, tout est processus.

Ces 2 approches ont pour objectif commun d’apporter de la valeur à l’entreprise (avec valeur signifiant quelque chose pour le métier : time to market, taux de défaillance…) et d’en simplifier le pilotage (moins d’applications, moins d’interlocuteur, moins d’intervention humaine redondante) et c’est pour cela que l’urbanisation du SI et l’approche processus s’accordent particulièrement bien. Cela consiste à définir les processus des « systèmes de l’organisation ».

Alors, comment faire travailler harmonieusement ces 2 cellules ensemble et avec le reste de l’entreprise ?

Organisation

Dans une organisation orientée projet, chaque projet devrait être dirigé par un chef de projet dont le cadre de travail découle de l’entente entre l’urbaniste (SI) et le business analyst (métier). Si le métier évolue, il est analysé par les business analyst qui déterminent le processus métier à mettre en place/modifier (QUOI / POURQUOI).

L’urbaniste intervient dans la concrétisation du projet et son intégration pratique avec l’existant (COMMENT). Pour moi, il joue aussi le rôle d’architecte d’entreprise. Il n’est pas seulement plongé sur les interfaces SI entre applications mais aussi sur l’implication métier de ses choix.

Tout projet faisant intervenir une modification du système d’information doit impliquer l’urbaniste et son acolyte le business analyst pour qu’ils définissent les conditions et le contexte futur de fonctionnement.

Métier

La fonction de l’urbaniste et du business analyst pourrait se résumé à « Traduire les objectifs stratégiques en actions concrètes dans les projets ». Ces rôles devraient donc être permanent dans l’entreprise – ils ne naissent pas avec un projet et meurent à la fin avec lui.

Je recommande vraiment d’avoir 2 personnes qui se comprennent et qui s’entendent bien.

Je ne pense pas qu’avoir une expérience dans le métier même de l’entreprise soit important : prenez un fabricant de meuble, une expérience opérationnelle dans le métier n’est absolument pas une garantie que le business analyst comprendra mieux le métier. Je pense qu’il veut mieux regarder du côté de la capacité/volonté d’apprendre et de comprendre le véritable métier. L’idéal étant d’avoir identifié un référent métier (le futur propriétaire du processus « business process owner ») qui sera en mesure d’expliquer l’histoire du métier dans l’entreprise.

Personnes

Il est évident qu’il faut les « bonnes » personnes dans chacune des fonctions. Il y a des caractéristiques essentielles qu’il faudra retrouver :

• capacité à manipuler des concepts abstraits
• capacité à communiquer (informer, discuter et convaincre)
• capacité à naviguer dans l’organisation et à comprendre le « véritable » métier (être aussi à l’aise avec le DSI qu’avec un conseiller client et pourvoir apporter à chaque fois des réponses adaptées aux inquiétudes des gens)

La plupart du temps, il n’est pas nécessaire d’avoir de grosses équipes pour occuper ces rôles. Parfois, une seule et même personne peut jouer l’urbaniste et le business analyst dans le cadre d’un projet. C’est quelque chose qui ne me choque pas et pour les raisons que j’ai évoqué, c’est assez naturel.

L’urbanisation du SI devrait donc être une activité permanente et son pendant métier, le business analyst, également. Ces 2 rôles ont une capacité qui devient de plus en plus importante dans les entreprises : celle de rendre simple et compréhensible une organisation en un mot « lisible ». Ils rencontreront des difficultés pour s’intégrer aux projets si la nouvelle donne n’est pas imposée. On préfèrera ainsi avoir le business analyst qui travaille « en parallèle » du projet mais ce type de choix ne donnera pratiquement aucun résultat concret (confirmant ainsi par la même occasion que la plupart des projets SI échouent…).

Vers un meilleur résultat des projets de changement des organisations !

Popularity: 20% [?]

Vous connaissez peut-être le principe de Peter. En résumé, c’est un principe qui dit que chaque personne tend à s’élever jusqu’au poste où elle est incompétente. L’une des variations de ce principe s’appelle l’incompétence par l’informatique et dit que :

• quelqu’un d’incompétent ne deviendra pas compétent si on lui colle un ordinateur,
• quelqu’un de compétent peut devenir incompétent avec un ordinateur.

Au delà du clin d’œil et pour revenir au sujet, l’ordinateur ou l’outil de modélisation ne fera qu’amplifier vos choix, fussent-ils bons ou mauvais. C’est pourquoi, le périmètre d’un projet processus ou d’urbanisation du SI est aussi important que la méthode qui sera utilisée pour décrire ces éléments dans le référentiel : il cadre le projet.

L’un des premières et inévitables questions concernera l’existant, le patrimoine (legacy) : faut-il le modéliser ? Faut-il capturer son fonctionnement, son essence ?

Il n’y a pas de réponse universelle car la question est trop générale.

Les mauvaises raisons pour modéliser l’existant

• Créer une documentation (temps passé*taux d’utilisation de la documentation = quelque chose proche de 0)
• Comprendre l’existant (question trop vague, particulièrement côté IT)
• Démontrer la capacité de l’outil (c’est l’éditeur qui sera content)
• Démontrer l’intelligence de l’équipe de modélisation (c’est le consultant qui sera content)

N’essayez pas de faire bouillir l’océan !

Les bonnes raisons pour modéliser l’existant

• Trouver une réponse à une question précise (confirmer/infirmer une hypothèse de la roadmap)
• Préparer un changement sur un périmètre défini
• Trouver un problème dans un domaine précis (diagnostique)

Savoir pourquoi on le fait

Le fait de disposer d’un patrimoine ne signifie absolument pas qu’il doit être modélisé. Il n’y a donc aucun impératif naturel à modéliser l’existant dans le seul but d’immortaliser son existence !

Comme pour n’importe quel projet de modélisation, sans objectif vous êtes condamné à modéliser trop en détail ou trop peu tout ceci pendant trop de temps. Si vous ne savez pas pourquoi vous le faites, vous ne saurez pas quand vous arrêter.

Un tel projet peu être catastrophique : dépense d’énergie et de ressources importantes, perte d’intérêt voir défiance envers le fait même de modéliser.

Il faut donc savoir pourquoi on le fait. Il y a de bonnes chances qu’un tel projet soit lancé pour apporter des réponses nécessaires à quelqu’un dans l’entreprise. Trouvez-le !

Être méthodique

Partir sur de bonnes bases est essentiel. Si un projet démarre sur de mauvaises suppositions, tous les modèles vont être influencés par ces suppositions.

Définissez ce que vous cherchez

Partant de la question de départ, il y a généralement 2 possibilités :

1. la réponse n’est pas identifiée
2. il y a une début de réponse mais elle est si incertaine ou imprécise que l’information n’est pas utile

Se laisser du temps

La modélisation en général est un travail itératif : la bonne réponse n’arrive que très rarement dès la première fois. La modélisation de l’existant l’est tout autant et le fait de s’attaquer à quelque chose d’existant ne facilite par le travail de modélisation pour une raison simple : la réalité est souvent beaucoup plus complexe que ce que l’on aurait décrit dans un modèle cible (donc n’ayant pas encore de réalité). La réalité n’apparaît jamais en une seule fois dès le premier modèle.

La modélisation de l’existant crée une charge supplémentaire qu’il ne faut pas négliger : celle de la mise à jour.  Chaque modèle devra être surveillé par un responsable afin d’être certain que le modèle décrit toujours la réalité. Un modèle dépassé perd beaucoup de sa valeur (voir toute sa valeur).

En clair, si vous voulez définir un To Be (votre cible), il est préférable d’avoir un As Is (existant) pour mesurer la différence et surtout pourvoir l’expliquer aux équipes qui exécutent le processus : « Qu’est-ce qui va changer ? ».

Cela permet aussi d’affiner ses réponses concernant la faisabilité de l’objectif et la probabilité de l’atteindre.

Modéliser l’existant est donc parfois nécessaire. N’ignorez pas la charge implicite que cela amène sur les épaules des responsables de processus.

Popularity: 8% [?]