Comment payer mon abonnement si mon fournisseur se situe en Belgique et moi à Tourcoing à 3 kilomètres de là ? Ou, plus sérieusement, comment accompagner la stratégie de Lisbonne ? Transformer l’Europe en une zone économique cohérente, favoriser la liberté des mouvements de personnes et capitaux, créer une réelle cohésion de pays disparates.
Cette idée s’est déclinée dans mon domaine, les paiements, par un acronyme simple : SEPA. Single Euro Payment Area. La mise en place de SEPA répondant à une volonté louable : mettre en place des moyens de paiement universels, efficaces et sécurisés.
Dans les faits, la mise en place de SEPA s’est traduit par la définition de règles – techniques et fonctionnelles – (normes ISO 20022, R-transactions, cycle des SDD, mandats…) complexes et contraignantes à mettre en œuvre.
Assez rapidement, SEPA est devenu l’arlésienne. Beaucoup d’articles et de conférences de toutes parts. Mais surtout de nombreux reports.
Mais ça y est, SEPA a été lancé en France.
Aujourd’hui, le démarrage, au forceps dans certains cas, est achevé.
Après une année de rodage, on peut tirer les premiers bilans de cette migration. Les tuyaux permettant les échanges sont en place et fonctionnent bien. Les outils permettant les transferts entre comptes sont en fin de rodage. Les organisations inter bancaires permettant le règlement des litiges sont opérationnelles.
Le chèque poursuit son lent déclin face à la carte et les virements (SCT) et prélèvements (SDD) ont définitivement remplacé les virements et prélèvements. Reste encore en circulation quelques moyens de paiements particuliers à la France comme les TIP, télé règlements et effets de commerce.
Novembre, nouveau mois clé de l’EPC
Dans ce nouveau cadre, l’EPC (European Payment Council, organisme qui définit les règles de fonctionnement des SCT et SDD) offre une nouvelle régularité à ses évolutions. Pas de keynote mode Apple, mais la définition d’un cycle régulier de diffusions et de mises en œuvre des règles.
Désormais c’est en novembre que l’EPC diffusera les règles des montées de versions (les rulebooks) mis en œuvre en novembre de l’année suivante. Ainsi, l’année 2015/2016 marque un gel des évolutions entre janvier 2015 et novembre 2016.
Quels impacts ?
A ce jour, la très grande majorité des transactions passe sans difficultés. Les banques et les grands remettants se sont adaptés. Des solutions ont été développées pour gérer les cas complexes posant encore problèmes.
Cependant, et malgré ces efforts, des blocages subsistent : la gestion des premiers SDD émis entre deux acteurs, la modification des mandats, la gestion des BIC / IBAN…
La gestion de ces – encore trop nombreuses – exceptions coûte cher à tous : paiements retardés ou empêchés, interventions manuelles, tensions entre les débiteurs et leurs créanciers, émissions en doubles.
Toutes les banques et tous les grands remettants gaspillent temps et argent pour gérer ces impacts. Une grande banque monopolise plus de 3 ETP rien que pour traiter les réactivations de RUM et le traitement des BIC/IBAN erronés. Dans ce middle office, les traitements manuels occupent environ la moitié des personnes en poste.
Les réponses de l’EPC : les nouveaux Rulebook
SEPA entre dans une nouvelle phase.
Après la décennie de définition des règles et principes, la migration des SDD et l’année de stabilisation technique, des leçons ont été tirées visant à clarifier et simplifier ces outils.
Les demandes des banques et des utilisateurs sont progressivement intégrées aux rulebooks.
Ainsi, en novembre 2015, une première simplification entre en application : donner la possibilité de modifier plusieurs paramètres d’un mandat en une seule fois. Imaginez. Deux entreprises fusionnent. Pour modifier les mandats, il faut d’abord modifier le nom des entreprises. Premier mandat. Puis modifier l’ICS (la référence du créancier) commun. Deuxième amendement.
De même avec ce nouveau rulebook, les principes de signature électronique sont clarifiés.
En début 2016, une nouvelle modification importante arrive : l’IBAN only. Le BIC disparaît. Dès lors, l’émetteur d’une opération n’aura plus à se soucier de la banque destinataire. Seul l’IBAN compte, charge à la banque d’identifier la banque destinataire et de lui faire parvenir les fonds.
Enfin, novembre 2016 marque une grande simplification des SDD.
1.1 Une réduction des délais
Aujourd’hui, la règle des délais à respecter pour la présentation d’un SDD est la suivante : 5 jours pour une première occurrence (First) ou pour un SDD unique (OneOff) et 2 jours pour les autres (Rcur), sauf si la banque en fait la demande et propose un règlement en une journée par l’intermédiaire d’un SDD Core 1.
En novembre 2016, la règle sera de respecter une journée entre l’émission et le traitement. Plus simple.
1.2 Une simplification des cycles
Fini les First !
Voilà comment nous pouvons résumer l’évolution à venir.
Avec ces trois mots, entreprises et banques vont être soulagées de bien des maux.
A ce jour, le cycle des SDD est le suivant : émettre un premier SDD (First) au cours duquel le mandat est référencé. Puis émettre les occurrences suivantes (RCUR) avec la référence de mandat (RUM) validée.
Imaginez le résultat pour les créanciers / débiteurs / banques. Lors du rejet de la première opération ce qui invalide le mandat, commence le grand jeu du « ce n’est pas moi, c’est lui ».
Dans le cas du middle office bancaire évoqué plus haut, cela se traduit par « et, gus, un rcur sur un rum invalide d’un first ko fait planter la chaine et le client il est en panade avec l’autre qui veut ses fond sinon c’est 10%, et le confrère y veut rien savoir, faut checker la rum et la valider manuellement »
Bon, en français ça donne, « un créancier vient d’émettre une demande de prélèvement sur un mandat non valide en raison d’un premier prélèvement non traité. Notre client demande d’agir rapidement car la DGFIP le menace d’une amende de 10%. Il faut valider manuellement le mandat sinon nous perdons notre bien aimé client ». Merci gus pour la traduction.
Ces simplifications importantes qui sont à mettre en œuvre dans les mois à venir impactent tous les SI – banque et client – sur les traitements, référentiels, contrôles, alertes et j’en passe. De même pour les processus dans les back et middle office.
Vers l’univers infini
Une fois ces simplifications en place, les moyens de paiements entrerons dans une phase de maturité : SI maitrisé, actions humaines réduites aux cas les plus critiques, rapidité d’exécution, fiabilité des traitements, sécurité des transactions.
L’idée séduisante est désormais partagée par l’ensemble des pays européens, y compris la Suisse, le Lichtenstein, ou San Marin. Après une mise en œuvre plutôt laborieuse, les européens ont mis en place un nouveau système de paiement global d’une puissance inégalée. Dès demain, toute personne (physique ou morale) de l’espace SEPA pourra toucher n’importe quelle autre personne dans des délais réduits et de manière sécurisée et simplifiée.
En fait, la mise en place de SEPA avait une double ambition.
Mettre en place des outils de paiements performants et standards en Europe, objectif en cours de finalisation. Mais également permettre l’éclosion de nouveaux services de paiement à haute valeur ajoutée.
Imaginez donc le résultat : avec SEPA, n’importe quelle entreprise a accès à un marché de plus de 740 millions d’habitants en une journée via un virement ou un prélèvement.
Demain, grâce à SEPA, les entrepreneurs qui développeront de nouveaux produits pourront directement assurer ce développement sur un marché dont le volume est supérieur au marché nord-américain et comparable à l’Inde.
SEPA va permettre l’éclosion de nouveaux modèles de paiements. Longtemps, les vecteurs d’échanges utilisés étaient normés et standardisés : le chèque, la carte, la demande de virement, le TIP… Demain, en utilisant les canaux de SEPA, n’importe quel « évènement » pourra déclencher un SCT ou un SDD. Utiliser un objet connecté, passer sous une arche, montrer son visage, lire une plaque d’immatriculation…
Bref avec SEPA, l’idée séduisante de départ permet à tout un secteur de passer d’un monde clos à un univers infini.
L’Architecture d’Entreprise est souvent vue de manière négative par les projets : effort coûteux, dé-corrélé de leurs contraintes, etc. Pourtant « sur le papier » cette pratique est très ambitieuse et prometteuse. Examinons les conditions d’un recours efficace à l’Architecture d’Entreprise.
Management de projets : tout change, rien ne change
Dans mon parcours professionnel, j’ai croisé et continue de croiser des « maîtres » qui influencent mes approches et mes convictions. L’un d’entre eux disait « le coût de la correction d’une erreur de conception est multiplié par 10 à chaque fois que l’on franchit une étape dans un projet : 1 au moment du cadrage, 10 en conception, 100 en réalisation / test, 1000 après le déploiement (lorsque c’est une fonctionnalité inadaptée qui a été déployée auprès de centaines d’utilisateurs) ». C’était à la fin des années 1990, et on était encore à l’époque sous le règne (finissant) de la méthode Merise.
Depuis, les technologies, la culture de projet et les compétences en ingénierie informatique se sont développées. Il existe aujourd’hui un grand nombre de « briques technologiques » utilisables pour assembler un SI comme un lego, sans avoir à développer spécifiquement chacune des pièces.
Cependant, rares sont les projets qui échappent aujourd’hui encore aux difficultés d’hier. On constate toujours une série de « manques » : manque de vision, de temps, de moyens, de savoir-faire, de discipline, de dialogue, d’analyse des besoins, etc. Plus que jamais, l’adage de mes débuts continue de se vérifier. D’ailleurs l’existence de « briques technologiques » de plus en plus élaborées, ne résout pas le problème d’architecture globale. En effet, on peut construire un truc très moche avec des lego très beaux !
Architecture d’Entreprise : l’art de traiter la complexité
Parmi les pratiques qui permettent de concevoir un SI, l’Architecture d’Entreprise est aujourd’hui celle qui apporte le maximum de garantie. Elle préconise l’extension des pratiques d’architecture du SI à l’ensemble des dimensions de l’entreprise. L’objectif poursuivi est d’éviter de ne penser l’architecture qu’en termes « d’architecture de solution informatique », qui est une réflexion trop restrictive car elle réduit le questionnement à la problématique informatique.
Pour compenser cela, les DSI font parfois intervenir sur les projets des maîtres d’ouvrage connaissant les applications, afin de conjuguer réflexion sur le métier et réflexion sur la solution. Cependant cela détourne souvent le maître d’ouvrage de son rôle : étudier l’opportunité et cadrer les besoins. Il arrive encore qu’on démarre des projets sans savoir s’ils sont vraiment souhaitables et faisables, avec pour seul actif une liste de besoins.
L’Architecture d’Entreprise propose un cadre permettant d’assurer une continuité d’analyse entre les différentes phases du projet. Elle couvre aussi l’analyse d’opportunité en amont des projets. Mais alors pourquoi les problèmes ne sont-ils pas déjà résolus ? Sans doute la démarche est-elle perçue comme complexe à déployer et à s’approprier (c’est l’argument le plus souvent entendu). En effet, le déploiement d’une démarche Architecture d’Enterprise appelle une évolution de l’organisation des démarches d’étude et de projet. Elle doit être portée par une ambition managériale et par la mobilisation des équipes. A défaut on verse immédiatement du côté obscur et l’on ne retient de l’approche que ce qu’elle a de plus hermétique : la méthode … inconcevable quand on manque de temps, manque de moyens, manque de savoir-faire, manque de discipline, manque de dialogue, etc. On finit par oublier le parti qu’on pourrait tirer de cette réflexion pour l’analyse.
Ce n’est pas le marteau qui fait bouger la main, mais l’inverse
Quand cet outil d’analyse est utilisé correctement, de manière pragmatique, on en voit immédiatement la valeur-ajoutée pour les projets. Et ce, sans attendre le déploiement des applications et le verdict des utilisateurs.
Lorsque l’Architecture d’Entreprise est présente dès le point d’ignition du projet (ou avec bonheur, plus en amont encore : lors d’un schéma directeur) elle est à même de porter et fédérer toutes les dimensions de l’analyse et répondre aux attentes des acteurs de la transformation :
Comprendre les enjeux des projets, et leur intérêt par rapport à la stratégie métier, pour donner des perspectives aux projets
Identifier conjointement les impacts pour le métier et la DSI, en animant le dialogue bipartite métier/IT qui soutient la transformation
Pouvoir identifier les ressources et les capacités d’évolution qu’il faudra mobiliser, et vérifier qu’elles sont bien disponibles (à quoi servirait une cible, sans la capacité d’évolution pour l’atteindre ?)
Donner aux équipes concernées les repères communs et partagés qui sont nécessaires pour fédérer les visions personnelles (forcément partielles et partiales)
Livrer les premiers plans ré-exploitables de la cible sous forme de schémas non équivoques, ainsi que des trajectoires appropriées pour l’atteindre
Créer la mobilisation autour du projet en propageant les nouvelles représentations mentales qu’implique la cible
(liste non exhaustive)
En résumé, l’Architecture d’Entreprise fait exister le projet avant qu’il n’existe. Puis elle l’accompagne dans son cycle de vie vers sa réalisation (son accomplissement !). Disposer d’un plan de route pour conduire une transformation est tellement utile lorsque les projets sont stratégiques, transverses et complexes. Faisons-le savoir, comme monsieur Jourdain pour la prose, l’architecte d’entreprise fait du management, sans qu’on le sache ! Mais lui, il le sait.
L’une des principales missions de l’urbaniste est de favoriser la souplesse d’adaptation du système d’information avec des moyens simples, peu coûteux et non intrusifs, tout en apportant une aide concrète aux équipes de projet. Traditionnellement, l’urbaniste est considéré comme un empêcheur de tourner en rond. Il est perçu comme l’auteur de chartes et de normes théoriques, que personne n’applique vraiment. Il en résulte un certain désenchantement, et un fort turn-over parmi la population des urbanistes.
Sans pour autant renier cette mission, cette tribune milite pour un urbanisme opérationnel, qui doit favoriser la souplesse d’adaptation du S.I. avec des moyens simples, peu coûteux et non intrusifs, tout en apportant une aide concrète aux équipes de projet. Exemple concret : le choix de progiciel.
Les deux missions de l’urbaniste
Pour définir le travail de l’urbaniste et ses enjeux, on a souvent recours à la métaphore de la ville. Comparaison pertinente, même si les contraintes du système d’information sont plus ou moins faciles à contourner. En effet, s’il est plus facile d’augmenter le débit d’une ligne réseau que d’élargir une rue, les erreurs et plus encore le manque d’anticipation se révèlent souvent très coûteux… des années après.
Penser l’organisation du territoire, donc. Appliqué au SI, le problème revient à découper celui-ci en blocs à la fois suffisamment autonomes, reliés entre eux de manière efficiente, et en mutualisant au mieux les composants. Si la problématique est relativement simple pour les composants techniques – les SGBD, les middleware, le poste de travail et ses applications de bureautique – , plusieurs approches ont cours pour déterminer les frontières applicatives : par fonction de l’entreprise, par service (au sens SOA), par domaines d’objets…
Soyons humbles : il n’existe pas de réponse toute faite. Pour prendre le seul exemple du pilotage d’entreprise, il peut être judicieux soit de l’isoler, afin de mutualiser les outils d’analyse et de reporting, soit de l’intégrer aux systèmes opérationnels (ERP…) pour faciliter le processus d’analyse de bout en bout, et éviter d’alimenter de coûteux datawarehouses. Sur ce point, le discours des éditeurs, variant au gré des alliances, n’éclaire pas vraiment les choix.
Pour noble et vitale qu’elle soit, cette première mission de l’urbaniste rencontre des limites d’application : tout d’abord, les projets de refonte significative du SI étant rares, le chantier est perpétuel et les victoires rapides demeurent exceptionnelles. Par ailleurs, les chartes d’urbanisme sont difficilement compatibles avec la mise en oeuvre de progiciels, pour une raison bien simple : l’objectif de l’éditeur est de pouvoir mutualiser son offre vis-à-vis de clients de métiers différents, d’organisations et de stratégies différentes.
Un garde-fou : les points de précaution
A notre point de vue, l’urbaniste doit assurer une seconde mission : veiller à ce que les équipes de projet respectent le minimum de règles de conception qui permettront de faire évoluer la solution facilement, sans paramétrage ni re-livraison de code. Point important, ces règles s’appliquent aussi bien aux progiciels qu’aux développements spécifiques. Problème : ces règles sont souvent abstraites, peu parlantes pour les experts métier et les maîtrises d’ouvrage.
La solution que nous proposons est simple et rapide : au lieu de règles, l’urbaniste fournit aux équipes projet un questionnaire de points de précaution, exprimés en termes métier. Exemple : est-il possible de modifier l’identifiant d’un client sans perdre l’historique des échanges avec ce client ? Pour déployer la solution sur une nouvelle filiale, est-il possible d’ajouter une nouvelle langue sans faire appel à l’éditeur du progiciel ?
Comme on le voit, les questions sont précises, conçues pour appeler une réponse rapide et simple : par oui ou non. Chaque réponse négative identifie immédiatement un risque de rigidité, un écart par rapport à des bonnes pratiques, dont l’impact peut être immédiatement évalué par l’ensemble des parties. Les points de précaution incontournables sont priorisés d’un commun accord, en fonction du métier et des perspectives d’évolution de celui-ci : intégration de nouveaux partenaires, déploiement plausible à l’international sous 3 ans… Conséquence logique de la démarche, l’urbaniste peut aller jusqu’à exercer un droit de veto lorsque ces points ne sont pas traités de manière satisfaisante.
En pratique, nous avons pu vérifier sur le terrain que le questionnaire permettait de hiérarchiser des progiciels entre eux, et par conséquent de discriminer les moins agiles. Bien entendu, il ne s’agit que d’un élément supplémentaire de choix, mais qui contribue à objectiver la décision finale.
Quelles compétences pour l’urbaniste ?
On le devine, cette approche transforme le rôle de l’urbaniste. De donneur de leçons, il devient fournisseur de conseil : il apporte un éclairage complémentaire, parfois décisif, sur des choix structurants. Son apport est reconnu, facilement accepté, et contribue à valoriser la fonction.
Pour arriver à remplir ce rôle, il est souhaitable d’avoir une expertise en modélisation et en fabrication de logiciel. Des connaissances métier sont également utiles pour traduire les règles de conception en points de précaution spécifiques au contexte. Il arrive de trouver dans des appels d’offre des questions formulées ainsi : le progiciel est-il multi-devise ? Bien entendu, l’éditeur répond oui. Dans le détail, même dans des domaines métiers aussi banalisés que la comptabilité, le traitement multi-devise varie d’un progiciel à l’autre. L’urbaniste est là pour affiner la question : le progiciel permet-il à un client de régler dans plusieurs devises, d’être titulaire de plusieurs contrats dans des devises différentes ?
Ne rêvons pas : le droit de veto de l’urbaniste n’est pas pour demain. Rares sont les urbanistes à disposer de budgets autonomes, d’équipes de conseil opérationnel à même d’apporter un support aux équipes de projet. Ce que nous proposons ici n’est qu’un modeste petit pas vers un renforcement légitime de l’autorité de l’urbaniste.
La modélisation des processus s’est répandue au cours des dernières années. Elle est un exercice délicat, surtout pour des personnes peu préparées. Cette chronique propose 10 règles pratiques et éprouvées pour produire des modèles utiles, et les réaliser rapidement.
L’intérêt de la modélisation des processus n’est plus à démontrer. Du côté des informaticiens, de nombreuses démarches de conception, d’urbanisation, d’»architecture d’entreprise» se fondent sur la modélisation des processus ; ces méthodes commencent à se diffuser du côté des utilisateurs et à attirer l’attention des décideurs. En parallèle, de nombreuses entreprises refondent en permanence leurs processus pour les optimiser et les adapter aux évolutions de leur métier. Toutefois, bien modéliser n’est pas donné à tout le monde. Récemment, j’ai été témoin de l’expérience suivante : dans une grande entreprise, la Direction des Opérations avait demandé à 3 personnes de modéliser le même processus. A l’arrivée, elle a obtenu trois résultats complètement différents ! Imagine-t-on un architecte fournir trois plans différents pour un même bâtiment, ou un constructeur de PC fournir 3 plans différents de la même carte-mère à son fabricant ?
Bien modéliser n’est pas un problème d’outillage, mais de méthode : la véritable difficulté est d’appliquer des règles simples, pour aboutir à un modèle qui soit à la fois fidèle et utile. Il ne suffit pas de maîtriser les notations BPMN ou UML : comme pour la musique, savoir lire une partition ne fait pas de vous un Bach ou un Gainsbourg du jour au lendemain !
Pour remédier à cette situation, il convient d’appliquer les dix règles concrètes de modélisation des processus :
1) Distinguer processus et procédure :
Cette règle bien connue est dans les faits très mal appliquée. Rappelons les définitions de l’AFNOR : un processus est un ‘ensemble d’activités corrélées ou interactives qui transforme des éléments d’entrée en éléments de sortie’ alors qu’une procédure est la ‘manière spécifiée d’accomplir une activité’. Bref, le processus décrit uniquement les invariants, c’est-à-dire les règles universelles applicables à toutes les organisations, indépendamment des moyens utilisés pour son exécution. Les moyens sont à décrire dans les procédures. Par exemple, une entreprise peut décider de mettre en place un processus unique et multi-canal pour traiter les réclamations de ses clients. Ce processus se déclinera ensuite selon différentes procédures, selon que la communication avec le client se fait par courrier, par e-mail, ou par téléphone.
Distinguer processus et procédure est la condition indispensable pour identifier les règles communes que l’entreprise s’impose – ou que le monde extérieur lui impose -, et bien les séparer des contraintes liées aux moyens utilisés.
2) Se contenter de 3 niveaux de description :
On rencontre parfois de superbes « chaînes de valeur » où les processus se décomposent en poupées russes. Il est fréquent de devoir explorer 6 ou 7 niveaux de profondeur. D’autres modélisateurs sont des adeptes de la récursivité : un seul concept est mis en œuvre, par exemple l’activité, et une activité peut contenir des activités, et ainsi de suite… Problème : dans les deux cas, ces modèles s’avèrent très vite inexploitables.Par exemple, il est très difficile au modélisateur de déterminer si l’action « contacter le client » devrait se situer au niveau 4, 5 ou 6. Conséquence : le référentiel des processus de l’entreprise contient de nombreux doublons, alors que chaque tâche et chaque activité ne devraient être décrites qu’une seule fois.
Nous recommandons de n’utiliser que trois éléments pour décrire les processus : au niveau le plus détaillé, la tâche, puis l’activité, et enfin le processus lui-même. Un quatrième niveau de description est utile lorsque l’on veut décrire les procédures : nous recommandons d’introduire la notion d’opération. Chaque tâche est alors décrite comme une suite d’opérations. Par exemple, contrôler l’identité d’une personne se décline en plusieurs opérations selon les pays et les supports (carte d’identité, badge, passeport biométrique…)
3) Définir les tâches par la transformation d’un objet Métier :
Toute tâche doit modifier un objet Métier. Par objet Métier, Rhapsodies Conseil entend un élément manipulé au quotidien par les acteurs de l’Entreprise. Il est assez facile de dresser une liste des principaux objets Métiers. Ce sont souvent les mêmes d’une entreprise à l’autre : des produits, des commandes, des contrats, des matériels…La règle permet alors de déterminer quelles sont les tâches qui sont vraiment nécessaires. En effet, comme on l’entend souvent dire, une tâche doit avoir une valeur ajoutée. Un moyen concret de s’en assurer, est de vérifier que la tâche a effectivement modifié un objet. A l’inverse, toute action qui ne modifie rien n’a pas de valeur ajoutée, il est donc totalement inutile de la décrire. L’action « lire le courrier » par exemple n’a aucune valeur ajoutée : ce qui importe vraiment, c’est de déterminer les tâches à exécuter suite à la réception de ce courrier.
4) Faire porter toutes les règles de gestion par des tâches :
Cette règle découle de la précédente. Soit une tâche T1, qui permet de faire passer un objet O d’un état E1 à un état E2. Pour cela, elle doit obéir à une série de règles de gestion. La tâche suivante aura pour but de traiter tous les objets O qui sont dans l’état E2. A ce niveau de description, il est totalement inutile d’ajouter une règle (ou pire, une tâche, comme on le voit parfois) pour indiquer que lorsque la tâche T1 est terminée, alors il faut exécuter la tâche T2. Ainsi, dès le départ, on isole tout naturellement les règles d’enchaînement, ce qui facilite l’utilisation d’outils d’orchestration de processus (BPM, workflow).
5) Appliquer une démarche ‘bottom-up’ :
C’est-à-dire décrire d’abord le niveau le plus fin, les tâches. Celles-ci seront ensuite regroupées en activités, en fonction de règles précises. Ceci évitera de reproduire l’organisation et les règles existantes : il suffit d’identifier l’objet Métier en jeu, l’état final de cet objet, pour déterminer de proche en proche les étapes nécessaires et les autres objets manipulés. Exemple : pour un processus de recrutement, la dernière tâche peut être exprimée par « confirmer l’adéquation du candidat au poste ». On en déduit les tâches antérieures : contrat signé, poste de travail configuré, recrue formée,… Comme on le voit dans cet exemple, on transcende les frontières de l’organisation, qui le plus souvent confie la formation à une entité, la signature du contrat d’embauche à une autre, la configuration du poste de travail à une troisième.
6) Utiliser les évènements avec parcimonie :
Dans la grande majorité des cas, il est inutile de conserver une trace séparée des évènements. Il suffit d’historiserles états successifs par lesquels l’objet Métier est passé, ce qui revient exactement au même. Par exemple, il est bien évident que la tâche « valider une facture » fait passer la facture à l’état validé ; il ne sert donc à rien d’enregistrer dans le système d’information un évènement ‘facture validée’. Il suffit de mémoriser la date à laquelle la facture a été validée, et ce, seulement si on en a vraiment besoin. Cette approche simplifie la mise en œuvre du pilotage de l’activité (BAM) en se concentrant directement sur les résultats, et non sur les évènements.
Bien entendu, certains évènements doivent figurer dans le modèle de processus. C’est en particulier le cas des évènements indépendants de tous les acteurs : par exemple, la fin du mois, pour déclencher un arrêté comptable.
7) Faire porter les activités sur un objet métier unique :
Une activité est une suite de tâches qui portent sur un même objet, et qui a pour but de faire passer cet objet par des états successifs de son cycle de vie. La raison de ce critère de regroupement est purement économique : dans l’idéal, cette série de tâches devrait pouvoir être confiée à un même agent, de manière à éviter les ruptures de charge, toujours coûteuses.
8) Déterminer les rôles à partir des activités, et non l’inverse :
Un rôle doit être vu comme l’ensemble des privilèges nécessaires à un même agent (personne, système…) pour pouvoir exécuter les tâches qui lui sont confiées. Dans l’idéal, comme on l’a vu précédemment, il est plus économique de faire exécuter une activité de bout en bout par le même agent. Toutefois, ceci n’est pas toujours souhaitable, en particulier pour des raisons de sécurité et de contrôle. L’exemple classique est le traitement des factures Fournisseurs : l’agent qui valide une facture ne peut pas déclencher le règlement de celle-ci. Ceci aboutit à définir deux rôles distincts. Contrairement à l’approche couramment pratiquée, ce ne sont donc pas les rôles qui doivent déterminer les activités, mais bien les activités qui doivent déterminer les rôles. Le titre de « Contrôleur de Gestion » par exemple, ne permet pas de déterminer les différentes activités dont un contrôleur de gestion a la charge : celles-ci varient fortement d’une organisation à l’autre. Par exemple, dans certaines entreprises, le contrôleur de gestion approuve les commandes d’investissement; dans d’autres, il valide les factures.
9) Distinguer les pouvoirs des compétences :
Les compétences nécessaires à l’accomplissement des activités n’ont pas à intervenir lorsqu’il s’agit de décrire un processus. Ces compétences seront à prendre en compte dans un deuxième temps seulement, au moment de définir les moyens nécessaires pour exécuter les tâches, c’est-à-dire lorsque l’on déclinera les procédures. Choisir de spécialiser ou non des agents en fonction de leur compétences est une décision purement économique :dans beaucoup de restaurants, le client va se servir lui-même. Et dans certains restaurants, le client cuit lui-même son repas !
10) Tenir compte des intérêts de toutes les parties prenantes :
Ce sera notre critère principal pour déterminer les bornes d’un processus. Un processus n’est que l’un des chemins possibles parmi toutes les activités qui figurent au « catalogue » de l’entreprise : il ne s’arrête que lorsque les intérêts de toutes les parties prenantes sont satisfaits. Par exemple, il y a quelques années, un opérateur de téléphonie mobile prenait la peine d’appeler ses clients dans les 48 heures suivant leur achat d’un nouveau coffret, de manière à s’assurer qu’ils arrivaient bien à l’utiliser. Par ailleurs, on oublie trop souvent les intérêts de l’État, du partenaire à qui il faut verser une commission,… Bien entendu, il ne s’agit pas de dire que toute l’Entreprise peut se réduire à un seul processus !
En conclusion, ces quelques règles basiques garantissent un référentiel de processus homogène : éviter d’avoir 200 actions pour décrire un processus alors que 15 suffisent, éviter des doublons du type « accorder un prêt » et « octroyer un crédit »… Avantage tout aussi important, elles amènent à se poser les bonnes questions au moment de modéliser un processus : et en particulier, distinguer ce qui est vraiment invariant, de ce qui dépend des moyens utilisés. Un modèle construit avec ces règles permettra à l’organisateur de trouver des leviers d’optimisation, et à l’informaticien, de trouver les fonctions à implémenter dans le système informatique.
Remerciements : Rendons à César ce qui lui appartient : si la majorité de ces règles sont ma modeste contribution, je remercie Praxeme qui dès 2003, avait clairement formulé la règle N°3. Merci également au Club des Pilotes de Processus, dont sont tirés quelques-uns des exemples cités.
Les autres articles qui peuvent vous intéresser
L’architecture d’entreprise, fruit de l’intelligence collective ?
L’architecture d’entreprise, fruit de l’intelligence collective ?
Une architecture d’entreprise bien conçue est le fruit d’une intelligence collective. Le déploiement des pratiques d’architecture doit aussi être considéré du point de vue humain. Tentative de démonstration en ré-exploitant quelques enseignements de la mobilisation en entreprise.
Pour concevoir et faire évoluer l’architecture du système d’information d’une entreprise, il faut tenir compte de nombreuses préoccupations hétéroclites : métiers, techniques, managériales, financières, réglementaires, etc.
Par leurs efforts, les différents métiers en charge de l’architecture parviennent à définir des architectures cohérentes, alignées avec les différents besoins, à la fois pérennes et évolutives. Une architecture bien conçue est finalement le fruit d’une mobilisation, par laquelle l’intelligence collective opère correctement. Pour aider les architectes d’entreprise, il existe un ensemble de bonnes pratiques permettant de concevoir une architecture adaptée à chaque entreprise, développé depuis plusieurs années. Ces bonnes pratiques sont une extension des pratiques architecturales à l’ensemble de l’entreprise : représenter (modéliser) pour concevoir et partager ; comprendre l’existant pour savoir d’où l’on part ; établir une cible ; établir des bibliothèques d’architectures-types ré-exploitables ; etc.
L’effort d’appropriation de ces bonnes pratiques est souvent focalisé sur la définition des outils de l’architecte (modélisation, patterns, concepts, livrables, etc.). L’appropriation et l’adoption des outils est longue et on la qualifie volontiers « d’évangélisation ». Aussi pertinents ces outils soient-ils, ils ne peuvent pas provoquer la mobilisation de l’intelligence collective à eux seuls. On doit compléter leur déploiement par une série d’initiatives visant à mobiliser les acteurs de l’architecture. Il faut rappeler ce qu’est la mobilisation.
Les différentes formes de la mobilisation
La mobilisation est l’acte intentionnel d’un collaborateur le conduisant à faire des efforts dans le sens d’un travail collectif. D’après Arnaud Bichon, sociologue, on trouve trois formes de comportement de mobilisation, classés par ordre de complexité croissante :
Les conduites relationnelles : ce sont les efforts favorisant la connaissance mutuelle des acteurs et divers types de partage entre eux. C’est le fameux « esprit de corps » des gens du (même) métier qui s’apprécient. Le collaborateur mobilisé est celui qui fait l’effort de tisser des liens, de vivre des expériences avec l’autre. L’inverse, c’est l’individu isolé qui n’engage aucune relation particulière.
Les conduites coopératives : ce sont les efforts spontanés de collaboration, avec des prises d’initiatives dépassant le cadre stricte des obligations. Le collaborateur mobilisé est celui qui travaille délibérément en interaction avec ses collègues et s’implique dans les décisions, qui « partage ». L’inverse c’est la non-collaboration.
Les conduites d’intercompréhension : ce sont les efforts pour construire des représentations communes, comme référence des actions collectives et individuelles. Le collaborateur mobilisé est celui qui développe une vision globale de l’activité contribuant à « construire avec autrui ». L’inverse, c’est celui qui veut rester dans son cadre de référence.
La mobilisation est provoquée selon deux modalités de natures très différentes, qui se complètent :
Un processus managérial de mobilisation (pratiques RH, prescriptives et descendantes, sous forme d’injonctions) visant à déclencher la mobilisation.
Un ensemble de comportements individuels, « autogènes », à l’initiative du collaborateur.
Plus les formes de mobilisation sont complexes (de 1 à 3 dans la liste plus haut), plus elles sont délicates à provoquer, car elles sont discrétionnaires. L’intelligence collective fait partie de celle-ci. Elle fait parfois dire à des patrons d’entreprises que « la collaboration se constate, mais qu’elle ne se mesure pas », comme une déclaration d’impuissance.
Application à l’architecture
Lorsque l’on déploie les outils de l’architecte (modélisation, patterns, concepts, livrables, etc.) on travaille sur une série d’injonctions visant à provoquer l’utilisation de nouveaux outils. A l’opposé d’une démarche par injonctions, pour que l’intelligence opère, il faut agir sur les comportements, afin de créer des réflexes de collaboration. Il s’agit de créer un contexte favorable.
Dans cette perspective, des actions prioritaires sont à mener en parallèle :
Faire reconnaître la pratique de l’architecture dans le cadre de référence RH de l’entreprise. Il paraît difficile de demander au équipes de réaliser des effort sur une discipline qui ne serait pas reconnue comme telle. Cela nécessité une réflexion, car il n’existe pas de cadre de référence publiée sur le sujet. On trouve n variantes sur le sujet « Architecte » dans le domaine SI. C’est dans le cadre de référence RH que l’on pourra définir les fonctions des « Architectes d’Entreprise » et des points de repère pour formuler des objectifs annuels individuels.
Créer une communauté des architectes, pour provoquer les rencontres et les « conduites relationnelles » qui ensuite seront poursuivies dans le cadre des activités courantes. Cette communauté peut prendre différentes formes : petits déjeuners débats réguliers, conférences animées par des intervenants internes ou des prestataires, groupes de travail à thème, outils de partage d’information (le « wiki » des architectes), etc.
Développer l’envie de faire de l’architecture, en recherchant et en agissant systématiquement sur les appétences et les freins des acteurs de l’architecture. On doit pouvoir établir un plan d’action de changement très pragmatique, impliquant les acteurs et leurs hiérarchies, en complément des habituelles réunions d’information. sur l’architecture.
Développer un réseau favorable à l’architecture en identifiant les alliés sur lesquels on peut compter et en leur confiant des initiatives concourant au déploiement de l’architecture.
Je n’ose pas rappeler qu’un soutien, dans les paroles et les actes, de la Direction des Systèmes d’Information, est indispensable pour que l’opération réussisse.
Les autres articles qui peuvent vous intéresser
Externalisation IT : les écueils au-delà du RFP et du contrat
Externalisation IT : les écueils au-delà du RFP et du contrat
Le marché de l’externalisation est devenu plus mature et les DSI beaucoup plus expérimentées sur la base des différentes générations de leurs contrats d’externalisation. Les enjeux d’hier : préparer / lancer un appel d’offre et contractualiser les services sont aujourd’hui perçus comme moins sensibles en dépit de nouveaux enjeux tels que le multi-sourcing, les renouvellements de contrats forcément plus fréquents et les nouvelles approches de delivery (Cloud, Devops, Agilité, SDA/RPA,…).
Néanmoins et en dépit de la maturité du marché, les difficultés à capter toute la valeur ajoutée des projets d’externalisation informatique n’ont pas diminué et ce d’autant plus que les durées cumulées des différents contrats s’allongent … Au-delà du RFP et du contrat quels sont donc les écueils que l’on rencontre dans les projets d’externalisation informatique ? Sur la base de mon expérience et des échanges que je peux avoir avec mes clients, j’identifie quatre type d’écueils :
Ecueil n°1 : pas de stratégie de sourcing pertinente
On peut presque tout externaliser mais pas n’importe comment ni avec n’importe qui…
Les motivations à externaliser un périmètre donné devraient théoriquement être toujours déterminées par l’objectif de le faire progresser dans différentes dimensions (coûts, qualité, flexibilité,..). Une fois tranchée la question des grands domaines susceptibles d’être externalisés, se posent des questions de stratégie de sourcing plus opérationnelle et leurs lots d’écueils potentiels :
Les axes de progrès recherchés (organisation, finance, technique,…) ne sont parfois pas formalisés et/ou partagés : difficile dans ces conditions de mesurer la valeur de tels projets et surtout d’empêcher les différentes parties prenantes d’être en situation d’insatisfaction quasi-permanente,
Dans certains cas, les leviers de progrès / d’optimisation indispensables et adaptés sont incompatibles avec la politique de l’entreprise ou bien les transformations organisationnelles à mener ne sont pas traitées dans le cadre du projet d’externalisation. En conséquence des projets souvent pertinents se retrouvent « plantés » en raison d’un modèle de sourcing inadéquat ou d’une gouvernance qui n’a pas été adapté. C’est dans ces situations que l’on voit des appels d’offres qui posent les mauvaises questions au marché,
Pire encore, l’appel d’offre pose les bonnes questions mais aux mauvais acteurs … C’est la meilleure manière d’externaliser un périmètre à un fournisseur qui n’a pas les leviers (industriels, méthodologiques, humains,..) pour faire progresser ce périmètre. C’est un cas que l’on voit relativement souvent quand un donneur d’ordre n’est pas si mature que cela et finit par signer un contrat avec un fournisseur aussi peu mature que lui mais avec qui le niveau d’échange est très bon mais les promesses rarement tangibles …
Ecueil n°2 : un gouvernance contractuelle de la relation
Quand on n’a qu’un marteau comme outil, tous les problèmes ressemblent à des clous…
Ou quand la relation client-fournisseur n’est vue qu’au travers du prisme du contrat signé – on parle alors de gouvernance contractuelle de la relation – tous les aspects de la relation client-fournisseur semblent régis par le contrat avec les écueils suivants :
Sans surprise, les gestionnaires de contrats côté fournisseurs finissent assez rapidement par se prendre pour les gestionnaires de la relation client mais avec un niveau d’échange limité aux enjeux de delivery, des interlocuteurs côté client centrés sur le pilotage du contrat et une tendance à ne pas laisser approcher les commerciaux et autres gestionnaires de comptes de ce qu’ils considèrent être leur périmètre. En conséquence, aucune promesse implicite (non contractualisée) n’est généralement tenue (exemple l’innovation) et le dynamisme dans la gestion du contrat / de la relation n’est souvent pas au rendez-vous.
Dans le contexte d’une gouvernance contractuelle de la relation le niveau des échanges conditionne le niveau des interactions. Ainsi l’on parle plutôt d’une relation de coopération et d’un partage des tâches que d’une relation de collaboration où ce sont les objectifs qui seraient partagés. Les incidences sont concrètes et directes, avec par exemple dans le cas de la coopération, un pilotage via un certain nombre de revues d’évaluation de la performance et pour la collaboration un certain nombre de revues de synchronisation … Ça fait toute la différence et c’est le début de relations client-fournisseur plus équilibrées / plus productives.
Ecueil n°3 : des services non centrés sur les utilisateurs
Les services sont produits au moment où ils sont consommés. On ne peut donc jamais s’affranchir de l’utilisateur…
Si les utilisateurs sont souvent les derniers à découvrir ce qui a été prévu pour eux dans un contrat d’externalisation, ils sont généralement les premiers à être impactés quand les services ne leur conviennent pas. Autant l’équation de services centrés sur les utilisateurs est simple à poser « adéquation aux besoins + attitudes + performance + valeur ajoutée », autant la promesse est difficile à tenir dans le cadre des projets d’externalisation. Je ne connais pas de méthodes scientifiques pour réussir ce challenge mais recommande trois principes d’actions de bon sens :
Impliquer les utilisateurs dans la définition du catalogue de services. C’est simple quand la maîtrise d’ouvrage est structurée, c’est difficile et souvent inefficace quand c’est la maîtrise d’oeuvre qui s’en charge et présume des besoins des utilisateurs,
Ne pas trop stéréotyper les prestations et veiller à garder de la flexibilité dans le modèle de delivery,
Enfin, concevoir des services certes industriels mais sans jamais les déshumaniser.
Ecueil n°4 : modèle d’opération inadapté
Ce n’est pas en faisant les choses de la même façon que l’on obtient des résultats différents…
Pour faire progresser les périmètres externalisés dans différentes dimensions (coûts, qualité, flexibilité,..), le fournisseur doit transformer le ou les modèles d’opération existants à l’aide de leviers de transformation dont son client ne dispose à priori pas.
Mais dans certains cas, le modèle d’opération cible n’est pas adapté aux progrès attendus et ce pour trois raisons principales :
Le projet d’externalisation a prévu une phase de transition des services vers l’infogérant mais n’a tout simplement pas prévu de phase de transformation.
Dans d’autres cas, un projet de transformation a bien été prévu dans le projet d’externalisation mais à l’usage, les leviers de transformation se révèlent inapplicables où bien le projet de transformation ne va pas au bout pour d’autres raisons (souvent des raisons de complexité, de coûts du projet ou de maturité de l’équipe en charge de la transformation).
Parfois c’est le client qui ne collabore pas suffisamment au projet de transformation avec son infogérant…. rarement volontairement mais souvent pour des raisons de gouvernance interne.
Dans les trois cas, le résultat est problématique car l’infogérant n’a tout simplement pas les moyens de tenir ses promesses avec un modèle d’opération inadapté / non transformé.
A titre d’illustration, on peut noter le cas de grands groupes qui externalisent – pour les faire converger – leurs différents Service Desk (filiales / pays) vers un infogérant unique. Dans de nombreux cas la « transformation » s’arrête à la transition des différents périmètres vers le fournisseur choisi. Très peu de rationalisations sont finalement menées et la capture des gains liés à la mutualisation de ressources et à l’utilisation de processus et d’outils communs demeure un vœu pieu.
Et pourtant tout s’annonçait si bien…
Syndrome du Titanic ?
Pour finir, les 4 écueils précédemment évoqués partagent avec l’histoire du Titanic et de son iceberg fatal, les 2 caractéristiques suivantes :
Ces écueils sont potentiellement dans le chemin critique du succès du projet d’externalisation avant le démarrage du projet,
Une fois le projet lancé, ces écueils sont difficiles à éviter / contourner.
En guise de conclusion : quelle que soit votre maturité en matière d’externalisation, il est toujours aussi crucial et difficile d’acheter les bonnes promesses et de faire en sorte qu’elles soient tenues dans la durée.
