dinsdag 28 april 2009

Besparen op je imago met BPM

Ik zal een aantal praktijk voorbeelden geven van zaken die ik het afgelopen jaar heb meegemaakt die leiden tot schades die voorkomen hadden kunnen worden door processen goed op orde te hebben.

Twee weken geleden kocht ik een auto uit een showroom. Na het maken van een ophaal afspraak vroeg ik tussentijds naar een kenteken zodat ik de verzekering kon regelen. Het kenteken was nog niet binnen dus ik kreeg geen antwoord. Een dag voor het ophalen nam ik nogmaals contact op en was mijn order kwijt. Het koopcontract stond op mijn naam, maar het was een auto voor mijn vrouw, en omdat zij al jaren zaken doet werd het gemakshalve op haar naam over gezet. Maar wat bleek: Administratie bleek een fout gemaakt te hebben en geen kenteken is aangevraagd waardoor de ophaal afspraak niet door kon gaan omdat er bij nieuwe auto’s 3 werkdagen voor een kenteken staan. Voor mij is dit onbegrijpelijk. De verkoper gaf aan dat dit soort dingen nu eenmaal gebeuren. Maar voor mij betekend het dat een bedrijf zijn processen en de beheersing daarvan gewoon niet op orde heeft.

Vorig jaar heb ik een keuken aangeschaft en laten plaatsen. Het laatste schroefje van de keuken werd door een waterleiding heen geboord. Omdat het wat hoger in de muur was duurde het een dag voordat de plas water onder mijn keuken vandaan kwam. Na een sorry kwam de monteur snel het probleem verhelpen en hij zij dat het echt een typisch pechgevalletje was. Ik kon me daar nog net in vinden, maar hoorde later dat er goedkope apparaatjes bestaan waarmee je kunt detecteren waar de leidingen lopen (water en stroom). Het is dus geen pech, het is gewoon geen onderdeel van de procedure en daarmee amateuristisch.

Een laatste voorbeeld is het bestellen van een hardhouten tuinbankje. Dit had ik via het internet gedaan en naast dat het bestelproces curieus was heb ik een dag later alsnog de organisatie gebeld. Zij gaven aan het bankje wel naar een dichtstbijzijnde vestiging te sturen waar ik deze op kon komen halen. Na telefonisch contact te hebben met de vestiging kon ik het ophalen. Het was een bankje van 150 cm, en toen ik de doos in mijn handen had was deze ook 150 cm hoog. Nadat ik het in elkaar gezet had bleek het een bankje van slechts 120 cm te zijn. Natuurlijk had ik het typenummer moeten controleren, maar bij het afgeven (en dragen naar de auto) is dit iets wat de verkoper had moeten doen.

Om een kort verhaal lang te maken: Een proces is een serie handelingen met een begin en een eind. Elk proces dat gestart wordt, moet worden afgehandeld. Pas als je een bepaalde actie hebt uitgevoerd kon het proces naar een volgende stap gebracht worden. Dit simpele principe had de eerste fout van het kenteken kunnen voorkomen.

Ook het plaatsen van een keuken is een proces en dient gewoon vaste stappen te hebben welke dienen te worden uitgevoerd. Als je die checklist gebruikt kun je nooit iets vergeten. Een van de onderdelen is het meenemen van apparatuur waarmee je leidingen kunt detecteren een ander onderdeel is dat voordat je gaat schroeven je weet waar de leidingen liggen.  Een checklist maken is geen draak van een opdracht en creëert ook nog eens rust voor de monteur en een goed te verdedigen werkwijze die overigens door middel van evolutie steeds beter wordt.

Ook het probleem van het bankje is een probleem wat middels een goed proces kon worden afgevangen.

Natuurlijk is het niet eenvoudig om je bedrijf proces gestuurd te maken, maar in alle drie de gevallen heeft het bedrijf imagoschade opgelopen. Een negatieve ervaring wordt nu eenmaal beter verspreid dan een goede ervaring. Daarnaast heeft het “proces denken” meer voordelen dan alleen het voorkomen van een negatieve ervaring, maar dat is voer voor een volgende topic.

maandag 20 april 2009

Zaken doen

Zaken doen met mij is eenvoudig. Neem contact op per mail of mobiel om een vrijblijvende afspraak te maken. Een eerste dagdeel advies is altijd kosteloos.

Een korte samenvatting van mijn onderscheidend vermogen:

  • Afspraak is afspraak
  • Duurzaam kennisdelen (ik geef geen vis maar een hengel)
  • Ik overbrug de kloof tussen business en IT.
  • Methodieken die werken in een taal die u spreekt.
  • Snel en duurzaam en zodoende een dubbele besparing

Mijn standaard tarief is 95 euro per uur exclusief BTW. Een speciale prijs is mogelijk bij een duurzame samenwerking.

Henri Koppen
henri@henrikoppen.nl
06-26112194

zondag 5 april 2009

Genericiteit: Deel 1

Hoe flexibeler een applicatie is ontwikkeld hoe breder deze kan worden ingezet en zal aansluiten bij de behoefte van een organisatie. Deze flexibiliteit ontstaat doordat bepaalde aspecten van de applicatie zoals het datamodel, de code, de gelaagdheid generiek zijn opgezet. Er bestaan veel misverstanden over genericiteit en het wordt nogal eens verkeerd toegepast, ook zien sommige opdrachtgevers generiek als het toverwoord waardoor de applicatie alles aan kan.

Het woord generiek als woord werd in de vorige eeuw voornamelijk toegepast bij medicijnen waarvan het patent was verlopen. Het bekendste voorbeeld is aspirine. Asperin was oorspronkelijk de naam van het medicijn maar nu staat het voor pijnstiller. Pijnstiller is een generiek woord of verzamelnaam voor alle medicijnen die wij kennen om pijn te bestrijden.

Maandag is generiek voor alle maandagen. Maandag 1 April is generiek voor alle maandagen die op 1 April vallen en is dus minder generiek. Maandag 1 April 1985 is niet meer generiek. Het gaat om precies 1 dag.

Om een vertaling te maken naar techniek: Stel een applicatie die op een school gebruikt worden heeft een tabel Studenten waarin de gegevens van studenten opgeslagen worden. Als de applicatie ook iets doet met docenten zal er dus ook een tabel docenten gemaakt moeten worden. Welke velden zullen deze tabellen bevatten? Waarschijnlijk zaken zoals naam, geboortedatum, BSN, etc. Deze velden komen dus meteen twee keer voor en hebben dus ook twee venster nodig om beheerd te worden en zo verder. Zowel studenten als leraren zijn mensen met veel dezelfde eigenschappen, het is dus logisch om beide in 1 tabel onder te brengen en hetgeen wat hun student of docent maakt te scheiden. De tabel mensen is dus generiek voor studenten en docenten, maar wat schiet je hier nu mee op? Waarin zit het voordeel voor generiek? Voornamelijk wellicht dat de programmeur maar 1 basis venster hoeft te maken voor het vullen van basis gegevens. Het datamodel wordt namelijk iets ingewikkelder. Als een leek naar het datamodel kijkt ziet hij direct het verschil tussen docenten en studenten. Dit voorbeeld dient alleen ter illustratie dat generiek maken niet per se betekend dat iets beter wordt door het generiek te maken. Per voorbeeld moet je ook kijken voor wie het voordeel is.

Een extreem voorbeeld van generiek is dat je elke database kunt nabouwen met maar twee tabellen (en eigenlijk zou het ook in één tabel kunnen). Eén tabel voor het benoemen van tabellen en kolommen, één tabel om records uniek te identificeren en kolomwaardes in op te slaan.

In dit laatste voorbeeld kun je alles namaken zonder aan de tabelstructuur te hoeven wijzigen. Maar wat schiet je hiermee op? Performance zal per definitie minder zijn, en de complexiteit komt te liggen bij de inrichter van de database en het schrijven van de documentatie. Ik schrijf dit omdat genericiteit altijd een doel moet dienen en dat je heel gemakkelijk je doel voorbij kan schieten. Ook zorgt het generiek maken van een database en applicatie dat de complexiteit verschuift van de programmeur naar de inrichter. Ook kan genericiteit een extra complexiteit met zich meebrengen. De impact van een wijziging wordt als een regel groter en het testen daardoor belangrijker.

Het is vaak helemaal niet nodig heel generiek te zijn. Je moet de genericiteit vooral toepassen op de gebieden die aan verandering onderhevig zijn.

Van bedrijfsprocessen weet je dat deze niet in steen gebeiteld zijn en natuurlijk gezien veranderen. Een bedrijfsproces zou dus generiek moeten worden opgezet. Een voordeel is dat het bedrijfsproces ook veel dichter staat bij de business analist dan bij de programmeur. De programmeur maakt zich verdienstelijk door de inrichting generiek te houden zodat de business analist het proces kan vormgeven en inrichten. De impact van een wijziging is daardoor organisatorisch en niet iets waar een database administrator (DBA) van wakker ligt.

Niet generiek is als je een object of tabel veldnamen heeft als: KlachtId, Indiener, Oplosser, KlachtGemeldOp. Wel generiek is als je een object of tabel veldnamen heeft als: ProcesId, ProcesStarter, ProcesEigenaar, ProcesInvoerDatum. De eerste genoemde velden passen alleen bij een klachtproces, de laatstgenoemde velden passen bij ieder bedrijfsproces. Dat een proces van het type klacht wel velden nodig heeft specifiek voor (bepaalde) klachten is triviaal.

Generiek maken van software gebeurt of verschillende lagen. Het datamodel kan generiek zijn door een tabel personen te gebruiken in plaats van Studenten en Docenten. De applicatie zelf kan uit meerdere lagen bestaan: Presentatielaag, Businesslaag, Datalaag. Door een datalaag te gebruiken kun je de applicatie bijvoorbeeld op verschillende typen databases laten draaien zoals Microsoft SQL Server, Oracle, MySQL, etc. In diverse blogs zal ik meer op deze specifieke zaken ingaan. Om toch een stokpaardje van me aan te halen vind ik dat een datalaag meestal geschreven moet worden voor één type database. Het grote nadeel van generiek in de datalaag is anders dat je bepaalde voordelen van een database niet kunt gebruiken omdat andere databases deze niet bevatten. Met andere woorden; doordat de applicatie op meerdere typen databases kan functioneren kun je alleen de functionaliteit gebruiken die op alle databases aanwezig is. Dit is overigens heel kort door de bocht, maar is wel een belangrijk inzicht.

De mate van genericiteit heeft invloed op de levenscyclus van een applicatie. Applicaties veranderen. Als de uiteindelijk functionaliteit erg afwijkt van het beginvisie waaruit de applicatie ontwikkeld is, dan is de rek er op een gegeven moment uit en moet de applicatie vanaf de grond weer opnieuw geschreven worden.

In deze blog heb ik een introductie gegeven over genericiteit zonder de diepte in te gaan of bepaalde voorbeelden uit te werken, deze komen aan bod in volgende blogs. Heb je een verzoek hierin of vragen? Ik vind het leuk als je contact met me opneemt en ligt één en ander graag toe.