ITIL belangrijk?

[Veance]

Ik ben uit interesse mezelf op eigen houtje wat meer kennis aan het toedienen op vlak van netwerken en ook andere topics over IT. Af en toe praat ik wel eens met een ervaren IT'er op mijn werk en dat leidt dan tot een nieuwe deur die open gaat.

Een tijd terug bespraken we allerlei hoofdgroepen die belangrijke kennis zouden zijn voor en IT'er.
Waarop het woord ITIL viel. En dat dit iets is wat elke IT'er zou moeten kennen.

De info die ik zocht online geven me redelijk wat vraagtekens dus heb ik er een boek van gekocht en wat blijkt?

Dat het vrij weinig met IT of netwerken zelf te maken heeft dan wel eerder met een taktiek of werkethiek te maken heeft. Of hoe efficient een service te bieden aan een klant.

Ben ik juist?

Nu vraag ik me af of elke IT'er hier bewust mee moet bezig zijn. Is dit een onderdeel van jullie opleiding geweest? Gebruiken jullie deze kennis (dagelijks) of is dit eerder iets wat uitgewerkt werd op bedrijfsniveau en slechts resulteert in de bedrijfssoftware zoals tickets voor problemen en dan verder niet meer?

[ Voor 5% gewijzigd door Veance op 12-10-2021 09:44 ]

[Rmg]

Het heeft te maken met process management. En ja dit is ongeveer standaardkost op een MBO ICT opleiding.

Je kunt het gebruiken als een referentiekader om IT processen te ontwerpen en dan specifiek voor de service gerichte IT diensten.

Persoonlijk gebruik ik het niet dagelijks in mn software development rol. Daar heb je weer zut als PDLM en Six Sigma die 'in' zijn om processen en managementstrategie te implementeren.

[418O2]

Ik weet er letterlijk niets van (bewust in elk geval) en ben al bijna 15 jaar developer. Veel van zulke zaken zijn vaak vrij logisch, maar dan met een mooie naam en dure certificaten

[ Voor 34% gewijzigd door 418O2 op 12-10-2021 10:02 ]

[CH4OS]

ITIL belangrijk? Kort door de bocht: nee, niet echt, naar mijn mening. ITIL beschrijft hoe je bepaalde processen kan doen binnen grote IT afdelingen. In de praktijk bij bedrijven zijn de processen vaak net iets anders ingericht (100% ITIL is dus echt geen ding) en is ITIL dus vooral een soort richtlijn/gids.

Er kennis van hebben en een certificaat hiervoor kan zeker handig zijn, maar om te zeggen dat het basiskennis is, nee, absoluut niet.

[CH4OS]

418O2 schreef op dinsdag 12 oktober 2021 @ 10:02:
Ik weet er letterlijk niets van (bewust in elk geval) en ben al bijna 15 jaar developer. Veel van zulke zaken zijn vaak vrij logisch, maar dan met een mooie naam en dure certificaten

IT is groter dan developing natuurlijk, die juist weer eigen en andere methodieken en termen heeft, zoals agile, scrum en kanban. ITIL is meer voor dingen als changemanagement, incidentmanagement en inventorymanagement (CMDB), dat soort zaken. Hiermee kun je o.a. de ticket- en RFC-processen beschrijven binnen de organisatie en is dus vooral handig voor grote organisaties.

[ Voor 24% gewijzigd door CH4OS op 12-10-2021 10:07 ]

[418O2]

CH4OS schreef op dinsdag 12 oktober 2021 @ 10:04:
[...]
IT is groter dan developing natuurlijk, die juist weer eigen en andere methodieken en termen heeft, zoals agile, scrum en kanban. ITIL is meer voor dingen als changemanagement, incidentmanagement, dat soort zaken.

Het topic staat in Softwareontwikkeling en het zou belangrijk zijn voor alle IT'ers (waar developers onder vallen toch)?

[Sadieka]

Ik heb de ITIL basis gedaan en op zich is het wel een interessant framework om te kennen. Het framework probeert alles binnen de IT in standaard processen te vatten, van ontwerp tot het einde van de software. Maar wat vooral handig is om even te snappen zijn de processen die meer over de service kant gaan. Dus tegen wat voor type vragen / problemen je klanten aan kunnen lopen en hoe je daar als bedrijf vervolgens mee om kunt gaan. Het procesje van event - incident - problem - change is best waardevol en wordt ook binnen DevOps gewoon toegepast.

Wat je in de praktijk alleen veel ziet is dat bedrijven ITIL als een soort wetboek hanteren en er een enorm papieren proces van maken. Dat moet je ten aller tijde proberen te voorkomen.

[CH4OS]

418O2 schreef op dinsdag 12 oktober 2021 @ 10:07:
Het topic staat in Softwareontwikkeling en het zou belangrijk zijn voor alle IT'ers (waar developers onder vallen toch)?

Ik zie niet hoe ITIL van toegevoegde waarde kan zijn binnen software development. Ik denk wel dat ITIL meerwaarde kan bieden binnen de IT-afdeling van een groot bedrijf of instelling, zodat je een gestandaardiseerde manier hebt van (ver)werken. Software development is maar een klein onderdeel daarvan, terwijl ITIL juist meer over de algehele IT (infrastructuur) gaat.

Bron: mijn eigen ervaringen als ~10 jaar servicedeskmedewerker (en in deze hoedanigheid ITILv2 foundations gecertificeerd) en ~6 jaar (web)developer.

[ Voor 11% gewijzigd door CH4OS op 12-10-2021 10:14 ]

[Rmg]

CH4OS schreef op dinsdag 12 oktober 2021 @ 10:11:
[...]
Ik zie niet hoe ITIL van toegevoegde waarde kan zijn binnen software development. Ik denk wel dat ITIL meerwaarde kan bieden binnen de IT-afdeling van een groot bedrijf of instelling, zodat je een gestandaardiseerde manier hebt van (ver)werken. Software development is maar een klein onderdeel daarvan, terwijl ITIL juist meer over de algehele IT (infrastructuur) gaat.

Bron: mijn eigen ervaringen als ~10 jaar servicedeskmedewerker (en in deze hoedanigheid ITILv2 foundations gecertificeerd) en ~6 jaar (web)developer.

Itil gaat inderdaad meer over de processen er om heen, hoe software development binnen een organisatie in te passen in. En niet zozeer over het software developen zelf.

[CH4OS]

Rmg schreef op dinsdag 12 oktober 2021 @ 10:17:
[Afbeelding]

Itil gaat inderdaad meer over de processen er om heen, hoe software development binnen een organisatie in te passen in. En niet zozeer over het software developen zelf.

Op de pagina waar je de afbeelding vandaan hebt staat ook dit:

Application Development is barely mentioned in the ITIL books, as ITIL focuses on different topics like service design and rollout.

Dus zo raar is het niet, dat het nauwelijks bekend is, of gebruikt wordt.

[ Voor 6% gewijzigd door CH4OS op 12-10-2021 10:22 ]

[Hydra]

Veance schreef op dinsdag 12 oktober 2021 @ 09:41:
Nu vraag ik me af of elke IT'er hier bewust mee moet bezig zijn.

Het is meer relevant voor servicedesk achtig werk. Aan de software engineering kant (waar ik in zit, en waar dit subforum over gaat) is het eigenlijk niet relevant. Veel mensen met ITIL certificaten zijn het hier overigens helemaal niet mee eens natuurlijk want hun hele werk is het maken van word-documentjes en powerpoints die we als developers lekker negeren

[CH4OS]

Hydra schreef op dinsdag 12 oktober 2021 @ 10:21:
Het is meer relevant voor servicedesk achtig werk. Aan de software engineering kant (waar ik in zit, en waar dit subforum over gaat) is het eigenlijk niet relevant. Veel mensen met ITIL certificaten zijn het hier overigens helemaal niet mee eens natuurlijk want hun hele werk is het maken van word-documentjes en powerpoints die we als developers lekker negeren

ITIL behelst wel wat meer dan 'servicedeskachtig werk'. Ik zie een servicedesk medewerker geen grote changes invoeren op core routers in grote IT infrastructuren, daar is een apart changeproces voor om het van voor tot achter te begeleiden, de impact van de wijziging te bevatten en de kans op verstoringen zoveel mogelijk te verkleinen. Nu ben ik toevallig ITILv2 foundations gecertificeerd, maar kan me niet vinden in de rest van jouw vooroordeel. Dat ITIL verder niet relevant is voor software development, ben ik het dan weer wel mee eens. Maar goed, applicatie ontwikkeling kan op zich natuurlijk wel onderdeel zijn van een door met ITIL ingericht proces. Hoe de doelen bewerkstelligt worden op praktisch niveau is natuurlijk aan de afdeling.

[ Voor 32% gewijzigd door CH4OS op 12-10-2021 10:27 ]

[Hydra]

CH4OS schreef op dinsdag 12 oktober 2021 @ 10:23:
[...]
ITIL behelst wel wat meer dan 'servicedeskachtig werk'. Ik zie een servicedesk medewerker geen grote changes invoeren op core routers in grote IT infrastructuren, daar is een apart changeproces voor om het van voor tot achter te begeleiden, de impact van de wijziging te bevatten en de kans op verstoringen zoveel mogelijk te verkleinen.

Tuurlijk. Maar massa's bedrijven doen dat zonder enige vorm van ITIL certificering.

[CH4OS]

Hydra schreef op dinsdag 12 oktober 2021 @ 10:27:
Tuurlijk. Maar massa's bedrijven doen dat zonder enige vorm van ITIL certificering.

Sterker nog; nog grotere massa's doen dat überhaupt zonder ITIL, simpelweg omdat de omvang van de omgeving te klein is. ITIL heeft echt grote meerwaarde binnen grote IT infrastructuren met duizenden medewerkers (buiten de IT afdeling om bedoel ik dan).

[psy]

Al dat geneuzel. Er zijn nog meer weinig collega's echt met een systeem bezig. Inhoudelijke kennis is schaars. De meesten zijn liever bezig hoe ze de organisatie nu weer eens kunnen gaan veranderen. De enige constante op mijn werk lijkt wel de continue verandering van procesinrichting. Maar mijn eigen werk (development) is al 22 jaar exact hetzelfde gebleven. En de echt goede mensen zijn met een lantaarntje te vinden.

Mijn credo - KISS

[ Voor 3% gewijzigd door psy op 12-10-2021 10:38 ]

[EvaluationCopy]

Ik (ITIL Expert v3/v4 papieren) voer altijd strijd met collega's die ik moet overtuigen van het nut van ITIL (Foundation). Het management ('kost geld') en de beoogde collega's zelf ('kapotsaai, wat moet ik er mee etc').

Ik heb altijd wel een paar individuele voorbeelden paraat waarmee ik ze kan overtuigen. 'Weet je nog toen jij dacht die Firewall te moeten patchen tijdens kantoortijd want de klant merkt daar niks van?' (alles plat) = Patterns of Business Activity

'Waarom heb je dat incident een lage prioriteit gegeven?' (Impact x urgentie)

ITIL heeft een hoop concepten waarvan ik vind dat ze voor IT'ers met klantgerichte functies gesneden koek zouden moeten zijn. Natuurlijk komt dat ook met ervaring (en common sense). Maar ik zie in de praktijk toch een groot gebrek aan kennis van ITIL basisconcepten. Het laat zich moeilijk in een businesscase gieten, de trainingen. Maar als je onbewust 2 of 3 betere beslissingen neemt in de jaren na je training dan verdient het zich ruim terug.

Met name de service lifecycle van v3 vind ik erg krachtig: op welke plek in de keten van onze dienst/product bevind mijn kennis/vakgebied zich? Welke gevolgen hebben mijn keuzes verderop in de keten? Etc etc.

Foundation is een prima toevoeging voor veel starters. Sommige (internationale) klanten eisen het zelfs.

[Croga]

Wat @EvaluationCopy ook zegt.

ITIL is mischien niet heel belangrij. De ideëen er achter zijn wel verdomd handig.

Vandaag ook weer: Een interface heeft vanacht niet gelopen. Ik heb hem handmatig af getrapt en daarmee is het af. Dit is een incident en pas als het een repeterend incident is heeft het zin om naar een oorzaak op zoek te gaan. Als het nou morgen en overmorgen weer gebeurt dan weten we dat het niet de nachtelfjes zijn die op een uit knop geduwt hebben.

Net als het gedachtengoed achter het manifesto voor Agile Software Development zou ook iedereen een keer naar ITIL gekeken moeten hebben. Niet omdat je het bedrijf moet overtuigen hun processen te veranderen maar omdat er bepaalde patronen in uitgelegd worden die niet voor iedereen van nature vanzelfsprekend zijn.

[psy]

Common sense dus.

[Speedmaster]

psy schreef op dinsdag 12 oktober 2021 @ 10:48:
Common sense dus.

Ja, maar de gebruiker is niet altijd common sense…😈

[EvaluationCopy]

psy schreef op dinsdag 12 oktober 2021 @ 10:48:
Common sense dus.

Dat blijkt dus bij heel veel mensen te ontbreken. Daar kan een Foundation training handig bij zijn.

Incident vs. problem management, nog zoiets. Hoeveel IT'ers (met zogenaamd jarenlange ervaring en massa's common sense) ik nog moet uitleggen wat het belang van wegnemen van rootcauses is ipv alleen maar brandjes blussen...

Het verschil tussen een change en een service request. Het is allemaal niet ingewikkeld, maar het helpt zéker als je het in het begin van je carriere een keer goed krijgt uitgelegd.

[FreakNL]

EvaluationCopy schreef op dinsdag 12 oktober 2021 @ 10:40:
Ik (ITIL Expert v3/v4 papieren) voer altijd strijd met collega's die ik moet overtuigen van het nut van ITIL (Foundation). Het management ('kost geld') en de beoogde collega's zelf ('kapotsaai, wat moet ik er mee etc').

Ik heb altijd wel een paar individuele voorbeelden paraat waarmee ik ze kan overtuigen. 'Weet je nog toen jij dacht die Firewall te moeten patchen tijdens kantoortijd want de klant merkt daar niks van?' (alles plat) = Patterns of Business Activity

'Waarom heb je dat incident een lage prioriteit gegeven?' (Impact x urgentie)

ITIL heeft een hoop concepten waarvan ik vind dat ze voor IT'ers met klantgerichte functies gesneden koek zouden moeten zijn. Natuurlijk komt dat ook met ervaring (en common sense). Maar ik zie in de praktijk toch een groot gebrek aan kennis van ITIL basisconcepten. Het laat zich moeilijk in een businesscase gieten, de trainingen. Maar als je onbewust 2 of 3 betere beslissingen neemt in de jaren na je training dan verdient het zich ruim terug.

Met name de service lifecycle van v3 vind ik erg krachtig: op welke plek in de keten van onze dienst/product bevind mijn kennis/vakgebied zich? Welke gevolgen hebben mijn keuzes verderop in de keten? Etc etc.

Foundation is een prima toevoeging voor veel starters. Sommige (internationale) klanten eisen het zelfs.

Dat je geen FW moet patchen tijdens productietijd heb ik echt geen ITIL voor nodig.

Ik heb in een grijs verleden Foundation gedaan maar ik doe er niks mee.

Common sense en KISS kom je een eind mee.

[Falcon]

Ik vroeg mij af hoe ik ITIL moet zien aangaande DevOps, kwam dit artikel tegen:
https://www.improfs.com/itil-of-devops-nee-itil-en-devops/

[EvaluationCopy]

FreakNL schreef op dinsdag 12 oktober 2021 @ 10:54:
[...]


Dat je geen FW moet patchen tijdens productietijd heb ik echt geen ITIL voor nodig.

Ik heb in een grijs verleden Foundation gedaan maar ik doe er niks mee.

Common sense en KISS kom je een eind mee.

Waarschijnlijk doe je er onbewust meer mee dan je denkt. Wat jij common sense noemt is ook vaak opgedane ervaring, opgedane kennis etc. Maar ik ben het met je eens dat het niet makkelijk concreet te maken is. En ik ken ook toppers die ITIL inderdaad niet nodig hebben. Maar die zijn in de minderheid, geloof me.

[psy]

EvaluationCopy schreef op dinsdag 12 oktober 2021 @ 10:54:
[...]


Dat blijkt dus bij heel veel mensen te ontbreken. Daar kan een Foundation training handig bij zijn.

Incident vs. problem management, nog zoiets. Hoeveel IT'ers (met zogenaamd jarenlange ervaring en massa's common sense) ik nog moet uitleggen wat het belang van wegnemen van rootcauses is ipv alleen maar brandjes blussen...

Het verschil tussen een change en een service request. Het is allemaal niet ingewikkeld, maar het helpt zéker als je het in het begin van je carriere een keer goed krijgt uitgelegd.

Maar is dat ook niet meer een probleem van een gebrek aan betrokkenheid?

Er wordt door velen maar wat aangeklooid. Probleempje oplossen (bv interface herstarten zonder te kijken waarom idd) en klaar. Om 17 uur lekker de laptop uitdoen en naar huis karren. Zich niet afvragen waarom iets fout blijft gaan.

[Hydra]

EvaluationCopy schreef op dinsdag 12 oktober 2021 @ 10:40:
'Waarom heb je dat incident een lage prioriteit gegeven?' (Impact x urgentie)

Goed voorbeeld; dit wordt ook gewoon zonder ITIL gedaan over het algemeen. Ben het er dus mee eens dat het vooral common sense is, en dat als mensen dat niet hebben, een certificaat niet gaat helpen.

[Hydra]

EvaluationCopy schreef op dinsdag 12 oktober 2021 @ 10:54:
Incident vs. problem management, nog zoiets. Hoeveel IT'ers (met zogenaamd jarenlange ervaring en massa's common sense) ik nog moet uitleggen wat het belang van wegnemen van rootcauses is ipv alleen maar brandjes blussen...

Grappig genoeg is het vaak management dat daar dwars ligt. Developers zitten zelf ook niet te wachten op on-calls waar ze midden in de nacht shit moeten fixen.

[Hydra]

psy schreef op dinsdag 12 oktober 2021 @ 11:03:
Er wordt door velen maar wat aangeklooid. Probleempje oplossen (bv interface herstarten zonder te kijken waarom idd) en klaar. Om 17 uur lekker de laptop uitdoen en naar huis karren. Zich niet afvragen waarom iets fout blijft gaan.

Er zijn gewoon veel slechte devs. Die ga je niet opeens goed maken met een ITIL participation trophy.

[ThomasG]

Hydra schreef op dinsdag 12 oktober 2021 @ 11:06:
[...]


Goed voorbeeld; dit wordt ook gewoon zonder ITIL gedaan over het algemeen. Ben het er dus mee eens dat het vooral common sense is, en dat als mensen dat niet hebben, een certificaat niet gaat helpen.

Het is niet eens alleen common sense. In de praktijk blijkt dat mensen over hele simpele dingen al een totaal verschillende interpretatie kunnen hebben, ook al lijken ze op dezelfde lijn te zitten. Het is in de praktijk dus gewoon belangrijk om het ergens duidelijk te hebben staan. Het hoeft niet meteen ITIL te zijn, maar een beschrijving van de procedures is eigenlijk gewoon een pré. Zelfs als je met korte lijnen werkt.

[TheDudez]

Mijn ervaring is:

Bij detachering willen ze vaak dat je dit papiertje haalt. In de praktijk gebruik je het nauwelijks. Alleen de basis dingen. Maar die spreken voor zich. Oftewel alleen de basis opleiding is handig als je begint in de ICT. Maar daarna de vervolg opleidingen volgen is echt zonde van je tijd. In de praktijk gebruik je het nauwelijks.

Maar misschien dat andere personen andere ervaringen hebben.

[Grvy]

EvaluationCopy schreef op dinsdag 12 oktober 2021 @ 10:54:
[...]


Dat blijkt dus bij heel veel mensen te ontbreken. Daar kan een Foundation training handig bij zijn.

Incident vs. problem management, nog zoiets. Hoeveel IT'ers (met zogenaamd jarenlange ervaring en massa's common sense) ik nog moet uitleggen wat het belang van wegnemen van rootcauses is ipv alleen maar brandjes blussen...

Het verschil tussen een change en een service request. Het is allemaal niet ingewikkeld, maar het helpt zéker als je het in het begin van je carriere een keer goed krijgt uitgelegd.

10000% mee eens. Zoveel IT'ers die denken dat ze e.a. "god ITer" zijn omdat ze de hele dag brandjes aan het blussen zijn. Ik noem dat incompetentie.

[Aragnut]

Ik ken ITIL voornamelijk vanuit de beheerders kant.

Bij een grote IT dienstverlener gewerkt en daar was alles ITIL ingericht. Helaas tot zover doorgevoerd dat het ITIL process belangrijker was dan het daadwerkelijke werk/issue. Vaak genoeg bij Large Change Control Boards moeten aankomen om tegen 4 man die geen idee van Unix hebben de change uit te leggen. Wat ik zelf wel handig vond is dat je door ITIL moet nadenken over je change: impact, duur, wie heb ik verder nodig, hoe rol ik het terug, wat gebeurd er als we het niet doen etc.
Daarnaast ook de nodige root cause analysis documenten moeten schrijven, en heb ik aan het eind zelf nog een hele workflow opgezet voor het uitrollen van AIX hosts binnen een on demand omgeving (multi tenant). voordeel: iedereen doet hetzelfde dus je nieuwe host is veel meer standaard ingericht.

Helaas werd er ook de nodige over de schutting gegooid tussen afdelingen met behulp van het ITIL process en werd je als afdeling afgerekend op aantal tickets. Op een moment kwam een manager erachter dat bij ons 90% van de tickets uit de automated monitoring kwam. Antwoord van een collega: maar dat is toch juist goed? dan waren we er maar 10% van de keren niet eerder bij dan de klant. Zo had de manager het natuurlijk nog niet bekeken....

Uiteindelijk is ITIL een proces dat je moet helpen om georganiseerd en overzichtelijk te kunnen samenwerken binnen een team (of tussen teams) waarbij de belangrijkste zaken eerst gedaan worden.

Waar ik nu werk is de IT een stuk kleiner en merk je dat dergelijke processen een stuk losser ingeregeld zijn. Ik heb voor een aantal dingen in de loop der tijd wel gepusht om het via iets meer ITIL manier te doen (dus ticket in plaats van een mailtje of langs lopen bijvoorbeeld).

[Gormenghast]

Vrijwel alle grote bedrijven werken binnen de ICT in meer of mindere mate met principes van ITIL. Of je nu op de helpdesk terecht komt ,een beheerplek of functioneel beheer, binnen al deze functies zul je tegen onderdelen van ITIL aan lopen. Daarom denk ik ook dat ITIL bijna een must-have is.

Wanneer je solliciteert zal je bij de meeste functies dan ook aantreffen dat kennis van ITIL een pre is.

Is het superboeiend? Daar zullen de meningen over verschillen maar 80% zal zeggen van niet. Daar staat tegenover dat je vrij eenvoudig het ITIL foundation papiertje kan halen en je de opgedane kennis weer kan gebruiken bij de meeste bedrijven.

[Hydra]

ThomasG schreef op dinsdag 12 oktober 2021 @ 11:13:
Het is niet eens alleen common sense. In de praktijk blijkt dat mensen over hele simpele dingen al een totaal verschillende interpretatie kunnen hebben, ook al lijken ze op dezelfde lijn te zitten. Het is in de praktijk dus gewoon belangrijk om het ergens duidelijk te hebben staan. Het hoeft niet meteen ITIL te zijn, maar een beschrijving van de procedures is eigenlijk gewoon een pré. Zelfs als je met korte lijnen werkt.

Er is niks mis met documenteren zo lang het maar goed gebeurt, maar wederom is dat gewoon niet iets waar je ITIL voor nodig hebt. Ik 'doe' al lang software engineering, vooral bij grote enterprise bedrijven met complexe architecturen, en je ziet daar ITIL gewoon niet terug als 'wens' of iets in die trant. Ik geloof gewoon niet in certificaten maar dat betekent niet dat ik niet geloof in een goede SDLC.

Neemt natuurlijk niet weg dat als je op vacatures reageert waar deze wel vaak gevraagd worden ik het volkomen logisch vindt dat je er wel voor gaat. Sowieso is "IT" daar heel anders dan software development omdat er gewoon geen goede "software development" certificaten zijn.

[ Voor 12% gewijzigd door Hydra op 12-10-2021 11:38 ]

[stijnislike]

Als je devops doet of iets wat erop lijkt bij een groter bedrijf kom je vroeg of laat toch met processen in aanraking die via ITIL zijn ingericht. Kennis ervan kan dan handig zijn, vooral bij zaken als grote changes. Om te stellen dat het nu broodnodig is voor elke ontwikkelaar gaat misschien wat ver.

[CH4OS]

Grvy schreef op dinsdag 12 oktober 2021 @ 11:20:
10000% mee eens. Zoveel IT'ers die denken dat ze e.a. "god ITer" zijn omdat ze de hele dag brandjes aan het blussen zijn. Ik noem dat incompetentie.

Naast dat je uiteindelijk ook niet gelukkig wordt van het werk.

[CH4OS]

TheDudez schreef op dinsdag 12 oktober 2021 @ 11:19:
Mijn ervaring is:

Bij detachering willen ze vaak dat je dit papiertje haalt. In de praktijk gebruik je het nauwelijks. Alleen de basis dingen. Maar die spreken voor zich. Oftewel alleen de basis opleiding is handig als je begint in de ICT. Maar daarna de vervolg opleidingen volgen is echt zonde van je tijd. In de praktijk gebruik je het nauwelijks.

Maar misschien dat andere personen andere ervaringen hebben.

De detachering wilt dat, omdat de klanten het van de medewerkers eist dat ze het hebben en dus bekend zijn met de ITIL-concepten. In dat opzicht is ITIL Foundation inderdaad voldoende, die heb ik (voor v2 althans) ook.

[Shivs]

ITIL is in mijn optiek handig als je geen ervaring hebt in de IT, dan is het een mooie inkijk hoe het zou kunnen. Het behelst een stuk meer dan alleen het service gedeelte tegenwoordig en geeft daarmee een prima overview van hoe je IT binnen een organisatie zou kunnen inrichten.

Tevens is het denk ik handig om het te kennen, omdat het zo verdomd groot is geworden in de IT wereld. Dat is ook vooral waar het verschil zit met common-sence als je het mij vraagt. Dat is soms ver te zoeken, maar ITIL hebben ze allemaal wel eens van gehoord.

Heb je ITIL dan echt nodig? Nee, maar het kan wel helpen om dingen in perspectief te zetten of om dingen niet over het hoofd te zien bij het inrichten van een IT afdeling/functie in een bedrijf.

[CH4OS]

Shivs schreef op dinsdag 12 oktober 2021 @ 12:39:
Heb je ITIL dan echt nodig? Nee, maar het kan wel helpen om dingen in perspectief te zetten of om dingen niet over het hoofd te zien bij het inrichten van een IT afdeling/functie in een bedrijf.

Het is niet dat ITIL alleen zorgt voor het opzetten van een afdeling of bedrijf. Het zorgt voor stroomlijning in interne IT-procesen en is daarmee dus iets 'blijvends' en 'leeft' het ook, doordat het proces continu aan verandering onderhevig is.

[Shivs]

Daar ben ik het mee eens. Het is in deze situatie, voor iemand die niet in de IT zit, denk ik relevanter om de structuur te zien die mogelijk is dan de evolutie van ITIL binnen een bedrijf. Maar uiteraard staan zulke zaken niet stil nadat je ze geïmplementeerd hebt.

[LankHoar]

EvaluationCopy schreef op dinsdag 12 oktober 2021 @ 10:40:
Ik (ITIL Expert v3/v4 papieren) voer altijd strijd met collega's die ik moet overtuigen van het nut van ITIL (Foundation). Het management ('kost geld') en de beoogde collega's zelf ('kapotsaai, wat moet ik er mee etc').

Ik heb altijd wel een paar individuele voorbeelden paraat waarmee ik ze kan overtuigen. 'Weet je nog toen jij dacht die Firewall te moeten patchen tijdens kantoortijd want de klant merkt daar niks van?' (alles plat) = Patterns of Business Activity

'Waarom heb je dat incident een lage prioriteit gegeven?' (Impact x urgentie)

ITIL heeft een hoop concepten waarvan ik vind dat ze voor IT'ers met klantgerichte functies gesneden koek zouden moeten zijn. Natuurlijk komt dat ook met ervaring (en common sense). Maar ik zie in de praktijk toch een groot gebrek aan kennis van ITIL basisconcepten. Het laat zich moeilijk in een businesscase gieten, de trainingen. Maar als je onbewust 2 of 3 betere beslissingen neemt in de jaren na je training dan verdient het zich ruim terug.

Met name de service lifecycle van v3 vind ik erg krachtig: op welke plek in de keten van onze dienst/product bevind mijn kennis/vakgebied zich? Welke gevolgen hebben mijn keuzes verderop in de keten? Etc etc.

Foundation is een prima toevoeging voor veel starters. Sommige (internationale) klanten eisen het zelfs.

Jammer dat ik als niet-TS zijnde geen posts kan aanmerken als beste antwoord, want dat is dit zeker!

[downtime]

Als IT'er sinds 22 jaar, en voornamelijk werkzaam in Enterprise(y) omgevingen, is ITIL gewoon verplichte kost. Al was het maar zodat we terminologie standaardiseren en allemaal het verschil tussen een incident en een problem snappen. Ik heb twee maal het Foundation certificaat (V2 en V3 dacht ik) moeten halen omdat twee van mijn werkgevers het verplicht stelden.

En ja, ITIL is deels common sense, zoals elk goed proces grotendeels common sense is. Dat maakt ITIL nog niet overbodig. Verkeersregels zijn ook common sense maar die leren we ook.

[FreakNL]

EvaluationCopy schreef op dinsdag 12 oktober 2021 @ 10:56:
[...]


Waarschijnlijk doe je er onbewust meer mee dan je denkt. Wat jij common sense noemt is ook vaak opgedane ervaring, opgedane kennis etc. Maar ik ben het met je eens dat het niet makkelijk concreet te maken is. En ik ken ook toppers die ITIL inderdaad niet nodig hebben. Maar die zijn in de minderheid, geloof me.

Klopt. Heeft niks met ITIL te maken.

[unezra]

CH4OS schreef op dinsdag 12 oktober 2021 @ 10:29:
[...]
Sterker nog; nog grotere massa's doen dat überhaupt zonder ITIL, simpelweg omdat de omvang van de omgeving te klein is. ITIL heeft echt grote meerwaarde binnen grote IT infrastructuren met duizenden medewerkers (buiten de IT afdeling om bedoel ik dan).

Dat is in mijn beleving onzin.

ITIL is niet een dingetje dat enkel nut heeft bij grote bedrijven en grote ICT afdelingen. Ik gebruikte een subset van ITIL op een 2-mans ICT afdeling en daar had het volledig nut.

Wel is dé essentie van ITIL dat je niet het hele circus van A-Z implementeerd, maar alleen dat wat nodig is voor jouw specifieke organisatie en werkwijze. Implementeer je ITIL van A-Z, zit je opeens in je eentje 6x op "approve" te klikken bij een change. Dat werkt niet.

Zelfs in een kleine organisatie is het verdomd handig om te spreken over incidenten, service requests, problems, changes, etc. Zodra je dat doet, hanteer je al een subset van ITIL. Ik denk dat er weinig organisaties bij IT-Ops, compleet andere terminologie en achterliggende processen gebruiken.

Of het voor 100% dev nuttig/nodig is, ik denk in zoverre dat dev niet op zichzelf staat in een organisatie, maar afhankelijkheden heeft buiten de devteams. Dan is kennis van de basisbegrippen (ITIL Foundation), zeker nuttig. De rest kun je over twisten.

[CH4OS]

unezra schreef op woensdag 13 oktober 2021 @ 07:05:
Dat is in mijn beleving onzin.

ITIL is niet een dingetje dat enkel nut heeft bij grote bedrijven en grote ICT afdelingen. Ik gebruikte een subset van ITIL op een 2-mans ICT afdeling en daar had het volledig nut.

Wel is dé essentie van ITIL dat je niet het hele circus van A-Z implementeert, maar alleen dat wat nodig is voor jouw specifieke organisatie en werkwijze. Implementeer je ITIL van A-Z, zit je opeens in je eentje 6x op "approve" te klikken bij een change. Dat werkt niet.

Dat doe je natuurlijk sowieso al, ook in grotere organisaties wordt ITIL gewoon als leidraad gebruikt en wordt het ingepast bij de huidige processen. In dat opzicht werken kleinere bedrijven veel meer met een ad-hoc en hands-on mentaliteit. Zaken als configuratiemanagement en problemmanagement zijn daar nauwelijks aan de orde, net als incidentmanagement. Dan is het gewoon "@unezra, kom even, ik heb een probleem met....". Natuurlijk vinden grotere aanpassingen buiten werktijd plaats, maar voor de rest is er binnen kleine bedrijven vooral een "het werkt toch!?" mentaliteit met daaraan "If it ain't broke, don't fix it" gekoppeld. Ga je wel zaken aan (incident)tickets koppelen en registreren, hoef je echt niet "al" met ITIL bezig te zijn. Want dan heb je ook prioriteiten en responstijden vastgelegd, wat de meeste kleine bedrijven ook niet hanteren.

Zelfs in een kleine organisatie is het verdomd handig om te spreken over incidenten, service requests, problems, changes, etc. Zodra je dat doet, hanteer je al een subset van ITIL. Ik denk dat er weinig organisaties bij IT-Ops, compleet andere terminologie en achterliggende processen gebruiken.

Onze ervaringen verschillen dan compleet. Ik heb bij meerdere kleine bedrijven gewerkt in diverse branches en kan je vertellen dat ik totaal andere ervaringen heb.

Of het voor 100% dev nuttig/nodig is, ik denk in zoverre dat dev niet op zichzelf staat in een organisatie, maar afhankelijkheden heeft buiten de devteams. Dan is kennis van de basisbegrippen (ITIL Foundation), zeker nuttig. De rest kun je over twisten.

ITIL is meer een leidraad voor de alles omvattende IT (ITIL is immers een raamwerk) en komt gewoon het beste tot zijn recht in grote(re) organisaties, door structuur aan te brengen in de werkwijze en afspraken te hebben tussen de afdelingen onderling. Hoe een devteam vervolgens hun werk in richt, of de afdeling van netwerkbeheerders om twee voorbeelden te noemen, kunnen ze vervolgens zelf invullen.

[Knutselsmurf]

psy schreef op dinsdag 12 oktober 2021 @ 10:48:
Common sense dus.

Klopt. Maar de enige manier om zelf die common sense op te doen, is gaandeweg je hoofd een aantal keer te stoten en te leren. Als iedereen dat doet, wordt het wiel wel heel vaak opnieuw uitgevonden. Dan is het toch handig als die common sense op papier wordt gezet, zodat bijvoorbeeld iedereen dezelfde termen gebruikt.

Het gevaar bestaat echter, dat iets als ITIL een eigen leven gaat leiden, waarbij men alleen nog maar de 'regeltjes' leert en vergeet wat de achterliggende common sense is.

[The Eagle]

Of het nou ITIL, Agile, SAFe, Scrum, PRINCE2, ASL/BiSL of een ander framework is: sommige mensen zijn er dagelijks mee bezig, anderen niet. Het is goed om te weten dat ze bestaan. Afhankelijk van je functie en je werkgever / klant is het handig om te weten wat men gebruikt voor bijvoorbeeld procesinrichting of projectmanagement methodiek en daar wat inhoudelijke kennis van te hebben. Dit omdat je er dan rekening mee kunt houden of, afhankelijk van je functie, op kunt sturen.

Gebruikt een bedrijf bijvoorbeeld ITIL en ASL/BISL dan kun je er vanuit gaan dat de procesinrichting vrij rigide is. Betekent soms langere doorlooptijden als je een incident of wijziging hebt, maar wel iets waar je rekening mee kunt houden en dus op kunt plannen, want standaard doorlooptijden. Daar staat tegenover dat er bij verstoringen of changes vaak heel goed terug is te vinden wie wat gedaan heeft en waarom.
Keerzijde is dat men dan een stuk minder agile is en het vaak ook lastiger is om nieuwe technologieen in te brengen.

[unezra]

CH4OS schreef op woensdag 13 oktober 2021 @ 09:34:
[...]
Dat doe je natuurlijk sowieso al, ook in grotere organisaties wordt ITIL gewoon als leidraad gebruikt en wordt het ingepast bij de huidige processen. In dat opzicht werken kleinere bedrijven veel meer met een ad-hoc en hands-on mentaliteit. Zaken als configuratiemanagement en problemmanagement zijn daar nauwelijks aan de orde, net als incidentmanagement. Dan is het gewoon "@unezra, kom even, ik heb een probleem met....". Natuurlijk vinden grotere aanpassingen buiten werktijd plaats, maar voor de rest is er binnen kleine bedrijven vooral een "het werkt toch!?" mentaliteit met daaraan "If it ain't broke, don't fix it" gekoppeld. Ga je wel zaken aan (incident)tickets koppelen en registreren, hoef je echt niet "al" met ITIL bezig te zijn. Want dan heb je ook prioriteiten en responstijden vastgelegd, wat de meeste kleine bedrijven ook niet hanteren.

Juist wel. Je kunt een SLA vast leggen, maar de uitvoering losjes doen. SLA's gaan om verwachtingsmanagement. Dat is zelfs heel prettig als het hele bedrijf 50 FTE groot is en de ICT afdeling bestaat uit 2 man. (Geen onwikkeleurig voorbeeld.) Automatisch prioriteiten toekennen op basis van overleg met de stakeholders, voorkomt een hoop vervelende discussies.

[...]
Onze ervaringen verschillen dan compleet. Ik heb bij meerdere kleine bedrijven gewerkt in diverse branches en kan je vertellen dat ik totaal andere ervaringen heb.

Er is een verschil tussen "zouden ze een subset van ITIL moeten gebruiken, of doen ze dat in de praktijk some-sort-of-onbewst" en "ze gebruiken helemaal geen proces- en projectmethodieken". Dat laatste zal minder vaak voorkomen dan het eerste. Als het er niet is, betekend het niet dat het niet nuttig of nodig is en dus eigenlijk gewoon geïmplementeerd moet worden. Al was het maar met de invoering van een eenvoudig ticketsysteem. (Dat vrijwel 100% zeker, ITIL als basis heeft.)

[...]
ITIL is meer een leidraad voor de alles omvattende IT (ITIL is immers een raamwerk) en komt gewoon het beste tot zijn recht in grote(re) organisaties, door structuur aan te brengen in de werkwijze en afspraken te hebben tussen de afdelingen onderling. Hoe een devteam vervolgens hun werk in richt, of de afdeling van netwerkbeheerders om twee voorbeelden te noemen, kunnen ze vervolgens zelf invullen.

Hierover verschillen we echt fundamenteel van mening. Ik denk dat goed proces en projectmanagement, essentieel is voor iedere organisatie. Ook als het gaat om kleinere organisaties.

Het juist toepassen van proces en projectmanagement, *bespaard* kosten, verhoogt de efficiëntie en draagt uiteindelijk bij aan een betere overall ervaring van alle stakeholders.

Absoluut dat devteams in de regel behoefte hebben aan *andere* proces- en projectmethodieken dan IT-ops teams, maar dat wil niet zeggen dat er in het geheel geen behoefte aan is.

ITIL is veelomvattend als procesmethodiek en ik denk dat een basiskennis hiervan (Foundation), essentieel is voor praktisch iedereen in de ICT, ook dev. Al was het maar om wanneer zij ergens te maken krijgen met IT-Ops, hun manier van werken kunnen alignen.

Is het nuttig voor dev? Ja.
Moet dev altijd kennis hebben van het complete framework? Neuh. Daarvoor is het veel te uitgebreid.

[Hydra]

unezra schreef op woensdag 13 oktober 2021 @ 07:05:
Of het voor 100% dev nuttig/nodig is, ik denk in zoverre dat dev niet op zichzelf staat in een organisatie, maar afhankelijkheden heeft buiten de devteams. Dan is kennis van de basisbegrippen (ITIL Foundation), zeker nuttig. De rest kun je over twisten.

Dit zijn geen "ITIL begrippen". Beetje een kip-ei verhaal, maar de meeste van dit soort 'processen' zijn weinig anders dan het formaliseren van common sense. Ook zonder ITIL heb je het als developer over 'changes' of 'incidents', alleen noem je ze soms anders. Scrum bijvoorbeeld is ook een formalisering van agile practices die al veel ouder zijn. ITIL is in die zin niet anders.

Als het voor een bedrijf handig is om een paar mensen op een ITIL cursus te doen; prima. Maar je hoeft niet een dergelijk certificaat te hebben om te weten wat een 'incident' is. Zelfde geldt bijvoorbeeld voor Scrum; veruit de meeste mensen 'doen' Scrum zonder daarvoor een certificaat te hebben.

[unezra]

Hydra schreef op woensdag 13 oktober 2021 @ 11:25:
[...]


Dit zijn geen "ITIL begrippen". Beetje een kip-ei verhaal, maar de meeste van dit soort 'processen' zijn weinig anders dan het formaliseren van common sense. Ook zonder ITIL heb je het als developer over 'changes' of 'incidents', alleen noem je ze soms anders. Scrum bijvoorbeeld is ook een formalisering van agile practices die al veel ouder zijn. ITIL is in die zin niet anders.

Als het voor een bedrijf handig is om een paar mensen op een ITIL cursus te doen; prima. Maar je hoeft niet een dergelijk certificaat te hebben om te weten wat een 'incident' is. Zelfde geldt bijvoorbeeld voor Scrum; veruit de meeste mensen 'doen' Scrum zonder daarvoor een certificaat te hebben.

Volgens mij ging het ook niet over de vraag of het nuttig is ITIL gecertificeerd te zijn.
Enkel over of basiskennis van ITIL (op Foundation niveau) nuttig is voor devteams.

[Vipertje]

Enige wat ik nog van ITIL kan herinneren is iets met een Apollo 13 simulatie spel. Voor de rest enkel nog bedrijven tegenkomen die claimen heel dik in de processen te zitten, maar in de praktijk ad hoc brandjes aan het blussen zijn.

Dit soort dingen zijn leuk om te hebben omdat HR meisjes daar mogelijk op filteren op LinkedIn, maar mocht een bedrijf dit compleet geïmplementeerd hebben leer je prima on the job hoe alles in elkaar steekt. Geen training/certificaat voor nodig

[Hydra]

Vipertje schreef op woensdag 13 oktober 2021 @ 11:30:
HR meisjes

Lijkt me niet nodig.

[unezra]

Vipertje schreef op woensdag 13 oktober 2021 @ 11:30:
Enige wat ik nog van ITIL kan herinneren is iets met een Apollo 13 simulatie spel. Voor de rest enkel nog bedrijven tegenkomen die claimen heel dik in de processen te zitten, maar in de praktijk ad hoc brandjes aan het blussen zijn.

Dit soort dingen zijn leuk om te hebben omdat HR meisjes

HRM & hiring managers <-- FTFY

Vipertje schreef op woensdag 13 oktober 2021 @ 11:30: daar mogelijk op filteren op LinkedIn, maar mocht een bedrijf dit compleet geïmplementeerd hebben leer je prima on the job hoe alles in elkaar steekt. Geen training/certificaat voor nodig

Ik denk dat je ITIL onderschat als je denkt dat je alles on-the-job kunt leren zonder ooit een ITIL boek te lezen.

Certificering, tja, soms kan het handig zijn de kennis van specifieke materie objectief te hebben vastgesteld. Is certificering *nodig* voor je werk? Nee. Is het logisch dat er door hiring managers en HRM op word gefilterd? Is wat voor te zeggen.

[CH4OS]

unezra schreef op woensdag 13 oktober 2021 @ 11:22:
Juist wel. Je kunt een SLA vast leggen, maar de uitvoering losjes doen. SLA's gaan om verwachtingsmanagement. Dat is zelfs heel prettig als het hele bedrijf 50 FTE groot is en de ICT afdeling bestaat uit 2 man. (Geen onwikkeleurig voorbeeld.) Automatisch prioriteiten toekennen op basis van overleg met de stakeholders, voorkomt een hoop vervelende discussies.

Heb jij ooit een kleine organisatie, bedrijf of instelling met een SLA zien werken met degene(n) die de interne IT doet? Degenen die de IT via outsourcing hebben, ja, maar niet elk kleine bedrijf heeft daar geld voor (of ervoor over). Ik heb bij een dergelijk bedrijf gewerkt in het verleden, waar ik samen met iemand anders samen de webdevelopment + interne IT deed, daar werd echt niet met SLA's oid gewerkt. Dat was gewoon altijd ad hoc.

Er is een verschil tussen "zouden ze een subset van ITIL moeten gebruiken, of doen ze dat in de praktijk some-sort-of-onbewst" en "ze gebruiken helemaal geen proces- en projectmethodieken". Dat laatste zal minder vaak voorkomen dan het eerste. Als het er niet is, betekend het niet dat het niet nuttig of nodig is en dus eigenlijk gewoon geïmplementeerd moet worden. Al was het maar met de invoering van een eenvoudig ticketsysteem. (Dat vrijwel 100% zeker, ITIL als basis heeft.)

Ik zeg dan ook nergens dat ITIL niet nuttig is, ik zeg dat ITIL in grotere organisaties een veel groter nut kan dienen dan in de kleine, doordat in een grote organisatie meer structuur nodig is om de samenwerking überhaupt goed te laten verlopen.

Hierover verschillen we echt fundamenteel van mening. Ik denk dat goed proces en projectmanagement, essentieel is voor iedere organisatie. Ook als het gaat om kleinere organisaties.
Het juist toepassen van proces en projectmanagement, *bespaard* kosten, verhoogt de efficiëntie en draagt uiteindelijk bij aan een betere overall ervaring van alle stakeholders.

ITIL is geen framework voor projectmanagement, daar is PRINCE voor bedoeld. ITIL kan helpen als leidraad bij IT specifieke processen, daar buiten zie je het weinig gebruikt worden.

ITIL is veelomvattend als procesmethodiek en ik denk dat een basiskennis hiervan (Foundation), essentieel is voor praktisch iedereen in de ICT, ook dev. Al was het maar om wanneer zij ergens te maken krijgen met IT-Ops, hun manier van werken kunnen alignen.

Het ligt er echt aan. Mijn vorige werkgever was een partij dat (web)apps en websites ontwikkeld voor de klanten, een software huis, zal ik maar zeggen. Met elk project werd er anders gewerkt. De teams werken voor specifieke klanten een algemene infra is er niet, of uiterst minimaal (voor het eigen interne netwerk bijvoorbeeld). De interne IT afdeling was dan ook maar 2 man en zouden die ook geen eigen klanten hebben, had de interne IT makkelijk met zelfs 1 iemand af gekund. Daar werd echt totaal niet met ITIL gewerkt. Wel heel veel met DevSecOps en natuurlijk ook een boel in overleg met de klant. Daar ontzorgden we de klant dus voor zowel het beheer als ontwikkeling aan hun website en de benodigdheden daarvoor.

Is het nuttig voor dev? Ja.
Moet dev altijd kennis hebben van het complete framework? Neuh. Daarvoor is het veel te uitgebreid.

Veel toegevoegde waarde heeft het niet voor developers, ondanks dat ITIL an sich zeker wel nuttig kan zijn, maar het is afhankelijk van de grootte en de manier van werken in hoeverre ITIL echt toegevoegde waarde is binnen het bedrijf of de instelling. Bij het voorbeeld hierboven heeft het gewoon geen toegevoegde waarde. Toen ik bij de servicedesk van de Gemeente Utrecht werkte (~3500 medewerkers in totaal inclusief IT afdeling van ~100-150 medewerkers), was daar de introductie van ITIL (naar mijn mening) echt een grote stap voorwaarts destijds.

[ Voor 6% gewijzigd door CH4OS op 13-10-2021 12:33 ]

[unezra]

CH4OS schreef op woensdag 13 oktober 2021 @ 12:27:
[...]
Heb jij ooit een kleine organisatie, bedrijf of instelling met een SLA zien werken met degene(n) die de interne IT doet? Degenen die de IT via outsourcing hebben, ja, maar niet elk kleine bedrijf heeft daar geld voor (of ervoor over). Ik heb bij een dergelijk bedrijf gewerkt in het verleden, waar ik samen met iemand anders samen de webdevelopment + interne IT deed, daar werd echt niet met SLA's oid gewerkt. Dat was gewoon altijd ad hoc.

Ja en (de afgelopen ~25 jaar) meerdere malen.

[...]
Ik zeg dan ook nergens dat ITIL niet nuttig is, ik zeg dat ITIL in grotere organisaties een veel groter nut kan dienen dan in de kleine, doordat in een grote organisatie meer structuur nodig is om de samenwerking überhaupt goed te laten verlopen.

Ik denk dat het per-saldo, het nut niet eens heel veel uit maakt.
Ook in een kleine organisatie is Outlook als ticketsysteem onwerkbaar.

[...]
ITIL is geen framework voor projectmanagement, daar is PRINCE voor bedoeld. ITIL kan helpen als leidraad bij IT specifieke processen, daar buiten zie je het weinig gebruikt worden.

Ik ken de verschillen.

(Het ITIL Master boekenpakket staat hier in de kast. Nog niet alles doorgelezen, niet gecertificeerd. Wel tot op zekere hoogte bekend met de materie. PRINCE2 ben ik niet verder gekomen dan PRINCE2 en "PRINCE2 Agile" foundation.)

[...]
Het ligt er echt aan. Mijn vorige werkgever was een partij dat (web)apps en websites ontwikkeld voor de klanten, een software huis, zal ik maar zeggen. Met elk project werd er anders gewerkt. De teams werken voor specifieke klanten een algemene infra is er niet, of uiterst minimaal (voor het eigen interne netwerk bijvoorbeeld). De interne IT afdeling was dan ook maar 2 man en zouden die ook geen eigen klanten hebben, had de interne IT makkelijk met zelfs 1 iemand af gekund. Daar werd echt totaal niet met ITIL gewerkt. Wel heel veel met DevSecOps en natuurlijk ook een boel in overleg met de klant. Daar ontzorgden we de klant dus voor zowel het beheer als ontwikkeling aan hun website en de benodigdheden daarvoor.

Interne ICT heeft altijd klanten: Je collega's en indirect, vaak, de eindklanten.

[...]
Veel toegevoegde waarde heeft het niet voor developers, ondanks dat ITIL an sich zeker wel nuttig kan zijn, maar het is afhankelijk van de grootte en de manier van werken in hoeverre ITIL echt toegevoegde waarde is binnen het bedrijf of de instelling. Bij het voorbeeld hierboven heeft het gewoon geen toegevoegde waarde. Toen ik bij de servicedesk van de Gemeente Utrecht werkte (~3500 medewerkers in totaal inclusief IT afdeling van ~100-150 medewerkers), was daar de introductie van ITIL (naar mijn mening) echt een grote stap voorwaarts destijds.

Zie boven. De enige fout die je echt nooit moet maken, is altijd en overal ITIL van A-Z implementeren. Zo is het niet bedoeld. Dan krijg je dat bij iedere standard change, je zelf alle stakeholders vertegenwoordig, je eigen CAB bent en letterlijk 6x je eigen change zit goed te keuren.

Dat ITIL meer een IT-Ops procesmethodiek is dan een dev procesmethodiek lijkt me evident. Dat dev andere methodieken nodig heeft voor hun day2day operatie lijkt me ook geen punt van discussie. Maar volgens mij was de vraag van OP of ITIL kennis nuttig en nodig is voor dev. Wat betreft Foundation denk ik dat het antwoord 100% "ja" is. De rest kan ik beperkt inschatten. (Ik doe ops dingen, geen dev dingen.)

[CH4OS]

unezra schreef op woensdag 13 oktober 2021 @ 13:01:
Ik denk dat het per-saldo, het nut niet eens heel veel uit maakt.
Ook in een kleine organisatie is Outlook als ticketsysteem onwerkbaar.

Dat je een ticketsysteem gebruikt betekend niet per definitie dat je bezig bent met ITIL.

Zie boven. De enige fout die je echt nooit moet maken, is altijd en overal ITIL van A-Z implementeren. Zo is het niet bedoeld. Dan krijg je dat bij iedere standard change, je zelf alle stakeholders vertegenwoordig, je eigen CAB bent en letterlijk 6x je eigen change zit goed te keuren.

ITIL implementeren om het implementeren van ITIL gaat nooit werken binnen een bedrijf of instelling. ITIL is ook enkel een leidraad en geeft hier en daar steekwoorden of (soort van) checklists en aandachtspunten.

Dat ITIL meer een IT-Ops procesmethodiek is dan een dev procesmethodiek lijkt me evident. Dat dev andere methodieken nodig heeft voor hun day2day operatie lijkt me ook geen punt van discussie. Maar volgens mij was de vraag van OP of ITIL kennis nuttig en nodig is voor dev. Wat betreft Foundation denk ik dat het antwoord 100% "ja" is. De rest kan ik beperkt inschatten. (Ik doe ops dingen, geen dev dingen.)

ITIL is meer een leidraad hoe samen te werken, hoe aan welke dingen te denken e.d. wanneer de IT afdeling meerdere grote afdelingen behelst. Dat is waar je ITIL gebruikt. Dat vervolgens de ene afdeling meer met Kanban werkt om tickets en verzoeken te verwerken en een ander met Scrum, dat is een keuze aan de afdeling.