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: 23% [?]

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: 42% [?]

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: 10% [?]

En relisant mon article premier du nom sur cette question je me suis rendu compte d’une chose terrible : je n’avais pas parlé du client !

Voici un complément de description.

Qui est le client du BPM ? En règle générale, c’est l’entreprise elle-même.

Si les processus interne sont améliorés et que les collaborateurs sont plus disponibles pour les clients, ceux-ci seront plus heureux et l’entreprise améliorera ses chiffres. Voilà le principe sous-jacent (simplifié).

La philosophie du Business Process Management consiste donc à améliorer le fonctionnement de l’entreprise.

Une fois ceci dit, tout reste à faire.

Le BPM a un gros problème : sa valeur chiffrée est parfois impossible à définir et un projet mal cadré/géré peut rapidement rappeler les jours sombres de l’informatique où l’entreprise investie pour obtenir un ROI négatif (les projets ERP sont réputés pour ça!).

Les projets dont le résultat est directement visible sont généralement ceux où un problème opérationnel existe. Ce n’est peut être pas très « sexy » mais en remettant de l’ordre dans un processus malade, vous produisez un résultat direct pour l’entreprise – à supposé que le processus apporte quelque chose à l’entreprise. Le procesus sera donc efficace encore faut-il qu’il soit efficient.

Le deuxième domaine où le BPM produit des effets indiscutables est lorsque de l’automatisation est effectuée. Moins d’interventions humaines = moins d’erreurs et des coûts plus faibles. Une démarche BPM aide à savoir quoi automatiser et à bien l’intégrer aux autres processus, ceux avant et ceux après.

Le dernier domaine qui permet de profiter du BPM, ce sont les projets de refonte du SI. Dans ces projets, le risque de dérapage est important et la conséquence (financière) peut-être très importante. Le BPM permet de cadrer les projets SI en amenant le besoin du client de manière limpide. C’est donc autant un travail d’AMOA que de gestion du changement.

Faut-il faire du BPM si vous n’êtes pas dans l’une de ces 3 situations ? Ma réponse est que si vous n’êtes pas dans l’une de ces 3 situations vous avez de la chance ! Je parie que ça n’est pas le cas.

Si malgré tout vous décrivez vos processus sans but opérationnel, vous obtiendrez de belles procédures de travail qui n’apporteront pas grand chose à votre entreprise et remettre au goût du jour cette blague de consultant : « En moyenne combien de temps dure un projet BPM ? 2,5 DSI. »

Je pourrais donc définir le BPM par ceci :

Décrire le fonctionnement de l’entreprise en détaillant les tâches, rôles, données et règles de gestion nécessaires à son fonctionnement dans le contexte d’une amélioration opérationnelle.

Popularity: 4% [?]

C’est la saison des Oscars et dans l’informatique c’est Adonis, l’outil de modélisation de BOC, qui a reçu une distinction pour avoir mis brillamment en œuvre différentes normes du BPM sur le projet de l’union européenne  baptisé GENESIS.

Ce projet doit permettre de faciliter les échanges électroniques dans l’union européenne en proposant une plateforme d’interopérabilité.

Communiqué de presse Adonis

On retrouve donc réuni sur un beau projet :

• BPMN : norme de notation d’un processus
• BPEL : norme d’exécution d’un processus
• Core Component Technical Specification (CCTS) : norme sur la modélisation de données (Télécharger le document)
• UBL : norme sur l’échange de documents électronique

L’outil est très souple et grâce à cette capacité, la combinaison des différentes normes fait que les données modélisées selon CCTS et ISO 15000-05 se retouve associées à  la notation BPMN, que tout ceci est transformé en BPEL pour ochestrer l’exécution des processus.

Voir le site du projet

Voir une démo de l’outil sur ce projet

Popularity: 5% [?]

Lorsqu’il s’agit de modéliser des processus, la plupart des clients vont chercher un outil avec cette question en tête : « quel est le meilleur outil pour faire ce que je dois faire ? ».

Cette question dérive bien souvent vers : « quel est le meilleur outil ? » qui veut bien entendu dire « quel est le plus cher ? ».

Outil ?

Cette tendance très humaine ne doit jamais faire oublier que modéliser n’est pas une question d’outil. Autant la question était primordiale il y a 3 ou 5 ans lorsque le marché était « sous-outillé » et qu’une décision sur ce point pouvait conditionner le succès ou non d’un projet mais désormais de nombreux outils sont très qualifiés.

J’ai pu tester et travailler avec de nombreux outils BPM ou outils de modélisation de processus métier.

Ce que je sais, c’est que les différences sont minimes entre les plus gros outils à tel point que les critéres d’évalutions doivent être très affinés.

L’outil n’est donc plus déterminant (sauf projet technologique particulier, une minorité). Ce constat est aussi valable pour la modélisation de systèmes d’information et l’urbanisation du SI.

L’outil sera quand même la garantie de la pérennité d’un référentiel d’entreprise. On ne compte plus les projets de modélisation basés sur Excel qui n’ont presque jamais servi…

Un outil est donc nécessaire mais pas déterminant.

Conceptualisation

L’une des qualités importantes que doit posséder un modélisateur, c’est donc de conceptualiser. C’est à dire, intégrer de nombreuses informations et arriver à organiser, reconnaître des patterns , et prioriser des idées.

Cette capacité, directement liée à l’hémisphère droit du cerveau, n’est pas à mon sens quelque chose qui se travaille. C’est quelque chose que l’on possède ou non.

C’est ce qui va faire la différence entre quelqu’un qui nécessite 20 minutes d’exposés et de prise de notes et quelqu’un qui reconnait les éléments clés et leurs relations en 5 minutes.

Bien sûr, je caricature un peu la chose, mais vous voyez ce que je veux dire.

Méthodologie

Un modélisateur doit être méthodique. La méthode définie les choses autorisées et interdites dans une modélisation. Elle définie ce que pourront faire les modélisateurs. Son objectif est de garantir une homogénéité dans les modèles et d’assurer un niveau de qualité minimum (en terme de détails de description).

C’est un point bien souvent négligé.

Le modélisateur doit :

- savoir suivre une méthode qu’il n’a pas créé,

- savoir mettre au point une méthode,

- trouver les points faibles et faire évoluer une méthode existante,

- savoir expliquer le point précédent à un client !

Restitution

Si conceptualiser est la première étape, restituer est l’étape finale. Restituer de manière cohérente avec ce qu’il a précédemment fait est une qualité qui ne se trouve pas chez tout le monde.

C’est là où la méthode intervient.

Malgré la méthode, il arrive très souvent qu’une marge de manoeuvre existe. Si le modélisateur est bon, cette marge sera utilisée pour faire du modèle quelque chose de mieux que prévu, sinon ce sera un résultat décevant.

C’est aussi simple que ça. Vous constaterez tout de suite si un modèle « parle » ou s’il nécessite 5 minutes d’explication. Vous verrez la différence entre un modèle « auto-descriptif » et un modèle qui nécessite la présence de son réalisateur pour être compris…

Conclusion

Voici donc un petit aperçu rapide des qualités « techniques » d’un bon modélisateur de processus d’entreprise ou de systèmes d’information. Au-delà de ça, il ne faut pas oublier qu’un modèlisateur sera amené à discuter et échanger avec de nombreuses personnes et que ses qualités humaines sont très importantes.

Il me semble que les modélisateurs sont plutôt des gens qui fonctionne de manière visuelle. Ils privilégient ce canal au lieu du son qui naturellement est moins utile dans ce type de travaux.

Popularity: 3% [?]