Toon posts:

[CM] Advies gevraagd mbt workflow

Pagina: 1
Acties:

Verwijderd

Topicstarter
Af en toe heb je van die momenten dat je het echt even niet meer weet. Ik heb het hier over workflow in een content management systeem. En elke keer denk ik, ja zo ga ik het doen, en na 50 x een A4'tje te hebben volgeschreven met aantekeningen, plan van aanpak, processen beland ditzelfde A4'tje in de bak met oud papier.

Het systeem bestaat om het even makkelijk te houden uit bibliotheken en uit een scherm waarmee je de structuur van een project bepaald. In het scherm waar je de structuur bepaald kun je in een treeview pagina's toevoegen. Wederom houden we het even simpel, en kun je aan de pagina's in die structuur, content uit je bibliotheken toevoegen.

Content heeft een aantal interne statussen waaronder bijv. draft, awaiting approval, approved, rejected. Bij het aanmaken van een object (artikel) krijgt het initieel de status draft mee.

Voordat het gepubliceerd kan worden moet het door een editor worden gecontroleerd. We doen als auteur dus een verzoek voor approval, en het object krijgt de status "awaiting approval" en de editor krijgt de nodige notificaties en zijn planning wordt bijgewerkt.

Deze workflow leg ik vast in een workflow configuratie.

Nu loop ik tegen het probleem aan dat ik niet weet waarop ik workflow wil gaan toepassen. Ik zit er aan te denken om de workflow configuratie aan te pakken zoals permissies in Windows NT werken. Een parent element bevat de workflow configuratie waar childs aan onderhevig zijn. De root zal dan default de website zijn.

Echter, ik heb de mogelijkheid om zowel in de bibliotheek content toe te voegen, en direct in de structuur content toe te voegen aan een pagina. Voeg ik direct in de structuur content in, dan wordt deze direct in de bibliotheek geplaatst, desnoods onder de gewenste folder.

Dit brengt echter een probleem mee. Zodra ik "request approval" in taxonomy kies kan deze "request approval" verschillen van workflow configuratie als in taxonomy de parent pagina een workflow configuratie heeft, en als in de bibliotheek de parent folder (of als er geen parent folder is de website root) een andere configuratie heeft.

Waar is dan de nieuwe content haar workflow van afhankelijk? Zijn er mensen die met dergelijke problemen te maken hebben gehad?

Ik kan er later even screenshots bij plaatsen, maar mijn dsl aanbieder heeft nogal moeite om de homepage server ftp toegang normaal te laten functioneren. Dus die komen nog.

  • D4Skunk
  • Registratie: Juni 2003
  • Laatst online: 20-10-2025

D4Skunk

Kind of Blue

Naast je workflow moet je natuurlijk ook een context hebben bij het implementeren van je systeem. Het is net die context die jij volgens mij mist.

Mijn .02 €

Verwijderd

Als ik het goed begrijp zijn er (om het simpel te houden) 3 scenario's:

1. Content toevoegen aan bibliotheek
2. Content toevoegen direct in de structuur
3. Content toevoegen aan bibliotheek doordat het aan de structuur wordt toegevoegd

Verder geef je aan dat je de workflow configuratie af wilt laten hangen van de locatie waar de content geplaatst wordt. Daar is helemaal niets mis mee, maar zoals je zelf al had vastgesteld loop je daarbij tegen problemen aan en wel doordat je als er content in de structuur wordt toegevoegd DIRECT de content aan de bibliotheek toevoegd. Je kunt dit probleem alleen tackelen door het proces erbij te betrekken.

1. Waar wordt content geplaatst?
2. Welk scenario (proces) maakt het plaatsen onderdeel van uit?
3. Welke workflow configuratie is van toepassing?

Suc6

[disclaimer]Hoop dat ik je probleem goed heb begrepen, zo niet: negeer bericht[/disclaimer]

Verwijderd

Ik worstel zelf ook al een tijdje met het probleem van Workflow. Via zoekmachine vivisimo kwam ik op het artikel The State of Workflow van Tom Baeyens.
Bij further reading onderaan de pagina zag ik een verwijzing naar Workflow Patterns research werk van professof Wil van der Aalst van de Tue. Wellicht interessant materiaal. Ik heb het nog niet gelezen, maar het lijkt me van hoge informatieve waarde.

Verwijderd

Topicstarter
Verwijderd schreef op dinsdag 15 maart 2005 @ 09:53:
Als ik het goed begrijp zijn er (om het simpel te houden) 3 scenario's:

1. Content toevoegen aan bibliotheek
2. Content toevoegen direct in de structuur
3. Content toevoegen aan bibliotheek doordat het aan de structuur wordt toegevoegd
100% correct .. bij punt 3 kun je in het dialoog om content toe te voegen een categorie in de bilbiotheek kiezen.
Verder geef je aan dat je de workflow configuratie af wilt laten hangen van de locatie waar de content geplaatst wordt. Daar is helemaal niets mis mee, maar zoals je zelf al had vastgesteld loop je daarbij tegen problemen aan en wel doordat je als er content in de structuur wordt toegevoegd DIRECT de content aan de bibliotheek toevoegd. Je kunt dit probleem alleen tackelen door het proces erbij te betrekken.
Ja dat is dus inderdaad het probleem.

1: Ga ik in de bibliotheek toevoegen, wie bepaat dan de workflow:
project of parent folder

2: Ga ik in de structuur toevoegen, wie bepaald dan de workflow:
project of parent pagina (waar de content inzit)


Mijn structuur is qua website dan ook vereenvoudigd.
domein - > cultuur - > pagina - > content
1. Waar wordt content geplaatst?
2. Welk scenario (proces) maakt het plaatsen onderdeel van uit?
3. Welke workflow configuratie is van toepassing?
Ik heb zelf de volgende oplossing bedacht, maar hoe denken jullie daarover:

1: workflow wordt bepaald op website niveau (lees domein)
2: workflow kan specifiek worden bepaald op taken

Een taak wordt dus vergezeld van een workflow configuratie. Een taak wordt toegekend door een project manager van een project (of hoofdredacteur bijv.).

Zo krijg je dus niet een spaghetti van workflow regels.

Mijn persoonlijke afkeer van workflow op pagina niveau is namelijk ook, dat een auteur geen pagina zou kunnen toevoegen en gelijktijdig workflow bepalen, dat zou een dergelijk persoon bijvoorbeeld helemaal niet mogen.

Verwijderd

Je bent sowieso erg flexibel door met losse taken te gaan werken.

Verder ben ik ook tot de conclusie gekomen dat OF de site OF de bibliotheek leidend moet zijn en ik vind het dan ook te rechtvaardigen dat je kiest voor de site. Dat houdt overigens wel in dat de bibliotheek dus van ondergeschikt belang wordt. Je zou dat kunnen oplossen door een soort van "bibliotheek - moderator" in het leven te kunnen roepen die een taak krijgt op het moment dat er een nieuw content item in de bibliotheek wordt aangemaakt.

Denk dat je zo hard op weg bent naar een werkende oplossing, maar ik zou wel de mogelijkheid openhouden om per pagina af te wijken van de workflow configuratie van het domein. Ik denk dat de praktijk gaat uitwijzen dat je dat wel nodig hebt.

Verwijderd

Topicstarter
Zowiezo kom ik niet onder taken uit, ik wil namelijk een gedeelte project management in het systeem verwerken met bijv. gantt charts dus taken heb ik zowiezo. Deze zullen bij uitvoer worden getransformeerd naar doel objecten zoals task->pagina of task->content object.

Een van de twee aanpakken leidend maken lijkt me niet een verstandige oplossing, omdat een eindgebruiker op het eind totaal niet meer weet waar, wat en wie afhankelijk is van welk niveau en waar dit bepaald wordt. Het mag dan flexibel zijn een NT achtig systeem, maar duidelijk is het niet. De optie echter kun je altijd openhouden omdat ik een object generiek aanpak.

Ik denk dus dat het voornamelijk verstandig is om per website default een enkele workflow configuratie actief te hebben. En alternatieve workflow configuraties indien met taken gewerkt gaat worden.

Ik zit dan alleen nog te kijken met permissies op taken in de workflow. Door deze eenmalig te definieren, loop je ook tegen het risico aan dat iemand in de workflow niet de benodigde permissies heeft. Het blijft lastig al die afhankelijkheden :)

Verwijderd

Misschien is het mogelijk de structuur van de websites te reduceren tot patroon "Composite". Voor de projecten kan je dat ook doen. Daarmee wordt iedere taak een project.

Status is een eigenschap bij zowel "Project" als "Website". De status van een (deel-)project is wat anders dan de status van een webpagina. Een deelproject kan afgesloten (geannuleerd :*) ) zijn, terwijl de pagina nog niet afgerond is. Web-objecten (bv een directory, status "newly created" ) kan je passen van de ene project activiteit naar de andere, bv als trigger of input. Een project activiteit is een proces, dus met input, output, support en triggers. Afhankelijk van de status van het project wisselt de benodigde support (mankracht). Support kan je als rol-systeem bouwen. Afhankelijk van de instelling van het project zal de rol worden ingevuld door mensen volgens de hierarchie van project of website. Hier zou ik een eigenschap voor aanmaken in "Project", om standaard te gebruiken voor alle deelprojecten. Afhankelijk van het type project kan je een standaard kiezen: project, web of library-default. Bv voor onderhoud via de website-hierarchie en voor nieuwbouw volgens project-hierarchie.

Verwijderd

Topicstarter
Ik snap je hele verhaal niet in vergelijking met mijn probleemstelling. Het punt is op welk niveau bepaal je workflow.

Hoe die workflow in elkaar steekt, hoe de content in elkaar steekt en hoe dit technisch werkt is niet de issue. Het is de issue hoe dit in de praktijk gaat werken.

[ Voor 61% gewijzigd door Verwijderd op 15-03-2005 15:59 ]


Verwijderd

Topicstarter
Ik heb eindelijk weer de mogelijkheid gehad om visueel wat uitleg te uploaden. Ik ben nog een belangrijk aspect in mijn uitleg vergeten.

Een website bevat een uitgebreide set rollen, gebruikers, policies maar ook departments. Een department is bijvoorbeeld marketing. De department marketing kan daarvoor verantwoordelijk zijn voor haar eigen stukje website. Bijvoorbeeld de pagina met press releases.

Dit kan bijvoorbeeld inhouden dat die specifieke department onderhevig is aan een andere, dan globaal ingestelde workflow. Een bepaald persoon in die department kan bijvoorbeeld verantwoordelijk zijn in de eindredactie.

Dan blijft eigenlijk nog de vraagstelling staan; als je zelf de keuze zou hebben, waar zou je de workflow instellen.

Stel ik de workflow in op domein niveau, dan zijn ook departments met een eigen startpagina daarvan afhankelijk. Als er in deze workflow mensen staan die zaken moeten accorderen maar totaal geen relatie hebben met het department ga je al nat.

Stel ik de workflow in op pagina niveau, dan kun je vanuit taxonomy bij request for approval op een stuk content de workflow afleiden uit de pagina. Maar als dit stuk content in de bibliotheek weer een andere workflow krijgt omdat op de folder workflow is gedefinieerd ga je ook nat.

lastig...

Nu de visuals:

Taxonomy, bepaling van de structuur. Links de treeview met pagina's en structuur, rechts de inhoud van de pagina. Een department kan dus verantwoordelijk zijn voor zijn eigen pagina. Op het moment dat iemand inlogged en zijn department heeft een eigen startpagina, dan zal de treeview ook vanaf die pagina beginnen, en niet vanaf de homepage.

Afbeeldingslocatie: http://www.mschopman.demon.nl/taxonomy.jpg

Bibliotheek, opslag en beheer van content. Links de treeview met artikelen, en folders voor categorisatie. Rechts de summary en versies van een artikel.

Afbeeldingslocatie: http://www.mschopman.demon.nl/library.jpg

Departments, roles, users, policies bepalen toegang en gebruik van het systeem.

Afbeeldingslocatie: http://www.mschopman.demon.nl/accounts.gif

Ik ben me ervan bewust dat ik de lat erg hoog leg, het is niet mijn eerste cm systeem, maar ditmaal wil ik er wat speciaals van maken.

[ Voor 18% gewijzigd door Verwijderd op 15-03-2005 19:41 ]


Verwijderd

Verwijderd schreef op dinsdag 15 maart 2005 @ 19:30:
Stel ik de workflow in op domein niveau, dan zijn ook departments met een eigen startpagina daarvan afhankelijk. Als er in deze workflow mensen staan die zaken moeten accorderen maar totaal geen relatie hebben met het department ga je al nat.
Dit is juist wel aardig. Je kan een waarschuwding maken wanneer iemand beslag wil leggen op een middel dat buiten z'n projectscope valt. De keuze voor de invullinging van rollen en de overrulebaarheid / delegeerbaarheid jou je dan per afdeling per type webobject in moeten kunnen stellen. Elke afdeling heeft dan mogelijk zijn eigen bieb van bouw- of onderhoudstaken, waar een project uit opgetrokken kan worden.

Oef, dit wordt een formele tent zeg ;).
Pagina: 1