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.

Human versus computational analytics

In deze blogpost gaan we analytics op een andere manier indelen: volgens de actor die analytics uitvoert. Actors zijn diegenen die de analytics technieken uitvoeren en beoordelen, om vervolgens de nodige conclusies te trekken.  Zo kunnen we spreken over twee soorten analytics:

• Human analytics, wat alle technieken omvat waar men manueel op zoek gaat naar patronen, afwijkingen, … in de data. Dit zijn meestal technieken die gebaseerd zijn op visualisaties van bepaalde parameters. Deze technieken laten toe om de finesses van een bepaald soort data leren te kennen, de volledigheid in te schatten en te bepalen welke variabelen belangrijk zijn of niet. Een groot voordeel van deze techniek is dat hij kan ingezet worden voor heel veel verschillende types problemen en types van data. Een nadeel is dat men vaak slechts een beperkt aantal parameters kan visualiseren/interpreteren en dat men bij hele grote volumes data vaak met steekproeven dient te werken om een niet te cluttered beeld van de data te verkrijgen.
• Computational analytics, zijn alle technieken waar de computer autonoom (i.e. volgens bepaalde regels en algoritmes) op zoek gaat naar patronen in de data. Dit zijn meestal methodes die gebaseerd zijn op artificiele intelligentie (neurale netwerken, support vector machines), machine learning (decision trees) of geavanceerde statistiek (verscheidene regressie analyse technieken). Een groot voordeel aan deze technieken is dat ze automatisch op regelmatige tijdstippen of ten gevolge van bepaalde events kunnen uitgevoerd worden en de nodige resultaten leveren. Computational analytics mogen we echter niet aanzien als een magische oplossing voor alle analyse problemen. Zo verwachten bijna al deze technieken een zeer strikt data-schema (de eerste normaalvorm), wat heel wat transformaties vooraf nodig maakt. Deze transformaties dienen door mensen bedacht en beschreven te worden, wat de nodige tijd kost. Voorts is niet elke techniek even geschikt voor elk probleem: soms is techniek één goed voor een binaire keuze uit een set numerieke variabelen daar waar techniek twee met heel veel verscheidene soorten variabelen en een ongebalanceerde data-verdeling overweg kan.

Het human-computational data-analyse proces

De opdeling uit de vorige sectie laat ons nu toe om een typisch data-analyse proces te beschrijven waar zowel human als computational analytics noodzakelijk zijn. De stappen die we in zo een typisch human-computational data-analyse proces nemen zijn de volgende:

1. We passen éérst human-analytics technieken toe om de data die relevant is voor een bepaald probleem te leren kennen. Zo kunnen we de impact van bepaalde variabelen inschatten en de links tussen bepaalde bronnen leren kennen. In deze eerste fase kunnen we de geproduceerde, human-readable, visualisaties gebruiken tijdens overleg met de klant om bepaalde keuzes beter af te wegen.
2. Nadat we tijdens de eerste fase de data hebben leren kennen kunnen we de nodige data-transformaties implementeren. Deze data-transformaties dienen gebouwd te worden om in de volgende fase de computational-analytics technieken van input te voorzien. Typische transformaties die hier gebouwd worden zijn: het discretiseren/omvormen van continue variabelen, het omzetten van netwerkdata naar een reeks van variabelen en het herkennen van features in multimedia data.
3. Nu we een reeks van variabelen gebouwd hebben dmv van data-transformaties kunnen we het computational-analytics algoritme van input voorzien. Dit gebeurt in twee stappen:

• De trainingsfase, een subset van de data (de trainingsset) wordt door het algoritme geanalyseerd. Dit leidt tot een predictief model dat bepaalde beslissingen over de data kan nemen op basis van nieuwe inputdata.
• De toepassingsfase, het predictief model wordt losgelaten op de nieuwe data, wat zal leiden tot een reeks van voorspellingen/schattingen over deze nieuwe data.

Bovenstaand proces toont aan dat de rol van de computer – computational analytics – slechts beperkt is in de hele data-analyse. Mensen – analisten – dienen eerst de data voldoende te begrijpen, de nodige transformaties te bouwen en het juiste algoritme te kiezen alvorens een computer de data op regelmatige basis kan analyseren. Bovendien is het belangrijk op te merken dat dit een iteratief proces is. Zo zal men initieel vaak transformaties maken op basis van de visualisaties, maar blijken deze niet significant voor het uiteindelijke predictief model. Dan dient men terug te grijpen naar nieuwe, meer gedetailleerdere visualisaties, om andere transformaties te maken die vervolgens het resultaat van het predictief model positief kunnen beinvloeden.

De uitdaging: “Big(ger) Data”

Door technieken als human en computational analytics te combineren kunnen we data via een vast stramien gaan analyseren en het resulterende model later op een structurele manier exploiteren. Toch schuilt er een addertje onder het gras: het volume aan data dat we analyseren heeft een grote invloed op de snelheid van het proces. Zo is het moeilijk om hele grote volumes aan data te visualiseren op een een begrijpbare, niet cluttered manier (er zijn immers slechts ~3 miljoen pixels die kunnen benut worden in een visualisatie). Dit zal leiden tot foute interpretaties, wat vervolgens de aanleiding kan zijn voor niet optimale transformaties en kwalitatief minder goeie input voor de predictieve modellen. Bovendien duurt het uitvoeren van de transformaties op grote hoeveelheden data ook veel langer en vraagt het bouwen van een visualisatie uit een grote data-set ook meer tijd.

Om om te gaan met de problematiek van “big(ger) data” zien we twee interessante ontwikkelingen:

• krachtigere en gedistribueerde server-infrastructuren, die het mogelijk maken om bijzonder grote hoeveelheden informatie op een heel korte tijd te verwerken. We denken hier eenerzijds aan cluster of gedistribueerde infrastructuren die verscheidene servers in parallel gebruiken om queries uit te voeren. Anderzijds denken we aan data warehouse appliances die via een compleet getunede architectuur bijzonder snel analytics vraagstukken kunnen oplossen.
• nieuwe visualisatietechnieken, die het mogelijk maken om ondanks een bijzonder grote hoeveelheid data toch door het bos de bomen nog te zien. Visualisatietechnieken die hierbij een belangrijke rol spelen zijn smoothing, aggregatie (binning) en interactie:
  • Smoothing zal bepaalde lokale effecten uitvlakken (gebruik makende van bv. piecewise regression) om een globaal beeld op de data te werpen.
  • Aggregatie deelt data op in bins met als maximum aantal bins het aantal pixels die beschikbaar zijn voor de visualisatie. Van elk van deze bins gaat men vervolgens een aantal summary statistics bouwen die men visualiseert op het scherm. Zo krijgt men een idee van welke data zich in elke bin bevindt.
  • Via interactie-technieken kan men dan inzoomen op bepaalde bins om details over deze bins te bekijken, kan men bepaalde parameters interactief filteren, data op een andere manier voorstellen, … .

Besluit

Analytics is geen magische techniek die een arbitraire hoeveelheid data als input krijgt om vervolgens de nodige conclusies te trekken. Er is een belangrijke rol weggelegd voor de menselijke analist, die de data dient te analyseren en transformeren alvorens hij door een computer kan geinterpreteerd worden dmv computational analytics. Daarnaast worden analytics technieken enorm beinvloed door de hoeveelheid data die men wenst te analyseren. Om op een goede manier met grote volumes aan data om te gaan is de vooruitgang in processing power voor analytics en visualisatie- en interactietechnieken cruciaal.

Cet ouvrage collectif  sur la qualité des données est inédit car il émane exclusivement de la communauté des web software developpers (Python, Perl script,  Parallel R, NLP, cloud computing,  …), web predictive analytics et architectes IT … Il compte même un  hacker parmi ses co-auteurs. Ces auteurs n’avaient a priori aucune prédilection pour l’étude des données : « In fact, I dare say that I don’t quite care for data » (p. 1). Mais, quotidiennement affectés par les problèmes de data quality dans leur job, ils ont programmé une pause entre deux lignes de code pour partager leur longue et douloureuse expérience dans les domaines d’application les plus variés :  “Bad Data …. include data that eats up your time, causes you to stay late at the office, drives you to tear out your hair in frustration. It’s data that you can’t access, data that you had and then lost, data that’s not the same today as it was yesterday…” (p. 1).

En soi, les principaux apports pratiques de cet ouvrage, en ce qui concerne le thème “Database Quality”, sont déjà connus par certains (“The ideas presented here are born from (often painful) experience and are likely not new to anyone who has spent any extended time looking at data“, p. 226). Ils sont par exemple plus largement intégrés dans l’approche opérationnelle  du Data Quality Competence Center de Smals (voir le data tracking, la gestion intégrée des anomalies, le recours aux “Data Quality Tools”, la documentation du système ou encore, la mise en place d’une organisation). S’agissant de l’egovernment, nos travaux sont synthétisés dans un ouvrage coédité à New York chez Springer en 2011 et dans un article paru aux Annales des Mines à Paris en 2012 : ils placent la question de l’évolution de l’information dans le temps au coeur de la réflexion conceptuelle,  appliquant la critique historique aux sources informatiques à des fins opérationnelles en termes de coûts-bénéfices et de gestion.

Nous présentons toutefois ici un aperçu de ce “Bad Data Handbook” et des catégories de questions qu’il aborde car il comporte au moins quatre aspects très intéressants et, en soi, particulièrement innovants  :

• les très nombreux cases studies présentés sont extraordinairement riches, inédits et variés dans des domaines d’applications stratégiques (police criminelle, marchés financiers internationaux, chimie urologique, egov, …);
• c’est la première fois que la communauté “geek” des développeurs & architectes IT aborde la question “data quality”, sujet sur lequel elle ne publie en général jamais, se concentrant essentiellement sur la complexité technique, algorithmique et mathématique;
• on y trouve une reconnaissance des impacts financiers énormes que suscite l’inadéquation des données aux usages (“non qualité”)  : “For large entreprises, this could be a multi-million dollar problem” (p. 163);
• sans aucune référence bibliographique explicite, plusieurs auteurs font preuve d’une finesse d’analyse et d’une acuité assez impressionnantes sur le plan épistémologique (certains d’entre eux ont fait leur thèse de doctorat en physique théorique, ce qui explique sans doute que K. Popper ne leur soit pas étranger).

Les apports de l’ouvrage retenus sont ici structurés en deux catégories logiquement liées et utiles non seulement pour les développeurs IT et les architectes mais aussi, la communauté des bases de données, les décideurs et utilisateurs finaux

A. “Data format, storage & infrastructure” : 5 pistes pour faciliter l’accès aux données

Avant d’aborder la qualité de l’information, … il s’agit d’abord d’accéder physiquement et logiquement aux données.  Or, notre longue expérience en “data profiling” le confirme, c’est souvent l’étape la plus fastidieuse.

Ceci est encore plus vrai dans le cadre du Web, espace ouvert, dynamique et non contrôlé : “in some (regrettably rare) cases, all the information about the data is provided” (K. Fink, p. 9); “the first, and sometimes, hardest part of doing any data analysis is acquiring the data from which you hope to extract information” (A. Laiacano, p. 69). Ceci amène les auteurs à s’interroger sur l’opacité des Media sociaux dont l’étude soulève de nombreux défis (P. Warden, How to Feed and Care for Your Machine-Learning Experts, ch. 16), qu’il s’agisse d’effectuer une “root cause analysis” des Web sites (R. Draper, Data Traceability, ch. 17) ou encore, de vérifier l’impact des données effacées, de liens en liens, sur les réseaux sociaux (J. Valeski, Social Media: Erasable Ink?, ch. 18). Cela étant dit, voici 5 pistes concrètes en vue de faciliter l’accès aux données.

1. Eviter, à la source, la production non organisée de volumineux ensembles de données stratégiques dans un format peu lisible par la machine, comme les spreadsheets. Il est très fréquent que les utilisateurs “business” utilisent de tels formats qui conviennent bien à la lecture humaine mais génèrent des “silos de données” redondants dont le traitement automatisé ultérieur est ardu. S’appuyant sur son expérience en matière de statistiques dans le domaine scolaire en Nouvelle Zélande, P. Murell propose des conseils de développement en R pour coder des données issues de tableurs dans un format réutilisable (P. Murrell, Data Intended for Human Consumption, Not Machine Consumption, ch. 3). Dans un autre chapitre appliqué au domaine de la chimie, R. Cotton plaide en faveur de processus de codage organisés, incluant contrôles et gestion des versions  (R. Cotton, Blood,Sweat, and Urine, ch. 8), proposant une cure de “Rehab for Chemists (and Other Spreadsheet Abusers)” (p. 115) et s’exclamant au passage : “Live Fast, Die Young and Leave a Good-Looking Corpse Code Repository” (p. 114).
2. Prendre en considération la variété des systèmes d’encodage hétérogènes sur le web (ASCII, différentes normes ISO, UTF, …).  J. Levy propose des conseils de programmation (“text processing “) en Python à cette fin offrant même au lecteur intéressé une série d’exercices (J. Levy, Bad Data Lurking in Plain Text, ch. 4).
3. Identifier le pattern d’organisation des sites web analysés et en conserver l’historique des versions off line en vue d’un parsing ultérieur. En raison du caractère imprévisible et dynamique de la mise à jour des sites web, cette démarche est indispensable. A. Laiacano propose plusieurs exemples de parsing et de reengineering du pattern de sites web en Python, Ajax et MATLAB scripts (A. Laiacano, (Re)Organizing the Web’s Data, ch. 5).
4. Evaluer les avantages et inconvénients des différents modèles logiques de bases de données, en fonction des usages et des modèles de coûts. Deux chapitres discutent cette question essentielle pour le stockage et l’analyse des données issues du Web. S’inspirant d’une étude des “social media”, l’un plaide en faveur d’un format simple de type “plain text” avec des flat files, lorsque les données sont volumineuses et statiques.  Ceci en facilite la préservation à long terme, la rapidité de traitement et la sauvegarde, contrairement à certaines bases de données NoSql reposant sur le MapReduce paradigm (T. McNamara, When Databases Attack: A Guide for When to Stick to Files, ch. 12).  L’autre évalue les coûts de gestion en terme de performance des différents modèles, reconnaissant la précision du modèle relationnel qui peut cependant être coûteux en terme de performance, évoquant “the Delicate Sound of a Combinatorial Explosion…” (p. 167). Il conseille un modèle en graphe qui constitue une abstraction simplifiée mais utile quand il s’agit de gérer à la fois la complexité des interactions entre données et la performance de leur gestion (B. Norton, Crouching Table, Hidden Network, ch. 13).
5. Utiliser le “cloud computing” avec prudence, en fonction du domaine d’application. Sur la base d’un exemple réaliste, les risques de perte de performance, de coûts élevés et de pertes de données, lorsque le « cloud computing » est appliqué sans précaution sont évoqués (S. Francia, Myths of Cloud Computing, ch. 14).

B. From “big data” to “long data” : 5 pistes pour faciliter l’interprétation des données

Une fois les données accédées, il s’agit de les interpréter pour les exploiter. Il est impensable d’étudier le phénomène “big data” sur le web sans prendre en considération la question historique du temps. Dans un blog publié en février 2013 par le journal Le Monde, la notion de  “long data” est préconisée pour envisager la prise en compte de l’évolution des phénomènes dans le temps. Certains changements “brutaux” et récents (étude de la surpêche, de la déforestation, du climat, …) prennent par exemple leur source dans des évolutions datant de plusieurs siècles. Mais cette étude est complexe car elle demande l’examen de l’évolution du sens des données et des mots dans le temps et dans l’espace. Dans cet esprit, citons par exemple l’application Google Ngrams, “qui vise à tracer l’historique de l’usage d’un mot depuis l’an 1500, grâce à une analyse des livres numérisés par Google Books. Évidemment, cela ne commence qu’à l’invention de l’imprimerie et le fonds n’est pas exhaustif. Mais c’est un début qui a lancé un nouveau champ d’études, la culturomique, reposant sur une analyse quantitative des termes étudiés.”

Associant le concept de « big data » à celui de « long data », voici 5 conseils relevés dans l’ouvrage en vue de faciliter l’interprétation des données.

1. Prendre en considération le caractère interdisciplinaire d’une approche « data quality », à travers des échanges permanents entre « connaissance métier » et « culture technique ».  Dans son chapitre déjà cité, “Blood, Sweat, and Urine” (Ch 8), R. Cotton présente une expérience  dans ce sens dans le domaine de la chimie urologique. Pendant une semaine, en tant que développeur IT, il a échangé son poste avec celui d’un chimiste en vue d’un apprentissage réciproque. Dans un paragraphe éloquent,« How Chemists Make Up Numbers” (p. 108),  il relate sa stupeur devant l’exigence de précision de l’approche scientifique face à la complexité du réel observable et l’importance des enjeux humains et médicaux associés. Il en tire avec humour les conclusions hypothétiques pour son propre métier d’informaticien : “They have an endless list of documents and rules on good laboratory practice, how to conduct experiments, how to maintain the instruments … The formal adherence to all these rules was a huge culture shock to me. All the chemists are required to carry a lab book around, in which they have to record the details of how they conducted each experiment. And if they forget to write it down ? Oops, the experiment is invalid. Run it again. I sometimes wonder what would happen if the same principles were applied to data scientists. You didn’t document this function. Delete. I can’t determine the origin of this dataset. Delete. There is no reference for this algorithm. Delete, delete, delete. The outcry would be enormous, but I’m sure standards would improve.” (p. 108). A l’inverse, cet échange permet à son collègue chimiste, spécialiste du domaine d’application, de tirer des “best practices” quant au traitement des données (éviter l’encodage intensif et non contrôlé sur des tableurs (cfr supra), à la source de redondance et de “data silos”, remplacer le double encodage humain et les phases de réencodage (à la source d’erreurs et coûteuses en terme de manpower) par un workflow structuré organisant tâches humaines de validation et contrôles automatisés ou encore, associer d’emblée aux données un modèle de base de données auquel correspondent des business rules, des règles de validation et une gestion des versions. L’auteur conclut : « Sometimes, technology just works…” (p. 116).
2. Adopter une approche statistique itérative face à la complexité du domaine d’application incluant des facteurs exogènes imprévus sur le Web. Dans un chapitre à propos des taux de consultation des données et du trafic sur le Web, qu’il s’agisse du “Pay per click” ou de la consultation de Wikipedia, F. Fink (It Just Me, or Does This Data Smell Funny ?, ch. 2)  montre comment aux effets saisonniers qui diminuent structurellement le taux de consultation («Superbowl Sunday” aux USA, congés scolaires, week-ends) se mêlent malicieusement des bugs dans les logs de Wikipedia qui complexifient l’interprétation des séries temporelles . On trouve un phénomène analogue dans un chapitre (J. Perkins,  “Detecting Liars and the Confused in Contradictory Online Reviews”, ch.6) consacré à l’analyse des sentiments sur le web (à propos des restaurants, par exemple) où l’auteur découvre des contradictions (apparemment intentionnelles) entre les scores (ratings) attribués et les commentaires associés qui incluent parfois des doubles négations, sources de confusion en langage naturel. Dans l’approche, l’auteur  montre comment construire un “sentiment classifier” en Python Natural Language sur la base d’un training set et d’une étude itérative en vue de détecter ces “mensonges volontaires”.
3. Face à certaines anomalies non élucidées par le modèle d’observation, ne pas hésiter à retourner sur le terrain pour réinspecter le domaine d’application (quand c’est matériellement possible). Le chapitre correspondant (P. K. Janert, Will the Bad Data Please Stand Up, ch. 7) est introduit en ces termes : “there is no such thing as bad weather – only inappropriate clothing  ; there is no such thing as bad data – only inappropriate approaches” (p. 95). L’auteur relate  plusieurs expériences d’analyse des données en industrie visant à évaluer, sous contrainte de coût, le nombre d’appels en entreprise ou encore, les critères de production des produits défectueux. Les modèles statistiques employés (courbe de Gauss, modèle de Poisson), ont chaque fois permis de détecter des exceptions qui ont requis une nouvelle inspection du domaine d’application (par exemple, au sein de la chaîne de production, des sources de destruction accidentelles n’avaient pas été intégrées dans la structure de l’échantillon). L’auteur plaide pour une approche empirique scientifique invitant à un réexamen régulier du modèle d’observation et des hypothèses associées : “It was not the data that was the problem. The problem was de discrepancy between the data and our ideas (assumptions) about what the data should be like  …  this discrepancy can lead to a form of “creative tension, which brings with it the opportunity for additional insights” (p. 104).
4. Prendre en considération le fait que des données non valides peuvent avoir, à l’insu de l’observateur, un impact (financier, par exemple) sur le réel empirique étudié. Dans certains cas, l’inadéquation des données au modèle d’observation a un impact direct sur les réalités observées (S. Burns, When Data and Reality Don’t Match, ch. 9).  Ainsi, les données sur l’état des marchés financiers diffusées sur Internet (Google Finance – Yahoo! Finance) peuvent faire, en quelques minutes, partie intégrante du marché étudié où l’on observe “a tight feedback loop where data about the state of the market affects the market (e.g. rising prices may cause people to push prices up further)” (p. 119). Même si un algorithme de « data cleansing » permet a posteriori de détecter facilement les anomalies, celles-ci ont eu, entre temps, un impact concret sur le marché. Ainsi, le cas s’est-il présenté le 6 septembre 2008, lorsque le spider de Google News a diffusé par défaut à la date du jour des données plus anciennes non datées (et en fait obsolètes) concernant la banqueroute d’une valeur cotée sur le marché.  En quelques minutes, cette information a donné lieu à des mouvements de vente massifs de la part des traders, avant que l’on ne se rende compte de l’erreur (p. 125). De tels phénomènes se sont souvent produits dans le secteur financier. Comment considérer le statut de ces données formellement erronées ex post, lorsqu’elles ont agi sur le marché réel ? D’importantes questions d’interprétation doivent être en effet abordées, lorsqu’on étudie un domaine d’application empirique critique, au sein duquel le système d’information est un instrument d’action sur les réalités qu’il représente.
5. Accepter les compromis, dans le cadre d’un double arbitrage “fitness for use” & “coût-bénéfice”. On déduira facilement des recommandations qui précèdent que la “qualité parfaite” n’existe pas (Vaisman M., The Dark Side of Data Science, ch. 15) . Dans le domaine de la police criminelle, par exemple, au sein du Chicago Police Department’s Predictive Analytics Group (B. J.  Goldstein,  Don’t Let the Perfect Be the Enemy of the Good: Is Bad Data Really Bad?, ch. 11),  les séries statistiques temporelles relatives aux appels d’urgence (“Reported Crime Information“, “Sale of Narcotics“, …) sont exploitées en vue de prévoir l’émergence de crimes par secteur géographique. Naturellement, dans la pratique, certains appels ne donnent pas lieu à la détection d’un délit (parce que les auteurs ont été prévenus entre-temps, par exemple). Ces informations sont toutefois utiles, pragmatiquement. Ainsi, le responsable du département conclut en ces termes  :  “In order to make informed strategic and tactical decisions in an environment with imperfect data, one must make compromises. … Still, I have repeatedly noted that it is better to have an informed decision built on imperfect data than to have decision built on no data at all. When one accepts that imperfection, it opens up the ability to integrate data into all supports of projects and policies” (p. 148). On trouve le même type d’analyse dans le domaine du recensement aux USA et des enquêtes réalisées par le Congressional Budget Office ou la U. S. Social Security Administration (J. A. Schwabish, Subtle Sources of Bias and Error, ch. 10).   C’est sur cette sage relativité que l’ouvrage se termine, privilégiant le pragmatisme et l’expérience à toute velléité stérile d’une représentation idéale du réel (Q. E. McCallum & K. Gleason, Data Quality Analysis Demystified: Knowing When Your Data Is Good Enough, ch. 19) :

“Things change (and break)

…

Indeed”.

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!