Questions about Document Management with SharePoint

This is something of an expansion of my question on Twitter from last week.

We are currently using a third-party document management system for the entire company. All documents are categorized within a hierarchy (rather than a flat category structure). It’s got both a web-based component as well as a desktop component which provides integration with Office and other applications. (This last part is an annoyance, as it tends to make Office unstable.)

However, it’s an old version of the product and we need to either upgrade or look for something new. Between some of the annoyances people have with it and the licensing and support contract costs, we’re trying to find an alternative. A newer version of the product in development is going to use SharePoint as its platform. Since we’ve had a bit of experience creating intranet sites with SharePoint, this is what my boss is wanting us to use. (Currently, we’re using WSS3, but we can license MOSS2007 if necessary.)

I know how to use some of the document management features of SharePoint libraries–versioning, check-in/check-out, Explorer integration–but going from document management features to enterprise document management system is a big leap that I’m not willing to make without some serious planning and evaluation. It’s difficult, however, as we’re not really sure what we need–we have a vague idea of what features people need and what annoys them, but no hard-and-fast requirements other than it needs to be a replacement for our existing DM system. (This is made even harder by the fact that we have no dedicated DM administrator anymore.) Quite simply, we don’t know that we won’t implement something and then have the users tell us it’s completely unusable.

The last time I looked at using SharePoint for this purpose, I got bogged down in trying to recreate our DM system in SharePoint. This ended with a lot of tinkering with hacking a cascading drop-down field feature and messing with InfoPath forms for Office integration. My problem with SharePoint is that I don’t do much development with it, so when I do, it’s always poking around in books to figure out how to do something very particular. What ends up happening is I ask the question, “how do I make this work in SharePoint?” rather than “how is this supposed to work?” and then “what’s the best approach to use in SharePoint?”, and that just ends in kludgy implementation. I have a feeling there’s an approach we need to take with SharePoint that won’t be mimicking our current DM system’s approach, but will still meet all of our current requirements. The problem is, I don’t have the experience to do this.

We need the hierarchy of categories and we need to be able to force users to profile their document before they upload it. Integrating both of these into Office would be nice–I imagine if we don’t have that, we’re going to get some pushback from users. We’re also under quite a bit of pressure, as our current support agreement has run out, we’re at least a version behind on our current DM software, and the age of the hardware is going to force us to switch or reinstall soon.

So the question is: has anyone used anything like this before? If not, is there a good source of “best practices” for this sort of thing? Or doing it right so far over our heads that we just need to call in a consulting company to give us some direction?

  • Gabriel

    We use sharepoint at work, but most people don’t care for it. I’m not sure why, other than random “GAH, I HATE SHAREPOINT” comments. For me, it’s trouble to use because they went out of their way to lock out non-ms users.

    If you’re not using windows and IE then you miss out on features and piss other people off. For example any file I modify I have to re-upload and it loses its history. But if I were on windows and using IE then I could check the document out and once saved you could go back to previous versions.

    Which is a pretty cool feature.

    As for “enterprise document management”, I haven’t seen the administrative side of Sharepoint but I can’t imagine it being rocket science, though I see you’re planning on doing some custom development on it for some reason.

    Anyway that was no help at all, was it. lol. Ah well.

  • Dylan Wolf

    We’re all MS here, so that’s really not an issue. Yeah, you don’t get the client integration with Firefox but it doesn’t prevent you from uploading and downloading files from the web. It’s supposed to preserve version history if you’re uploading a file with the same name.

    Yeah, I’ve come to have a love/hate relationship with SharePoint, but only because (as I mentioned) doing custom development only occasionally ends up being a hodgepodge of unrelated skills. Not to mention you start spending more time on the incidentals of programming, like figuring out what configuration options you need to set, than the essentials. (SharePoint seems to have an unnatural affinity for XML config files.)

    I would suspect part of the “GAH, I HATE [application]” sentiment, both for SharePoint at JTV and for our current DM system here, is that it requires extra work to maintain. If you were doing it on paper it’d be “GAH, I HATE THIS FORM.” If you had to email a copy of the file to someone for record keeping, it’d be “GAH, I HATE EMAILING A COPY OF THIS FILE.”

    Yeah, administering the basic DM features really isn’t rocket science. The difficulty I’m having is higher-level: creating a basic library and telling people to upload files there is not necessarily a replacement for our current DM system. We have a lot of documents, and, for example, people complained when we dropped the lowest level of the category hierarchy out of our current DM system. On the other hand, hacking SharePoint into a copy of our DM system may be the hard way of doing it–don’t fight the framework and all that stuff.

    Unfortunately, I think there’s some vague unspoken idea that “well, if the new version of our current DM software is using SharePoint, why don’t we just use SharePoint and cut out the middleman?” Which makes as much sense as saying “Well, ASP runs on Windows, so why don’t we just program our website in Windows?” (Or, if you’d rather, s/ASP/PHP/ and s/Windows/Linux/.)

  • Michael Neel

    You know my love of Wiki, how I long to use some strange new syntax instead of html to do the same thing. Text interfaces to building rich content pages rock as well.

    Ahem, so I ditched our group’s shareport page in favor of a Wiki (ScrewTurn Wiki – the name strikes a chord with me).

    SharePoint fails on the usability front, is spite it’s great feature set. The ease of editing a wiki page offsets the horrid syntax users must learn.

    Having SharePoint at JTV is good for one thing though – I get a request to add a form to the intranet and can reply “hey, sharepoint can handle that, call IT!”

    btw, can I get more than 150px width in this edit box?

  • Dylan Wolf

    Ironically, in our case, one of SharePoint’s goals was to replace a public wiki storing company market info.

    From my experience, SharePoint’s pretty usable, as long as you’re doing simple out-of-the-box stuff. It’s great for that, and cuts down on what would otherwise be a lot of requests for simple forms and web apps. Furthermore, it’s a lot more structured than a wiki–it lets you group all those lists in one centralized location. I wouldn’t exactly call it centralized storage, though–maybe pseudo-centralized, since it feels like you have a single data source (a SP site) but what you have is a lot of little disconnected ones (SP lists). Lists and views can do a nice approximation of database tables and queries, but at some point it’s just more trouble than it’s worth (especially for users who have to learn how to sort and filter and change views). If you really need to import/export data the API is decent. You can even use them as a data source in Reporting Services if you install an extension to SSRS.

    Sadly, I am both the IT guy who’ll get the initial request to create an ASP.Net form and a SharePoint list.

    Yeah, I’ve heard both you and Nathan complain about the comment box width. I set it up so it wouldn’t break the fluid layout in 800×600, but… well, that’s probably unnecessary.

  • Dylan Wolf

    FWIW, I’m going to try to spend most of the day doing research on this question. I’ve got a meeting with some other people in IT to discuss how to do this, just because I think we need more than my perspective.

    I’ve actually found a couple of good blog posts on the subject of DM, but (perhaps more interesting) is this post rebutting the “SharePoint sucks” sentiment. The bottom line is the axiom I keep trying to impress on people: software is a tool, not a solution. In the case of something massive and customizable like SharePoint (to the point of being more along the lines of a development platform than a software product), you have to know how to design, implement, and use it for it to be useful. You can’t just install it and go without any forethought into architecture.

    So I’m feeling a bit better about things after reading that perspective. Tasking a single person who has very little SP experience (me) with “just design something to replace our current system” without a serious commitment to planning is a setup for failure. I’m going to try and worry about this whole “SharePoint as a replacement for the current DM system” mandate a little less. The fact that I’m actually able to get a meeting with different perspectives together is a good sign, though.

  • Dylan Wolf

    Oh, one other thing. If anyone’s interested, I’ll post my findings on DM in SP later in the week.

  • Michael Neel

    As my manager says, you’re trying to apply logic and common sense here, neither of which exist.

  • Dylan Wolf

    Since applying logic and common sense will not work, I should just move on to Plan B.

    Plan B is go with the flow and FAIL.

    If I can get enough people involved and (more importantly) enthusiastic without actually contributing or refining any feedback, I may be able to attain EPIC FAIL.

  • Chris Luttrell

    I agree with your “software is a tool, not a solution” line of thought. Too often, people think just because they have a platform tool like SP or an application server (BEA, Oracle, IBM) that they have the solution. None of these things solve “Problems” out ot the box, you have to build solutions on them and that means diving into the business processes and problems behind the need for the new tool. I am interested in what you find out about DM in SP, please do post your findings.

  • Dylan Wolf

    I’ve been keeping track of all the good blog posts and articles I find on the subject, so I may post a series on that later on as things shape up. My main problem in that regard is that I can go at least two or three directions with the follow-up post, because trying to get this in shape is a two-front war.

    On the one hand, I know enough about WSS to set up a good portal site, but I know very little about MOSS. What’s worse, I’m not even sure what all it offers, so I don’t even know what I don’t know. If I don’t get a handle on that before moving forward it’s going to end in a very kludgy implementation, because I’m going to jury-rig features I know how to use in place of features I don’t know about. The breadth of skills required to administer and build a (good, usable) SharePoint site is overwhelming, and I’m just one person.

    The second front is the company. We have a complicated situation, because, while we don’t have millions of documents, we do have a fairly complicated structure in our current DM system. And as much as people hate our current DM system, they’re going to complain if the pieces they do like are missing. The problem is identifying those pieces–there’s no single point of administration or ownership for our current DM system. While we know users who use it heavily, they’re very busy so it’s hard to get feedback on demo versions out of them, and their feedback doesn’t guarantee other users won’t have other needs.

    Implementation will also be an uphill battle in some respects. There’s a push to move to SharePoint and Groove for document management and collaboration, and I’m going to have to force other people to separate these conceptually into two different tasks/phases/layers. I’m also going to get a lot of requests to change basic SharePoint processes (i.e., “that’s great, but can it do X/force users to do Y/look like Z?”) which I need to resist unless absolutely necessary–otherwise, they’re going to be time sinks and if I ever find a way to do them, they’ll probably be very kludgy.