Dear List,
Thank you for the conversation regarding MOSS 2007. We are about to embark
on a proof of concept using MOSS's records and document management
capabilities in a very highly regulated area -- medical device
manufacturing. I am not convinced it will do the job without much
customization, as has been mentioned. However, if this will get the
executives to "buy into" the ECM concept, then I am all for it. Sometimes
it is necessary to crawl before we can walk...
I'll keep you all posted as much as I am able considering the constraints of
proprietary information sharing for the company I am discussing.
Kindest Regards to all,
TK Train, CRM, ECMp, MIT
-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf
Of Jim Connelly
Sent: Saturday, June 16, 2007 2:18 PM
To: [log in to unmask]
Subject: Re: [RM] Sharepoint
I would like to add a few comments to the Sharepoint discussion in the hopes
that Steve can use some more practical thoughts.
My apologies to anyone who participates in the UK list serve and received my
short rant last month. The following is a slightly updated version based on
replies I received from UK.
As an RM consultant from Canada, I almost had a coronary in San Antonio last
October, when I saw the latest Sharepoint MOSS 2007. But despite my panic,
I believe Jesse is right that Sharepoint is workable ... in that we can
tweak Sharepoint despite its flaws.
God bless him, Mr. Gates has it wrong again, but the functionality of
Sharepoint does provide most of the Basic Content Services (BCS) of an
Enterprise Content Management (ECM) System. Think of it as ECM - Lite.
"Content Type" is the key element. It has to be used as the 'Activity' or
'Records Series' equivalent within Sharepoint to get any RM and workflow
functionality.
In other words a taxonomy framework - a set of libraries can easily be moved
into Sharepoint . see www.rehamniconsulting.com for some excellent videos on
how to work within both 2003 and 2007 Sharepoint. But you MUST duplicate
each records series in your taxonomy as a "content type". For a small
organization of 300 - 400 people this may mean 1000 - 1500 content types.
Each content type can have a number of workflows associated with it. Once
this is done, documents can be set up for automatic transfer to a central
repository. NO content type ... no automatic transfer. It seems a lot of
work and it is, but the results could be rewarding for many of us and it all
ends up as transparent to our users..
One key element of Sharepoint deployment that will cause difficulty is the
decision to use a single repository or to allow web sites to create their
own repository with their own retention management capability. My bet is we
will need to create one corporate repository that is the heart and soul of
the Sharepoint engine and one that is decidedly under RM control . one site
of buckets where the organization can store documents and one set of
controls . a retention schedule. I cannot imagine an organization sometimes
moving documents to a central repository and sometimes keeping them for
themselves in business unit repositories . shades of decentralized and
uncontrolled file rooms. By creating flexibility, Mr Gates has opened up a
rat's nest of security and integrity problems.
Remember that if you use ONE repository and auto-file from business unit,
project or teamsites through the use of 'content types'. You will have a
central repository that is controlled by your retention schedule and the
documents stored in the unit, project or team sites can essentially be
considered transitory.
Another key element of Sharepoint deployment is the web architecture. You
must create the tree structure for your organization carefully with one top
level web site and my suggestion is actually 2 (one for RM use only to
maintain the taxonomy and index lists for RSS feeds) at the top of the tree.
Below that level you can create organization unit web sites. Each must use
the same (by that I mean, in most cases, subsets) of the master framework
and taxonomy. I have an example of a Sharepoint tree structure in an old
ECM presentation on my website. Each organization unit can then create
meeting or project sites as they see fit. Templates for these sites are
critical. Also, remember that project sites may use folders that do not
match the library framework but if those folders can be assigned a content
type then the documents can be moved automatically via the workflow process
to the corporate repository.
So let me just list a few of the other glitches you may hit.
I am not entirely positive about 2007 but 2003, I believe, had a limit of
1000 libraries and 1000 folders within a library. This means getting
creative with some large case file series . breaking them down with range
folders either numerically, date or alpha.
When using document types, metadata allows for pull-down menus . anyone
tried this? So large metadata elements such as project names that you want
to pull in may need to be made uniform through central administration. RSS
feeds may also work here?
Security links with Active Directory Services (ADS) also may need to be
identified. I don't think there is a way to import the ADS tables directly
to Sharepoint . anyone been there yet? Most other ECMs support this and
without it, you are in for significant workload problems.
As usual, "special characters" are forbidden in folder names e.g. no
ampersands "&" . these will not be allowed in folder names as they are part
of the actual code of Sharepoint. So tidy up your series titles before
moving to Sharepoint.
Another issue is that organizations will glom onto Sharepoint to get rapid
collaboration for current documents and current projects. In other words
the millions of past documents on organizations servers will remain in
critical condition (poor naming, poor versioning, strange and convoluted
folder structures) but rather than clean them up ... an expensive and time
consuming process as we all know, Organizations will roll-out Sharepoint to
provide instant collaboration with current work. In other words, they will
tell business units not to worry about the thousands of past documents in
poor structures, just move your current documents to a Sharepoint folder and
let RM worry about the rest.
Does anyone not see the danger in an IT solution that skips past all
principles of security, risk management, records integrity?
My gut feeling is that organizations will race willy-nilly to implement
Sharepoint and it is up to the RM community to stay ahead of the masses.
Set up the structures and the business rules surrounding sites before things
spin out of control.
My weekend 2 cents or tuppence!
Regards
Jim
Jim Connelly
8 Oakdale Place
St. Albert, Alberta
T8N 6K6
1-780-460-7089
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
|
