De nombreuses erreurs peuvent donc survenir lorsqu’un processus est morcelé entre les unités. Ces erreurs peuvent découler d’exceptions aux situations normales. Dans cette situation, les personnes à l’extérieur de l’organisation ne sont pas nécessairement au courant des erreurs. Ainsi, une fois enclenchée, le processus est quasiment perdu dans l'organisation, jusqu'à ce que le processus soit terminé et qu’un produit final soit livré ou un résultat déterminé.

L'amélioration d'un processus, lorsqu’il est fragmenté entre plusieurs groupes, est souvent difficile car l’amélioration devrait remonter et ensuite redescendre la voie hiérarchique. Donc il y a beaucoup d'occasions pour une amélioration de tomber à l'eau, si elle ne provient pas de la haute direction. Selon [HAMM 2001], la réingénierie correspond à la réinvention des façons de faire des affaires. Cela ne correspond pas à la simple modification ou à l'amélioration des processus d'affaires. Lorsqu’on recherche des améliorations de l’ordre de 10% on peut employer la modification ou l'amélioration. La réingénierie est un changement plus radical qui devrait fournir des augmentations de productivité de l’ordre de 50 à 100%. Ainsi la réingénierie est révolutionnaire et non pas évolutionnaire.

Les organisations sont divisées en unités. Elles ne sont pas divisées selon leurs processus d’affaires. Dans un grand nombre d’organisations il existe un département des finances, mais il n’existe pas de processus des finances. Par contre :  Facturer le client et obtenir le paiement , est un processus. Il ne faut pas voir les processus d’affaires comme une invention théorique, mais une réalité.

Dans leur ouvrage Hammer et Champy expliquent qu’il faut avoir des processus simples, même s'il faut accepter des tâches plus ardues. Cette vision s’oppose à celle de l’économiste anglais du 18^ème siècle, Adam Smith selon lequel il faut avoir des tâches simples même si cela implique des processus complexes pour lier toutes ces tâches ensembles. Smith voyait dans la spécialisation et la simplification des tâches un moyen de décupler la productivité. Contrairement à Adam Smith, Hammer et Champy considèrent qu’une organisation doit avoir des processus simples même si cela implique des tâches complexes et un personnel très qualifié.

Pour Hammer et Champy : la vérification, la réconciliation, les temps d’attente, la surveillance et le contrôle sont du travail improductif qui existe à cause des barrières ou frontières dans une organisation. Ce travail est nécessaire pour compenser la fragmentation des processus et serait éliminé par une réingénierie efficace. Ceci permet ainsi aux gens de se concentrer sur le travail vraiment productif.

La réingénierie des processus d’affaires s’effectue sur des processus qui sont inefficaces. On peut choisir les processus à réformer selon les critères suivants :

[HAMM 2001] identifient sept types de changement qui sont censés résoudre la fragmentation :

Ces solutions peuvent être mises en œuvre si on peut déléguer ou modifier les rôles, droits et privilèges des participants. Si ces solutions sont censées être soutenues par des outils informatiques alors la question des droits d’accès est essentielle. La réingénierie est liée à la possibilité de modifier rapidement et efficacement les droits, rôles ou privilèges d’accès.

La réingénierie des processus d’affaires n'est pas une panacée. Pour [HAMM 2001] elle implique un travail rigoureux et des sacrifices. Les responsables de la réingénierie affrontent souvent de la résistance chez les employés. Cette résistance est normale. Certaines personnes peuvent ou vont perdre leur emploi à cause d’une réorganisation radicale du travail. Il ne faut pas essayer de réaliser la réingénierie sans mécontenter certains. C'est une erreur. Satisfaire tout le monde va soit dévaluer l'efficacité du programme de réingénierie soit retarder sa mise en oeuvre dans le temps. Il est inexact de dire qu’un projet de réingénierie a échoué parce que les employés ont résisté au changement. Un projet échoue parce que le niveau de résistance n'a pas été correctement géré.

Enfin, les auteurs ne détaillent pas les difficultés qui peuvent surgir du fait qu’une organisation peut ne pas avoir la maturité nécessaire pour effectuer correctement des opérations requises et choisir correctement des processus optimums. Une entreprise doit avoir la capacité de mesurer l’efficacité de ses processus et de sa gestion. Cela implique de la part de l’organisation, un haut niveau de maturité CMM. Selon le SEI (Software Engineering Institute) il est hasardeux d’entreprendre des projets qui requièrent un niveau CMM supérieur à celui que maîtrise l’organisation. Il existe cinq niveaux CMM. Généralement, passer d’un niveau à un autre dure un an et ce n’est qu’au niveau cinq qu’une organisation a la maturité nécessaire pour réussir une « amélioration » de ses processus. Une étude [JUNG 2003] du SEI vient confirmer cette thèse avec des preuves rigoureuses et chiffrées. Dans son étude [JUNG 2003] démontre un lien entre efficacité de la gestion de la maintenance logicielle et maturité CMM de l’organisation.

L’intégrité des processus vérifie :

[HAMM 2001] établissait dans son ouvrage la notion de propriétaire de processus et distinguait les personnes « responsible » et « accountable ».

C'est-à-dire qu’il peut exister une personne responsable des résultats d’un processus même si d’autres gèrent les tâches qui font parti de ce processus. Cependant Hammer et Champy se concentrent uniquement sur la productivité de l’entreprise face à sa clientèle. D’autres enjeux devraient influencer les processus d’affaires.

[TCHO 2002] spécifie que la vérification de l’intégrité des nouveaux processus se termine par l’acceptation formelle « Sign-off » et écrite par les responsables de processus, et des vérificateurs avant d’officialiser ces processus. Lorsqu’un logiciel professionnel commercial est acheté par une organisation, c’est l’organisation qui doit s’adapter au système et non l’inverse. Dans ce contexte une étape formelle de validation de test et d’acceptation des nouveaux processus par leurs propriétaires prend tout son sens. Cette étape d’acceptation prépare l’entreprise à l’arrivée de nouveaux systèmes informatiques.

Quelques leçons tirées de l’expérience de Pratt et Whitney [TCHO 2002] méritent d’être mentionnées.

Il faut gérer la quantité de réingénierie. Cela signifie qu’il faut maximiser la concordance avec les processus d’affaires du système informatique. Pour autant, il ne faut pas chercher une concordance parfaite et absolue avec les processus d’affaires du système informatique. Si une solution est jugée satisfaisante elle n’a pas besoin d’être optimale. En effet, si trop d’exceptions sont analysés, ces exceptions peuvent compromettre le projet. Il faut éviter de consacrer toutes ses ressources à des exceptions marginales.

L’acceptation des nouveaux processus par les propriétaires de processus devrait être une étape formelle et écrite. Les propriétaires devraient signer un document affirmant que les nouveaux processus sont intègres et qu'ils peuvent et seront suivis.

Ce système est renforcé par le pouvoir hiérarchique qui s'exerce du supérieur hiérarchique vers le subordonné. Ce pouvoir comporte trois éléments : le pouvoir d'instruction (faculté dont dispose le supérieur de fixer à l'avance, pour le subordonné, la manière dont il devra agir), le pouvoir de réformation (consiste dans les faits, pour le supérieur, de modifier éventuellement les décisions prises par le subordonné), le pouvoir disciplinaire (pouvoir de noter les subordonnés et de les sanctionner en conséquence).

Sur un plan pratique, les organisations centralisées ont peu de chances de fonctionner sur un territoire étendu. Tout en restant dans la centralisation, on peut persister dans l'idée qu'il faut maintenir une centralisation très forte (concentration) ou l’atténuer par la déconcentration.

Ces représentants n'auront pas besoin d'attendre le feu vert de la haute direction, car ils disposent d'une compétence discrétionnaire d'appréciation. L'avantage de ce découpage est une meilleure adaptation de la décision à la situation que l'on veut régler, car le responsable local peut avoir une connaissance plus concrète et plus précise que celle que peut avoir la haute direction. En d’autres termes « on peut gouverner de loin mais on n'administre correctement que de près. » Les responsables locaux reçoivent toujours des instructions de leur supérieur et peuvent être sanctionnés (car placés sous l'autorité hiérarchique) mais ils disposent d'une marge de manoeuvre intéressante.

D’après [LANG 1998], le coût du projet euro était estimé à :

Plus précisément, les coûts du projet Euro pour les banques, estimés à 2 % des coûts d'exploitation pendant 3 ans, étaient répartis avec les pourcentages suivants :

Il est intéressant de noter que le projet de changement des systèmes informatiques pour le passage à l’euro était particulier car il avait un impact sur l’intérieur et l’extérieur des entreprises. Le changement à l’euro affectait les transactions comptables et budgétaires et affectait la stratégie de marketing et de publicité des organisations. Les applications internes de l’entreprise, tels que des applications comptables ou applications de marketing, ne sont pas connues du grand public. Mais, pendant la migration à l’euro, les clients de ces organisations étaient affectés puisque les prix des articles changeaient. Le changement informatique pour s’adapter à la monnaie européenne affectait donc toutes les unités de l’organisation.

Il faut bien entendu nuancer le modèle et les chiffres présentés. Tout d’abord ils ne sont pas justifiés par des recherches rigoureuses, ni confirmées dans la pratique par l’auteur. En effet, le livre date de 1998, et le passage à l’euro a eu lieu en 2002.

Le projet Gires devait remplacer deux systèmes patrimoniaux SAGIP et SYGBEC et implanter un logiciel professionnel à travers tous les ministères. Le budget du projet Gires a été initialement estimé à 84 millions de dollars canadiens. Cette première évaluation ressemble au modèle énoncé dans [SCHE 2000], soit 14 millions pour la licence, d’après [LYRE 2003] et 5 x 14 millions pour les coûts de déploiement, pour un total de 84 millions. Cependant le modèle de [SCHE 2000] ne tient pas compte de l’état du système patrimonial particulièrement archaïque du gouvernement du Québec. Le système patrimonial SAGIP et SYGBEC constituaient le point de départ du projet du projet et influait sur les coûts du projet. Les systèmes SAGIP et SYGBEC étaient programmés en Cobol et assembleur, et les bases de données de ces systèmes reposaient sur des serveurs locaux VSAM et DB2. Les serveurs étaient des ordinateurs centraux IBM. SAGIP employait le SGBD M204. Cette technologie matérielle et logicielle était très ancienne et difficile à maintenir.

En 2003, le projet Gires fut interrompu avant d’être étendu à tous les ministères pour des raisons de dépassement important de budget. Dressons un parallèle entre l’estimation des coûts du projet euro du livre de Marc Langlois [LANG 1998], avec les coûts du projet Gires du gouvernement du Québec. L’estimation des coûts moyens du projet euro correspondait à 1% du chiffre d’affaires pour les entreprises. Selon le site officiel du ministère du trésor [TRES 2004], le budget annuel du gouvernement du Québec est de l’ordre de 50 milliards $ pour le budget de dépenses 2003-2004. L’application de l’estimation indique que le projet Gires aurait pu coûter 1 % de 50 milliards : soit 500 millions de dollars canadiens.

En septembre 2003 un rapport indépendant rédigé à la demande du gouvernement du Québec [LYRE 2003] analysait l’état du projet et l’avancement des travaux en faisant des recommandations. Le rapport déterminait que :

[HAMM 2001] mesure la valeur ajoutée à l’entreprise par la réingénierie des processus d’affaires. Pour ces auteurs, tout processus et son amélioration ne doivent pas être mesurés d’après les tâches réalisées par l’usager d’un système, ils ne peuvent être mesurés que par les bénéfices apportés au client. Une analyse des tâches d’un usager est très spécifique et ne donne qu’une information fragmentaire et qui ne peut être comprise que par l’organisation, pas par le client. Par exemple, réaliser une soudure est une tâche qui en soi n'a de valeur que pour l’organisation, alors que produire une voiture suit un processus qui crée de la valeur pour le client de l’organisation.

La vision de [HAMM 2001] se concentre exclusivement sur les clients de l’organisation. On pourrait la nuancer en indiquant qu’une migration logicielle qui améliorerait le fonctionnement des processus d’une organisation vis-à-vis d’une entité externe apporte de la valeur ajoutée : que ce soit un client, un fournisseur ou le gouvernement.