In tradionele datawarehousing wordt gewerkt met ETL batchprocessen. Data wordt maandelijks, wekelijks of zelfs nog frequenter geladen in het datawarehouse en gepresenteerd in bijvoorbeeld scorecards, rapporten en kubussen en daarnaast vinden er ook dataleveringen plaats.
Met B.I. 2.0 komt de data realtime binnen en wordt direct in een realtime datacache verwerkt. Dit opent mogelijkheden om niet alleen achteraf te verantwoorden maar ook mogelijkheden om te gaan sturen. Voorraden, wachttijden, fouten kunnen immers direct inzichtelijk gemaakt worden en op basis van deze informatie kan snel en direct ingegrepen worden.
B.I. 2.0 biedt dus kleinere latentietijden en er kan dus eerder ingegrepen worden in processen. Dit kan zelfs op geautomatiseerde wijze gebeuren. Daarnaast biedt BI 2.0 de mogelijkheid om inzicht te verschaffen over de toestand van processen.
Zo kan een callcenter agent aangeven wat er wanneer plaats heeft gevonden. Volgende vraag die dan meestal bij een klant rijst is de vraag: "En hoe lang gaat het nog duren?".
Om deze vraag van een klant te kunnen beantwoorden is nog meer nodig dan het inzicht wat er in de processen allemaal gebeurd is. In zo'n geval is er een inzicht in processtructuur nodig. Hoe zijn de processen opgebouwd, welke stappen zijn er te nemen, hoelang duren ze gemiddeld, zijn er achterstanden etc. Daarvoor is een zogenaamde procesboom nodig. Is deze er dan kan er niet alleen verantwoord worden, gestuurd worden maar ook nog eens gepland worden.
Het traject van verantwoorden naar sturen en zelfs plannen is een traject waarbij de DWH afdeling te maken kan krijgen met geheel andere klanten en geheel andere klantbehoeften. Een transitietraject voor een DWH afdeling is dan ook onvermijdelijk.
woensdag 7 november 2007
woensdag 25 juli 2007
Kenmerken van BI 2.0
BI 2.0 is driven by this need for intelligent processes and has the following characteristics:
Event driven. Automated processes are driven by events; therefore, it is implicit that in order to create smarter processes, businesses need to be able to analyze and interpret events. This means analyzing data, event by event, either in parallel with the business process or as an implicit process step.
Real time. This is essential in an event-driven world. Without it, it is hard to build in BI capabilities as a process step and nearly impossible to automate actions. By comparison, batch processes are informational - they report on the effectiveness of a process but cannot be part of the process itself unless time is not critical. Any application that involves trading, dynamic pricing, demand sensing, security, risk, fraud, replenishment or any form of interaction with a customer is a time-critical process and requires real-time processing.
Automate analysis. In order to automate day-to-day operational decision-making, organizations need to be able to do more than simply present data on a dashboard or in a report. The challenge is turning real-time data into something actionable. In short, businesses need to be able to automatically interpret data, dynamically, in real time. What this means in practice is the ability to compare each individual event with what would normally be expected based on past or predicted future performance. BI 2.0 products, therefore, must understand what normal looks like at both individual and aggregate levels and be able to compare individual events to this automatically.
Forward looking. Understanding the impact of any given event on an organization needs to be forward looking. For example, questions such as "Will my shipment arrive on time?" and "Is the system going to break today?" require forward-looking interpretations. This capability adds immediate value to operations teams that have a rolling, forward-looking perspective of what their performance is likely to be at the end of the day, week or month.
Process oriented. To be embedded within a process in order to make the process inherently smarter requires that BI 2.0 products be process-oriented. This doesn't mean that the process has been modeled with a business process management tool. Actions can be optimized based on the outcome of a particular process, but the process itself may or may not be explicitly defined.
Scalable. Scalability is naturally a cornerstone of BI 2.0 because it is based on event-driven architectures. This is critical because event streams can be unpredictable and occur in very high volumes. For example, a retailer may want to build a demand-sensing application to track the sales of every top-selling item for every store. The retailer may have 30,000 unique items being sold in 1,000 stores, creating 30 million store/item combinations that need tracking and may be selling 10 million items per day. Dealing with this scale is run of the mill for BI 2.0. In fact, this scalability itself enables new classes of applications that would never have been possible using traditional BI applications.
www.linkedin.com/in/pnierop
Event driven. Automated processes are driven by events; therefore, it is implicit that in order to create smarter processes, businesses need to be able to analyze and interpret events. This means analyzing data, event by event, either in parallel with the business process or as an implicit process step.
Real time. This is essential in an event-driven world. Without it, it is hard to build in BI capabilities as a process step and nearly impossible to automate actions. By comparison, batch processes are informational - they report on the effectiveness of a process but cannot be part of the process itself unless time is not critical. Any application that involves trading, dynamic pricing, demand sensing, security, risk, fraud, replenishment or any form of interaction with a customer is a time-critical process and requires real-time processing.
Automate analysis. In order to automate day-to-day operational decision-making, organizations need to be able to do more than simply present data on a dashboard or in a report. The challenge is turning real-time data into something actionable. In short, businesses need to be able to automatically interpret data, dynamically, in real time. What this means in practice is the ability to compare each individual event with what would normally be expected based on past or predicted future performance. BI 2.0 products, therefore, must understand what normal looks like at both individual and aggregate levels and be able to compare individual events to this automatically.
Forward looking. Understanding the impact of any given event on an organization needs to be forward looking. For example, questions such as "Will my shipment arrive on time?" and "Is the system going to break today?" require forward-looking interpretations. This capability adds immediate value to operations teams that have a rolling, forward-looking perspective of what their performance is likely to be at the end of the day, week or month.
Process oriented. To be embedded within a process in order to make the process inherently smarter requires that BI 2.0 products be process-oriented. This doesn't mean that the process has been modeled with a business process management tool. Actions can be optimized based on the outcome of a particular process, but the process itself may or may not be explicitly defined.
Scalable. Scalability is naturally a cornerstone of BI 2.0 because it is based on event-driven architectures. This is critical because event streams can be unpredictable and occur in very high volumes. For example, a retailer may want to build a demand-sensing application to track the sales of every top-selling item for every store. The retailer may have 30,000 unique items being sold in 1,000 stores, creating 30 million store/item combinations that need tracking and may be selling 10 million items per day. Dealing with this scale is run of the mill for BI 2.0. In fact, this scalability itself enables new classes of applications that would never have been possible using traditional BI applications.
www.linkedin.com/in/pnierop
dinsdag 24 juli 2007
De BI 2.0 visie
De BI 2.0 Visie
Het doel van BI 2.0 is om latentietijden te reduceren - dat is de tijd terugdringen tussen het optreden van een gebeurtenis en het ondernemen van een actie daarop - dit om de prestaties van de business te verbeteren. Bestaande BI architecturen worstelen hier momenteel mee.
Met BI 2.0 wordt data niet opgeslagen in een database en vervolgens geextraheerd voor analyse. BI 2.0 gaat middels de verwerking van een stroom gebeurtenissen. Zoals de naam als zegt verwerkt deze aanpak de stroom van berichten in het geheugen, hetzij parallell met de feitelijke business processen of als een proces op zich.
Dit komt er op neer dat men zoekt naar scenario's van gebeurtenissen, zoals patronen en combinaties van gebeurtenissen die elkaar opvolgen, die van belang zijn voor het businessprobleem waar men zich mee bezig houdt. Normaal gesproken bestaat de output van dergelijke systemen in vorm van real-time meetwaarden en notificaties of het direct initieren van acties in andere applicaties.
Het resultaat is dat analyse processen geautomatiseerd worden en niet meer afhangen van menselijk handelen, maar de mens in kan roepen als actie benodigd is.
BI 2.0 krijgt z'n data direct vanuit de middleware, de plek waar je normaal gesproken zoekt voor realtime data. Standaard middleware kan heel eenvoudig stromen van gebeurtenissen genereren voor analyse doeleinden die in-memory uitgevoerd worden. Als deze real-time gebeurtenissen vergeleken worden met prestaties uit het verleden kunnen problemen en mogelijkheden onmiddelijk automatisch geidentificeerd worden.
Het doel van BI 2.0 is om latentietijden te reduceren - dat is de tijd terugdringen tussen het optreden van een gebeurtenis en het ondernemen van een actie daarop - dit om de prestaties van de business te verbeteren. Bestaande BI architecturen worstelen hier momenteel mee.
Met BI 2.0 wordt data niet opgeslagen in een database en vervolgens geextraheerd voor analyse. BI 2.0 gaat middels de verwerking van een stroom gebeurtenissen. Zoals de naam als zegt verwerkt deze aanpak de stroom van berichten in het geheugen, hetzij parallell met de feitelijke business processen of als een proces op zich.
Dit komt er op neer dat men zoekt naar scenario's van gebeurtenissen, zoals patronen en combinaties van gebeurtenissen die elkaar opvolgen, die van belang zijn voor het businessprobleem waar men zich mee bezig houdt. Normaal gesproken bestaat de output van dergelijke systemen in vorm van real-time meetwaarden en notificaties of het direct initieren van acties in andere applicaties.
Het resultaat is dat analyse processen geautomatiseerd worden en niet meer afhangen van menselijk handelen, maar de mens in kan roepen als actie benodigd is.
BI 2.0 krijgt z'n data direct vanuit de middleware, de plek waar je normaal gesproken zoekt voor realtime data. Standaard middleware kan heel eenvoudig stromen van gebeurtenissen genereren voor analyse doeleinden die in-memory uitgevoerd worden. Als deze real-time gebeurtenissen vergeleken worden met prestaties uit het verleden kunnen problemen en mogelijkheden onmiddelijk automatisch geidentificeerd worden.
Ontsluiting van de events vanuit BAM van BizTalk
Voor het genereren van stuurinformatie halen we de eventlogs op in BizTalk. Echter wij hebben niet alle informatie nodig die voorhanden is in BizTalk. Daarom hebben wij een zogenaamde Management Informatie Bericht specificatie gemaakt. De inhoud van een Management informatie bericht moet voldoende zijn om onze gewenste stuurinformatie te genereren. Daarom hebben wij ervoor gekozen de volgende velden vanuit de BAM van BizTalk te onsluiten.
zondag 22 juli 2007
DWH eerder in de lucht dan operationele systemen
Het is opmerkelijk te noemen. Met BI 2.0 is het mogelijk de stuurinformatie in je datawarehouse eerder opgenomen te hebben dan dat de operationele systemen in werking zijn.
De clou zit hem in het goed afspreken van je interfaces en het feit dat in een SOA architectuur de besturing gescheiden is van de uitvoering. Voeg daaraan toe een gesimmulieerde stroom van XML-testberichtjes vanuit SOAtest (Parasoft) en je kunt direct aan de slag met de nodige POC's, testen en bouw van je Real-Time Data Cache, datawarehouse en rapportageomgeving.
BizTalk logt events en daarvan kan op voorhand een definitie voor een extratie van gemaakt worden. Dit hebben wij gedaan. We hebben vastgelegd waarneer berichtjes afgevuurd moeten worden en wat daar dan de inhoud van moet zijn. Vervolgens kun je met SOAtest een uitputtende stroom testberichten genereren.
Binnen ons project noemen wij die berichtjes MIB's (Management Informatie Berichtjes). Die zullen wij straks in werkelijkheid vanuit de BAM van Biztalk ontvangen. Deze MIB's zijn XML berichtjes van pakweg 1K groot zijn.
Wij vangen de MIB's op in een Real-Time Data Cache en daar verwerken we ze met behulp van parsers. Dit druppelgewijs binnenkomen van MIB berichtjes wordt bij ons dripfeed genoemd maar de juiste benaming hiervoor is tricklefeed. Het mechanisme wat de MIB's opvangt en verwerkt is zowel te upscalen als te outscalen. Dus indien er voor meerdere processen MIB's aangeleverd gaan worden is het gewoon een kwestie van bijplaatsen van servers die parsen.
Dit parsen gaat met behulp van een procesboom. Het komt neer op het intepreteren van de MIB's. Als er bijvoorbeeld een proces gestart wordt dan wordt er een MIB afgevuurd. Het parsingsysteem moet dan bijvoorbeeld bepalen dat vanaf dat moment de voorraad 1 afneemt, de doorlooptijd start en het onderhanden werk 1 toeneemt. etc. Op deze realtime datacache wordt ingeprikt met BO-excelcius. Hiermee hebben wij real-time stuurinformatie waarmee wij onder andere inzicht hebben in wie met welke activiteiten bezig is, wat de voorraad is, de ouderdom van de voorraad, het onderhanden werk etc.
Dagelijks worden aan het einde van de dag de MIB berichtjes middels een drip-en-flip mechanisme in ons datawarehouse gebracht waar ze uiteindelijk terecht komen in de activiteiten sterren. Wij doen dit dagelijks omdat als wij dit realtime zouden doen de rapportage voordurend wijzigen, hetgeen tot verwarring over cijfers kan leiden.
Deze stuurinformatie is op voorhand te genereren voordat processen ontworpen, gebouwd, getest en geimplementeerd zijn.
De clou zit hem in het goed afspreken van je interfaces en het feit dat in een SOA architectuur de besturing gescheiden is van de uitvoering. Voeg daaraan toe een gesimmulieerde stroom van XML-testberichtjes vanuit SOAtest (Parasoft) en je kunt direct aan de slag met de nodige POC's, testen en bouw van je Real-Time Data Cache, datawarehouse en rapportageomgeving.
BizTalk logt events en daarvan kan op voorhand een definitie voor een extratie van gemaakt worden. Dit hebben wij gedaan. We hebben vastgelegd waarneer berichtjes afgevuurd moeten worden en wat daar dan de inhoud van moet zijn. Vervolgens kun je met SOAtest een uitputtende stroom testberichten genereren.
Binnen ons project noemen wij die berichtjes MIB's (Management Informatie Berichtjes). Die zullen wij straks in werkelijkheid vanuit de BAM van Biztalk ontvangen. Deze MIB's zijn XML berichtjes van pakweg 1K groot zijn.
Wij vangen de MIB's op in een Real-Time Data Cache en daar verwerken we ze met behulp van parsers. Dit druppelgewijs binnenkomen van MIB berichtjes wordt bij ons dripfeed genoemd maar de juiste benaming hiervoor is tricklefeed. Het mechanisme wat de MIB's opvangt en verwerkt is zowel te upscalen als te outscalen. Dus indien er voor meerdere processen MIB's aangeleverd gaan worden is het gewoon een kwestie van bijplaatsen van servers die parsen.
Dit parsen gaat met behulp van een procesboom. Het komt neer op het intepreteren van de MIB's. Als er bijvoorbeeld een proces gestart wordt dan wordt er een MIB afgevuurd. Het parsingsysteem moet dan bijvoorbeeld bepalen dat vanaf dat moment de voorraad 1 afneemt, de doorlooptijd start en het onderhanden werk 1 toeneemt. etc. Op deze realtime datacache wordt ingeprikt met BO-excelcius. Hiermee hebben wij real-time stuurinformatie waarmee wij onder andere inzicht hebben in wie met welke activiteiten bezig is, wat de voorraad is, de ouderdom van de voorraad, het onderhanden werk etc.
Dagelijks worden aan het einde van de dag de MIB berichtjes middels een drip-en-flip mechanisme in ons datawarehouse gebracht waar ze uiteindelijk terecht komen in de activiteiten sterren. Wij doen dit dagelijks omdat als wij dit realtime zouden doen de rapportage voordurend wijzigen, hetgeen tot verwarring over cijfers kan leiden.
Deze stuurinformatie is op voorhand te genereren voordat processen ontworpen, gebouwd, getest en geimplementeerd zijn.
dinsdag 17 juli 2007
Realtime datawarehouse kan eerder live dan operationele systemen
't Is wel een raar idee om je Real Time Datawarehouse voor een groot deel te bouwen en te testen voordat je operationele systemen gereed zijn. Maar dat is toch echt wat er bij ons aan de gang is.
De truck zit hem in de scheiding van besturingsinformatie en de inhoudelijke informatie.
Over de inhoud van de besturingsinformatie hebben wij heldere afspraken gemaakt. We hebben zo exact mogeljk vastgelegd welke besturingsinformatie, informatie uit de event-logs in de BAM van BizTalk, wij willen hebben. De eerste berichten komen nu al binnen en wij werken momenteel aan complexere processen waaruit deze berichten in xml-formaat moeten komen.
Wij zijn daarom vroegtijdig aan de slag gegaan met de bouw van onze activiteitensterren en de laadscripts die deze sterren laden. Deze omgeving is inmiddels ook al operationeel.
Grappig om te zien dat je dus een generieke BI-omgeving met stuurinformatie voor een groot deel op kan trekken en kan testen zonder dat er ook maar een proces in ons operationele systeem geimplementeerd is. Als dan straks de processen in de operationele systemen een voor een live gaan vullen de rapporten zich vanzelf.
Het ontwikkelen van de stuurinformatie in een Real Time Datawarehouse en een traditioneel datawarehouse verloopt dus op verschillende manieren.
Ben benieuwd hoe nu in de komende maanden de ontwikkeling van verantwoordingsinformatie gaat verlopen.
De truck zit hem in de scheiding van besturingsinformatie en de inhoudelijke informatie.
Over de inhoud van de besturingsinformatie hebben wij heldere afspraken gemaakt. We hebben zo exact mogeljk vastgelegd welke besturingsinformatie, informatie uit de event-logs in de BAM van BizTalk, wij willen hebben. De eerste berichten komen nu al binnen en wij werken momenteel aan complexere processen waaruit deze berichten in xml-formaat moeten komen.
Wij zijn daarom vroegtijdig aan de slag gegaan met de bouw van onze activiteitensterren en de laadscripts die deze sterren laden. Deze omgeving is inmiddels ook al operationeel.
Grappig om te zien dat je dus een generieke BI-omgeving met stuurinformatie voor een groot deel op kan trekken en kan testen zonder dat er ook maar een proces in ons operationele systeem geimplementeerd is. Als dan straks de processen in de operationele systemen een voor een live gaan vullen de rapporten zich vanzelf.
Het ontwikkelen van de stuurinformatie in een Real Time Datawarehouse en een traditioneel datawarehouse verloopt dus op verschillende manieren.
Ben benieuwd hoe nu in de komende maanden de ontwikkeling van verantwoordingsinformatie gaat verlopen.
maandag 16 juli 2007
De zoektocht naar een procesboom
Procesboom vanuit proces ontwerptool, bijvoorbeeld BiZZdesigner
Het zou voor de hand liggen om de procesvolgorde uit je procesboom van je ontwerptool te halen. Echter dan moet aan een aantal voorwaarden worden voldaan die in de praktijk niet vervuld worden.
In de praktijk is het namelijk zo dat het ontwerp van het proces niet overeenkomt met de implementatie in de workflowtool, bij ons BizTalk. Dit heeft te maken met de beperkt exportfunctionaliteit van ontwerptools en de beperkingen van workflowtools om dergelijke ontwerpen een op een over te nemen. Niet alles wat in de ontwerptool gemoddeleerd wordt kan zo geimplementeerd worden in een workflowtool.
Door de verschillen van ontwerp en implementatie gaat de intepretatie van onze events in de Real-Time Data Cache uiteindelijke verkeerd. Daarnaast lopen we risico's bij het changemanagement van processen. Processen die wij aanpassen bestaan namelijk niet in de praktijk.
Tevens kun je in processen loops ontwerpen, een ontwerpregel zou moeten zijn dat loops niet voor mogen komen in de ontwerpen. Een procesboom genereren van een procesontwerp met loops zou leiden tot een oneindig aantal mogelijke procespaden.
Het gebruik van een procesboom die voortkomt uit een ontwerptool geeft niet weer of dat proces handig of onhandig ontworpen is. Daarvoor zou je cases moeten bekijken die door de flow gaan.
Procesboom vanuit een workflowtool, bijvoorbeeld BizTalk
Je kunt de procesboom ook afleiden uit de orchestratie in je workflowtool. Bij ons is dat BizTalk.
Belangrijk bij het verkrijgen van een procesboom uit een workflowtool is dat er slechts een versie van de workflow centraal geimplementeerd is. Over het algemeen zie je dat niet alle processtappen van klant tot klant in een workflowtool opgenomen zijn maar dat deze zich ook nog in andere systemen dan de workflowtool bevinden. Sturing van klant tot klant is daardoor alleen mogelijk indien alle systemen ontsloten worden en de procesbomen uit alle systemen tot een grote procesboom samengevoegd worden.
Om de procesboom uit BizTalk te genereren heb je een zeer ervaring expert op het gebied van BitTalk nodig. Iemand die inhoudelijke weet hoe de BizTalk repository functioneert, kennis heeft van *.Net en C#. Geen eenvoudige opgave om zo iemand te vinden.
Ook het gebruik van een procesboom die voortkomt uit een of meerdere workflowtools geeft niet weer of dat proces handig of onhandig ontworpen is. Daarvoor zou je cases moeten bekijken die door de flow gaan.
Procesboom opbouwen met behulp van event-logs
Tenslotte is er nog de mogelijkheid om de procesboom samen te stellen uit de eventlogs. Hoe je zoiets doet kun je lezen op de site van de Technische Universiteit in Eindhoven: http://www.processmining.org/. Het komt erop neer dat een procesboom automatisch gegenereerd wordt bij het analyseren van de event-logs.
Groot voordeel van deze aanpak is dat je informatie hebt over hoe een proces werkelijk doorlopen wordt. Met de tool ProM 4.1 kun je zien of processen onhandig of juist handig ontworpen zijn. Bovendien kun je van processen zoals ze geimplementeerd zijn een BPEL export maken die je hoogstwaarschijnlijk weer in BiZZdesigner in kan lezen. Daarmee kun je de ontwerpen van je processen beheersen.
Tweede voordeel is dat je de procesboom kan genereren vanuit event-logs van meerdere systemen.
Derde voordeel is dat je via deze procesboom de verschillen tussen ontwerp van een proces en de werkelijke implementatie aan het licht brengt. Hetgeen handig kan zijn voor het beheersen van je ontwerptraject.
Nadeel van deze aanpak is dat je niet weet of alle procespaden wel doorlopen zijn, waardoor je trickelfeed verwerkingsmechanisme in de Real Time Data Cache niet alle input van events verwerken kan. Dit probleem kan ondervangen worden door een uitpuntende set van testcases te maken en deze door BizTalk te halen. Je hebt dan uiteindelijk een event-log met alle mogelijke procespaden.
Handmatig een procesboom maken
Het is tevens mogelijk om een procesboom handmatig te maken in Excel. Echter als de ontworpen processen een klein beetje complex van aard zijn dan genereert dat al gauw duizenden regels. Onderhoud van een dergelijke procesboom in een SOA architectuur waarin processen snel kunnen wijzigen is een bijna niet uit te voeren opgave.
Het zou voor de hand liggen om de procesvolgorde uit je procesboom van je ontwerptool te halen. Echter dan moet aan een aantal voorwaarden worden voldaan die in de praktijk niet vervuld worden.
In de praktijk is het namelijk zo dat het ontwerp van het proces niet overeenkomt met de implementatie in de workflowtool, bij ons BizTalk. Dit heeft te maken met de beperkt exportfunctionaliteit van ontwerptools en de beperkingen van workflowtools om dergelijke ontwerpen een op een over te nemen. Niet alles wat in de ontwerptool gemoddeleerd wordt kan zo geimplementeerd worden in een workflowtool.
Door de verschillen van ontwerp en implementatie gaat de intepretatie van onze events in de Real-Time Data Cache uiteindelijke verkeerd. Daarnaast lopen we risico's bij het changemanagement van processen. Processen die wij aanpassen bestaan namelijk niet in de praktijk.
Tevens kun je in processen loops ontwerpen, een ontwerpregel zou moeten zijn dat loops niet voor mogen komen in de ontwerpen. Een procesboom genereren van een procesontwerp met loops zou leiden tot een oneindig aantal mogelijke procespaden.
Het gebruik van een procesboom die voortkomt uit een ontwerptool geeft niet weer of dat proces handig of onhandig ontworpen is. Daarvoor zou je cases moeten bekijken die door de flow gaan.
Procesboom vanuit een workflowtool, bijvoorbeeld BizTalk
Je kunt de procesboom ook afleiden uit de orchestratie in je workflowtool. Bij ons is dat BizTalk.
Belangrijk bij het verkrijgen van een procesboom uit een workflowtool is dat er slechts een versie van de workflow centraal geimplementeerd is. Over het algemeen zie je dat niet alle processtappen van klant tot klant in een workflowtool opgenomen zijn maar dat deze zich ook nog in andere systemen dan de workflowtool bevinden. Sturing van klant tot klant is daardoor alleen mogelijk indien alle systemen ontsloten worden en de procesbomen uit alle systemen tot een grote procesboom samengevoegd worden.
Om de procesboom uit BizTalk te genereren heb je een zeer ervaring expert op het gebied van BitTalk nodig. Iemand die inhoudelijke weet hoe de BizTalk repository functioneert, kennis heeft van *.Net en C#. Geen eenvoudige opgave om zo iemand te vinden.
Ook het gebruik van een procesboom die voortkomt uit een of meerdere workflowtools geeft niet weer of dat proces handig of onhandig ontworpen is. Daarvoor zou je cases moeten bekijken die door de flow gaan.
Procesboom opbouwen met behulp van event-logs
Tenslotte is er nog de mogelijkheid om de procesboom samen te stellen uit de eventlogs. Hoe je zoiets doet kun je lezen op de site van de Technische Universiteit in Eindhoven: http://www.processmining.org/. Het komt erop neer dat een procesboom automatisch gegenereerd wordt bij het analyseren van de event-logs.
Groot voordeel van deze aanpak is dat je informatie hebt over hoe een proces werkelijk doorlopen wordt. Met de tool ProM 4.1 kun je zien of processen onhandig of juist handig ontworpen zijn. Bovendien kun je van processen zoals ze geimplementeerd zijn een BPEL export maken die je hoogstwaarschijnlijk weer in BiZZdesigner in kan lezen. Daarmee kun je de ontwerpen van je processen beheersen.
Tweede voordeel is dat je de procesboom kan genereren vanuit event-logs van meerdere systemen.
Derde voordeel is dat je via deze procesboom de verschillen tussen ontwerp van een proces en de werkelijke implementatie aan het licht brengt. Hetgeen handig kan zijn voor het beheersen van je ontwerptraject.
Nadeel van deze aanpak is dat je niet weet of alle procespaden wel doorlopen zijn, waardoor je trickelfeed verwerkingsmechanisme in de Real Time Data Cache niet alle input van events verwerken kan. Dit probleem kan ondervangen worden door een uitpuntende set van testcases te maken en deze door BizTalk te halen. Je hebt dan uiteindelijk een event-log met alle mogelijke procespaden.
Handmatig een procesboom maken
Het is tevens mogelijk om een procesboom handmatig te maken in Excel. Echter als de ontworpen processen een klein beetje complex van aard zijn dan genereert dat al gauw duizenden regels. Onderhoud van een dergelijke procesboom in een SOA architectuur waarin processen snel kunnen wijzigen is een bijna niet uit te voeren opgave.
De noodzaak van een procesboom
Met BI 2.0 is het mogelijk om op nieuwe manieren te sturen. Het realtime genereren van voorspellende informatie is mogelijk.
Denk bijvoorbeeld aan het genereren van het antwoord op de vraag hoelang het verwerken van een aanvraag nog zal duren. Wil je daar antwoord op geven dan is het noodzakelijk dat je beschikt over een inzicht in welke processtappen er nog uitgevoerd moeten worden en hoelang deze nog zullen duren.
Om een antwoord op een dergelijke vraag te formuleren heb je een zogenaamde procesboom nodig. Een boom die alle mogelijke paden weergeeft waarlangs een aanvraag zou kunnen lopen.
Zo'n procesboom kun je ook gebruiken om een complexere KPI als first time right te bepalen. Je moet bij zo'n KPI namelijk weten wat het aantal geplande processtappen is en dat vergelijken met het werkelijk aantal genomen processtappen.
Bij het inrichten van je besturing is het handig goed na te denken over welke metertjes je wilt plaatsen. Heb je werkelijk zo'n KPI als First Time Right nodig; of voldoet het ook wel als je de doorlooptijd meet of de ouderdom van een voorraad kent. In zo'n geval heb je misschien je procesboom in het geheel niet nodig.
In ons geval hebben wij een procesboom nodig.
Denk bijvoorbeeld aan het genereren van het antwoord op de vraag hoelang het verwerken van een aanvraag nog zal duren. Wil je daar antwoord op geven dan is het noodzakelijk dat je beschikt over een inzicht in welke processtappen er nog uitgevoerd moeten worden en hoelang deze nog zullen duren.
Om een antwoord op een dergelijke vraag te formuleren heb je een zogenaamde procesboom nodig. Een boom die alle mogelijke paden weergeeft waarlangs een aanvraag zou kunnen lopen.
Zo'n procesboom kun je ook gebruiken om een complexere KPI als first time right te bepalen. Je moet bij zo'n KPI namelijk weten wat het aantal geplande processtappen is en dat vergelijken met het werkelijk aantal genomen processtappen.
Bij het inrichten van je besturing is het handig goed na te denken over welke metertjes je wilt plaatsen. Heb je werkelijk zo'n KPI als First Time Right nodig; of voldoet het ook wel als je de doorlooptijd meet of de ouderdom van een voorraad kent. In zo'n geval heb je misschien je procesboom in het geheel niet nodig.
In ons geval hebben wij een procesboom nodig.
Goed plan Goed team
Na het een en ander door de theorie gespit te zijn van hoe je een real-time datawarehouse neerzet is het van belang dat je het juiste team samenstelt. En waarschijnlijk is de keuze van het juiste team de belangrijkste beslissing die je als projectmanager te nemen hebt. Maak je daarin de juiste keuzes dan heeft je project een grote kans van slagen.
Als je een slecht plan hebt en een slecht team dan heb je veel werk te doen.
Heb je een goed plan en een slecht team, dan heb je iets minder werk.
Heb je een slecht plan maar een goed team, dan kun je er met elkaar wat van maken.
Heb je een goed plan en een goed team dan heb je een leuk project dat leuke resultaten neer kan zetten.
Uitgangspunt voor mijn project is dat ik wil werken met de toppers op DWH gebied, bij voorkeur met ervaring in Real-Time Datawarehousing (BI 2.0). Bij voorkeur een team dat ook nog eens resultaat commitment aan wil gaan en een enorme drive heeft om er voor te gaan. In een totaal overspannen markt is het niet echt een eenvoudig om zo'n team te vinden. Toch wist HotITem mij zo'n team te leveren. www.hotitem.nl
Als je een slecht plan hebt en een slecht team dan heb je veel werk te doen.
Heb je een goed plan en een slecht team, dan heb je iets minder werk.
Heb je een slecht plan maar een goed team, dan kun je er met elkaar wat van maken.
Heb je een goed plan en een goed team dan heb je een leuk project dat leuke resultaten neer kan zetten.
Uitgangspunt voor mijn project is dat ik wil werken met de toppers op DWH gebied, bij voorkeur met ervaring in Real-Time Datawarehousing (BI 2.0). Bij voorkeur een team dat ook nog eens resultaat commitment aan wil gaan en een enorme drive heeft om er voor te gaan. In een totaal overspannen markt is het niet echt een eenvoudig om zo'n team te vinden. Toch wist HotITem mij zo'n team te leveren. www.hotitem.nl
Hoe begin je aan een Real-Time Data Warehouse?
Op een gegeven moment zat ik daar dan, vroeg mij af: "hoe begin je nu met de bouw van een realtime datawarehouse? Is de aanpak anders dan de aanpak van de bouw van een traditioneel datawarehouse op basis van ETL technieken?"
Heb besloten maar op dezelfde manier te beginnen als aan de bouw van een traditioneel datawarehouse. Zo van: "onderweg zie ik wel waar de verschillen boven tafel komen."
Ben dus het intranet afgestruind op zoek naar de belanghebbenden en doelstellingen van de organisatie waarbinnen ik werk. Wat is het doel van de organisatie? Wat zijn de hoofdtaken van de organisatie? Waar moeten ze extern op verantwoorden en aan wie en wanneer in welke vorm? Zijn er targets voor kostenreductie, productiviteitsverbetering in de vorm van efficiency verbetering of doorlooptijdverkorting?
Ons realtime datawarehouse zal tenslotte die informatie moeten gaan verstrekken die bijdraagt tot het bereiken van die doelstellingen. Allemaal elementen voor ons functioneel ontwerp.
Het bleek dat de organisatie niet alleen te verantwoorden heeft. Key element in het verbeteringstraject is het invoeren van sturing op strategisch, tactisch en operationeel niveau. Maar ja, wat versta je dan onder strategisch, tactisch en operationeel sturen en verantwoorden? Wat doe je dan? Wat voor rapportages heb je daarbij nodig? Of gaat het niet om rapportages maar om dataleveringen of het ter beschikking stellen van enkele gegevens?
We zijn vanuit de theorie begonnen en hebben een zogenaamde besturingspyramide als basis genomen voor het inrichten van onze nieuwe management informatievoorziening. Een uitvoerige beschrijving van de theorie van "The Art of Managment" is te vinden op: http://123management.nl/index.html
Heb besloten maar op dezelfde manier te beginnen als aan de bouw van een traditioneel datawarehouse. Zo van: "onderweg zie ik wel waar de verschillen boven tafel komen."
Ben dus het intranet afgestruind op zoek naar de belanghebbenden en doelstellingen van de organisatie waarbinnen ik werk. Wat is het doel van de organisatie? Wat zijn de hoofdtaken van de organisatie? Waar moeten ze extern op verantwoorden en aan wie en wanneer in welke vorm? Zijn er targets voor kostenreductie, productiviteitsverbetering in de vorm van efficiency verbetering of doorlooptijdverkorting?
Ons realtime datawarehouse zal tenslotte die informatie moeten gaan verstrekken die bijdraagt tot het bereiken van die doelstellingen. Allemaal elementen voor ons functioneel ontwerp.
Het bleek dat de organisatie niet alleen te verantwoorden heeft. Key element in het verbeteringstraject is het invoeren van sturing op strategisch, tactisch en operationeel niveau. Maar ja, wat versta je dan onder strategisch, tactisch en operationeel sturen en verantwoorden? Wat doe je dan? Wat voor rapportages heb je daarbij nodig? Of gaat het niet om rapportages maar om dataleveringen of het ter beschikking stellen van enkele gegevens?
We zijn vanuit de theorie begonnen en hebben een zogenaamde besturingspyramide als basis genomen voor het inrichten van onze nieuwe management informatievoorziening. Een uitvoerige beschrijving van de theorie van "The Art of Managment" is te vinden op: http://123management.nl/index.html
zondag 15 juli 2007
Het eerste artikel waar ik tegenaan liep
Het eerste artikel waar ik tegen aanliep toen ik met realtime datawarehousing begon was:
"Real-Time Data Warehousing: Challenges and Solutions"
Een artikel dat geschreven is in augustus 2004 door Justin Langseth.
Dit artikel is een echte aanrader voor diegene die op hoofdlijnen keuzes wil maken voor zijn toekomstige realtime datwarehouse architectuur.
Bijna iedereen die op ons ontwerp traject betrokken raakte had dit artikel al gelezen. Ze gaven nagenoeg allemaal aan dat het een van de betere artikelen is dat ze over gelezen hebben.
"Real-Time Data Warehousing: Challenges and Solutions"
Een artikel dat geschreven is in augustus 2004 door Justin Langseth.
Dit artikel is een echte aanrader voor diegene die op hoofdlijnen keuzes wil maken voor zijn toekomstige realtime datwarehouse architectuur.
Bijna iedereen die op ons ontwerp traject betrokken raakte had dit artikel al gelezen. Ze gaven nagenoeg allemaal aan dat het een van de betere artikelen is dat ze over gelezen hebben.
Realtime Business Intelligence BI 2.0
Momenteel zijn we bezig met de bouw van een realtime datawarehouse. Maar is daar wel behoefte aan? Nou de wereld om ons heen is toch echt realtime aan het worden. Ook de wereld van een overheidsorganisatie.
In eerste instantie wordt er geroepen dat het nergens voor nodig is. Totdat je uitvoerig met elkaar gaat communiceren over de uitdagingen waar de organisatie voor staat en dan blijkt toch dat er wel een beetje behoefte aan wat realtime sturing is. Na nog wat weken communicatie blijkt dat er een sterke behoefte aan realtime informatie is.
Ik ben ervan overtuigd dat als ons Realtime datawarehouse eenmaal op volle toeren draait er een moment zal zijn dat men niet meer zonder kunnen. Het zou in de gedachte zoiets zijn als hetmet de ossekar door de modder ploegen om in Parijs te komen terwijl men ook de HSL kan nemen.
Laten we maar zeggen dat de behoefte latent aanwezig is. Het moet even tot de mensen doordringen, ze hebben even de tijd nodig om zaken te verwerken. Zeker als ze al jaren in een BI 1.0 stramien werken. BI 2.0 is hot, ook voor overheidsorganisaties !
In eerste instantie wordt er geroepen dat het nergens voor nodig is. Totdat je uitvoerig met elkaar gaat communiceren over de uitdagingen waar de organisatie voor staat en dan blijkt toch dat er wel een beetje behoefte aan wat realtime sturing is. Na nog wat weken communicatie blijkt dat er een sterke behoefte aan realtime informatie is.
Ik ben ervan overtuigd dat als ons Realtime datawarehouse eenmaal op volle toeren draait er een moment zal zijn dat men niet meer zonder kunnen. Het zou in de gedachte zoiets zijn als hetmet de ossekar door de modder ploegen om in Parijs te komen terwijl men ook de HSL kan nemen.
Laten we maar zeggen dat de behoefte latent aanwezig is. Het moet even tot de mensen doordringen, ze hebben even de tijd nodig om zaken te verwerken. Zeker als ze al jaren in een BI 1.0 stramien werken. BI 2.0 is hot, ook voor overheidsorganisaties !
Procesboom
Momenteel zijn we bezig met de bouw van een realtime datawarehouse. De noodzaak van realtime was in eerste instantie niet aanwezig. Echter door voortschrijdend inzicht blijkt de noodzaak toch wel degelijk aanwezig te zijn. Laten we het maar een latente behoefte noemen.
Mensen worden zich in de organisatie steeds bewuster van het feit dat de wereld toch echt meer realtime aan het worden is. Afspraken realtime online inplannen is toch wel handig. Fraude realtime en online detecteren is toch ook wel handig. Analyses op batchjobs uitvoeren terwijl ze lopen en ze op tijd af te breken is toch wel handiger dan er na een dag of twee dagen achterkomen dat de batchjobs verkeerd gelopen zijn. En dit is nog maar het begin van de mogelijkheden die men nu begint te zien.
De mogelijkheden voor het callcenter beginnen ook in zicht te komen. Als een klant belt direct in het scherm krijgen dat de klant nog mailings per post krijgt, met de tip om de klant te vragen of het in het vervolg per mail mag. Of de klant betaalt nog niet automatisch, bezoekt nog niet de FAQ-pagina en heeft nog geen account aangemaakt, neemt nog niet een ander product af.
Veel mogelijkheden dus om de klantwaarde te vergroten.
De BI 1.0 gedachte maakt langzaam aan ruimbaan voor de BI 2.0 gedachte.
Waarom deze blog
Ik vraag mij zelf een beetje af waarom ik deze blog nou begonnen ben.
Het heeft iets te doen met heet niet iedere keer mijn verhaal hoeven te doen. Maar ook iets met mijn irritatie van artikelen in een andere taal te moeten lezen. Daarnaast lijkt het mij wel leuk om over een aantal jaren eens terug te lezen wat mij nou precies op BI 2.0 gebied bezig hield.
Over business intelligence 2.0 kom je zo her en der versnipperd over het internet intepretaties tegen van wat BI 2.0 nou precies is. Daarvoor moet je vaak lange artikelen lezen in een andere taal. En voor het to the point komt ben je wel even aan het lezen.
Daarnaast mis ik een beetje de praktijk van waar ik tegen aanloop. Geen antwoorden op mijn vragen. Maar wellicht dat de antwoorden nog bedacht moeten worden. Kan mij haast niet voorstellen want ik kan toch niet de enige zijn die als eerste ergens tegenaan loopt denk ik dan. Wellicht dat via deze weg, een andere dan via mijn LinkedIn netwerk, nog wat mensen terugkoppeling zullen geven.
Het heeft iets te doen met heet niet iedere keer mijn verhaal hoeven te doen. Maar ook iets met mijn irritatie van artikelen in een andere taal te moeten lezen. Daarnaast lijkt het mij wel leuk om over een aantal jaren eens terug te lezen wat mij nou precies op BI 2.0 gebied bezig hield.
Over business intelligence 2.0 kom je zo her en der versnipperd over het internet intepretaties tegen van wat BI 2.0 nou precies is. Daarvoor moet je vaak lange artikelen lezen in een andere taal. En voor het to the point komt ben je wel even aan het lezen.
Daarnaast mis ik een beetje de praktijk van waar ik tegen aanloop. Geen antwoorden op mijn vragen. Maar wellicht dat de antwoorden nog bedacht moeten worden. Kan mij haast niet voorstellen want ik kan toch niet de enige zijn die als eerste ergens tegenaan loopt denk ik dan. Wellicht dat via deze weg, een andere dan via mijn LinkedIn netwerk, nog wat mensen terugkoppeling zullen geven.
Start van mijn blog
Welkom op mijn nederlandstalige blog over business intelligence 2.0. U treft hier schrijfsels aan over de uitdagingen die ik tegenkom bij het implementeren van business intelligence 2.0 oplossingen. Daarnaast zal ik wat artikelen vertalen uit het engels en duits. Wellicht dat dat voor anderen interessant kan zijn.
Abonneren op:
Posts (Atom)
