www.johntimney.com

I've been asked this question a few times, and I can honestly say I don't have a defacto answer for it.  Can MOSS really do Fileplans?  Myself and a good friend Brian English (who know more than me about information flow in MOSS) had a chat about this.

MOSS doesn’t provide great tools for defining a Fileplan and then enforcing it from that. However many organisations, inc Government, document their File plan in MS Excel or even Word so this isn’t necessarily a huge shortcoming. If the implementation and Design of the FilePlan is in the same tool and that tool doesn’t separate the two activities you run the risk of quality audit non-compliance. If one tool does everything, how do you know that it is doing what it is meant to do, and not what someone has mistakenly set it up to do. This is a common check for ISO9001 Quality Auditors in all sorts of areas which can result in the Fileplan design therefore having to be documented off-the system that enforces it anyway.

So, File-plans are normally defined outside of MOSS, depending on how you want to organise your information storage and the policies around it.  This is then mapped into MOSS using a combination of document workspaces, libraries, lists, image libraries etc. either at a root site level (department) or at a team site level (team) or an individual level (mysite – typically no policy other than manual process enforcement). 

This would include definition of Metadata which could be applied to each document and list item and views hrough which to improve exploitation.

You would build site templates to represent how the taxonomy of these storage areas (for want of a better description) would sit, and the structure for new sites based on the breakdown of the fileplan and new sites would be created to represent this taxonomy and the fileplan breakdown as it was expected to be applied. These can be reused to provide a consistent site structure, they may include standard data, e.g. document templates or links to help or template references (other sites) that you want to deliver to each site. You need to be careful which approach is used as embedding data in site templates can cause problems over time if the data changes significantly and there are a lot of sites that then need updating.

All areas of information storage in MOSS can be team centric (but they don’t have to be) as they can be divisional centric – but those team centric views on information can have policies applied to feed the records centre from anywhere to ensure the fileplan requirement is met.  So the structure of any “drop zone” in the records centre so to speak can have information policies applied that ensure the requirements of the fileplan are met. Ie. If it’s this type of document (email) move to folder X in the record centre and retain for two years then delete. The concept of content types supports the fileplan definition stage, so fileplan elements should be mapped into content types and the content types mapped to MOSS Information Management policy whihc can for all sense and purpose drive your fileplan enforcement.

There is a specific site called the document centre which is designed to offer a more robust document centric view on an organisation than a document library in a team site, where a less formal more hierarchical top level file structure can be created that represents how a logical view of the information might be managed – but it’s a bit of a forced taxonomy.  This though can be applied at any level, as can a folder hierarchy that represents taxonomy based on lists and libraries.  So it all depends on “what” you trying to do with your fileplan and whether it can be done in MOSS.

There are no fileplan modelling tools in MOSS.  You are expected to do this outside of MOSS and enforce the policy of fileplan object types based on specific content types.   MOSS also has no support in its record centre for hierarchical fileplans - you need third party tools like Wisdom, which is MOREQ2 compliant and conforms to the UK National Archive standards.

At this stage, I would probably start repeating an excellent article writtien by MVP  Zlatan Dzinic which goes into more details than I intend to do, and so I'm going to divert you over to that.

http://dotnet.org.za/zlatan/archive/2007/09.aspx

Hopefully I've wet your appetite and Zlatan can serve you the main course!