Steeds vaker hoor ik mensen klagen over hoe vol hun inbox wel niet is. Dit kan een serieus probleem voor mensen vormen omdat ze simpelweg de tijd niet kunnen vinden de mailtjes te beantwoorden. Helaas is het regelmatig ook een soort status symbool geworden waarbij het aantal inkomende mailtjes zou aangeven hoe belangrijk iemand is.

“Toen ik terugkwam van vakantie stonden er meer dan 400 mailjes te wachten”

Er is veel geschreven over het efficiënt afhandelen van de mailbox en het opnemen van mailafhandeling in de time management. Hierbij wordt geadviseerd om niet continu de mail te checken. Het checken is een interruptie en afleiding van het eigenlijke werk en zinloos als er niet genoeg tijd is om er echt iets aan te doen. Verdere adviezen hebben te maken met het organiseren en filteren van de belangrijke mails.

Dit is echter symptoom bestrijding.
Vraag je eens af waarom er komen zoveel emails binnenkomen. Als er zoveel mails binnenkomen dat ze redelijkerwijs niet in een uur per dag af te handelen zijn zit er iets essentieel fout. Op een of andere manier wordt de mailstroom veroorzaakt. Dit kan bij jezelf liggen of natuurlijk ook bij de manier waarop mensen om je heen met mail omgaan.

CC-hell
We herkennen allemaal wel de overvloedig gebruikte cc. Deze zijn zeer irritant, de inhoud is niet voor je bedoeld, beslist niet voor je op maat gesneden en vraagt geen actie of reactie, anders was de mail wel aan je gericht. Maar de verzender veronderstelt wel dat je naar behoren op de hoogte gebracht ben door de cc. Dan zijn er nog de overbodige cc’s. “Als je hem niet wilde kan je hem toch gewoon weggooien?” Maar wel nadat je tijd verspild hebt met het lezen ervan. Laten we hier nu allemaal op letten en onszelf niet schuldig maken aan dezelfde bron van tijdverspilling.

Verbeter de wereld en begin bij jezelf
Bedenk verder ook bij elke mail die je verstuurt of de mail nodig en accuraat is, gericht op alle ontvangers, of de mail tijdig is, niet te vroeg en niet te laat, en of de mail summier genoeg is. Als je ook maar enigszins twijfelt niet versturen en opnieuw beginnen. Hiermee help je de ontvangers enorm, maar ook jezelf. Denk eraan dat elk verstuurd mailtje waarschijnlijk één of meer mailtjes terug veroorzaakt. Daar zat je nou net niet op te wachten.

Mismaakte takenlijst
Gebruik de inbox niet als time management tool of takenlijst. Teveel mensen waarmee ik werk verzoeken mij aan het eind van het gesprek een mailtje te sturen zodat ze het niet kunnen vergeten. Dit is omdat de inbox voor hen een takenlijst vertegenwoordigd. Daar is de mail niet geschikt voor. Daar is een takenlijst geschikt voor. Schrijf het op in je takenlijst en vraag niet om je mailbox verder te vervuilen.

Wie kan er delegeren?
Een andere –misschien wel de belangrijkste- bron van teveel mails voor managers is het onvolledig delegeren. Als je iets delegeert doe het dan goed. Dit betekent dat je de gehele verantwoordelijkheid en de daarbij behorende middelen en budgetten delegeert en het verder met rust laat. Dit moet formeel, zonder afspraken over op de hoogte gehouden worden, maar ook informeel. Informeel in de zin dat je volledig vertrouwen uitspreekt en uitstraalt naar degene die de taak op zich neemt. Als dat ook maar een beetje fout gaat ontstaat er een continue, overbodige informatiestroom, vaak in email cc’s, die je ervan proberen te overtuigen dat de taak naar behoren en tijdig uitgevoerd wordt.

Referenties:
Mail management: http://money.cnn.com/2007/05/17/news/economy/email.fortune/index.htm
Mail vermindert IQ: http://www.mindhacks.com/blog/2005/04/does_email_really_re.html
Lege Inbox: http://www.43folders.com/2006/03/13/philosophy

Niets heeft de ontwikkeling van open source software zo laten groeien als het internet en als je wilt kan je daar nu al de vruchten van plukken. Het enige wat je nodig hebt, is… het internet en wat lef. Naast de huis, tuin en keuken applicaties zoals firefox, openoffice en allerlei onbekende maar niet onbeminde producten, is er een schat aan software beschikbaar voor professioneel gebruik. Ik durf de uitdaging aan dat er voor elke applicatie een vergelijkbaar en vaak beter alternatief bestaat. Hier al vast een voorzet: Winzip 7zip, MS Office OpenOffice, Internet Explorer Firefox, Vista Ubuntu, MSN Messenger Gaim, Windows Media Center MediaPortal.
Daarnaast is de lijst van opensource software voor server applicaties bijna onuitputtelijk: Apache webserver, Jboss application server, MySQL, PHP, Samba, Joomla, Drupal, Zimbra, MediaWiki enz… Maar interessanter dan dat is de zoektocht naar opensource BI software, die opmerkelijk veel resultaat oplevert: MySQL of PostgreSQL als database, Kettle of Talend als ETL tool, Pentaho of SpagoBI als rapportage frontend. Daarnaast hoef je je niet te beperken tot alleen server componenten, maar zou je je hele project kunnen inrichten met open source software: Arrah (data Profiler and data quality), Openworkbench (projectmanagement), dbdesigner (data modelleren), enz…

Hier houdt het nog niet op, want je zou er ook voor kunnen kiezen al je bronsystemen in open source uit te voeren: LimeSurvey (enquête), Openbravo (ERP), SugarCRM, OrangeHRM, enz. En het ideale hiervan is dat het gehele datamodel vrij beschikbaar is en misschien bestaat er zelfs een kant en klare interface (natuurlijk open source), welke een hoop saai ETL werk bespaart. Probeer dat maar eens met SAP. Naast al deze kant en klaar oplossing zijn de mogelijkheden voor maatwerk m.b.v. open source ontwikkelingstools en onderdelen onbeperkt.

Wie alvast wil grasduinen zijn er hulpmiddelen zoals Sourceforge, BerliOS, OW2 forge en natuurlijk good old Google (geen open source ;))

Ooit wel eens stilgestaan bij de oorzaken van de vele files? Mogelijkheden te over; vrachtwagens, bestelbusjes, mensen die je er niet tussenlaten, iedereen blijft maar links hangen, niet netjes ritsen en misschien zijn er nog wel meer.

Op een willekeurige avond hoor ik op de radio dat er voor de volgende dag weeralarm (heuze storm met heftige windstoten) is afgekondigd. Ik ben er niet vroeger voor opgestaan, maar heb wel iets minder geteut in de badkamer, waardoor ik welgeteld 10 minuten eerder van huis wegreed dan op andere dagen. Wel fijn, want het zou wel een lange tocht worden

En wat schetst mijn verbazing: Door de hard wind rijdt men een stuk rustiger. De 120 kilometer wordt zelden overschreden. En……………………..Helemaal GEEN file.

Wat mij betreft is de oorzaak van de files bekend :-).

Er lopen her en der enthousiaste discussies over het al dan niet gebruiken van surrogaatsleutels bij datamodel implementaties. Deze discussie binnen data warehousing wil ik hier even loslaten, deze is sterk verwaterd door de gekozen modellering 3NF, Ster of Data Vault.
Bij OLTP systemen valt er regelmatig wel wat te zeggen van het gebruik van Surrogaat sleutels. Er is een snelle mapping naar objectmodellen, er is minder pijn in de applicatie bij wijziging van business sleutels, en zo kunnen er redenen genoeg zijn om een surrogaat sleutel als primary key voor de tabellen te kiezen.

Het is echter van essentieel belang dat de business keys wel onderkend worden, en ook altijd in de database als constraint afgedwongen worden. Wet van Wout: “Voor elke constraint die niet in de database afgedwongen is ontstaat na verloop van tijd een rij die niet aan deze constraint voldoet” De programma’s kunnen best de constraint proberen af te dwingen, maar op een moment wordt door migratie, handmatige actie of tijdelijk in productie nemen van een buggy programma of bewakende trigger de constraint toch overtreden.

Een nog belangrijkere wet vind ik: “Een surrogaat sleutel mag een systeem nooit verlaten”. Een surrogaat sleutel die het systeem verlaat is namelijk niet meer technisch noch mag door het initiërende system willekeurig aangepast worden. De surrogaatsleutel die het systeem verlaat wordt onbedoeld een business key die met de bijbehorende hoeveelheid aandacht bewaakt en gepubliceerd moet worden. Verwijdering moet in alle verwante systemen geverifieerd worden, garantie op unieke uitgifte bewaakt worden, aanpassing of hernummering moet door de systemen heen gepropageerd worden, noem maar op. Voorbeeld is personeelsnummer of klantnummer. Nog zwaarder is het als de sleutel de organisatie verlaat. Denk maar eens na over de hoeveelheid organisatie die nodig is voor beheren van het sofinummer of het kenteken van een auto.
Als een surrogaat sleutel zo beheerd moet worden zijn alle voordelen van zo’n sleutel ongeveer verdwenen en kan beter serieus over centrale, bewaakte uitgifte van een business key nagedacht worden, maar dan met in volle bewustzijn van de hoeveelheid werk die dit meebrengt.

Ik heb bij een klant gewerkt waar voor een ordersysteem prachtig 3NF gemodelleerd alle tabellen volgens de richtlijnen van Oracle en regelen der kunst gemodelleerd waren. Een werkelijk prachtig stukje werk, waar goed en gedegen over nagedacht was. Technische id’s voor de primary keys en altijd een unique index op de business key. Behalve bij orderregels. Ik kan die gedachten wel volgen. Het ordernummer is een technische sleutel verheven tot business key, primaty key orderId. De business key voor orderregel wordt dat orderId met iets als orderregel volgnummer? Een moeilijk te genereren volgnummer, terwijl er al een surrgogaatsleutel orderregelId is die vergelijkbare inhoud heeft. Laten we die maar weglaten. Later tijdens het koppelen van het systeem aan het mainframe, waar de levering gedaan werd, onstond een probleem. De status van levering werd per stuks geleverd en soms werd 1 artikel van de 2 bestelde afgeleverd, waardoor de orderregel met aantal 2 eigenlijk 2 statussen had.
Als er een business key had bestaan had men deze vast gehouden en een nieuwe entiteit orderregel in status bedacht of zo. Maar de ontwerper/programmeur voelde zich bevoegd om de orderregel te splitsen in twee regels met aparte statussen, met de som van de aantallen gelijk aan het bestelde aantal. Bevoegd omdat de sleutel die gebruikt was toch maar technisch was, en die dus op technische gronden opnieuw uitgegeven of zelfs verwijderd kon worden.
Nu was er een data warehouse aan dit systeem gekoppeld die niet anders kon dan de technische sleutel orderregelId als business key bombarderen; een andere identiteit had de regel niet. Consternatie alom toen ineens orderregels verwenen!
Zo was met de beste intenties de surrogaatsleutel buiten het systeem getreden, niet verheven tot business key en niet in identiteit of uniciteit niet te bewaken in welk systeem dan ook.

Ik heb ooit een project gedaan bij een klant die met ernstige ruimteproblemen te kampen had. Hoog in de boom wilde men vooralsnog niet investeren in tijdelijke kantoorruime. Het gevolg was dat de verschillende kantoortuinen overvol zaten. Een aantal externen hadden zelfs geen vaste werkplek. Bij aankomst moest je maar op zoek gaan naar een PC en buro die die dag vrij zou blijven.
Het projectteam (10 man) was verdeeld over verschillende ruimtes. De wijze van onderlinge communicatie was toch vooral de email. Incidenteel liep je bij elkaar langs, en er werden ook overleggen geplanned, maar alleen als er een concreet onderwerp was dat een meeting rechtvaardigde. Opvallend was dat in deze situatie er op geen enkele wijze enige mate van wat ik dan maar secundaire informatieoverdracht noem was. Projectleden wisten van elkaar niet precies waar men mee bezig was, ook issues die ergens al waren tegengekomen waren onbekend voor anderen. Een veel gemaakte opmerking was dan ook dat het projectgevoel ontbrak.
Wat ik vreemd vind is dat als een organisatie voor veel geld de hulp inroept van een aantal externe consultants, er geen geld is voor de huisvesting van deze mensen. Het is uiteindelijk moeilijk in geld uit te drukken wat er aan synergie verloren gaat als je een projectteam niet bij elkaar zet, maar ik weet zeker dat het meer is dan wat men kwijt zou zijn aan extra huisvesting.

Ondanks dat ik een ‘gewone’ medewerker van Euclides ben, ligt de verantwoordelijkheid voor opleidingen bij mij. Het leek mij erg leuk om, naast mijn consultancy uren, ook wat tijd aan interne taken te besteden. Opleidingen leent zich daar heel goed voor en leek mij ook erg leuk om op te pakken.

Praktisch betekent het dat er een aantal uren per week beschikbaar is om van alles met betrekking tot opleidingen te regelen. En ik heb de bijbehorende bevoegdheden gekregen in de zin van een geldbudget, een urenbudget (ieder uur niet declarabel gewerkt kost ook geld) en het mandaat om hierover te beslissen.

Wat schetste mijn verbazing toen ik, inmiddels de budgetten kennende, eens ging kijken hoeveel er van op gemaakt was.
Qua geldbudget zag het er goed uit, maar inmiddels hebben we, met de opleidingen die nog gepland zijn, qua uren het budget al overschreden. Tja, wat nu?

Wat er vervolgens gebeurde is heel tekenend voor Euclides en dat is ook één van de redenen dat ik er zo graag werk. In een gezamenlijke meeting heb ik de situatie uitgelegd. Vervolgens heeft de directie een overzicht laten zien van de activiteiten waar interne uren voor gebudgetteerd zijn. We hebben besproken waar er nog wat ruimte was, welke oplossingen meer of minder de voorkeur hadden en tot slot hebben we gezamenlijk besloten wat we inleveren om weer ruimte in de opleidingsuren te krijgen. En alles zonder gemopper, maar juist met een hele positieve insteek.

Dat is nou echt des Eclides’.

Business Intelligence kan op een veelheid van manieren worden geleverd. Als het uitsluitend gaat om het eenmalig presenteren van informatie uit de organisatie in een bepaald formaat, volstaat meestal de combinatie Excel en een paar dagen drag-and-drop. De adder onder het gras hier is duidelijk het woord “eenmalig”. Over het algemeen willen we dat de informatie herhaald, op dezelfde wijze, gecontroleerd wordt geleverd. Veelal willen we ook dat de wijze waarop de informatie wordt vergaard en gepresenteerd, flexibel, aanpasbaar, uitbreidbaar, robuust en op de toekomst voorbereid is.

De functionaliteit is nog steeds “presenteer informatie uit de organisatie”, maar de wijze waarop hier invulling aan wordt gegeven is veel bepalender voor kosten en inspanning, dan de functionaliteit sec.

Naar mijn smaak is dit het essentiele onderscheid tussen architectuur en ontwerp; ontwerp richt zich op het realiseren van functionaliteit, terwijl architectuur zich richt op het realiseren van alle niet-functionele kwaliteitseisen.

En zo hebben we aan de linkerkant enkele Excel-sheets die de vereiste informatie leveren op basis van een paar weken muisklikken en aan de rechterkant een data warehouse-architectuur en -infrastructuur waarin enkele miljoenen is geinvesteerd, die ogenschijnlijk hetzelfde levert. Het verschil zit slechts in de niet-functionele kwaliteitseisen, maar wat maken die een verschil.

Bij verschillende klanten ben ik de situatie tegengekomen dat er gebruik werd gemaakt van een bepaald tool zonder dat daar een gedegen toolselectie aan voorafgegaan was. Nu is het niet zo dat ik vind dat je altijd een uitgebreid toolselectietraject moet doen alvorens een tool te selecteren, maar er functioneel over nadenken kan nooit kwaad.
Kennelijk is het in Nederland zo dat veel toolselecties op de golfbaan plaatsvinden. Een vertegenwoordiger van een tool praat met een directeur en voordat iedereen het weet is er een tool naar binnen gereden dat niet beheerd kan worden, niet de benodigde functionaliteit biedt, technisch rammelt aan alle kanten, en zorgt voor beel bijkomende kosten. De directeur wordt waarschijnlijk beloond voor zijn keuze, terwijl de rest van de organisatie zich in vreemde bochten moet wringen om e.e.a. in de lucht te krijgen.