4.3.4 La création des interfaces
utilisateurs
Le critère essentiel lors de cette étape est
d'avoir un accès facile et intuitif aux données que nous avons
établies a l'étape précédente. Les outils peuvent
cependant différer les uns par rapport aux autres dans la manière
de procéder pour construire les interfaces. On peut utiliser du code
pur, du glisser/déplacer, piocher les données directement
à partir du modèle construit ou bien les définir et les
lier ultérieurement au modèle. Ces deux dernières
façon de faire peuvent être très utiles dans quelques cas,
en particulier lorsqu'on imagine des données a rajouter aux formulaires
a construire au moment oü on les développe alors qu'on y avait pas
pensé lors de la construction du modèle.
Il peut y arriver de rencontrer des outils qui offrent la
possibilité de personnaliser ses formulaires selon la charte graphique
de son entreprise, cela améliore le rendu final et on obtient alors une
application « maison » qui aura le mérite de ne pas trop
dépayser les futurs utilisateurs. La navigabilité y joue aussi un
rôle important. Veuillez vérifier la présence de mise en
page avec des onglets ou des groupements de données qui facilitent la
lecture des formulaires.
4.3.5 Le moteur de règles métiers
L'utilisation d'un moteur de règles métiers
apporte les bénéfices suivants :
- Assurer la conformité avec la
réglementation ;
- Adapter rapidement le processus suite aux modifications
(temporaires ou définitives) de la politique (globales ou par services)
;
- Gagner en autonomie, donc en efficacité, en
offrant la possibilité aux chefs de service d'apporter des modifications
au processus vertical en fonction de leurs besoins.
Jérôme BESSON, 2009. (Product Manager
VDoc Software)
Le moteur de règles est le cerveau des applications
BPM. Il représente l'ensemble des algorithmes d'automatisation des
prises de décisions qui permettent de tracer les différents
chemins empruntés par un processus. C'est aussi le déclencheur
des activités/actions et des alertes automatiques (e-mails, warnings)
lorsque le processus se trouve dans un état particulier
prédéfini par l'utilisateur. Tous les calculs, les traitements de
données, les contrôles et les assignements se font via le moteur
de règles. L'agilité de l'application finale dépendra de
la flexibilité et de la puissance de ce moteur.
Il faut donc veiller scrupuleusement a vérifier
l'adéquation du moteur disponible dans une suite BPM avec les besoins
métiers des processus a implémenter. S'il y a des traitements
spécifiques à programmer, il se peut que cela nécessite
une intervention sur les couches inférieures du logiciel et donc une
expertise technique sera requise. (BDD, Batchs...)
Ce module doit être parfaitement maîtrisé
si on veut devenir capable de s'adapter très rapidement au moindre
changement qui survient, sans avoir à retoucher à la
modélisation des processus. Car les règles peuvent changer
à tout moment et évoluent dans le temps causant
généralement une redéfinition totale ou partielle des
processus. Une enquête d'IDC de début 2005
reflète que « plus de la moitié des entreprises qui
n'utilisent pas de solution de gestion des règles métier
modifieraient leurs processus métier plus fréquemment si elles
pouvaient réaliser ces changements plus simplement et de manière
plus économique. »
La modélisation des règles doit se faire donc de
préférence en syntaxe naturelle, afin que les responsables
métiers puissent aisément les faire évoluer.
| 
