Systems of Engagement – A bridge too near?

It’s now about a year since AIIM first introduced their study “Systems of Engagement and the future if Enterprise IT” (led by Geoffrey Moore). In this last year I’ve heard this study presented several times and it always resonates with the audience.

However, I believe that the study does not go far enough.

I agree totally that in the last few years we have seen a dramatic shift in the way people interact and communicate and it’s primarily driven through the adoption of social networking and collaboration tools. So the principle of moving to “Systems of Engagement” is sound.

Where I disagree with the study though, is the concept that “Systems of engagement begin with a focus on communications”. That we have moved from managing content to managing interactions. Yes, the new mediums are a lot more interactive and as a result we have more transient content and a higher volume to manage. But fundamentally, this is still describing a system of records, with records encompassing this new type of content.

In my view, what has fundamentally and irrevocably changed is the perception of value. Systems of Engagement no longer derive value from managing information. The focus is on managing Relationships.

• Relationships between individuals
• Relationships between people and knowledge domains or communities
• Relationships between people and information
• Relationships between information sources – i.e. context
• Relationships between groups, businesses, communities

What was the primary driver for adoption of tools like Facebook, Twitter and LinkedIn? connecting people into networks. What will determine the success or failure of Google+? The transition of communities of users from other networks.

In Systems of Engagement, we no longer bookmark the information. We connect with individuals: Friends, Circles, Connections, Followers. We trust the information, because we trust the source. We seek expertise first, and information second. My value, as an individual, is not defined by the documents I’ve written but by my network, my presence and my contribution to the communities I belong.

This applies just as much inside the firewall, as it does outside. Collaborative tools, crowdsourcing, open Q&A, etc. are not driven by sets of captured information, they are driven by connecting the right people to the right tasks and the right communities. By developing relationships.

Yes, as Geoffrey Moore describes in the study, new information is generated through the interaction between individuals. But the new currency in the world of Systems of Engagement is not the snippet of interaction between individuals and the knowledge contained within it. That knowledge is transient and most often obsolete as soon as it is captured.

The new currency today in Systems of Engagement is the Relationship, the connection, the network: Who knows whom? Who knows what? Who do I know? Who knows and follows me?

My first DMS kiss…

A recent tweet exchange with @pmonks and @pelujan (legends amongst the ECM Twitterati…) prompted me to dig deep into my past to find my first flirting with Document Management, a relationship that has lasted over 35 years.

The year: 1984

The venue: London, offices of a Greek shipping company

The actor: An impoverished first year BSc student

The platform: Perkin-Elmer (later Concurrent) super-minis, 32-bit architecture

The language: CoBoL with proprietary RDBMS and transaction processing

The screen: Green on Black

The medium: X.25 network, over a private leased London-to-Athens line

The gig: Long-distance telephone calls between London and Athens offices were costing the company a fortune. Also, the timezone difference reduced the effective daily communication window by 4 hours. The company was looking for a way to leverage their existing technology platform, to exchange messages between offices synchronously or asynchronously, without incurring additional telephone costs.

The solution: A database system written in Cobol, which allowed terminal users at either end to pick a recipient from a list or registered users, leave a message from the user to the opposite party and receive a message back. Since it showed a history of the messages exchanged between the parties, if both parties were on-line, then you could have a dialogue in real-time (line-by-line). If not, the other party would pick the message when they logged in and respond back. This was using a temporary database table. If either party wanted to keep a permanent record of the conversation, they would “archive it” in a separate table, holding metadata like start time, end time, from, to, a subject description, location, etc. Also, since I wanted to be able to exchange messages about code with other programmers in the head office, it had a primitive system of referencing external files on shared disks.

In today’s terminology, this was email, Instant Messaging, micro-blogging and Document Management system rolled into one. An early form of social collaboration. I designed it and built it in about two weeks and it was used daily. It was simple, crude but effective.

[A side note for the pedants: I know email systems were already around by then in the Unix community, but they were not commonplace and they certainly were not available on a business platform like the Perkin-Elmer. Remember, 1984: no TCI/IP, no Internet, no Windows, no PCs, no files]

Since then, I’ve worked on many more weird DMS implementations, before the Document Management market was even identified as such: A hand-crafted invoice processing system written in VB with Kofax cards and massive Cornerstone monitors on OS/2 machines; A bespoke DMS for commercial property agents, with distributed desktop scanning (property images) attached to workflow (rental review) cases; A bespoke DMS based on Uniplex and Informix 4GL for lawyers, a fully fledged DMS with version control and content searching on NeXT machines, using C, Informix and BRS-Search (free-text database), later ported to a disasterous Ingres implementation on Windows 3.11

By then Documentum came on the scene and I remember writing VB for a very early implementation of version 1 (effectively just a set of APIs) for a Pharmaceutical company. FileNet was already on the scene with the first notion of Imaging+Workflow as a single intergrated platform, but our paths were not to cross until a decade later.

Now, there is a point to this inane drivel, beyond self-indulgence…

In today’s confused ECM market, none of these early bespoke implementations would classify as proper “Document Management”. Yet at the time, they were all innovative, trailblazing, and large companies would pay good money to implement them. It created the legitimate (if schizophrenic) ECM market space that we live in and love today.

When I launched “Document Management Avenue” in 1995 – the first independent online community forum for DMS, for those old enough to remember – we were tracking over 300 products in this space. I still have the list somewhere. Today, most of us can only point at a dozen or so major ECM / EDRMS vendors.

There you have it. My own short history of watching the birth of ECM – The bespoke became product, which became open-source, which became commodity. The rest, as they say, is history… And some of us are still arguing what to call the baby

Lawyers are from Mars, Technology is from Venus

I spent two excellent days last week at the Legal Week’s Corporate Counsel Forum, where I’ve met several new and interesting people and learned an awful lot of things I didn’t know.

But I left the conference very frustrated.

The forum audience comprises primarily senior lawyers: General Counsel and Heads of Legal departments. The topics covered were as wide as crisis management, ‘moral’ compass, employment, Bribery Act, ‘Tesco’ law, cross-border teams, intellectual property, competition, etc., etc. Fascinating subjects, some of which admittedly I knew nothing about and learned a lot. It gave me a small insight into “a day in the life of a General Counsel” and the sheer volume of diversity that they have to be knowledgeable about, deal with and protect themselves (and their company) from.

And in 8 out of 10 conference sessions I wanted to shout: “There is a solution that can help here!”.

It amazes me (and frustrates me!) how much of the technology that other parts of the organisation take for granted seems to be absent from the legal department. As if they are the poor relatives in the organisation. I am not talking about highly specialised legal technologies such as eDiscovery, Content Analytics or even Information Risk & Compliance Governance (although these too are available and seem to be missing from many legal officers’ armoury, but that’s another conversation…). I am talking about basic capabilities that make the daily office operation significantly more efficient:

• Digitising paper – avoiding the costs, avoiding delays of shifting piles of paper around and the risk of losing them by accident or in a crisis
• Electronic document repositories – managing security and access controls, reducing duplication, managing versions, allowing online access from anywhere and simple searching
• Case management – allowing lawyers to organise their work, negotiate with third parties, monitor progress, apply rules and generate reports automatically instead of using spreadsheets
• Email management – capturing, filtering, organising and routing emails, ensuring compliance
• Collaboration software – communicating amongst large teams, dispersed in different geographies and timezones

The list goes on… This isn’t trailblazing, these are automation tools and capabilities that have proven their value and have been helping organisations remove basic inefficiencies, for the last 10-20 years.

I am not advocating that technology is the answer to everything. Some business problems can be improved with some common sense and a bit of reorganising. Others are far too complex to be tackled by technology alone. But there is certainly enough basic technology to make a General Counsel’s life much simpler.

One of the key messages coming out of the conference was the resource constraints that legal departments are facing. Too much to do, too little time, too few people, too much information to process, too much knowledge to upkeep, too many risks to avoid, too many departments to coordinate, too many regulations to adhere to and too many stakeholders to appease.

So why are you wasting time on menial tasks that can be simplified, automated, or eliminated by use of simple tools, instead of using that time effectively to add value to the elements of the process where technology can’t  help.

Whenever I asked that question, the answer is typically “We don’t control the budget” or “We have other priorities” or “We don’t have the time to look at new tools”, etc.

Excuses! The question here is not “have I got time to worry about technology?”. The question is “Can I afford the luxury of NOT using it?”.  If these technologies can improve the productivity and reduce costs in the operations department, the marketing department, the sales department, the procurement department, why not use them to improve the efficiency of the legal department too?

(I would love to hear your views on this, especially if you are and in-house lawyer or work in a legal department)