CAS ARROW
Le cas Arrow
Adaptation de parties de l’article de:
Kettinger, William J., Guha, Subashish et Teng, James T.C. The Process Reengineering Life Cycle Methodology: A Case Study. Business Process Change(1995): 211-244
Le cas ARROW SYSTEMS INC. – L’étape de la vision
Arrow Systems, un important manufacturier de logiciel avec une clientèle globale et un but d’équilibre entre la satisfaction de la clientèle et l’efficacité en matière de coûts (cost efficiency), était préoccupé du délai de livraison et des coûts de développement de ses nouveaux produits.
En particulier, monsieur White, leur vice-président senior au marketing et à la planification du produit, était las des plaintes de la clientèle et particulièrement du temps requis pour lancer de nouvelles versions de logiciels. Il discuta du problème avec madame Black, la VP des systèmes d’information; celle-ci avait lu sur la réingénierie des processus d’affaires (RPA) et lui indiqua que la réingénierie pouvait être un moyen efficace de traiter ces problèmes. Ensemble, ils
persuadèrent le PDG de créer un groupe de gestionnaires de haut niveau pour discuter des opportunités de RPA. On décida d’engager monsieur Bose, un consultant en réingénierie très renommé, pour conduire un séminaire sur la RPA auquel participèrent des représentants de la haute gestion des départements, incluant ceux de la planification de la production, du génie logiciel, de l’assurance de la qualité, du soutien à la clientèle, de la documentation technique, des systèmes d’information et de la comptabilité. La rétroaction des participants fut positive et, en conséquence, monsieur Bose a été engagé pour guider plus avant les efforts de RPA.
Les membres du séminaire furent réinvités pour commencer à identifier des processus candidats pour la RPA. Ce groupe décida qu’une étude complète de tous les processus corporatifs devait être entreprise. Monsieur Bose leur indiqua que cela pouvait être une entreprise longue et pénible, mais avait l’avantage d’être exhaustif. Toutefois, un mois et huit réunions plus tard, le groupe réalisa qu’il n’avait ni le temps, ni la patience pour faire un examen détaillé de tous les processus de la firme. Monsieur Bose, reconnaissant l’ambivalence du groupe envers le niveau de travail requis, recommanda qu’une stratégie ciblée d’identification des processus soit plutôt choisie. Après quelques sessions de remue-méninges (brainstorming), la haute gestion décida que, compte tenu du risque en cause, le processus d’assurance de la qualité (AQ) offrait les plus
grandes possibilités d’améliorations de la satisfaction de la clientèle, du temps de cycle et de l’efficacité reposant sur les coûts. La décision fut en partie appuyée sur la discussion qu’avait faite madame Black des opportunités d’utilisation des technologies clients-serveur, de collecticiels et de l’orientation objet dans un processus de réingénierie de l’assurance qualité.
Monsieur Jones, le Vice-Président de l’assurance qualité corporative, et un des participants à ces réunions, était d’accord pour désigner le processus d’assurance qualité comme un bon candidat pour la RPA. En particulier, il indiqua que quelques-unes des unités reliées à l’assurance qualité posaient des problèmes de contrôle et que le temps de livraison des produits était trop long. Il était aussi préoccupé du fait que les niveaux de dotation et les coûts indirects étaient hauts et qu’il semblait y avoir duplication d’efforts. À la recommandation de monsieur Bose, la haute gestion accepta les paramètres de projet ci-dessous :
Projet sélectionné :
● Le processus d’assurance qualité – la décision fut prise d’étudier et de piloter un projet de reconception de processus dans une des unités d’affaires, celle des logiciels de bureau et de groupe. Une fois le succès de ce projet pilote atteint, le nouveau design de processus pourrait être implanté dans d’autres unités d’affaires.
Alignement avec la stratégie corporative
● Le processus d’assurance qualité devait faire l’objet d’une réingénierie pour améliorer le délai de livraison et la qualité ainsi que pour réduire les coûts.
Opportunités technologiques utilisées
·La technologie client-serveur et une base de données distribuée.
·Les technologies d’automatisation des flux de travail et de traitement des formulaires.
Le cas ARROW SYSTEMS INC. – L’étape de l’inauguration
Monsieur Jones, responsable du processus (process owner), organisa une équipe de RPA composée de personnes connaissant les procédures et politiques de l’assurance qualité (AQ). Il tenta de sélectionner des membres qui étaient hautement créatifs et possédaient de fortes capacités d’analyse. Monsieur Chang, un gestionnaire d’une section de l’assurance qualité, fut choisi comme chef de projet senior. Madame Black, qui voulait s’assurer que ce premier projet de réingénierie soit un succès, recommanda cinq de ses meilleurs employés des systèmes
d’information (SI) comme membres de l’équipe. La première tâche de l’équipe était de préparer un plan de projet et de formaliser les objectifs de performance qui seraient la base de l’effort de RPA et de l’évaluation subséquente.
Équipe de RPA:
·Champion de la RPA :Monsieur White, VP senior, marketing et planification de produit
·Responsable du processus (owner):Monsieur Jones, VP, assurance-qualité
·Consultant en RPA:Monsieur Bose
·Personnel de l’AQ et d’autres secteurs fonctionnels (par exemple : la certification des produits, le soutien à la clientèle)
·Chef du projet de réingénierie:Monsieur Chang, gestionnaire de section, assurance- qualité
·Spécialistes des SI :Un planificateur de système, un spécialiste de la technologie, trois analystes d’application
·Spécialiste des ressources humaines Objectifs de performance :
·Réduire le temps de cycle et les défauts de 40%.
·Réduire les coûts de main-d’œuvre de l’AQ de 25%.
·Améliorer la satisfaction de la clientèle au sujet des produits livrés.
·Intégrer les processus au moyen d’un accès à l’information et d’une génération de rapports améliorés.
Le cas ARROW SYSTEMS INC. – L’étape du diagnostic
Monsieur Chang et l’équipe de RPA conduisirent quelques réunions avec le personnel de l’assurance-qualité (AQ) pour documenter les flux de travail des activités existantes. L’équipe détermina que les six sous-processus de l’AQ étaient : le contrôle de la version et la compilation du code, le test de système, les demandes de changement de module, la certification de produit, le déploiement à la clientèle (voir figure 2). Un rapport détaillé incluant des diagrammes de flux (flowcharts ou ordinogrammes) du processus fut développé par les membres de l’équipe des SI décrivant toutes les activités du début à la fin.
En se basant sur la modélisation des processus, le processus existant fut représenté
graphiquement, incluant les intrants, les extrants, les contrôles, les ressources et le indicateurs de performance. On trouva que chaque sous-processus avait son propre système autonome (stand- alone) et que des standards de performance ne reposaient pas sur des critères relatifs à
l’ensemble du processus. Le résultat était que chaque sous-système traitait une quantité excessive de paperasse et dupliquait l’information.
En utilisant des techniques comme l’analyse Fishbone, l’équipe identifia comme un problème majeur le délai de traitement durant la certification du logiciel, préalable au lancement du produit.
On trouva que l’information était réentrée manuellement afin de compléter plusieurs formulaires standards requis par le comité des standards du siège social. En fait, 90% de l’information utilisée dans le sous-processus de certification des produits était dédoublée (c’est-à-dire réentrée).
Plusieurs problèmes simples qui auraient pu être résolus en partageant l’information à des
niveaux inférieurs remontaient à des niveaux supérieurs de gestion, causant des délais additionnels. Deux niveaux d’autorisation furent identifiés comme des goulots d’étranglement majeurs. Par exemple, un développeur de logiciel se plaignait du fait que « cela ne prend qu’une demi-heure pour compiler la correction à mon logiciel, mais les gestionnaires sont toujours en réunion et cela me prend une demi-journée pour obtenir finalement leurs approbations ».
Pathologies:
·Des sous-processus non reliés.
·Un manque d’information partagée pour supporter les décisions autonomes.
·Des autorisations longues et rigides pour certifier des formulaires.
·Une dépendance excessive envers des activités manuelles et séquentielles causant des délais.
·Des signatures et des autorisations de formulaires inutiles.
·Trop de temps consacré dans le transfert d’information plutôt que dans des activités à valeur ajoutée.
·Le manque de rétroaction directe de la clientèle versus la vérification de la qualité.
Le cas ARROW SYSTEMS INC. – L’étape de la reconception (redesign)
Monsieur Chang convoqua une réunion de l’équipe de RPA. Sur la table, ils placèrent les
diagrammes de processus, les modèles de processus, et la liste des pathologies de processus.
Monsieur Bose défia l’équipe de « repenser le processus à partir de zéro, pas seulement de faire des modification mineures au processus existant, mais d’atteindre des objectifs extrêmes
(stretch)». L’équipe fit du remue-méninges sur quelques reconceptions alternatives. Les exigences de la clientèle tant interne (entre sous-processus) qu’externe furent évaluées pour chaque design de processus. Une des options considérées était de développer des groupes auto- gérés d’assurance-qualité des produits, chacun étant responsable d’un produit spécifique du début à la fin. Madame Black et le spécialiste de la technologie recommandèrent d’utiliser un collecticiel pour améliorer le partage de l’information et pour automatiser les activités manuelles.
Une seconde alternative utiliserait des groupes interdépendants et intégrerait les sous-processus dans un processus d’AQ plus intégré. Cette approche permettrait l’élimination de quelques
niveaux d’autorisation et la réduction du personnel clérical occupé à des tâches manuelles.
À la suite des discussions, la seconde alternative sembla la meilleure solution parce qu’elle
mènerait le design à un processus très intégré. Le point focal de cette alternative était d’améliorer la satisfaction de la clientèle et l’efficacité. En se basant sur une recommandation de monsieur Bose, l’équipe de RPA utilisa des techniques de simulation pour analyser les deux designs alternatifs du processus. La simulation sembla confirmer l’analyse précédente de l’équipe,
démontrant que la seconde alternative mènerait à une livraison de produit accélérée, un temps de cycle interne réduit, moins de défauts et la réduction des coûts.
Un diagramme de haut niveau du processus re-conçu est présenté à la Figure 3. Les clients externes seraient liés aux sous-processus d’entretien et de requêtes de changement en développant un tableau d’affichage en ligne (BBS) contrôlé au siège social.Le personnel de
l’entretien et des requêtes de changement ne feraient donc plus seulement l’entretien et la
recommandation de nouvelles caractéristiques, mais interagiraient aussi avec les clients pour les ventes et le service à la clientèle. En utilisant une architecture client-serveur avec une base de données en ligne, ce design améliorerait le partage d’information et augmenterait les activités simultanées à l’intérieur de chaque sous-processus. Le design permettrait l’intégration de certains sous-processus. Par exemple, les processus de contrôle de version et de compilation de code ainsi que de test de systèmes seraient consolidés en un sous-processus et les membres du groupe auraient le pouvoir d’autoriser des tâches allant de la compilation de modules au test de systèmes. Ce design unifié de processus d’AQ permettrait à l’information d’être capturée au point d’entrée dans le processus. Le traitement des formulaires seraient entièrement en ligne et
distribué en utilisant l’automatisation du flux de travail.
Un prototype du système de flux de travail de type client-serveur fut testé en utilisant trois clients liés au serveur de flux de travail et de base de données. Messieurs Bose et Chang ont interviewé les usagers pour générer les règles et les interfaces graphiques et aussi pour déterminer
l’acheminement et la distribution des formulaires nécessaires dans le réseau. Une démonstration du prototype fut donnée initialement à monsieur Jones et madame Black et d’autres gestionnaires senior, puis au personnel de l’AQ. La gestion était heureuse des données sur l’amélioration de la performance et a approuvé le nouveau design de processus. Monsieur Jones réalisa que, en plus des habiletés techniques, les traits personnels comme la créativité, la flexibilité et la capacité de prendre des décisions étaient d’une extrême importance pour le choix des employés du nouveau processus intégré d’AQ. En se basant sur ces traits, monsieur Jones sélectionna les membres du personnel de l’AQ pour les nouveaux sous-processus (Compilation de code et test de système, Entretien et demande de changements et Certification).
Design alternatif:
·Alternative 1 : Des sous-processus indépendants reposant s sur les produits et utilisant des équipes auto-gérées.
·Alternative 2 : Un processus intégré utilisant des sous-processus interdépendants et des groupes inter-fonctionnels.
Nouveau design de processus (alternative 2 choisie):
·Un processus unique avec des groupes en interaction conduisant des activités
simultanées, intégrant quelques sous-processus et utilisant des groupes inter-fonctionnels pour réaliser les sous-processus.
·Élimination de l’entrée manuelle des formulaires et des approbations superflues.
Architecture des ressources humaines:
·Réduction des niveaux hiérarchiques et du nombre de niveaux d’autorisation.
·Moins d’emphase sur la spécialisation des tâches et plus sur l’objectif global du
processus de satisfaction du client.
Plate-forme de TI
·Utilisation d’une base de donnée en ligne dans une architecture client-serveur pour permettre le partage d’information et éliminer la redondance des données.
·Utilisation de l’automatisation des flux de travail et d’un logiciel de génération de
formulaires pour acheminer, distribuer et compléter des formulaires électroniquement et mettre à jour l’information dans la base de donnée d’un serveur central.
·Utilisation d’un progiciel 4GL pour automatiser les formulaires de certification et utiliser l’information disponible dans la base de données du serveur pour générer
automatiquement tous les formulaires de certification.
Le cas ARROW SYSTEMS INC. – L’étape de la reconstruction
La nouvelle de l’approbation du processus re-conçu et de la réorganisation prévue se répandit rapidement dans la « machine à rumeur » de l’organisation. Monsieur Jones, anticipant les appréhensions du personnel autant que leur excitation, trouvait qu’il était nécessaire d’apaiser leurs peurs et de diriger leurs énergies de façon positive. Il invita les 42 membres du personnel du département (30 professionnels de systèmes et 12 employés cléricaux) à une réunion et expliqua candidement les objectifs, bénéfices et impacts du nouveau design de processus sur chacun d’eux. Monsieur Jones rassura les 10 employés (huit employés cléricaux et deux professionnels) dont les positions seraient éliminées, leur disant qu’ils auraient la plus haute priorité de
replacement dans des postes vacants de l’organisation. À cause des changements dramatiques qui se produiraient avec la reconception et du fait que la satisfaction de la clientèle était en jeu, le nouveau processus serait introduit graduellement.
Messieurs Chang et Bose lancèrent un programme d’éducation exhaustif avec les trois nouveaux groupes d’AQ, couvrant leurs nouveaux rôles et responsabilités. Pour supporter cet effort, le département des ressources humaines développa un atelier sur mesure sur la création d’équipes (team-building) qui mettait l’accent sur l’orientation des employés à être leur propre patron et à briser les habitudes. Cela était fait en espérant que les employés agiraient de façon plus
autonome et se réorienteraient vers l’accomplissement des objectifs du processus commun. De plus, le département des ressources humaines travailla étroitement avec monsieur Jones pour concevoir un système d’évaluation de groupe qui récompenserait les employés en se basant sur des dimensions individuelles, de groupe ainsi que sur la performance du processus.
Les analystes d’application en Si assignés à l’équipe de RPA commencèrent à développer les interfaces graphiques, le design de la base de donnée, les applications de flux de travail et
l’architecture client-serveur globale pour le nouveau processus d’assurance-qualité. Cette fonction critique était guidée par un consultant, qui avait l’expérience du design de flux de travail. Au
moment où les TI furent installées, les employés commencèrent à jouer avec l’interface graphique et à mettre en application leur récente formation. Monsieur Chang utilisa l’assistance du groupe d’intégration des systèmes SI (GIS) pour installer le réseau local utilisant Ethernet et les
applications sur les serveurs et les clients. GIS installa la plate-forme Windows 3.1 sur chaque client et sur le serveur UNIX avec les applications de base de données et de flux de travail.
Chaque usager avait sur son ordinateur un ensemble d’icônes graphiques qui représentaient chaque fonction du système du processus re-conçu.
Durant la période d’implantation, monsieur Jones rencontra souvent son nouveau groupe d’AQ pour les informer, renforcer leur enthousiasme et soutenir leur moral. Durant ces réunions, monsieur Jones permettait à son personnel de discuter de leurs ressentiments, problèmes et préoccupations. Des discussions entre les groupes étaient encouragées pour faciliter la
coordination et la collaboration. Comme on avait donné aux groupes la propriété totale de leur sous-processus, ils commencèrent à être tenu responsables de l’atteinte des objectifs de performance et de la prise des actions correctives.
La période d’implantation ne s’est pas faite complètement en douceur. Après environ un mois, l’opération du nouveau processus commença à se stabiliser. La figure 4 représente le flux de travail du processus re-conçu. Le processus commence quand un développeur soumet du code électroniquement à l’assurance-qualité. Un développeur sélectionne l’icône de soumission de code qui affiche les formulaires électroniques. Une fois le formulaire complété et toutes les versions contrôlées et compilées avec succès, les modules exécutables sont soumis à des tests d’intégration de système. Les problèmes rencontrés durant les tests sont entrés dans le système de suivi des problèmes sur le serveur de base de données et de flux de travail. Les développeurs, le personnel de l’AQ et la gestion interrogent constamment cette base de données pour voir les solutions apportées au code et les problèmes non résolus qui doivent être réglés avant la
certification.
Une fois tous les critères des tests d’intégration de système rencontrés, les formulaires de certification sont automatiquement générés. Monsieur Jones approuve les formulaires de
certification et autorise l’offre du logiciel à la clientèle. Le logiciel est ensuite copié pour la livraison à la clientèle. Simultanément, le personnel de l’entretien et des demandes de changement
surveille le système de tableau d’affichage en ligne pour les plaintes des clients, les suggestions de nouvelles caractéristiques et le travail d’entretien. En se basant sur leurs commentaires, le personnel de l’entretien et des demandes de changement recommande de nouvelles fonctions et des changements de « pièces » ou « patchs » au groupe de développement des systèmes et le processus recommence. Le groupe des ventes et du marketing affiche aussi les ventes auprès de nouveaux clients sur le BBS, ce qui stimule le moral. De plus, des sondages en ligne sont
administrés périodiquement aux clients sur le BBS pour s’assurer d’une rétroaction continue.
Réorganiser:
·Informer les employés.
·Implanter progressivement.
·Des programmes d’éducation et des ateliers.
·Un système d’évaluation des employés reposant sur le groupe.
·Des réunions du groupe.
Déployer les TI:
● Développement de l’application.
● Implantation de l’architecture client-serveur.
·Installation des flux de travail et de la base de données.
Le cas ARROW SYSTEMS INC. – L’étape de l’évaluation
Évaluer la performance du nouveau processus avait une haute priorité. Les efforts d’évaluation se sont centrés sur la mesure du temps de cycle global, du taux de défaut, de la satisfaction de la clientèle et de la réduction des coûts. La base de comparaison du temps de cycle a été établie en utilisant les méthodes d’estimation pre-RPA de la compagnie, qui reposaient sur des données historiques. Après six mois, le temps de cycle moyen du nouveau processus (développement de nouveaux logiciels, délai de la commande à la livraison et entretien) a été calculé et comparé avec les données des anciennes mesures de comparaison. Monsieur Jones trouva une réduction moyenne du temps de cycle de 27%. Le taux de défaut fut déterminé en termes de nombre de problèmes, de plaintes de la clientèle et de « pièces » (patches) développées. Ici encore, en utilisant les données historiques, une réduction de 38% des défauts a été constatée. Avant la RPA, aucun canal formel n’existait pour recueillir la rétroaction de la clientèle. En utilisant le BBS, le processus re-conçu ramassa des mesures périodiques des perceptions de fiabilité du service, de qualité de l’interaction avec la clientèle et de qualité de réponse. Ces mesures ont montré une tendance mensuelle à la hausse. Les bénéfices en terme de productivité du travail ont été
déterminés en tant que résultat de la réduction initiale de personnel et de la diminution de temps de cycle. Des rencontres hebdomadaires du département de l’AQ ont été conduites pour évaluer l’efficacité du groupe, la formation inter-fonctionnelle et l’amélioration des compétences. Les membres du groupe ont établi un ordre de priorité des enjeux. Ces enjeux furent évalués par l’équipe de RPA pour déterminer si de nouvelles actions étaient nécessaires. En général, monsieur Jones constata des améliorations visibles de la motivation et de l’esprit de corps du personnel.
Les résultats du projet pilote de RPA furent complimentés par la haute direction. Le succès de la RPA du personnel de l’AQ fut documenté dans le bulletin interne et circulé pour servir de
paradigme pour la conduite d’autres RPA dans d’autres unités d’affaires de la firme. Peu après, une étude de l’ensemble de la corporation commença à identifier d’autres processus candidats.
Mesure de la performance:
·Réduction des coûts de main d’œuvre de 19%.
·Réduction du temps de cycle de 27%.
·Réduction des défauts de 38%.
·Augmentation continue de la satisfaction de la clientèle.
