Leaving SharePoint

imageNo, we’re not leaving SharePoint. We are reducing our SharePoint footprint though and I thought that I’d start a periodic mini-series on this subject. The mini-series appeals to me because I don’t think I can cram enough material into a single post and still squeeze under that self-imposed 800-word limit. Raise your hand if you want me to abandon that limit…yeah, I thought so.

So, what is it exactly that we are reducing about the way we use SharePoint? We are beginning a project that will gradually eliminate our Internet-facing SharePoint site. Why are we doing this? There are lots of reasons, but I’ll limit this post to three:

It’s Complicated – Not the answer, the answer is pretty simple, but having an Internet-facing SharePoint server is complicated. That SharePoint server runs under a separate domain, so we had to build a Trust between our in-house server and the outside server. Even though this allowed us to let our employees have access with their in-house domain credentials, they still have to log in. We could eliminate that step if we designated our in-house domain as the primary domain, but then our business partners, the people we built this server for, would have to include the domain in their user name. We tried that and the results were terrible.

While we can tell our employees to “suck it up and include the domain name and the forward slash, you know, the one over the Enter key, with your user name” we can’t really tell our customers to do that.

It’s not just complicated for people, it’s complicated for software. MetaVis, Harmon.ie, Muhimbi and HarePoint all had to make tweaks to their product to let us work across the two farms. I think it’s pretty cool that they all made those tweaks, but we quickly learned that it is one of the things we have to ask vendors about their products. I look forward to not caring about that capability in the future.

It’s Expensive – When we started out, the outside SharePoint server was a separate physical box. In addition, we had a separate server acting as the domain controller for that domain. These are both virtual servers now, but they still represent two Windows Server licenses, as well as a SharePoint license as well as, well I think none of us actually we all understand Microsoft licensing. Of course there’s more to buy than licenses, those servers have to be maintained, upgraded, backed-up and tended to during power outages.

It’s not just expensive from Microsoft; it’s expensive for some of that other software as well. Add-on software vendors seem to follow weird currents in the industry. Some drift toward the “pay enough money and you can use this anywhere” model and some like the À la carte approach. Unfortunately, when stuff is priced at the “enterprise” level, the companies who benefit are the companies with hundreds of servers. Having 2 servers and paying enterprise prices is a budget story that never ends well.

It’s not what people want – This is the most significant reason of all, our business partners do not want to use SharePoint as a way to get the information they want from us. It might be a sad commentary on the state of ECM. It might be a reflection on what we did or didn’t do with SharePoint. It might just be that SharePoint was overkill, but it’s not wanted. Most of our historic (we’ve been doing this since 2006) use of SharePoint can be filed under the category of “file sharing.” People go to our site to get documents that we have, or they use SharePoint as a conduit to move documents between themselves and our employees. SharePoint worked, but there are other products and / or services that work just as well, perhaps better. These alternatives are less complicated and they are less expensive and they work the way our customers want to work.

Next up in this series, I’ll talk a little bit more about what our customers want and about some of the solutions we considered and some of the reasons we did or didn’t like them. I started off by saying that this would be a periodic series, meaning that you shouldn’t expect to see that story next week. Every time I try to plan the story I want to share next week, something interesting happens and I end up pre-empting the scheduled subject.

Brave New World of Capture

clip_image002Hopefully the salesmen who have tried to sell me Capture solutions over the years aren’t reading this blog; if any are, I’m sorry. I have been telling those guys for years that:

We don’t use forms and we really don’t have a need for hardware or software to scan into SharePoint.”

I lied. OK, I really didn’t lie, I just couldn’t properly imagine the truth – we do have a need for a scan-to-SharePoint. Well, actually we don’t but we will for a while.

Sorry for the confusing lead-up to this post, but it has been very confusing for us as well. Despite the fact that we are an insurance company, we really don’t use hardly any forms in our business process. What we do need a scanning solution for is backfilling some important document libraries. We could simply take the approach of having a network scanner, or even desktop scanners  (since we have so few insureds) but I don’t think that will work. What makes me say that? Well we’ve had desktop scanners and high-speed Multi-function copies on our network for the entire time that we’ve had SharePoint but very little content has been added to SharePoint via those devices. The reason for that result is something that Marc Anderson mentioned recently and Steve Weissman has been saying forever – simply having the technology scanners or SharePoint) in place is not enough.

If technology is not the answer, then why am I excited about the arrival of these MFC’s and the configuration of the scan-to-SharePoint options next week? The answer is technology is only part of the answer this time. This time, we are going to attempt to address the business process side of the equation and the human side of the business process.

The copiers that we just replaced were “capable” of scanning to SharePoint, but only if you gave the copier Full Control the SharePoint sites that you wanted to scan to. That meant that people could scan documents into libraries that they couldn’t actually reach from their desktop. We trust our employees, but that’s dumb. The dumbest part of that would occur when someone accidentally scanned a document to the wrong library – then they couldn’t even delete it. In addition, the copiers needed to be on the Internet so the vendor could access the copier for maintenance and meter readings. Call me silly, but that sounds like a potential security risk. With that feature never activated, we were left scanning to a network drive and getting documents in the form of “Scan_20080616121254.PDF” – very helpful. Of course, there were better capture options around when we bought those MFC’s but we didn’t need them; remember? We also couldn’t afford them – we still can’t.

What we can afford is the following combination of hardware, software, workflows, training and administrivia:

The MFC’s communicate with server-based software that can map user rights and privileges back to the menu system of the copier.

The MFC’s are capable of rendering the scanned documents as PDF or PDF/A into the desired library and they are capable of producing metadata from barcodes or other scanned artifacts.

We are capable of creating SharePoint Designer workflows to process the scanned documents upon arrival in the library. In some cases, we may have the scanner deliver documents to a staging library so that the workflow can perform other operations first. For example: our policies are what are known as “continuous form” policies, meaning that we renew by endorsement. In non-insurance speak, that means that each year, we have to add 10-12 pages to an existing document / PDF. These MFC’s in conjunction with software from HarePoint and Muhimbi can stitch the incoming PDFs onto the back or front of an existing PDF.

Once we can demonstrate these capabilities, we can ask department managers to accept the assignment, on behalf of their staff, to make backfilling a requirement during the lease-term of these copiers. If our Policy Management software can be made to print to PDF in those libraries, we can eliminate the need for the scan-to-SharePoint option with the next generation MFC’s (see, I didn’t lie).

By the way, just to prove that “we get it,” rather than make people login at the copier using an on-screen keyboard, we paid extra for a reader that can accept the proximity badges we use for our security system as input – how cool is that?

The copiers just arrived. The software has not been configured. The workflows haven’t been written and the people haven’t been trained. But we have engaged a training partner to help us get our coworkers up-to-speed and we are starting with “Content Management Fundamentals” – We are going to start at the beginning, cover all the bases and build solutions that will help us treat “Backfilling” like the important business process that it is in real life.

As Easy as 1-2-3

clip_image002Last week, I talked about how we built a prototype site in order to demonstrate some of the features we were thinking about using in a project for our legal department. The prototype site was well received, and even though we’re going to delete it pretty soon, it was worth building. In addition, it didn’t take that much effort to build. Part of the reason we were able to build the site so fast is because SharePoint is designed to be built fast; let’s face it, that’s one of the reasons we bought it. The second reason we were able to work fast is because we used a few of the tools we have bolted onto SharePoint. I’ve talked about each of these before, but it’s summer so I think we can stand a few reruns. Here are three of the things we have added to SharePoint that I am happy to have:

Muhimbi PDF Converter – This product not only lets our users convert Office and a wide variety of other documents to PDF from the library drop-down menu, we can call on these services from a SharePoint Designer workflow. The best part is that last little bit about workflows. We can save our coworkers the time it takes to create the PDF, but we can also manage the process. That means that we can put the PDF in the library it belongs in, and because we can kick the workflow off when an item is uploaded or changed, we don’t have to worry about people forgetting this important step.

SharePoint Classifier – We added this product from Boost Solutions last year. Working from an intuitive interface, this lets us bulk edit metadata for a large number of selected or uploaded files quickly. We can set metadata to a specific value across the entire group or we can skip through the list of documents, setting some bits of metadata to a single value but setting others to unique values. We used this to quickly populate the demonstration libraries on our prototype site. Classifier can also copy or move the selected items from one library to another, set tags and check the documents in if necessary.

Lightning Conductor – This is our most recent add-on, but it’s one that I am really going to enjoy using. One of the features we wanted to demonstrate was the ability to pull items together from the various libraries based on certain metadata. The example we used was to show all the documents that had been tagged as the “Current Version” in a single web part on the main page. This illustrated a critical capability that our users wanted, the ability to store documents where they belong, but present them as if they are in the same place. What I like so much is the fact that we configured the web part in a matter of minutes.

These tools make SharePoint easier to use and much more powerful by augmenting the inherent strength of SharePoint’s out-of-the-box power. Whether our users are working directly with these tools or asking us to configure a solution for them, these (and other) tools are saving us precious time.

The Other Side of Capture

Last week, I mentioned the importance of the tight integration between Office and SharePoint. It is one thing to say that most of the documents we have to upload to our SharePoint library were created in Microsoft Office. It’s quite another thing when we realize that we began creating these using Office 97 and these documents are currently in a number of different locations. In most cases, this comes down to a “you know the drill” moment. In this particular case, we found a Rosetta stone of sorts. One of our employees had an Excel spreadsheet that linked to the documents in their various locations. The spreadsheet also included numerous columns of information about the documents, some of which matched our metadata requirements exactly. Unfortunately, the spreadsheet had been poorly maintained and also included a few errors. With the help of a temporary list, a few VBA scripts and a few disposable workflows, we were able to update and correct the spreadsheet, and then upload it to a SharePoint list. Once in SharePoint, we ran a workflow that used the list values to update the document library metadata. It wasn’t pretty, but it worked, it saved time and it helped ensure accuracy. I realize there are products that can perform tasks like this, but when you only need to do this once, buying something doesn’t make sense.

Moving on to the opposite end of the Capture portion of the roadmap, we find one interesting on-ramp lane, Application Created Information. We have quite a bit of this content in our organization and even some in this particular project. The important thing to understand about this content is that it is already being created by the most efficient process we can imagine. In other words, this does not represent a problem we want SharePoint to solve. Instead, we are extending the reach of our applications to include SharePoint, by taking advantage of the powerful, albeit poorly documented web services interface that Microsoft provides. This represents an expensive proposition for us, but unlike a highly focused add-on product, this is a broad based solution that we can use in multiple applications. We are building this capability gradually; our first version can handle basic list and library operations. That means that our applications that create reports can also file them. While we can’t yet initiate a workflow, we can rely on SharePoint to handle that task until we finish v2.0 of our development effort.

In addition to the expense associated with building the interface library for our software development environment, will be buying some products too. We are currently evaluating Muhimbi’s PDF Converter for SharePoint, to create PDFs on SharePoint and inside workflows. We are also planning to integrate PDF manipulation capabilities into our in-house applications in 2011. That capability will enable us to automatically update PDFs stored in SharePoint. These two solutions will help us to bring content into SharePoint through non-traditional pathways. We may be driving on the shoulder of the on-ramp, but I think that still counts as capture.