Fileservers kunnen zeker zo gevaarlijk zijn. Wat begint als een eenvoudig middel om wat bestanden van gebruikers op te slaan in hun ‘home' directories kan maar zo uitgroeien tot een gemeenschappelijke opslagplaats van digitale derrie.
De hoeveelheid gegevens die we opslaan groeit enorm hard. Fileservers bieden geen enkel houvast voor het vastleggen en handhaven van regels over hoe lang iets bewaard moet worden, of juist wanneer het kan worden weggegooid. En met de hand opschonen van een fileserver is tegenwoordig ondoenlijk.
Van fileservers wordt regelmatig een backup gemaakt, als het goed is. Maar die backup wordt ook misbruikt als ‘time machine' om oude versies terug te halen. Dat dwingt de systeembeheerders om veel meer backups bij te houden dan nodig is voor ‘disaster recovery´.
Op een fileserver wordt het beheer van toegangsrechten op bestanden en mappen door systeembeheerders gedaan. Maar zijn dat werkelijk de mensen aan wie we de controle over de informatiehuishouding van een bedrijf willen toevertrouwen? Dat is net zo verstandig als je archiefbeheer toevertrouwen aan de verwarmingsmonteur, louter omdat dat archief in het ketelhok staat.
Voor het serieus beheren van grote hoeveelheden bedrijfskritische informatie zijn toch echt betere tools nodig. Maar met betere software alleen komen we er niet. Berucht zijn de intranetten, al dan niet met SharePoint gemaakt. Jan en alleman pleurt er zijn oude projectarchieven in, zodat men weer binnen zijn opslagquota blijft. Geen wonder dat die intranetten niet gebruikt worden, de lucht van beschimmelde oude bestanden is niet te harden!
Goed beheer gaat uit van het bedrijfsbelang van de gegevens, niet van het gemak voor gebruikers en systeembeheerders, anders maken we alleen maar nieuwe en grotere digitale afvoerputjes.
Reacties
Voor overheden en bedrijven is er zeker goede ondersteunende software voor het beheren van hun ongestructureerde bedrijsinformatie. (lees documentaire informatie huishouding).
De toezichthouder of raad van bestuur zou zich op de hoogte kunnen laten stellen door in de jaarlijkse accountant rapportage, een hoofdstuk te laten spenderen aan de stand van zaken binnen het bedrijf.
hoofdvragen kunnen zijn:
1. is er een regeling vastgesteld
2. is er op basis van de regeling kwaliteitszorg en onafhankelijk toezicht
3. Hoe is het gesteld met de ordening, authenticiteit, context,toegankelijkheid en duurzaamheid
4. Zijn er eisen gesteld aan digitaal archiefbeheer
5. is er een procedure vastgesteld voor vernietiging van informatie
6. Is er opslag van digitale informatie mogelijk voor de lange termijn (bv. meer als 10 jaar)
7. is er een rampen of calamiteiten plan
8. is de beveiliging (o.a. autorisatie) van bedrijfskritisch info georganiseerd
9. zijn er voldoende "middelen" voor bovenstaande in de begrotingen opgenomen.
10. ??
De vraag blijft wil een organisatie zich wel werpen op een bedrijfsonderdeel wat niet hun core business is.
Bedenk wel dat in de documentaire informatiehuishouding een groot deel van de bedrijfsrisico's verscholen zit. Terwijl de financiele bedrijfshuishouding alleen de cijfers weergeeft op basis van de documentaire besdrijfshuishouding.
Berucht zijn de onwetenden.
Zij die werken met computers maar er niets van snappen.
Ik hoop dat de schrijver enige kennis heeft van sharepoint, waarmee goede intranetten gebouwd kunnen worden. Maar mijn vrees is dat de schrijver er weinig van snapt. Niet nadenkt over sharepoint workflow, of over document tags etc. Maar ik vrees dat er meer Excel helden zijn dan mensen die iets snappen van SQL / sharepoint / access...
@Peter
Ik moet zeggen dat het concept van Sharepoint wel juist is, maar dat mijn praktijk ervaringen met Sharepoint ronduit frustrerend is. Zoeken op inhoud van documenten is bedroevend slecht (als al aanwezig) en de links die je zou kunnen rondsturen werken niet meer als het document wordt verplaatst. De responstijden zijn tranentrekkend, maar dat kan aan een astmatische file server liggen. Van de door jouw gesuggereerde workflow mogelijkheden in Sharepoint heb ik al helemaal nooit gehoord, maar dat kan gewoon liggen aan een gebrekkige implementatie (of een onvolledige, of een gemankeerde).
We moeten ook bedenken dat er meer systemen zijn die doen wat Sharepoint zegt te doen. Maar de ervaringen die ik tot nu toe met Sharepoint heb, zijn niet echt positief.
Mijn ervaring is wel dat een fileserver niets meer en niets minder is dan een extra harde schijf in het netwerk, waar iedereen zijn of haar bestanden op plaatst. Dat zo'n schijf in meerdere netwerk schijven is opgedeeld doet niet ter zake. Dat er toegangsrechten op de directories zietten om gebruikers nog enige privacy te geven, het zij zo.
Het meest opvallende is dat je er zo veel op kwijt kan... totdat de beheerder zegt dat de boel vol is en je moet gaan opruimen. Ga daar maar eens aan staan. Wat is echt oud en kan weg? Wat moet er beslist bewaard worden?
Hier ligt inderdaad het gevaar van de fileserver: geen enkel versiebeheer, geen enkele vorm van bescherming. Dat laatste werd onlangs duidelijk: een bestand met testgegevens werd, per ongeluk, door een nader overschreven door één enkel record. Weg aanpassingen van die dag. Back-up was nog niet gemaakt. Enige oplossing: diep zuchten en opnieuw beginnen (met als basis een oude versie, die er gelukkig nog wel was).
Als enige vorm van versiebeheer (of dat nou Sharepoint, PVCS of wat anders is) zou zijn gebruikt, dan was dat nooit gebeurd.
Hoe goed of slecht Sharepoint ook is (ik ga er vanuit dat bij volledig implementeren je er het beste uit kan halen), het ligt uiteindelijk bij de gebruiker hoe die er mee werkt en of alle functies juist gebruikt worden.
Ik ben het eens met CPT. Ik ben Sharepoint-beheerder bij een vrij grote organisatie en ik vind het een rampzalig pakket.
1. de zoekfunctie is niet goed, is toch elementair
2. een "alles in één" oplossing, en dus overal matig in. Plus: de simpelste dingen worden opeens erg ingewikkeld
niet goed in....
3. alles werkt met eigen Microsoft-logica. Als je kunt werken met een aantal DMS-en en CMS-en, dan kun je nog niks met Sharepoint, want die doet alles weer anders
4. Interface onlogisch en contra-intuitief
5. Traag
6. Ongeschikt voor snelle, sociale interactie, afstemming. Als een gebruiker geen rechten heeft, ziet hij content niet. Dat is op zich logisch en gewenst, maar niet als je kennis wilt delen en dwarsverbanden leggen.
7. Afhankelijk van de rest van de Microsoft-stack (de hele mikmak)
8. Duur
9. Toegang met een iPad, een Blackberry of een Android-tablet? Tweederangs-ervaring.....
Er is nog een overeenkomst tussen fileservers en spreadsheets: Sharepoint. Sharepoint raakt aan letterlijk ieder product, technologie of marktvraag waarvoor Microsoft zich in de afgelopen tien jaar gesteld heeft gezien. Het is als technologie-platform groter dan alle producten/technologiën bij elkaar, want het omvat alle producten. Je kunt er letterlijk hele boeken over schrijven.
Niet alleen door een zeer turbulente markt, maar ook door een historisch ontstane situatie, een hoop denkfouten en (on)welbegrepen eigenbelang is Sharepoint pas de laatste drie jaar qua productfilosifie in mijn ogen goed op het spoor. Het zelfherstellend vermogen van MS om er op termijn toch nog een succes van te maken is echt fenomenaal.
De schade voor de markt van de eerste vijf jaar is enorm (maar pakt zeker niet in alle opzichten ongunstig uit voor MS). Een deel kan het gevolg van kwade opzet zijn geweest, maar van mij krijgen ze nog steeds het voordeel van de twijfel. Als je ziet wat voor ongeleide projectielen andere organisaties zijn, is het nog steeds onvoorstelbaar hoe weinig schade ze veroorzaken in geïnvesteerde belangen van derden.
Je zou nog kunnen stellen dat de Business Solutions producten (CRM, Axapta, Navision e.a.) autonoom van Sharepoint bestaan, maar zelfs dat is voor discussie vatbaar.
Als je met batchfiles in een fileserver zou gaan werken als 'de nieuwste programmeertaal van Microsoft' zou je Windows Server ook maar een zeer matig product vinden.
Wat wordt het weer allemaal technisch aangevlogen. Het probleem uit zich in techniek, maar de oorzaak bevind zich elders. Net als een veelvoud aan bestanden, excel oplossingen en andere sateliet applicaties valt of staat de kracht ervan bij de organisatie zelf. Dit is ook 1 van de redenen waarom IT projecten vaak falen, omdat ze als IT projecten gezien worden en dus bij IT terecht komen.
Door met goede richtlijnen te komen hoe om te gaan met bestanden, mappen en rechten en een beeld te schetsen hoe de organisatie werkt (welke afdelingen, welke overlap) kan een manier van werken worden afgesproken. Deze is zinloos als niemand er voor verantwoordelijk is. Verantwoordelijken moeten goed begeleid worden in het signaleren, handhaven en ingrijpen.
Het ontstaan van Excel applicaties kan alleen gebeuren als de organisatie het toestaat of er niet bewust van is.
In alle gevallen heeft te maken met leiding geven, heldere visie en discipline van de "sleutel" figuren.
Als aanvulling kun je een kwartaal iteratie maken waarin extra kritisch gekeken wordt en geschoond. Los van de fileserver of het gebruik van andere tools zoals sharepoint.
The most popular software for writing fiction isn't Word. It's Excel.— Brian Alvey.
Dit hele verhaal kun je nog veel verder doortrekken dan alleen documentatie. Wat te denken van broncode van je applicaties.
Ook daar wil je graag versiebeheer op kunnen doen, zodat je bijvoorbeeld een roll-back kunt doen naar een vorige versie mocht de nieuwe niet meer werken, of om een oude testcase te reproduceren die nu ineens niet meer werkt. Hiervoor zijn diverse pakketten op de markt, variërend van simpel en/of open source (CVS, GIT) tot geavanceerd en closed source (ClearCase, CM Synergy)
Dit voor released producten, hier zijn diverse application lifecycle management (ALM) applicaties voor op de markt.
Maar waarom gaan we dan voor documenten het wiel opnieuw uitvinden en proberen versiebeheer te doen met fileservers of sharepoint servers ?
Versiebeheer \ configuration management is in een aantal bedrijven een volwaardige discipline, in tegenstelling tot de gekunstelde (of moet ik zeggen "geknutselde") omgevingen zoals geschetst worden in het artikel, dus waarom het wiel opnieuw uitvinden?
@hkoppen: ik ben het niet met je eens. Je faciliteert mensen ook met zoiets als een technisch aangevlogen spoortrein-infrastructuur. Daarbij wil je toch ook niet dat de conducteur vraagt waar de reis heen gaat en dat - bij een goed georganiseerde familie - het helemaal niet nodig was geweest dat je moeder 100 km van je vandaan woont? Er zullen indertijd ongetwijfeld goede redenen of andere prioriteiten zijn geweest en zelfs emotionele redenen kunnen een rol spelen bij het in stand blijven ervan.
Je probeert gebruikers/organisaties te faciliteren met universeel inzetbare oplossingen waarbij je uiteraard wel probeert mee te denken over de optimale inzetbaarheid ervan (dus ook oneigenlijk gebruik ontmoedigt). Maar dat laatste is zeker niet de expertise van de faciliteerder.
@PaVaKe: ALM zou m.i. volledig ingebed moeten zijn in de ontwikkelomgeving i.v.m. version building, automated testing, scheiding presentatie/designers, business code developers, integratie projectmanagement, etc. Maar dat lijkt me toch een heel andere tak van sport dan lifecycle management van bedrijfsdocumenten.
@Rob Koelmans
Da's net hoe je het bekijkt. Ook op bedrijfsdocumenten kun je een vorm van lifecyclemanagement toepassen. Zo is het bijvoorbeeld wel praktisch als je allen over dezelfde versie van de begroting beschikt.
Ook als je vanuit een beleidsplan naar een strategisch document verwijst, kan het praktisch zijn te verwijzen naar een specifieke revisie; dit om misverstanden te voorkomen.
Configuratie management is wijder verbreidt dan je denkt, alleen noemen we het niet altijd zo.
@PaVaKe: Ik ben het absoluut met je eens dat op ieder type document lifecycle management toegepast moet kunnen worden. Maar ik denk dat source code nog een reeks extra eisen stelt die bij andere documenttypen niet van toepassing is.
Dit riekt naar een probleem aanmaken, dan dat er echt een probleem is. Quota op persoonlijke, groeps- en sharepointdirectories daar begint het mee. Mailarchieven op goedkopere servers laten landen. Standaard PDF opslaan-opties aanbieden ipv dure/grote Office-bestanden. Beperken grafische bestanden (JPG ipv screendumps in BMP bijlages).
Begin bij het einde: men slaat zoveel op omdat het kan. Geef je een goed doch redelijk quotum dan gaat men vanzelf opschonen. Altijd uit noodzaak, niet omdat men het zo graag wil ;)