De productieverstoring

De productieverstoring

Wat is het ‘fijn’ dat er af en toe productieverstoringen zijn…

Bij organisatie X ligt een applicatie er al twee dagen uit. Na een regulier gepland en uitgevoerd onderhoud, uiteraard in het weekend, blijft de applicatie(server) niet meer op te komen. Hoewel het geen bedrijfskritische applicatie is, is het toch vervelend voor gebruikers. Sommige gebruikers werken vanaf huis, ook in het weekend. Degene die probeerde in te loggen na het verstrijken van het gecommuniceerde onderhoudsvenster, merkten het het eerste. De melding van de in het weekend opgetreden verstoring werd maandagochtend om 9 uur verstuurd naar alle medewerkers. Rijkelijk (te) laat. Na twee dagen hard werken, interne en externe escalaties (leverancier), wordt de oorzaak gevonden en het probleem verholpen.

Hoewel productieverstoringen altijd vervelend zijn, ben ik oprecht blij dat ze -zij het af en toe- optreden. Hiermee wordt aangetoond wat het oplossend vermogen is van de organisatie. Ook wordt duidelijk op welk volwassenheidsniveau de incident- en problemmanagementprocessen en procedures (BiSL, ASL, ITIL) zich bevinden en, voor zover van toepassing, wordt tenslotte de relatie tussen de organisatie en haar leverancier(s) beproefd.  Nadat de verstoring is verholpen, vindt er een evaluatie plaats. Als het goed is leiden de resultaten en conclusie van deze evaluatie tot preventieve en reactieve verbeteringen. Natuurlijk wordt bekeken welke acties/activiteiten kunnen worden uitgevoerd c.q. verbeterd om de fout in het vervolg te voorkomen. Daarnaast wordt bekeken op welke wijze de samenwerking, communicatie, afhandeling en andere belangrijke processen kunnen worden verbeterd wanneer een incident of probleem optreedt. Wanneer we uiteindelijk terugkijken op hetgeen is gebeurd, moeten we kunnen vaststellen dat we er beter van zijn geworden. Een kleinere kans op dezelfde verstoring, verbeterde processen en een hoger niveau dienstverlening. Dan pas spreken we van een echt lerende organisatie.

Ook het applicatielandschap en de onderliggende faciliterende technologie moeten in een organisatie bestuurd worden. Vooraf moet een organisatie een goed beeld hebben van wat dit applicatie- en technologielandschap bijdraagt aan de doelen van de organisatie. Ook moet men een beeld hebben van een naar behoren presterend applicatie- en technologielandschap. Met andere woorden:  bij welke QoS, bijvoorbeeld aangaande beschikbaarheid, uptime, performance, afhandelingssnelheid (vraag, incident, probleem) en bijvoorbeeld uitwijksnelheid, is men tevreden. De meeste van deze aspecten kunnen prima in key performance indicators (KPI) worden vertaald en in service level agreements (SLA) worden vastgelegd, zodat IT-afdelingen en -management op basis van het al of niet halen van het afgesproken niveau van dienstverlening. Kortom, ook hier kunnen we business intelligence (BI) toepassen, welke leidt tot de relevante rapportages en analyses, die bijvoorbeeld kunnen samenkomen in een (management) dashboard …

About the Author

Martin Misseyer (1964) is als CIO werkzaam bij Ordina. Zie de pagina 'Over Martin ...' Alle onderwerpen en commentaren van zijn hand zijn op persoonlijke titel gemaakt.