Als je links en rechts eens met collega's praat, of de diverse artikelen op deze website leest, dan is één van de onderwerpen die regelmatig terugkomt snelheid en slagvaardigheid (en dan vooral het gebrek aan) van de it-afdeling. Maar zijn ze inderdaad zo traag of spelen er wellicht andere belangen een rol?
Voor velen vast een herkenbaar scenario: voor een bepaalde test of implementatie heb je even snel een systeem nodig. De standaard procedure schrijft voor dat je een it-aanvraag doet, deze moet weer door allerlei mensen getekend worden, et cetera, et cetera, et cetera. In het ergste geval moet je ook nog een hele onderbouwing aanleveren waarom jij een eigen systeem nodig hebt, in plaats van gebruik te maken van de standaardomgeving die it levert.
Kortom, het even regelen van een systeem eindigt al snel in een tijdrovend administratief klusje. De verleiding is dan ook groot om snel even bij de lokale pc-winkelketen een systeem te kopen en deze zelf in te richten.
Een vergelijkbaar scenario is te schetsen voor het aanschaffen van software. Zelf regelen is vaak sneller, met open source kom je vandaag de dag ook heel ver, en al die vervelende processen rondom het aanschaffen van software werken ook alleen maar vertragend.
Vanuit projectperspectief is er heel veel te zeggen voor deze benadering. Immers, als project wil je graag op tijd je spullen opleveren, en daarbij zo min mogelijk gehinderd worden. Of….misschien toch niet.
Het zou om te beginnen te denken moeten geven dat het project verrast wordt door de levertijden van de it-afdeling. Je mag mijns inziens verwachten dat deze bekend zijn binnen de organisatie, dus kun je er rekening mee houden in je projectplanning en de benodigde hard- en/of software tijdig aanvragen.
Verrassingen en valkuil
Maar de echte verrassingen komen pas na verloop van tijd. Het project heeft het gevraagde opgeleverd en wordt ontbonden. Na verloop van tijd blijkt er een probleem te zijn met het systeem waar de software draait, maar waar stond die pc ook al weer. Destijds stond hij bij de integrator onder het bureau. Zowel de integrator als zijn bureau zijn inmiddels weg, en de pc dus ook. Blijkbaar hangt hij nog ergens aan het netwerk, maar waar?
Een variant hierop is die pc in de hoek van de kantoortuin, waarvan niemand na verloop van tijd meer weet waarom die er eigenlijk staat. Bij de eerstvolgende verhuizing wordt het systeem maar uitgezet, met alle mogelijke gevolgen van dien.
Wat ook kan gebeuren, is een applicatie die na een aantal systeem-updates niet meer werkt, omdat bepaalde, van internet geplukte, libraries niet meer ondersteund worden? Waar hadden we die libraries ook al weer vandaan, worden ze eigenlijk nog wel bijgehouden, bestaat de leverancier nog wel?
Een andere valkuil kunnen de gebruiksvoorwaarden van open source software zijn. Negen van de tien gebruikers klikken klakkeloos op de OK, accept en next-knoppen als ze software downloaden en/of installeren zonder de voorwaarden goed te lezen. Afhankelijk van het licentiemodel kan het commercieel verhandelen van deze software onverwachte bij-effecten hebben. Een voorbeeld wat ik onlangs hierover tegenkwam betrof een gratis online Agile-scrumbord. Alles wat je daar op zet mag door de leverancier van deze website gebruikt worden voor demo-doeleinden. In veel gevallen zal dit geen probleem zijn, maar in het geval van concurrentiegevoelige informatie (bijvoorbeeld bij r&d-afdelingen) zal niet iedereen hier even blij mee zijn.
Rol van betekenis
Zo zijn er ongetwijfeld nog meer voorbeelden te bedenken. Maar willen we dit eigenlijk liever niet voorkomen? Een it-afdeling kan hierbij een grote rol van betekenis spelen. Let wel, kan! Door de jaren heen hebben zij veel van dit soort valkuilen voorbij zien komen en kunnen de projecten vanuit die positie adviseren.
De slagvaardigheid van de it-afdeling is daarmee echter nog niet opgelost. Het loont de moeite je eens te verdiepen in de budgetverdelingen binnen je organisatie. It wordt vaak gezien als een kostenpost en heeft vanuit die positie al direct een achterstand op een project. Alle investeringen moeten door talloze managementlagen geaccordeerd worden, voorraden geminimaliseerd en om kosten-efficiënt te werken kan er alleen standaard hardware aangeschaft worden.
Haastige spoed… vanuit het project geredeneerd misschien goed, maar vanuit langetermijnvisie lang niet altijd.
Zoals altijd weet je leuke artikelen te schrijven die ook nog erg herkenbaar en relevant zijn. Ieder in de IT kent bovenstaande voorbeelden. Het is vooral de realiteit die zo weerbarstig is dat er vijftig tinten grijs ontstaan. Om je artikel even uit elkaar te trekken:
Veel van de voorbeelden die je beschrijft leunen zwaar op governance of regie. Er wordt iets opgeleverd zonder hulp van IT en daarna wordt het niet nog alsnog ondergebracht bij IT en blijkbaar ook niet gedocumenteerd en vastgelegd op de door de organisatie besloten standaarden. Dat zijn wel een hele hoop fout op fout op fout. Dit is een rode vlag dat er behoorlijk wat mis is in je organisatie.
Een paar anekdotes. Bij de Rabobank was er een probleem in verband met planning en moest er performance van medewerkers gemeten worden. Al snel had ik een database server nodig omdat het toch wel om behoorlijk wat data ging. Andere consultants deden een weddenschap dat het me niet binnen vier maanden ging lukken… Zij kregen gelijk.
Het ging dus niet om “Even snel”, maar ook met een hoop geduld was het een heel zwaar proces om iets bij IT voor elkaar te krijgen.
In de echte wereld zijn het vaak klant vragen en kansen die er liggen en als IT roept “ho ho, over drie maanden ben je de eerste”, dan is het gewoon verleidelijk om een alternatief te zoeken.
Dan heb je het over open source en bijvoorbeeld de regeltjes en dat “gratis” diensten dus soms verstrekkende gevolgen hebben. Als er geen goede regels en werkwijzen zijn (vanuit de IT afdeling, of het bedrijfsbeleid) dan ontstaan dit soort dingen, maar ook een projectmanager moet ook de bril op zetten van beveiliger of een jurist erbij betrekken als er iets nieuws gerealiseerd wordt. Want nu heb je het echt over uitersten en cowboy praktijken.
Dan vind ik je oplossing voor je geschetste schaduw IT “Een it-afdeling kan hierbij een grote rol van betekenis spelen.” wel heel erg kort door de bocht.
Een pragmatische benadering van het probleem moet dus komen vanuit de praktijk.
De IT afdeling / Beleid afdeling moet
– Erkennen dat projecten in relatief korte tijd gestart worden
– Wendbare processen worden ingezet voor het realiseren van budgetten
– Helder communicatie medewerker kaders voor een project kunnen inzien en zien welke checks zij moeten uitvoeren.
Ik ben het overigens volledig met je eens dat er vaak gedacht wordt aan de voorkant en het realiseren van iets, en dat de prijs achteraf enorm hoog blijkt omdat men aan de voorkant van het project zo lekker hard gegaan is. Volgens mij is dit namelijk hoe ieder IT project gerealiseerd word.
Vaak krijg ik de vraag “wat kost dat om te maken?” en zelden de vraag “wat kost het om te onderhouden?” terwijl er het meeste geld gemoeid is met die 2e vraag….
De oorzaak is vaak:
– Onnodige procedures (een manager die goedkeuring moet geven, maar er eigenlijk niets mee te maken heeft)
– Controledrang van managers hoger in de hiërarchie (laatst hoorde ik dat een directeur van een internationaal IT-bedrijf goedkeuring moet geven voor het in bruikleen nemen van een laptop van één van de medewerkers)
– Inefficiënte processen (b.v. taken die wachten op de afronding van andere taken, terwijl dat niet hoeft)
En last but not least. Te krappe projectplanning en dus te hoge verwachtingsmanagement. Als ik een project start, kijk ik eerst rond in de organisatie. Als ik enigszins weet hoe dik de stroop om vervolgens te kiezen tussen een tijdsmarge van 50% (inefficiënte organisatie) of 10% voor een efficiënte organisatie.
Het is namelijk zo dat als je je project goed plant (lees rekening houdt met de stroperigheid van de organisatie), je altijd op tijd bent. Hoe inefficiënt de organisatie ook mag zijn.
Efficiënt (niet veel, maar goed) management van je projecten en infrastructuur is essentieel.
“Negen van de tien gebruikers klikken klakkeloos op de OK, accept en next-knoppen als ze software downloaden en/of installeren zonder de voorwaarden goed te lezen.”
Dit heeft toch niets met de licentie-vorm te maken? Opensource of closed source, men klikt nog steeds op Ok en je krijgt vroeg of laat altijd ellende. Dit zegt iets over het licentie-management in het algemeen, niets over open of closed.
Je moest eens weten hoe druk Oracle en Microsoft zijn met het uitknijpen van klanten die hun licentie management niet op orde hebben en meer doen met de aangeschafte software dan waar voor is betaald….
@Frank … ja en nee. Als je een pakket aanschaft via de IT-afdeling, wordt het licentie- en juridisch gedeelte daar vaak al afgedekt, en hoef je je als eindgebruiker daar niet meer om te bekommeren.
Wanneer je iets download van internet en zelf installeert wordt het een ander verhaal
@Mark … de eerste drie punten die je noemt heb ik vaker gezien/gehoord. De vraag die ik dan meestal terug stel is: waarom pas je dan de processen etc. niet aan in plaats van telkens weer een eigen IT omgeving te creëeren?
@Henri: ik leg daarom ook bewust de nadruk op het woordje “KAN”. Als je de IT afdeling niet van budget en/of middelen voorziet zullen ze niet veel kunnen helpen.
… en laten we het maar niet hebben over security in al dat gehaast …
“even bij de lokale pc-winkelketen een systeem te kopen en deze zelf in te richten” en “met open source kom je vandaag de dag ook heel ver” zijn voor veel gebruikers al een gepasseerd station. In plaats daarvan betalen ze voor een SAAS applicatie waar een aantal vd bedrijfsinterne problemen die je schetst, zoals wie installeert en beheert, niet meer aanwezig zijn. Uiteraard blijven er ook dan zaken die je goed moet regelen. Iets waarbij de IT-afdeling ook zijn meerwaarde kan hebben. Maar het begint hem daarbij steeds meer te zitten in andere zaken dan installeren en beheren van servers en software.
De grootste kostenpost is niet de ICT, maar de kennelijke veronderstelling van de gebruikersorganisatie dat spullenboel en toepassingen het altijd, overal en vanzelf doen en dat IT derhalve niks hoeft te kosten.
Wie voor “mooi” zijn geen pijn wil lijden en gaat voor dat goedkope wonderpilletje, moet achteraf niet piepen over bijwerkingen.
Ik ben erg verbaasd te lezen dat een aanvraag voor een PC 3 maanden duurt. De prijzen zijn toch zo gedaald dat het niet meer om de kosten van de aanschaf gaat. Misschien nog het onderhoud.
Met een raamwerk van regels en een zekere mate van speelruimte moet het vandaag de dag toch mogelijk zijn de mensen te motiveren tot samenwerken met een IT-afdeling.
Ik zie echter ook het omgekeerde, een nieuwe “manager” komt en gaat fijn op eigen houtje IT-projektjes starten omdat hij denkt dat hij daarvan ook verstand heeft. Dat brengt de IT-afdeling aan de rand van de waanzin.
De kunst is mijns inziens tijd in samenwerking te investeren, wie doet wat en waarom en hoe houden we het voor elkaar werkbaar.
Heel simpel. Een projectmanager krijgt een bepaalde opdracht en die moet hij binnen een bepaalde tijd met een bepaald budget uitvoeren. Dagelijks kom ik processen tegen, welke véél efficiënter ingericht kunnen worden. Als ik deze zou willen aanpakken, had ik wel procesmanager geworden.
Wat je hooguit als projectmanager zou kunnen doen om inefficiënte processen onder de aandacht brengen is ze opnemen als risico in je projectplan of als advies in je eindrapport meegeven.
@Rob: valide opmerking, maar dit ligt iets te ver buiten mijn expertisegebied om daar stelling over in te nemen
@Ad: maar los je daarmee het probleem op? Als je de SAAS aanvraag via een centrale afdeling met vergelijkbare regeltjes moet aanvragen duurt ook dat lang. Regel je het zelf bij “een” provider, dan weet de financiële afdeling op een gegeven moment ook niet welke rekening waarvoor is. Als niemand ze dat kan vertellen, stoppen ze wellicht de betalingen met alle gevolgen van dien. Of, als iets niet weet, en er draait “iets” bij “een” provider, wat is dan nog het verschil met die PC die “ergens” op kantoor staat?
@hk: klopt, Gas, water en electriciteit is toch ook altijd beschikbaar, dus waarom ICT niet? Wat men vergeet is dat de 3 nutsvoorzieningen al een wat langer bestaansrecht hebben (en daarmee een stuk uitgekristalliseerd zijn) en veel minder aan verandering onderhevig zijn.
@Mark: als opdracht, budget en tijd al vast staan, accepteer ik de opdracht niet. Simpelweg omdat je dan geen knoppen meer hebt om aan te draaien (tenzij je de kwaliteit ter discussie wil gaan stellen). De uitdaging is het probleem terug te leggen daar waar het hoort. Als de organisatie waarbinnen jij het project uitvoert levertijden heeft van 3 maanden, en daardoor kun jij niet leveren, moet je dat niet jou probleem maken, maar dat van de organisatie.
@Jan: sommige organisaties zijn héél bureaucratisch 🙂 Zeker wanneer het gaat om niet-standaard spullen.
Ach, en die nieuwe manager… ik vergelijk het wel eens met voetbal; daar meent ook iedereen verstand van te hebben, vooral rond het EK/WK. “Schoenmaker blijf bij je leest” is een spreekwoord wat veel managers niet willen kennen, zo lijkt het