Microsoft makes a template available on Technet for a file plan which is document-based. Although this may serve as a basis for smaller companies that start with archiving activities, the template leads in a direction that is different from what is used in most RM technologies, supported by records management practices. In this post I describe a method to bring these practises to SharePoint. This is a draft part of my book Records Management and metadata,
Digital archiving in SharePoint Online and Office 365, which will be published in januari 2016.
Retention schedules may be created on the basis of document type, function or process. An organizational hierarchy revolves around various departments that each have their own manager; a function relates to a part of the organization (such as performing resource management). In practice, the function is often closely linked to a department, but it may also relate to several departments. A process may include several functions/organizational units, but it may also be entirely located within a function or department. Retention schedules based on document types consist of a list of all types of documents in the organization. The various documents are grouped according to type. Such a classification is stable and simple, but lacks relationship with the business. Classifications based on the organizational hierarchy or function follow the structure of the organization or the type of work that is carried out. Structures in organizations are always sensitive to reorganization and the accompanying changes. A classification based on function is considered to be more stable, although businesses have had to change increasingly rapidly and fundamentally over the past decades.
Similar items (document types, functions or processes) may be combined across the various business units, or they may be separated for each business unit. Both methods have their drawbacks and advantages. When a specific item is searched, it may be helpful to have a hierarchical classification in which the first level is the main process or the department, for example. Within a SharePoint record center, there is also the issue that document libraries should not become unmanageably large. The maximum number of items in a view for SharePoint Online (Enterprise) is 5,000 items at present. On the other hand, smart views may be created within a document library, which facilitate the creation of relevant cross-sections for the documents present.
The following is a basic working method for arriving at a process-based retention schedule:
- Create an inventory for the main processes, which consist of various functions or departments. See also ISO 15489-1, section 8.4b, ISO 15489-2, section 4.2.2.2. It is also possible to start with an inventory of the main processes for each function or department, for processes that take place entirely within such a unit.
- Create an inventory for sub-processes for each main process. See also ISO 15489-1, section 8.4b, ISO 15489-2, section 4.2.2.2.
- Determine the importance for each sub-process and identify requirements arising from laws and regulations, as well as the need for evidence. Statutory tasks for governments, for example, are listed in decrees, see also ISO 15489-1, section 8.4c.
- Determine what records are related to the previous point.
- Determine the retention period for each process or for each document type as well as the event that marks the beginning of the term (for example: contract drawn up, signed at local level, signed by the management board, signed by the client). Determine what should happen with the documents after the retention period.
- Determine the retention period of documents that are not records and what should happen with them after the retention term. This may look similar to the previous point, but the focus is now on the destruction of documents that have lost their value after a certain period.
- For the Dutch government, the selection list is formally established and published in the Dutch Government Gazette.
Set up a main structure for ordering by standardizing the list at as high a level as possible. This avoids a situation where every department invents its own set of document types for processes that you actually want to streamline as much as possible at record level, such as project management. Creating a structure for ordering was the final step taken here, but it is probably more efficient to standardize after the first processes, and to establish best practices accordingly with which subsequent processes should comply. Not only does this create a recognizable structure and you have an influence on the desired detail level this way, it also provides an important reference point for implementation in SharePoint. Here, too, the functional requirements come first, but a workable system can only be created by already factoring in implementation during the process. Standardization offers the possibility of basing similar document types on a shared content type in SharePoint. As a result, the records management solution becomes easier to maintain.