Aan de ene kant laten computerprogramma’s, meer bepaald datamining-algoritmes, toe om te leren uit vaststellingen gemaakt in het verleden, en kunnen zij op wetenschappelijk verantwoorde wijze aanleiding geven tot proactieve risicobepaling. De gebruikers dienen wel te beseffen dat het gaat om risico’s, en geen bewijzen. Controle ten gronde, of zelfs ter plaatse, is nodig. Maar datamining kan dus duidelijk bijdragen tot het efficiënter en doelgerichter werken van de overheid.
Bovendien kan automatisatie inderdaad willekeur en voorkeursbehandeling tegengaan, als daar sprake van zou zijn. Zo stelt ook de fiscus, volgens het artikel: “Sinds enkele jaren gebruikt de fiscus een computersysteem om te bepalen wie een controleur op bezoek krijgt. Op die manier wil de overheid willekeur en voorkeursbehandelingen vermijden.”
De tegenstanders, vaak inspecteurs en controleurs zèlf (maar lang niet allemaal), kunnen argumenteren dat de digitale selectie op basis van risicoprofielen net voor een ongelijke behandeling zorgt. Moeten we daar dan uit besluiten dat gelijke behandeling alleen kan mits controledoelen volledig random geselecteerd worden?

Een moderne overheid, die met minder middelen meer resultaat wil, zal niet iedereen kunnen controleren. Het is ook niet haalbaar, dat iedereen om de zoveel jaar gecontroleerd zou worden. Met het huidig effectief, zouden er immers teveel jaren tussen liggen. Maar controles ten gronde zijn nodig, omdat op basis van aangiftes en andere beschikbare digitale gegevens alleen, de juistheid en waarheid van aangegeven data niet kan bepaald worden (cfr. BOYDENS I., “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium”. In ASSAR S., BOUGHZALA I. et BOYDENS I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011, p. 116 e.v.).

Gegeven dat selectie dus nodig is – is ieder selectieprincipe, dat niet volledig random (en dus blind) is, dan ongelijk en oneerlijk?

Ongelijk misschien wel, maar is dat oneerlijk?

Belastingplichtigen (individuen èn organisaties) gedragen zich niet gelijk – misschien is een daarop gerichte, wetenschappelijk verantwoorde (ongelijke, zo u wil) selectie dan wel eerlijk? Zolang de behandeling en afhandeling van de gecontroleerde op gelijke (en eerbare) wijze gebeurt, kan men toch stellen dat de overheid naar de geest een gelijke behandeling nastreeft – laat staan naar de letter.

In mijn ervaring als dataminer blijken de beste predictieve modellen steeds diegene die zich uitdrukken (dankzij bloed, zweet en tranen in doorgedreven business-analyse) in termen van gedrag (van een systeem, en waarom ook niet van een individu of organisatie). En dus niet alleen in termen van statische variabelen. Dit is een aspect dat ik als best practice wel zou willen meegeven aan iedereen die te maken heeft met selectie, en hopelijk gelijke en eerlijke behandeling nastreeft.

Tegelijk moet bij dit alles een dubbele caveat geformuleerd worden.
Ten eerste moet men ervoor zorgen dat de, overigens onbetwistbaar noodzakelijke, inspecteurs en controleurs niet tot “aapjes” of papegaaien gereduceerd worden, en dat hun terreinervaring blijvend gevaloriseerd wordt. Zowel bij de ontwikkeling van datamining-gedreven systemen als de evolutie ervan, en de ontwikkeling van feedback-systemen die vaststellingen en resultaten registeren. Telkens opnieuw blijkt dit cruciaal voor succes.
Ten tweede, en dit sluit naadloos aan bij de terreinervaring van zulke inspecteurs en controleurs (en waarom niet, ook die van andere betrokken partijen), moet men steeds, naast datamining- en andere geautomatiseerde risicogedreven criteria, tegelijk andere selecties toelaten. Enerzijds random, om minstens de mogelijkheid te verzekeren dat iedereen aan de beurt kan komen – ook degene die onder de reeds geïnstalleerde radars doorglippen. Anderzijds kan de voeling met het terrein van onschatbare waarde zijn om snel genoeg, doelgerichte controleacties uit te voeren. Mits duidelijke afspraken en geregistreerde motivatie voor zulke keuzes, moet dit kunnen.

Verder wil ik nog inpikken op de 80/20 (%) verdeling voor de controles. Zoals gezegd in het artikel worden op dit moment 80% van de controles automatisch geselecteerd op basis van datamining. Of dit een goede verdeling is, hangt af van wat men zou kunnen noemen de dekkingsgraad van de geïmplementeerde predictieve modellen en risicoprofielen t.o.v. de zich in de werkelijkheid voordoende fenomenen en scenario’s. De datamining-modellen worden gevoed met voorbeelden van een welbepaald type probleem of doel. Indien uit de vaststellingen in het kader van de 80% op datamining geïnspireerde controles blijkt dat men steeds dezelfde, beperkte set van resultaten boekt, terwijl men vroeger (of nu, in het kader van de 20% anderszins geïnspireerde controles) meer verschillende – laat staan, belangrijkere – vaststellingen en rechtzettingen optekende, dan lijdt men er duidelijk aan teveel in dezelfde vijver te vissen, en is de 80/20 regel hier aan herziening toe. Of het dan 50/50 moet zijn? Men doet er goed aan te luisteren naar het terrein, het te proberen, en vervolgens rigoureus de resultaten te registreren en te vergelijken. Meten is weten.
Opletten trouwens: de ene controle is de andere niet. Met inbegrip van de afhandeling van onderzoeken tot en met het resultaat, zijn er zwaardere dossiers en lichtere. Niets zegt dus dat de totale effort van inspecteurs en controleurs per dossier diezelfde 80/20-verdeling zal volgen. En voor de 20% anders gekozen controles, moet er ook voldoende tijd zijn om de selectie op een degelijke manier te doen.

Besluit
Het is mijn stelling dat analytisch gedreven werken, het aansturen van kernprocessen op basis van data en gekwantificeerde risico’s, niet fundamenteel verkeerd, ongelijk, of oneerlijk is. Meer nog, een moderne overheid moet zich in de huidige budgettaire omstandigheden verplicht zien om efficiënt en doelgericht te werken, en de hiertoe beschikbare, wetenschappelijk verantwoorde middelen in te zetten. Echter zonder blind te worden voor de beperkingen daarvan. Er is een gulden middenweg tussen automatisatie en voeling met het terrein.

Driven by Results, Governed by Risks

De meeste business-processen zijn uiteraard ingericht met een welbepaald doel voor ogen. Bij de behandeling van een patiënt: genezing. Bij de opvolging van verschuldigde betalingen van ondernemingen aan de overheid: tijdige inning. Enzovoort.

We stellen echter vast dat de complexiteit van business-processen, het aantal stappen, vertakkingen, acties en uitzonderingen, veelal is ingegeven is door risicobeheersing. Het doel is immers in wezen: genezing zonder complicaties en zonder negatieve bijwerkingen op langere termijn. (We zwijgen hier best over wat het doel moet zijn als genezing niet mogelijk is. Maar in die context moet de vraag zeker ook gesteld worden.) In het geval van de regelmatige inning, kan het doel ook de langdurige financiële gezondheid van beide partijen zijn, met zo positief mogelijke invloed op tewerkstelling.

Welk proces is in deze omstandigheden optimaal? In het geval van een zijtak die een specifieke risicogroep anders afhandelt, welke criteria bepalen het behoren tot deze risicogroep? In het bijzonder, wanneer er manuele stappen zijn, wanneer er keuzes gemaakt moeten worden die zich beroepen op de ervaring van de business-user, kan men zich de vraag stellen: wat is optimaal? Is de leidraad, die ooit is opgesteld, wel optimaal? En als hij destijds goed was, is hij nog wel aangepast aan de huidige omstandigheden?

In zulke context nemen wij resoluut de stelling in dat het nodig is – op zijn minst nuttig, en vaak strategisch – om wetenschappelijk verantwoord te kwantificeren in hoeverre procescriteria een voorspellende waarde (predictive power) hebben voor een welbepaald resultaat (annex neveneffecten). Dit kunnen we doen met Predictive Analytics-technieken, een deelverzameling van datamining. Kort gezegd betekent dit dat we de voorhanden zijnde historiek van procesintelligentie (gestructureerde data), als training-data gebruiken voor een predictief model (meer info en how to: zie mijn vorige post), gericht op vastgestelde procesresultaten. Een goede typering van procesresultaten op lange termijn, is in deze optiek cruciaal. Zulk een datamining-model levert dan niet alleen een formule om te berekenen welk resultaat op lange termijn we mogen verwachten in functie van de op heden gemeten procesgegevens, maar ook met welke betrouwbaarheid deze projectie gebeurt, en welk relatief aandeel de verschillende procescriteria hebben.

Next steps – procesvernieuwing

Natuurlijk is het kwantificeren van de voorspellende waarde van de huidige procescriteria al reeds nuttig. Maar voor Predictive Analytics is dat maar de eerste stap. Omkaderd door een gedegen business-analyse zal men immers in staat zijn met Predictive Analytics nieuwe indicatoren, nieuwe criteria, en nieuwe, resultaatgerichte acties voor te stellen, en daarvan de relatieve meerwaarde te kwantificeren. Zo weet men of het sop de kool wel waard zal zijn als men gaat ingrijpen in een bestaand business-proces. En zo ja, welke criteria het meest lijken door te wegen.

We kunnen ons voorstellen dat de hierboven beschreven aanpak aan de basis kan liggen van alle Business Process Re-engineeringen van de toekomst …

Conclusie

Ons inziens kan geen enkele resultaatgerichte Business Process Re-engineering aan de slag zonder zich minstens te inspireren op conclusies die, wetenschappelijk verantwoord, gekwantificeerd kunnen worden dankzij data-driven predictive analytics.

De organisatie van de toekomst is analytics-driven, en zal minstens haar kernprocessen sturen aan de hand van criteria waarvan de predictive power dankzij analytics is gekwantificeerd.

In dit artikel wensten we vooral de aandacht te vestigen op de resultaatgerichte aspecten van predictive analytics, hoe er resultaatgericht gedacht moet worden bij elk business-proces, en hoe predictive analytics hierbij helpen.

Tot slot nog enkele praktische tips voor de analytics-driven organisatie:

1. Breng voor elk business-proces de resultaten en neveneffecten op lange termijn in kaart; stel voldoende in vraag wat het doel eigenlijk is (vaak is dit slechts impliciet gesteld); typeer de resultaten en zorg dat ze geregistreerd zijn zodat datamining mogelijk is.
2. Zorg voor voldoende procesintelligentie: zorg dat de acties die in verschillende processtappen genomen worden, geregistreerd zijn; evalueer ook het potentieel van logging-informatie.
3. Bekijk, vooral in de context van risicobeheersing, de huidige procescriteria kritisch, kwantificeer de “as is”, en tracht samen met de business-kenners nieuwe kandidaat-criteria te vinden en te kwantificeren.
4. Goede criteria drukken zich typisch uit in functie van karakteristieken, gebeurtenissen, en gedrag, in een bepaalde tijdspanne, voorafgaand aan de vaststelbare resultaten uit 1.

Succes!

Nadat we vorig jaar in de infosessie “Streamlining Analytics” enkele praktische aspecten in detail konden belichten (in a nutshell: overwinnen van barrières bij de introductie van Analytics in de organisatie – architectuur, data quality, methodologie – cfr. slideshare, research note), is het hoog tijd om een andere belangrijke succesfactor voor Predictive Analytics onder de loep te nemen: feedback.

Een predictief model heeft slechts waarde als het ook ingezet wordt in processen. Dit wil zeggen dat de voorspelling die het model levert, geëxploiteerd wordt om actie te ondernemen: om in te grijpen in het productieproces of om beslissingen te nemen in een business-proces, met een welbepaald doel. Het is vervolgens van het allergrootste belang om de werkelijke uitkomst te registreren en te confronteren met de voorspelde. Die ‘werkelijke uitkomst’, voorzien van de juiste metadata, noemen we de feedback.

Waarom is deze feedback-registratie zo belangrijk? De ervaring die we in afgelopen en doorlopende projecten opdeden, leert ons dat nauwkeurige feedback-registratie een cruciaal, zoniet het belangrijkste, element vormt voor de realisatie van meerwaarde op de volgende vlakken:

1. opvangen van het gebrek aan trainingsdata – de verwachte nauwkeurigheid opdrijven;
2. kwantificeren van de werkelijke nauwkeurigheid – rapporteren;
3. opvangen van evolutie – nauwkeurig blijven;
4. innovatie en procesinnovatie mogelijk maken.

Opvangen van het gebrek aan trainingsdata – de verwachte nauwkeurigheid opdrijven

De karakteristieken van het trainingsproces doen ons dit onmiddellijk inzien. Even recapituleren om wat termen in te voeren en het predictive-analyticsproces te verduidelijken:

• Predictive analytics bedient zich in een trainingsfase van algoritmen en invoerdata om een formule (een model, een patroon) op te stellen. Deze formule drukt zich uit in termen van variabelen uit de invoerdata (de zogenaamde ‘onafhankelijke’ variabelen), en berekent een verwachte waarde voor een doelvariabele (de ‘afhankelijke’ variabele). De doelvariabele drukt uit waar het voor de business om te doen is. Bv. de onafhankelijke variabelen zijn afgeleid van reeksen biometrische waarden, gemeten bij een gemonitorde patiënt; de afhankelijke variabele is het optreden van nierfalen binnen een zekere tijd.
• Predictive Analytics moet dus teruggrijpen naar historische data, waarbij voor een voldoende groot gedeelte de doelvariabele, de uitkomst van wat men wenst te voorspellen, bekend is (‘gelabelde’ data).
• De verwachte nauwkeurigheid van een predictief model kan dan worden berekend in functie van hoeveel keer de berekende verwachte waarde van de doelvariabele correct of incorrect blijkt.
• Als de verwachte nauwkeurigheid voldoende groot is, en het model is voldoende stabiel, dan kan de formule van het model ‘predictief’ ingezet worden, om de verwachte uitkomst te berekenen voor nieuwe invoerdata waarvan de doelvariabele nog niet bekend is (‘ongelabelde’ data).

Het is een statistische wetmatigheid, en in de praktijk ondervinden we het ook zo, dat de (verwachte) nauwkeurigheid van een predictief model verhoogt naarmate er meer gelabelde trainingsdata voorhanden zijn. Een tweede wetmatigheid zegt dat hoe meer (onafhankelijke) invoervariabelen er zijn, dus hoe complexer of rijker het model, hoe meer trainingsdata er minimaal nodig zijn voor een stabiel, robuust model. Een derde stelt dat de ongelijke verdeling van de doelvariabele een invloed heeft op de nauwkeurigheid waarmee het model in staat is de verschillende voorkomende waarden van de doelvariabele te voorspellen.

In de praktijk is het echter meestal zo dat er te weinig gelabelde data voorhanden zijn, of toch minder dan wenselijk. Dit omdat het duur of moeilijk is om ze te bemachtigen (denk bv. aan medische experimenten). Bij ongelijke verdeling van de doelvariable zal men typisch geconfronteerd zijn met het feit dat net de interessantste waarde het minst voorkomt.

Besluit:

Wie bij het inzetten van een predictief model in een proces, ook zorgt voor een nauwgezette registratie van de werkelijke uitkomst, beschikt na verloop van tijd over méér gelabelde data, en zal dus in staat zijn betere predictieve modellen te bouwen: nauwkeuriger, robuuster, gerichter.

Kwantificeren van de werkelijke nauwkeurigheid – rapporteren

The proof is in the pudding. Het is weinig interessant te beschikken over een model dat een hoge verwachte nauwkeurigheid kent, als het in de praktijk niet werkt. Het is evident dat slechts de registratie van de werkelijke uitkomst ons in staat stelt te rapporteren over de werkelijke nauwkeurigheid, de ‘performantie’ van het model.

Waar de werkelijke nauwkeurigheid sterk afwijkt van de verwachte, valt ongetwijfeld veel te leren uit het bestuderen van individuele cases waar de predictie verschilt van de geregistreerde uitkomst = feedback. Dit verhoogt het inzicht in de eigen business-context.

Verder hoeft het geen betoog dat de feedbackregistratie best gestructureerd, elektronisch, gebeurt. Dit maakt een regelmatige, automatische rapportering mogelijk, en maakt het ook mogelijk de performantie van een predictief model op te volgen in de tijd. Wat ons naadloos brengt tot het volgende punt.

Opvangen van evolutie – nauwkeurig blijven

De werkelijkheid evolueert. De context van elk proces zal in de tijd dus steeds veranderen. Men mag dus verwachten dat ook een predictief model mettertijd gaat slijten. Dankzij feedback-registratie zijn we nu niet alleen in staat deze daling in perfomantie waar te nemen, maar kunnen we er nu ook iets aan doen! Het volstaat immers de ‘oudste’ gelabelde data te laten vallen en te vervangen door ‘nieuwe’, waarvoor de uitkomst dus werd geregistreerd.

In het geval de feedback elektronisch is geregistreerd, is het ook mogelijk dit in een continu proces te gieten, waarbij een glijdend tijdsvenster wordt gebruikt bij automatisch opstellen van trainingsdata. Aldus berekent men op regelmatige wijze een nieuw predictief model, en blijft men constant “leren” in de evoluerende context.

Innovatie en procesinnovatie mogelijk maken

Met predictive analytics wil men vaak een nieuw probleem aanpakken, een nieuwe opportuniteit aanboren, een risico of fenomeen dat men voorheen niet expliciet, of expliciet genoeg, registreerde. Bv. voor fraudebestrijding: misschien deed men dit voorheen niet, of niet expliciet op een data-gedreven manier. Of bv. in de context van de medische wetenschap: het kan zijn dat men voorheen slechts een algemeen nierfalen benoemde, herkende, en registreerde, daar waar men nu voor een specifiek of gevaarlijk subtype een gerichtere, nauwkeurigere diagnose- of zorgondersteuning wenst uit te bouwen.

In die gevallen start men dan zonder gelabelde data, of in het beste geval met ‘onnauwkeurig getypeerde’ data. Bv. voor fraudebestrijding heeft men boetes geregistreerd, maar men kan fraude niet onderscheiden van vergissingen e.a. Bv. nierfalen: aanvankelijk heeft men slechts trainingsdata voor het algemeen type.

In elk geval dient men een nieuw afhandelproces te definiëren, waarbij men voor nieuwe dingen aandacht heeft, en waarbij men nauwkeurig, met de juiste metadata, de uitkomst registreert. Deze feedback kan dan op termijn wel geëxploiteerd worden in een echt predictief model.

Conclusie

We willen hiermee vooral de goede raad meegeven om van bij het begin het ganse proces te beschouwen, en in het afhandelproces (na actie in functie van predictie) te voorzien om goed getypeerde feedback te registreren. Zodanig dat die feedback, liefst volledig geautomatiseerd, geëxploiteerd kan worden voor het opvolgen van modelperformantie en voor constante bijsturing van predictieve modellen. Het adagium is: “Learning by Doing, and Continue to Learn”.

Hoe slimmer de feedbackregistratie is opgezet, hoe meer mogelijkheden de organisatie zal hebben om haar inzicht te vergroten en predictieve modellen te richten op voorheen onontgonnen terreinen.

Een woordje uitleg.

Stel dat u in het zweet uws aanschijns, op basis van procesparameters, statussen, business object-karakteristieken en -categorieën, ja zelfs historiek, een predictief model hebt kunnen opstellen dat op statistisch verantwoorde wijze en met een bepaalde nauwkeurigheid het optreden van een “event” voorspelt (1).
Uiteraard hebt u ervoor gezorgd dat uw nieuwe business-processen toelaten om snel en gericht actie te ondernemen op basis van deze voorspelling. Uw agenten en/of processen anticiperen op het “event” en genereren zo een meerwaarde in het geval van een gewenst event of vermijden kosten in het geval van een ongewenst event.
Wenst u nu te weten wat de ROI van deze nieuwe business-processen en acties is, dan zal u het resultaat moeten monitoren en dit vergelijken met wat het resultaat zou geweest zijn indien men geen actie zou ondernomen hebben. Hoe kan men dit bereiken?
De berekening van de ROI kan dan geschieden door het predictief model toe te passen op historische gegevens

• waarvan het resultaat (vóór de invoering van vernieuwde business-processen en geïnformeerde acties) bekend is, en
• die vergelijkbaar zijn met de gevallen waarvoor gerichte acties worden ondernomen.

Dit klinkt logisch, maar hoe bepaalt u wat vergelijkbaar is? Op welke basis dient de vergelijking op te gaan? Opnieuw biedt het predictief model een antwoord: kijk immers naar de variabelen die door het predictief model als meest significant worden beschouwd. Dan kan u voor de berekeningen aan de slag met de bekende resultaten, waarvan bv. het gemiddelde genomen kan worden van een groep vergelijkbare gevallen uit de historiek. Eventueel kan men bij dit laatste ook gebruik maken van descriptive analytics (zoals clustering).

(1) Het “optreden van een event” dient hier heel ruim geïnterpreteerd te worden. Het kan immers echt om het even wat zijn – als het maar strategisch interessant is, gelinkt aan een doelstelling van de organisatie, aan een gewenst of ongewenst resultaat. Wanneer gaat een klant weg, faalt een machine-onderdeel, of overschrijdt de waarde van een resultaatvariabele een welbepaalde drempel? Voorbeelden zijn legio.

Let wel, bij dit alles geldt: TIMTOWDI – “there is more than one way to do it” (denk bv. aan keuze van algoritmen, parameters, performance measures). Maar welke benadering ook gekozen wordt, er dient duidelijk over gecommuniceerd te worden, en men heeft er alle belang bij de keuzes die werden gemaakt, te motiveren en te documenteren.

Lessons learned:

• spreek op voorhand goed af met de business;
• spreek op voorhand goed af met de business hoe de resultaten van predictive analytics aanleiding kunnen geven tot concrete acties in concrete business processen;
• spreek op voorhand goed af met de business hoe de resultaten van zulke acties aanleiding kunnen geven tot een meetbare waarde, en hoe dit gemonitord kan worden;
• spreek op voorhand goed af met de business hoe de ROI dan op basis van het voorgaande kan en mag berekend worden;
• monitor de evolutie van de ROI en wees klaar om modellen bij te sturen;
• blijf daarom continu de business betrekken in dit proces.

Dat wisten we dus al – maar wat nu we een tijdje verder zijn, de eerste successen geboekt zijn? Enkele lessen kunnen getrokken worden, nu we dit aan den lijve hebben kunnen ondervinden. We geven ze hier al kort mee; elk van deze deelaspecten kan het onderwerp vormen van aparte blogs, waarin we er telkens wat meer aan besteden …

• men heeft specifieke skills nodig (business analyse, data mining, …) die verder gaan dan deze die nodig zijn voor Data Integration en Statistics;
• men moet rekening houden met evolutie in de modellen, onderliggend aan analytics, en dient dus een model management te voorzien;
• men moet een goed idee hebben van hoe (en met welk personeel) men zal afhandelen (workflow, case management, business processen, …) wat men met analytics detecteert;
• afhankelijk van de behoeften van de business (bv. (near) real-time detectie), is er misschien nood aan specifieke implementatie-architectuur (bv. Complex-event Processing, of moderne BI-architecturen, Data Virtualisatie) bij de koppeling van analytics aan de productiesystemen. Klassieke DWH-gebaseerde architecturen kunnen immers tekort schieten! Veel hangt ook af van de aanwezige Enterprise Architectuur.

Zeker en vast “to be continued”, dus … blijf ons volgen!

(Talend vermeldde ik reeds als DI-onderdeel van open source BI-platformen, deel1 en deel 2, en na recente overname van Sopera, als opkomende EAI-speler die een open source alternatief biedt.)

Hoe doet Talend het, en wat is er zo sterk aan?

In de eerste plaats gaat het om connectiviteit, waarbij de bron en/of het resultaat van de ETL-routines in Hadoop gaat. Tot daar nog niks spectaculairs.
Maar de Talend Integration Suite gaat nog verder, en profiteert van haar mogelijkheid om native Hadoop-code te genereren, waarbij net de transformatie-operaties aan Hadoop gegeven worden om aldus van Hadoops performantie voor Big Data te profiteren.
Dit soort ETL is niet zo bekend, maar heet ELT: “Extract-Load-Transform”, een stokpaardje van Talend.

Merk wel op dat de generatie van Hadoop-code enkel in de Subscription-versie (Talend Integration Suite) vervat zit, niet in de gratis versie (Talend Open Studio). Geen verrassingen hier.

Voor de liefhebbers: lees hier meer.

Conclusie

MapReduce is niet alleen voor Analytics, en Talend is een belangrijke, groeiende speler, die ook Big Data aankan.

Dit zijn inderdaad de sterke punten waarop dit product zich profileert, en volgens het Gartner-onderzoek waarderen de klanten het dan ook bij de allerhoogsten op het vlak van gebruiksvriendelijkheid, globale functionaliteit, support, software-kwaliteit en performantie.

Met de sterke aanwezigheid en support in België is dit dus een speler die zeker geëvalueerd moet worden bij het testen van nieuwe producten, bij informele marktverkenningen, of in het kader van eventuele lastenboeken.

Dit is m.i. goed gezien, want vaak zijn de redenen voor het falen van SOA-projecten e.d. (verwachtingen niet ingelost, vertragingen, budget overscheden, …) te vinden in de onderliggende datakwaliteitsproblemen of moeilijkheden op het vlak van data-integratie – naast de beter bekende redenen zoals gebrekkig requirements management en slechte software-kwaliteitscontrole (SQA). Dit zou dus wel eens een vruchtbaar huwelijk kunnen blijken.

U kan er hier meer over lezen.

FOD Economie: Adreskwaliteit KBO

In het project rond de authentieke bron van de Kruispuntbank van Ondernemingen (KBO) slagen we er met behulp van de Data Quality Tools in om de adreskwaliteit te verbeteren door

Een illustratie hiervan op reële data vind je hier.

De klant bevestigt dat de resultaten behaald met de tools een meerwaarde betekenen ten opzichte van de resultaten die de afgelopen jaren reeds op het vlak van de verbetering van adreskwaliteit werden bereikt. Er wordt regelmatig overlegd met de klant, die al herhaaldelijk zijn tevredenheid heeft uitgedrukt.

RSZ, dienst Inning: 30bis, werfmeldingen

Ook de RSZ is tevreden met de voorlopige resultaten die op slechts 2 dagen tijd werden bereikt, en wil verder gaan met de detectie en resolutie van dubbels in de signaletiek van Orderers, Contractors, en Sub-contractors in de toepassing voor de werfmeldingen. Sommige bedrijven met zeer gelijkaardige benaming en adres werden tot 3000 keer geregistreerd!

Korte historiek

De Data Quality Tools werden aangekocht na doorgedreven testen in een tweefasig lastenboek. De testen omvatten naast het functionele ook de integratiemogelijkheden van de oplossing (succesvol met J2EE en WebLogic10, onder andere), en een kosten-batenanalyse.
Ondertussen werd een productiemiddel (Data Quality Run Set) gecreëerd; meer uitleg op het Intranet.

Toekomst?

Er lijkt zeker voldoende vraag te bestaan bij klanten en leden.
De KSZ zou nog vóór het einde van het jaar met behulp van onze Data Quality Tools de verbetering van het BIS-register en migratie naar de SOA-omgeving willen realiseren.
KBO zou nog de kwaliteit van namen en adressen van contactpersonen (functies en rollen) van bedrijven willen in kaart brengen en vergelijken met de inhoud van het Rijksregister waar mogelijk.
Het FAVV zou de kwaliteit van adressen van vestigingseenheden en activiteitscentra in kaart willen brengen en verbeteren.

Het moment is nu gekomen om deze investering maximaal te laten renderen, voor alle betrokken partijen.
De klantenbeheerders kunnen hun voelhoorns uitsteken bij de leden van Smals en de opportuniteiten ontdekken.
En minstens enkele analisten van TO&P dienen ervaring op te doen met de Data Quality Tools in het kader van concrete opdrachten, om het Data Quality Competency Center van voldoende capaciteit en beschikbaarheid te voorzien en zo een solide basis te vormen voor dit nieuwe service-aanbod van Smals. Een uitdaging!

Uiteraard zal men hierbij kunnen blijven rekenen op de know-how die door de Data Quality Cel werd opgebouwd.

LogiXML combineert een moderne (je zou zelfs kunnen stellen: Web2.0) look-and-feel en architectuur (alles SOA en Web-based) met een interessant pricing-model (enkel per server, niet per client). Zo zijn ze excellent geplaatst om de meer bekende, traditionelere spelers de loef af te steken qua pricing en snelheid van roll-out (je kan alles namelijk in een pakket downloaden, installeren, en onmiddellijk in je browser gaan beginnen gebruiken en configueren na een half dagje opleiding). Met LogiETL erbij dekt deze oplossing alle lagen van BI; van ETL tot Reporting en Dashboarding met volledige “drill down”-mogelijkheden.

Eerder dit jaar had ik LogiXML al aangeraden aan het team SAS/statistieken/BI van Pierre Ghislain en aan het team SLM van Luc Vandam, ingevolge de wens om sneller over SLA-opvolgingsindicatoren te kunnen beschikken en in het algemeen om onze huidige DWH/BI-architectuur te herevalueren in functie van de recente ontwikkelingen. Concrete testen (o.a. Oracle BI, LogiXML, en een Open Source alternatief – zie mijn Open Source BI blog entries deel 1 en deel 2) zijn nu gepland.

Stilaan beginnen zich succesverhalen met LogiXML in de Belgische markt af te tekenen, getuige bijvoorbeeld het verhaal van EDPnet.

Bart van Daal, Development manager bij EDPnet: “In eerste instantie was EDPnet op zoek naar een tool om de bestaande Crystal reports rapporten te vervangen. Die tool was niet meer toereikend qua layout en functionaliteit om de groei en innovatiedrang van het bedrijf te kunnen volgen. De criteria waren de mogelijkheid tot documentcreatie, een intuïtieve interface en concept, snelle leercurve voor ontwikkelaars en de mogelijkheid voor de eindgebruiker om zelf parameters te beheren.”

“Na evaluatie van een aantal BI oplossingen, waaronder de laatste versie van de bestaande oplossing, werden we aangenaam verrast door de resultaten die we bereikten met LogiXML. Het concept van de tool en het nauw aansluiten met Microsoft .NET zorgden ervoor dat we zeer snel overtuigd werden van de capaciteiten van deze BI oplossing.” aldus nog Bart.

Het resultaat bij EDPnet

Lees hier het relaas over het resultaat behaald met LogiXML.