Je passe quelques jours à Milan cette semaine pour parler Case Management avec mes collègues européens.
L’idée de ce workshop est de réunir tous ceux qui parlent de Case Management au quotidien chez nos clients et partenaires et de partager nos expériences respectives. Je profite de l’occasion pour retranscrire quelques notes de la journée, rien de très formel mais des idées intéressantes sur lesquelles réfléchir.
Qu’est-ce qu’un « Case » dans un application de Case Management ?
Tout le monde s’accorde à dire que le « Case » est l’ensemble des traitements, informations, documents et actions nécessaires pour traiter une affaire dans un contexte métier.
Qu’est-ce qu’une « tâche » dans une application de Case Management ?
Dans le vocabulaire IBM ACM, on parle de « tâche » et non d’activité. Débat intéressant duquel il ressort que :
– une tâche correspond à tout ce qu’il est nécessaire de faire pour traiter l’affaire en question,
– le terme « Activité » est très lié au BPM et à BPMN et ne peut être repris dans un contexte ACM car une activité (BPM) est liée à une autre activité alors qu’une tâche ACM ne l’est pas nécessairement,
– une « tâche » ACM regroupe l’ensemble des opérations élémentaires qui doivent être faites, ainsi que toutes les tâches qui « peuvent » être faites selon le cas.
Le BPM n’est (toujours) pas de l’ACM … et vice-versa
Autant il nous semble à tous que la différence entre ACM et BPM est évidente, autant il est important de savoir le démontrer. Voici quelques arguments différentiateurs :
– ACM trouve sa place entre « le tout collaboratif » d’une part, sans aucune notion de processus, et « le tout processus » de l’autre, le monde du BPM, où tout est modélisé et ordonnancé,
– ACM est orienté « donnée » – BPM est orienté « processus » : le coeur applicatif d’ACM est le gestionnaire de contenu alors que le coeur du BPM est le moteur d’exécution BPM,
– quand une instance BPM meurt (lire « est terminée ») les données propres à son exécution disparaissent, à l’inverse une instance ACM est archivée ainsi que l’ensemble des informations connexes qui ont été générées/traitées,
– une application ACM détermine un ensemble de tâches qui doivent être exécutées, quel que soit l’ordre d’exécution. Des conditions d’entrée déterminent le caractère exécutable d’une tâche, ou pas. A l’inverse un processus BPM impose un ordre d’exécution, un séquencement, il est donc plus rigide.
Comment instancier un Case ?
Note: « instancier » … « instantier » … merci à Solange pour avoir pointé du doigt la traduction un peu rapide …
Tout le monde s’accorde également pour dire qu’il y a de nombreuses façons d’instancier un « Case ». Parmi celles que nous avons recensées :
Instanciation par un auteur de contenu
– un document ajouté à un dossier lance la création d’un case,
– une opération métier, quelle que soit sa complexité, lance la création d’un case en mettant à jour un élément de contenu ayant un rapport direct avec l’affaire/le client,
Instanciation par un gestionnaire d’affaires
– un gestionnaire décide de créer un nouveau case et le fait manuellement,
– un processus métier crée un case via l’exécution d’une tâche BPM,
Instanciation par une application métier
– un case peut être créé par un appel CMIS depuis un gestionnaire de contenu,
– un case peut être la résultante d’un appel de Web Services,
– un case peut être créé par un autre case.
Je vous laisse réagir et apporter votre vision si vous le souhaitez, laissez un commentaire …
A suivre dès que possible en fonction du programme …
Illustration: itselea
Bonjour,
Nouveau dans le monde de l’ACM, plus expérimenté en BPM, l’instanciation par une application métier telle que présentée me gêne un peu.
Je vois le BPM et l’ACM comme des approches orientées métier où la technique sous jacente est occultée. Or, partir sur « appel CMIS » et « Web service » cloisonnent déjà sur des approches techniques données. Je serais plus partisant de présenter qu’un case soit la résultante d’une action sur une GED (voir même CMS pour gérer des documents structurés et non structurés ?), d’un appel vers une interface publique et via l’appel d’un case.
Un exemple du même genre de « débat » : lorsque la service task de BPMN est présentée comme l’appel d’un webservice. L’envoi d’un email de notification n’a rien à voir avec l’invocation d’un webservice, et pourtant, c’est ainsi que cela se modélise.
Tiens, une demande récurrente de clients qui n’est pas adressée par nos approches favorites peut rentrer quelque part dans le débat : réagir à un évènement externe (ex : réception d’un email). A l’heure actuelle, nous sommes obligé d’encapsuler les implémentations dans un outil externe comme un ESB pour gérer ces cas, sans vraiment de recommendation précise à ce sujet (à ma connaissance au moins).
Cela dit, l’article présente bien ce qu’est le case management et sa différence avec le BPM, j’apprécie
Bonjour et merci pour le commentaire. Je tente quelques réponses.
La création d’un case est consécutive à un événement métier, quel qu’il soit et quelle que soit l’application et/ou la donnée à l’origine. J’entends la remarque sur CMIS et Web Service mais pour autant, imaginons un document client reçu dans un référentiel documentaire lambda et permettant la création d’un case via appel CMIS, rien ne me choque.
Pour ce qui est de réagir à un événement externe comme la réception d’un mail, il existe des outils spécialisé de capture automatique, stockage du mail et/ou des pièces jointes en GED et création automatique d’un case. Je peux vous fournir plus d’infos par mail au besoin.
Et merci pour l’appréciation de l’article 🙂