IT SIMPLIFICATION

Knowledge engineer, Solution manager, Sevice manager, Lead architect, Documentalist, Controller, IT-manager, Strategie adviseur, Manager infrastructuur, ICT-directeur, Programma-manager, Netwerkbeheerder, Projectmanager, Innovatiespecialist, CIO, Servicedesk medewerker, Informatie analist, Smartphone beheerder, Programmeur, EDP-auditor, Systeembeheerder, Applicatie ontwerper, Embedded software engineer, Architect technische infrastructuur, Security specialist, Gegevensbeheerder, Storage manager, Multi media adviseur, Operator, iPad-specialist, Account manager, Incident manager, Configuration manager, CFO, Applicatiebeheerder, Web master, Autorisatie beheerder, Service manager, Hoofd systeemontwikkeling, QA manager, ICT coördinator, Gegevensbeheerder, Informatie manager, Tester, Team leider, Business process improvement manager, Data architect, Functioneel ontwerper, Netwerk architect, Problem manager, Change manager, pffff…..

Hebben jullie die ook in huis? Sta je er zelf bij?

Wie doet wat? en Wie beslist waar over? Zijn alle benodigde rollen ingevuld? Kan het eenvoudiger en effectiever? Zie het Whitepaper IT Governance voor Beslissers en doe de ICT-besturingsscan.

Bron o.m.: Taken, Functies, Rollen en Competenties in de Informatica – Johan C. Op de Coul

Governance voor Beslissers? Bestaan er dan ook papers, boeken en websites over Governance, die niet over besluitvorming gaan?

Ja, dat is nou precies het probleem. Het onderwerp IT Governance is verdwaald. Een prachtige illustratie is te vinden op LinkedIn.  Vorig jaar is door Mark Toomey binnen de LinkedIn group IT Governance de volgende uitdaging geplaatst: ‘Describe IT Governance in no more than 160 characters SMSmessage.’ Die oproep heeft inmiddels 201 reacties opgeleverd. De diversiteit is geweldig. Heel interessant!

Volgens mij gaat IT Governance primair over besluitvorming: Wie gaat er hier eigenlijk waar over, als we het over ICT hebben? Ik heb over dit onderwerp een whitepaper geschreven gebaseerd op een concrete praktijkcase. Kosteloos verkrijgbaar via de Aurelia! website. Ben benieuwd wat je ervan vindt.

Communicatie is moeilijk. Mensen hebben nou eenmaal last van slecht kunnen luisteren, vooringenomenheden, een matig geheugen, onhandig woordgebruik, wisselend humeur, etc. In de media-mix leiden e-mails vaak sneller tot irritatie dan verwacht. En het gaat dan van kwaad tot erger. E-mail-irritatie verdiept zich tot een serieus conflict. Hoe komt dat?

1. E-mails zijn soms laf. Het komt voor dat je iemand iets moet zeggen of wilt vragen of opdragen dat niet leuk, aardig of prettig is. In plaats van naar de persoon toe te gaan, kun je even opbellen. Maar telefoneren is nog steeds heel direct. Dan gaat die ander dingen terug zeggen. Als je een e-mail stuurt dan kan de persoon in kwestie niet direct antwoorden. Het is een adequate manier om de confrontatie te vermijden. Frustraties of boosheid uiten via de mail is een zwaktebod. Delegeren via de e-mail zit ook in deze categorie.

2. Te kort door de bocht schrijven. Een e-mail is geen formele brief. Tegelijk is een e-mail ook weer niet zo kort als een sms-je. E-mail leent zich er prima voor om in min of meer spreektaal iets klip en klaar op te schrijven. De risico’s zijn: te duidelijk of onzorgvuldige formuleringen.  Spreektaal zonder klank of gelaatsuitdrukking erbij is moeilijker te interpreteren. Het is ook logisch dat de emoticons uit de wereld van instant en short messaging  soms ook in e-mails gebruikt worden.

3. Slecht lezen. E-mails worden vaak snel en oppervlakkig gelezen. Tussen de bedrijven door gescand. Vaak multi-taskend, maar de eerste indruk is dan al gesettled. Zeker als er iets negatief geinterpreteerd kan worden. ‘Verkeerd begrepen’ ligt op de loer. Zorgvuldiger tweede lezing helpt niet meer echt. Dit risico is flink vergroot door het lezen van e-mails vanaf de kleine schermpjes van pda’s.

4. Te snel antwoorden. De verleiding is groot om op een e-mail direct te antwoorden met een e-mail. Veel mensen willen hun in-box leeg houden. De Send-knop is dichtbij. Er kan gemakkelijk een irritatie-versnelling ontstaan. Dit risico is kleiner geworden door het lezen van e-mails vanaf pda’s. De pda nodigt niet uit tot het schrijven van e-mails. Degenen die dat wel doen, antwoorden in sms-stijl en dat kan beide kanten op: variërend van ‘laten we het er snel even over hebben’ tot ‘ik begrijp niet hoe je hierbij komt’.

5. Te traag of niet antwoorden. E-mail verzenders verwachten eigenlijk dezelfde dag antwoord. De volgende dag kan nog net. Als dat uitblijft, en er is al enige irritatie, dan groeit die. Multi-mail-ontvangers en pda-e-mail-lezers antwoorden vaak helemaal niet. Dat is heel irritant en leidt niet tot een telefoontje, of even langs lopen, maar tot een nog iets geirriteerdere reminder-mail. Soms al na een dag.

6. Te uitgebreid antwoorden. E-mail communicatie is niet geschikt voor interactie met veel overwegingen en argumenten. Eenzijdig een wat uitgebreidere mail sturen om bijvoorbeeld een standpunt helder te maken kan nog. Maar er op reageren via de e-mail met een antwoord op al die punten , werkt niet.

7. Oneigenlijke kopie-ontvangers. Leidinggevenden ontvangen regelmatig cc’s van e-mail tussen, van of aan ondergeschikten, waarbij de cc eigenlijk bedoeld is om de baas te attenderen op een narigheid. Dat leidt gemakkelijk tot meer narigheid. Mails kunnen ook, zonder medeweten van de verzender, doorgestuurd worden naar onbedoelde ontvangers. Met onbedoelde effecten.

Als de e-mail irritatie eenmaal op gang is, dan valt het niet mee om weer on speaking terms te komen: elkaar vis-a-vis te spreken of te bellen. Er ontstaat een moeilijk te doorbreken wapenstilte. Het probleem in kwestie lost zich vaak (vanzelf) op, maar de irritatie blijft.

Dus, bij gevoelige en/of  negatieve berichten: gebruik e-mail niet om de directe confrontatie te vermijden en bij uitgebreide berichten: antwoord niet inhoudelijk per mail.  Hou het simpel en kies voor een medium met direct tweerichtingsverkeer: even bellen, zodat de ander je kan horen, of nog beter skypen, zodat je elkaar kunt zien, of nog, nog beter even langsgaan, kopje koffie, rustig uitleggen aan elkaar hoe en waarom je er in zit, zoals je er in zit. Ook ik zal mijn leven beteren.

Recent is een LinkedIn poll gehouden over de vraag: Wat is de belangrijkste reden voor het mislukken van projecten? 35% van de 250 respondenten kiest voor ‘Opdrachtgevers weten niet wat ze willen’ als belangrijkste oorzaak voor falende projecten. ‘Ineffectief gedrag hindert samenwerking’ krijgt 30% van de stemmen. Heel weinig respondenten kiezen voor ‘Projectmanagers missen certificeringen’ (2%) en ook ‘Slecht gebruik van methoden/technieken’ krijgt weinig stemmen (11%). Aan de project-methodologie ligt het dus gelukkig niet. In de commentaren op LinkedIn is terecht gewezen op het ontbreken van een aantal relevante faal-oorzaken in de antwoordcategorieën. Men miste o.m. als faal-factoren: ‘de omvang (te groot, te ambitieus) van projecten’, onvoldoende betrokkenheid gebruikers / voorbereiding’, ‘gebruik van vakjargon in documenten’ en ‘samenstelling projectteam’.

Terug naar de uitkomsten van de enquête. Die sluiten goed aan bij een Slideshare-presentatie over ICT-projecten die ik vorig jaar maakte samen met Arie Klootwijk (Buro Bloemers). Titel: KING2, SuperVisie over projecten.

In ons verhaal is KING1 de eindgebruiker. Uiteindelijk is de klant immers koning. PRINCE2 is een gecertificeerde project- manager, die minder belangrijk is dan het volk denkt. De sleutel voor het welslagen van projecten ligt bij KING2, de opdrachtgever. Duidelijk is dat de opdrachtgever afkomstig moet zijn uit het volk, uit de business dus, en niet uit het ICT-paleis. Potentieel probleem is dat deze KING2 teveel op afstand blijft en niet in actie komt als er signalen komen dat het project minder goed verloopt. Ook gebeurt het dat een stuurgroep wordt ingesteld met meerdere KING2′s: topfunctionarissen die vooral naar elkaar kijken als problemen opdagen. Nog risicovoller is een getrapt opdrachtgeverschap (koning, keizer, admiraal). Denk aan een gedelegeerd opdrachtgever, de opdrachtgever, een voorzitter stuurgroep en een voorzitter programma-stuurgroep ofwel escalatie-management. Het valt niet mee. Het is de kunst om het geheel overzichtelijk en eenvoudig te houden. Ook adequate management-informatie in de vorm van een project-rapportage is een randvoorwaarde voor goed functioneren van KING2. Kort en bondig is het devies.

Vroeger……. stonden veel fabrieken naast beken en rivieren. Een schoepenrad in het snelstromende water zorgde voor de aandrijving van machines. De stoommachine maakte het al rond 1800 mogelijk om fabrieken door te laten draaien, onafhankelijk van water-, wind- of paardenkracht. Business continuity. Maar nog steeds had iedere fabriek zijn eigen krachtcentrale. Pas aan het einde van de 19de eeuw kon men de energie van stoommachines of -turbines omzetten in elektriciteit en verspreiden via een wisselstroom-netwerk.  In gebieden met veel industrie werd het efficiënter en veiliger om gezamenlijk een stroomgenerator te bouwen en die te verbinden met de individuele fabrieken. De geboorte van de elektriciteitscentrale.

Zo zal het ook gaan met ICT. Veel bedrijven hebben nog een eigen computerruimte met een verzameling servers (file-, mail-, web-, database-, applicatie-, proxy-, etc.-servers), soms een oude telefooncentrale, veel bekabeling, een ingewikkeld koelsysteem en een blusinstallatie. Maar langzaam maar zeker snappen we wat dat mysterieuze ‘Cloud Computing’ betekent. Cloud = Internet. Dus als je cloud computing gebruikt dan gebruik je het internet voor rekencapaciteit en voor data opslag. Niet meer in-house, maar gewoon via internet ergens anders. Niet in de lucht. De afgelopen decennia gebruikten we deze servers op andere locaties vooral om data op te slaan. Zodoende noemen we die centrales met servers nog steeds Datacenters. Dat is een vergissing: het zijn ICT-centrales.

Het is altijd eng om eerste levensbehoeften aan anderen over te laten. Maar zoals de moestuin er alleen nog is voor de liefhebbers, zo zal ook de computer (met rekencapaciteit en gegevensopslag) het pand verlaten. Een diepvriesje met wat reservegroente is soms handig. En bedrijven en organisaties, zoals ziekenhuizen, die nu een noodaggregaat hebben voor het geval de electriciteit uitvalt, zullen ook noodcomputer-faciliteiten in huis houden, maar dit zijn de uitzonderingen.

Nicholas Carr, de man van ‘Does IT Matter?’ (blijft een briljante titel) schreef in 2008 ‘The Big Switch’ over deze parallel tussen ICT en elektriciteit. Op 2 maart 2011 spreekt hij in Amsterdam bij het John Adams Institute. Hij is verguisd en geprezen. Carr is een uitdager. Zijn lezing zal waarschijnlijk vooral gaan over zijn nieuwe boek ‘The Shallows’ over de toenemende oppervlakkigheid in de internet-maatschappij.

Is de ICT van de gemeente Amsterdam anders dan die van Rotterdam, Den Haag of Utrecht?

Gemeenten in Nederland voeren allemaal dezelfde taken uit. Een heel pakket: van paspoorten en rijbewijzen uitdelen, politie en  brandweer organiseren, via de uitvoering van bijstandsregelingen, GGD en  thuiszorg tot en met grondzaken en woningbouw regelen, inzameling huisvuil, de plantsoenendienst, sportfaciliteiten onderhouden en nog veel meer. Dat hebben ze niet zelf bedacht, maar is gewoon vastgelegd in de Grondwet en in de Gemeentewet.

De ICT-ondersteuning, die de 418 Nederlandse gemeenten nodig hebben bij de uitvoering van deze taken, kan niet erg verschillend zijn. De bedrijfsprocessen en werkprocessen moeten op elkaar lijken, zo niet identiek zijn, net als de management-informatiebehoefte ……. tenzij iedere gemeente en iedere ICT-afdeling zijn eigen ding mag doen.

Nu is het wel zo dat de kleinste gemeente, Schiermonnikoog, nog geen 1000 inwoners telt, en de grootste gemeente, Amsterdam, een stuk of 780.000. Dat zal leiden tot verschillen in de benodigde ICT-constellatie. Laten we de 418 gemeenten indelen in drie clusters:

- 25 grotere gemeenten met meer dan 100.000 inwoners

- 180 middelgrote gemeenten met tussen de 25.000 en 100.000 inwoners

- 215 kleinere gemeenten met minder dan 25.000 inwoners.

Die 180 middelgrote gemeenten vormen de harde kern, daar wonen de meeste burgers. Dat zullen er alleen maar meer worden als gevolg van lopende gemeentelijke herindelingen, waarbij met name kleine gemeenten samengevoegd worden. Voor die middelgrote gemeenten moet een standaard ICT-configuratie (hardware, software en architectuur) bedacht worden: de Gemeente Standaard ICT (GESI).

De 215 kleinere gemeenten kunnen volgens mij qua ICT het beste op regionale basis samenwerken in ca 20 Shared Service Centra.  Die SSC’s kunnen hun configuratie dan weer in grote lijnen baseren op de GESI. De 25 grotere gemeenten moeten ook GESI toepassen, tenzij er bijzondere redenen zijn om een andere oplossing te kiezen. Verder stel ik me voor alle gemeenten en SSC’s verplicht gebruik maken van een stuk of 4 landelijk verspreide gemeentelijke datacentra voor dataverwerking- en data-opslagcapaciteit. Met onderlinge uitwijk natuurlijk. Alle servers de deur uit!

Twee belangrijke voordelen: gemeentelijke kostenbesparing en landelijke kostenbeheersing. In 2010 zijn de softwarekosten van gemeenten met 25 procent toegenomen, blijkt uit de ICT Benchmark Gemeenten van adviesbureau M&I. Naar verwachting zullen de kosten ook de komende jaren zullen stijgen, omdat er bij veel gemeenten sprake is van een investeringsachterstand. Een tweede voordeel is dat de kosten en andere consequenties van beleidswijzigingen in de Haagse politiek ook voortaan beter in te schatten zijn en meegenomen kunnen worden in de besluitvorming.

KING, een adviesorgaan voor gemeenten, zit op eenzelfde lijn van standaardisatie en SSC’s. Er zijn al een Gemeentelijke Model Architectuur (GEMMA), Referentiemodellen voor Gemeentelijke Basisgegevens (RGBZ en RSGB) en een Standaard Uitwisselingsformaat (StUF). Veel denkwerk is al verricht blijkbaar. Nu doorpakken dus! Of redeneer ik te simpel?

Knopen doorhakken over ICT is lastig. Het gaat altijd over big money, er is veel vakjargon, innovatie jakkert voort, ongemak voor gebruikers dreigt, IT security, pfff…..

IT Governance is het thema. Marketing Governance? HR Governance? Financial Governance? Nooit van gehoord. Corporate Governance wel, maar dat klinkt ook als een relevant onderwerp. Hoezo eigenlijk IT Governance? We hebben hier een kernprobleem van ICT in organisaties te pakken. Er zijn veel boeken en artikelen over IT Governance geschreven. In de wetenschap zijn Peter Weill en Jeanne Ross de meest relevante auteurs. Er is ook een serieus IT Governance Institute. De neiging is groot om het ‘vakgebied’ te verbreden. IT management, security & risk management, beheer van hardware en software, compliancy, ICT-strategievorming, control. Wat valt er eigenlijk niet onder IT Governance?

Volgens mij is het simpel: IT Governance gaat over aansturing en besluitvorming: Wie gaat er hier eigenlijk waar over, als we het over ICT hebben? De relevante rollen moeten belegd zijn binnen de organisatie. De verdeling van taken en verantwoordelijkheden is inzichtelijk te maken door de ICT-onderwerpen in een RAPID- of RACI-matrix te verdelen over de functies en overlegorganen. Samen met een inventarisatie van het geldende ICT-beleid (principes, beleidskeuzes, recente notities) ontstaat een helder plaatje van de IT Governance. Vergeet niet de interne corporate governance toe te voegen. Zonder context geen ICT. Zo ontstaat helderheid en duidelijkheid.

Maar gaat het ook werken, zo’n notitie over IT Governance? Definitieve besluitvorming wordt vaak uitgesteld, terwijl de werkelijkheid door gaat, beslissingen zijn vaak onvoldoende scherp, het ligt altijd aan de communicatie. We zijn hier onhandig in. Vereist is een consequente managementstijl en al even stringente communicatie-afspraken om IT Governance daadwerkelijk effectief te laten zijn. Dat heeft dan te maken met vergadertechniek en -discipline, met het opstellen en verspreiden van agenda’s en besluitenlijstjes. Succes ermee! Bellen mag ook.

Outsourcing is an important road that may lead to IT Simplification. It is not a short and straight lane however. Organisational learning on IT outsourcing tends to be slow. There are outspoken opponents as well as enthousiastic supporters. Outsourcing of IT may be followed up by tough renegotiations or even by insourcing back again. From literature and practice 12 Golden Rules for IT Outsourcing are:

1. Outsource only stable and non-core activities; selective or incremental outsourcing is to be preferred above complete, package deal outsoucing

2. Built a business case with costs and benefits; watch the transaction costs and the in-house costs closely; include value creation in the business case and review periodically

3. Formalise the sourcing process with RFI and RFP

4. Ensure supplier capabilities; pay visits to references

5. Multi supplier outsourcing has a higher success rate than one single partner outsourcing

6. Detailled contracts, including mechanisms for changes and innovation, out-perform vague, open-ended contracts; still mutual trust is key

7. Create a triple-win contract for business, IT and suppliers with shared and transparant risks and rewards

8. Establish a IT demand-supply organization before outsourcing

9. Secure the in-house management of external suppliers before transition

10. Manage the transformation tight and keep the transition phase as short as possible

11. Make IT outsourcing a shared business-IT decision

12. Go for a  low risk approach as the risk of failure has proven to be serious

Sources:

Information Technology Sourcing: Reflections and Lessons 1991-2007 –  Willcocks, Leslie, Mary Lacity and Sara Cullen

5 Reasons why outsourcing must move up the CEO’s agenda – Willcocks, Leslie in Shared Services & Outsourcing Network September 2009

Outsourcing Performance 2010 Research Note – Giarte

Gridforum.nl organiseerde vandaag een jaarlijkse Business Day bij Sun Microsystems in Amersfoort met presentaties van o.m. Sun, IBM, NOS en CSC. De aanleiding voor grid computing is dat veel beschikbare computercapaciteit niet gebruikt wordt. Volgens IBM geldt dat voor 85% van infrastructuur hardware. Maar ook desktops staan bijvoorbeeld ‘s nachts en in het weekend urenlang te niksen. Aangezien de meeste computers en servers via netwerken met elkaar verbonden zijn kan deze onbenutte capaciteit ook door anderen gebruikt worden. De Hogeschool van Rotterdam heeft met het Erasmus Medisch Centrum een samenwerkingsverband waarbij computercapaciteit van de Hogeschool gebruikt wordt door het Erasmus MC. Het vergelijken bijvoorbeeld van de resultaten van periodieke MRI-scans van patienten om veranderingen te kunnen constateren kost erg veel rekencapaciteit. Het lijkt een beetje op serverconsolidatie, waarbij de restcapaciteit van een server wordt benut om meerdere besturingssystemen naast elkaar op diezelfde server te laten draaien. Ogenschijnlijk meerdere servers in 1 server ofwel virtualisatie. Een belangrijk verschil is wel dat consolidatie of virtualisatie in het algemeen binnen één organisatie plaatsvindt, terwijl kenmerkend voor grid computing juist de samenwerking tussen meerdere organisaties is. Betere benutting van bestaande capaciteit spreekt natuurlijk tot de verbeelding: hardware-kostenbesparing, energiebesparing en vereenvoudiging van beheer zijn concrete voordelen. Samenvoegingen binnen ICT-infrastructuur zorgen echter ook altijd voor een toename van  complexiteit door onderlinge afhankelijkheden. Wat weegt zwaarder?