SharePoint Customers Playing ‘Match Game’ with Providers

Say the word “SharePoint” in IT circles these days and you’ll be met with free-association responses that are as contradictory as they are predictable:

Easy to use … difficult to manage … pretty solid … hard to understand … the latest Microsoft plot to take over the world

Ask, however, about the purposes to which SharePoint is to be put and a much clearer picture emerges:

Content management … collaboration … portals … business forms … search

We know this because we’ve spent the past several weeks asking these questions, formally and informally, and then diving deeply into the world of SharePoint partners to see how their statements of value match up against the responses we received. The result? A typical misalignment of marketing message and market need. Here’s what we found:

Among the Partners

• An awful lot of SharePoint partners – say, a third of them – seem hard-pressed to use the word “SharePoint” properly in a sentence. They’ve done a fair-to-middling job of repurposing Microsoft’s official verbiage, and that’s about it. Consequently, nothing stands out about what differentiates them from the 999 other firms they nominally compete with, nor what need SharePoint may have been designed to fill.
   
• Another 20% or so appear to have focused on one or two of SharePoint’s numerous capabilities, and have done so to decent effect. Most of these highlight content management, collaboration, and, to a lesser degree, process improvement as core strengths, a proper and solid mix for most customer organizations.
   
• The remainder come across as the consultants most of them are, talking about their stellar ability to listen to their customers and develop solutions that are optimized for each situation. Not that there’s anything wrong with that (see Seinfeld, Jerry), but it can leave the reader wanting, and it certainly does presuppose the customer already knows what he or she wants.
  
  And therein lies the rub.

Among the Customers

• If the participants in a recent AIIM webinar are any guide, nearly a quarter of organizations either are still learning about SharePoint or are considering whether to deploy it. These people are hungry for as much fluff-free information as they can get, not only about the product but about how to think about what they most need. They likely know SharePoint can do a lot of things, but they may not know which of those functions will do them the most immediate good. Offers of meaningful help thus are gratefully accepted.
  
   
• Those that do have an idea – between half and two-thirds of our Webinar participants – say they’re looking to SharePoint primarily to handle content management and collaboration, followed by portals, search, and business forms in relatively equal measure. That content management scored so high may not be a surprise given that the question was asked of an AIIM-centered audience. However, business forms’ strong showing is interesting because they tend to be represent the great stealth need: never appearing in an inquiry or specification but needing to be dealt with right away because they’re central to most business processes.
  
  
  
  Sadly, very few SharePoint partners mention forms at all, even though the capability is baked-in via InfoPath.

• Besides being great for jump-starting workflows, electronic forms also work wonders for organizations seeking to reduce paper. However, it turns out that relatively few of the organizations we polled are thinking that way. Only one-third reported having a paper-reduction program in place, and 14% said they are too overwhelmed by the possibility to even think about it. So SharePoint partners leading with the environmental savings associated with moving from hard copy to soft might want to reconsider – not because the logic is wrong, but because people have other priorities right now.
  
  
  

Conclusion

At the end of the day, our foray into the market tells us that SharePoint partners overall can do a better job of matching their value propositions to the needs of their intended customers, and bringing out areas of associated value along the way. This issue isn’t endemic to SharePoint, of course. But it is worth bringing up because of the messaging onslaught we’re about to experience with the release of SharePoint 2010, which will only pile questions about the differences between the 2010 and 2007 editions on top of the questions so many organizations already have.

If only Gene Rayburn were available to moderate …

InfoPath: Where e-forms meet Sharepoint (comin’ thru the rye)

As much as recent perambulations around the edges of the forms arena have confirmed that so much hasn’t changed about organizations’ appreciation for and use of electronic forms (see post of February 9), so they also have opened the gates between what once was an administrative backwater and the more mainstream world of IT. This isn’t to say that today’s forms administrator is tomorrow’s CIO – far from it! – but for those who are so attuned, the separation between the roles is beginning to narrow.

For example, not too long ago, I asked in several places (including the AIIM and Xplor groups on LinkedIn) where forms become something more in the scheme of content collection/presentation (like, say, personalized brochures/enrollment kits), and the answers were varied and interesting.

Today, I’m moving in a different direction to gauge how e-forms are being leveraged in the Sharepoint world. Specifically, I’m keen to learn how best to move forms into InfoPath, and I’d like to pose the couple of quick questions below about your experiences so I can compile an insider’s lay of the land. Even some short, quick bullets would be really helpful, so please comment and/or email me at sweissman@hollygroup.com. Thank you!

- Are you starting from scratch in InfoPath, or are you converting from paper or a different e-format? (Jetform, PDF, etc.)

- Are you trying to re-create the layout of a specific paper form, or is a regular online form OK? (trying to learn what the latest thinking is about this)

- Do you need only simple fill and submit capabilities, or do you need programming for calculations, validation, database lookup/entry/reporting, etc. as well? (don’t know how much harder it is to do all this vs. not)

- How long does each form take to finish? (I know it depends, but is there a rough guideline for planning purposes?)

- Who’s doing the actual work? (by title or function)

- What is especially straightforward or challenging about moving to InfoPath forms? (forewarned is forearmed!)

Stay tuned for more. Thanks!

In forms and forms conversion, everything old is new again

Thanks to a new client, your humble servant has been spending a lot of time lately in the realm of forms and forms conversion, and it is nothing short of amazing to see how relatively little has changed since my introduction to this space 20 years ago.

This isn’t necessarily a bad thing, since a great deal of what hasn’t changed has to do with the fundamental value associated with ‘electronifying’ paper forms, tying them tightly to some form of routing or workflow, and using them as front-ends to databases (for both information input and output). This all was a good idea then, and it’s all a good idea now. Period.

More good news: the tools required to move forms from paper to screen (and to stay there) have gotten better and better, and not only are they are making e-forms more accessible to more people than ever before, they’re becoming increasingly crucial to business-critical applications in core industries like financial services, insurance, and health care.

But here’s the kicker: too few people still seem to understand that a form that doesn’t work well on paper won’t work any better on screen. If the design is confusing and the wording is unclear, the e-outcome still will include incompletions, inaccuracies, and other productivity-sapping, time consuming, and potentially costly errors – perhaps in record volume given how much easier it is to distribute forms electronically vs. physically.

Further, there’s more to converting from paper to “e” than simply scanning to PDF – sure that can get the ball rolling, but the ultimate goal isn’t simply to recreate a form’s look-and-feel in the new medium. Instead, it’s to activate the form’s fields so they can check for errors, apply formatting filters, and properly populate some back-end system with the information filled in.

Happily, these nigh-exclusively and heavily programmatic tasks of 1990 are now well within the ken of any half-savvy forms designer or line-of-business manager. However, too many of them don’t yet know it, and – despite the best efforts of Adobe and other, now mostly departed, vendors – they remain stuck in the scan-to-screen mindset.

This tale is told not so much to lament the cloud of non-understanding that still seems to shroud e-forms adoption but to remind us to keep up with the latest technologies while remembering that they are not magic bullets. At the end of the day, it is your experience and expertise that will make your new systems sing – but only if you are both alert to their presence and sufficiently adept in your craft to understand what they can and cannot do.

Just as it was 20 years ago.