I attended an educational seminar recently, which was targeted at records managers. Being the "technophile" that I am, I signed up for a number of the technology sessions that had been described in the conference brochure as "document management" discussions. I was astounded to find at one of these sessions that a document management software was being presented as a "workflow" solution, and at another session, that an imaging product was being called a "workflow" product. I would not have expected either session to have anything to do with "workflow"; and neither did the sessions deal with "document management," the advertised topic for the seminars.
A ROSE BY ANY OTHER NAME
I find it troubling that the "definitions" of what constitutes a "type" of software product are being treated cavalierly by vendors and consultants alike. Of course, not all would agree with me. Some would argue that the categorization of software products is useless anyway. Software changes so quickly, who can keep up? Some would say that the lines between types of software products are "blurring" and are therefore meaningless.
Let's explore that rationale. If you were going to buy a car, would it make a difference whether it was diesel-powered or gas-powered - even though the "functionality was "the same"? Of course! Although the difference is an apparently "small" one, a diesel engine could pose some significant problems for you - especially if no one sells diesel fuel in your area, or if no one understands the mechanics of what is under the hood of your brand new, diesel-powered car.
Similarly, a bicycle and a car will both move you more rapidly than walking, but one is very different from the other; the car "automates" the function, and the bike leverages the existing physical capabilities of the rider. If I'm looking for a mode of transportation and I have bad knees, a bicycle may not be a good choice.
Further, if I need a car, does that mean I have to buy a Porsche? Maybe not. Maybe all I need is a second-hand, four-cylinder "puddle jumper" to get groceries from the store down the street, and not a high-powered, top-of-the-line sports car. It might not be necessary to go to the store at 150 miles an hour. So, where do "functions" and "requirements" meet?
My argument is that the lines between products may blur (and will certainly change and evolve over time), but the differences between products are still significant because an organization's requirements are different - in which case, the definitions matter. It's my starting point for deciding what to look at.
Let's get back to the discussion of software products. Generally, products which deal with storage and retrieval of images have been called imaging products. Document management products deal with the management and retrieval of electronic documents (usually word processing or spreadsheet items which are stored on the Local Area Network). And workflow technology is actually something which integrates other technologies, including imaging and document management potentially, into an overall business process and a "common user desktop."
These things are not all alike. So, what gives?
First of all, it's fascinating that records managers are being provided with this kind of technology information. Perhaps the world at large has decided that those who actually are the information experts within organizations should also understand the technologies that are geared toward managing that information. This is a good thing, and to be commended and encouraged.
The disappointing part for me, as one who has worked for the past eight years in the technology field, is that a significant portion of the information which I have seen presented in a variety of forums is "misleading." This is not a deliberate conspiracy. It is a manifestation of the confusion growing out of a combination of the rapid changes in software products, and a "blurring" of the lines between one type of product functionality and another. …