Kadenza+

Hoe zou een voetbalwedstrijd verlopen als de verschillende teams eigen regels hanteerden?

Met een beetje geluk komen de regels overeen en dan wordt het een wedstrijd. Maar als je pech hebt liggen de regels mijlenver uit elkaar en is er van een wedstrijd dan weinig sprake. Het is zo vanzelfsprekend in sport dat bij het betreden van hetzelfde speelveld je dezelfde regels hanteert.

Waarom gebeurt dat dan niet binnen een organisatie? Read the rest of this entry →

Delen

In elke top 3 van taken waar een ICT’er geen zin in heeft, staat altijd ergens documenteren. Zelfs beheerders die wel eens ‘s nachts uit hun bed gebeld worden om verstoringen op te lossen, vinden documenteren geen onverdeeld genoegen. Het is geen hoofdzaak, maar een bijzaak: het is niet de core business van ICT. En toch zal diezelfde beheerder beamen dat zijn leven aanzienlijk makkelijker wordt gemaakt door goede documentatie. Maar wat is nu eigenlijk goede documentatie?

In mijn ogen zijn er drie zaken die documentatie goed maken:

• Goede documentatie stelt mij in staat om te begrijpen HOE iets in elkaar steekt en nog belangrijker in mijn ogen WAAROM het zo in elkaar steekt.
• Goede documentatie is altijd toegankelijk. Het systeem waarin de documentatie is opgeslagen is envoudig: eenvoudig in invoer en eenvoudig in opvraging.
• Goede documentatie is een weergave van de werkelijke situatie.

Wat is voor jou goede documentatie?

Delen

Recentelijk heb ik een klant geholpen bij de implementatie van een Data Warehouse. Als rapportagetool kozen we na een toolselectie voor Business Objects. Binnen de organisatie was al kennis van BO aanwezig, en de tool scoorde het hoogste op de shortlist.

Omdat BO onlangs uitkwam met versie 4.0 overwogen we live te gaan met deze versie. Het Data Warehouse was immers niet essentieel voor de continue operatie, en gegeven de nieuwe features kon men waarschijnlijk wel leven met de ongetwijfeld aanwezige bugs.

Nu ben ik ooit mijn BI carriere begonnen als een BO ontwikkelaar, dus ik heb een aantal jaren ervaring met het product, maar dan nog van de voor de web-enabled tijd. Ik was dan ook benieuwd wat er in die ruim tien jaar sinds ik het gezien had verbeterd was aan het product.

Groot was mijn verbazing toen ik ontdekte dat veel mijn “irritating issues” (strikt genomen geen bugs, maar ze maken het leven van een ontwikkelaar wel moeilijker) allemaal nog aanwezig waren in het product. Workarounds die je als ontwikkelaar moest kennen om bepaalde zaken gedaan te krijgen waren nog steeds noodzakelijk.

Toch waagden we de sprong in het diepe met 4.0. De installatie verliep vlekkeloos, maar de hoeveelheid zaken die niet of gebrekkig werkten waren op de grens van het acceptabele. Met basale use-cases hadden de programmeurs geen rekening gehouden (twee tabjes in je browser met verschillende rapporten?), niet in alle gevallen werden de juiste menu-opties getoond, en meer van dit soort zaken waarbij je je af gaat vragen of de Q&A afdeling van SAP op vakantie is geweest het afgelopen jaar.

Een van de nieuwe features die 4.0 bood, en die mijn klant wilde, was gebruik te kunnen maken van gradients binnen staafgrafieken. Binnen 4.0 kun je nu inderdaad tot en met de schaduw van de leganda een gradient instellen, alleen niet van de staafjes in het grafiek zelf. Je vraagt je af of ze van de requirements een pagina zijn kwijtgeraakt.

Toen ik hoorde dat er inmiddels een patch uit was, heb ik deze blind geinstalleerd, slechter kon het immers niet worden. Na de installatie werkte het hele platform niet meer. De java-exceptions vlogen je om de oren (ook geen goed teken voor de kwaliteit van software), en ik heb uiteindelijk moeten besluiten om de klant te adviseren om niet met versie 4.0 in productie te gaan. Ondanks de verzekering van de accountmanager dat 4.0 toch echt een “prima product” is.

Nu vind ik dat BO in zijn opzet best zaken goed voor elkaar heeft (de wijze waarop ze een Universe opgezet hebben, i.c.m. het bij elkaar klikken van rapporten), maar ik bespeur een groot gebrek aan wil om er een echt mooi product van te maken.

In mijn (inmiddels al jaren durende) zoektocht naar het perfecte BI-tool ben ik veel initiatieven tegen gekomen die op grond van de marketingpraat veelbelovend zijn, maar als ik dan kijk wie er bij betrokken zijn, zie ik daar nooit een BI consultant met ervaring in het vakgebied bij staan. Zulke tools zullen niet gaan beantwoorden aan mijn eisen. Ik heb regelmatig op het punt gestaan zelf een tool te bouwen.

Bestaat er nu een BI tool (rapportage op een semantische laag) dat nog niet tot de grote jongens behoort, maar wel aan het uitgroeien is tot een mooi product zonder al de extra features die 95% van alle klanten toch niet gebruikt, betaalbaar is, en waarvan de maker nog oprecht interesse heeft om het product beter te maken?

Delen

"I don't know how it started, either. All I know is that it's part of our corporate culture."

“Hello, my name is Arjen, a BO expert”. In één van mijn eerste meetings, waarbij Engels werd gesproken, ging het al fout. In Amerika betekent BO namelijk ‘body odor’. Oftewel, ik stelde me voor als lichaamsgeuren specialist.
Cultuurverschillen tussen bedrijfstypen, jong en oud en andere landen leveren soms hilarische momenten en versprekingen op. Maar maken deze verschillen het ons niet onnodig lastig?
De presentatie van informatie met flitsende meters en andere grafische hoogstandjes werkt voor iedereen. Apple is niet voor niets zo succesvol wereldwijd. Echter, Scandinaviërs blijken al snel de vrijheid van uitgebreide analyse mogelijkheden te missen. De zuidelijke landen grijpen maar al te graag terug op de standaard rapportages. Daarmee ontstaat  meteen de wens naar onderscheid in het type informatiebehoefte en de eindgebruikerstooling. Hoe ga je het data model hier op voorbereiden en met welke software maken we hier informatie van?
Er zijn verschillen in regelgeving omtrent het vrijgeven van data. Zo is het in sommige landen ‘not done’ of zelfs verboden om de sales performance van andere collega’s, of klanten daarvan, te kunnen bekijken. In een ander land kan dit juist gewenst zijn. Daardoor ontstaan verschillende security eisen aan het centrale project.
Naar mijn mening worden de cultuurverschillen in internationale BI projecten nog al eens onderschat. Het vergt veel kennis van de business, en die wordt in de meeste gevallen niet op dezelfde manier bedreven. Goed geschreven requirements overbruggen een hoop. Maar 100% vastleggen lijkt zelden mogelijk. De tussentijdse communicatie blijft daarom erg belangrijk en vormt soms de bottleneck. Zeker als er een aanname wordt gedaan en je dan de opmerking krijgt “maar in de requirements stond niet geschreven dat het niet zo moest”. Het gebeurt regelmatig. Op deze manier kan Offshore ontwikkeling erg duur worden.
Bij grote internationale projecten moet de centralisatie zich beperken tot data integratie. De business logica en informatie presentatie kunnen we dan beter bij het land zelf laten.

Heb jij te maken met, of voorbeelden van cultuurverschillen binnen een BI project? Is het een verrijking of zware last? Deel je ervaringen gerust. Leuke versprekingen zijn altijd welkom J
Tot slot nog een aardig filmpje dat niet zo lang geleden op de televisie verscheen…

httpv://www.youtube.com/watch?v=KLSdOY-6R_U

Delen

Enkele maanden geleden gaf ik in de blog “Kadenza innoveert met oeroude ideeënbus” aan dat het resultaat van een eerste innovatie binnen het Innovatieplatform van Kadenza prominent zichtbaar zou worden. Uit de vele aangedragen ideeën werd door het Innovatieplatform gekozen voor Mobile BI. Door het opdoen van kennis en ervaring rondom het opslaan van bedrijfsgegevens in de Cloud en het ontsluiten van de informatie op tablet en smartphone, is Kadenza nu in staat bedrijven te adviseren over de inzet van Cloud BI en Mobile BI.

Gedurende het ontwikkelen van deze nieuwe dienstverlening hebben we een onderzoek laten uit voeren onder ruim 300 managers naar het gebruik van en gedrag m.b.t. tablet en smartphone. De belangrijkste uitkomsten hebben uitgebreid de nationale en internationale media gehaald. Het volledige onderzoeksrapport is te downloaden via http://www.kadenza.nl/mobile.

Tevens hebben we een animatie laten maken over hoe wij als Kadenza denken dat Mobile BI succesvol is in te zetten. De animatie “How to succeed with Mobile Business Intelligence” is op moment van schrijven van dit blog reeds meer dan 2700 keer bekeken.

Voor de keuze van een volgende innovatie heeft het Innovatieplatform een pitch georganiseerd waarin zes deelnemende teams werden uitgenodigd een via de ideeënbus aangedragen idee te presenteren aan de Kadenza collega’s.  Het aanwezige publiek is vervolgens via stemming tot de keuze gekomen welk idee als volgende wordt opgepakt voor verdere uitwerking en realisatie. De keuze voor een idee betekent zeker niet dat de overige ideeën niet goed zouden zijn, integendeel zelfs.

We herkennen ons in de woorden van de nieuwe topman van Apple, Tim Cook, die aangeeft geen twijfels te hebben met het dagelijks verwerpen van goede ideeën. “We say no to good ideas every day. We say no to great ideas in order to keep the amount of things we focus on very small in number, so that we can put enormous energy behind the ones we do choose, so that we can deliver the best products in the world. And that is not from just saying “Yes” to the right product which gets a lot of focus. It’s saying no to many products that are good ideas, but just not nearly as good as the other ones.”

Tot zover voor nu. Meer over de gemaakte keuze en de realisatie hiervan in een later blog.

Nieuwsgierig geworden? Reageer op deze blog of stuur een mail naar innovatie@kadenza.nl

Delen

Volgens de klassieke werkwijze van een IT project doe je eerst hard je best om iets te maken wat zo goed mogelijk aansluit bij de ooit geformuleerde klantwensen. Op een gegeven moment ben je daarmee klaar, en moet de klant (vaak de business) je gaan vertellen of ze vinden dat je je werk goed gedaan hebt. Deze laatste stap noemen we dan de acceptatie van je product.

Volgens de regels der kunst heb je van tevoren samen met de klant geformuleerd aan welke voorwaarden je product moet voldoen. De klant verlangt bijvoorbeeld dat de getallen van je BI oplossing aansluiten bij vergelijkbare getallen uit de bron, of dat rapportages er niet te lang over doen. Nadat de klant heeft gevalideerd dat alles in orde is kan het product daadwerkelijk in gebruik worden genomen.

Een probleem wat ik echter heel vaak in de BI wereld tegen kom is dat de werkelijkheid niet zo eenvoudig is als bovenstaande theorie. Dit heeft een aantal oorzaken.

In de praktijk is het vrijwel onmogelijk om de requirements (de specificaties) van de BI oplossing 100% van te voren te formuleren. De klant is vaak niet op de hoogte van details van het operationele proces die van belang zijn voor implementatie, en dus gevolgen hebben voor de requirements. Een klant is daarnaast ook niet goed in staat (het is immers niet waarvoor hij betaald wordt) om exact zijn wensen te formuleren.

Ook zie je vaak dat gedurende de ontwikkeling van een Data Warehouse de werkelijkheid verandert, dus requirements die ooit zo zeker leken kunnen verschuiven. Ik zie bovendien altijd gebeuren dat zodra een klant de beschikking krijgt over de producten van een Data Warehouse vrijwel meteen zijn informatiebehoefte verschuift.

Uiteindelijk is het doel van je Data Warehouse niet om conform specificaties op te leveren, maar om de business het best te helpen. Dit laatste is natuurlijk veel fuzzier en minder geschikt om je project mee te sturen maar levert je wel de hoogste klanttevredenheid op.

Sommige organisaties verlangen een formele acceptatiehandtekening, maar mijn voorkeur heeft het altijd om een zachte overgang te hebben tussen de development, acceptatie en productie-fasen van een BI project. Je kunt daarbij nog steeds harde milestones afspreken, dus het geheel blijft stuurbaar.

Op een gegeven moment ben je technisch ver genoeg om de klant er mee te laten werken. Je hebt er in je projectaanpak voor gezorgd dat je iets generiekers en breders hebt gebouwd dan de strikte wensen van de klant. Doordat de klant daadwerkelijk kan werken met de data, zonder dat hij operationeel afhankelijk is van de correctheid van alles kun je er voor zorgen dat de klant meer mee gaat denken. Gaandeweg krijgt de klant een gevoel van de waarde van het Data Warehouse dat verder gaat dan het simpele gegeven dat een rapport wel of niet correct is. Bovendien kan de klant zelf op een gegeven moment beoordelen of, gegeven de inmiddels bereikte betrouwbaarheidsgraad, het geheel operationeel een toegevoegde waarde heeft. In mijn ervaring is dat punt eerder bereikt dan een 99% betrouwbaarheid.

Hoe is de ervaringen hiermee bij collega’s?

Delen

Ik ben het al te vaak tegengekomen. Iemand hoog in het bedrijf (bv een directeur) heeft een vriendje/golfmaatje die iets doet in de softwarebouw, ze drinken een borrel en de een overtuigt de ander van het nut van het product. De directeur ziet wel mogelijkheden en noemt het tijdens een meeting met zijn team. Het team heeft er eigenlijk geen verstand van, maar het is goed voor de carrrière als de baas tevreden is, dus het product wordt de organisatie binnengerold. Voor bezwaren die lager in de organisatie ontstaan op basis van rationele argumenten is het dan al te laat. Trajecten als dit zijn netto altijd slecht voor de organisatie.

Recentelijk heb ik bij een klant bovenstaande kunnen voorkomen. Een relatief onbekend visualisatietool werd gepresenteerd aan een groep managers die ‘deeply impressed’ waren, inhoudelijke experts waren (natuurlijk) niet aanwezig bij die demo. Met veel moeite heb ik de klant ervan kunnen overtuigen om toch ook maar naar andere producten te kijken, en ook te kijken naar wat eigenlijk de requirements waren.

Na het net toolselectie traject kwam er een ander tool uit, waarvan uiteindelijk ook de directie moest toegeven dat dit toch eigenlijk wel een betere keuze leek. Complimenten waren ons deel, omdat dit voor het eerst was dat men ervoer dat je ook op een verstandige wijze kunt kiezen voor software.

Veel vaker maak ik het mee dat er niets meer aan een dergelijke keuze te doen is, en je met de gebakken peren zit. Wanneer leren organisaties het nou eens?

Delen

Ben ik nu degene die zo slim is, of ben jij nou zo dom?

“Wij hebben altijd gelijk. De informatie is correct en als je fouten constateert is dit verkeerd ingevoerde informatie in jullie eigen systemen. Het is maar goed dat wij deze fouten voor jullie inzichtelijk maken.” 

Stiekum is dit de iets wat arrogante houding die iedere BI-afdeling maar al te graag aanneemt… Niet? Als je als BI-afdeling de zaakjes goed op orde hebt kan je wat mij betreft ook zo arrogant zijn. Als je vertrouwen hebt in je eigen BI-omgeving moet je dat ook uitstralen, denk ik dan.

Een vraag aan alle BI-collega’s in Nederland:
Ben jij al arrogant? En zo ja, wat doe jij er aan om arrogant te kunnen blijven? Zo nee, wat doe jij er aan om arrogant te worden?

Delen

Nee, deze gedachtengang gaat niet over een bewuste vijand van binnenuit. Het gaat wel over ongeziene medewerkers die hun krachten voor hun eigen goede doel inzetten, en daarmee de effectiviteit van het totaal kunnen ondermijnen.

Neem als voorbeeld eens een middelgroot bedrijf van, zeg, 500 kantoormedewerkers. Hoeveel BI-er’s werken er eigenlijk in zo’n bedrijf? Hoe groot is de afdeling die voor het ontwikkelen en beheren van rapportages zorgt? Ongeacht of je deze afdeling een BICC noemt of niet, waarschijnlijk zijn dat er maar 5 tot 10. Maar als je bij zo’n zelfde bedrijf kijkt, dan zwerven daar honderden, zo niet duizenden rapporten rond, op elk denkbaar bronsysteem en allemaal ongetwijfeld belangrijk.

Zijn al die rapporten dan gebouwd door die paar man van IT? Read the rest of this entry →

Delen

Bronsystemen de achilleshiel van BI, is dat een open deur? Jazeker!

Maar daardoor niet minder waar zoals deze week weer over de politie te lezen was. Daar blijkt na onderzoek dat een aantal van de bronsystemen onvoldoende aansluit bij de werkwijze van de politie. Hierdoor worden de systemen zo goed en zo kwaad als het gaat gebruikt door de eindgebruiker: de politieagent in uniform. Het resultaat is dat informatie niet altijd conform de werkelijkheid in de systemen komt. En als de frustratie maar hoog genoeg oploopt soms ook gewoon helemaal niet, vermoed ik. Read the rest of this entry →

Delen