Reading Andrew McAfee’s interesting
post on lightweight workflow made me think again about how some of the trends in enterprise applications and enterprise 2.0 might fit together. In particular, as he points out there has been a realisation for a while that there is a
need for technology that spans the highly structured interactions baked into classic enterprise apps like ERP (in other words, their pre-defined workflows) and the totally unstructured interactions enabled by the 2.0 toolkit ... (blogs, wikis, facebook, etc.)
The post goes on to describe how, in the world of collaborative, ad hoc processes, there are really interesting things going on to address this need to bring data and functions out of the enterprise application world and into the collaborative / enterprise 2.0 zone. It cites products such as Google Wave, SAP Streamwork and Salesforce Chatter bringing application content and data into the conversations they power. I would also argue that these trends are nicely complemented by data-style enterprise mashups that make it easy to combine data to create dashboards and widgets.
However, I was also struck by some of the comments to the blog, specifically from Dan Keldsen
It seems we're finally getting solutions on the low-end (lightweight) of workflow, the traditional high-end (far more flexible than *most* need), but have instead of the classic bell curve bump in the middle (with a notch taken out for the chasm), well, we have essentially no-mans land....
What's the path from no workflow, to lightweight workflow, and on up to heavyweight workflow?
This is an important point. There is a risk that we’ve been focused at either end of the “long tail” – with enterprise 2.0 focused on no or lightweight workflow, while enterprise applications and BPM focus on the highly structured and complex. This isindeed a gap and dearth of solutions at the workgroup, line of business level, where teams such as contact center agents are left with complex, multi-application desktops that are hard to learn, slow to use and error prone. For these teams, processes can change frequently and the need for integration is at the UI level rather than for complex, long running transactions. While desktop scripting can go some way to alleviate these problems, it is the ability to create seamless process based mashups for these users that match their changing roles that is needed.
This style of mashup fixes the “no-man’s land” problem in two ways
- It provides tremendous ROI in its own right, making the jobs of users such as customer service employees more productive by providing previously unfeasible integration solutions
- It provides a stepping stone between the highly structured and highly ad-hoc. This can work in two directions – it provides an additional driver for the extraction and supply of the widgets needed in the ad hoc world, and it provides a means to “pave the cowpaths”. By this I mean a process whereby ad hoc processes can be mined for repeatable mashups, and mashups can be mined for future features or enterprise applications and BPM processes, allowing reusable components to be created and shared in response to real patterns of demand.
In other words, I think that if you add process based mashups to the equation, you get a step closer to a sensible end to end story.
The picture below is an attempt to summarise these ideas – feedback welcome!
Labels: agent desktop, call center, data mashup, enterprise 2.0, enterprise mashup, Enterprise Mashups
