Good Question, the Answer is Yes!

Posted on by

imageAfter some fairly extensive proof-of-concept work, I had the opportunity to meet with some of our engineers this week to review our plans for the “system” of SharePoint lists, libraries, interconnecting metadata and workflows required to track the recommendations the engineers make as a result of their inspections. Wow, was that really one sentence? Sorry. Everything that I took to the meeting was wired together to support a smooth flowing business process. Of course, this was a review with the end-users, the people who know how that smooth process goes off the rails.

As I worked my way through the process flow I described last week, a question emerged. I had described how, in order to avoid processing a recommendation, only to have it be removed after review, the main workflow wouldn’t run until the report status was final. They pointed out that while that was logical most of the time, during the group review meeting they need to review all recommendations, including the ones that are “about to be released.” No problem, the workflow can be started manually. Also, we will add another little bit of metadata to prevent duplicate updates from occurring when the report gets released.

We spent a good deal of time reviewing the way the workflow was processing the text of the Word document. “What if the order (New, Pending, Open, Closed) was mixed up?” “What if we refer to a recommendation inside the text of another recommendation?” “What if the status e.g. ‘pending’ is used in the body of the recommendation?” All good questions, but none of them are show stoppers.

I had been tipped off to the fact that the various status states could appear in any order. The good thing about processing text with the aid of a Regular Expression is that I don’t need to care where the text is. Also, the format of these reports allows me to distinguish between “Pending” as a section header and “pending” as in “the reason this recommendation is still pending…” Same with the recommendation numbers, HarePoint’s workflow extensions lets me distinguish between a number used as a title and the same number used in text. There’s no magic here, when these strings are used as headers, they are either preceded or followed by CR/LF combinations.

The next question revealed a bit of the process that I was not aware of, “what about recommendation status changes that result from a phone call or an email?” I had to stop and think, and I had to remember that:

SharePoint “systems” are still in SharePoint.

In other words, everything that the workflow is doing can be done (or undone) by humans. Engineers love hearing that. They love knowing that there is a ‘manual override’ or a way to start, stop and derail a process without having to call the IT Guy. Of course, I mentioned that while phone calls would require a manual entry, we could easily apply a similar workflow to an email-enabled library. In that case, the engineer could simply CC SharePoint and let the automation happen. We opted not to add that feature, but it’s always nice letting people know that SharePoint is prepared to go even further.

The final significant questions were focused on the recommendation review process itself. The process starts with a recommendation by one engineer. The group reviews the material and decides whether to accept, reject or modify the proposal. “Can we differentiate between what the account engineer proposes and what the committee approves?” “Yes, absolutely, how do you want to do it?” Options include:

  • Change a bit of metadata in the item from ‘proposed’ to ‘approved’
  • Keep the proposed version of the item in addition to the approved version
  • Duplicate the proposed item as a stub approved item at the start of the review process

They opted for the third choice. They wanted a visible trail to indicate the activity. I pointed out that we could build columns into the item so each item could store before and after versions of the metadata, but that seemed messy.

The last question was kind of a bonus question: “is there any way that all this stuff can help us document the proceedings of the review committee?”

“Yes, yes it can.”

Given the choices that they made, it will be pretty easy to prepare a composite view of the proposed items and the approved items that will provide a chronology of what took place. We won’t be recording the conversation, but we will be documenting the results.

The really cool part of this conversation was that, with the exception of a few tricky bits from HarePoint, this can all be brought to our engineers courtesy of out-of-the-box SharePoint. Microsoft baked some serious power into this product.

Happiness is…

Posted on by

imageRealizing that the thing you need your coworkers to do in order for your SharePoint solution to work, is something they already like doing.

Yeah, that was too long for a title, but that’s how I feel right now. It’s as if my doctor had told me that “in order to remain healthy, you need to eat more Heath Bar Klondikes.” In addition, my new found happiness reveals one of SharePoint’s often overlooked strengths. Yes, if you want to, go get a Klondike before reading; it’s ok.

The project that I’ll be working on while my coworker and friends are in Vegas is one where we hope to link several aspects of our engineering process. To do this, we needed to refine an identifying number that has been in use forever. To really achieve that value we are looking for, we need a way to make it seem like this new way is the way we’ve always done things. The really cool thing is that SharePoint can make this all possible.

I’ve talked about bits and pieces of the neighborhood in which I’m working before, loss control inspection reports, recommendations and composite views of data. We have a solution that lets us track and support the development of a loss control inspection report. Ultimately, that process ends with the final report being stored as a PDF, in a records library – locked away forever. However, the process leaves the Word document that created the PDF, behind for review. Keep that in mind.

We also have a solution that tracks the recommendations our engineers make in those reports. These ‘recs’ have a long and complicated life. They get written. They get reviewed. Customers comment on them, engineering peers comment on them and once or twice a year, they get ranked:

  • How important are they?
  • How are they being addressed?
  • Where are they in that life-cycle?

We built a series of custom lists to aid in this process. We also built a couple of composite pages, aided by some data view web parts to assist in that review. Still, something is missing.

What’s missing is the link between the reports in which the recs originated and the recs and the rec-review process. My job is to establish those links.

This is where ECM projects often run into trouble. We have hundreds of reports. We have hundreds of recommendations. Most of the recommendations are ‘closed’ but they still have value. A lot of information is coded into those custom lists, but the real value, the mother-load of information, is in the original reports. The trouble is that this isn’t a one-and-done process.

The recs can appear in many reports over time and any single report can refer to multiple recommendations. It takes time to review, reread, search and add metadata to those reports in order to link them to the lists…or does it?

Well, it seems that it will take some time, but not much. It also appears that going forward we can keep the reports and the recs in sync, with little or no effort at all.

The key to my happy day lies in the fact that SharePoint, with the aid of some workflow add-on products, can read those reports. Further, it turns out that the way our engineers like to write those reports, their “style,” the style they’ve been using forever, lends itself to being picked apart by Regular Expressions.

The reports already have metadata that tell us what policy they refer to. The recommendations have an ID number that tell us what facility they refer to. Today, I built another SharePoint custom list that links those facility ID numbers and our policy numbers. Now it looks like I’ll be able to have a workflow read the reports, pick out the recommendations and automatically maintain the activity in the recommendation lists. If this is successful, once an engineer finalizes a report, a SharePoint workflow will create a stub new recommendation or a stub recommendation update item, and then create a “please complete this item” task.

I’m talking in the future because I’ve only completed the proof-of-concept steps. I can read the reports. I can find the recommendations. I can build a new composite identifier and I can stick it in every custom list where it’s required. I usually wait until I have a solution to write about it, but this was so much fun, I needed to share it. When I finish this project, I’ll let you know how it works, in this blog and at AIIM14. If I fail or partially fail, I’ll write about that, too.

My Annual Plug

Posted on by

imageI’ve been writing this blog for almost five years. During that time, I’ve talked about lots of products that we use (in addition to SharePoint of course). I’ve talked about people we have worked with and conferences that I’ve attended. There’s only one organization’s event that I’ve ever really dedicated a post to. That organization is AIIM and this is that post. It’s a good time for this post for two reasons: 1) the conference is coming up soon, and 2) my SharePoint coworker has been on vacation so it’s been a slow news week here in the office.

In about 6 weeks, AIIM 14 will take place in Orlando, FL. Right now, looking out over 4’ mounds of snow in my yard as I watch freezing rain pour down, sunshine and warmth seems like something out of a fairy tale, but they have it in abundance in Orlando. So, if you’re a fan of such stuff, you have reason enough to go. But, that’s not why I’m going. I like winter. I like snow. I’m going to Orlando, to AIIM 14, to learn.image

If you want to know “how” to use SharePoint, there are just under a zillion conferences you can go to. There’s probably a great one on Saturday or at least there will be, on an upcoming Saturday within walking distance of your house. If you want to know what Microsoft plans to do with SharePoint and what they think you should do with SharePoint, there’s something big happening pretty soon in Las Vegas. But, if you want to know “why” you should be using SharePoint (or any ECM/collaboration solution) or how you might use it better, you need to go to AIIM.

Seriously, nobody understands content like the folks at AIIM and the folks that will be speaking at AIIM 14.

OK, disclaimer time. Sheesh, this gets bigger every year. 1) I will be speaking at AIIM 14. 2) I am the Program Director for the AIIM New England Chapter. 3) I am on the Board of Directors of AIIM International.

Do I have a vested interest in wanting you to go to AIIM 14? I guess, kinda-sorta, but it’s not like I make any money from AIIM. It’s not like working with AIIM, AIIM NE, speaking at the conference or (writing this blog for that matter) will ever lead to increased sales. Well, that is assuming that none of you have an uninsured nuclear reactor hanging around. I attend the AIIM Conference to learn. That’s the benefit I bring back to the office. I have been attending the AIIM Conference, every year since 2000 in order to learn and I have never not learned something that has helped me do my job better. Every single conference has been worth the effort, worth the expense, worth the time; this year will not be different – AIIM 14 will be worth the trip.

The AIIM Conference offers one of the best conference experiences I’ve ever had. It’s big enough to attract some really cool keynote speakers, but it’s small enough to be comfy. You can meet people and actually see them again after you’ve met them. You can meet the speakers, the organizers, the staff members at AIIM, the Board members of AIIM and you will have plenty of opportunities to talk with all those people. It’s also small enough to sell out, so if you want to go, get moving.

My presentation at AIIM 14 is titled “From Hoarders to Pickers and Pawn Stars” you can read about it here, but I think it will be better in person. One of the things people have told me that they like about my presentations is that I talk about things that go wrong, don’t work or cause problems. I also try to point out how we got those things back on track. You’ll hear a lot of real life experience at AIIM 14, told by the end-users, managers, CIO and VP’s who struggled through them and a few who stepped up and hit a home run off the first pitch.

In addition to hearing and talking and taking notes, I’ve made numerous connections at the AIIM Conference that are some of the most important people in my little network.

OK, I hear the “yeah, yeah, we get it, you’re going to AIIM 14 and I should too” comments and I feel the effect of hundreds of shaking heads. There are so many choices today when it comes to ways of acquiring information that I thought I’d share my favorite way with you. Next week, I’ll have another SharePoint Story – maybe about something that worked.

Episode II

Posted on by

imageShortly after I posted the first episode in this little mini-series on leaving SharePoint, Christophe a.k.a. @PathToSharePoint suggested that Office 365 might be the answer to the problems we are having. I responded, telling him SharePoint 365, sorry SharePoint Online will have a role in our future, just not this role. It is as if SharePoint Online had shown up for an audition, missed the lead role but got picked up as an extra on a different film. Hey, that’s show-biz.

The reason we looked at SharePoint Online was because we thought it would be easy. In some ways, it would be easy. Unfortunately, the ways in which it would be easy are the ways it would be easy for us. We already know SharePoint, so working with SharePoint in the cloud would be a snap. We already have the content organized in SharePoint so moving it to the cloud would be a snap. We already own MetaVis, so moving our on-premises SharePoint stuff into the cloud would be…what’s the word for a snappier snap…let’s say easy-peasy. The problem is that we’re supposed to be making life easier for our customers. How does that work for me?

Once when I was discussing two options with my boss, he summarized my arguments by saying:

“Let’s see, the business benefits are the same. Option one is expensive but it would be easy for you. Option two is cheap but it will be harder for you to work with. I’m going to go with option two.”

That’s the thing with business problems, the solutions are spread across a spectrum of benefit. If we can’t have the whole rainbow, we have to focus on our members and our customers first.

The big reason SharePoint Online would be easy is because we are going to use it for a part of our normal business process. We have some stuff in SharePoint on premises that requires high availability. Specifically, it needs to be available when our office is without power. We don’t have any redundant power options, so we have to create redundant content. The content is in SharePoint, the redundant content will be in SharePoint online, done. That works really well, but again, it works for us. There are ways to make it easy for our domain users to log into SharePoint in the cloud, but our customers aren’t in our domain. In order to get them to login, they would have to have some sort of Microsoft account.

As far as Microsoft is concerned, this isn’t an issue because everybody either has or can have a Microsoft account. Yeah, but that’s not really the case. Some people don’t have an account. Some of those people don’t want one. Some people have a Microsoft account, but it isn’t associated with their job.

I had to create a Microsoft account in order to work with an association I belong to. As an old boss used to say: “the process was 1, 2, 6;” in other words, a snap. I don’t use this account very often, but whenever I do, my first task is to delete about 100 pieces of junk mail. This is the last thing I want our customers to have to do in order to work with us.

In addition, for security reasons, some of our customers are prevented from using personal credentials to access content while at work and others are prevented from creating such an account that is linked to their domain email address. In our on premises implementation, we had a separate domain and we issued credentials when necessary. Moving to the cloud seemed like a step backward as far as user experience goes.

Finally, in addition to all of the above, if we did go with SharePoint Online as a solution, our content would be in SharePoint, duh. I you remember the original post in this series, the problem with that is that most of our customers, I’d say 95% of them; simply want to download files from our repository. They don’t want calendars, tasks, blogs, wikis, custom lists, metadata and workflows – just the files. When that’s all they want, you either have to spend time to make SharePoint look less capable than it is, or you are going to make your customers wade through a process that seems overly complex.

If you are a lover of suspense, stop reading. I’m going to spoil the ending of this saga. We have decided to use Citrix ShareFile for this application. I’ll explain why we selected it and how we use/plan to use that service in the final installment of this series. Until then, I can say that we are very excited about it, our employees are very excited about it and the customers we’ve spoken to are very excited about it.

Blah blah InfoPath blah blah

Posted on by

imageWow, has anything ever attracted as much attention as Microsoft’s decision to kill a mediocre product? My inbox is full of “InfoPath is Dead” and “Microsoft is Killing InfoPath” emails. I’ve seen Tweets, Facebook posts, invitations to join discussions on LinkedIn and invitations to attend Webinars practically every single day since the announcement was made. I get it! InfoPath will die in 2023. Guess what, I will retire before then.

The fact that I will be retired before then really won’t be considered as input to our decisions regarding InfoPath usage. As it stands today, we are making limited use of InfoPath in a fairly important project. In addition, we have plans to use InfoPath in a slightly larger, more important project later this year. I don’t see us changing these plans. Here’s why:

2023 – 2014 = 9 Years – Seriously, 9 years! That’s a long time. It’s not like “ding dong the witch is dead; click your shoes and go home.” The metaphorical Dorothy will be old enough to drink by the time she gets back to Kansas. We made an investment in InfoPath, and well before 2023, we will have achieved a return on that investment. That is what we are supposed to do isn’t it?

What’s on Other Roadmaps? – I realize that there are other ways to publish and process forms. Some of these alternatives are every bit as good as InfoPath, many are superior. If you made me choose a new forms platform today, I would probably start by taking a hard look at Nintex. We use Nintex’s workflow product and I imagine their form product works well too. That said, what’s Nintex’s plan for the future? Will Nintex Forms exist in 2023? Will the forms we produce with Nintex Forms today still run in 2023? Well, we really don’t know. In terms of vendors you can trust for the long haul, there really aren’t many. It’s not like they are untrustworthy, but what company can really say that they and their products will be here in 10 years? HP? Dell? BlackBerry (RIM)? Kodak? Go back 10 years and think about how those guys looked at the time and then consider how they look today. If you’ve been reading this blog, you might be surprised to see me say that I trust Microsoft, but when they say that they put something on a long, supported slide to the back door, I think we can believe them.

Now, let’s take a look at those scary emails. Here are some of the things they are warning me about and why I’m not concerned:

Support and Compatibility Questions Abound – Sure they do, but when haven’t they? Microsoft says that InfoPath 2013 will be the last version and support will end in April of 2023. As far as I know, they didn’t actually say that InfoPath 2013 and SharePoint 20nn will be compatible, but I’m not going to worry about that. Let’s assume that the next version of SharePoint is the 2016 version (I know they want to stop the “big release thing” but humor me). Chances are good that SharePoint 2016 will be compatible with InfoPath 2013. Chances are also good that we could run SharePoint 2016 until 2020 (we’re still running SharePoint 2010). Since we know that InfoPath is on a collision course with the trash bin in 2023, I’m pretty sure that my successors will have an alternative in mind before 2020. I don’t think they will be building any new InfoPath Forms in 2018-2020, but I think we can safely build them in 2014-2016 and still get that ROI.

No Certain Migration Path – In other words what if Microsoft creates a new Forms product and we can’t convert our InfoPath forms to that product. Well, that would be dumb. If Microsoft wants to play in the forms arena, they would be silly to alienate their previous forms customers. Still, since we know that Microsoft is capable of doing dumb things, I’ll accept this as a possibility. On the other hand, you have to ask: is there a way to migrate one forms product today to another forms product today? I am assuming that if we wanted to move to Nintex Forms today, we’d be recreating the functionality of our InfoPath forms on that platform. That’s OK. Also, that’s really the worst thing that can happen to us, that in 5-7 years we will have to recreate a form that probably will be due for a major update anyway.

A member of my team will be at the SharePoint Conference. We will hear about the future of InfoPath from the horse, and we will plan or adjust our plans accordingly. In the meantime, I’m not losing any sleep.

It’s Alive

Posted on by

iPad Screen shotWell I guess the phrase is actually “it’s now gone live” but that just doesn’t invoke the same emotional response. We have a business process that is now partially running in SharePoint. Even better, the right portion is running in SharePoint and the stuff that shouldn’t be in SharePoint is running somewhere else.

The business process is “payables” – something everybody has to do but something most people do differently than we do. See, we’re small, we don’t have a lot of vendors, we don’t have a complicated (no you can’t have that) procurement process and we don’t have a receiving dock. We buy things. We hire contractors. We incur professional fees. We refund premium on occasion and we reimburse people for things. We do this a bunch of ways. We have Concur (shudder and cue the foreboding music) which I actually kinda like. We do ACH transactions. We do wire transfers and we write checks. We also periodically reimburse people for small purchases with something called cash. I’m sure some of the younger readers are Googling that term.

The payables process, in addition to resulting in many financial outcomes, begins with a variety of financial transactions. Eventually, we will lasso all of these transactions and pull them into the same ring, but we decided to start with Check-Requests and checks. The process is pretty simple. We buy something from a vendor. They send us an invoice. We send them a check. In between step 2 and 3, someone studies the invoice, makes sure it’s legitimate, prepares a check request and then somebody else approves that request. That whole process, the stuff between step 2 and 3, is now done in SharePoint. Below are some of the cool things we (remember ‘we’ now means ‘they’ and stands for the shy people on my team) were able to include:

  • Maintaining a list of vendors that are automatically checked to make sure they aren’t on the US Treasury’s list of bad guys, and then approved by someone in authority in accounting.
  • Create a check request for an invoice(s) from an approved vendor.
  • Attach the image(s) of the receipt(s) to that check request.
  • Allocate the amount of that/those invoice(s) across multiple departments or multiple accounts within a department. For example, I buy a server, but some portion of the invoice is for the warranty.
  • Route the check request to one or more people for approval.
  • Do all the little checks and balances like making sure that the total of the allocations equal the total of the request.
  • Approve individual check requests for payment.
  • Allow the approvers to send the request back to the previous person to correct an error.

The tools used to make this happen include:

  • SharePoint external lists and the ability to impersonate users when working with them
  • InfoPath forms
  • Custom lists and views
  • Data View Web Parts to put the forms, lists and view on a single interactive page.
  • SharePoint Designer workflows to respond to the various activities a user did and to validate the transaction while it is in process
  • HarePoint’s Workflow Extensions to do some of the tricky stuff that SharePoint Designer doesn’t seem to do, like execute SQL Statements or use Regular Expressions to evaluate a sting.
  • Nintex Workflow’s “for each” capability to cycle through each Paid request in an external list to update our detailed custom list with the payment details.
  • All the various widget to widget connections you can establish in SharePoint Designer to get web parts to respond to other web parts.

We decided to use InfoPath instead of other techniques because we wanted a more functional form with less code buried behind it. I’m not sure that we saved on the coding effort, but I like the mix we are left with. We are trying to stay very close to the level where we can establish the action we want by “configuring” parts instead of writing code. It’s a fine-line kind of balancing act, but it works for us.

This just in, yes I know that Microsoft has put InfoPath on the short-line track to obscurity, but it will be around for a while and I feel that we risk very little by using it the way we do.

The reason I said that the right stuff is and isn’t running in SharePoint is central to our use case for having SharePoint and it is something that I think people often overlook – SharePoint runs in a browser. By building the front-end of this application in SharePoint, I can let people who are traveling submit invoices to be paid, approve payment requests and manage their budgets without having to write any web stuff. Also, since we have that Mass360 browser I talked about, I can approve payments on my iPad without a VPN connection.

The stuff that’s not running in SharePoint are those back-room accounting processes that nobody sees and everyone is content just knowing that they get done. Nothing to see here, move along.

Leaving SharePoint

Posted on by

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.