rudolf_kleurenbalk.png

Releasematig werken

Datawarehouses worden in de regel gebouwd en beheerd door een IT-afdeling. Daardoor wordt deze omgeving dus meestal vanzelfsprekend op dezelfde manier ontwikkeld en beheerd als operationele systemen. Maar een rapportageomgeving is iets heel anders dan een operationele omgeving. Met name een strikte releasekalender beperkt de bruikbaarheid en het nut van de rapportageomgeving aanzienlijk. Het is verstandig om daarom om een andere manier met releases om te gaan.

Bij een rapportageomgeving kun je een onderscheid maken tussen twee delen. De achterkant, meestal een datawarehouse, waarin de informatie uit verschillende bronnen wordt verwerkt en omgevormd tot eenvoudig voor de business bruikbare informatie en de voorkant, de omgeving waarin de gebruiker zijn rapportages kan raadplegen. Deze twee delen kun je het beste verschillend behandelen.
De achterkant moet een stabiele omgeving zijn. Er zijn meestal afhankelijkheden met andere systemen en aangezien hier vaak ook archivering en opschoning plaatsvindt, zijn fouten hier ook niet zo gemakkelijk te herstellen. Dit is een omgeving waar het belangrijk is om releasematig te werken, zodat de stabiliteit van de omgeving zo goed mogelijk kan worden gegarandeerd. Wel is het jammer om te wachten met het in productie brengen van nieuwe functionaliteit tot de vooraf vastgestelde releasedatum, als de ontwikkeling is afgerond. Informatie is waardevol, zodra deze beschikbaar is, dus waarom niet direct is productie brengen als het mogelijk is?

De voorkant bestaat uit een repository en rapportages. Deze omgeving kan zowel standaardrapportages als ad hoc rapportage mogelijkheden bieden. Hier veranderen de wensen voortdurend en dat is ook de bedoeling. Als de omgeving intensief gebruikt wordt ontstaan er nieuwe vragen en nieuwe wensen. Als je hier niet flexibel op inspeelt, zullen de gebruikers andere oplossingen verzinnen, waarvan Excel de beruchtste is. Het is dus jammer om vast te zitten aan de releasekalender. Er volgen nu een paar voorbeelden, waarbij je liever niet wilt wachten op de eerstvolgende releasedatum (vaak één keer per kwartaal) en een illustratie wat het effect is als je gebruikers laat wachten.

  1. Gebruikers willen graag in een rapport een omschrijving toevoegen bij een bepaalde code. Deze omschrijving werd niet meegeleverd vanuit het bronsysteem, maar is algemeen bekend op de vloer, maar niet bij de managers. Dit kun je heel gemakkelijk via de achterkant toevoegen via een codetabel. Als je dat niet doet, is er een kans dat gebruikers in hun rapporten handmatig codes gaan vertellen (bijvoorbeeld via een CASE WHEN of DECODE). Dit is zonde van de tijd en wat als de betekenis ooit wijzigt? 100 rapporten aanpassen?
  2. De gebruikers willen graag de omzet in het lopende jaar (en het vorige en twee jaar geleden) standaard kunnen toevoegen aan de klantgegevens. Dit kan natuurlijk berekend worden in het rapport, maar meestal komt dat de performance niet ten goede. Door deze waarde als extra attribuut toe te voegen aan de klantdimensie en in de laadprocessen te berekenen, voorkom je performanceproblemen of het bewerken van het rapport in Excel.

Mijn advies is om dit soort aanpassingen in een releasecyclus van maximaal twee weken uit te voeren. Dat biedt voldoende flexibiliteit en is ook goed uit te leggen aan de gebruikersorganisatie. Juist dit soort kleine toevoegingen verhogen het gebruiksgemak en daarmee de klanttevredenheid en het wederzijds begrip aanzienlijk. Ik zie het in de praktijk vaak misgaan doordat de ICT-afdeling vanwege releasekalenders niet op dit soort kleine wensen mag reageren.
Tot slot een waarschuwing: Het is niet de bedoeling elke wijziging maar in het wilde weg door te gaan voeren. Zorgvuldig testen blijft altijd nodig. Met name als de wijziging een grote groep standaardrapportages raakt, is het verstandig om dit heel goed te testen. Als de standaardrapportages gebruikt worden, krijg je veel klachten en dat zijn meestal niet de gebruikers die de snelle reactie op kleine wensen kunnen ervaren.

Reageren? | 15-06-2009 | RSS

scheidingslijntje

Flip zei op 14-08-2011

No more s***. All posts of this qluaity from now on

____________________________________________________________________