4.2.2 Processus pilote
Dans son livre `Processus métiers et
SI' (Chantal MORLEY et al., 2007), Chantal MORLEY évoque un
type de processus dit de pilotage qui « ne participe pas directement
à la réalisation d'une mission se traduisant par la production
d'un produit ou d'un service. Il a pour but de veiller à la bonne marche
de tout ou partie d'une organisation. Pour cela, il utilise des informations
produites par les autres processus. Il peut conduire à orienter ou
reconfigurer certains processus ~. Il serait plus judicieux
d'élaborer une première étude sur un processus de ce type
afin de ne pas en affecter d'autres, et restreindre au maximum le
périmètre d'implantation sans pour autant le limiter qu'à
deux ou trois utilisateurs, cela pour permettre de vérifier
l'utilité du BPM dans la coordination des acteurs concernés. Dans
tous les cas de figures, il faudra choisir un processus « cobaye »
pour y construire une analyse à travers les différentes phases de
tests et d'implémentation des outils étudiés.
4.3 Les phases du projet
Les bénéfices
associés au
pilotage réactif des processus métiers ne
sont pas exagérés, mais l'ampleur de la
démarche est souvent sousestimée. Comme pour
l'urbanisation, il s'agit d'un changement de culture d'entreprise, qui touche
l'ensemble de l'organisation et s'exerce sur de nombreuses dimensions.
Yves CASEAU, 2008.
Une fois notre « processus test » choisi, nous
allons présenter les différentes étapes à franchir
une à une en prenant compte des fonctionnalités propres à
chaque phase. Il y aura certainement d'autres paramètres
spécifiques (relatifs au métier) à considérer dans
la plupart des cas et qui ne seront pas cités du fait de
l'impossibilité de traiter tous les secteurs d'activités bien
entendu. Un travail de réflexion propre à chacun sera requis pour
la réalisation d'une étude plus complète et
personnalisée.
4.3.1 Présélection technique, fonctionnelle
et... commerciale !
La première phase consiste à réduire le
nombre de logiciels susceptibles de faire partie de notre étude
comparative afin d'en sélectionner qu'un nombre restreint, et en vue de
limiter d'une part les efforts consentis aux différents essais, et
d'autre part de respecter les contraintes liées a l'environnement de
l'organisation concernée. Ces contraintes peuvent être d'un ordre
technique ou fonctionnel tel que :
· Les systèmes d'exploitation pris en compte
· L'architecture réseau
· Serveurs web
· Serveurs d'applications
· Systèmes de gestion de bases de données
· Disponibilité de connecteurs vers des
systèmes spécifiques
· Langage de programmation utilisé
Des contraintes qui sont plus liées aux habitudes et a la
culture de l'entreprise peuvent aussi peser sur le choix des suites BPM
à tester, voire des préférences commerciales telles que
:
· Les relations et l'entente avec les éditeurs
(fournisseurs)
· Les licences proposées (et l'accès au code
source): Propriétaires ou Open Source ; Gratuites ou payantes ;
Annuelles ou perpétuelles...
· Documentation et/ou tutoriels disponibles, formations en
ligne, accompagnement...
· Communauté autour du logiciel (en nombre de
personnes et en volume d'activité)
· Les références clients des éditeurs
(ex : rechercher des sociétés du même secteur
d'activité et se renseigner sur la solution BPM adoptée, faire un
Benchmark)
En outre, on peut déjà écumer les
applications selon les fonctionnalités présentes (ou pas) tel que
les modules de BAM, les relances automatiques, la possibilité de
modéliser et d'exécuter le processus dans le même
Framework...etc. Ce dernier point est important car il existe des
éditeurs qui ne proposent que l'un ou l'autre, ou bien les deux
séparément (modélisation et exécution).
| 
