Ce qui est compliqué dans une démarche d’amélioration par les processus, c’est d’accomplir le potentiel « maximum » de la démarche.

On rencontre souvent des débuts de définition de processus, de la recherche du processus optimal et parfois même la mise en oeuvre de changements opérationnels.

Dans d’autres cas, on va se concentrer sur l’urbanisation du système d’information et sur la rationalisation du parc applicatif. Ici, les résultats mesurables seront toujours intéressant tant le poids du patrimoine pèse de plus en plus lourd dans le fonctionnement des entreprises.

Ailleurs, ce sera une analyse opérationnelle façon Lean Six Sigma avec des modifications locales qui amélioreront le processus.

Dans tous les cas, chacune de ces démarches aura un effet positif mais au fil du temps je me demande si on ne perd pas une partie de l’effort en réalisant ces projets de manière déconnectée, sans capitalisation de l’expérience commune.

Plus facile à dire qu’à faire, le fait de coordonner les efforts serait une articulation idéale entre la nécessaire analyse de l’existant tant du point de vue général que du point de vue opérationnel et les changements à mettre en oeuvre. Le support idéal reste le référentiel des processus supporté par une démarche d’architecture d’entreprise.

L’urbanisation des systèmes d’information reste encore l’une des sources les plus fréquentes d’une démarche de modélisation des processus métier. Curieusement, on semble considérer -et le nom de mon blog en témoigne- que le système d’information fait parti du métier de l’entreprise à un point tel qu’il se permet de parler de processus métier.

De ma perspective, cela reste un travers dont on doit sortir. Le métier et ses objectifs doivent piloter l’ensemble des efforts. Les objectifs stratégiques doivent être déclinés en indicateurs opérationnels et c’est ensuite que les éléments de support à la production de valeur, comme le système d’information, prennent le relais.

Coordonner est très compliqué mais c’est en orchestrant les actions depuis le bon niveau d’autorité que les résultats auront un impact notable, durable et surtout reproductibles.

Popularity: 10% [?]

Les discussions autour de l’architecture d’entreprise et des meilleures pratiques à adopter produisent souvent le même schéma de discussion.

Tout d’abord, on commence par lister l’ensemble des problèmes dans les différents projets en cours en essayant d’en trouver sommairement les causes et soudainement on passe à la phase où l’on défini les choses telles qu’elles devraient être.

N’importe qui suivant une discussion de ce type peut facilement trouver le propos très optimiste voire idéaliste : comment peut-on survoler les problèmes et passer du temps à élaborer un monde tel qu’on souhaiterait le voir ?

S’il y a une difficulté récurrente à laquelle doit faire face un architecte, c’est son manque de poids sur la vie de l’entreprise : au mieux il est écouté, au pire il est ignoré.

Bien entendu, rien n’est jamais si noir ou si blanc mais notre architecte a de quoi être perdu au beau milieu de cet organisme dont il voudrait pouvoir définir la structure et qui n’a pas le temps de se structurer.

Beaucoup d’architectes d’entreprise tendent parfois à penser que l’entreprise existe pour se structurer en omettant un détail : les clients, la place sur le marché et les produits/services à vendre.

L’organisation interne est tirée par le marché. Si auparavant, l’entreprise devait se structurer pour pouvoir répondre à un marché, le sentiment que c’est désormais le marché qui tire les organisations est de plus en plus répandu.

L’architecte d’entreprise est donc destiné à être un idéaliste car ses rêves d’efficacité ne pourront jamais tous être mis en oeuvre. Entre sa vision cible et la capacité de changement au quotidien qu’il peut réaliser, notre architecte d’entreprise est bien tiraillé entre 2 opposés.

Pour autant, son rôle est essentiel. Sa vision d’une cible donne la direction à suivre pour l’organisation interne. Il ne pourrait y avoir d’évolution réussie et reproductible sans savoir où l’on va et sans quelqu’un qui soit le pivot entre les tendances technologiques, les besoins business et l’état du patrimoine.

Popularity: 27% [?]

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

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

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