IT and unmanaged processes

Quite commonly organizations have some undefined or unmanaged processes. This is giving the impression to C level that only IT enforced processes are working fine.

Then, to feel more comfortable, top or senior management triggers projects to automate those unclear processes.

Very often this IT enforcement is not mandatory : having a proper process definition and performing the proper checks would often be sufficient and by far cheaper!

IT is not the only way to setup a process

A little anecdote on this topic : a company was struggling in setting up a sensitive process dealing with revenue recognition between production and sales. As it was not working, it was decided to get it automated (!). IT has been called and implemented a process at unitary deal level creating an IT an administrative monster. Production and sales were fighting on each transaction blocking the whole process.

Stepping back for a while, it was clear that this was the wrong decision and a more manual approach was taken : a weekly report was produced and both parties were invited to discuss and sign it off. The sign-off was recorded in a basic document workflow making the agreement official.

This simplistic approach paid off : due to netting effect, production and sales were much more in sync, talking to each other every week instead of fighting through systems, also creating a smoother relationship.

 IT is not meant to be a change agent

Another impact of trying to automate unclear processes is that IT is being put in a difficult role: IT is becoming the change agent. Instead of managing the required change in the process from the business side, this change is becoming all of a sudden a change forced by IT. Business managers can escape from their responsabilities in managing the change letting IT doing it. This is not so comfortable for IT teams that have to manage the process clarification, its implementation and the change management.

Also, the small example above is telling that brutal force is not helpful. Enforcing systematically processes implementation through systems is not always bringing value although it is sometimes mandatory (managing transaction status, product lifecycle, purchase orders, …).

A lightweight approach can also be considered espacially when processes are unclear. IT is then not any more in the driving seat which gives back to business the change responsibility.

Outils de Workflow

Pour les outils de workflow, comme pour beaucoup d'autres technologies, les concepts ne datent pas d’hier. Ces outils tentent de donner un support informatique à la mise en place de procédures opérationnelles. Les directions de l’Organisation de nombreuses sociétés ont utilisé des outils de cette nature d’abord pour modéliser les processus, puis pour les mettre en œuvre. Des consortiums ont travaillé depuis des années sur la normalisation des outils qui sont restés très souvent confinés au monde du traitement documentaire.


L’objectif de ces outils est de décrire, souvent à travers une interface graphique, les différentes étapes d’une procédure mettant en relation différents intervenants et une demandant le respect d’une séquence. Après avoir été descriptifs, ces outils ont proposé des moteurs permettant alors de mettre en œuvre opérationnellement les procédures décrites. Ces outils ont ainsi permis la collaboration des différents intervenants en orchestrant les échanges et les validations. Le passage du descriptif à l’interactif a d’ailleurs alimenté bien des querelles entre Directions Informatiques et Directions de l’Organisation !


Comme mentionné plus haut, ces outils ont été utilisés pour des procédures documentaires. N’ayant aucun lien profond avec le reste du système d’information, ils ne pouvaient pas orchestrer les échanges inter applicatifs même si, technologiquement, ils en avaient depuis longtemps la capacité.
Si on imagine facilement l’importance de la formalisation des procédures, l’émergence des processus de normalisation Iso ayant matérialisé cette nécessité, on sait moins que la plupart des systèmes d’information des entreprises cachent dans leurs applicatifs des procédures implicites dont la connaissance disparaît au fil des années.


Pour illustrer ceci on peut prendre le cas de ces entreprises qui disposent de filiales en différents points du globe, chacune opérant sur des systèmes différents. Le groupe cherchant néanmoins à mettre en place des traitements consolidés pour dégager des économies d’échelle, la mise en place d’échanges inter applicatifs devient alors essentielle. Inévitablement, au gré des restructurations, ces règles d’échanges évoluent impliquant une reconfiguration du système d’information.
On parle alors de rigidité du système d’information car, l’adaptation du système aux nouvelles règles métier est longue voire pénible. Pour réaliser ces adaptations, on est souvent obligé de se réapproprier les règles d’origine dont la connaissance a été perdue, puis on tente d’implémenter les nouvelles règles dans tous les applicatifs concernés.
Le monde du Workflow, jusqu’à la naissance de la SOA, restait étranger à ces problèmes d’intégration et d’échanges inter applicatifs