ECRM Software vs ECRM Solutions

The end of the year is looming, and many people tend to reflect on topics large and small - good things that have happened to them, usually, but also those "tics" large and small that seem to stick in one's mind.  A recurring theme that seems to sound like fingernails scratching a blackboard to me is the tendency to term ECRM software as a "solution".  You know the mantra:  "Our Acme All-In-One magical software solution will answer all your needs and desires to implement an information and records management program."  To believe the sales hype is to believe that all you need to do is purchase the magical software and your RIM problems are solved.

Now, I certainly understand the need for catchy phrases and terminology in the sales and marketing realm for any product; perception is important, your product must stand out by having a sense of strength or dominance in its given industry.  What concerns me is the tendency of even impartial commentators to use this term - even the well-respected Gartner Group has been known to use "solutions" when referring to various software applications, albeit in general terms and not to specifically call out an individual product.  To me, this only heightens the perception given to those intrepid records managers, IT and compliance managers and others who are ardently searching for a true solution to managing their information.  There has been a tendency over the past few years to perceive software as the answer; I believe this approach was strengthened with the advent of ECM/ERM/ECRM software development that was considered as quite advanced and complex - and complexity often seems to imply "heaven-sent" resolution to all life's ills, as in "I don't understand what I need so will take this as my solution - it must do everything I need."  There seems to be a tendency to believe that the software application provides all the pieces to the solution puzzle, rather than being just a piece of the solution. 

There are certainly many excellent ECRM products available, with tremendous capabilities.  But, at least to me, are tools, not solutions.  In order to develop a successful RIM program, one needs strategy, buy-in, policies and procedures, plans, AND the tools to implement and deploy the program.  Software is one of those tools, of course very likely an expensive, central and powerful tool.  I will concede that the term "tool" is not very attractive on its face - not a marketable term.  But even when I try to rationalize the term "solution" with some sort of clarifying statement, it still rings a bit hollow or at worst weakens the entire comment about the product.

But education and knowledge about developing a RIM program in general should alleviate some mis-perceptions and re-weight significance back to the need for developing all aspects of proper records management.  If only a true "solution" to a company's RIM needs could come in a package, holiday shopping would be much simpler.

In A Rage Over Information

Craig Roth from Gartner posted interesting comments about Information Rage, a term cooked up by editorialists in New Zealand regarding the stress felt by knowledge workers over what used to be called "information overload".  Mr. Roth correctly called out the writers of the opinion piece for dramatizing the issue and seemingly mis-interpreting comments made by interviewees.  While many of the individuals interviewed mentioned "giving up", it is highly unlikely we will see a mass walk-off of employees who will prefer not working and no paycheck to dealing with their information management issues.  This is wonderful fodder for some media folk to feast on, especially as the US mid-term election hoopla recedes, but as Mr. Roth ably points out there's a lot of noise here with poor substance.

My thought is that knowledge workers aren't frustrated so much by too much information, often aptly and comically referred to as TMI; rather, I tend to think the frustration is finding the right information when the users need it - maybe they are suffering more from "search overload" than information overload.  I do know that I am happy when I stumble across, or am rewarded with an abundance of hits when searching for information on a topic - when the results are accurate and applicable.  It's the lack of results, or irrelevant information returns that really bug me...having to sort through 10 pages of stuff to find one or two applicable bits of information, for instance.  I relish the fantastic reservoir of information we have available, literally at our fingertips; and I often look forward to embarking on a quest to discover information about a new topic, or more information than I thought existed about something I am familiar with.  But there are times when I am also frustrated by the surfeit of incorrect or irrelevant "stuff" that can pour onto my screen, seemingly mocking my attempts to just "get the facts".

Maybe this is just another way to talk about, and implement, appropriate information management practices - learning how to find what we want when we want it, but also learning how to shrug off or shut out the noise that comes with such instant and comprehensive access to information.

2D Barcode Technology Still Needs Facetime

New technologies and technological capabilities seem to have two lives, or perhaps more - initial excitement, dormancy and finally acceptance or oblivion.  The lucky ones have that quality or moment that their creators crave - the tipping point as Malcolm Gladwell so described, when the technology, program or especially now the cellphone-directed app takes off and becomes the latest "must have".

2D barcode technology appears to be in a sort of "dormant but pulling out to acceptance" phase.  There was a burst of media attention followed by what seemed to be silence, or a settling in as the technology searched for its place.  Now, the advertising world is ramping up to find more and more innovative ways to use this app to direct potential customers to their sites, products and events.  The NYTimes reports in a Science section article that the barcodes are appearing as part of an ad campaign at the Albany, NY rail station.  The barcodes ads are attractive and eye-catching, but as one person who actually scanned a barcode noted, she appeared to be the only person doing so.

I had a similar experience at the recent Bayou City Arts Festival held in Houston, TX - exhibitors were provided with an 8x11 sheet of paper with a 2D barcode that would allow festival attendees access to the individual exhibitor's website by scanning the barcode with their smartphones.  However, I had viewed almost all of the exhibits before I noticed a barcode posted at a booth.  Once I was aware of the fact that most, if not all of the exhibitors were given barcodes, I went back through the festival to see if I had just missed the postings.  However, my very unsophisticated search found perhaps less than 10% of the exhibits that had posted the barcodes.  When I asked some exhibitors at random why they had not used the barcode, they responded with complete surprise - if they had been told about the barcodes and what they were, they had missed the point or had not understood how to use them at all. 

This is a technology that certainly seems, at least to me, on the cusp of becoming a standard - perhaps an evolution of hyperlinking, especially due to the fact that the barcode itself can contain so much more information; instead of just a "flat" link to another site, the 2D barcode is already being used to gather statistics in new ways for the implementor; direct users to a store or even to locations and products within a store; provide instant discounts on products, provide pricing benchmarks and many other innovative and new ways to market products and ideas.  Now the challenge is to make it "tip", when consumers and users embrace this technology as their doorway to products and ideas.

Building Blocks or Stumbling Blocks

One of the mantras often stated in the RIM industry is the need to gain "user buy-in"; this is a great concept, quite necessary for the success of any RIM endeavor.  Obviously, if the user doesn't use it - whatever it is, software, policies, processes, whatever - it won't fly.  So we often hear that it should be designed around user needs, but often those needs are defined quite narrowly.  Steps may be initiated to conduct interviews, utilize questionnaires and so forth, but there are basic preliminary questions that need to be addressed as well, outside of "What do you do?", or "What types of information do you handle?", capabilities that need to be in place to ensure that users can and will use whatever you have developed or implemented.  Some of the information that I think needs to be gathered up-front include:

Can all users gain access to it? 
This is User Buy-In 101 - if they can't get to it, they ain't gonna use it.  And all of your hard work defining metadata, identifying information types, building taxonomy/folksonomy structures, are for nothing.  If you are using SharePoint as a collaboration tool or for other activities, do all users have the capability to access the intranet site?  Same with documents posted to your website - are you certain all employees have easy access to the web?  This is not a frivolous question, especially when you consider security walls at client sites, employees at remote locations, etc.

Can you adequately identify necessary and understandable metadata?
Metadata has to adequately identify content, but it also must do so in a way that users understand and relate to.  Both the metadata label and metadata content must be stated in terms that are understandable and sensible to the users.  Closely related to this is....

Have you developed robust standardization of terms?
Although the next question, regarding synonyms, removes much of the agony over this process, standardization is still a necessary component of naming process.  Employees are now very mobile, both due to the ability and willingness to relocate, and due to more extensive cross-training within companies.  So users need to have the comfort of seeing similarity in not just processes, but also terminology as they migrate from one geographical location to another, or from one discipline to another.  Standardization calls for comformity driven by accepted business use, established user terms developed over a significant period of time, and other drivers of commonality.  Colloquialisms should be relegated to the synonym function whenever possible.

Are you able to allow for the use of synonyms?
I grew up calling all soft drink beverages "pop", common in the northern part of the country at least.  When I settled in Houston, and used that term, all I got for a response was a blank stare, if not giggles and head-shaking, until I learned to use the term "soda".  Similarily, the ability to implement synonyms are almost mandatory in new applications, metadata and especially search capabilities.  An additional benefit is the avoidance of extended struggles over standardization of terms, and bad feelings for those whose terms are rejected in that process.

Have you allowed for adequate/multiple access?
Again, the users must be able to access whatever it is they need when they need to.  There must be sufficient bandwidth, adequate numbers of licenses, availability over multiple time zones - many accessibility considerations to be resolved.

There are many other, more detailed considerations to be addressed - these are just some of the things that must be in place to ensure that initial user buy-in.  The goal at this point is to allow them to get where they need to go, when they need to do so, and begin the process of accessing and utilizing their information.  And, to state once more my mantra - nothing will work without user acceptance, and cooperation among all involved.  One of the only actions I know of that is highly effective from a top-down aspect with no user input is the firing squad - probably not a good option.

Getting the Horse to Drink: How to Obtain Policy Buy-In

I just read an interesting blog written by Craig Roth of Gartner, regarding strategy for gaining buy-in for SharePoint impementation.  Mr. Roth gave compelling arguments for using the "outside-in" approach, which is basically going out and ascertaining what the customer or user needs and then developing strategy, as opposed to the (obvious) "inside-out" technique of developing strategy and then pushing it out to the user.  Mr. Roth's view was based on an earlier article and book by George Day that fully outlines the outside-in approach for customer value.

This approach is valuable on so many levels, beyond software implementation or customer service; it seems to be a great fit as a core strategy for business development, internal and external, on all levels.  Naturally, there are reasons for top-down strategy implementations when needed, especially to address critical or immediate issues - mandatory changes in security access during a critical event, for example.  And even less-dramatic instances as well, possibly an update or change in some HR-related policy.  But for many, if not most user-activity processes, input from the "outside" - from the users or target audience, is critical to the success of the policy implementation and compliance.  If a policy, process, tool or what-have-you, does not fit the criteria established by the users' needs, the implementation will languish, be overly costly, or just plain fail.  Strategists and planners - the insiders - can possess the knowledge in information related to feasibility, cost and so forth, but they do not necessarily have a clue as to whether what "looks good" is right for their needs.  SharePoint, as an example, is feature rich, especially in the 2010 model; but which features are right for, or needed by the end users - what is applicable to the user's needs, and what is a waste of time and energy?  A policy that states all users will share documents through links in an email message as opposed to attachments is great - it saves email space, reduces document redundancy and copies, lessens the false dependency on email as a records management tool, etc.  But what if some of your users are in an environment where they cannot access the linked repository - for instance, in a client setting that blocks access, or a 3rd party partner in a remote location with limited web access?  Then the policy is unenforceable, and the procedures are unworkable.  However...if the "outside-in" approach is followed, the planners will become aware of these obstacles and (hopefully) adjust accordingly.

The old, well-worn adage about being able to lead a horse to water, but not being able to make him drink is applicable.  Perhaps one should think of this in new terms:  If a horse is thirsty, you don't need to lead her to water - she'll go, and she'll drink.  In the same manner, if a policy, tool, process, whatever is applicable and of value to the user, that person will use it - the manager, strategist, policy-maker or whomever has an obligation to talk to that user and find out what works...explain the situation, then ask what will work from the user standpoint, and ultimately incorporate that viewpoint or need into the final decision.  The business community is hopefully in an age of more openness, transparency and interactive communication; everyone should optimize those traits to engage the users as well as the planners.

RIM Policies in Context

Tom Davenport had an interesting post about context recently, in which he shared the importance of understanding how we might better understand the manner in which recent political leaders arrived at global decisions, when we probe into the context around them - who was consulted or not consulted, what disparate views were presented, etc.  This type of analysis can be applied to RIM policy development as well; are the policy writers and decision-makers considering all of the context around the development of their policy statement, or are they blinkered by specific activities within the company that they want to address or rectify?  Who are the participants when asking for perspective or review of the statement...are they representative of only one specific thought-process, seen as supporters of a pre-defined direction for the policy, or are there disparate voices being heard?

I am most likely thinking at the moment in terms of policy that attempts to address some of the more current RIM issues, especially regarding the use of the cloud to store documents - where users are downloading app's onto their business computers, smartphones and possibly home computers to allow access to documents.  The intent here can be completely straightforward and honest; perhaps the employee is a road warrior, and has had too many instances of needing to quickly collaborate with a co-worker on a document but cannot rapidly or easily power up their laptop - how great to be able to view and edit the document in synch with the co-worker right from their phone.  Or, another logical argument is to utilize the capabilities of these app's to minimize the need for overloading the company's email system with attachments.  The arguments for usage go on...as do the obvious concerns for records managers, attorneys, compliance and so forth.

My thought as stimulated by Mr. Davenport's excellent blog, however, is whether a company will tend to construct a policy with a pre-ordained slant towards addressing only the risk posed here, and not thoroughly review the context surrounding the use of this technology.  For instance, if the company decides to ban the use of the cloud-sharing technology, have they given an honest appraisal to whether this practice is actually in use today by their employees?  Is it a technical process that has already gained value for their work?  Will they simply drive their employees "underground", where the technology is secretly used, with documents going totally outside the realm and reach of compliance?  Practices that work for employees seem to not disappear...there will always be ways to work around a policy that might not be in the company's best business interest.  Of course, risk and possibility of highly damaging loss to the company must be a major consideration when establishing policies.  But well-thought-out and constructed policies can ensure that practices are in line with requirements, and can provide stronger management of information.  For instance, a policy can provide the direction for the development of extremely thorough procedures for identifying what app's are allowed within the company, who uses them and where to go to find the information when necessary - litigation activities, employee termination, etc.  The policy can ensure that data maps are complete, that employees are acutely aware of their responsibilities as well as the repercussions for neglectful, improper or illegal use of the technology.  Sometimes a policy must be in place to restrict activity, but perhaps a healthier and more successful approach is to know when to work with new ideas and processes, not shun them through lack of contextual knowledge.

Maintaining Records Destruction Logs

At one point in my career, I participated as a records manager in a project for a major automaker, and enjoyed many stimulating conversations with the Corporate Legal Counsel.  The attorney, a very competent individual who was well-tempered in the litigation arena, had very definite opinions that of course were relevant to the company and position he served and not intended as generic guidelines.  And he was very self-confident in his ability to support his position with the backing of a global corporate presence.  One of those conversations centered on records disposition, and how best to maintain destruction logs.  The attorney's position was that the company was not to create a records disposition log of any sort; his reasoning was very simple and straightforward - the company's records retention schedule was the official documentation of what records were maintained by the company, as well as the map of when documents would be destroyed.  He felt that, in the event of discovery, the company could reliably state that any requested records that would qualify as having been destroyed BEFORE any litigation hold would have applied, were in fact destroyed according to the retention schedule.

Over time, I have concluded that his position, while admirable in its "strength", may not be the best road to follow.  However, I do endorse his thinking in terms of what to document - as an attorney of long standing and great experience, he was a master of the philosophy of "give no more than necessary, and no sooner than necessary".  In this case, he felt that most destruction logs contain too much information, and is just another door left ajar for others to peer into the company's realm.  So I do think it is perhaps best for a company to maintain a destruction log, but one that is concise and precise while of course serving as a valuable tool as proof of proper RIM activities.

Mike Alsop has a very informative PPT presentation that includes a slide pertaining to this.  He also believes in the "minimalist" approach of including only information such as a document ID, significant document lifecycle dates, and system-generated metadata for the destroyed documents.  A properly maintained destruction log can then serve as supporting documentation to the litigation hold process as well, by at the least verifying that no relevant documents were recorded as destroyed once the litigation hold was initiated.  Of course, no single document or process can completely ensure that rogue activities will not be performed, but tools such as this destruction log can establish a level of trust in the consistency of the RIM program and the operations around it.