Le débat revient régulièrement sur le devant de la scène, ECM et BPM doivent-ils être un seul et même outil au service des organisations, est-il nécessaire pour les vendeurs d’ECM d’offrir des capacités de BPM équivalentes à celles offertes par les purs players du secteur, le workflow intégré dans les outils d’ECM peut-il concurrencer les offres BPM indépendantes ?

Je lisais encore récemment quelques notes sur la blogosphère à ce sujet, en particulier celle de PCM.blog intitulée « Should BPM be a part of ECM », ou encore celle de Russ Stalters qui anime le blog BetterECM et dont le titre est « BPM and ECM intersecting ? », sans oublier le Gilbane Group Blog qui a écrit « The ECM and BPM intersection », et j’avais envie de faire le point par rapport à ma précédente note sur ce même sujet.

Ce que l’on peut en dire aujourd’hui, c’est que le marché du BPM s’est bien renforcé et tout particulièrement en France. Les années difficiles semblent être derrière nous et d’ailleurs on peut même voir certains acteurs se manifester à nouveau sur le marché (ou d’autres apparaître d’ailleurs). Les grands éditeurs l’ont bien compris qui renforcent leurs offres en ce sens. Pour en revenir à la question initiale, je crois que l’association ECM-BPM va croître et les offres intégrées vont se développer pour plusieurs raisons.

La première est que les purs-players sont ou vont être absorbés par les grands éditeurs. On l’a vu avec BEA et Fuego, il en reste quelqu’uns sur le marché qui pourraient être les prochaines proies. Tout rachat impliquant à terme l’intégration des produits, il y a fort à parier qu’au moins pour ces acteurs là et par souci de rationalisation, ECM et BPM vont vite être présentés comme un seul et même outil.

La deuxième raison est que les clients recherchent de plus en plus à réduire les coûts de mise en oeuvre et les cycles de développement de leurs applications. L’intégration des fonctions de BPM au sein de l’outil ECM, ou l’inverse d’ailleurs, va dans ce sens et permet de substantielles économies en la matière. De même il y a quelques effets de bord comme le fait d’utiliser des ressources communes (pas besoin de deux équipes spécialisées chacune dans leur produit), d’avoir affaire à un seul acteur (un même éditeur) ou encore de regrouper les contrats de maintenance en un seul.

La troisième raison est moins tangible mais je pense qu’il va devenir de plus en plus évident pour les organisations et les décideurs que le processus est une partie intégrante de leur problématique ECM, qu’il leur faut absolument implémenter le BPM ou encore bâtir une infrastructure de services de gestion des contenus et des processus (la vague SOA et Enterprise Reference Architecture !) qui intègre donc tout naturellement ces deux composantes. Et pour ce faire, un seul et même outil c’est beaucoup plus facile. Qui se poserait la question aujourd’hui de n’acheter qu’un simple traitement de texte ou un simple tableur, tout le monde s’équipe d’un pack bureautique comprenant au minimum ces deux outils sans se poser d’autre question. Il en est de même avec les serveurs d’application qui intègre tout naturellement un serveur HTTP.
Maintenant, la difficulté est de mettre à la disposition de ces organisations les outils appropriés. j’ai la chance de travailler pour un éditeur (FileNet) qui peut se vanter de le faire. Ce n’est pas le cas des purs-players BPM, ce n’est pas (encore) le cas des grands éditeurs (je mets de côté IBM et sous certains aspects BEA). Ce n’est pas le cas non plus des purs-players ECM. Néanmoins, je reste persuadé que la réponse à la question est bien « oui, ECM et BPM doivent être unifiés ».

Je vous laisse réagir à cette note, comme cela avait d’ailleurs était le cas pour la première déjà citée.