Process Engine + Social Media -> Thingamy and ESME

For a long while I've been keeping an eye on the E 2.0, collaboration and social media efforts meant for enterprise use. I have to admit to being a sceptic, still viewing such as mainly single-task tools with little or no process and mostly lacking any way to add accountability and task ownership.

When discussing this with the large Enterprise Software vendors this has not been countered, quite the opposite, and promises of adding some 'process' to their E 2.0 / socmed efforts has been uttered.

In regards SAP's latest E 2.0 effort my fellow EI'er Dennis Moore suggests:

"SAP can distinguish 12Sprints.com by integrating it with business processes and enterprise data, including the Business Suite and Business Objects. This is an area few other collaboration tool providers are venturing into, and one where SAP has a natural advantage. If SAP does take this path, it is likely that 12Sprints.com can deliver real value to enterprises. This likely would result in new customers for SAP, new users within SAP's installed base, and greater customer satisfaction for SAP's existing customers."

To which I humbly disagree: SAP do not have any process engines (nor do any of the other big ones) for Barely Repeatable Processes, and this tool (12sprints) is for people centred processes that by definition are BRP. Hence SAP has no suitable process engine to integrate with.

But I do not think slapping some "process'ish stuff" on top of E 2.0 / socmed / collaboration tools would not cut it, that would be like putting the cart in front of the horse. Or at best elevating E 2.0 to Middleware 2.0.

Better, and I think the only way to go, is to have a core process engine and data architecture onto which the ad-hoc and mostly single task social media and collaboration tools could be added.

To put my money where my mouth is, we integrated some social media into our own BRP process framework in between the holiday parties and food frenzies.

ESME, aka Enterprise Social Messaging Experiment is now a part of the Apache Incubator program, developed and supported by a group springing out of the SAP mentor program.

Yes it's quite similar to Twitter, but it has features and abilities minted for the enterprise user - hence a perfect starting point for Thingamy.

Here's a conceptual description:

Thingamy's Work Processor runs the workflow without a glitch with path choices at most corners - punting a little "train" of relevant and inter-related objects (Workflow/issue/request/idea object - the main one + Assignment objects) through a workflow. The Assignment objects holds the task instructions and captures what's done in the assignment while the Workflow objects holds the details about the issue/idea/request.

That way an Assignee is presented with relevant objects, all the pertinent information required for a specific task + the Assignment object to fill in with result and files.

When having been assigned a task, or when trying to get one's head around the progress of a workflow there is always a need for ad-hoc communication with co-workers and/or other participants; "anybody know...?", "Could somebody help with...?" etc. Normally that would happen by email, phone or walking around - all of which limits the discovery of the unknown, like a co-worker having unknown but useful knowledge or ideas. And it would not add the very useful effect of "peer review" either.

ESME adds that crucial part of "Discovery & Discussion" that inevitably is needed during any process; in a task or when studying the progress. In addition it should become the natural in-system conduit for communication as well as the social pivot point, the water cooler, for the group/department/firm.

The crux being that the data in the two parts must be related - and that is implemented here; any ESME message can be related to any Thingamy object adding context to both sides - in the midst of a task, when studying the automatically generated reports or when scratching your head wondering "what's this discussion about?".

I don't know what next step, as in features, will be - our philosophy is to keep it as simple as possible in the beginning and only add if it makes huge sense and works in practice. So we'll see, the good thing is that both ESME and Thingamy are extremely nimble and doing crazy stunts underway shall be easy.

And here's a quick and dirty effort to demo the result within seven minutes :)

[Update - more discussions out there: Dennis at Zdnet, and David at Biztwozero.]

Comments

[Account Deleted]

New build for that one, Sig? How tricky was it to integrate?

[sig]

New build underway, although shifting most (but ultrageeks like yourself ;)) to pilots running on my server.

Pretty easy to start up: ESME server is standalone, easy to get going (a couple of things to do specific for Thingamy) then you can leave it alone as it's multitenant for any number of Thingamy instances!

Thingamy admin sets the rest for each instance: Enable/disable ESME integration, setting app name and token.

I'll give you a short manual with the new builds ;)

[Account Deleted]

nice ... bated breath etc :)

[Dennis Moore]

Sig -

Good thoughts.

I was not proposing 12Sprints for BRPs. I was proposing 12Sprints for VRPs (VERY repeatable processes). Even very boring, repeatable processes like invoice approval, hiring, and manufacturing scheduling - the very heart and soul of repeatable processes - sometimes need a little conversation for effective execution. I can't tell you how many invoices I've approved for payment with insufficient information, just because it was too hard to dig in and see whether the invoice was within the project's scoped budget, or whether we were getting real value for the money we were spending. I'm thinking of something like 12Sprints NOT to solve every E2.0 problem, but just to solve the problem of adding some social goodness onto VRPs.

BTW, even BRPs need data to make informed decisions, so ESME and 12Sprints and others will need to integrate with frameworks like BOBJ if they want to enable BRPs like "annual budgeting" or "raises and bonuses" or "S&OP."

I hope this clarifies ... and thanks for taking this discussion forward!

[John Dodds]

I think the more such demos you can produce the better.

Two suggestions - initially, make them shorter if possible (2-3 minutes) i.e. break this example into two. And get closer in on the screen so the viewer can better see what is happening.

[sig]

John, good advice!

Agree totally, will move from amateur to professional asap, albeit time consuming, in such matters I'm the classic noob :-D