Recent blog posts made me aware that some things take an incredible long time:
ECM and Zombies by Billy Cripe:
‘ECMS’ are graveyards and they are a dead end. They may be called digital landfills or “deep archives” or enterprise document management storage systems. But they are where content goes to die.’
Keeping your Content Alive by Lawrence Hart:
‘Content without Context is incomplete – I have a whole Blog posting dedicated to this. So if we take that ECM as a Practice, then we can marry this practice with a system that manages content and context, ties together seamlessly the authoring front end and the back and, and infuses Content with Collaboration.’
While I am happy that this is finally spelled out by someone else than me, I have people asking me frequently why we are moving away from ECM (or the cryptic Forrester DOCCM) into the BPM and ACM (Forrester DCM and Gartner IBO or IBPM) domain. While we do nothing of the kind, the answer is apparently so simple that it defies the minds of those thinking in silos. We don’t care about the analysts defined market fragments but only about what the business actually needs to close the customer communication loop (meaning processes!!) without continuous complex programming and product integration projects.
What is a Business Process? Really!!
Shouldn’t we start with the question what we did before we tried to manage business processes as a methodology or with software? Well, we had departments with people who had a certain responsibility to fulfill in an overall organization. So how did the various departments communicate about their process hand-offs? You remember the in-house mail department with the mail cart, the inbox and outbox on your desk and the mail envelopes? Sure some of you do. Then came email and soon thereafter came collaboration and eventually BPM. Even if we consider the recent outcome- and goal orientation of BPM, these processes won’t work without enabling at least the same kind of communication.
But what about communicating with the customer? Creating mass paper mailings with computer software started in the Nineties. Mass mailings – also called SPAM (really a kind of canned corned beef and made popular by this Monty Python Classic) – were a favorite way to find new customers until it kind of got too ugly and expensive. Adding marketing messages to customer documents was expanded to one-on-one correspondence created by software such as our Papyrus DocEXEC. Funnily enough, spam has remained with us through email and moved into the social era.
I still remember 1996 and our first multi-language, embedded advertizing bank statement for Citibank in Singapore, where the customer care center was suddenly overwhelmed with calls from customers about the new statement. They weren’t even informed that it was sent out, much less did they have access to those documents. At the time most companies did not worry too much about customer reactions.
John Mancini, the president of AIIM, has a nice graph on his blog that also contains the various eras of IT and how they related to documents. Only with the Millennium customer communication became a two-way consideration. But try to send an email to any large business today and it likely is still less well handled than a letter or a fax.
So proposing closing that customer communications loop with software already in 1999 was something that was way before its time. That year I announced our Inbound/Process/Outbound concept at XPLOR and AIIM conferences and I made our product philosophy clear:
‘There is no process without content and content without process is irrelevant.’
When we introduced the Papyrus Platform to the analyst community in 2001, proposing that it would link incoming and outgoing content with the intermediate processes (state/event and not flowchart-driven) the response was: ‘Has anyone asked for this?’ and ‘ISIS is this strange company who wants to link scanning and printing and no one knows why.’ Until recently the analyst community refused to consider a non-flow-diagram process management product as BPM. Consolidated BPM and ECM has no market fragment they cover, while today they cover so-called Multifunction Printers or MFPs that have the whole concept of incoming and outgoing content within the same device, including basic archiving and workflow. Why not with software? Around 2005 ECM and BPM vendors began to acquire each other but remain mostly independent products within the group, lacking true homogenous consolidation till today. So to my amazement, twelve years after our announcement, ECM experts finally have the ‘enlightenment’ that content and processes could go together?
For years I have been proposing that ECM, CRM and BPM will have to eventually merge to become one, with little response. Now we also have collaboration, case management, E.20 and Social in the product mix and all have to be mobile enabled. The product mess is greater than ever. With ACM (or DCM or IBPM) at least process and case management is seen as consolidated, but I am the only one to propose that ACM has to consolidate content capabilities as well to empower adaptation by performers. This requires business-relevant data AND content objects, managing their life-cycle, and related back-end services to enable process evolution. Office documents are not just BLOBs – Binary Large Objects – with unstructured content. They are not standalone, but governing inbound and outbound business objects with rules-embedded business data, therefore representing through their state the actual business process instance.
Systems of Record and Systems of Engagement
An insurance executive told me a couple of weeks ago: ‘Max, we have two systems that run our business – SAP and Papyrus – one of them stops and our business stops!’ ERP, CRM and ECM are systems of record. Their job is to retain and manage information. Papyrus provides a System of Engagement (content and process oriented) supporting the knowledge worker and his low-volume, high-value processes, most likely more than 50% (more in terms of value generation) of all processes. Those knowledge workers take relevant business decisions and create high-value content to document and complete the process.
AIIM and others refer to software that supports these knowledge processes as Systems of Engagement. Amazingly enough, they are hardly considered regarding their ability to deal with business content in terms of application and context. Either they deal with content as a hard-coded applications and scanned images or it is created with office tools lacking functional integration. Social is just text and image blobs without a business data link. If content is just seen as a resource but not they way it is structured, it will cause substantial problems and because the process and the content are handled by different programming projects. The clerk wanting to sell a new combination of items to a new customer can not do so until a project has been set up to program the new document (proposal, offer, contract, shipment, invoice, maintenance, service documents). Many content management companies make a lot of money by programming content for business.
A content perspective leads to state/event processes, which are ideal to support innovation and they are structured in a way that humans can relate to. While it is theoretically possible that the complete process is not creating any content, in reality any kind of people-to-people interaction requires some form of business documents and not just ‘documentation’. Hardly anyone understands that business content has no need for version control, but needs embedded business data, related content rules, a state engine, and user authorization. It is the template that is used to create the business content that goes through versions over time and may need language or departmental variants, but not the business document instance. It is instantiated according to the rules that consider the process context and data and has a state progression and when it is final it is final. That content state controls the process. Rules are used within the content as much as they are used within the GUI or in the case logic.
The State of the Art in Systems of Engagement:
Lawrence Hart writes in his blog post:
‘No tool will give that to you. Only a well thought-out design, implementation, and proper governance will give it to you. Sure, some tools will fit some business problems better than others, but the tool cannot provide Context. That is up to the people using the system.’
I do not agree on the tool but I agree about the importance of people. I believe that he is talking about Complex Content Applications that need to merge standalone silos. While design and architecture are important, there seems to be a lack of understanding what modern content and process platforms such as Papyrus can deliver! And yes, it is about the people who work with the context of the content and the platform has to empower them to create processes and content resources without substantial implementation projects. Content and process are ONE and as soon as that is clear, the ‘system of engagement’ can offer a completely consolidated capability to deal with them as ONE PROBLEM, not two or more independent ones. That also means that the processes can be defined interactively by the business and not by a governance authority and therefore it requires ACM and not orthodox BPM with back-end ECM systems.
Not BPM or ECM but the people make the difference!
Don’t fall into the trap of thinking that I refer ‘just’ to document-oriented processes according to analyst segmentation. All processes are the same. Name me one process that produces some outcome for a customer that does NOT require to receive and send business content, including paper, email, fax, XML files, or social messages! So should it really be ECM? It shows how confusing the outdated analyst market fragments really are!
Any effort to consider business strategy, processes, goals and customer outcomes as a whole will improve things. It has little to do with BPM. Trying to nail all this down into flow-diagrams will kill the opportunity for people-driven innovation. Forgetting content in that empowerment makes the whole effort a lot less dynamic and customer focused. AND NO, Sharepoint, (Box or Dropbox in the Cloud) do not provide content or process management features, it is file-sharing with dumbed-down (and cryptic to create) user interfaces. Practical? Yes, but it shows how limited that kind of ECM really is.
Conclusion: Empowering employees for processes means to make them enjoy what they do by giving them what they need: autonomy, targets, objectives, expected outcomes, guidance, social interaction, transparency, and security. How could a flowchart without content give this to them? Empowered employees will care about those customer outcomes that a rigid-process execution can’t guarantee! And yes, the right kind of software won’t do it alone, but neither can it be done without it!