Addressing the Fragmentation Problem

Let’s call the challenge we’re discussing the Fragmentation Problem. It’s primarily the outcome of the explosion of “systems of engagement”. “Systems of engagement” (SOE) is a useful popular term to distinguish the collaborative and social technologies from the older “Systems of record” (SOR) that most of us in ECM are familiar with. (And when I say SOR it doesn’t mean that I’m confused about what a records manager’s record is – it’s just a useful term.) The SOEs and associated trends include mobile applications, social media, wireless access, “life splicing” (integrating professional and personal life), multiple BYOD devices and platforms, synching all devices by using the cloud, and consumerization.

Such trends are the primary cause of the Fragmentation Problem, which shows itself in uncontrolled diversity, failed enterprise synching (a problem way beyond desktop synching), and other SOE problems like content getting stored in multiple locations, multiple and varied content formats, no security control, no version control, no process control, no backup, and failed access. What we want to do is maximize the upside of these new realities while minimizing the downside – increase the benefits while decreasing the costs and risks.

As a preliminary step, we can divide the Fragmentation Problem into 2 pieces, General Adequacy and Specific Business Applications:

• General Adequacy:  What should we do to ensure “general adequacy” – ensure that we have established a baseline of adequacy for our new IT environments? That is, independent of any particular work process or business unit application (like using “Social Collaboration” for marketing or HR), what good housekeeping practices should we adopt? What are the necessary, foundational, minimal conditions for any successful initiatives?
   
• Specific Business Applications:  What types of particular initiatives, projects, and applications should we roll out for particular business processes – should they be focused on “shared services” processes like AP or LOB processes like servicing auto insurance claims? Should they be primarily ECM-based, primarily Social Collaboration-based, or a mix of the two?

I’m going to answer these questions in four parts. Part #1 addresses how you should pursue General Adequacy to address the Fragmentation Problem. Part #2 and #3 address the specific Projects and Applications you should roll out. Part #4 addresses how you should tie #1 - #3 together in a Program. So let’s start with #1, Get to a Baseline of Adequacy.

Part 1: Get to a Baseline of Adequacy

First, do a – focused, quick   -- Current State Assessment of your organization’s situation, particularly with respect to ECM and content-intensive Social Business. Address the ECM categories: people, process, technology, and content. There’s a solid methodology for doing this, from AIIM, from Doculabs, and from lots of others. But address and document the important SOE issues. Look for your Social Media policy and provide one if you don’t have one. (If you don’t have one, download a starter policy and tweak it.)  

Assess and document the important SOE categories and issues, such as: the division of labor between IT and users, the capabilities used, the configurations, the types of devices (such as smart phones, Blackberries, iPads), and the types of users and user scenarios.

You’ll see lots of Fragmentation: uncontrolled diversity, failed enterprise synching, and lots of system of engagement problems. For basic ECM health these need to be managed at the enterprise level. You can tackle them while you address the Specific Applications, but these are more important than Specific Applications because the Fragmentation Problem will destroy you if you ignore it.

Second, Implement general baseline principles. Alan Turner of HP (my co-presenter) addressed these in our presentation so I won’t steal his material except to point at it. He recommended that you implement general baseline principles for addressing the Fragmentation Problem across information silos, content formats, devices, business units, and organizations.

Third, address over-retention.  Fortunately Alan left me with something to contribute about General Adequacy against the Fragmentation Problem, and that’s a discussion of the problem of over-retention. This is a huge problem that would have plagued us without the explosion of SOEs and fragmentation -- but it’s far worse with them. Think of email and twitter feeds, distributed repositories inside and outside of your firewalls and organizations, and so on. Organizations have been over-retaining electronic information and failing to dispose of it in a legally defensible manner when business and law will allow. It’s an issue you must address if you’re going to be letting folks seriously “engage” with Systems of Engagement.

Almost all organizations over-retain but this problem is far worse for bigger organizations. So if you’re a small firm you may be in pretty good shape. But if you’re big, you may have hundreds of TBs or even PBs of information that is compounding. So you must address it to meet General Adequacy.

Recall that above I divided the Fragmentation Problem and its solution into General Adequacy and Specific Business Applications. Now let’s do another division. The best way to address this monster problem of over-retention is to break it into 2 more tractable sub-problems: day forward information disposition and historical information disposition.

So fourth, address day forward over-retention.  Addressing day forward over-retention is much easier to address than historical retention -- even though addressing it messes with employees’ day-to-day activities. The key is to initiate information lifecycle (ILM) practices on a “day forward” basis first, so any new content created or saved is assigned a disposition period. Then provide employees with very clear and explicit guidance for the acceptable use of available tools for dynamic content and their associated retention periods. An example is “retain non-records for 3 years, and retain official records per the retention schedule.”

Fifth, address historical content over-retention by using a defensible disposition methodology. So now that we’ve solved day forward, let’s start tackling Historical Content. The good news is that there’s a methodology to follow. It’ll be a long haul and you may be at it for years, but you can tackle it incrementally and you’ll start getting immediate benefits. I’m only going to outline what I think is the best approach. I talk about this more elsewhere.

You must satisfy 4 demands: 1) Regulatory retention requirements, 2) Legal Hold retention requirements, 3) Business retention requirements, and 4) the Cost impact of anything you do. Your 2 most important activities are Sorting and Disposing, and you do everything in a reasonable manner, in good faith, in a way that can be defended in court.

You do it by developing and then executing 4 pieces:

1. The Defensible Disposition Policy (which is the design specification that states very clearly the objectives that your methodology will fulfill.
2. The Technology Plan (which addresses what tools you should use, as there are lots of them out there and you should pick the right ones for your particular needs!).
3. The Assessment Plan (for sorting).
4. And The Disposition Plan(for purging or keeping).

Part 2: Integrate Your SOEs into Your Solid SORs

Now that we’ve established a solid baseline of adequacy against the Fragmentation Problem, let’s address the kinds of content-intensive applications to roll out. I summarize my recommendation as “Integrate your SOEs into your solid SORs”, and now I’m going to explain what I mean by that.

For our purposes, there are 3 general kinds of content-using applications: SORs, SOEs, and combinations of the two.

First, you can: Implement, enhance, or integrate your SORs. Your SORs are either internal administrative applications (for accounting, customer service, HR, records management), or line of business applications (for selling and onboarding new customers, making products, servicing customers, etc.). By implement, enhance, or integrate your SORs, I mean something like you can implement imaging and workflow for AP and integrate it with ERP, and then enhance and integrate that with other pieces of ERP and other parts of the Purchase-to-Pay process. We (collectively) have been doing this sort of thing for ten or twenty years, and we have this nailed.

When organizations fail with SOR, it’s typically in execution, of failing to do what’s known to work well. Atul Gawande describes these kinds of problems in the Checklist Manifesto, as failures of ineptitude rather than failures of ignorance. The knowledge is out there (most of it at aiim.org) – and when SOR deployments fail, it’s because though the knowledge exists, it wasn’t applied correctly.

Second, you can: implement, enhance, or integrate your SOEs. These may be internal employee team-based collaboration, or internal and external interactive communities, or something else.  Some of these we’re (collectively) addressing pretty well. But with a lot of this SOE stuff we’re all just feeling our way so far. When organizations fail with SOE, sometimes just execution is the culprit – but overwhelmingly it’s both strategy and execution.

Finally, you can integrate your SOEs into your SORs. These are the most interesting opportunities. We (collectively) can do great here because #3 combines parts of #1 and #2. We therefore have a good chance of success if we focus on enhancing our solid SORs with SOEs where it makes good sense. In addition, this approach also typically provides better ROI than #1 or #2 if done well. If you do business cases, you’ll see that Social-enabled enterprise applications (#3) typically beat employee team-based collaboration and interactive communities (both #2). Here’s a business case and a calculator you can use to model your own situation.

I therefore recommend that as you address the Fragmentation Problem, and are looking for Specific Applications, you should pursue projects that integrate your SOEs into your SORs. Call these “Social-enabled ECM applications”. 

Part 3: Pick the Right Social-Enabled ECM Applications

So the next question is:  Which “Social-enabled ECM Applications” should you pursue? Great question!

To identify and rank integrated SOE-SOR opportunities (what I’m calling Social-enabled ECM Applications), I recommend that you segment them into three basic groups or levels. The three groups are:

1. Group #1:  The easiest. These are Light SOEintegrated with mature Administrative and Line of Business ECM applications.
2. Group #2:  The more complex and knowledge-worker focused Moderate SOEenterprise social collaboration applications.
3. Group #3:  The complex and usually process-worker focused Heavy SOEintegrated with vertical Line of Business applications.

Let’s look at each of these in turn.

Group #1: ECM applications that can be enhanced with Light SOE

Consider Administrative ECM applications first. These applications for accounting, HR, and customer service are mature in ECM and are usually a good place to start before tackling LOB applications or those requiring heavier redesign and use of social and mobile technologies. Basically the idea here is to add social capabilities – particularly mobile technology – at the endpoints. Participants can then use smartphones and tablets to contribute and access relevant documents and content, and participate in workflows. So this means applications like using your smart phone to take pictures of your receipts and submit them to Accounting for expense reporting, add mobile capabilities to your HR intranet, and add light mobile capabilities to your customer service processes.

Now consider Line of Business and general  (either Administrative or LOB) ECM applications that can be enhanced with Light SOE. They are still in Group #1 but typically higher in value, risk, and complexity. The idea here is the same as with Administrative applications: add social capabilities, particularly mobile technology, at the endpoints to facilitate good quality participation in the process. So enable your employees or customers to submit documents and information via remote and mobile capture and e-forms. Be careful with the complexity though.

Group #2: Collaborative ECM applications that can be enhanced with Moderate SOE

This group is more complex than the first group because the applications, involving collaborative ECM and social collaboration, are less mature and require more social design and technology. This group of applications at first seems like it should be fully SOE (category #2 at the beginning of this post) except for two factors. These applications typically involve collaboration around documents that are expected to be managed in an SOR manner (like proposal development), or they are part of processes that result in documents at certain steps, and these documents are expected to be managed in an SOR manner.

These applications are popular because they are some of the best applications for the new social technologies. We have found that these kinds of applications work well where there’s a start and end to the process, like creating a sales proposal at the end of a well-defined project.

Note that I crossed off collaborative applications like expertise identification and community building. Why? Because they are pure SOE applications that require no SOR-type management of documents or content.

Group #3: Vertical Line of Business ECM applications that can be enhanced with Heavy SOE

Group #3 is the most complex --- vertical LOB applications that depend heavily on advanced social technologies integrated with ECM, which serves as the SOR. These are high value (and thus high risk) applications that are developed primarily to be mobile. Unlike Group #2, they are often more process-worker focused. As you read through these, notice that they all depend on trained employees – not untrained “citizens” (like my kids) to create and capture information, to participate in workflows, to search and access information, and to act on it.

These are the clipboard applications that John Mancini sometimes talks about. When they involve mobile capture, they are what I call Complex Distributed capture applications. They are much different than Simple Distributed capture applications and require a lot more planning, design, and attention to execution than e.g. mobile receipt capture or business card capture. They also have an entirely different business case – because the focus often depends on reducing process cycle time rather than just reducing the costs of moving paper around.

Note that one good strategy is to evolve in phases from Group #1 to Group #3.

Part 4:  Make Alignment of SOE and SOR the Focus of Your ECM Program

So lets’ see what we’ve done so far. I said that the explosion of Systems of Engagement have brought us great opportunities but also the Fragmentation Problem. Then I said that we should reap the upside and control the downside by first breaking the Fragmentation Problem into 2 pieces, and that it’s necessary to address both. You’ve got to reach and maintain a Baseline of General Adequacy. And you’ve got to select and roll out the right Specific Applications. To reach the Baseline of General Adequacy, you should efficiently assess your ECM and SOE situation, implement General Principles of Adequacy, and address the Over-Retention Problem. To roll out the right Specific Applications, you should focus on Social-enabled ECM Applications (the ones that integrate SOEs and solid SORs). Which Social-enabled ECM Applications you ask? I reply that there are 3 general types, and you should consider starting with what I called Group #1. But if you’re careful and prepared, you can pursue any of them.

Wow. All of this leads me to my next point. If you try to do any of this without a Program Framework to plan and manage, your initiative will probably look like an exp assortment of expensive random actions yielding nothing useful.

We recommend that you should roll out any ECM solution with a systematic approach that addresses overall strategy, governance and operations, information architecture, process design and implementation, technology architecture and standards, and communication and training. These six components are best organized in an ECM program framework, but can be scaled down and used to manage any single, focused ECM project.

I know this was a lot of material. Here are the source articles that I mentioned or that provide more details:

How to Integrate Your Systems of Engagement into Your Systems of Record
http://www.richardmedinadoculabs.com/1/post/2013/04/how-to-integrate-your-systems-of-engagement-into-your-systems-of-record.html

Here’s the First Draft of Your Social Media Policy
http://www.richardmedinadoculabs.com/1/post/2013/04/-heres-the-first-draft-of-your-social-media-policy.html

The Business Case for Social Collaboration and "Systems of Engagement"
http://www.richardmedinadoculabs.com/1/post/2013/04/the-business-case-for-social-co.html

Defensible Disposition in a Nutshell – My AIIM Talk
http://www.richardmedinadoculabs.com/1/post/2013/03/defensible-disposition-in-a-nutshell-my-aiim-talk.html

Developing Your Assessment Plan for Defensible Disposition
http://www.richardmedinadoculabs.com/1/post/2013/03/developing-your-assessment-plan-for-disposable-disposition.html

6 Key Considerations to Going Mobile
http://www.richardmedinadoculabs.com/1/post/2013/03/6-key-considerations-to-going-mobile.html

The scenario involves the selection of a college for my son, a graduating high school senior. He's the third of my children to travel down this path, and it is interesting indeed to see how the advancement of the technologies involved promises to make the application process easier than ever. But it's abundantly clear that the people charged with applying those technologies have done almost everything they can to negate that potential and create what we in the biz would call a very poor user experience.

The theory is certainly sound: fill out a couple of online forms one time and push the button for that information to be sent to the colleges of your choice. Those colleges then parse the information you’ve provided, corroborate it with data from the high school and the IRS, and (hopefully!) return an acceptance and a financial aid offer.

The problem is that, in practice, there is nothing at all common about the so-called Common Application. Every school seems to want variations on what the name suggests would be a single set of data, and they seem to think that because you file taxes electronically, you can easily present it in the way they desire. Many also seem not to understand that the IRS works at the IRS's own pace, and in this time of sequestration, the agency simply hasn't got the resources to process everyone's tax returns and produce the corroborating material in time to meet the decision deadlines.

Compounding the problem is the fact that the questions on the forms themselves are often very badly written; one notable example asks you to provide “current information at time of your original submission.” Does this mean “current information,” as in, what that account balance is today, or “information at the time of your original submission,” as in, what that account balance was two months ago? Can't have it both ways, and yet that's exactly how the process designers have set it up.

The lessons here are obvious to anyone with any kind of experience as an information professional:

1) Think about what you're asking users to do from the perspective of those users – you may know what you have in mind, but they probably don't, and they may well be nervous about making a costly mistake.

2) Don't leave people feeling accountable for things that are beyond their control. This requires that you first understand what things are within their control – leaving them to sort it out and then stress about falling behind is not a good way to curry favor with people whose cooperation you ultimately will need.

3) Be as clear as you possibly can be in your instructions and explanations. Show your materials to a control group that is unfamiliar with your activity and see if/where confusion arises.

Then maybe you have a fighting chance to collect the information you need and support of the decisions that need to be made in anything resembling a painless and timely fashion.

I know, the title sounds like an old Dragnet episode. (For those of you who are too young, it was a cutting edge TV Detective series about the Los Angeles Police Department in the 1950's.) Anyway, this sentence is what was given in response to my question about emailing information to an insurance provider.

What started this is that I made a change and consolidated all of my insurance to a new carrier - to be managed by one agent who is local to me. In doing so, I had to cancel the other policies which were not all under one carrier or agent. In this case, the only way to cancel is to call the carrier directly for instructions on how to cancel the policy. (If you live in Florida, you can probably guess who this is). Anyway, I got on the phone with the service representative who explained all of what I needed to do in order to cancel, part of which was to either mail the request in through the postal service or by Fax. When I asked if it could be emailed, the answer was no, we do not accept email or digital copies as viable.

Having done work in the insurance sector of Florida, and knowing agents use digital signatures as binding for the signing of a contract, I found this somewhat unsettling and pointed this out, only to be told, “sorry sir, I do not make the rules, I can only take just the Fax sir, unless you wish to mail in the paper documents.” Needless to say, I say I was a bit frustrated with this but nevertheless, I plugged the land line into my Office Jet 8600 – good thing I still have a landline – and sent him, just the Fax. Of course I could have done this digitally if I subscribed to a Fax service but I do not, nor should I have to in these times.

In my view, there is no reason why, if at all levels of government digital information is accepted, that companies like this cannot do the same. I keep hearing about how companies are struggling, profits are down, and costs are rising yet we are still in some cases living in the stone age when it comes to information and information sharing. It amazes me that in an age where information is digitally born, managed and destroyed, there are still organizations who refuse to make the move forward. What is the fear preventing the human from trusting the digital? What is the barrier preventing a “modern day” organization from being modern? In the words of Sergeant Joe Friday, “I would like just the facts sir.”

If you are ready to move forward and are finding yourself stuck or unfocused and are not sure where to begin or what to do next, seek professional assistance and/or training to get you started. Be sure to investigate AIIM's Enterprise Content Management training program.

And be sure to read the AIIM Training Briefing on ECM (authored by yours truly). Click on the image to download and read. 

What say you? Do you have a story to tell? What are your thoughts on this topic? Do you have a topic of interest you would like discussed in this forum? Let me know.

Bob Larrivee, Director and Industry Advisor – AIIM
Email me: blarrivee@aiim.org

Follow me on Twitter – BobLarrivee
www.aiim.org/training

I will be at the following events:

May  - Fusion 2013 in Orlando, FL

August - NIRMA 2013 in Las Vegas

In our case, I am building a list to support our Business Continuity plan. We are compiling a list of all the various business processes that we (Information Services) support, and ranking them according to their continuity needs. In other words, those that have to be available 24/7, those that have to be available within 24 hours, within 72 hours, and so on. The lookup column is driven by a list of underlying technologies like SharePoint, Exchange, Lync and the various systems we have built ourselves. Some of these systems require the support of multiple technologies so it seems that I am left with a choice between depicting the systems clearly and easily, or having the benefit of enforcing the relationships. Of course, the geek in me started thinking of the ways I could make SharePoint behave the way I wanted it to. I could use a shadow list that enforced the relationship, and a workflow could put an entry into that list for every choice selected. We could move some of this stuff into SQL Server, let it enforce relationships and expose it back into SharePoint via External Lists.

Or…

I could realize that this might not be a SharePoint problem; I may be approaching this all wrong. This really isn’t a recipe book – systems are either here or not. Preventing the ability to delete a system from a list doesn’t prevent my system administrator from eliminating the system. This is a two-fold business process problem, and the solution is pretty easy. The technology list is maintained by our systems administrator, he is the only person who can delete systems. Everybody else is responsible for maintaining the list of business processes and the technologies that those processes rely upon.

If a particular technology is no longer being used, maybe it can be eliminated. If a technology needs to be eliminated (due to cost or age or whatever) we need to plan a mitigation strategy with the people involved in the processes affected. If a vendor has eliminated a technology, or has announced plans to deprecate or eliminate it in the near future, we need to work (again with the affected users) to find an alternative.  We don’t have to automate everything; we just have to make sure everything has been taken into consideration.

I still think it would be a good idea for Microsoft to extend the relationship behavior to lookup columns that allow multiple choices, but the crisis is over. I didn’t need better technology, I needed to spend a little more time thinking about the business process.