Het is inmiddels 2009. Voor mij betekent dit dat het al weer ruim tien jaar geleden is dat ik mijn eerste kennismaking had met business intelligence. In mijn geval was dat Business Objects. Wanneer ik wat meer afstand neem van deze conclusie dan blijkt deze onjuist. Immers, ik was de jaren ervoor al bezig om met behulp van MS Access rapportages te bouwen op onze backoffice-gegevens. Eigenlijk was dit ook BI. Wat miste was de visie op de essentie van wat BI maakt wat het is: geïntegreerde informatie om activiteiten te kunnen plannen, uit te voeren, te controleren en zo nodig bij te sturen. Met MS Access kwamen we er ook wel, maar BO vertelde het verhaal en had tooling die het werk nog weer net iets makkelijker maakte. Mijn inzicht in de potentie van BI vergrootte mijn enthousiasme over toekomstige mogelijkheden toen enorm. Nu zijn er weer twee trends waarvan ik vermoed dat ze de komende jaren in de schijnwerpers zullen staan. Dit is de integratie met de zogenaamde ongestructureerde data en een integratie met bedrijfsprocessen. Over deze laatste wat meer.
Waar ik tien jaar geleden het inzicht had dat het niet ging om het rapport maar om de geïntegreerde stuurinformatie, heb ik nu het inzicht dat de informatie nooit los gezien moet worden van het bedrijfsproces. Ook dit weten en doen we eigenlijk al, maar de potentie is veel groter. Wat bedoel ik hiermee? Ik zal dit toelichten met een voorbeeld.
Wellicht herkennen enigen van ons de vraag om een rapport/kubus te ontwerpen met een overzicht van bijvoorbeeld verholpen storingen per artikel per medewerker per maand. Verondersteld dat de gevraagde informatie van juiste kwaliteit met de juiste dimensies in de bronsystemen is vastgelegd, wordt er dan uitgekeken naar het rapport, waarna conclusies worden getrokken als bijvoorbeeld "ja ja, dat dachten we wel", of "goh, waarom verhelpt Annelies zoveel meer storingen op de applie313 dan Herman?". In dat tweede geval ontstaat er een nieuwe vraag naar een nieuw rapport. De business case in deze gevallen is vaak discutabel.
Wanneer we het onderliggend proces als uitgangspunt nemen en dus zouden beginnen met het beschrijven en beheren van het proces van storingsafhandeling, dan biedt dit een aantal belangrijke voordelen waarvan ik er een aantal in willekeurige volgorde zal bespreken.
- Impliciete kennis is vooraf beschreven. Het feit dat Annelies specifiek geschoold is op applie313 en daarom alle stroringen hierop op haar naam krijgt en oplost is hierin expliciet bekend. Rapporten die open deuren rapporteren hebben we niet meer nodig en worden niet gemaakt.
- Normen zijn bekend en beargumenteerbaar. Kritische knooppunten in het proces zijn zichtbaar en vooraf is bekend welke gegevens belangrijk zijn voor sturing van het proces en welke 'nice to have' zijn. Vooraf is bijvoorbeeld bekend boven welke waarde processen gaan vastlopen.
- Informatie krijgt een kader en een doelstelling. Duidelijk wordt waarom bepaalde informatie van belang is. In het voorbeeld zou weleens de doorlooptijd van storingen belangrijker kunnen zijn dan het aantal. Of misschien het aantal gemelde storingen in relatie tot het aantal opgeloste.
- Toegevoegde waarde van BI wordt duidelijker. De toegevoegde waarde van informatie kan worden benoemd in concretere termen dan 'betere besluitvorming'.
- Corporate performance management heeft een logische plaats in je informatie management. Bedrijfsvoering is immers ook een proces. Klanttevredenheid als resultante van een goed management van storingen heeft hierin een logische plaats.
- Prioriteitstelling van werkzaamheden wordt makkelijker. Kritische processen behoeven eerder informatievoorziening van niet kritische.
- Noodzaak voor metadata-afstemming en datakwaliteit wordt beter zichtbaar. Uit de procesbeschrijving blijkt de relevantie van brondata. Nastreven van uniforme datadefinities en juiste data wordt hierin ondersteund.
- Mogelijkheid organisatiebreed (her)gebruik van logica (business rules) wordt door deze werkwijze eerder inzichtelijk.
Met de verdere ontwikkeling van technologie die niet alleen het beschrijven van processen ondersteunt, maar die in enkele gevallen ook ondersteuning biedt aan de daadwerkelijke uitvoering ervan, denk ik dat we nog veel van de relatie tussen BI en processen kunnen verwachten.
Bovenstaand inzicht is niet nieuw: het proces is altijd al belangrijk geweest. Maar goed, dat betoogt Marco Bussemaker ook niet. Wat nog interessanter is (en ik weet niet of hij daar ook op focust) h?e dergelijke proceskennis in een rapport is terug te vinden. In feite zorgt het genoemde beschrijven en beheren van het proces voor een groot aantal nuances bij het lezen van een dergelijk rapport. Helaas worden dergelijke nuances vaak niet meegenomen bij het bekijken van de cijfers. Hoe vaak zal een gebruiker eerst uitgebreid in een procesbeschrijving of rapportdefinitie duiken alvorens deze te openen? Tuurlijk, een operationele gebruiker van BI zal deze kennis veelal paraat hebben. Echter, hoe groter de afstand tot de werkvloer, hoe minder van dergelijke kennis aanwezig is, maar hoe groter de impact van beslissingen o.b.v. de getoonde gegevens.
De ultieme uitdaging is aldus hoe de proceskennis (en alle daaruitvolgende nuances) over de in het rapport getoonde cijfers in ??n en het zelfde overzicht terecht kunnen komen. Proceskennis: anytime, anywhere, any report.
In het streven naar ‘operational excellence’ is dit een aardige structuur om als startpunt te gebruiken. Maar betekent Business Intelligence in relatie tot processen dat je proceskennis in rapporten terug vindt zoals Jasper de Vries dat aangeeft? Deels wel natuurlijk; echter het maken van rapporten moet niet de focus zijn. Het goed laten verlopen van het proces, daar gaat het om. Dit kan je realiseren door de relevante events te volgen, ze in de context van een proces te kunnen plaatsen, en dan daarop alerts te kunnen definieren. Een alert bijvoorbeeld wanneer het proces op een bepaald punt niet voldoende capaciteit (resources) heeft of dreigt te krijgen. Of een alert wanneer er bijvoorbeeld een order in een processtap langer dan 1 dag vast zit. Of een alert wanneer de loop van het proces afwijkt van het gewenste verloop. Dit soort informatie behoeft geen rapport, het gaat er om dat de relevante persoon deze alert op de juiste tijd krijgt.
En daarmee kom je mijns inziens richting Business Process Intelligence, het huwelijk van Business Intelligence met Business Activity Monitoring de operationele berdijfsprocessen. (Andere gebruikte benaming in de markt is ook BI 2.0, Operational BI). Als je meer interesse hebt in dit vakgebied, kijk dan eens naar het TDWI artikel van Wayne Eckerson, Best Practices in Operational BI – Converging Analytical and Operational Processes (zie http://www.tdwi.org/research/display.aspx?ID=8621). Momenteel ben ik bezig met een verkenning op dit gebied: hoe ver zijn organisaties in Nederland hiermee? Ik heb ben zelf al eens betrokken geweest bij een implementatie, in dit geval met Altosoft, en zie de enorme potentie hiervan. Maar voor een beter begrip vanuit de markt zoek ik contact met ervaren consultants (die de problematiek herkennen), business process owners (die het probleem hebben), die hieraan willen meewerken. Ik nodig je uit om dan contact met mij op te nemen (bijvoorbeeld via LinkedIn of via wbakker [at] bi-vision.nl).
De samenhang op technologisch gebied ligt nog veel dieper…
Proces-modelleringstools worden steeds professioneler. Een proces wordt leidend voor zowel ontwikkeling als het toekomstig beheer van systemen.
Als we een proces beschouwen als een stroom met een begin- en eindpunt, bestaande uit objecten waarbij onderlinge interactie visueel gemaakt is, dan kunnen we goed begrijpen dat deze technologie ook breder in te zetten is. In de ERP-ontwikkeling is het al goed mogelijk om vanuit proces-design het ERP-pakket op maat te configureren. Dit doorvertalend naar BI zien we dat data, ETL en rapportages als een soort proces gemodelleerd worden.
Deze filosofie doortrekkend wordt modellering volgens Kimball en/of Inmon slechts een kwestie van configuratie. Doordat proces-modelleringstools ook het OTAP-proces kunnen volgen, staat de wereld open voor basisapplicaties waarbij de BI-omgeving op maat geconfigureerd wordt.
Omdat er dan geen (of in ieder geval minder) maatwerkontwikkeling nodig is, betekent dit enorme besparingen voor toekomstig beheer.
Mijn eerste reactie was er ��n van ‘what else is new?’. Immers BI en CPM benaderen we toch altijd al vanuit het te ondersteunen bedrijfs- of specifieker sturingsproces! Maar goed, eigenlijk geeft Marco dat zelf ook wel aan. En daarbij is het nooit erg om af en toe een open deur nog iets verder open te trappen, zeker niet voor ‘de goede zaak’!
Waar denk ik wel een goed punt wordt gemaakt, is de mogelijkheden om dat tegenwoordig, gebruikmakend van geschikte technologische hulpmiddelen, ook concreet op de werkplek van de manager-medewerker te ondersteunen. Dit uit zich dan, naast adequate support van het (sturings)proces, in collaboratieondersteuning en content managementachtige zaken en een soepele link naar het gehanteerde communicatieplatform. Zodat ��n en ander ook daadwerkelijk ?actionable? wordt.
@ Wietse Erg herkenbaar wat je schrijft. Heb mij ook uitvoerig bezig gehouden met deze problematiek en een realtime datawarehouse met een datacache gebouwd op een SOA-architectuur. Daar heb ik aardig wat over geschreven op mijn weblog. http://businessintelligence20.blogspot.com.
Het genereren van rapporten wordt door implementaties van realtime BI steeds minder belangrijk en inderdaad moest informatie meer en meer in relatie gezien worden tot het proces. En daarbij zie je dat rapporten nog wel blijven bestaan in de strategische en tactische informatie voorziening, maar dat er in de operationele reporting meer gewerkt wordt met korte overzichtjes en allerting- /trigger-management. Precies jouw punt en waarvoor Altosoft inderdaad schitterende software heeft. Zeker ook omdat Altosoft dusdanig in elkaar gezet is dat het een aantal hobbels waar ik even aan Marco over schrijf platslaat.
@Marco Ook wat jij schrijft is zeer herkenbaar. Er is veel te verwachten maar er zijn ook een hoop hobbels te nemen. Grootste struikelblokken die ik tegengekomen zijn:
1) Ontwerptools sluiten vaak niet aan bij de implementatie van workflows in tooling zoals bijvoorbeeld Bizztalk. In ontwerptools worden nogal eens processen ontworpen die in de processturingstools niet te implementeren zijn. Na handmatige aanpassingen in de procesflows komen dan de ontwerpen niet meer overeen met de implementatie. Het gevolg is dat mapping van events op processtromen niet plaats kan vinden. Een struikelblok waar ik alleen nog maar gezien heb dat Aqualogic van BEASystems daar iets mee doet.
De volgende hobbel is de implementatie in workflowtools. Veelal houdt met zich bij implementatie van processen in workflowtools niet aan de standaarden zoals BPEL compliant ontwerpen en implementeren. Daardoor is het weer niet mogelijk voor datawarehouses om het geheel van de procesverlopen (de zogenaamde processboom) goed te exporteren en binnen te halen in een engine die de content uit de realtime datacache gaat mappen op de processen om vervolgens KPI’s te berekenen voor de alerting zoals genoemd door Wietse.
Derde grote hobbel is het beheersprobleem door snelle procesversioning. Door introductie van SOA architecturen waarin processen snel kunnen wijzigen loop je al gauw aan tegen de problemen van het niet kunnen implementeren van ontworpen processen in workflowtools en daardoor ontstaat na export van procesbomen problemen bij het interpreteren van wat er gebeurd als er een berichtje binnenkomt van een opgetreden event. (berichtjes over events die afgevuurd worden kunnen niet juist gemapt kunnen worden op processen). Snelle procesversioning gaat hand in hand met snelle wijzigingen in hoe events geintepreteerd dienen te worden. Veranderd een proces dan heeft dat onmiddellijk tot gevolg dat er in rapportages anders naar gegevens gekeken moet worden. Leuk he die snelle proceswijzigen door implementatie van SOA-architecturen ? 🙂 Weet je om de haverklap niet meer wat je cijfers in je rapporten nog voorstellen.
Mijn conclusie…. er is veel te verwachten alleen de tooling is er nog niet helemaal klaar voor. De procesontwerptools niet. De workflow tools integreren nog niet echt goed met de procesontwerptools (Aqualogic is een uitzondering). Workflowtools exporteren nog niet richting standaard RealTime Data Caches (Die zijn er volgens mij nog niet). Hier biedt Altosoft inmiddels een goed alternatief.
En last but not least… ik ken nog maar heel weinig experts in Nederland op dit gebied. Nog geen tien.
BI is veel meer dan alleen ‘u roept en wij bouwen’. Maar helaas wordt BI nog te vaak benaderd als een technisch IT trucje. Bij het maken van een BI-oplossing moet altijd worden stilgestaan bij het waarom van de vraag. Wat gaan we hiermee oplossen? Met andere woorden: wat is het doel? Een proces leidt tot een doel en daarom onderschrijf ik ook de toegevoegde waarde van een procesperspectief voor BI.
Een ander punt is dat de druk toeneemt om sneller te beslissen, bijvoorbeeld als gevolg van de huidige economische omstandigheden. BI werkt daarin ondersteunend. Om die snelheid te kunnen waarmaken zal BI dichter op het (operationele) proces moeten zitten. BI hoort daarom niet thuis bij enkele specialisten maar is juist het hardst nodig op de werkvloer.
In de BI hebben we Operationele Rapportages/informatie en Managementinformatie. Deze Managementinformatie kan ontworpen zijn voor verschillende managementlagen. Kijkend naar managementinformatie die tegen de uitvoering aanzitten dan wil ik het volgende stellen: Gelukkig kunnen we met moderne BI-tools flexibele rapportages ontwerpen met sorterings- en inzoom-functionaliteit (drill-down) die de gebruiker in staat stellen de informatie op vele verschillende manieren te bekijken. Dit kan vaak tot op het transactieniveau waarbij vele opkomende vragen beantwoord kunnen worden. Hier kan soms ook met Alerts op gewezen worden. Het is inderdaad van groot belang dat rapporten gemaakt zijn met begrip van het proces en begrip van welke factoren van belang zijn voor de aansturing en uitvoering van het proces. Flexibiliteit en Proceskennis bij zowel opsteller als gebruiker van de informatie zijn belangrijk!
Reactie #1 BI en Performance Management richten zich al vaak op rapportages en ondersteuning van bedrijfsprocessen, door gegevens te extraheren en erover te rapporteren, of processen als onderwerp van bijvoorbeeld planning en budgeting.
Andersom staat ook al enige jaren in de belangstelling, we noemden dat bij Gartner “business activity monitoring”. Dit draait om het inbedden van BI in de processen zelf. Een slim stukje techniek dat in een call center een aanbeveling doet aan de agent om iets te doen of te laten. Of een algoritme dat in een schadeverwerkingsproces beslist of een expert nodig is of niet. Of een fraude-detectie module die geldstroom-processen volgt en ingrijpt waar nodig.
Het klassieke deel (BI/PM rapporterend over processen) is niks nieuws en werkt al jaren goed (en er zijn allerlei best practices). Het tegenovergestelde, BI als onderdeel van het proces, is theoretisch niet zo nieuw (in de belangstelling sinds 2001), maar deze trend gaat een STUK langzamer dan verwacht.
Hier is dus nog veel te leren.
Reactie #2 In de reacties tot nu toe wordt voornamelijk gesproken over “operational excellence”, het ondersteunen van bedrijfsprocessen. Maar hoe zit het met de ondersteuning van managementprocessen, oftewel “management excellence”?
Managementprocessen zijn helemaal niet zo goed gedefinieerd als bedrijfsprocessen. We snappen allemaal “order to cash”, “procure to pay” en “hire to retire”, deze processen zijn beschreven en we hebben ze onder controle. Dit inzicht bestaat niet voor managementprocessen.
Ik heb de laatste anderhalf jaar een onderzoeksproject geleid dat zich richtte op managementprocessen. In totaal hebben we er zes gedefinieerd:
– Gain to sustain. Het proces dat zich richt op stakeholderinteractie, stakeholderbijdragen en stakeholderverwachtingen
– Investigate to invest. De link met competitive intelligence, en de blik op de markt.
– Design to decide. Het strategieformuleringsproces dat traditional buiten BI/PM ligt, maar onterecht
– Plan to act. De integratie van financiele en operationele plannings en budgetteringsactiviteiten.
– Analyze to adjust. Het onderkennen van relaties tussen verschillende bedrijfsonderdelen (waardeketenanalyse, strategy maps)
– Record to report. Rapportageprocessen intern en extern.
Het ondersteunen van managementprocessen gebeurt momenteel veel te impliciet. BI geeft “inzicht”, maar wat daarmee gedaan wordt is meestal niet duidelijk. PM help Planning en Control, maar hoe is niet duidelijk.
Ik heb inmiddels vele workshops wereldwijd gedaan, en getest wie managementprocessen en besluitvormingsprocessen “modelleert” als onderdeel van een BI of PM project. Dit gebeurt nauwelijks. Een grote omissie.
Reactie #3 Er moet nog veel gebeuren om BI en procesmanagement bij elkaar te brengen. De wereld van proces en de wereld van data zijn altijd heel verschillend geweest. Dit begint al bij IT-opleidingen. In mijn eigen opleiding werd in het eerste semester al duidelijk dat er mensen waren die “proces” begrepen, en andere mensen die meer tot “data” waren aangetrokken.
Eigen methoden, eigen projecten, eigen domeinen, eigen alles.
Dit is langzaam aan het veranderen. Dat heeft te maken met een interessante paradox rondom SOA en de behoefte aan slimmere en meer flexibele processen.
In een SOA moet je proceslogica en gegevens scheiden (in tegenstelling tot huidige systemen). Anders kun je de componenten alsmede de data niet hergebruiken. SOA’s maken het ook mogelijk om BI en proces bij elkaar te brengen, middels “business activity monitoring” componenten. Zie hier de paradox: je moet proces en gegevens scheiden om ze te kunnen combineren.