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.
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 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.
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 .
@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.