Un court historique du BPM – Première partie

J’ai beaucoup discuté ces dernières semaines avec Sandy Kemsley, une de mes anciennes collègues chez FileNet, qui fait depuis pas mal d’années du BPM son quotidien. J’avoue que Sandy n’est pas pour rien dans l’histoire de ce blog car ses encouragements à continuer l’aventure me permettent de trouver de nouvelles sources d’inspiration pour écrire mes notes personnelles.
Si vous lisez régulièrement la chronique de Sandy vous n’êtes pas sans avoir remarqué qu’elle a entamé depuis quelques semaines une série de notes sur l’histoire du BPM et elle m’a gentiment invité récemment à réutiliser une partie de ce contenu et à l’adapter en français en y joignant mes propres commentaires. Comme je trouve l’idée plutôt sympa, j’ai décidé de m’y mettre et voici donc une nouvelle rubrique sur ce blog qui va regrouper les différentes notes pompeusement intitulées « Un court historique du BPM« . Je précise ‘pompeusement’ car je n’ai aucune prétention en la matière, c’est tout simplement l’envie de réfléchir sur ce qu’a été le BPM à ses débuts, ce qu’il est aujourd’hui et ce qu’il pourrait être dans un proche avenir qui me pousse dans ma démarche.

Bien évidemment tous vos commentaires sont les bienvenus et seront publiés, et je ne manquerai pas de corriger mes notes si vous avez un apport intéressant à faire. En ce qui concerne les textes, et afin de rendre à César ce qui appartient à Sandy, j’ai pris la liberté de citer en italiques le texte original de Sandy et d’y ajouter mes commentaires en caractères normaux.

Première partie: Au tout début

Au tout début il n’y avait pas de workflow. Pour être plus précis, on pratiquait le routage de documents dématérialisés de personnes à personnes en suivant un processus prédéterminé.

Pour autant que je sache, FileNet a été le premier éditeur à utiliser le terme « Workflow » dans ce contexte, dans les années 80 quand la société à débuté, même si elle a été rejointe rapidement sur ce créneau par IBM et quelques autres acteurs.
La plupart de ces systèmes workflow étaient alors centrés « documents », leur seule raison d’être étant de faire circuler un document dématérialisé – scanné, une image électronique donc – d’une personne à une autre afin que ces dernières puissent en traiter le contenu à l’aide de différentes applications, saisir des données liées à une transaction par exemple.

Je rajouterais même ici « au sein d’une seule et unique organisation », la notion d’échanges entre partenaires métiers au-delà des frontières du Système d’Information ne faisant pas partie des capacités des systèmes workflow à cette époque.

Cette étape découlait d’une certaine logique après que les organisations aient commencé à scanner leurs documents afin de les préserver et de les partager : en effet, pourquoi ne pas les scanner avant de les utiliser, et ensuite les faire circuler de façon électronique afin d’améliorer l’efficacité de l’organisation ? Malheureusement toute tentative d’intégration directe entre les différentes applications du Système d’Information et les systèmes workflow était forcément spécifique, couteuse et très peu flexible.

En fait nous avons là la raison initiale qui fait qu’aujourd’hui encore les outils de workflow soient divisés en deux grandes familles, les workflow de routage (ou Ad Hoc) et les workflow métier (ou d’Entreprise). Il n’en reste pas moins vrai que cela avait du sens à une époque où les applications critiques d’Entreprise reposaient majoritairement sur des systèmes centraux (mainframes) et où il n’était pas trop question de les porter sur des systèmes Unix comme on peut le voir aujourd’hui avec les ERP, les CRM et autres progiciels de gestion.

A la suite, les systèmes workflow ont évolué lentement durant les années 90 pour devenir des produits plus fonctionnels et plus souples, particulièrement en matière d’intégration, supportant des plateformes serveurs et clients plus nombreuses, incluant des outils de conception des processus simples et des outils de supervision basiques. Dans la plupart des cas néanmoins, les produits de workflow restaient très orientés « documents » : le marché de la dématérialisation et de la gestion électronique des documents était alors une telle « vache à lait » pour la plupart des éditeurs qu’ils ne furent pas énormément visionnaires lorsqu’il s’agit de trouver des utilisations au workflow allant au-delà du simple routage documentaire d’un bureau à l’autre. Ceci a favorisé deux choses :

– des modules complémentaires aux outils du marché ont proliféré, afin de couvrir tous les besoins que les éditeurs ne jugeaient pas importants de couvrir
– des start-up plus souples et spécialisées dans le workflow (en fait les premiers éditeurs de BPM) allaient laisser de côté l’orientation « contenu » initiale et développer des produits de workflow qui n’étaient certes pas nécessairement capables d’assumer la charge quotidienne des entreprises mais qui avaient au moins le mérite de permettre l’élargissement du spectre fonctionnel.

Ce que dit Sandy est vrai, mais il faut aussi penser aux sociétés de services qui ont elles-aussi développé des modules tiers venant compléter les offres éditeurs. Bien souvent intégratrices de ces outils, ces sociétés ont permis aux éditeurs de prendre conscience du fait que les add-ons proposés avaient une vraie raison d’exister pour certains, particulièrement quand ces mêmes éditeurs voyaient leurs clients investir dans des outils compagnons et laissaient ainsi échapper une part non négligeable des revenus associés.

On peut également signaler la montée en puissance des acteurs issus du monde du groupware qui ont petit à petit commencé à intégrer dans leurs offres des fonctionnalités de routage très orientées « documents » bien évidemment. On ne saurait les classer aujourd’hui dans les éditeurs de BPM.

Avant d’en arriver à aborder ces deux sujets, il nous faut parler un peu de l’EAI.

A suivre …

Retrouvez l’article original sur le blog de Sandy Kemsley