Document management systeem combineren met dashboard

[Clock]

Waarschijnlijk heb ik met deze titel de hoofdprijs in vaagheid gewonnen, welke ik graag in ontvangst zal nemen. Om mijn probleem helder te kunnen omschrijven zal ik er helaas toch enkele woorden tegenaan moeten gooien, maar het is (naar ik denk) een interessant probleem, dus bare with me

Momenteel werk/studeer ik in the UK en loop nu bij een manufacturing bedrijf dat veel doet in de olie/gas industrie en aerospace onderdelen. Vanwege de hoge eisen aan deze producten dienen deze voorzien te worden van een heus DocPack, een documentatiepakket met daarin alle materiaalcertificaten, machine-operator-certificaten, testrapporten, apparaatcalibratierapporten, etc, etc. Een DocPack voor een afsluiter die op de zeebodem komt te staan is ongeveer 800 pagina's dik, een beste pil dus.

De directe aanleiding waarom ik daar rondloop voor werk/studie is omwille de typisch Britse organisatie van het process. Die is gebaseerd op eeuwenoude software en werkmethodes en houdt nu het bedrijf achter in zijn groei. De afgelopen weken heb ik alle problemen in kaart gebracht en ben nu bezig met de selectie van een nieuw DMS en redesign van de werkprocessen om dit systeem optimaal te gebruiken. Tot zo ver geen probleem.

Een van de andere dringende problemen is het gebrek van monitoring van het process. De hele afdeling (7 FTE) die hier mee bezig zijn wordt op geen enkele manier beoordeeld op de performance van het proces, de troughput, kwaliteit, etc. Een van de zaken waar ik mee bezig ben is het opzetten van een systeem om dit soort KPI's consistent in kaart te brengen. En hiermee komen we bij het probleem.

Dit performance monitoring systeem (laten we het een dashboard noemen) willen ze hier graag gecombineerd in het DMS, omdat het vooral de flow en status van documenten zal measuren. Hoewel ik hier de logica van inzie zijn de KPI's weldegelijk breder dan alleen DMS-zaken. Ook is een performance management systeem een compleet ander iets van een DMS, en daardoor zie ik niet in hoe dit gecombineerd moet worden. Daarom is mijn voorstel: DMS voor het werk itself en een seperate dashboard applicatie die data uit het DMS trekt om dit om te vormen naar KPI's en hip te weergeven.

Dit heb ik getracht grafisch te weergeven in onderstaand schema


De structuur van een DocPack kan alsvolgt weergeven worden:

code:

PurchaseOrder123
 - WorkOrder456
   - NoodzakelijkDocument1
   - NoodzakelijkDocument2
   - NoodzakelijkDocument3
  - WorkOrder789
   - NoodzakelijkDocument1
   - NoodzakelijkDocument2
   - etc
  - WorkOrderetc
   -etc

Een DocPack bestaat uit ongeveer 80 a 90 documenten en de output is ongeveer 110 DocPacks per maand. Een beste berg data dus.

Nu eindelijk de concrete problemen:

• Is er een DMS waar jullie van weten dat dit soort zaken geintegreerd heeft (KPI's, dashboard, etc). Ik heb heel veel paketten bekeken en heb het nergens kunnen vinden, maar ik vraag het even voor de zekerheid.
• Daar de meeste measures en KPI's over de DocPacks zullen gaan (voortgang per stuk, totale progress, throughput, complexity, etc) is het belangrijk dat beide systemen over dezelfde data praten. Dit betekent dat de structuur van de DocPack zoals hierboven beschreven wordt gehanteerd in beide systemen. Ik breek er mijn hoofd over hoe ik die structuur kan opleggen in beide systemen. Ik dacht aan een custom-made script/programma waar de structuur gedefinieerd kan worden (PO en WO's) en er vervolgens vereiste documentatie aan elk onderdeel gehangen kan worden (een soort template dus). Deze template wordt gepusht naar beide systemen, resulterende in een folderstructure in het DMS en wat nieuwe regels in de tussenliggende database. Vervolgens draait een script eens per uur die alle data uit het DMS trekt, wat bewerkingen op toepast en opslaat in de tussenliggende database. Die wordt weer uitgelezen door de dashboard applicatie die er hippe grafiekjes van maakt en totalen van berekend.
• Ik denk persoonlijk dat bovenstaande zal gaan werken, maar aangezien ik weinig achtergrond in dit soort zaken heb weet ik niet of het een goede/slimme manier van werken is. Het vereist een extra database tussen beide systemen in en er moet een tool geschreven worden waarin de structuur gedefinieerd kan worden. Kan dit simpeler, makkelijker en/of beter?

Graag jullie advies!

[F_J_K]

Je beschrijving komt heel redelijk overeen met wat bij de NL overheid met een zaaksysteem (of via zaakgericht werken) gebeurt. Al kan dat natuurlijk ook komen dat ik in alles een spijker zie als ik een hamer heb ) Overigens niet 1-op-1 te vergelijken met case management zoals je dat misschien kent. Afhankelijk van de verdere complexiteit klinkt het alsof het al zonder maatwerk redelijk moet passen.

Een proces doorlopen met een aantal vastgestelde statussen, met een paar statussen waarop je kan rapporteren en rappeleren, en vooral ook met digitale dossiervorming tijdens het proces. Een KPI als complexity kan je er misschien opzetten in door bepaalde typen workorders (eenvoudig, middel, moeilijk) als eigen subzaak op te zetten.

[Clock]

Ik zie inderdaad de gelijkenissen met een dergelijk systeem wel in. Helaas zijn er ook flinke verschillen, zo draait het in dit geval meer om een filesystem-achtig-DMS met volledige functionaliteit voor onderling linken van files, retentiebeheer, collaboration, etc. Ook zijn de KPI's en metrics dusdanig anders dat er flinke aanpassingen gemaakt zouden moeten worden. Maar ik heb wel wat mooie inspiratie kunnen opdoen uit de zaaksysteem-systemen die ik heb bekeken!

Het ging mij meer om de wijze waarop het DMS en BIS aan elkaar gekoppeld worden. We hebben het hier overigens niet over echte enterprise-level systemen maar over SME-niveau. Doordat beide systemen betrekking hebben op dezelfde data/datastructure zal er een systeem moeten komen die die structuur opgelegd. Daar mijn ervaring op dit gebied niet uitputtend is ben ik wat onzeker over de manier zoals ik die in de startpost omschreef.

Ik heb zojuist de schematische situatie iets meer uitgewerkt, staat hier. Is de manier van de 2 systemen linken iets zoals jullie het ook zouden aanpakken?

[Turdie]

Misschien SharePoint met PerformancePoint Services erbij?

[Hooglander1]

Je bent nu al bezig met de oplossing, terwijl je eigenlijk nog niet weet wát je wilt meten.

Ik zou eerst een stap terug nemen, dus eerst goed gaan nadenken over wat je nu precies wilt weten. Dit is eigenlijk de stap die de beoordelaar moet doen. Welke informatie heeft hij nodig om een oordeel te vormen. Ga dan pas nadenken over de KPI's en hoe je die kan verkrijgen.

Als je die stap hebt gedaan is het handig om te gaan kijken naar een oplossing. Er zijn zoveel verschillende vormen en leveranciers van dashboards dat dat best veel kan zijn. Daar zul je dan zelf een pakketselectie op los moeten laten (of kijken of het te vinden is in het DMS zelf). Of neem deze informatie mee bij de pakketselectie van je DMS. (Al is het de vraag of je het daar heel zwaar mee wilt nemen).

Als je eerst gaat kijken naar de technische oplossing kom je er misschien wel achter dat je ook data uit andere applicatie wilt gaan gebruiken en heb je jezelf bij voorbaat al beperkt. Dat is zonde, daarnaast beperk je je qua functionaliteit wel heel erg tot bepaalde systemen die voor hun hoofdfunctionaliteit een stuk minder geschikt zijn.

[Clock]

shadowman12 schreef op zondag 16 december 2012 @ 14:29:
Misschien SharePoint met PerformancePoint Services erbij?

Dat zit tegenwoordig allemaal geintegreerd in SharePoint Server. Ik heb er een tijd naar gekeken maar het is zo'n ontzettend groot platform waar slechts 10% van gebruikt zal gaan worden. Ietwat overkill voor zo'n kleine afdeling.

Hooglander1 schreef op zondag 16 december 2012 @ 14:35:
Je bent nu al bezig met de oplossing, terwijl je eigenlijk nog niet weet wát je wilt meten.

Ik zou eerst een stap terug nemen, dus eerst goed gaan nadenken over wat je nu precies wilt weten. Dit is eigenlijk de stap die de beoordelaar moet doen. Welke informatie heeft hij nodig om een oordeel te vormen. Ga dan pas nadenken over de KPI's en hoe je die kan verkrijgen.

De KPI's zijn gedefinieerd en hangen allemaal samen met de documentflow en output van DocPacks. Daar het hele process geen directe waarde toevoegd aan het product (het is een order qualifier) is het financieel gezien niet zinvol om meer data te verzamelen over de performance van het process. Het standpunt van het bedrijf is dat dat meer kost dan dat het opleverd, en ik denk dat ze daar gelijk in hebben. Een mockup van een dashboard met KPI's staat in de uitwerking.

Voorafgaand aan deze stap is het volledige business process met inputs, outputs en trigger points in beeld gebracht, evenals een assesment van de huidige systemen en processdesign. Conclusie is dat de oude systemen niet voldoen en er gezocht moet worden naar een nieuw platform en de werkprocessen hieromheen te redesignen. Je hebt in zoverre wel gelijk met je opmerking in de zin dat het het traject vanaf het begin alleen gefocussed was op de document management zaken en de KPI stuff er later bij-in werd gedrukt.

Als je die stap hebt gedaan is het handig om te gaan kijken naar een oplossing. Er zijn zoveel verschillende vormen en leveranciers van dashboards dat dat best veel kan zijn. Daar zul je dan zelf een pakketselectie op los moeten laten (of kijken of het te vinden is in het DMS zelf). Of neem deze informatie mee bij de pakketselectie van je DMS. (Al is het de vraag of je het daar heel zwaar mee wilt nemen).

De dashboard functionaliteit is meegenomen in de requirements voor het DMS, echter blijkt uit de nu gaande selectie dat geen van de 10 geselecteerde DMS-pakketten hier punten op kunnen scoren. Statistics zijn in elk pakket te algemeen en niet aanpasbaar om deze situatie aan te kunnen.

Dat was ook de reden om eens goed naar de requirements te kijken, waarna de conclusie was dat we zoeken naar 2-systemen-in-1. BIS en DMS, beiden compleet verschillende systemen. Dat was de hele aanzet om te zoeken naar 2 systemen, welke als complicatie dan vervolgens met elkaar verbonden moeten worden.

Als je eerst gaat kijken naar de technische oplossing kom je er misschien wel achter dat je ook data uit andere applicatie wilt gaan gebruiken en heb je jezelf bij voorbaat al beperkt. Dat is zonde, daarnaast beperk je je qua functionaliteit wel heel erg tot bepaalde systemen die voor hun hoofdfunctionaliteit een stuk minder geschikt zijn.

Helemaal mee eens wat betreft eerst kijken naar technische oplossing. Ik denk zelf dat dat in dit geval nog wel meevalt. Na het opstellen van de requirements voor de complete oplossing (80% DMS requirements en 20% BIS requirements) liepen we tegen een probleem aan. Dat probleem proberen we nu op te lossen wat leidt tot de huidige situatie.

Edit: bedankt voor de reacties, dit soort discussies heb ik nodig maar zijn lastig met de rest van de (functioneel georienteerde) projectgroep

[Turdie]

Clock schreef op zondag 16 december 2012 @ 14:53:
[...]


Dat zit tegenwoordig allemaal geintegreerd in SharePoint Server. Ik heb er een tijd naar gekeken maar het is zo'n ontzettend groot platform waar slechts 10% van gebruikt zal gaan worden. Ietwat overkill voor zo'n kleine afdeling.

Hmm, en SharePoint met Excel Services en PowerPivot?

[Clock]

shadowman12 schreef op zondag 16 december 2012 @ 16:15:
[...]


Hmm, en SharePoint met Excel Services en PowerPivot?

Neem ik mee in de overweging. Dank voor de suggestie!