Comment les processus en boucle ouverte perturbent le flux d'informations dans les entreprises

J'ai effectué une bonne partie de la réingénierie des processus métier au cours de ma carrière, et le plus gros problème que je rencontre est toujours le même : les processus métier en boucle ouverte. Les processus en boucle ouverte se produisent principalement parce que la responsabilité est répartie entre plusieurs personnes et souvent entre plusieurs services. Un flux d'informations qui commence en R&D par une demande d'un nouvel équipement peut transiter par les Finances et les Achats avant de sortir du périmètre organisationnel vers le Fournisseur (où il passera tour à tour par plusieurs départements), puis finalement de revenir vers la Réception et , avec de la chance, le groupe R&D qui a initié le flux.

À chaque étape, il est possible que la communication soit perturbée et les chefs de projet doivent atténuer ces risques. Si les flux d'informations intégrés à un processus métier ne sont pas explicitement structurés pour intercepter puis gérer les exceptions, l'échec ne sera détecté que bien plus tard, voire pas du tout. Alors que certaines défaillances du flux d'informations se traduisent simplement par des articles relativement sans importance qui ne sont pas commandés ou livrés correctement, d'autres défaillances peuvent coûter aux organisations d'énormes sommes d'argent ou imposer des retards sur des activités critiques.

Les boucles ouvertes peuvent coûter des millions de dollars

Pour illustrer ce point, je vais d'abord parler d'une grande organisation pharmaceutique qui payait des taxes sur des centaines de millions de dollars d'équipement qu'elle ne pouvait plus retracer et qui voulait supprimer cette dépense inutile. Notre projet a révélé de nombreux défauts de processus fondamentaux, qui totalisaient des dizaines de millions de dollars d'impôts inutiles par an et autant d'argent dépensé pour commander les mêmes choses plusieurs fois par erreur.

Communication à sens unique entre les domaines de responsabilité

Comme toutes les grandes organisations, les responsabilités étaient cloisonnées. Quelqu'un dans la fabrication a besoin de l'équipement X, il en informe donc les finances et un bon de commande (PO) est généré. La commande envoie le bon de commande au fournisseur. Jusqu'à un an dans le futur, X est livré et accepté par Réception. La réception notifie la fabrication et les finances. Les finances émettent une étiquette d'actif, qui reçoit des gifles sur X. X est placé dans la chaîne de production et tout va bien.

Sauf que tout ne va pas bien. Pour commencer, les employés vont et viennent, et il est facile de commander X sans se rendre compte que quelqu'un d'autre dans le même rôle a commandé X il y a neuf mois. Les finances n'ont aucune idée que cette commande est un doublon : elles supposent que vous avez simplement besoin d'un autre X, et donc un autre bon de commande est généré et une autre commande est passée. En dehors de cela, même si vous ne sur-commandez pas accidentellement, vous perdez rapidement la trace de ce que vous avez.

Supposons que X est une pièce d'équipement complexe, peut-être une ligne de remplissage-finition. Il se compose de 20 composants principaux, qui seront tous remplacés plusieurs fois au cours de sa durée de vie. Une étiquette d'inventaire collée au hasard sur une partie de X disparaîtra à cause de l'usure. Pire encore, l'étiquette d'inventaire peut même ne pas être appliquée car elle n'atteint pas la réception à temps. Après cela, personne ne sait comment suivre X, et donc aucune idée de comment le déclasser en fin de vie. D'un point de vue fiscal, X est toujours un élément imposable fonctionnel.

Au cours de plus de 20 ans, cela commencerait à nuire au résultat net d'une manière non négligeable. De plus, Finance utilise une partie de son système ERP avec un ensemble de désignations d'actifs, tandis que Manufacturing utilise un module ERP totalement séparé avec un ensemble différent de désignations d'actifs. À la fin de l'année, personne ne peut concilier les deux ensembles de chiffres, et les vérificateurs se demandent pourquoi vous avez des dizaines ou des centaines de millions de dollars d'écart concernant vos biens d'équipement.

Ce sont des problèmes classiques résultant d'un ensemble de processus métier en boucle ouverte. La boucle ouverte est lorsque vous n'intégrez pas de points de confirmation explicites le long de la ligne de flux de processus. Dans l'exemple ci-dessus, il y avait tellement de processus en boucle ouverte que l'échec était garanti.

Création de flux d'informations bidirectionnels

Voici comment nous avons abordé le problème. Nous avons modélisé chaque flux de processus significatif du début à la fin. Nous avons identifié toutes les boucles ouvertes. Ensuite, nous avons conçu des moyens simples de fermer ces boucles, une à la fois, en commençant par le tout début.

La première étape

La fabrication a besoin de X, elle demande donc aux finances d'ouvrir un bon de commande. Le service des finances vérifie maintenant auprès de la fabrication pour confirmer, en fournissant des détails sur les commandes précédentes pour X remontant à 24 mois. La duplication accidentelle des commandes est évitée.

Deuxième étape

La fabrication fournit aux finances une ventilation des composants de X qui seront remplacés pendant la durée de vie. Les finances créent des étiquettes d'inventaire pour chaque composant et confirment avec la fabrication. Les deux modules ERP sont remplis avec des balises d'actif correspondantes par composant, permettant un suivi tout au long du cycle de vie de l'actif.

Troisième étape

La réception notifie Finance, qui notifie Fabrication. Le placement des étiquettes d'inventaire est effectué par une partie responsable de la fabrication pour s'assurer que chaque étiquette est placée sur son composant correct. Toutes les balises/composants sont ensuite reconfirmés pour les deux modules ERP.

Étape 4

Chaque fois qu'un composant est échangé, la fabrication informe les finances, et une nouvelle étiquette d'inventaire pour ce composant est générée et placée sur le nouveau composant par la fabrication, puis confirmée dans les deux modules ERP. Les finances commencent alors le processus de suppression de l'ancien composant des livres tandis que la fabrication passe par le processus de déclassement du guide des bonnes pratiques (GMP). À la fin du démantèlement, la fabrication informe les finances afin que l'actif puisse être retiré des livres.

Les détails sont un peu plus complexes que cet exemple simplifié, mais le point est clair : à chaque étape de la route, il y a des vérifications et des confirmations explicites.

Assurer les actions d'urgence

Dans un autre projet, on m'a demandé d'aider une société de services à améliorer son taux de satisfaction client. Leur activité était axée sur le traitement des réclamations et ils craignaient de ne pas remporter les offres. De plus, dans leurs offres gagnantes, le mécontentement ultérieur des clients signifiait que leur ratio de comptes perdus était trop élevé.

Il n'a fallu que quelques jours pour identifier le cœur du problème, qui était encore une fois les processus en boucle ouverte. Lorsqu'un prospect demandait une offre, le gestionnaire de compte utilisait son système interne pour envoyer un aperçu des exigences du client à la personne responsable de l'assemblage de l'offre. Le créateur de l'offre créerait alors l'offre et la transmettrait au client. Espérons que le client finira par répondre, généralement avec les modifications souhaitées, que le créateur de l'offre intégrera dans la prochaine version. À un moment donné, le client accepterait l'offre et un nouveau compte client serait créé par la comptabilité, une facture serait émise et l'équipe d'intégration informée.

Le premier problème était qu'il n'y avait pas de confirmation explicite du créateur de l'offre au gestionnaire de compte, donc parfois les offres n'étaient pas créées et envoyées à temps, et personne ne le savait. Cela était possible parce que le système interne n'avait pas de champ pour afficher une date d'échéance pour une offre, et comme le créateur de l'offre était perpétuellement surchargé, cela entraînait la soumission des offres trop tard. En raison d'une mauvaise circulation de l'information dans l'entreprise, ces situations ne se sont jamais présentées.

Par la suite, les modifications de l'offre n'ont pas été transmises au gestionnaire de compte. C'était important car c'était le gestionnaire de compte qui informait l'équipe d'intégration lorsqu'un client signait finalement sur la ligne pointillée. Souvent, le brief était basé sur la compréhension initiale du gestionnaire de compte plutôt que sur l'offre que le client avait effectivement acceptée.

Une fois l'engagement commencé, les documents des clients arrivaient et étaient transmis au membre de l'équipe du pool de traitement qui avait été chargé cette semaine-là de les traiter. Comme il n'y avait pas de confirmation explicite de réception, il était possible que des documents disparaissent sans que personne ne le sache, jusqu'à ce que le client commence à demander pourquoi il ne recevait pas les résultats du travail de traitement.

Lorsque les documents traités étaient renvoyés au client, il n'y avait aucune confirmation à la réception, de sorte que tous les documents manquants étaient perdus de vue jusqu'à ce que quelqu'un, quelque part, commence à se plaindre de leur absence.

Confirmer les événements clés

À chaque étape du processus d'appel d'offres, nous avons intégré des confirmations explicites. Nous avons créé des solutions de contournement pour les lacunes du système afin que toutes les informations critiques soient capturées, y compris la date requise par et les modifications ultérieures de l'offre. Nous avons mis en place des vérifications et des confirmations explicites pour tous les flux d'informations dans les affaires au sein de l'entreprise, et entre l'entreprise et le client.

Par exemple, lorsqu'un client envoyait un ensemble de documents, il envoyait désormais un e-mail au responsable du compte client pour l'en informer. Le gestionnaire de compte client le transmettra à la partie responsable du traitement des réclamations. Si les documents n'étaient pas reçus dans les trois jours, une alerte serait déclenchée. Lorsque les documents ont été reçus, un e-mail a été envoyé au client confirmant la réception. L'inverse était également vrai lorsque l'entreprise renvoyait les documents traités au client.

Comme la plupart des clients utilisaient le courrier américain pour déplacer des documents papier dans les deux sens, des processus en boucle fermée utilisant des vérifications explicites à chaque étape signifiaient que tout document perdu pouvait être rapidement identifié et que des mesures étaient prises pour rectifier la situation.

Concevoir des procédures de gestion des exceptions

Pour voir comment les procédures de gestion des exceptions peuvent être construites de manière raisonnablement légère mais efficace, nous allons examiner un autre exemple concret que j'ai rencontré dans ma carrière lorsque j'étais directeur informatique d'une organisation de recherche scientifique axée sur l'étude des causes de le vieillissement et les déclencheurs des maladies liées à l'âge.

Tous les instituts de recherche financés par les NIH contiennent de nombreux laboratoires individuels, chacun dirigé par un chercheur principal (PI) et doté de divers scientifiques et post-doctorants subordonnés. À un moment donné, le PI a besoin d'un nouveau plateau de réactifs multichambres, il demande donc à l'un des post-doctorants de créer la demande nécessaire. Le post-doctorant crée la demande et l'envoie par e-mail aux Finances pour demander qu'un bon de commande soit émis, en mettant en copie le PI pour s'assurer que le PI est au courant que la demande a été envoyée. Pendant ce temps, le PI dispose d'une notification de calendrier automatique pour lui rappeler de vérifier l'état de la demande s'il n'a pas reçu de confirmation à une certaine date. Cela garantit un mécanisme de sécurité au cas où le post-doc oublie de créer ou d'envoyer la requête nécessaire.

Désormais, le post-doctorant dispose également d'une notification de calendrier automatique pour vérifier auprès des finances s'il ne reçoit pas la confirmation que le bon de commande a été émis dans un délai défini. Lorsque Finance soulève le bon de commande, le post-doc reçoit un e-mail confirmant qu'il a été envoyé au fournisseur, et le post-doc transmet cette confirmation au PI.

À ce stade, le PI ou le post-doc définit une autre notification de calendrier automatique pour s'assurer que si aucune réponse n'est reçue du fournisseur dans un délai défini, quelqu'un vérifie auprès du fournisseur pour s'assurer de la réception du bon de commande et de l'envoi du bon de commande. matériel qui a été commandé.

En supposant que le fournisseur accuse réception du bon de commande et expédie l'article avec une notification d'expédition, celle-ci est acheminée vers le PI ou le post-doc. Ils définissent ensuite une notification de calendrier finale pendant trois jours après la date de réception prévue afin de s'assurer que si l'article ne se présente pas, ils savent contacter le fournisseur pour suivre ce qui s'est passé et faire livrer l'article correctement. Si l'article arrive comme prévu, le post-doc informe les finances, et si l'organisation utilise des étiquettes d'inventaire, cet ensemble de processus peut être lancé.

À chaque étape du processus, une confirmation explicite est requise et un sous-processus est disponible pour s'assurer que des mesures correctives sont prises si le flux de processus principal est interrompu. Rien n'est laissé en suspens, non confirmé ou non pris en charge. Aucune action ad hoc n'est requise car tout le monde sait ce qui est requis et ce qu'il faut faire si les choses tournent mal.

Apprendre à créer des processus en boucle fermée à partir de SQL

L'essence d'un bon processus est très similaire à la manière dont les bases de données relationnelles basées sur SQL ont été conçues pour assurer la cohérence transactionnelle. Toute action doit être confirmée pour être considérée comme terminée. Toutes les communications bidirectionnelles nécessitent une confirmation explicite intégrée dans le cadre du processus, et des processus subordonnés développés pour garantir que si la confirmation n'est pas reçue, l'action correcte est prise. Les chefs de projet qui réussissent doivent créer des processus en boucle fermée pour améliorer le flux d'informations dans une entreprise et faire économiser beaucoup de temps et d'argent aux organisations.