This is the concluding part of a quartet of articles about social networking and business process management. The previous items looked, respectively, at the nature of social networking, what business process management does and the kinds of system we find in our organizations.
In this posting, which is the longest of the four, I look mainly at the issue I raised near the end of part 3: how systems of engagement interwork with systems of action.
What talks to what?
Here is a simplified general diagram of the data flows among five main entities we should consider when looking at corporate social systems.
Figure 1: Where social fits
Those entities are:
- line of business systems, the main engines of systems of record. For ease of labelling, this includes administrative systems, such as for managing expenses, facilities and human resources
- data stores, the sources of and repositories for the records used by and output by the other entities
- business processes, whether or not computerised end to end. These are the heart of systems of action
- enterprise social networks, the internal element of systems of engagement. These also include networks embracing trading partners and outworkers – the equivalent of extranets
- social media, the external element of systems of engagement. These are the publicly accessible networks that exist outside the boundaries of the organization.
For simplicity, I have assumed that communication with social media takes place only via the enterprise social network. I have also assumed that this links to the line of business systems or soon will do. If not, its value will be limited (but not negligible).
The diagram helps us visualise the origins, routes and destinations of data traffic but that’s all. It purposely gives us no ideas about how and when these entities might interwork or of the kind of content that passes around the organization. Still less does it give us any clues about which entities might exert control over which others.
This is particularly so with process management software, some of whose advocates think should take priority in all enterprise computing. Such absolutism is unhelpful. We should instead refine our thinking, asking some more questions:
- What kind of process software we are talking about?
- Who will be involved in creating and managing it?
- At what point will that involvement be?
Types of process management software
There is more than one kind of process in an organization and the types of process management software employed can (and should) vary accordingly.
In the diagram below, I suggest three dimensions to consider when using computers to control or help with business processes – design complexity, transaction volume and ease of origination or adaptation of the software. Like most such schematics, it presents an idealised picture. Also, there are overlaps between and among categories.
Figure 2: Process types
At upper right are the high-volume, short-cycle and largely unvarying actions that typify production systems. Purchase order handling is an example. Business Process Management mainly concerns itself with this kind of work, which aims to give end-to-end management of, usually, a single overall thread.
Next to it, at top centre, is case management. This consists of fluid and multi-threaded processes, often with human intervention or guidance. Typical examples are bank account opening and provisioning telecoms services.
The third variety, at top left, is the low-repetition and lengthy pan– and inter-organizational processes, such as for developing drugs or designing oil rigs. These are complex and conditional arrangements that involve much human decision-making, sometimes collectively.
Below these are what I’ve termed ‘desktop’ processes. These arise (“emerge”, in the vogue term) from everyday interactions between people or groups. They are not always formally documented and sometimes are short-lived. Such processes are low in complexity and usually intended for small numbers of participants.
Who has a say?
The second question is about who gets involved in the life of a process management system. As you’d expect, ‘desktop’ processes natively allow the greatest user involvement but it is also possible for the other types to provide this opportunity. How likely it is depends on the development method used and the attitude of the local IT department.
Some systems developers and process analysts prefer to create BPM systems, especially for production processes, according to the traditional software (or systems) development life cycle. Sometimes called the waterfall method, this is linear, sequential and compartmentalised. It allows little or no user involvement in either the design stage or future revisions.
Here’s what a fan said in TechRepublic, just a few years ago:
Waterfall development… limits the amount of cross-team interaction that occurs during development…[It] allows for greater ease in project management since plans aren’t constantly being revised.
And these were among its good points! Not much room for social networking by users there.
Iterative techniques such as rapid application development (RAD), “scrum”, “agile” development and “extreme” programming are less rigid. (Are daft names de rigeur?) However, they don’t all guarantee a greater role for users.
Careful selection is needed, therefore, to match the development method not only with the process type but also the outlook and abilities of the systems professionals. There’s not much point opting for a user-inclusive method, say, when you have people like Shelley Doll (above) on the project, or, it seems, Terry Schurter:
Creating open, collaborative process discussions, particularly in the unstructured environment of social networking is plain and simple a recipe for disaster.
In anthropological terms, the priesthood (systems staff ) do not trust the laity (users) to behave responsibly. They are seen as children or, at best, adolescents.
As well as typifying a widely held prejudice, Schurter’s outburst is a fine example of slippery slope arguing. In this worldview, the only alternative to tight control is anarchy. Its adherents incline to Belloc’s advice and “…always keep a-hold of Nurse / For fear of finding something worse.”
BPM does not involve just direct users and systems people. “User” is far from being a homogeneous entity. The label applies also to people outside the systems function who instigate the automation programme, identify or confirm the processes that need attention, commission the work, agree budgets, approve the finished system, manage its running and so on. The systems side is similarly heterogeneous.
All these employees or contractors need access to the organisation’s social network if they are to contribute fully to the socialising of business process management.
The third major consideration is where in the life of a process any social interaction might occur. How would social process design look? Who would discover, specify or demand, commission, model, design, test, approve, implement, monitor and update or rework such processes? What quality controls would there be?
In the traditional view, the processes managed by BPM software are essentially unchanging. Departures from their polished routines are anomalous and, by implication, rare. These are typically thought of – and described – as exceptions. It’s as though the human being were enclosed in a cabinet bearing the label: “In case of process emergency, break glass”.
Sameer Patel, Sovos Group would like to see exceptions handled in a way that involves users:
Our process centric world no doubt solves 90% of issues by volume, but provides neither line employees nor middle managers with the facility to reach across disparate organization [sic] (expertise finding), loop in the best people (wrapping around problem virtually), use data and content needed (in context), to address exceptions.
It’s a start but isn’t exactly a wholehearted embrace of the idea of group involvement. As Michael zur Muehlen commented:
If you only focus on streamlining process execution and making it as efficient as possible the social aspect diminishes. But if you consider process discovery, the development of a shared understanding of what your operations look like, and monitoring your process environment, then social plays a big role.
It looks as though people are trying to shoehorn several definitions into the one expression. At the risk of over-simplifying (and with tongue slightly in cheek), I suggest there will be three main types of software available, all of them a kind of Social BPM:
1. Social for the Anointed BPM (SfA BPM). This is for the systems function alone. It uses the same user-excluding methods as before, such as waterfall development, but lets the priesthood discuss developmental matters among themselves over an electronic network.
2. Sort-of-Social BPM (SoS BPM). This applies while the software is running (“in-flight”) and allows users to make small variations in routing, timing or inputs after discussing them over a social network. Sameer Patel proposes “a giant Discuss button that sits right between Submit and Cancel buttons”.
3. Democratised BPM (Dem BPM). In this, anyone who wants to get involved can do so at whatever stage he or she can best do so. (It is unlikely to be the same people all the way through.) Dem BPM treats users as adults.
Henk de Man, writing about case management, is nearly there with this thought: “Process workers define processes, and the process of defining a process is part of the process”.
Keith Swenson goes further: “The proper use of social software in the business will eliminate the need for process designers. Everyone will be a designer…” Hail the rise of the citizen developer!
Joking aside, Dem BPM is to me what Social BPM should be about. The other two kinds have value but do not justify creating a new term for. They are embellishments of something existing.
Although potentially revolutionary, Dem BPM does not mean discarding the knowledge and experience of the systems function. It does, though, mean that function’s voice will not be the only one heard and it will no longer be the dominant voice when creating process systems. We’re some way short of that yet.
Sometimes the systems function will not be needed at all. It must be prepared to accept that, too.
What kind of software would result?
The previous section looked at how Social BPM might be used but not what it consists of. Here is a paraphrasis of what Dion Hinchcliffe thinks its technical manifestations will be. He lists three possibilities:
1. Social apps. These wrap existing business applications in a social envelope that allows them to live in and interact with users and their activity streams. This looks to me like ointment.
2. Social embedding. This allows developers and suppliers to put sharing, social notifications and threaded conversations inside existing systems of record and action. There is a movement to this already.
3. Social integration. Hincliffe describes this as a fall-back option, for use when the first two won’t work. It’s likely to be more expensive and time-consuming than either of the other two approaches. Your neighbourhood systems integrator would be happy to quote you for this work.
A fourth option might be making social networking a backbone service, on call to any local or enterprise software. I feel this is some way off but Jive and Salesforce are edging that way, the latter as exoskeleton.
The following suppliers are also active in the “social + BPM” market (which is not necessarily the same as Social BPM): ActionBase, Appian, ASANA, Attachmate / Novell, Fujitsu, HandySoft, IBM, Kenandy (in manufacturing), OpenText (including Global 360), SAP, Serena, Software AG, StreamWork and TIBCO. It promises to be a busy sector.
As I said in my apologia last week, there has been much thought and discussion already about Social BPM. If you’d like to do further reading, I recommend these commentators and blogs. Not all of them are directly about business process management but some of their posts offer relevant material.
I have recently joined The Human Centric Business Process Management (BPM) group on LinkedIn. That looks useful, too.