Note:
Inventory nu are sensul de inventar ca la noi, ci de lista a gruparilor de documente care au fost create; e mai degraba o recenzare, decat un instrument de evidenta.
Clasificare are sensul de organizare intr-un sistem de clasificare, nu de documente secrete.
O discutie recenta interesanta la americani (http://lists.ufl.edu/archives/recmgmt-l.html) daca planul de clasare ar trebui sa fie legat de lista termenelor de pastrare. Adica, asa cum e la noi nomenclatorul arhivistic. Intrebarea si raspunsurile (anonimzate):
Question:
Has anyone ever benefited from establishing a company file structure based on the company retention schedule? What would be the pros and cons?
Answer #1:
it’s not a good idea.
File structures serve (at least) three possible purposes: to find things by browsing when searching doesn’t work; to apply security access and permissions, and to apply retention rules. You will note that only one of these (browsing) has any benefit to end users, the other two (security,
retention) are for back office people like RM.
The problem is that our common law-based legal system results in pretty convoluted retention rules, so any resulting file structure will hinder users rather than help. One of many, many examples: where I work now, agendas for meetings have a very short life, but minutes of meetings are kept much longer. Set your file structure up with separate folders for agendas and minutes, and 80% of PA’s will hate you because they want folders by meeting not by type of document.
Here in Oz, the KeywordAAA thesaurus published by NSW State Records, admirable and groundbreaking though it was, is far too heavily influenced and constrained by retention. So I’ve insisted that under no circumstances do we adjust the folder structure to suit back office requirements. As a result we’ve gone big bucket in a big way, and will end up keeping lots of things longer than necessary (a risk we will manage in ways other than via the folder structure). But the end users do not have to know about retention, or security, they just check documents into folders which they know are right for finding things.
Obviously it depends a lot on your system. Some software handles retention and security in ways which don’t intrude on end users, and the browsing folder structure is separate. If you have really good search functionality it can reduce the need for browsing, as can shareable saved searches and the like. The system I’m working with is pretty primitive, and we have to closely align the retention rules with the virtual folder structure.
So my message is that your systems and services, including folder structures, must be aimed primarily at meeting end user / business needs, and to build anything around retention is the tail wagging the dog. In this day and age that’s not a good career move!
Answer #2:
you explained this decision process very well. I totally agree because I have played around with using the retention schedule as a file structure (sounded like a good idea), but everything you said is true. The two structures have totally different purposes and cannot be merged. Create the file structure to make it easy and simple for the end user to find what they need (the number one rule in RIM), and apply the appropriate retention to those folders behind the scenes. This is true with electronic and paper records – although it should be easier with electronic records.
Answer #3:
Contrary to […] we have made some good experiences with using the retention schedules as file structure. Our system (Documentum by EMC) sets retention at folder level, so we have a record series folder which sets the retention for all folders and records which structurally come under it. That way, we can apply retention policies in a grouped way. It is a true that it separates records that content-wise belong together (such as meetings and agendas), but that could be circumvented, if users wanted, by virtual folders. However, this is not even needed, as we use our system for archiving records when they are no longer in the current life. For the current life, we use Sharepoint where, in our case, retention plays no role for information organisation. So, some of the points Glenn and Mary make do not really apply in our case.
The advantage of building folder structure on retention schedules is the tighter document control; the disadvantage is that it takes longer to prepare the system for roll-out.
Answer #4:
>>File structures serve (at least) three possible purposes: to find things by browsing when searching doesn’t work; to apply security access and permissions, and to apply retention rules. You will note that only one of these (browsing) has any benefit to end users, the other two (security, retention) are for back office people like RM<<
Sorry I have to disagree. I have used retention schedules as the basis for file structures since I started in RM. It seemed logical at the time and has worked well ever since. One of the things I like most about it is that it enables users to logically store their content in a structure that meets their needs and enables the disposal of information when the retention timeframe expires. Additionally, users have been very quick to pick up on the structure as the retention schedule is structured to follow the functional business structures of the organization. As a result, files stored by users on the shelf, in a share or uploaded to the ECM solution are where they would logically store the information anyway. Moving from the extremely detailed retention schedules of the past to slightly bigger buckets has made the connection even more logical and provided users with flexibility extend the file plan as they see fit.
I would also disagree that security and retention are only for back office people. All employees are responsible for knowing whether the information they have is protected and the level of protection required. Retention is also important to individual employees, especially if you are in an industry that is subject to frequent compliance reviews, regulatory scrutiny and legal matters.
Answer #5:
If you have a retention schedule that is “functional” rather than “organizational” and it touches functions that cross organizational lines, to use this as your file plan as well is not only logical, but it supports culling older files for transmittal to your record center, either on or off site. Additionally, it simplifies placing destruction holds on records and performing disposals based on retention periods being met on stored records.
Answer #6:
Well, that’s what I said too, in a different way. I don’t know what Larry and Bill’s retention schedules look like, but ours (most of which we have no option on using, they are imposed on us) are a fright, huge, complex, overly granular, inconsistent, pedantic . . . don’t get me started). So we took the schedules as one of the factors in developing our framework, made them VERY functional, ironed out inconsistencies, eliminated things we know drive end users crazy – all in ways which do not conflict with the letter of the retention law (it’s called big bucket). From the end user’s point of view it doesn’t look much like the retention schedules they love to hate.
So we still have our voluminous, granular, clunky horrible retention schedules, and a virtual folder setup in the EDMS which makes it easy for people to browse for things when search doesn’t work. And all of our users are very aware of recordkeeping obligations, security, and privacy, through our ongoing awareness program, and they know how to apply additional security in the EDMS on a case by case basis. We don’t use retention to teach good recordkeeping.
Users also appreciate knowing that, 99% of the time, they can simply drop a document into a browse folder, and don’t have to worry about retention and security if they don’t want to because we’ve set it up for them.
I still insist, your retention schedules should not drive your EDMS structure – nor should they drive your RM program because an RM program is all about managing DOCUMENTS (some of which are records).
Answer #7
We have very successfully used the concept of functional classification in our retention schedules. We introduced two additional concepts as well. The first is to ‘tack’ the retention schedules behind the hardcopy and electronic folders so the user does not need to know retention schedules.
We also used a business analyst to ensure that the user department folder structure was consistent with the corporate classification schedule, and to work with the departments to refine as needed so we had their support in this effort. The result was an effective system that works.
Bogdan's Archival Blog -- Blog de arhivist 