Seamless integrated and hidden from users
Managing records is typically not every employee’s accountability. Putting obligations on users to do records management’s tasks will in most cases lead to failure. Users will find other – frictionless - ways of working with their content, resulting in unmanaged content.Aim to implement a records management solution within your SharePoint environment that is providing automatic records classification, auto-declaring documents as records (based on rules), enriching your content automatically with additional metadata, and performing other records management tasks automatically. The OOTB records management capabilities in SharePoint will not do this for you, so you need to use a third party tools or develop a solution (the “Records Management feature”) to provide this type of functionality.
Extendable Content Type schema
Create your content type schema with the goal of having as few content types as possible. The number of content types needed should be driven by retention policies, and/or by other business drivers you have identified in your organization.For example; instead of creating a content type for each document type, e.g. Cheque, Invoice, Requisition, Budget, Statement, etc. - create one content type named “Finance”. Instead of Minutes of Meeting, Letter, Newsletter, Notice, Policy, etc. – create one content type named “Administrative”. The result is a set of few, more generic, content types.
Designing an extendable content type schema will help you meet future needs. Also, make sure you have functionality available to provision your content types cross your SharePoint sites (e.g. using the Content Type Hub).
Example of a simple content type hierarchy:
| Content Type | Parent | Description |
| Document | Item | OOTB content type. |
| Basis | Document | Contains common fields, which is inherited by child content types as well. Content type is created for manageability purposes only, and will not be provisioned to sites and available for users to choose from. |
| Finance | Basis | Enable in applicable document libraries only. |
| Administrative | Basis | Enable in applicable document libraries only. |
Example of fields added to the Basis content type (and inherited by child content types):
| Site Column | Part of Content Type | Description |
| Title | Item | OOTB |
| Created by | Item | OOTB |
| Modified by | Item | OOTB |
| Created date | Item | OOTB |
| Modified date | Item | OOTB |
| Document type | Basis | Values provided by the term store. |
| Document owner | Basis | People picker. |
| Record Classification | Basis | Values provided by your Records Management feature (via the term store). The Records management tool must manage the file plan, retention policies and other records management functionality. This field is the connection between your content and the Records management tool. |
| Year | Finance | Values provided by the term store. |
| Vendor name | Finance, Administrative | Unique field to child content types. |
| Section | Administrative | Unique field to child content type. |
Redesign your File Plan
Do not import your existing file plan if it was designed for physical records. SharePoint will associate your content with a content type, and with content types comes fields/properties (as described in the tables above). This will allow you to categorize your content in a new way, and most likely, you should be able to design a much simpler file plan. By the way, SharePoint OOTB is only allowing you to create policies (in forms of workflows associated with e.g. content types) so you should probably not heading down that path. I highly recommend you purchasing a third party tool to help you managing your file plan in an enterprise fashion.Design an information architecture in SharePoint to allow for automatic records classification. Also, make sure it is easy and straightforward for users add their content. For someone in the Finance department, it might be important to separate the content on a more refined level than the content type “Finance” (see above table), so you might end up creating multiple document libraries for that purpose. For each document library you can configure default Content type (Finance), default (unique) Document Type, and default (unique) Records Classification values. The retention policy is defined in the file plan and mapped via the record classification value applied to the content.
Example of retention period for finance related record classifications:
Record Classification
|
Retention Period
|
Finance general
|
CY+2; 6y; D
|
Accounting general
|
CY+2; 6y; D
|
Accounting receivable
|
CY+2; 6y; D
|
Financial Statements
|
CY+2, 6y, P
|
Salaries and wages - Payroll
|
CY+2; 6y; D
|
Agreements
|
SO; nil; P
|
Approach
Implementing an enterprise level records management solution is a daunting task. If possible, make it an iterative process that allows you to engage with a single department, a single function, or another grouping of people - one at a time.Pick a records management tool that allows you to manage your file plan (add, modify, and delete records categories, retention schedules and other parts of your file plan) in a user-friendly way - without depending on developers.
Having an iterative process + a records management tool that allows you to modify your file plan as you go + an extendable content type schema = engaging and fun records management project. It allows you to configure your solution, present it early to users, and make changes quickly based on feedback from your stakeholders. This “show and tell” approach allows you to gather meaningful feedback from your stakeholders, produce better value for your stakeholders, and eliminate creating unengaging documentation (waste).
I hope the above considerations are of help and “food for thought” in your records management journey/project.
Awesome
ReplyDelete