Clouds and rain in the ECM/BPM forecast

“There must be a cloud in my head – rain keeps falling from my eyes.” - Dee Clark, Raindrops

Users and investigators of today’s content and business process management technologies must be near tears as they endeavor to sort through their options and plot a course for the future.

Should I work with a single vendor or take a “best of breed” approach? Is open source a credible alternative? What happens if I do/don’t go the SharePoint route?

Every question being raised requires a great deal of operational analysis and organizational soul-searching to answer, and the pressure is on to come up with responses that are consistent with your company’s philosophy and culture. However, there is one that stands out as being especially important, for it speaks to longer-term strategy-setting and strikes directly at the most sensitive subject there is:

What about this ‘cloud computing’ thing I’m hearing so much about?

For those of you who’ve been out of town, the ‘cloud’ is broadly said to be where the servers of the future will live as they happily run your applications and connect to your users via the Internet. The big issue it raises is what the military calls “command and control,” or the setting of direction for, and the exertion of authority over, a given mission.

Imagine signing a ‘cloud company’ to manage, maintain, and upgrade your content and process automation servers: how nice it might be to shed all that responsibility and cost! But it will come at a price that many business executives and IT managers are loathe to pay: the loss of direct day-to-day control over, and future development of, this critical central resource.

Plenty of folks – including yours truly – already are feeling this sort of discomfort, even in the much less business-critical context of managing our personal calendars. In my case, it’s a function of wanting to synchronize my Thunderbird client (using the Lightning extension) with my iPhone, something that appears to be most efficiently accomplished only by syncing both with Google.

Does it make me nervous that my appointments are being housed on the Web where ‘anyone can see them,’ that there’s no real file I can copy locally and use as a backup as I used to, and that someone I don’t know and can’t reach can make changes at anytime that could cost me money or displace me altogether? Yes, yes, and yes – and I can only imagine what a wreck I’d be if my company’s content and process flows were subject to the same uncertainties.

Ironically, I remain convinced that we all eventually will procure computing power in the same way we now buy electricity: on a subscription basis via an outlet in the wall. Precisely how we get from here to there still is a question in my mind, but the emergence of the ‘cloud’ sure does seem like a step along the way. Just be sure you keep your eyes open as you progress down the path, for it’d be a crying shame to make an avoidable mistake.

What Doesn't Work: 5 Steps to Requirements Document Oblivion

AIIM’s Atle Skjekkeland recently listed five steps for producing an ECM requirements document. In the interests of full disclosure – and a small bit of fun – here’s my counterpoint to his solid recommendations, as drawn from the pages of the Big Book of ECM Blunders.

1. Avoid “paralysis by analysis” and charge full-steam ahead. Don’t do so totally without a plan, but don’t wait for every “t” to be crossed and “i” to be dotted, either. Time is money, after all, so get after it as quick as you can. And besides, people will let you know if you go off course.

2. Reality-check your suspicions as to what your ECM system should do by asking a few other people what they think too. Four or five should be plenty, especially if they come from different departments – and extra especially if they’re the department managers, who can represent the views and experiences of all the people who work for them.

3. Look at the answers you get and compare them to the ideas you already had. If they’re different, that means you’ll have to design the system to do more than you first thought, and thus will have to allow some extra time to finish the job. If they’re largely the same, that means you know exactly what’s to be done and probably don’t need any more outside input.

4. Write down everything you know about what the system needs to do and which functions are most important. Since you’re driving the project, don’t worry too much about how you structure the information or even what you call things – just be sure you know what you mean, and that you look at this document every so often to be sure you’re staying on track.

5. Now that you’ve talked to everybody and documented their input, you’re ready to start building the solution. Good luck!

Good luck, indeed. A recipe for disaster if ever there was one!