Eerder schreef ik al over de veranderingen die cloud computing ons gaat brengen en dat het nu de tijd is dat bedrijven een cloud strategie ontwikkelen. De cloud bied niet alleen mogelijkheden voor bedrijven om verder te automatiseren, flexibel te zijn en kosten te besparen, maar het verandert ook de markt voor consumenten, de manier waarop de jeugd werkt en leert en wellicht dus het hele ecosysteem van een branche.
Daarnaast zijn de kosten voor het huidige landschap hoger dan de optelsom van hardware, licenties en arbeid van de IT afdeling om het in de lucht te houden. Hoe hoger de gemiddelde leeftijd van applicaties hoe meer verborgen kosten er zijn. Verborgen kosten zijn wachttijden van medewerkers bij uitval, extra handelingen die nodig zijn omdat een systeem niet optimaal (meer) is, extra tijd die nodig is bij het uitvoeren van handelingen omdat het landschap complex is.
Tijdens een presentatie van Martien Ouwens van Oracle op een Computerworld event gaf Martien aan dat bedrijven die goed zijn in het rationaliseren van het applicatielandschap, goed zijn in het adopteren van cloud computing.
Toevallig schreef Ron Tolido van Capgemini ( http://goo.gl/CBlGQ ) onlangs ook over het rationaliseren van het applicatielandschap in de Automatiseringsgids, en dat dit één van de grootste kopzorgen van CIO’s geworden is.
Nu is dus een goed moment om hier wat handen en voeten aan te geven.
Saillant detail is dat het lastig is om een definitie van applicatielandschap te vinden terwijl de term al qua beeld scheppend is. Mijn definitie is de gebruikte applicaties binnen een organisatie inclusief de onderliggende samenhang.
Met rationaliseren wordt het praktisch maken of economisch inrichten bedoeld. Dat huidige legacy applicaties een groot obstakel vormen voor het bewegen richting cloud computing lijkt mij een no-brainer. De applicatie heeft al een hoop meegemaakt en is vergroeid met de organisatie waardoor onderlinge afhankelijkheden in de regel alleen maar zijn toegenomen. Het gat tussen cloud en deze applicaties is dus ook het grootst.
Een belangrijk inzicht dat de slagingskans van rationaliseren vergroot is dat de projecten die voortvloeien uit rationalisatie wel betrekking hebben op de IT maar zeker niet allemaal IT projecten zijn. Het zijn veelal ook organisatorische veranderingen. Rationaliseren is dus een symbiose van organisatie en techniek.
Een voorbeeld: Door een opdrachtgever werd me gevraagd structurele management rapportages te genereren om productiviteit inzichtelijk te maken. Snel ontdekte ik dat afdelingen onderling een iets andere methode hadden voor het registreren van uren. Dit maakte berekeningen arbeidsintensiever en moeilijker. Door hier eerst uniformiteit in aan te brengen (organisatorisch, aansturen van chefs), hoefde er minder aanpassingen gedaan worden om de rapportages structureel te kunnen genereren. Vaak wordt de applicatie aangegrepen om een organisatorisch probleem te kunnen omzeilen.
Overstap naar virtueel
Bij veel MKB bedrijven draaien applicaties (en database) nog op fysieke servers. Als een moederbord het begeeft faalt de server en de applicatie. Hoewel het verplaatsen van software van een vaste server naar een gevirtualiseerde server zeker niet altijd een appeltje-eitje is (http://goo.gl/jRynh) , maakt het wel de weg vrij om de applicatie te zijner tijd te verplaatsen naar een datacenter. Kijk in hoeverre de servers zijn afgeschreven, of wellicht dat de servers ook te gebruiken zijn voor virtualisering.
Toen applicaties werden aangeschaft en ingezet, waren er wellicht minder mogelijkheden om deze applicaties te verbinden met andere applicaties. Vaak zie je dat bij het volwassen worden van applicaties er ook veel gedaan wordt aan integratie mogelijkheden. Omdat deze er in het begin niet waren zijn deze waarschijnlijk nooit ingezet en is hier omheen gewerkt of is er maatwerk voor gemaakt. Het gebruiken van Application Programming Interfaces (API), bijvoorbeeld in de vorm van (platform onafhankelijke) webservices, kan het rationalisatie proces enorm versnellen en eenvoudiger maken. Er kan toegewerkt worden om de oorspronkelijke software meer als standaard te gebruiken. Ik zie vaak dat bedrijven maatwerk laten bouwen op standaard software. Dit heeft drie grote nadelen:
1) Er wordt betaald voor de licenties en er wordt betaald voor het maatwerk inclusief onderhoud.
2) Door het maatwerk is het upgrade proces van de standaard software duur en moeizaam geworden waardoor er slechts traag van nieuwe functionaliteit gebruik gemaakt kan worden terwijl er in feite wel voor die ontwikkeling wordt betaald
3) Standaard software wordt doorontwikkeld. Dit zit het maatwerk steeds meer in de weg en de architectuur van de software sluit steeds slechter aan op het maatwerk
Standaardisatie is bijna een vereiste voor cloud computing. Om te kunnen profiteren van drastische kostenverlagingen lijkt rationaliseren dus onvermijdelijk.
Rationalisatie is strategie. Strategie werkt alleen als het op het hoogste niveau gedragen wordt en tot op het laagste niveau wordt uitgevoerd. Rationalisatie zal dus pas effectief uitgevoerd kunnen worden als de directie erachter staat en niet alleen in naam, maar ook in daad. Rationaliseren leidt tot pittige trajecten welke doorzettingskracht en focus vragen, tel hierbij de weerstand tegen verandering op en de financiën die nodig zijn en dan is de rol van sterk leiderschap noodzakelijk.
Rationaliseren is niet alleen een IT aangelegenheid
Zoals ik eerder in dit artikel aangaf leidt rationaliseren van applicaties ook tot rationaliseren van processen. Hoeveel procent van de processen wordt standaard uitgevoerd, en hoeveel procent heeft uitzonderingen? Een goede indicatie van standaard werk is de hoeveelheid parate kennis die een medewerker nodig heeft om zijn werk te kunnen doen. Hoe meer opgebouwde parate kennis iemand nodig heeft, hoe minder standaard het proces blijkbaar is. Dit leidt tot langere inwerktijden, meer afhankelijkheden en daardoor hogere salarissen. Door te sturen op de standaard, zoveel mogelijk afscheid te nemen van uitzonderingen en het bevorderen van uniformiteit (mensen nemen dezelfde beslissingen op gelijke situaties) worden processen gerationaliseerd wat leidt tot betere aansluiting op de cloud.
Om inzicht te krijgen in de latente rationaliseringsbehoefte van de organisatie stel ik voor om antwoord te vinden op een aantal vragen:
- Hoeveel parate kennis is nodig om het primaire productieproces uit te voeren? (standaardisatie)
- Worden processen door verschillende mensen met gelijke functies hetzelfde uitgevoerd? (uniformiteit)
- Versterkt aanwezige software en automatisering de productiviteit?
- Wordt het standaard proces en de uitzonderingen door dezelfde mensen uitgevoerd?
- Is integratie van IT en hoe werk wordt uitgevoerd met de beschikbare applicaties vaak een onderwerp op de agenda van vergaderingen?
Als de vragen leiden tot lange antwoorden is dit een serieuze indicatie dat rationaliseren van het applicatie landschap en processen zinvol is en geld kan opleveren. Deze vragen zijn minder interessant als het primaire productieproces per definitie ad hoc is of uit veel R&D bestaat.
De business case van applicatie rationalisatie
Volgens mij is het moeilijk om een directie te overtuigen rationalisatie prioriteit te geven. De business case is namelijk niet heel gemakkelijk te maken. Je moet immers geld uitgeven zonder dat je er iets voor koopt. Omdat ik eerder al schreef over verborgen kosten kun je dus ook niet snel een ROI berekenen. Daarnaast vereist rationalisatie denkwerk en inspanning van de organisatie. Het niet rationaliseren van het applicatie landschap en het bijkomende verzuim op applicatielandschap governance kan gezien worden als een technologie schuld (Technical debt, aardige blog op http://goo.gl/IKFpH ). Kosten van veranderingen, onderhoud en integratie worden steeds hoger door eerder gemaakte keuzes. Om dit tastbaar te maken heb ik hier een kleine anekdote die het principe duidelijk maakt. Op mijn afdeling staat een vaatwasser. Mensen worden geacht zelf hun vaat in de vaatwasser te doen. Een aantal keer heb ik expres mijn kopje niet in maar op de vaatwasser gezet. Zonder uitzondering zorgde dit ervoor dat voor het eind van de middag de vaatwasser vol stond met kopjes en borden. Hiermee bedoel ik dat als je uitzonderingen toelaat dit alleen maar meer uitzonderingen aantrekt. Bij de vaatwasser is dit nog wel te overzien, maar bij organisaties kunnen deze kosten enorm zijn. Beginnen met rationalisatie is in het begin dus vooral inlossen op een opgebouwde technologie schuld en dat maakt een business case minder aantrekkelijk om mee te beginnen. Vergelijk het met hoe overheid met de pensioenproblemen omgaat. Die worden steeds maar vooruit geschoven.
Conclusie
De kracht uit de cloud en daarmee de drastische kosten besparing, schaalbaarheid, elasticiteit en mogelijkheid van het nieuwe werken ontstaan dus als er goede aansluiting is op de mogelijkheden van cloud computing en die worden dus bereikt met rationaliseren van applicaties en processen.
De cloud lost niet de IT problemen en hoge kosten op. Pas als er een rationaliseringsgraad bereikt is ontstaat er aansluiting op drastische besparingen en andere voordelen van cloud computing. Voorbeelden hiervan beschrijf ik in een vervolg artikel.