NIJKERK - Een van de leukere zaken op Internet is, dat je je bestelling kunt volgen via tracking software. Het achterliggende proces is eenvoudig, de softwarematige ondersteuning behoorlijk ingewikkeld. Er zijn veel meer mogelijkheden met tracking, ook in administratieve omgevingen.

De mogelijkheid van tracking is niet alleen leuk, maar ook handig. Voor kleinere bedrijven, eenpitters en zeker ook voor particulieren. Je ziet de computer die je via Internet besteld hebt naar je toe komen, en je kunt je agenda afstemmen op de bezorging. Mits er voldoende informatie bij gegeven wordt, wat aan het begin van de ontwikkeling wel eens problemen gaf. Dan stond het pakket dagenlang ‘in transit’, om plotseling niet meer traceerbaar te zijn. Bij wijze van spreken kon de bezorger dan al op de stoep staan, maar het kon ook wel twee dagen later zijn. Die kinderziektes zijn er langzamerhand wel uit.

Klant hoeft minder te weten
De achterliggende procesketen is interessant, maar niet vreselijk ingewikkeld. Wat het moeilijk maakt zijn de aanpassingen die leverancier, verlader(s) en bezorgers moeten maken in de software die zij zelf gebruiken om goederen te traceren. In de eerste plaats moet er een code aan het pakket worden toegevoegd, die door de leverancier wordt gemaild naar de klant. Vervolgens moeten alle schakels in de keten van processen diezelfde code gebruiken voor hetzelfde pakket, en moet de software geschikt worden gemaakt voor gebruik door klanten, via Internet.

Lastig daarbij is, dat klanten maar een deel van de informatie hoeven te weten die de bedrijven in de keten nodig hebben: het is voldoende te weten dat iets ‘op dit moment’ onderweg is van Amerika naar Rotterdam, terwijl de bezorger van de goederen ook graag wil weten in welke container of op welke pallet het zich bevindt.

Ook in ‘administratieve’ situaties spelen dergelijke processen of procesketens een prominente rol. Ik heb eens in een afdeling van softwarebeheerders gevraagd naar de manier waarop zij konden nagaan waar en in welk stadium zich een wijzigingsaanvraag bevindt. De betreffende afdeling had juist zijn processen en de organisatie op orde gebracht.

Ruziënde managers door wijzigingsaanvraag
Er was een afdeling voor de probleemmeldingen; een afdeling voor het onderzoek naar de oorzaken van fouten in de software; twee afdelingen voor het formuleren en in gang zetten van wijzigingen, onderverdeeld naar interne soorten functionarissen (klanten). Ook was er een afdeling die de configuratie beheerde. Kortom, het was allemaal heel ITIL.

Elke afdeling had zijn eigen proces geformuleerd. Ik zag dat de processen zeer gedetailleerd waren en hoorde dat er nogal verzet tegen was geweest. Mijn vraag naar het stadium van een wijzigingsaanvraag kon dus alleen maar in vruchtbare aarde vallen. Om te beginnen vlogen de heren afdelingsmanagers elkaar in de haren over het begrip ‘wijzigingsaanvraag’. De relatie tussen een probleem en een wijziging was niet bekend en de procesmanager Wijzigingen zweeg in alle talen.

De reden daarvoor bleek te zijn, dat hij door de afdelingsmanagers voornamelijk genegeerd werd. Zijn taak bestond uit het uitdraaien van overzichten over de gemelde problemen ten behoeve van sturing door de managers en het voorbereiden van besprekingen over de wijzigingen per software–onderdeel. Het was een tamelijk genante vertoning.

Gemeengoed
Nog veel genanter is, dat de oplossing voor de invoering van ITIL die deze mensen gekozen hadden, gemeengoed is in de wereld van softwarebeheer. In feite vráágt de methode om dergelijke problemen en alleen daar, waar mensen zijn ingeschakeld die op een echte, procesmatige manier denken, komt het tot goede en werkbare oplossingen.

Werkbaar, omdat er oplossingen komen voor problemen die bij de uitvoerende medewerkers, op de werkvloer, bekend zijn. Dat heeft als bijkomstig, groot voordeel, dat het verzet tegen de invoering van ITIL, of om het even welke andere beheermethode, verdwijnt als sneeuw voor de zon.

Beheersbaar
Het andere voordeel is, dat de beheersbaarheid groter wordt, omdat de managers de juiste informatie krijgen. Zo is de relatie tussen wijzigingsaanvragen en probleemmeldingen helder. Verder kan er prioritering plaatsvinden over de uitvoering van wijzigingen op basis van de ernst van de problemen of naar andere criteria (zoals belanghebbende).

En wat is er mooier dan een functionaris (een klant!), die op een oplossing voor zijn probleem zit te wachten, te kunnen melden dat het op die–en–die datum in release nummer zoveel is opgelost? En dat er tijdelijk een noodoplossing wordt aangebracht, die morgen van kracht wordt?

Carolien Kars | Flow Profile