La gestion de cas métiers, ou gestion de dossiers électroniques, répond à un besoin pressant des entreprises et des administrations : permettre de coordonner le travail de réponse à des sollicitations (ex : appels d'offres, réclamations, enquêtes, audits, questions, etc.) suivant des processus contrôlés et qui impliquent des équipes souvent pluridisciplinaires (ex : administratifs, juristes, experts, etc.).
Nuxeo CMF répond à ces besoins en proposant les briques de base de telles applications (cas, files de traitements, workflow, gestion des droits, base de connaissance), permettant ainsi de créer facilement et rapidement des applications métiers dédiées à un domaine ou une entreprise particuliers.
C'est un projet open source, basé sur Java EE et la plateforme d'ECM de Nuxeo, avec un dépôt de source Mercurial, un gestionnaire de tâche ouvert, et un forum de discussion.
NdM : le logiciel est sous licence LGPL La gestion de cas métiers est souvent vue comme une sous-discipline de l'ECM (Entreprise Content Management), dans le sens où on y trouve :
- Des documents à traiter, souvent composites, dans le cas des réponses complexes, avec des métadonnées, des plans de classement, de la recherche plein texte, etc. ;
- Des processus documentaires, avec des règles métiers, des workflows de délégation et de validation, du travail collaboratif entre les différents intervenants sur un dossier (versioning, notifications, etc.) ;
- De l'archivage des dossiers, avec leurs réponses associées, une fois complétés ;
- Un historique de toutes les actions effectuées sur les différents dossiers, des tableaux de bord de suivi, etc. ;
- Une base de connaissance permettant de capitaliser sur les dossiers déjà traités ;
- Un besoin d'intégration avec le système d'information des organisations utilisatrices (base de contacts LDAP, outils de CRM, etc.).
Pour donner quelques exemples d'applications potentielles, on peut citer :
- La coordination d'une équipe de commerciaux, d'ingénieurs avant-ventes, de juristes, etc. autour de réponses à des appels d'offres ("usine à propales") ;
- La gestion des demandes de permis de construire, ou d'autres types d'autorisations administratives ;
- La gestion des demandes ou des questions à des élus, à des responsables politiques, ou à des structures de médiations entre les citoyens et les administrations ;
- La gestion des dossiers d'enquêtes (administratives, policières, judiciaires, etc.) ;
- La gestion de demandes de prêts, de remboursement de sinistres, etc. ;
- La gestion des réclamations auprès d'une grande entreprise ;
- Etc.
Aller plus loin
- Nuxeo CMF (435 clics)
- Le code source (29 clics)
- Le gestionnaire de tâches (50 clics)
- Le forum (5 clics)
- Nuxeo EP (61 clics)
# A propos de JIRA
Posté par franck villaume (site web personnel) . Évalué à 7.
N'existe-t-il pas de solutions de tracker libre ?
Merci de vos lumières.
[^] # Re: A propos de JIRA
Posté par Stefane Fermigier (site web personnel) . Évalué à 3.
Excellente question, même si elle est en effet totalement hors-sujet ;)
On a essayé toutes sortes de bug trackers open source par le passé: bugzilla, pour commencer, puis Mantis, puis Trac.
A chaque fois c'était pas mal, mais ca ne couvrait pas tous les besoins aux fur et à mesure que nos besoins augmentaient (besoin d'avoir des projets publics mais aussi des projets privés dans la même plateforme, pour nos projets clients; besoin d'une gestion fine des droits pour ces même raisons; besoin de workflows spécifiques à chaque projets; etc.) on s'est retrouvé avec des solutions pas totalement satisfaisantes.
Au final, on a fait ce que beaucoup de gens ont fait dans le monde Java open source (à commencer par la Fondation Apache), on est passé à Jira.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: A propos de JIRA
Posté par franck villaume (site web personnel) . Évalué à 4.
je comprends très bien le besoin d'efficacité et donc l'envie de prendre une solution sur étagère. Toutefois, je m'étonne de cet état de fait : "... dans le monde Java open source, on est passé à Jira". La fondation Eclipse est d'ailleurs resté à Bugzilla car elle considère que JIRA est propriétaire.
Pourquoi ne pas regarder ce que font des projets comme Redmine, FusionForge (1) et exprimer vos besoins vers ces communautés souvent très réactives ?
Parce que finalement, choisir JIRA, c'est faire le choix du propriétaire non ? D'ailleurs quel est le coût de sortie d'une telle solution ?
Sans être provocateur, mais imaginons que je doive choisir un ECM, devrais-je faire le choix entre du propriétaire gratuit(2) ou du libre ?
1: liste non-exhaustive
2: je ne sais même pas si il en existe :-)
[^] # Re: A propos de JIRA
Posté par Stefane Fermigier (site web personnel) . Évalué à 3.
-> La fondation Eclipse n'a pas les même besoins que nous.
"Pourquoi ne pas regarder ce que font des projets comme Redmine, FusionForge..."
-> On a regardé tout ce qui se faisait au moment où on a switché à Jira, peut-être qu'il y a eu des progrès depuis mais à l'époque il n'y avait rien. Et je ne pense pas qu'aujourd'hui ca ait vraiment changé.
"Parce que finalement, choisir JIRA, c'est faire le choix du propriétaire non ?"
-> Sur ce point précis, nous avons choisi le logiciel propriétaire qui répondait à notre besoin, parce qu'il n'y en avait pas et que l'énergie nécessaire pour mettre les outils au niveau dont nous avons besoin était largement plus onéreuse (i.e. se compte en années.hommes). C'est un choix pragmatique. La fondation Apache a fait le même, comme je l'ai écrit.
"D'ailleurs quel est le coût de sortie d'une telle solution ? "
-> Il est de l'ordre de l'investissement nécessaire pour mettre une solution libre au niveau dont on a besoin, donc très élevé.
Le jour où une solution libre satisfaisante existera, je ne pense pas que le coût de création d'un script de migration sera si élevé que ca, par contre. Le format d'export de Jira est un XML bien construit et documenté.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: A propos de JIRA
Posté par franck villaume (site web personnel) . Évalué à 1.
[^] # Re: A propos de JIRA
Posté par Etienne Juliot (site web personnel) . Évalué à 2.
On préfère de très loin utiliser les outils OpenSource et en faire la promotion ou envoyer des patchs, mais là faut bien avouer que la différence entre Bugzilla/Trac/andCo et Jira était trop grande pour rester sur la solution existante. (en gros, on estimait à 0,5j de charge par mois par personne de perdu, à multiplier par plusieurs dizaines de personnes, ca commence à faire mal).
Par exemple, un problème typique qu'on avait était sur la confidentialité. Quand tu as un trac sur ton outil OpenSource, et que tu as des clients avec du support ou des projets commandés, tes clients t'envoient parfois du code confidentiel avec leurs problèmes. Donc, tu ne peux pas le mettre en publique, et comme il n'y a pas workflow et de confidentialité bien paramétrable, et bien on avait plusieurs Trac. Et du coup, avec des redondances dans les bugs sur les projets FOSS, et une gestion plus complexe qu'avec Jira qui permet de tout unifier.
C'est vraiment dommage qu'une solution libre aussi puissante n'existe pas. Mais comme d'hab : YAKAFOKON ... Si quelqu'un se sent la volonté de faire changer cela, Trac et autre sont des projets ouverts à contribution.
[^] # Re: A propos de JIRA
Posté par El Titi . Évalué à 5.
A chaque fois c'était pas mal, mais ca ne couvrait pas tous les besoins aux fur et à mesure que nos besoins augmentaient (besoin d'avoir des projets publics mais aussi des projets privés dans la même plateforme, pour nos projets clients; besoin d'une gestion fine des droits pour ces même raisons; besoin de workflows spécifiques à chaque projets; etc.) on s'est retrouvé avec des solutions pas totalement satisfaisantes.
Dans tous les besoins que tu as exprimé (visibilité, droits par rôle/projet , workflow, ...) je n'en vois pas un qui n'est pas couvert par Redmine
http://www.redmine.org/wiki/redmine/Features
Si tu t'en tiens au simple bugtracker, je ne vois pas ce qu'apporte Jira de plus.
Si tes besoins couvrent aussi la gestion de projet avec des méthodes agiles, toutes les fonctionnalités de GreenHoper (module proprio) sont dans charts http://www.redmine.org/wiki/redmine/PluginCharts ou nativement dans Retrospectiva (celles que tu as évoqué sont présentes aussi).
http://retrospectiva.org/overview
Au niveau du wiki, Jira t'oblige à acquérir Confluence + Crown pour le SSO.
Niveau fonctionnalité XWiki lui en écrase.
Pour l'intégration continue Hudson n'a pas à rougir devant Bamboo proprio lui aussi.
Sans compter l'acquisition de Fisheye pour browser tes repository alors que tous les autres intègrent ca de base.
[^] # Re: A propos de JIRA
Posté par Stefane Fermigier (site web personnel) . Évalué à 1.
on a fait des essais avec Redmine en début d'année mais ils n'ont pas été concluants jusqu'à présent (je n'ai pas les détails). C'est pourtant très tentant.
Pour ce qui est de l'intégration continue, je te rassure, on utilise Hudson:
Cf. http://qa.nuxeo.org/
Merci pour les infos sur les équivalents de GreenHopper (qu'on n'utilise pas, on a développé un petit plugin à la mano pour faire du kanban). On va regarder tout ca.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: A propos de JIRA
Posté par Stefane Fermigier (site web personnel) . Évalué à 1.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: A propos de JIRA
Posté par claudex . Évalué à 2.
---> []
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: A propos de JIRA
Posté par Jérôme FIX (site web personnel) . Évalué à 3.
# Case Management
Posté par nomorsad . Évalué à 2.
Je n'ai pas encore essayer cette nouvelle application, donc il faudrait que le fasse pour comprendre, mais est-ce que cela se rapproche de Bonita, que l'on a vu dernièrement passer dans une dépêche ( https://linuxfr.org/2010/06/23/27049.html ) ?
Au passage, il faudrait que je teste Bonita pour comprendre également ce que ça fait, mais j'avais quand même globalement compris avec la dépêche (workflow
En tout cas, je suis bien content de voir des applis libres destinées aux fonctionnels de grosses entreprises, car on a toujours le sentiment que le libre, c'est toujours un peu des applications orientées techniciens ou grand public..
Cela veut surtout dire que la GPL gagne en crédibilité auprès des entreprises utilisatrices, et que le business model est viable du coté des fournisseurs de logiciels/services.
Donc oui, alors vous avez compris ce que ça faisait cette applis??
[^] # Re: Case Management
Posté par Stefane Fermigier (site web personnel) . Évalué à 4.
Mais en fait, si, c'est juste deux façons différentes d'aborder le même problème.
Le BPM, ou si on préfère, le workflow, s'intéresse avant tout aux processus. Il y a un certains nombre d'acteurs dans l'entreprise qui doivent effectuer des actions pour atteindre but, on modélise cela comme un processus, et le système de BPM s'arrange pour coordonner les actions de tout le monde et de surveiller que ca avance bien. Le processus peut agir à certains moments sur des documents mais ce n'est pas nécessaire.
A l'opposé, dans l'approche ECM, les objets de base sont les documents. Tout comme dans une entreprise "à l'ancienne" on avait des dossiers qui circulaient de service en service, et d'acteur en acteur, chacun effectuant par exemple la rédaction d'un bout de réponse, et la relecture ou la validation du tout (avec souvent plusieurs étapes de validation), on retrouve ces mêmes concepts dans le système de Case Management basé sur les concepts de l'ECM (on va d'ailleurs parler de "workflow documentaire").
Enfin une remarque: Nuxeo n'est pas GPL mais LGPL, ce qui fait qu'il est aussi possible de créer des applications métier propriétaires par dessus pour les gens qui le souhaitent.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Case Management
Posté par nomorsad . Évalué à 1.
En tout cas,ça donne bien envie de le tester, car j'ai déjà quelques idées de processus qu'on pourrait informatisé dans ma boite.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.