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

Heilige graal van Business IT-alignment

 

Expert

E D
Iets met ICT, nvt. Expert van voor het topic .

Een jaar of zes geleden schreef ik een artikel voor een computermagazine over de al jaren gaande strijd tussen de business en it, zeg maar het business it-alignment probleem. De reden voor dat artikel was de toenmalige hype rond virtualisatie, omdat de business toch altijd weer als het kind op Sinterklaasavond is: vol verwachting klopt hun hart, wie de koek krijgt en wie de gard.

'De vele technologische ontwikkelingen en snel veranderende manier van werken voeden de verwachting dat it snel, kosteneffectief en flexibel mee kan gaan in de nieuwe trends.'

Achter welk trends business aanloopt blijft voor de it altijd onduidelijk maar één trend die al een tijdje gaande is gaat om de wet van Moore. De technologische ontwikkelingen laten namelijk een trendbreuk zien. Zo schuurt die wet al een tijdje met de boekhouding omdat de technische erosie sneller gaat dan economische afschrijving, technologie die vandaag duur is kost morgen (bijna) niets meer. Dat zorgt dus voor een spanningsveld omdat de bedrijfseconomische benaderingen in de aansturing van de it  hierdoor uiteindelijk altijd mank gaan. Een ander probleem is dat de meeste software architecturen geen gelijke tred houden met de techniek en veel applicaties hebben dan ook nog geen voordeel van de parallellisatie met multi-cores of uitschaling via virtualisatie. Batch georiënteerde architecturen bewegen wel richting transactie- en interactieve oplossingen maar die transities kosten tijd. Veel bedrijfskritische services zijn dan ook minder flexibel dan business denkt.  

'A majority of IT departments are deploying virtualization, but still most don’t feel comfortable with tools and technology they have in place to manage application performance or troubleshoot the virtual environment...when asked what the primary troubleshooting problem was, 78 percent said identifying the problem source.' - Survey conducted by Network World  

Luchtkastelen
Ik loop dus regelmatig tegen de perceptieverschillen aan omdat uitgangspunten bij projecten niet kloppen. Vertaling van sla’s naar de techniek gebeurt dan vaak ook nog op wonderbaarlijke wijze omdat virtualisatie ook nog weleens als een placebo gebruikt wordt tegen een chronisch tekort aan kennis. Dit niet alleen door de ‘technology debt’ die er in menige infrastructuur zit in de vorm van oude code, maar ook door het stelselmatig nalaten van capaciteitstesten. It lijkt aangestuurd te worden als oude de kinderserie Tita Tovenaar waar de tovenaarsleerling in haar handen klapte als de dingen niet gingen zoals ze wilde en alles stil stond.

Toen ik zes jaar geleden over het business-IT alignment probleem schreef voorzag ik dan ook al problemen met de hype van vitualisatie omdat deze vooral ging om service delivery en geen focus legde op service support, het stukje beheer dat vaak als personeelskosten in de boekhouding staat. Dit mede doordat de aansturing van de it steeds vaker gedaan wordt via asset management waar de relaties tussen de geregistreerde componenten ontbreekt. Hierdoor is het moeilijk om de waardeketens in de it te kunnen bepalen en hoewel enterprise architectuur (EA) dit probleem probeert op te lossen staat deze discipline echter op achterstand zoals Gartner ook stelt:

'By 2016, 15 percent of organizations will integrate IT Service View with EA tools, up from a modest 1percent today.'     

TCO of ToC
Nu gaat het naar mijn opinie hier dus niet om een asset management systeem waarmee vooral gestuurd wordt op de Capital Expenditures (Capex), de bedrijfseconomische aansturing van de it, die, zoals ik al stelde, mank gaat door een trendbreuk in de wet van Moore. Zo werkte het idee van een CMDB nog goed in batch georiënteerde architecturen, maar schiet het te kort in alle transactie gerichte oplossingen. Kosten voor het netwerk worden vaak niet eens doorbelast terwijl die belasting steeds meer toeneemt. Nu komt wijsheid pas met de jaren, zoals we ook tot ontdekking komen dat internet goedkoop is maar niet veilig. Kijkend naar de trend in de it lijkt het er dus op dat business zich zelf telkens opnieuw in de nesten werkt, omdat er niet verder gekeken wordt dan functionaliteit en kosten.

Mogelijk ten overvloede, maar de doorbelasting van resources zegt niets over de totale kosten van een services en al helemaal niets over de toegevoegde waarde. Een doelmatige (efficiënte) inzet van middelen is hierdoor dan ook lastig te beoordelen. Opmerkelijk vaak blijkt het reclaimen van resources achterwege te blijven waardoor virtuele omgevingen dus even statisch zijn als weleer, een lagere fysieke server footprint zorgt dan ook lang niet altijd voor lagere kosten.  

'In IT operations, all the hype is around configuration management databases as the means to solve all problems. Eventually, another management database related to performance and capacity will emerge.'  - Gartner.

Hypocris(i)e
Business it-alignment is vaak een zwarte pieten discussie door tradities in de boekhouding of organisatorische aansturing. De klaaglijn vanuit incident management helpt ook niet echt om dit probleem op te lossen, zeker niet als er geen aansluiting op de events vanuit de technologie is. De trend van oplopende resource belasting geeft een indicatie van een activiteit maar dat kan dus zowel een nieuw business initiatief als een aanval zijn. Beveiliging zorgt dan ook voor de nodige spanningen tussen business en it terwijl de kosten daarvan vaak onduidelijk zijn. De business kijkt ondertussen verlekkerd naar de speelgoedcatalogus van de cloud, maar zoals ik al aangaf zijn er nog wel enige perceptie verschillen. Afgelopen zes jaar bleken deze grotendeels voort te komen uit de processen die geen gelijke tred houden met de technologische ontwikkelingen. Dit betrof zowel business als beheer processen. Opmerkelijk vaak zijn de verschillen tussen perceptie en realiteit het grootst bij organisaties die hun it uitbesteed hebben. Uit het oog, uit het hart zorgt dan ook niet echt voor een betere relatie tussen de business en it.  

'In the end, all business operations can be reduced to three words: people, product and profits. Unless you've got a good team, you can't do much with the other two.' - Lee Iacocca


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

?


Lees meer over


 

Reacties

@Ewout
Goed artikel. Wat betreft de CMDB, laten we die maar eens dood verklaren : http://www.itskeptic.org/itil-cmdb-skeptic

Over het "pay for what you use" model: de-allocatie en re-claiming van resources vind meestal niet automatisch plaats in clouds omdat die bedrijven meestal geen extra moeite en kosten aangaan om hun klanten een lagere rekening te bezorgen. In de praktijk zal de klant zulke zaken toch echt zelf in de gaten moeten houden en aanvragen.

Wat betreft de zwarte pieten discussie (tech vs. business): technologie heeft zich, mede door outsourcing/cloud, meer en meer losgemaakt van de business, en is nu ipv een afdeling binnen een bedrijf vaak een zelfstandige businesspartner.
De toon van de business zal zich dan ook gevoeglijk wat moeten gaan aanpassen. De vroegere ICT afdeling die de "orders" moest opvolgen van de business en meehielp de bedrijfsdoelen te bewerkstelligen is aan het verdwijnen. Ervoor in de plaats is een zelfstandig bedrijf gekomen dat meerdere klanten heeft en zich nu vervolgens kan concentreren op hun kerntaak: het leveren van technologische oplossingen voor al hun klanten.

he Ewout, hoe zou je dat allemaal oplossen ?
(wel mooi opinie artikel)

nog eens gelezen ..
in the end : how do you gather a good team ?

@felix
Misschien had ik er onder moeten zetten: Wordt vervolgd....

Business-IT alignment gaat (naar mijn opinie) vooral om optimaliseren van de communicatie tussen business managers die de zakelijke beslissingen nemen en IT-managers die toezicht houden op technische kant van de IT. In die communicatie gaat nog veel mis omdat de realtime status vaak ontbreekt en er geen sprake is van een team, tenminste niet één die hetzelfde doel nastreeft.

Kan op basis van 6 jaar ervaring met health checks op IT(SM) een bloemlezing geven, hoewel het soms meer weg heeft van comedy. Let ook even op het verschil in de quote van Iacocca waar het om producten in plaats van processen gaat. Het productgericht denken is ook tekend voor de wijze waarop de IT governance ingericht wordt, niemand geloofd hierdoor dat een organisatie met ISO27001 certificaat de informatiebeveiliging werkelijk goed geregeld heeft.

"De trend van oplopende resource belasting geeft een indicatie van een activiteit maar dat kan dus zowel een nieuw business initiatief als een aanval zijn."

Afgelopen jaren zijn diagnose mogelijkheden beter geworden, niet alleen in Windows met uitbreiding van WMI maar in allerlei componenten die zich geheel of gedeeltelijk conformeren aan de vele management standaards die er gedefinieerd zijn. Nu is die wildgroei aan management protocollen wel suboptimaal omdat hierdoor informatie vaak opgesloten blijft in de tools en elke groep in het beheer heeft dan ook zijn eigen favorieten, wederom door het productgericht denken.

P.S
Ik heb trouwens ook plaatjes bij het verhaaltje:
http://www.slideshare.net/edekkinga/building-a-service-knowledge-dashboard

@KJ
Of we CMDB dood moeten verklaren of aan moeten passen is een visie verschil, denk persoonlijk dat C erin meer moet staan voor connectie en compliance dan configuratie. Een probleem dat ik namelijk vaak zie zijn 'disconnected processen' en gemiddeld genomen zijn afwijkingen op wat is vastgelegd en hoe het daadwerkelijk is ingericht 40%. De complaints (slide 2) vanuit de business zijn terecht hoewel de oorzaken hiervan meer organisatorisch dan technisch van aard zijn. Een CMDB inrichten met de C van contracten blijkt namelijk vaak voor verstoringen in de supply chain te zorgen zoals ook uit het interconnected risk rapport blijkt.

Ewout, ijzeren artikel. Volledig eens met Iacocca die volgens mij hardstikke NL had kunnen zijn met zijn nuchtere boerenwijsheid.

@Ewout,
dat de Skeptic tegen alles aan trapt zegt nog niet dat hij gelijk heeft, zeker niet waar het z'n stelling over CMDB's betreft. Hij illustreert hooguit dat organisaties dit vaak verkeerd aanpakken. Daarmee is echter nog niets gezegd over het concept. Niks mis mee. Ik zou zelfs zeggen: cruciaal voor een efficiënte organisatie. En waarom zou dat tekort schieten in 'transactiegerichte oplossingen'?

Je titel intrigeerde me, het gaat uiteindelijk in "de IT" uitsluitend om de toegevoegde waarde voor die business. Maar je verhaal gaat daar toch helemaal niet over? Je schopt - in navolging van de Skeptic - tegen een aantal trends en misstanden aan, maar ik lees niet een opinie over hoe de business en "de IT" dan wel aligned zouden moeten worden. Misschien kun je dat nog eens proberen duidelijk te maken?

@Jan van Bon
Het was ik die het artikel van de Skeptic introduceerde, niet Ewout.
Wat mij betreft is die CMDB niet te realiseren. De Skeptic geeft ook duidelijk aan waarom: het modelleren van de CI's, het bijhouden van de CMDB, de kosten etc. etc. Ik heb het nog nooit ergens zien werken, elke CMDB die ik heb gezien, was inconsistent en/of werdt niet gebruikt (en ik loop al een aantal jaren mee als freelancer).



@Jan
Business-IT alignment is inderdaad een discussie die al meer dan 10 jaar (nog uit de tijd van de gulden) loopt maar gaat uiteindelijk om communicatie tussen de business (unit) managers die de zakelijke beslissingen nemen en IT managers die voor de invulling ervan in de vorm van ICT zorgen. Tenminste vroeger want het gaat steeds meer richting BYO door de IT industrialisatie waardoor business niet alleen de eigen applicaties kiest maar ook de apparaten koopt. De configuratie vrijheid ligt daardoor steeds meer bij de gebuikers terwijl er nog vastgehouden wordt aan een proces uit het stoomtijdperk, architecturen van het eerste uur met niet alleen voorspelbare afschrijvingstermijnen maar waar de IT nog geraadpleegd werd bij keuzen.

Kortom: het gaat steeds meer om landen, tanken en vliegen;-)

Laatste is trouwens vaak een probleem zoals ik al stelde met uitdagingen in Enterprise Architectuur, rationalisatie in applicaties is meestal een loopgravenstrijd. Grappige is dat business zich pas weer bewust wordt van de waarde die beheer heeft als ze door uitwijk of beveiligingsincidenten met de neus op de feiten gedrukt worden.

@KJ
Je constatering dat CMDB inconsistent is zie ik ook vaak maar hier liggen volgens mij een paar oorzaken aan ten gronde. Zoals je zelf al kon lezen in de reacties bij je link zie je dat er vaak niet gemodelleerd wordt naar de informatiebehoefte maar gewoon een product gekozen. In de praktijk kom je mede door de opdeling in het beheer - Looijens model - veel verschillende repositories tegen die allemaal een stukje van de puzzel bevatten, zie ook de discussie over federated CMDB.

Maar hoe je het ook wendt of keert uiteindelijk zul je toch een soort van administratie moeten hebben, onwetenheid wordt vaak verwart met complexiteit.

@Ewout
Klopt en mee eens. In de meeste produkten kan de klant kiezen wat er geadministreerd wordt. Wat wordt als een CI beschouwd is de vraag. Een compleet SAP systeem of ook de fysieke en virtuele servers waar het systeem op draait (die kunnen nogal eens wisselen), licenties, software stacks, routers, firewalls etc ? Zowiezo is het schier onmogelijk om de relaties tussen de CI's bij te houden, dus het herleiden van een probleem naar diverse CI's via de relaties ertussen, zit er niet in.

Wat er geadministreerd moet worden zijn de gegevens die worden gebruikt voor het opstellen van de factuur naar de klant.
- Welke services heeft de klant in gebruik
- Hoeveel : CPU, Memory en Disk is er gealloceerd per service
- Voor pay per use bijvoorbeeld : wat is het gemiddelde van de 3 hoogste CPU pieken. Maar uiteraard zijn ook de gealloceerde resources verdisconteerd in dat bedrag.

Wat betreft hardware afschrijvingen heb ik de indruk dat er, zolang er geen service degradatie plaatsvindt binnen de cloud een stuk langer gedraaid wordt op oudere hardware, omdat dat nu eenmaal meer oplevert.
De klant ziet vaak alleen het viruele OS en is zich niet bewust van de onderliggende hardware. Zolang een klant geen expliciete klachten heeft en de SLA niet wordt overschreden (hoewel daar vaak niet eens op wordt gemonitord door die klant) niets vervangen wordt.

@KJ
Een CMDB zou meer een template dan een product moeten zijn, de vraag wat je vastlegt is namelijk uiteindelijk weer afhankelijk van de best practice die je volgt.

Ik zal niet zeggen dat elk probleem is op te lossen als je de relaties weet maar wat meer inzichtelijkheid dan nu gebruikelijk zorgt wel voor meer inzicht. Of je dat aggregeerd van business naar service, van service naar applicatie, van applicatie naar platform en van platform naar configuratie of op een andere manier is niet zo belangrijk maar nu ontbreken deze koppelvlakken nog vaak.

Ook wel handig als je van de koppelvlakken weet wat ze kunnen, niet alleen in capaciteit en beschikbaarheid maar ook ondersteuning want aan de achterkant zijn er nog weleens SLA's die niet kloppen met de verwachting.

@Ewout
Wat ik zie in onze cloud is dat voor ieder systeem wordt bijgehouden waar (op welke virtuele server) de bijbehorende services (applications en database) draaien op elk moment. Elke wijziging in de toestand die services (up/down verplaatsing naar andere virtuele server etc.) wordt automatisch bijgehouden zodat er een real-time image bestaat van de toestand van alle services. Vanuit de monitoring wordt voor iedere virtuele server de load uitgedrukt in CPU geaggregeerd per uur en per dag.

Billing geschiedt op basis van de 3 hoogste dagelijkse CPU percentages per maand. Hierin zit ook de aangeboden capaciteit als totaal verdisconteerd. Immers als klanten niets zouden gebruiken zouden ze in theorie niets hoeven te betalen, hetgeen uiteraard niet het geval is.

Aangezien de hardware onafhankelijk is van de gevirtualiseerde services, kan daarvoor een aparte administratie worden gevoerd tav. de afschrijvingen. Zoals gezegd heeft de klant hier geen zicht op en wordt oudere hardware langer gebruikt dan dat in conventionele omgevingen gebruikelijk was.

In het algemeen geldt dat een cloud bedrijf geen extra inspanningen doet boven op de SLA om de klant een financieel voordeel te bezorgen. De verhouding is zakelijk en de klant dient zelf in de gaten te houden of de kengetallen genoemd in de SLA niet overschreden worden.

Pro-activiteit is nul en bestaat niet meer. Iedere klacht wordt als een nieuw incident behandeld en opgepikt door iemand in het verre oosten. Slechts als je erg veel geluk hebt weet er iemand in de cloud een incident naar probleem te herleiden en er een oorzaak voor te vinden en die vervolgens te verhelpen. Meestal blijft het bij incidentbestrijding en wordt er gegrepen naar het verhogen van capaciteit, want dat is makkelijk en levert ook meer op.

Waar een conventionele ICT afdeling nog wel eens aandrong op applicatie en systeemonderhoud (patches/upgrades), blijft dit in een cloud meestal achterwege, vooral als de klant aangeeft daar geen trek in te hebben. Dit resulteert in een toename van IT-debt (http://www.gartner.com/newsroom/id/1439513).

Ondanks de virtualisatie blijkt het verhuizen naar een andere cloud toch vaak niet zo simpel en goedkoop te zijn als vaak wordt gesuggereerd. Het gevolg is dat een cloudbedrijf in staat is om zijn (kleinere) klanten behoorlijk onder druk te zetten.

Wellicht een wat somber verhaal, maar het is wat ik waarneem in de praktijk.

@KJ
Een cloud provider zit in de business van resources verkopen, liefst overgecommiteerd om marge per vloertegel te verhogen. Dat ze geen enkel belang hebben om het verbruik te verlagen is dus logisch want dat hoort bij het business model. Net als dat ze zich niet druk maken om de code die er op draait, zolang de rekening betaald wordt mogen het ook allemaal bogomips zijn want de chargeback is geaggreerd naar de service die ze leveren, niet naar de business service die de klant afneemt. Hetzelfde zie je met incidenten, de servicedesk wordt afgerekend op de tijd die besteed wordt en niet of de oplossing goed is maar ik had al wat over KPI's gezegd.

Ik lees in veel van de reacties hierboven juist dé reden waarom business en IT vaak onvoldoende aligned zijn: we hebben het als IT nog altijd teveel over de techniek i.p.v. dat we op een afdoende manier de vertaalslag kunnen maken naar begrijpelijke concepten voor de business! Zoveel mogelijk in Jip-en-Janneketaal. We vliegen nog altijd teveel projecten vanuit een IT perspectief aan en we zijn nog altijd onvoldoende in staat om de juiste vragen te stellen aan de business en goed te luisteren naar de antwoorden. IT is immers geen doel op zich, maar een essentiële steunpilaar die organisaties zou moeten helpen hun bedrijfsdoelstellingen te verwezenlijken.

@Ralf
Als we het tegenwoordig over IT hebben zullen we onderscheid moeten maken tussen de business IT, welke om de overdracht van informatie gaat en de technische IT die zich meer richt op de infrastructuur om overdracht te faciliteren en in de breedste zin van het woord informatie te beveiligen. Je kunt niet stellen dat die overdacht van informatie zonder techniek kan, van grottekening tot infographic is het gevolg van de technologische ontwikkelingen.

@Ewout
Helemaal eens, maar ik zie gewoon dat die belangrijke brugfunctie tussen demand (business IT) en supply (technische IT) nog altijd onvoldoende ingevuld wordt bij veel organisaties.

@Ralf
Is gemis aan een brugfunctie niet mede het gevolg van de opdelingen die er gemaakt zijn en slechte (fact free) communicatie daar tussen?

De demand kant denkt nog weleens dat het lopende band processen zijn, waarbij alles in een gelijk tempo gaat aan de supply kant. In werkelijkheid is het meer Assemble-to-Order waarbij de verschillende halffabrikaten allemaal op andere snelheden lopen. Ik stelde al dat de vertaling van SLA's naar techniek soms op een wonderbaarlijke wijze gedaan wordt, leveranciers beloven schaalbaarheid maar vertellen er niet bij dat horizontale of vertikale schaling twee compleet verschillende benaderingen zijn. Dat snapt technische-IT maar business-IT meestal niet omdat ze in functionaliteiten in plaats van capaciteiten denken.

@Ewout
Ongetwijfeld. Maar de business vraagt mijn inziens terecht om functionaliteiten, dus iemand moet die beide 'talen' voor alle partijen begrijpelijk kunnen maken. Mensen die de juiste vragen kunnen en durven stellen aan en goed kunnen luisteren naar de antwoorden van zowel IT als Business. Functioneel Beheer is daar een goed voorbeeld van, maar wel met een solide IT achtergrond, flinke business- en procesmanagement kennis en bovenal de juiste soft skills. En dan met name dat laatste...

@Ralf
Ik zeg NIET dat de business onterecht om functionaliteiten vraagt, ik zeg alleen dat vertaling ervan naar mogelijkheden nog weleens scheef gaat. E-mail functionaliteit kun je op minimaal 3 manieren invullen, elk met een eigen belasting van de resources. Laat ik stellen dat ik nog weleens prachtige functionele ontwerpen zie die technisch ingevuld zijn op de meest inefficiënte wijze.

Ewout,

Zouden de werkelijke alignment-problemen (of: afstemmingsproblemen) zich niet moeten afspelen op het niveau van:
Application-to-Business (ofwel het ontsluiten van die functionaliteit die de Business vraagt);
Business-to-Business (in verband met federatie/samenwerking);
Business-to-Consumer (ofwel het leveren van die diensten die de klant vraagt).

Ook wel aangeduid met afkortingen als:
A2B (Application to Business); B2B (Business to Business); A2A(Application to Application); B2C(Business to Consumer) - met dank aan Google.

Zolang onderscheid wordt gemaakt tussen demand (business IT) en supply (technische IT) blijf je gevangen in de business IT-alignment problematiek; hoogste tijd dus dat ook supply een zaak wordt van de Business!

Je blijft mijns inziens teveel hangen aan de onmogelijkheden van bestaande technologie en hebt te weinig oog voor de mogelijkheden van nieuwe technologie.

Zoals Peter van Eijk al terecht opmerkt: “Vergeet …technologie”.
Maar dat geldt natuurlijk niet voor techneuten zoals jij :-)

@Jack
Als vrijwel elke functionaliteit afhankelijk is van techniek dan kun je deze negeren maar het wordt lastig als de techniek het vervolgens nalaat. Prachtig verhaal van je maar kijk eens naar gebruikers als netwerk eruit ligt, data niet bereikbaar of elk ander incident dat je maar kunt bedenken. Van Eijk is dan ook een fantast want zonder techniek geen connectie en dus ook geen cloud. Misschien ben ik een technicus maar het is net als met auto's, je hebt monteurs nodig om niet stil te komen staan.

Ewout, je voorbeeld is ongelukkig, want onjuist:
auto’s rijden niet vanwege monteurs, maar vanwege goed functionerende, bewezen technologie.

Als van een nieuw aangeschafte auto na 2 jaar een onderdeel vervangen moet worden hebben zowel de consument als de autofabrikant een stevig probleem. Want een onderdeel dat na 2 jaar al kapot gaat duidt op een fabricagefout, met als gevolg een waardedaling van de tweedehandse modellen en flinke imagoschade voor de fabrikant. Via coulanceregelingen proberen autofabrikanten dit soort gevallen dan ook zo lang mogelijk buiten de publiciteit te houden.

Monteurs dienen voor regulier onderhoud en het oplossen van storingen, die zich dus vooral voordoen (of horen voor te doen) bij verouderde modellen met verouderde technologie.

Tegenwoordig is technologie dus niet meer het issue; het gaat om de functionaliteit.

@Jack
O.N.Z.I.N.

Auto's zijn inderdaad betrouwbaarder geworden maar kunnen nog steeds niet zonder onderhoud, wet verplicht dit zelfs met APK hoewel daarmee uiteindelijk geen pech- en ongevallen te voorkomen zijn. En monteurs hebben niet alleen een rol in reguliere onderhoud maar ook in het ontwerp- en bouwproces. Dit geldt ook voor de IT en met name de infrastructuur omdat er nog een wezenlijk verschil zit tussen functie en prestatie.

Stellen dat technologie geen issue meer is lijkt me onzin als ik kijk dat door 'joy-riding' van de business de kosten de baten overstijgen. Er zit namelijk ook een verschil tussen effectieve en efficiente inzet van technologie. Doelmatigheid is dan ook soms hoogst bedenkelijk als ik kijk naar de stortvloed aan overlappende functies, vooral in B2B en B2C oplossingen.

En inderdaad rijden auto's niet als in één keer iedereen tegelijk door de Coentunnel wil, te weinig infrastructuur blijft altijd weer voor verrassingen zorgen.

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

×
×