Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Haastige spoed...

 

Computable Expert

Pa Va Ke
Configuration Management / Product Lifecycle Management, -. Expert van Computable voor de topics Development, Beheer en Zorg.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5229686). © Jaarbeurs IT Media.

6,9


Lees meer over


 

Reacties

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.

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.

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.

@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

Dan heb je zeker weinig opdrachten? Als ik een opdracht niet kan uitvoeren binnen de gestelde voorwaarden, rapporteer ik dat en laat ik de opdrachtgever de keuze: voorwaarden wijzigen of iemand anders zoeken.

Scope is ook een knop waar je aan kunt draaien. Kwaliteit lever ik altijd. De opdrachtgever mag zelf bepalen welke scope met welke productrisico's.

Het ondankbare voor de echte ICT-ers zit hem in het feit dat een degelijke ICT oplossing veel voor de leek verborgen concepten nodig heeft voor het solide beheer van de toepassing. De meeste gebruikers focussen zich op de sympthonen en niet op de diepere business en ICT processen. Sympthonen organiseren is chaos creëren.
Breng 50 gebruiker- professionals bijeen voor eenzelfde probleem en je zal mogelijk 50 ideale oplossingen vinden,maar weinig overeenkomst. Er is meer nodig dan gelijke buz-words .

Het is het beroemde "test systeem in productie" verhaal. Nou zal het mij een biet zijn dat iemand wat in de marge zit te knutselen. Overigens kan je binnen 2 minuten een server op het internet ter beschikking krijgen. Daar kan je lekker op pielen en rommelen tot je een ons weegt. Ik zou zeggen wanneer echt "spannend gaat worden", zou ik de papieren molen door. Het is namelijk wel belangrijk dat de uiteindelijke "productie server" volgens gangbare middelen wordt verkregen en kan worden beheerd. Overigens vind ik het de verantwoordelijkheid van de "aanvrager" wel enige realiteit in ogenschouw te hebben hoe een eventueel succes kan landen in de organisatie. Het is wat triest als je je omgeving compleet in .Net ontwikkeld en weet dat de organisatie een Java bolwerk is. Of dat je een redundant FireWall oplossing in elkaar knutselt van fabrikant A en de organisatie gebruikt B.
Op een gegeven moment is je gezonde verstand gebruiken wellicht een idee.

@Atilla: alhoewel ik geen harde cijfers heb om het volgende te onderbouwen, denk ik dat er ook nog een verschil kan zitten in wie de opdracht uitvoert.

Wanneer het een IT-team is van het bedrijf zelf, zullen ze ook met het eventuele onderhoud en andere problemen opgezadeld worden. Hierdoor zullen ze meer oog hebben voor de genoemde problematiek dan een team dat alleen voor de opdracht wordt ingehuurd. De laatste wordt afgerekend op resultaat, en na hun de zondvloed.

"Ik ben erg verbaasd te lezen dat een aanvraag voor een PC 3 maanden duurt."
Ach... Da's nog snel. Als er hier bij de jaarlijkse begroting niet vooraf al rekening was gehouden met een verandering (iets kapot, uitbreiding, wat dan ook) in het jaar die op die begroting volgt, is er vaak al gezeur.
Probeer als onderknuppel dan maar te zeggen dat de begroting dan niet deugt (houdt gewoon standaard rekening met 5% onbekende kosten? Klaar!).

"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"

't Gaat in dezen toch niet om de software zelf maar om wat men met (bedrijfs/klant)gegevens doet? Al dan niet vertrouwelijke gegevens invoeren/lekken kan via software die via de IT-afdeling is aangeschaft, via zelf gedownloade Open Source, via online formulieren / online software, via cookies (middels een cookie beleid waarbij je op 'ja' geklikt hebt), via niet-versnipperd oud papier...

Het gaat toch om de kern. Haastige spoed....
Als iets snel moet is het een pleister op een wond, een lapmiddel een tijdelijke oplossing dus.
Dat kan heel nuttig en goed zijn. Ook als het om een gedefinieerde pilot of proefopstelling gaat. Dan zijn wellicht allerlei non-functional requirements niet relevant. We willen immers juist snel inzage in de bruikbaarheid van het systeem of inderdaad gewoon snel even het bloeden stelpen.
Voor gebruikers en management is het probleem dan ogenschijnlijk opgelost. Geen ruimte meer voor budget en volgende agendapunt.
De IT adviseur/manager speelt hier dan een belangrijke rol; die moet nu gaan steigeren. Al op het moment van insteken van de oplossing moet al helder zijn dat het een tijdelijke oplossing is. Het gesprek over budget en definitieve oplossing moet dus eigenlijk tegelijkertijd al worden opgestart. Gewoon om het momentum vast te houden en later niet in de problemen te komen.
Gewoon ook hier.. Het ijzer smeden als het heet is.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×