When the terms of Systems of Record and Systems of Engagement were introduced, they were a great way to introduce the concept of expanding social from the water cooler to the digital world. Then a funny thing happened on the way to success. It didn’t work.
For every success story on the move towards social business, there are more examples where collaborative software didn’t take off. When you sit down and ask why, it becomes apparent that the issue isn’t always that people don’t want to collaborate. They just don’t want to do it in a forced manner.
One Job, One System
The core problem is the fact that there aren’t two types of systems. Documentum is clearly a System of Record and Jive is clearly a System of Engagement. There are thousands of other systems that fall somewhere between those two extremes.
People do not want to either work with records or engage with others. Most people in organizations do both. They have one job and they want to use one system to perform that job. What is needed are a systems that allows people to perform their duties while allowing them to both engage with colleagues and manage important information as records.
One system, two functions.
The balance between those two mindsets varies based upon the job at hand, but there needs to be in one place.
How Do We Do It?
This is the tricky bit, one for which there are multiple answers. One thing that doesn’t work well is waiting for existing vendors to build useful collaboration into their products. The end result is usually poor and it isn’t conducive to collaborating with the rest of the organization.
Case in point, Chatter in SalesForce. We are still waiting for them to conquer the world with that solution.
What is needed is a single social platform. This may seem an old approach but the key feature is the single platform for delivering and consuming services. While collaboration within the platform would be available, the capabilities would be available as services that could be embedded in other systems.
The primary collaborative interface would be open to having services embedded. This would allow jobs that were much heavier on the collaborative side of the equation to function in a primarily social business nature.
This sounds great in theory, but how do we get there from here?
Well Along the Road
This concept is similar to what we had over a decade ago when the portal market first took off. The issue with portals was that each portlet represented a separate function or application. What was really needed was a more context sensitive environment where the applications worked around business functions.
This is solved by embedding services into a system and not creating a new system from a collection of services. The “host” system needs to provide the context for the embedded services and the people who are using the system. The services exist to augment the target system, not be a system.
We are already seeing this start to happen in the worlds mobile and cloud. There are a lot of apps out there that provide a single function but they are starting to be combined together to provide solutions. The next wave will be a focused solution app that leverages other services to provide commoditized features.
From there it won’t take long until we start using those systems, forcing our existing system evolve or die.
When all is said and done, we will finally have our Systems of Productivity.
Nice post! I agree that having a separate “social silo” in each system of record is a losing proposition.
But I believe it’s more practical and valuable to think of an environment where transactional, functional, and social systems used for work evolve more like the Web than a single portal and its parts.
The great surprise of the Web was how it enabled search, social, commerce, news, research and personal writing to constantly evolve and improve. It enabled invention of new capabilities including search without the central control and complex, expensive, and inflexible integration which are the downfall of most classical IT systems.
I believe that it’s possible to link and work across business systems by layering a few consistent authentication, permission, and context/permission aware indexing and search capabilities across systems of record, creating systems of engagement that are much more flexible and focused that a classic IT portal, particularly for a mobile world.
Ideally you’d end up with a Web / Apps framework with de-facto or formal protocols that reward vendors who interoperate, and make it possible for IT to quickly deliver new capabilities with user experience that rivals what people use on the public Web.
More from my blog:
Reinventing the Web – The evolution of the Web
http://traction.tractionsoftware.com/traction/permalink/Blog936
Intertwingled Work – Following threads
http://traction.tractionsoftware.com/traction/permalink/Blog1424
LikeLike
Laurence, you are quite apparently equating social networking with systems of engagement. That is however incorrect.
Your are making the right points in principle but you do not know what is already available on the market. SOE and SOR do not stand next to each other. It is the SOE that embeds and hides multiple SOR silos, plus content and data and communiation means. There won’t be any SORs that talk to each other directly directly without the performer. There is actually no need because it is simply possible to federate all data from multiple systems in for example our Papyrus Plattform.
Here is my take on SOE: http://isismjpucher.wordpress.com/2012/08/27/bpm-vs-bpms-how-to-think-big-and-act-small/
My main point is that the core function of a SOE is not social interaction because that is freeform and unauthorized. SOEs provide purposeful collaboration towards well defined business goals. They consolidate data, content and transactions into a homogeneous user interaction.
And YES, it won’t be long until we start seeing theses systems because they are already here.
LikeLike
The future may be here but it isn’t evenly distributed. Too many people also just don’t get it.
LikeLike