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

Verhuizen van ICT levert vaak hoofdpijn op

Ik heb het zelf weer aan den lijve ondervonden. Verhuizen is geen prettige aangelegenheid. Het levert veel stress op, vreet energie en kost vaak meer geld dan van te voren ingecalculeerd. Hoewel ik refereer aan een verhuizing in de privésfeer zijn er toch meer gelijkenissen met een ICT- verhuizing dan je vooraf misschien denkt. Onderstaand enkele tips die kunnen bijdragen aan het succes van een verhuizing. Onderwerp van de verhuizing is een storage omgeving, inclusief de bijbehorende servers en applicaties van een middelgrote organisatie.

Zonder een heldere scope is een verhuizing gedoemd te mislukken. Het moet vooraf goed duidelijk zijn wie, wat, waar, waarom, wanneer en hoe? Inventarisatie is de eerster stap. Wat moet er allemaal verhuisd worden? Waar staat het en wie is er verantwoordelijk voor?  Dat zijn vragen die vooraf beantwoord moeten worden. Dit proces wordt vaak nog handmatig uitgevoerd. Op zich niets mis mee. Maar bij grote omgevingen ondoenlijk en tijdrovend. Ook is bij een handmatige inventarisatie de kans op het maken van fouten groter. Dus probeer hier slim mee om te gaan en maak gebruik van tooling en CMDB’s ( mits up to date ).

Hier gaat het echter meestal fout. Er is vaak wel netjes geïnventariseerd wie, wat, waar en wanneer, maar de onderlinge relaties en afhankelijkheden zijn nog wel eens onduidelijk.  Levensgevaarlijk natuurlijk. Want hoe kun je iets verhuizen als je niet weet wie en wat er allemaal bij elkaar hoort? 

Het is daarom van groot belang om de onderlinge relatie en afhankelijkheden vooraf in kaart te brengen. Welke processen maken gebruik van de bedrijfskritische applicatie? Hoe zijn deze opgebouwd? Wat zijn de afhankelijkheden? Wat is hier voor benodigd? Welke servers en services maken hier gebruik van? Zo kan ik nog wel tig vragen bedenken. Breng deze relaties en afhankelijkheden goed in kaart. Definieer 'move-groups' of 'workloads'. Je ontkomt er gewoon niet aan en je kunt geen zaken los en apart  migreren.

Planning en kosten

Zodra de scope en afhankelijkheden geïnventariseerd en vastgesteld zijn kun je beginnen met het opstellen van de planning en het daarbij horende kostenplaatje. Wees niet te ambitieus en plan niet te strak. Hier zie ik het tijdens verhuizingen nog wel eens mis gaan. Natuurlijk snapt iedereen dat je de verhuizing zo snel mogelijk achter de rug wilt hebben maar dit moet niet ten koste gaan van alles.  Een te strakke planning levert uiteindelijk alleen maar veel stress, discussie en frustratie op.

Definieer vooraf per fase de kosten. Vergeet hier niet mogelijke aanpassingen op het gebied van hardware, software, netwerk en mensen in op te nemen. En blijf dit dagelijks bewaken. Uit  ervaring blijkt dat een verhuizing vaak meer kosten met zich mee brengt dan vooraf verwacht. Laat dit kostenplaatje daarom  altijd door een ervaren verhuizer dubbelchecken.

Infrastructuurproblemen

Ook een heikel punt zijn de infrastructuurproblemen. Apparatuur die al een aantal jaar onafgebroken staat te draaien kan soms moeilijk worden aan- en uitgezet. Ook is deze apparatuur over het algemeen wat kwetsbaarder. Het is daarom zaak om voorafgaand aan de verhuizing een goede back-up van de data te hebben. Definieer ook een fail/roll-back scenario.  Alleen met een goede back-up ben je er nog niet. Het aanwezig hebben van spare en swing apparatuur is ook cruciaal.  Alles wat draait kan een keer stuk gaan dus het is geen overbodige luxe om wat op de plank te hebben liggen of stand-by te hebben staan.

Netwerkverbindingen en andere problematiek

Het fysiek verhuizen van ict-omgevingen heeft nogal wat impact op de netwerkinfrastructuur. Denk hierbij aan netwerk- en internetverbindingen en connectiviteit, DNS, ip,wan, vpn’s en dergelijke. Tijdens de inventarisatiefase moet dit ook goed in kaart gebracht worden. Helaas wordt dit nog wel eens vergeten. Met alle gevolgen van dien.

Bij een verhuizing komt het geregeld voor dat er ook zaken gemigreerd dienen te worden. Dit maakt het vaak nog complexer. Dus probeer het aantal migraties te beperken. Vaak ontkom je er niet aan omdat apparatuur fysiek vervangen dient te worden. Mijn ervaring is dat je beter vooraf aan de verhuizing kan migreren dan tijdens..

Kennis, ervaring en documentatie

Zorg dat er voldoende kennis en ervaring op het gebied van verhuizingen aanwezig is. Is dit nieuw voor de organisatie huur dit dan in. Want verhuizen is en blijft een vak apart.  En al doende leert men. Dergelijke kennis kan worden ingehuurd bij ict-partijen (intergrators ) die hier in gespecialiseerd zijn.

Verhuizen is de ultieme manier van het testen van je documentatie. Mijn ervaring is dat de kwaliteit en actualiteit  van de documentatie nog wel eens te wensen over laat. En veel kennis nog bij de mensen zelf aanwezig is en niet op papier staat. Hoe voorkom je dit? Definieer een aantal testen. Welke functionaliteiten moeten het doen? Wat zijn onze eisen op basis van performance? Hoe zet ik data terug? En documenteer deze testen vooraf kort en bondig. Te veel informatie zorgt nu eenmaal voor verwarring. Goede en bijgewerkte documentatie is cruciaal bij een verhuizing. Niet alleen vooraf maar ook achteraf. Documenteer ook goed waarom er bepaalde beslissingen gemaakt zijn.

Testen- Fallback scenario

Zorgen

Na iedere stap in je verhuisplan dient er getest te worden. Is alle functionaliteit nog aanwezig? Werkt dit hetzelfde als voor de verhuizing? Dit zijn de twee belangrijkste vragen die je je als projectteam dient af te vragen.  Het is daarom zaak om vooraf een goed, duidelijk en functioneel testplan op te stellen. Ook is het van cruciaal belang een fall-back plan/scenario hier in op te nemen. Ervaring leert dat het bij verhuizingen nog wel anders loopt dan als vooraf verwacht. Vaak zie je dan dat er keihard gewerkt wordt om het alsnog voor elkaar te krijgen. Belangrijk daarin is om goed de energie, tijd en kosten van deze inspanning in beeld te houden. En dit wordt juist dan nog wel eens vergeten. Natuurlijk is het van belang om het weer aan de praat te krijgen maar niet tegen alle kosten. Soms is het gemakkelijker en effectiever om gebruik te maken van het fall-back-scenario.

Verhuizen blijft zoals ik al eerder aangaf, een vak apart. Ik ben daarom erg benieuwd naar jullie ervaringen, tips en trucs op het gebied van verhuizen.

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

 

Reacties

@Ruud,

zoals gebruikelijk van je een goed en helder verhaal.

Maar netwerktechnsich zijn verhuizingen, wanneer alles op een cleane manier op basis van IP is ingericht relatief veel makkelijker dan " vroeger", toe er nog "dedicated" netwerken waren. Blijft onverlet dat effectief verhuizen je niet uit een boekje (oeps wat schrijf ik nu toch) leert en dat daar inderdaad veel kennis en ervaring voor nodig is.

Ruud,
De benoemde zaken zijn terecht en zeker al bekend bij een projectleider die een beetje kennis heeft met transitietrajecten.
Misschien twee aanvulling en aandachtspunten:

1- Je kunt beter eerst je huidige omgeving opruimen, consolideren en daar waar het mogelijk is moderniseren. Hoe minder objecten, hoe minder verwevenheden en relaties, hoe minder ouderdom binnen je omgeving hoe veiliger je transitie.

2- Het wordt een uitdaging als je de zaak van een leverancier naar andere gaat overbrengen. Je komt waarschijnlijk in een tussenfase terecht waarin je een deel van je spullen in het nieuwe en andere deel nog in het oude datacenter hebt staan, dit terwijl de business van de klant door moet gaan. De leverancier waar je van afscheid neemt voelt zich niet meer verantwoordelijk voor de klant die weggaat. Hij stelt zijn resources niet makkelijk beschikbaar om deze transitie snel af te ronden want zijn trouwe klanten zijn belangrijker voor hem dan een overloper. Besteedt veel tijd en aandacht aan je huidige leverancier en probeer hem ergens tegemoet te komen.

Maarten,

Thanks voor je toevoeging. Ik deel je mening dat het vroeger netwerktechnisch gezien wat uitdagender was. Toch is het nu nog steeds belangrijk om je huiswerk vooraf goed te doen en de afhankelijkheden goed in kaart te brengen.

Nog te vaak worden IP omnummeringen, DNS aanpassingen en allerei andere zaken vergeten. Ook zie ik nog wel eens dat er te weinig geld wordt uitgegeven aan degelijke verbindingen ( lees bandbreedte ) met alle gevolgen van dien. Je moet er niet aan denken dat je tijdens een data migratie beperkte bandbreedte tot je beschikking hebt. Maar daar heb ik al eerder wat over geroepen in een artikel ( Bandbreedte is nog steeds een ondergeschoven kindje ).

En ik ben heel benieuwd naar je boek. Dus ik hou me aanbevolen :-)

@ Reza,

Helemaal eens en bedankt voor je reactie. Helaas heeft niet iedere projectleider de ervaring en kennis/kunde om hier vooraf goed over na te denken. Je verhuist namelijk niet ieder jaar. Tenminste laten we hopen van niet. Ik weet wel 1 ding. Ik doe het zelf nooit meer. Prive gezien dan :-)

1. Eens. Probeer alle kinderziektes vooraf te adresseren en waarbij mogelijk op te lossen. Doe je dit niet dan levert dit tijdens de verhuizing cq. migratie alleen maar problemen en vertragingen op.

2. Zeer herkenbaar in Cloud of Hosting scenario's. Afscheid nemen doet nu eenmaal pijn en niet iedereen gaat daar even proffesioneel mee om.

Ruud,

Leuk stukje.
Mijn ervaring is dat het definieren van zo'n move-group een lastige, maar crusiale rol is bij het verhuizen van een grote organisatie. Het lastige is vaak dat alles aan alles hangt en er weinig splitsing te maken valt.
In de projecten die ik heb meegemaakt ging dit pas werken als de business werd betrokken en de verhuizing gedaan werd in business ketens. Op deze manier werd het risico duidelijk in kaart gebracht en konden de acceptatietesten ook op de juiste manier worden uitgevoerd

Maarten,

Kleine toevoeging nog. IP is nu gemakkelijker te verhuizen. Maar SAN verhuizingen leveren nog wel eens wat onvoorziene uitdagingen op.

Netwerk is natuurlijk meer dan IP.

Goed artikel Ruud en goede aanvulling van Reza. Vooraf puin ruimen, migraties doen en waar nodig consolideren, bespaart tijd en ruimte.
Soms wordt geconstateerd dat een server vervangen moet worden. Juist dan is de verhuizing ideaal. De nieuwe omgeving kan op het nieuwe adres geinstalleerd worden, met alle bestaande applicaties erop kan er rustig getest worden of alles werkt. Is alle ok, dan kan de oude machine op het oude adres achter blijven of ergens anders ingezet worden als backup/uitwijk systeem.

Hi Ruud,

Net als thuis je kunt zelf een busje huren en je vrienden of familie inschakelen. Ja, het is goedkoper dan een verhuizer inhuren maar meestal niet verstandiger. Een verhuizing zelf doen zal niet de eerste vriendschap kosten. Dus wees na je studententijd verstandig en laat je verhuizen door een verhuisbedrijf.

Goed advies van je dus om kennis en ervaring in te huren bij je leverancier of bij gespecialiseerde bedrijven. Alleen al het fysiek verplaatsen van de apparatuur is een vak apart laat staan de rest. Als je je leverancier in de arm neemt heeft deze meestal ook handige tools of tijdelijke systemen beschikbaar om de verhuizing soepel te laten verlopen.

Remko

@ Remco,

Bedankt voor je reactie. Je maakt meestal de fout van het zelf verhuizen maar 1x.

Je toevoeging van tijdelijke systemen is een zeer bruikbare. Servers, switches, disken gaan nog wel eens stuk dus wat extra spare/swing capacity is geen overbodige luxe. Zeker omdat de MTBF van hardware aanzienlijk afneemt tijdens verhuizingen.

@ Ruud,

zeker er is nog werk te doen, maar wat dacht je er van om een dedicated netwerk te verhuizen.... dan snak je naar een IP omgeving, ook al is die nog zo beroerd geconfigureerd. :-)

Als we de inrichting voor een compleet kantoor moeten verhuizen, doen we dat niet zelf, maar laten we er een gespecialiseerd bedrijf voor komen
Ook voor particulieren bestaat de mogelijkheid om je hele verhuizing uit te besteden.
Waarom zou je dat niet doen voor je ICT?

Ik heb meerdere verhuizingen van mainframe omgevingen gedaan in het verleden. Als datacentrum hadden we een team welke zich daar mee bezig hield. Al doende leert men, en met de ervaring van dit team zijn de verhuizingen die ik heb mee mogen maken eigenlijk heel soepel verlopen. Eén van de grootste uitdagingen was meestal de logistiek, zeker als je een vrachtwagen met tapes en/of hardware in een weekend door Duitsland of Frankrijk wil laten rijden.

Privé verhuizingen doe je doorgaans te weinig om er geroutineerd in te geraken. Hetzelfde geldt voor verhuizen van bedrijven inclusief infrastructuur. Wellicht een gat in de markt?

Maar ... deels off topic: het valt me op dat ik nog geen cloud-fanaten heb zien reageren. Immers, als je alles in de cloud host, kun je toch zorgenloos verhuizen?


@PaVaKe:

Mooie opmerking over cloud! Houd ik mijn mond erover dan begin jij :-)
Er zijn mensen die alle artikelen op deze site aan (de voordelen van)cloud knopen. Ben benieuwd of dat ze ook gaan doen voor de verhuizing!

Ruud,

Helemaal mee eens en zeker het gedeelte van documentatie.
Zelf heb ik veel bedrijven begeleid met verhuizen van hun SAN en alleen al de basis vraag hoe log je in met welk ip en welk wachtwoord krijg je als antwoord: ja dat weten we niet we komen er nooit op, dit was altijd de taak van Jan maar deze is al een tijdje weg bij ons.
Maak zeker voordat je gaat verhuizen altijd je documentatie up to date en kijk fysiek ook of het klopt en eigenlijk niet alleen bij een verhuizing, van tijd tot tijd bijhouden is een must.

@ Pavake,

Verhuizen in of naar de Cloud levert in mijn ogen bijna dezelfde uitdagingen. Maar dat raken we weer aardig off topic.

@ Frank,

Bedankt voor je reactie. De voorbeelden die je aanhaalt zijn pijnlijk en herkenbaar. Zeker de menselijke factor in het geheel wordt nog wel eens vergeten. Cruciale zaken zijn vaak niet (goed) gedocumenteerd. En zoals je al aangeeft is het up to date houden van kennis en documentatie cruciaal.

Cloud. mmm, daar wordt dus te weinig over gezegd :)

Verhuizen naar de Cloud is niet veel anders dan verhuizen tussen eigen DC's of DC's van klassieke hosters of outsourcers.

Wat wel anders is dat je niet je volledige IT ecosysteem zult verhuizen naar 1 enkele cloud. Je wilt cloud op maat toepassen en brengt je systemen dus onder in de omgeving die het best past.

De hybride omgeving die je zo creeerd geeft, ook rond verhuizingen, zijn eigen uitdagingen. Eerst moet je helder krijgen wat je waar heen wilt brengen, je moet inregelen dat systemen waar nodig nog steeds met elkaar kunnen communiceren en je moet je spullen zo in de cloud plaatsen dat je het er ook weer uit kunt halen.

ok..., misschien wel een leuk onderwerp om ook eens een stukkie over te schrijven.

Reza geeft in zijn eerste reactie aan waarom verhuizingen in de cloud een uitdaging is (punt 2). Maar je hebt ook varianten van on-premise naar de cloud, of terug. Maar dit zijn in feite migratie trajecten. En vallen niet zozeer onder een verhuizing, maar een onderdeel van een exit strategie.

Een groot verschil van het verhuizen van IT en van je huis vind ik dat een verhuizer wel verstand heeft van verhuizen en jijzelf vaak (als bedrijf) niet.

Het verhuizen van IT is echter moeilijker uit te besteden anders dan het fysieke vervoer.

Maar wat betreft het "cloud" inkoppertje, ik hield wijselijk mijn mond :-)


Ruud,

Als gebruikelijk weer een goed artikel,allemaal bruikbare tips en met de extra tips van Reza een compleet verhaal.

En nog een kleine tip, doe de verhuizing in een weekend of in ieder geval op een tijdstip dat je rek hebt om de boel weer op te krijgen. Niet nadat je je hebt voorbereid natuurlijk zodat je weet wat je kunt verwachten. Verhuizen van bestaande applicaties/functionaliteit naar een externe cloud lijkt me een project apart en in het geheel niet triviaal. Buiten de vraag of je dat wil.

@ Boris,

Goede toevoeging. Op dat punt gaat het nog te vaak fout.

@ Guido/Henri,

Ik denk dat de Move to/from the Cloud discussie genoeg discussie oplevert om in een vervolg artikel verder op in te haken.

@ Arthur,

Goede toevoeging. Een green field opbouwen naast je bestaande omgeving heeft veel voordelen. Echter kost dit meer tijd en vaak is de tijdsdruk tijdens verhuizingen/migraties hoog. Maar nogmaals absoluut een zeer bruikbare tip.

@ Ron,

Thnx voor je positieve feedback.

@ Wim,

Timing is cruciaal en het verhuizen van bedrijfskritische zaken gebeurt zoals je al aangeeft vaak in het weekend. Echter zijn er ook genoeg organisaties die ook in het weekend open zijn. Dus het maintenance/move window wordt tegenwoordig steeds beperkter.

@Wim: de grote mainframe verhuizingen deden we altijd in paas- of pinksterweekenden; simpelweg omdat je dan 3 dagen hebt. Kan je net dat beetje extra ademruimte geven.

@ Pavake,

Dit is natuurlijk een goede optie. En geeft wat meer tijd en lucht.

Ook kerst is hier een goede optie voor.

Ruud,

Een leuk stuk waar je het vooral hebt over de uitvoering maar de reden van verhuizing achterwege laat. Verhuizen om het verhuizen is tenslotte een zinloze bezigheid, kost tijd en levert vaak weinig plezier op. Dit geldt ook voor de IT waar soms verhuisd moet worden door reorganisatie, door een te klein of tegenwoordig ook vaak te groot datacenter maar waar de reden niet altijd gecommuniceerd wordt naar de business. En deze blijft vaak niet alleen onveranderlijk zitten maar verwacht voor, tijdens en na de transitie ook gewoon dezelfde service. Hierdoor wordt het achterhalen van eigenaarschap van data, systemen en applicaties soms bemoeilijkt omdat de gebruikers de reden voor het verstrekken van de informatie dus niet zien.

Dat in tegenstelling tot een privé verhuizing waarbij iedereen van het gezin zich vaak ook een beetje verheugd op het nieuwe huis, de nieuwe omgeving en alle andere spannende dingen die erbij komen kijken. Daardoor is de wil om op te ruimen van wat niet meer gebruikt wordt of past dus ook groter om zodoende te voorkomen dat je de dozen van zolder naar zolder verhuisd. Vergelijkend met de verhuizingen die ik prive zelf gedaan heb, van kleiner maar dichter bij het werk naar weer groter, is een service als Shurgard trouwens best wel handig. Het geeft namelijk een keus tussen behouden en afstoten wanneer je bijvoorbeeld die dingen die je niet dagelijks gebruikt, zoals allerlei seizoensgebonden kleding, (sport)artikelen en vele andere dingen, op deze manier opslaat. Als je goed bijhoudt wat waar is opgeslagen en je de opslag handig inricht zodat je niet alles onderste boven hoeft te halen als je voor een week je ski's of schaatsen nodig hebt is het een win-win situatie. En de dingen die uiteindelijk helemaal niet meer gebruikt worden omdat ze bijvoorbeeld niet meer passen, iets wat nog weleens gebeurt met snel opgroeiende kinderen, kunnen altijd nog op Marktplaats gezet worden.

Om ontopic te blijven zie je in de ICT ook de lifecycle van baby tot bejaarden waarbij mijn ervaring leert dat sommigen nimmer afscheid kunnen nemen van hun 'kindje' en je dus lastige situaties krijgt. Bijvoorbeeld wanneer de voortschrijdende ontwikkeling van techniek geen gelijke tred houdt met applicaties of processen en waarover ik in een eerdere opinie: "Oud maar nog niet vervangen" ook al iets schrijf. Vooral de onopgeloste problemen met applicaties zorgen bij een verhuizing dan ook voor hoofdpijn, zeker als je de infrastructuur gelijktijdig wilt moderniseren, consolideren en rationaliseren want afhankelijkheden zitten er op alle lagen van de infrastructuur. Niet alleen in onderlinge communicatie, waarbij sommige applicaties trouwens 'hardcoded' adressen gebruiken waardoor omnummering van IP's of veranderen van MAC-adres voor verrassingen zorgt. Bij een verhuizing kom je ze dan ook altijd weer tegen, de (besturing)systemen en oplossingen die al lang niet meer ondersteund worden maar niet uitgezet kunnen worden.

Omdat een datacenter verhuizing vaak gedaan wordt vanuit een economisch perspectief, IT operations moet vooral goedkoper, zijn het deze 'constraints' die altijd weer voor hoofdpijn zorgen. Zoals dat er een dure vleugel verhuisd moet worden waar dochterlief nauwelijks op speelt en dus eigenlijk net zo goed door een handzamer en goedkopere digitale piano vervangen kan worden maar het gevoel uiteindelijk bepalend is. Om dus terug te komen op mijn eerste zin, vergeet niet om de business te betrekken bij een verhuizing als je meerdere doelen hebt binnen deze exercitie. Het kostenplaatje moet dus niet alleen gaan om de verplaatsing maar vooral om de verbetering die echter soms ook nog weleens tegen kan vallen voor de gebruiker wanneer data en systemen op afstand geplaatst worden.

@ Ewout,

Zoals gewoonlijk weer een goede reactie van je. Waar voor dank. Je hebt helemaal gelijk dat verhuizingen politiek gevoelig liggen en vaak ook nog eens emotioneel beladen zijn.

Ik sluit mij aan dat een verhuizing ook iets moet opleveren. Vaak wordt er alleen naar de kosten op de kortere termijn gekeken. En dit levert op langere termijn soms een teleurstelling op.

Eerst alles naar de Cloud verhuizen, dan kun je daarna doen wat je wilt!

Jeffrey,

Bij een verhuizing naar de cloud kom je ook nog veel van de eerder genoemde uitdagingen tegen. En een verhuizing uit de cloud is ook erg tijdrovend aangezien je dan afhankelijk bent van de desbetreffende cloud leverancier en technologieen die hier achter hangen.

In mijn ogen is cloud hier niet het ultimie wondermiddeltje voor. Hoe je went of keert blijft verhuizen altijd lasting.

Ik heb zelf in dit soort trajecten gezeten en herken de meeste zaken. Een onderwerp dat niet wordt aangesneden is het moeten maken van verbeteringen die nodig zijn omdat de situatie anders is. Een voorbeeld is bijvoorbeeld een datacenter waar men vroeger naar toe kon lopen, maar nu op 500 kilometer afstand is. Dit is een trigger voor verbeteringen te maken. Hoe gaat men om met spare-parts? Er zijn ook technologische verbeteringen te maken. Zo hebben wij indertijd wat configuratie veranderingen op Active Directory, Antivirus distributie en het patch-management proces moeten maken om de verhuizing tot een succes te maken. Kortom dit is een behoorlijk complex traject, maar niet ondoenlijk zolang iedereen dezelfde focus heeft.

@ Ruud,

Je haalt een goed punt aan. Waar voor dank!

Spare-parts zijn vaak wel via je leverancier/hardware vendor in te regelen. Maar vaak is het goedkoper om zelf wat spullenboel op de plank te hebben.

@ Ruud M.
als je ze toch op de plank hebt liggen zou ik ze actief opslaan, met andere woorden er een redundant systeem van maken. Spullen die "passief" op de plank liggen zijn stuk op het moment dat je ze activeert, dus wanneer je er spanning op zet.

Maarten,

Dit is afhankelijk van de apparatuur. Maar in veel gevallen gaat dit natuurlijk op. Het is sowieso zaak om de apparatuur zo nu en dan te testen als je er voor kiest om het niet actief in te zetten.

Hoi Ruud,

Vergeet tijdens de verhuizing niet om een goede transport en montage verzekering af te sluiten. Dit geeft dekking tegen fysieke schade. Als de te verhuizen apparatuur bij in onderhoud is, controleer dan of het onderhoudscontract dekking geeft indien er niet zichtbare schade ontstaat. Vaak maakt dit geen onderdeel uit van zo'n overeenkomst. Veel partijen zijn wel bereid om dit risico tegen een bepaalde vergoeding voor hun rekening te nemen. Verder ben ik het met Remko eens dat het transport uitgevoerd moet worden door een gespecialiseerd bedrijf welke beschikt over de juiste hulpmiddelen, en verhuiswagens welke zijn voorzien van luchtvering om schade zo veel mogelijk te beperken.

Hallo Heren,

Ik ben zelf een verhuizer, een opgeleid ict/project/cablemanagement verhuizer. en ik kan zeggen uit ervaring. huur vanaf het moment dat er besloten is dat een (groot)kantoor gaat verhuizen een verhuisbedrijf in. laat het verhuisbedrijf ook alles inventariseren. klinkt misschien raar maar het scheelt zoveel tijd. ik inventariseer zelf namelijk ook bij kantoren. en niet om op te scheppen wij als verhuizer zijn daar toch een stuk beter in.

aan de hand van de inventarisatie word een lijst gemaakt en we volgen op de dagen van de verhuizing echt alleen de lijst. en als er toch nog wat bijkomt zeggen wij dat komt na de verhuizing omdat zulke dingen vaak veel te veel tijd kosten. en na een grootte verhuizing is er meestal toch wel 'nazorg' zoals wij dat noemen.

en nog even over dat in het weekend werken. verhuizers zijn daar niet blij mee, (met uitzondering van de jeugd die geen vrouw en kinderen heeft) omdat wij als verhuizer vaak toch als 50-60 uur in de week werken en moeten dan ook nog ons vrije weekend op offeren omdat er weer een bedrijf is die perse in het weekend wil.

Maar 1 voordeel van de verhuizing op zaterdag is dat het bedrijf wat verhuist 50% meer loon moet betalen voor de personen die werken. en ik krijg ook 50% meer.

Ruud,

Mooi artikel, wat mij betreft kan er niet genoeg informatie gedeeld worden over ICT-verhuizingen. Als projectleider ICT Verhuizingen of projectmanager ICT Verhuizingen kom ik er toch altijd weer achter dat je van werkelijk alle markten thuis moet zijn en veel diverse en diepgaande kennis nodig hebt om na een ICT verhuizing een werkbare situatie gecreeerd te hebben.

Zelf heb ik aan 27 ICT-verhuizingen gewerkt en werk nu weer aan de planvorming rond de volgende 3 grote verhuizingen bij diverse ministeries (5200 man).

Tegenwoordig hou ik er een blog over de ICT verhuizingen bij, dit om zoveel mogelijk kennis te delen.


Pieter Nierop
Projectmanager ICT Verhuizing


Blog:
ICT Verhuizing
http://www.ictverhuizing.blogspot.nl/

Christiaan,

Helaas zijn weekendacties vaak onoverkomelijk.

@ Pieter,

Dank voor je reactie. Ik ga zeker een blik op je blog werpen.

Computable Expert
Ruud  Mulder

Ruud Mulder
Senior Systems Engineer, Dell EMC. Expert van Computable voor de topics Cloud Computing, Infrastructuur en Loopbaan.
Hele profiel

Lees meer over:
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

×
×