NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Binnen mijn organisatie wordt steeds meer gebruik gemaakt van de e-mail. Op dit moment zijn we druk bezig om dit goed te organiseren omdat sommige e-mail berichten natuurlijk geregistreerd moeten worden in ons DMS systeem.
Hierbij vraag ik mij af of je de bijlage, die bij een e-mail mee wordt gestuurd, apart moet opslaan / los van de e-mail. De bijlage wordt dan wel onder hetzelfde registratienummer opgeslagen maar als een los document. De e-mail en de bijlage zijn immers afzonderlijke documenten.
Ik ben benieuwd naar jullie meningen / ervaringen.
Tags:
Hallo,
We hebben een standaard product welke de mogelijkheid biedt om middels classificatie inkomende- en uitgaande en interne mailberichten inclusief bijlage(-n) automatisch te integreren met een DMS/CMS en/of primair proces.
Indien interesse dan hoor ik het graag.
Groet,
Fred
Ha Fred,
Dankjewel voor je reactie. We zijn nog niet zover dat we voor het opslaan van email op zoek zijn naar een product hiervoor. We willen eerst kijken hoe we dit met de tools welke we al in huis hebben kunnen regelen.
Alleen vraag ik mij hierin dus af of je de bijlagen van een email los van de mail moet opslaan?
Groet, Pauline
Hallo Pauline,
Bedankt voor je antwoord.
Op 23 maart a.s. organiseren we weer inloopsessies met als onderwerp "Mail-integratie met een DMS/CMSen of primair proces"; interessant om bij te wonen.
Tijdens deze inloopsessie zal je vraag ook beantwoord worden betreffende het opslaan van bijlagen en mail in het algemeen.
Alvast een prettig weekend,
groet,
Fred
Hi Pauline,
Gelukkig ben je niet alleen in je worsteling met de registratie en archivering van e-mailberichten! Het is eigenlijk vrijwel overal een drama. En het handmatig toevoegen (door DIV of door de eindgebruiker) aan een document management systeem gebeurt meestal niet consequent. Hoe goed je als DIVer ook je organisatie van dienst wil zijn.
Je laatste opmerking begrijp ik eigenlijk niet zo. Inderdaad horen ze bij één en dezelfde registratie. En vaak zijn het verschillende bestandsformaten zodat je toch al gedwongen wordt om ze apart op te slaan. Sommige document management systemen kunnen de e-mail zowiezo alleen als tekst opnemen in een tekstveld. Ik zie niet zo snel gebeuren dat het als één document kan worden opgeslagen, zoals bijvoorbeeld bij scannen een brief met bijlage als één PDF bestand wordt gescand. Tenzij jullie emails eerst (laten) printen en vervolgens scannen. Archivistisch is dat een minder goede oplossing. Door de vervanging naar papier en digitaal gaat immers informatie verloren.
Afhankelijk van het soort organisatie (overheid of niet, omvang, digitaal verkeer) zijn er verschillende archiveringsstrategieën denkbaar voor email. Handmatige classificatie door DIV vind ik een mooi streven maar lijkt me gezien de omvang en de afhankelijkheid van de discipline in de organisatie om de berichten aan te bieden, de meest risicovolle optie. Handmatige classificatie door eindgebruikers, door middel van drag-and-drop maakt de drempel lager om te archiveren, maar er zijn ook andere meer geautomatiseerde methoden denkbaar (zoals die hieronder, verwoord door Fred Titaley).
In een cursus voor GO-Opleidingenga ik in op de verschillende strategieën voor emailarchivering. Ik heb daar ook een stukje over geschreven: 'E-mail archiveren: geen verloren strijd'.
Succes gewenst!
Het registreren en archiveren kan op diverse manieren.
Het meest gewenste is om dit in een DMS/RMA te doen.
Wij maken bijd e gemeente gebruik van Decos en daarin is outlook geintegreerd met Decos,w aardoor vanuit decos een document kan worden geregistreerd in ons DMS/RMA. Hierbij worden de bijlagen mee opgeslagen.
Ik ben er inmiddels achter dat de bestanden los van de mail opgeslagen moeten worden. Wij werken ook met Decos en hierin wordt de mail met de bijlagen erin als een bestand opgeslagen. In de nieuwe versie van Decos worden de bestanden los van de mail opgeslagen. Je kunt dan er ook voor kiezen om alleen de bijlagen te registreren of om sommige bijlage te registreren.
Bedankt voor alle reacties!
Hoi Pauline,
Ben blij dat je met Decos de mailberichten + evt. bijlagen of los hiervan kan archiveren.
Maar ik ben bang dat hierbij handelingen van de gebruiker nodig zal zijn; vB. het bekende "knopje"
Waar ik in mijn eerste antwoord aangaf is dat met ons concept/toepassing alle mailberichten + evt. bijlagen op automatische (dus géén knopje) wijze geïntegreerd worden in een DMS/CMS en of primair proces. Dit geldt overigens ook voor uitgaande mailberichten.
Daar we met z'n allen te maken hebben met bezuigingen of géén mogelijkheid tot uitbreidingen moeten we denk ik werken met oplossingen waarbij men minder afhankelijk zijn van een gebruiker.
Groet,
Fred
Hoi Pauline,
Een nogal oude discussie, maar dit speelt nu bij onze organisatie. Je schrijft dat je erachter bent dat bestanden los van de mail opgeslagen moeten worden. Ik ben benieuwd hoe je daar achter bent gekomen/waar je dat op baseert. Is het een keuze vanuit de organisatie geweest of puur op basis van de (archief) wet? Ik heb in andere discussies op Breed ook wel gelezen dat juist de mail met bijlagen als authentiek geheel gezien kan worden.
Voor de gebruiker zie ik de voordelen van het apart opslaan van de mail en bijlagen: waaronder betere zoekmogelijkheid op bijlagen en beter overzicht in de zaak van alle documenten. Maar niet iedereen ervaart dat zo.
We hebben nu nog geen mogelijkheid om vanuit Outlook mail en bijlagen in een simpele actie in het DMS op te slaan, moet dus allemaal handmatig en daar lopen de gebruikers tegenaan.
Ik ben op zoek naar gegronde redenen om de gebruikers te overtuigen om de bijlagen wel apart op te slaan. Zou je bijvoorbeeld een grens kunnen leggen bij de bewaartermijn van de zaak?
Groet,
Christina
Pauline zei:
Ik ben er inmiddels achter dat de bestanden los van de mail opgeslagen moeten worden. Wij werken ook met Decos en hierin wordt de mail met de bijlagen erin als een bestand opgeslagen. In de nieuwe versie van Decos worden de bestanden los van de mail opgeslagen. Je kunt dan er ook voor kiezen om alleen de bijlagen te registreren of om sommige bijlage te registreren.
Bedankt voor alle reacties!
© 2024 Gemaakt door Marco Klerks. Verzorgd door