Our guest columnist today is , the Content, Collaboration & Communication Solutions Director for Siemens IT Solutions & Services. Chris has over 20 years of experience including management consulting, IT Strategy, Architecture & Implementation and business process reengineering. Recently, he has focused on the areas of Enterprise 2.0, Litigation Support, eDiscovery and IT Governance, developing solutions in these areas for Fortune 1000 clients.
[JM Note -- This topic is right smack in the middle of two new communities that we have recently launched at AIIM -- one on Electronic Records Management and one on Enterprise 2.0 Technologies. Check them out; join the conversation.]
If you’re like most companies these days, you’re in the midst of deploying collaboration tools, such as SharePoint, in an attempt to meet users demands for more open communications. At the same time, you’re probably maintaining an array of legacy records management systems, deployed a decade or more ago, which are used to manage a specific subset of data in a very specific way. If you haven’t already noticed, these systems are like oil and water.
To provide some guidance on how to balance the conflicting goals of collaboration and records management, I offer the following considerations:
8 Ways to Balance Collaboration Efforts with Traditional Records Management
1 -– Good Governance is Of the People, By the People, For the People.
There seems to be little argument these days over the importance of Governance for both Records Management and Collaboration. However, many people are wondering how to staff up and manage a Governance council. Here are some simple rules of thumb:
- Governance teams should be staffed 20% by IT, 80% by the business
- 80% of the work will be done by IT, 20% by the Business
- IT knows what questions to ask, but doesn’t know the right answers
- The Business knows all of the answers, but doesn’t know which questions need to be asked
It is absolutely critical that business people, as users of collaboration tools, directly participate in governance of any collaboration platforms. Without their active engagement, they will not understand, and will never support, the degree of structure and control that IT knows is necessary for proper management of an environment. So, keep the business engaged, but understand that IT will still be responsible for the bulk of the work performed by the council.
2 -– Good Governance is Invisible.
Most people don’t like being told what to do, and this is particularly true of people who thrive in collaboration environments. While most records management systems have A LOT of structure, rules and controls, if you’re going to drive adoption of a collaboration system, you need a lighter touch.
To achieve this, implement structure in such a way as it isn’t visible to users. This happens through appropriate design of information architecture, data classification, access rights, etc., but the key is to make people THINK that they’re self-provisioning, even if they aren’t.
Next, make maximum use of automation. A successful collaboration environment will grow so quickly that manual intervention will be impossible. So, build governance such that new rules can be defined and implemented invisibly, and automatically.
Finally, do not ask users to govern themselves: They can’t, they won’t, and they shouldn’t.
3 -– Best-In-Class Solutions Yield Worst-In-Class Results.
Most companies are maintaining what I call “Noah’s Software Ark," where they implement 2 copies of every software package in the world, in an apparent attempt to save each “species." It is common to find 10, 20 even 100 different platforms for content management or collaboration in a single organization. Further, it is common for those same companies to complain that they can’t find anything, their systems are too fragmented, governance is impossible, etc. Well, duh!
Point solutions, while appearing to be simple, bring massive redundancy in functionality, hardware, software, administration, and of course, cost. They also prevent meaningful enterprise-wide governance and collaboration. So, whatever your plan, make sure that it includes rationalizing your environment and “cull the package herd” as much as possible. Technology platforms such as SharePoint make this easy.
4 –- Speeds & Feeds are Dead, Laws & Regulations Rule.
Remember the old days (say, 2002) when you would agonize for weeks or months over where to place your servers, how much bandwidth was needed between location A and location B, how much storage you would need to buy, etc? Those days are dead. Now, compute capacity, bandwidth and storage are as hard to come by as sand in Arabia. Heck, you can’t swing a Gucci iPad bag around your head without hitting someone’s compute cloud!
Infrastructure planning is no longer about speeds and feeds. Rather, placement of systems and data is being driven by a new set of constraints: Laws and Regulations. Sound dubious? Note that at least 44 of the United States have implemented privacy and data protection laws, as have dozens of major international markets. Ignore these requirements for managing corporate data at your own peril. And, for those of you who think Safe Harbor will protect you, think again. Recently, Safe Harbor has been shot so full of holes you could start calling it PEARL Harbor.
5 –- Packages are Prisons, Set Your Functionality Free.
IT is very package-oriented. Tell an IT person that you have foot fungus, and she’ll tell you, “There’s an APP for that!” But, what the business is asking for, and what IT is hearing are VERY different things. Business people are usually asking for a capability, NOT an application. Unfortunately, since most capabilities are bound up in software packages, that’s what IT goes out and buys.
The evolution of software over the last 10-15 years has been focused upon platforms… J2EE, .NET, etc. These platforms, if properly implemented, allow IT to build capabilities that can then be pieced together, Lego-style, to create virtual-applications. Virtual, because once the app is done running, the components disassemble and return to the background, waiting to be used again for something else.
Sound good? Good. STOP buying packages, start building platforms and start dragging your APPs to the Trash can.
6 –- Federation is Fool’s Gold… Rationalize and Simplify.
If ever there was a snake-oil-salesman in the digital age, it’s the person who claims that they have a great federation tool. No matter how transparently you can connect two different systems, one truth will always remain: Garbage In, Garbage Out. Most IT systems are poorly designed within themselves. Start stitching them together and you’re diving down a digital rabbit hole from which you may never emerge.
Federation itself is not a bad thing. Rather, federation without rationalization is a bad thing. Before tying together two or more systems it’s important to fix them independently; driving them towards a balanced, middle ground. To do this, you must first DEFINE this middle ground, and this requires a focused effort to define global requirements for information architecture, taxonomy, and business rules. Only once you know where you’re going, can you take a step in the right direction. If you don’t know where you’re going, any federation tool can get you there.
7 -- Taxonomy Alone is a Content Jail, Folksonomies Alone are Gibberish.
Heavy-handed taxonomies, like those in traditional records management systems, make those systems user-hostile. Make a system hard to use and voila, people won’t use it. The answer to this problem appears to be the free-flowing folksonomies of collaboration systems, where everyone organizes things their own way. In reality, if thousands of people are classifying information their own way what is the likelihood that the results will be better than no classification at all? This approach is cute for finding funny photos on some foto.com site, but for corporate use, it is sorely lacking.
So what’s the answer? The best approach is a balance of both, where a structured taxonomy is in place to provide a “tree” from which users can hang their own “leaves” of Folksonomy. The folksonomies live within enough structure that they’re still useable and meaningful to the business, but not so restricted that they wither and die. Are you noticing the theme of balance, yet?
8 –- Abstraction Equals Adaptability.
In any design effort that you undertake, follow this one rule: Abstract, Abstract, Abstract. Whether its data, workflow, access rights, rules, roles, etc., the more that you abstract specific values from their specific use, the more flexible your resulting solution. In other words, don’t hard-code the 50 states into a system, rather, design the system to recognize “states”, and there may be 50, there may be more. It sounds simple, but few designers use this principle as maniacally as they should.
-----
Some recent posts from our ERM and E20 Expert bloggers that relate to this post:
Recent Comments