Aujourd’hui je vais illustrer mon propos avec des exemples concrets. Jusqu’à présent, j’avais plutôt tendance à m’adresser à mes collègues consultants mais je souhaite aussi montrer et expliquer ce que le BPM et l’urbanisation du SI peuvent faire de concret pour les entreprises.

Je pense particulièrement aux PME que je connais bien et où il est facile de faire des changements produisant de très bons résultats. Lorsque l’on a 5, 10 ou 30 personnes à gérer l’effet « tête dans le guidon » est souvent le seul souvenir que l’on garde de notre semaine. Beaucoup d’énergie est consacrée à faire tourner la machine et il est difficile de prendre du recul pour analyser les choses et automatiser certaines parties. On pense ne pas pouvoir changer le fonctionnement tant l’activité est en flux tendu, on pense ne pas avoir les ressources/compétences pour le faire et surtout on a peur de casser la machine.

Pourtant dans le développement d’une entreprise, l’automatisation est essentielle pour pouvoir allouer les ressources ailleurs sans faire augmenter la masse salariale et surtout augmenter le côté prévisible du business. C’est là que les outils d’automatisation interviennent (moteur de workflow). En ayant décrit le processus métier à modéliser et en le rendant exécutable dans un outil approprié, il est ainsi possible de rendre fiable un processus (un ensemble de tâches). La fiabilité est importante pour vos clients, vos fournisseurs et vos collaborateurs.

Les termes BPM, urbanisation du SI et workflow peuvent être intimidants et c’est l’une des raisons pour lesquelles j’écris ce blog : il n’y a rien de compliqué. Cela peut devenir complexe, notamment dans les grandes entreprises où les processus et le paysage SI sont lourds mais généralement les PME peuvent mettre en place quelques processus clés et devenir « super productive ».

Si vous êtes à la tête d’une PME ou d’une business unit, vous avez peut-être déjà remarqué une performance opérationnelle exceptionnelle d’un concurrent ou d’un fournisseur : elle repose sur des outils qui rendent systématique le fonctionnement.

Pour faire un crochet par autre chose, le fonctionnement extrêmement précis et reproductible des chaînes de fast-food repose sur ces mêmes principes : décrire les processus, mettre en place les outils d’exécution et de contrôle. Le cas de la franchise va plus loin que cela et comporte une philosophie à part entière mais l’idée de décrire et d’automatiser est le socle qui permet le développement du business. Mac Donalds sans processus et sans systèmes d’automatisation est en fait la sandwicherie du coin.

Maintenant, il faut choisir son camp entre tendre vers la performance de Mac Donalds ou celle de la sandwicherie du coin.

Voici donc 3 exemples où les résultats de la description/automatisation des processus peut produire des résultats surprenants. Ces exemples prennent des processus : gourmand en temps et donc en ressources.

Relation client

Pourquoi n’est-il plus possible de parler directement à un humain lorsque vous joignez le service client d’une entreprise ? Parce que le nombre de requête client inutile est trop important et donc les entreprises ont mis en place des systèmes de filtrage. Il n’est pas question de juger l’intérêt de faire ceci : si vous souhaitez grandir et avoir un système capable de suivre votre développement vous devez filtrer les requêtes clients. Filtrer ne signifie pas écarter ou rendre difficile le parcours du client ! Cela signifie qu’il faut décider de la manière dont le client sera reçu et automatiser au maximum ce processus avec un outil adéquat. Vous pouvez économiser un temps très précieux !

Regardez ce que fait google dans la prise en charge des demandes clients son centre d’aide est un modèle d’efficacité : http://www.google.fr/support/?hl=fr

Que se passerait-il si au lieu d’avoir 3 personnes qui répondent aux emails et aux appels de vos clients, vous avez un système d’aide précis et un processus de résolution des problèmes précis ? Est-ce que le support client est un frein (souvent inconscient) à votre développement ?

Relation fournisseur

La relation avec vos fournisseurs est également une source potentielle d’inefficacité. Bien entendu, tout dépend du domaine dans lequel vous évoluez et de l’importance et de la fréquence de vos relations entre votre entreprise/unités et vos fournisseurs. Un cabinet de conseil en informatique n’a que très peu de relations fournisseurs alors qu’un supermarché en possède un très grand nombre : c’est même l’un de ses cœurs de métier (voir la source de l’hégémonie de Wallmart).

Dans quelle mesure est-il possible d’automatiser la commande/livraison ?

Encore une fois, il s’agit de décrire, décider et d’appliquer un fonctionnement type avec vos fournisseurs. Grâce à internet et aux solutions hébergées, il n’a jamais été aussi simple et aussi facile et économique de mettre en place ce type de solutions.

Tâches répétitives internes

L’autre point important concerne les tâches internes. Bien souvent de nature administrative, ces tâches doivent être analysées, remises en question et éventuellement automatisées. Typiquement toutes les demandes RH, de support informatique ou les demandes non métier peuvent faire l’objet d’une analyse et d’une automatisation.

Ainsi, vous pouvez réduire leur consommation de ressource de 25 à 75 %.

Gardez cependant ces principes en tête

• Automatiser quelque chose d’inefficace ne le rendra pas efficace : le processus doit être analysé et remis en question
• Mal automatiser est parfois pire que de ne pas automatiser (principe de peter)
• Ne pas automatiser du tout, c’est avoir un handicap par rapport à sa concurrence (scalability)

Je serais heureux de vous aider sur ces points (je suis actuellement occupé pour quelques mois), n’hésitez pas à me contacter pour que l’on voit ce qui est possible.

Popularity: 22% [?]

L’une des plus grandes frustrations d’un business analyst ou de toute personne qui modélise, c’est le fait que tout ce qui est manipulé au quotidien soit abstrait : les concepts, les modèles, les objets, le méta-modèle… Le modélisateur se trouve sans cesse à jouer avec des idées qui n’ont parfois aucune réalité.

Bien entendu, cette capacité d’abstraction est l’une des raisons même pour laquelle le modélisateur occupe ce poste : c’est une compétence spécifique et donc tout le monde ne peut s’improviser modélisateur. Ajoutons à cela une nécessaire connaissance des méthodes et outils associés à la modélisation et vous comprendrez qu’il est difficile de confier ce rôle au premier venu.

Malgré cela, le côté abstrait des choses peut être frustrant. Lorsqu’on travaille sur quelque chose de concret, il est plus facile de savoir quand s’arrêter. Il est plus facile de mesurer la progression. L’équipe qui fabrique l’Airbus peut voir se concrétiser le fruit de leur travail. Ils peuvent voir les pièces se réaliser pour finalement être assemblées pour obtenir le produit fini. Même si la production de l’avion ne marque pas la fin du processus ou du travail des équipes, c’est un jalon notable que n’ont pas la plupart des modélisateurs, tant du côté des processus métier que du côté des urbanistes du SI. Le produit fini est très souvent un nouveau système et restera donc encore une fois… abstrait.

Parmi les tâches que j’ai réalisé récemment, le portage de processus métier dans le but de le rendre exécutable est un exercice que j’apprécie. Certes, rendre exécutable un processus ne le rend pas réel mais admettez que son niveau d’utilité progresse énormément entre son état de processus modélisé dans un référentiel et celui de processus exécutable : il devient utilisable.

Le processus exécutable prend vie puisqu’il entre en interaction avec d’autres personnes que le modélisateur ou son sponsor. Comment arrive-t-on ici ? Comment passe-t-on d’un processus métier à un processus exécutable ?

Tout comme dans les théories économiques, il existe plusieurs courants de pensée autour de l’exécution des processus. Certains outils vont être axés sur l’interaction homme-homme, d’autres sur l’intégration entre homme et machine ou bien encore sur la simple automatisation de tâches.

Ainsi, on peut distinguer les outils qui servent à gérer la collaboration entre personnes de ceux qui servent à gérer l’exécution pure et simple d’un processus. Dans le second cas, l’outil permet un traçage et une interaction plus avancée avec l’utilisateur. Vous l’aurez deviné, dans l’idéal un outil doit faire les 2.

Lorsqu’on réalise le portage d’un processus métier, plusieurs choses vont être frappantes :

• le processus apparait comme théorique et donc non exécutable directement (dépend beaucoup de la méthode de modélisation)
• toutes les informations pour l’exécuter ne sont pas disponibles (délais, personnes…) et seront difficiles à obtenir
• le processus théorique est plus compliqué que le processus réel

J’appelle « processus théorique » le processus qui se trouve dans le référentiel d’entreprise. C’est le modèle théorique qui est né de l’esprit et d’une interprétation de la réalité. Cette opération le rend à la fois plus complexe que la réalité mais tout en le gardant non exécutable. Autrement dit, il est décrit pour être théorique et non pour être exécutable. Si vous n’êtes pas familier de la pratique cela peut vous paraître contre-productif mais ça ne l’est pas : chaque modélisation à son objectif. Celui du processus théorique, c’est l’analyse et il n’y a donc rien de choquant à ce qu’il ne soit pas exécutable.

Beaucoup de personnes pensent cependant que le processus théorique est le processus exécutable, au prix de quelques adaptations mineures. Encore une fois tout dépend de la méthode  de modélisation utilisée au départ. Certains partiront avec une notation BPMN et un méta-modèle orienté exécution : cela facilitera le portage mais rendra difficile une analyse en profondeur.

Ce sont 2 mondes séparés : la théorie et la pratique. C’est le gap que des langages comme BPEL essaient de combler.

Pour rendre exécutable un processus nous allons nous intéresser principalement aux actions et donc aux acteurs. Chaque tâche sera ainsi prise en charge par un acteur au travers d’un écran utilisateur. Cet écran est un formulaire web qui affiche les informations dont a besoin l’utilisateur pour exécuter la tâche ainsi que les informations attendues de sa part.

Une règle simple peut-être énoncée : s’il n’y a pas d’interaction humaine, il n’y a pas d’écran de dialogue (évident mais bon à rappeler!). Autrement dit, si le processus théorique contient 20 tâches, le processus exécutable en aura surement moins (15 ou 10).

Ce qui est intéressant dans l’exécution, c’est la mise en oeuvre du système et son effet sur l’entreprise. Par exemple, pour chaque assignation de tâche entre 2 acteurs (Je valide ma demande de congés, mon supérieur doit la vérifier) il faudra définir une personne remplaçante, un délai d’exécution, un chemin par défaut en cas de problèmes… Aucun chemin d’exécution ne pourra être laissé ouvert.

Il s’agit véritablement d’une opération de transformation du processus et il y a vraiment autant de manière de rendre exécutable un processus que de manière de le modéliser. Récemment j’effectuais le portage d’un processus ITIL (Change Management) et de très nombreuses questions doivent être posées pour que le client obtienne le résultat qui lui convient.

L’exécution est l’aboutissement du travail de modélisation et c’est une étape très intéressante. Les outils en mode SaaS (hébergé sur le web) permettent de faciliter grandement l’intégration des processus dans les entreprises (CMlight, Xpert.Ivy, RunMyProcess…), notamment de taille modeste puisque celle-ci n’a plus à mettre en place les solutions techniques pour supporter le tout : elle se concentre sur le résultat attendu et surtout sur l’organisation du métier. Après tout, c’est comme ça que ça devrait être non ?

Popularity: 9% [?]

Comme beaucoup de professionnels de mon secteur, je suis convaincu de l’intérêt de l’urbanisation du système d’information.

L’urbanisation, par le niveau de compréhension qui en ressort, est une formidable source d’information permettant de prendre des décisions éclairées et de voir le véritable lien entre le métier de l’entreprise et son système d’information.

La direction de l’entreprise s’en trouve simplifiée et les décisions métiers et IT gagnent en synergie.

La complexité des systèmes d’information est à un niveau jamais atteint, cela rend plus simple la prise de décision.

Cependant dans les projets, sur le terrain et loin des conférences et autres symposiums, les résultats obtenus sont souvent décevants.

Je vais m’attacher au lien entre le projet d’urbanisation et le projet IT de refonte ou de développement dans le système d’information de l’entreprise.

Les difficultés rencontrées :

Tout d’abord chaque projet IT doit affronter les chefs de silo (CDS). Les chefs de silo interviennent pour garantir que leur secteur (ou leur territoire) ne sera pas réduit par le projet. Que l’organisation soit notablement sous forme de silo ou non ne change pas grand chose car dans le fond, les chefs de silo trouvent toujours un moyen de recréer une organisation par silo.

Il faudra donc composer avec eux et surtout arriver à faire collaborer ces chefs entre eux. C’est d’ailleurs en bonne partie pour cela que la recommandation dans tout projet d’urbanisation est que le haut management soit acteur : pour « forcer » les chefs de silo à travailler entre eux.

Ensuite, le projet devra affronter la résistance de nombreux intervenants dont la liste n’est pas très réjouissante.

Le projet d’urbanisation peinera à atteindre des résultats satisfaisants à cause des entraves précédemment listées : les intervenants terrain ne croient pas au projet et n’en attendent rien. La conséquence logique est que l’investissement consenti pour le projet ne donnera pas de bons résultats.

Inévitablement, le projet IT qui en découle sera comme la majorité des projets IT non encadrés : il comportera trop de fonctionnalités qui ne seront basées sur aucun besoin métier et coûtera donc trop cher.

Bien sûr, le projet sera trop gros avec un planning intenable. Cerise sur le gâteau, les indicateurs permettant de mesurer la qualité du projet et sa contribution aux résultats de l’entreprise ne seront pas définis et donc non mesurés ce qui poussera l’équipe projet à livrer à tout prix sans s’attacher aux détails de la livraison (le lien vers la nouvelle application dans l’intranet suffi pour apporter satisfaction non ?).

Comment faire ?

Si l’urbanisation n’est pas la méthode miracle pour faire des projets IT une absolue réussite, sa rigueur permettra surtout de s’attacher aux résultats qu’attends l’entreprise : un changement positif qui apporte une amélioration métier.

La réalité des projets d’urbanisation n’est en fait pas très différente de celle des projets IT. Si le projet d’urbanisation doit apporter un éclairage pratique et fixer les limites des projets IT, il souffre des mêmes contraintes pour une seule raison : il évolue dans le même milieu.

Le milieu est grandement influencé par la manière dont les équipes collaborent et je pense que le type de collaboration entre projets et urbanistes est déterminant.

Il existe différentes manières d’intégrer l’urbanisation aux projets IT.

Les urbanistes sont souvent une entité isolée qui intervient sur les projets à la demande. La plupart du temps ils sont dans leur tour d’ivoire bureau et travaillent en parallèle des projets IT en essayant de produire le plus gros modèle du monde. Selon le niveau d’autorité qui leur ai accordé, ils peuvent opposer un véto au projet si jamais celui-ci ne respectait pas les pré-requis nécessaires pour garder un SI urbanisé.

On les trouve parfois dans l’équipe des business analyst qui décrit les processus métier à mettre en place. Ils bénéficient d’une place de choix puisqu’ils peuvent faire remonter les parties du SI susceptibles de couvrir les besoins métiers étudiés et ainsi concrétiser un mot sacré la réutilisation. Souvent, il s’agit d’une personne détachée de l’équipe d’urbanistes.

Parfois, ils ne sont pas tout à fait identifié et leur intervention sur les projets est mal vue. Ils restent en marge et se contentent de documenter ce qui se passe et d’emettre des « notes de recommandation »…

Je suis intimement convaincu que la position de l’urbaniste doit être dans les projets. C’est là où l’urbaniste prend sa casquette d’archiecte applicatif (si ce rôle n’existe pas) pour aider les projets à s’intégrer au SI. C’est là où le travail de cartographie apporte de la valeur et délivre son potentiel. Il n’en reste pas moins que la nature des projets IT est très diverse et cela rend toujours un peu difficile de coller à une organisation type. Cependant, posez-vous la question : est-ce que mes urbanistes contribuent aux projets IT ? Est-ce que le référentiel des applications (CMDB ou pas) est mis à contribution ? Est-ce que tous les outils à notre disposition sont utilisés pour encadrer le projet ?

Popularity: 20% [?]