Quel est le flux de travail de publication idéal pour un CMS d'entreprise?
Quel est le flux de travail de publication idéal au sein d'un CMS d'entreprise?
Contexte: La taille de l'entreprise est de 1 000. Environ 20 gestionnaires doivent approuver le contenu de leur département avant de publier. Il y a 3 rôles d'utilisateur:
- Webmaster Admin (support)
- Editeur (gestionnaires)
- Rédacteur en chef
À l'heure actuelle, un éditeur effectue sa modification, puis la soumet pour révision. Pendant ce temps, le contenu est verrouillé pour édition. Un éditeur reçoit un courrier électronique "travail en attente de publication" et peut examiner le travail via une adresse Web test, puis l'approuver ou le refuser.
Ce processus fonctionne la plupart du temps, à quelques exceptions près. Parfois, un projet à grande échelle nécessite que les modifications de contenu soient mises à jour et testées bien avant d'être publiées. Par exemple, un produit est renommé publiquement dans 2 mois, ce qui signifie que le contenu est mis à jour longtemps à l’avance et testé en interne. Ces pages restent ensuite dans cette étape pendant 2 mois jusqu'à ce qu'elles soient nécessaires pour être publiées. Cela signifie qu'environ 50 pages sont verrouillées en édition, ce qui signifie que tout autre contenu de cette page ne peut pas être mis à jour pendant cette période, ce qui provoque des perturbations et une frustration pour les propriétaires de contenu.
Maintenant, je sais que cela ne doit pas être un problème unique, mais je suis perplexe quant à la manière de le gérer.
Je ne pense pas qu'il y ait une réponse globale à cette question. Le flux de travail peut être aussi simple ou complexe que nécessaire pour correspondre au modèle de gouvernance requis par l'entreprise.
-
J'ai moi-même assisté à des démonstrations d'aspect louche de concepteurs de flux de travail capables d'impliquer plusieurs niveaux d'approbation, de processus externes et de logique de branchement. En fait, ces flux de travail sont tellement avancés qu'il existe des outils visuels qui aident les administrateurs à découvrir où un élément est bloqué dans le flux de travail.
Mon opinion personnelle est que le flux de travail doit toujours être aussi simple que possible. L'engagement et l'adoption internes constituent le premier obstacle à surmonter lors du déploiement d'un système de gestion de contenu. Si on superpose la CMS à la bureaucratie, les gens en ont juste peur et l’utilisent moins.
Cela étant dit, les workflows (et même les workflows complexes) deviennent un mal nécessaire dans une organisation complexe. Un communiqué de presse mal programmé pourrait avoir des conséquences désastreuses dans certains contextes. Dans ces cas, je privilégie toujours " le moins de flux de travail possible ". Si la direction est à l'aise avec une simple approbation en 1 ou 2 étapes, c'est l'idéal.
-
En ce qui concerne la création de contenu, je ne suis pas au courant d'un CMS qui le fait bien. Pour notre propre CMS , nous prenons en charge WWF (Windows Workflow Foundation), mais le référentiel de contenu est versionné sur une seule piste. Il est facile de revenir en arrière, mais sans codage personnalisé, nous ne prenons pas en charge le forking ou la fusion.
Dans le passé, nous avons surmonté des défis similaires en créant des sections cachées du site Web et en dupliquant le contenu de la page existante (cette opération peut être réalisée via l'interface utilisateur ou l'API). Les nouvelles modifications peuvent ensuite être développées en privé et le contenu existant peut continuer à être maintenu.
Lorsque le moment est venu de changer, nous avons simplement changé d'URL pour cacher le contenu existant, puis faire en sorte que le nouveau contenu utilise l'URL existante. Toute fusion devrait être faite manuellement. Je ne suis pas sûr que ce soit la meilleure solution, mais cela a fonctionné.
-
Je suis cependant intéressé par l’idée de forger et de fusionner du contenu dans un CMS. Je serais intéressé de voir si quelqu'un a de meilleures suggestions.
Si c'était de la programmation, vous créeriez une branche qui serait ensuite fusionnée avec l'arborescence principale. Sans connaître les détails de votre système de gestion de contenu, je créerais une copie de la partie pertinente du site pendant ces 2 mois et j'y apporterais et testerais les modifications. Cela ne sera jamais publié sur le site en direct.
Ensuite, lors de la mise en production, vous devez modifier les pages d'origine pour utiliser, par exemple, le nouveau nom du produit. Si le nom du produit est le plus petit changement, vous modifiez la page d'origine pour utiliser le nom. Si les modifications apportées aux pages d'origine étaient plus petites, copiez la page de test sur la page d'origine et réappliquez les modifications apportées à la page d'origine.
Avec le code source, il existe des outils pour aider à cette fusion, mais vous devrez peut-être le faire à la main en comparant les deux pages.