BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, February 06 2014, 09:40 AM
  4.  Subscribe via email
Aberdeen recently released this survey that stated:
Thirty-four percent (34%) of respondents in Aberdeen’s Solving Collaboration Challenges with Social ERP indicated that they have difficulty converting collaborative data into business execution. This is unnerving because, for many processes, the ability for people working together collaboratively is essential for process effectiveness.
So what do you think is the key of solving the social aspect of business processes?
Dave Duggal Accepted Answer
Blog Writer
Social is about interactions; it is generally asynchronous, event-driven, stateless - in contrast to Process, which is generally synchronous, flow-chart-driven, stateful.

The Web's success is because it is a enabling platform for people to be social, just like the telephone (the global communications infrastructure the Web runs on). Cloud, which in turn runs on top of Web protocols, is slowly de-coupling traditional app/process architecture for a more loosely-coupled, event-driven, interaction-centric experience.

The problem is thinking of these things as being separate, when we should be noting the convergence. I think this is the natural trajectory driven by the force of humans as social creatures.

Desire to collaborate, communicate will trump desire to participate in gratuitously structured processes that are seen as ineffective.
Comment
Interestingly, the BPM tool that we use most frequently is asynchronous in nature. It does use BPMN, but you're basically modeling parallel processing activities and they are asynchronously managed. Interesting implications for scale and supporting less structured processes when needed.
  1. Scott Francis
  2. 2 years ago
Dave, I totally agree on your statement: "Process, which is generally synchronous, flow-chart-driven, stateful". So unlike business real life. I understand flowcharts, but so few small customers find these complicated.

That is exactly the reason why the BPM as an industry has been stalling for decades.

This approach is about to change, I hope sooner than later.
  1. Bogdan Nafornita
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Bogdan Nafornita Accepted Answer
Easy: invent a business process execution language (BPEL) that is as close as possible to natural business language and embed it into a simple BPM system.

Yeah, I'm working on it :-)
Managing Founder, profluo.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
David Chassels Accepted Answer
Seems to be in context of "ERP" so no surprises there with lack of encouraging the human centric interactions? I think there are 2 aspects to this issue.

First as Bogdan indicated having a way build and execute direct with users in their language will help. That's already been done no BPEL no BPMN recognising all business logic never changes so just need configure to user requirements click a button and using declarative ready to run with no code generation or compiling so very easy to change in build or as business requires in the future. With the users gaining confidence their views matter they will be encouraged to work collaboratively to find better ways to achieve their required outcome.

Second aspect to social is recognising not all processes are formal. It might be as simple as being able to write notes for next users etc or even just a timing for say reminders of "off line" interactions that may help the process e.g. doing research?

All should be readily supported by a good BPM Platform. Delighted to hear Bogdan working on it and with more challengers we can confine BPEL and BPMN to the history book of evolution of the next generation BPM Platforms which will eventually and effectively replace ERP?
Comment
Thanks for the compliments, David, but don't hold your breath on my start-up, I am still scared as hell about hiring my first developer :)

And yes, in a broader sense why would ERP and BPM be two different business domain fiefdoms? ;-)

Thank you once more.
  1. Bogdan Nafornita
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Steve Weissman Accepted Answer
Is it me, or are we making this overly complicated? “Converting collaborative data into business execution” isn’t a matter of technology, it’s a matter of people!

The technology can be great in terms of helping collaborators share and discuss information, and keep the collaborative process moving through alerts, etc. But at the end of the day, it’s the human beings who have to make the decisions and energize the organization. So if that unhappy third of respondents Is having trouble in this regard, then I’d humbly suggest they need better training – or maybe better people!

(And just what the heck is “Social ERP” anyway?! Sounds like just so much “Mad Libs Marketing” to me.)
Comment
It's not just you. Overly complicating things is what technical people do the vast majority of the time.
  1. Patrick Lujan
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Shelley Sweet Accepted Answer
Blog Writer
To me the social aspect of BPM works when it naturally integrates with the automated side of BPM. In other words, when employees need to communicate with one another or retrieve something such as a best practice, it is easy for them to do, they can do it real time most anywhere, and they get answers back quickly. This is technology and humans working together well. And we have a lot of this now. And it's getting easier. So that will help the 'social aspect' of BPM. I don't really see this as an either/ or. I see it as continuous improvement - and stop trying to make BPM just the stable mechanized workflow.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Patrick Lujan Accepted Answer
Blog Writer
Ahhh.... so many problems, so little time. So many falsely stated problems. IT's belated enamor of #social aside (including here in the BPM space) this is not a new problem. Informing, collaborating, educating - the problem has always been one of capturing and codifying institutional knowledge, extending and enhancing that knowledge. Technology can facilitate that, but will NOT solve it because, as Steve has correctly pointed out, it's a people problem. Start there.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
E Scott Menter Accepted Answer
Blog Writer
Let us for a moment step back and appreciate the beauty that is BPM technology. Prior to BPM, "social" input into process design was a pretty one-directional matter: we'd all sit around in absolutely fascinating meetings talking about how the process should work, then somebody would write a spec and somebody else would code it. If you wanted to see how the process <b>actually</b> worked once implemented, you could then either (a) try it out or (b) read the code.

Today, though, anybody can see how a process is designed: just review the lovely Timeline or the unlovely (but still commonplace) flowchart. All you'll need is the ability to read and distinguish between different types of shapes—a level we all hope to reach by around the first grade. No code parsing skills required.

So we get together, review the designed process, and provide input. Then we do it again once in a while. If we have trouble converting that "collaborative data" into "business execution", well... perhaps the technology is not where the blame ought to be directed.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
Depending on which tooling you're using, you can have multiple people editing in real-time - in the same room or thousands of miles apart. Much easier to collaborate at design time. But what people are typically focused on when they complain about lack of "social" in BPM is the run-time side of the equation.
  1. Scott Francis
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Keith Swenson Accepted Answer
Social capability is not simply frosting that you spread on the BPM cake.

To leverage social capabilities, you need to understand the difference between "push" and "pull" systems ( John Hagel et.al )
Most existing systems that call themselves BPM Systems operate on the push principle: someone very smart discovers and formalizes the process, develops an application, and pushes that application to the workers to use. The brains are separated from the brawn. A push approach will never be able to leverage the emergent propensity of social systems.

Instead, a pull approach is needed. Look at Facebook: nobody sat down and decided what the main groups and organization would be, but it emerged. Look at twitter: nobody decided what the structure was to be, or even actions like FF and RT. Those emerged. The power of social comes from serendipity, not a BPM/development lifecycle.

Social BPM will be less about drawing diagrams (i.e. programming) and more about just letting people work together, and watching the processes emerge from that. You need Self Organizing Business Networks and the problem is that traditional management is uncomfortable with this idea.

Notice how Shelley correctly draws a distinction between the social side and the automation side: that is pull versus push. I almost laughed at Scott's comment that "you only need to be able to read and distinguish different shapes ... no code parsing skills required." What are code parsing skills if not the ability to read and distinguish symbols? But clearly Social BPM will have nothing to do with drawing diagram, just as Facebook and Twitter have nothing to do with drawing organization charts, or communications flows.

Programmers want to think that social is a frosting that spread on the BPM cake, but only when the they realize that they need to abandon the idea of a cake, will they begin to understand social.
References
  1. http://social-biz.org/2010/06/23/11-questions-on-social-bpm/
Comment
A couple points:
1. there's a lot of social in design-time BPM tooling. So the idea that social can only happen if there is no design-time is wrong, misplaced, or miscommunicated.
2. I presume we're talking about run-time social, where it doesn't matter how the baseline process got there. Twitter, Facebook, for example, are programs that were written by programmers without my input as a user. They decide how timelines and profiles work, and follow/unfollow, friend/unfriend, etc. Now, within those strict limits (and there were many strict limits, like 140 chars), users can innovate and collaborate and be social and define conventions like the hashtag and the @ convention. (Which later the software companies adopted). All well and good.
3. so the advice to bpm programmers - give users a platform on which to communicate / collaborate and set their own conventions, then listen to them for how to improve on it or formalize some of the conventions. For example, in email, i often get messages that end in [eom] or /eom in the subject line (meaning, there is no body of text in this email, this is all). But email programs never learn from these conventions and improve on them. What I think programmers have not done for most BPM platforms is really discover what users would want to use to collaborate around execution of business processes (or cases if you prefer). to this day, the best social/collaboration tools are not BPM tools (twitter, fb, google+, email, linkedin, Instant Messenger, etc. )
  1. Scott Francis
  2. 2 years ago
Scott, to clarify, when we talk of "social BPM" then yes, this should by definition embrace some of the characteristics of Facebook and Twitter. As you point out, whether this is "good" or not is an open issue, but the subject proposed for this discussion was around social BPM.

Please forgive me for over reacting to your comment on diagrams and programming. I don't mean anything personal. It is just that I have heard so many times the claim that to make a diagram you don't need programming skills. This is silly. BPMN has very specific syntactic requirements on how a diagram can be constructed. You can easily draw a diagram that is complete nonsense and invalid. In order to draw a "valid" BPMN diagram, you have to know a lot about the semantics of the diagram elements. That is, you have to know how to program with those shapes. Surely you don't think that programming is difficult because you have to type. Typing, after all, is easy. What is difficult is satisfying the syntactic constraints of the language, and accomplishing the algorithmic requirements. It is silly to think that just because you can drag and drop visual element that that makes the programming any easier. You can't simply drop anything anywhere and connect anything. While there are some distinct advantages to visual programming, the effort to make a valid, logical, and correct diagram can take as much skill and effort as ANY kind of programming. I find the claim that so many BPMS vendors make, that "you don't need to program" both misleading and dishonest. Among us experts, we should not imply that drawing a BPMN diagram takes "NO" programming ability.

Just remember: the difficulty in programming is not because you have to type and/or read text.
  1. Keith Swenson
  2. 2 years ago
So, to clarify, you think processes should arise in the same way that Facebook and Twitter conventions were established? Hmmm. I suppose that would work if you wanted to end up with the chaotic signal-to-noise ratio characteristic of those systems.

The fundamental fallacy here is: "Social is good. Facebook and Twitter are good examples of social. We want BPM to be good. So BPM should be more like Facebook and Twitter." Substitute "dessert" for "social" and "apple pie" (I like mine with ice cream) for "Facebook and Twitter" and the statement is neither more nor less sensible.

I am also a little confused by your code analogy. Distinguishing between a diamond shape and a rectangle is the same as reading code? I have to admit that it's been a while since I've been a coder, but my recollection of programming languages is apparently pretty different from yours.
  1. E Scott Menter
  2. 2 years ago
Hi Keith. No worries, no offense taken or intended.

While I think we still disagree on the relative complexity of creating and reviewing processes implemented via code vs. flowcharts, it looks like we at least agree that neither is overly simple. My point was that it was easier to share a completed flowchart with end users as an explanation of how a process works than it is to share a segment of code.

That said, the flowchart model is itself so flawed that I believe its use should be strictly limited to very small (less than 10 steps, say) processes altogether. Obviously, as a vendor of an alternative model, I'm biased, although to be fair my enthusiasm for that alternative did predate (and motivate )) my arrival here.

As to "social", well... As Scott and others correctly point out, there's the question of internal social (process design) versus external social (social participation in process). The former makes little sense, IMHO, whereas the latter is inescapable. BPM has grown beyond its niche as a back-office solution, and is extending out to the edges of the organization (sales, field service) and beyond (customers). In 2014, a BPM platform that cannot meet that challenge has fallen embarrassingly behind.
  1. E Scott Menter
  2. 2 years ago
Because the tolerance threshold for chaos is lower in a business, and the upside is smaller.

I'm glad you chose Wikipedia as an example, as we both agree that it is an extremely valuable and successful resource (I even send them a tiny contribution every month). But actually, I think Wikipedia supports my position better than it does yours. Consider:

(1) If somebody comes along and messes up a Wikipedia entry, it generally gets corrected very quickly. But in the interval in between, you have a broken entry. A business process so easily broken represents a greater risk than most organizations would want to take. What's more, it's unlikely to be fixed nearly as rapidly because the audience of potential repairers is going to be many orders of magnitude smaller than that enjoyed by Wikipedia.

(2) Where entries are controversial and tend to be frequently and competitively updated, Wikipedia has had to lock them down. Lesson: when the matter is important to a lot of people, the crowd sourcing model fails.

(3) Wikipedia's value is directly proportional to the number and validity of source references in any given article. The most valuable of those references are research papers, which generally speaking are the result of a small number of individuals engaging in a study that is then peer-reviewed for correctness before publication. Ultimately, a topic's credibility relies on that of its sources, and Wikipedia's credibility as a whole is simply an aggregate of that of its individual articles. So whatever credibility Wikipedia can claim is derived directly from the fairly rigid underlying process through which scholarly content is produced. Otherwise the whole endeavor would have no more value than Yahoo Answers.

As a result, I think the question of "what's the best way to execute social BPM" is not nearly as urgent as the question, "is social BPM [in the sense we are using it here] a good idea to begin with?".
  1. E Scott Menter
  2. 2 years ago
Remember, the subject is "social BPM" and many would think that process that emerge from the work as being "chaotic" and "low signal to noise" behavior.

Consider this: what if you had a system that allowed processes to be created the way that Wikipedia is created. There is no central control. There is no brains vs. brawn, where a ruling elite pushes content to the masses.

You can be as critical as you want about Wikipedia, some people are happy to show the flaws, but there is no denying that it is the single greatest reference source in the world, far surpassing all previous attempts at encyclopedia. (Yes, those former encyclopedia also showed all the same flaws, but were less comprehensive.)

Wikipedia is not chaos. It is not organized by a top down Aristotelian categorization, but rather a bottom up emergent organization. Why can't business process be handled in an analogous way?
  1. Keith Swenson
  2. 2 years ago
Scott: excellent points!

(1) process can be easily broken: that is a problem specific to the current incarnation of process technology. Most current BPM technology views the organization as a machine, and support creating another complicated machine for the business process. But it is very fragile, and breaks when the world shifts. Instead, what is needed is a different approach that robust, or even antifragile. When it comes to emergent definition of processes, we need to think outside the box -- it simply won't look like our current process application design tools.

(2) Controversial subjects in Wikipedia needs to be locked down: indeed, and you will need similar mechanisms in social BPM. The analogy breaks a bit, because in Wikipedia you have one page for the entire world on a subject, but for process there is little evidence that everyone should use the same process. There is quite a lot of evidence that different organizations, and different contexts within a single organization, would do better to have unique processes. how much difference, and how much uniformity, I can't say for sure, I just mean to say that in business process there is lots of evidence that enforcing a single process on everyone does not necessarily lead to the optimal business.

(3) Agree with your point, however I think the analogy breaks here.

Finally, you ask: is social BPM of any benefit? In return, I ask the question: have you noticed how automation has the effect of calcifying an organization? Applications are created to support a specific function/process but then the world changes and it is *harder* for the organization to respond, and there is a real cost. The problem is that the people doing the work can not reorganize themselves, because they have to hire programmers and explain the change, etc. Thinking outside the box: imagine that you had a system that COULD be reprogrammed by the users, not by programming, but just by using it. The users would just start doing things differently, and the system would learn. Can you imagine that? It is very very different from the BPMN-style fragile programmed systems we have today. If you can imagine this, you will see that there would be a tremendous benefit to the organization. That is WHY we talk about Social BPM.
  1. Keith Swenson
  2. 2 years ago
Thanks Keith. A couple of more thoughts based on your response. Two or three more of these and we should just collect them and publish them as a book. :)

"Have you noticed how automation has the effect of calcifying an organization?" Sure: bad automation. Packaged apps with minimal flexibility, or even poorly executed BPM-based processes.

"The problem is that the people doing the work can not reorganize themselves, because they have to hire programmers and explain the change..." Not in my universe. In the vast majority of cases, no programmers are required. If you think listing out the steps in a process the same way you would if you were, say, enumerating them in Excel is the same as programming, so be it.

"Imagine that you had a system that COULD be reprogrammed by the users, not by programming, but just by using it." I'm not going to argue the total non-existence of such use cases, but I suggest that they are few and (for the most part) relatively unimportant ones. If they were critical, the organization would want to clearly define how they were structured (even if that structure is highly flexible, as most are). In addition, in today's world, the burgeoning regulatory state is rendering normal processes into compliance processes at a frantic pace—and compliance is not the type of thing that works well with a laissez-faire process model.
  1. E Scott Menter
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Phillip Rhodes Accepted Answer
The short answer from Fogbeam Labs is "It's your culture, stupid". OK, we might not actually phrase it like that to a customer, but you get my drift. This really is less of a technology question than a question of culture, and organizational structure.

Long answer: Written up as a blog post, which you can read here:
http://fogbeam.blogspot.com/2014/02/on-solving-social-aspect-of-bpm.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
I think that the key part of the quote is “…difficulty converting collaborative data into business execution”. I translate it into a need to fuse new work-coordination-techniques such as “community-based” and “intelligence-based” with already existing work-coordination-techniques (“template-based”, “rules-based”, “event-based”, etc.) under the common umbrella of BPM.

We have to stop equating BPM with OLNY template-based work-coordination-technique. BPM (as a discipline) is open for any work-coordination-technique. ( see also http://improving-bpm-systems.blogspot.ch/2012/07/coordination-techniques-in-bpm-social.html )

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Max J. Pucher Accepted Answer
Blog Writer
The best description of a business is 'purposeful collaboration'. Also flow-diagrammed BPM is collaboration but unfortunately of the rigid, predetermined kind that only solves a small percentage of business problems. Adding Social to BPM can only improve this minimally:

http://isismjpucher.wordpress.com/2010/10/27/lipstick-on-a-pig/

The 'purpose' of doing BPM is to complete all process steps. If something does not comply with a predefined process you end up in a mess. Therefore the purpose of the process must be defined as a goal that people can freely collaborate towards. Social BPM (or ERP) doesn't allow that. It allows people to communicate freely but has no features to define goals and verify if they have been reached, Some ad-hoc tasks can be added, but the next time this situation appears the same thing happens unless you go through a optimization iteration that usually requires BPM experts of some kind.

Unpredictable events by people, from external systems, incomplete documents or data can throw any predefined process off its course. With ACM we define the business or process goals, recommend certain actions or activities and if people do something else to achieve the goal that is just as well. Rules can be used to provide further guardrails or boundaries for the collaboration.

A process is always about outcomes even if they undefined in the process itself. So it is really not understandable that these are not explicitly defined as part of it. Rigid flows have a hard time to describe all the variants that might lead to a good outcome. Efficiency comes second to effectiveness so reaching the goal is a lot more important than the shortest or cheapest process path.

A successful outcome must be easily reusable as a template with little or no additional effort.

Let's nor forget that we defined all this in 2009 with ACM. I am not sure what the big surprise is that BPM doesn't handle these process types:

http://isismjpucher.wordpress.com/2011/08/27/social-bpm-methodology-the-triple-oxymoron/
Comment
Max
But "BPM" has no restrictions in thinking. Sure in the past as the supporting technologies evolved so there were limitations just as you say. But not now nothing you have said that cannot be handled in the design by a modern BPM Platform that does not require BPMN.
  1. David Chassels
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Max J. Pucher Accepted Answer
Blog Writer
David, 'BPM' is a fuzzy cloud so who cares if it has 'no restrictions in thinking'.

BPM today has immense 'restrictions in doing' because of its methodology in the analysis, model, implement, deploy, monitor, and improve cycle.

But the business users should be able to define the goals, outcomes and handovers, work towards them, add rules, content and data on the fly, add new participants and once the goal is reached, save what has been done as a reusable template.

Give me a list of BPM platforms that do the above without IT or expert involvement ...
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
David Chassels Accepted Answer
Keith, Max

Keith can’t let those old views go with out a challenge.
“It is just that I have heard so many times the claim that to make a diagram you don't need programming skills. This is silly” Well Keith might be “silly” in BPMN but there are new approaches that take a BIG step forward to build next generation Enterprise software which is driven by the BPM principles. We use a declarative technique from the graphical design build to the trigger the automatic build where all logic pre built. With no code generation or compiling to build which makes change very quick and easy. And. The core research was published last year see http://www.igi-global.com/chapter/object-model-development-engineering/78620 and other experts now saying “….how those models can become applications without any code being written or even generated”. “…”If your Enterprise vendor isn't pretty far down this path, their future isn't very bright”

Before you say but what about… this is what we and any BPM Platform must now cover as an integrated capability.
• Process engine – orchestrating as required to ensure all works to plan
• Rules engine - reflecting real world of complexity and compliance
• Calculation engine - automating system work
• State engine - real time feed back from any point
• Workflow - everything connected in right order
• Audit trail, events, escalations - managed control and accountability
• Rapid prototyping - user involvement in build
• Time recording - supports activity based costing
• Real time reporting - become predictive
• Build mash ups - one screen multiple data sources
• Linked intelligent Ajax grids - enter data only once
• Roles and performers - people and machines indentified
• Management hierarchy - see who does what and when reallocate work
• Orchestrating legacy - recognising valuable data in legacy
• User interface dynamically created - linking people, roles, task type and data via forms for specific instances recognising that user forms needs to be specific for that task in hand
• Pre-built templates for custom documents, letters, e-mails, messages etc dynamically populated with instance specific data and edit capability in browser - automating yet giving users ultimate control over external communications
• Process and task versioning control - recognising change is inevitable

“It is silly to think that just because you can drag and drop visual element that that makes the programming any easier”. Again you are out of date the “visual” elements are pre-coded objects that just need configured which does not require programming and built Yes if you have “algorithmic requirements” then get your best coder to do it inside the “calculation” task but often with use of inbuilt logic rules easier to build complex requirements without such “programming”. However the surrounding logic is all in hands of business driven skills.

“I find the claim that so many BPMS vendors make, that "you don't need to program" both misleading and dishonest. Among us experts, we should not imply that drawing a BPMN diagram takes "NO" programming ability”. Keith you have just signed the death warrant for BPMN….so just time until execution.

You and I have had this exchange before and your disbelief continues. We must never stop learning but when the “new” starts to challenge Mahatma Gandhi summed it up “First they ignore you, then they ridicule you then they fight you, then you win.” Keith you choose where you sit….?.


Max we do it and I hope others are following. Spotted one in Canada and there was an initiative from academia in Australia …….maybe “the experts” might know - bit isolated here in UK. Many now talking the language but if using BPMN…..?

A few external comments from third parties might help
• ".....has re-written the rule book for application building." -- Oracle Press release

• "The software is an innovative and powerful application development tool which is business process rather than software vendor driven." BT Evaluation

• Off the cuff real comments: “It will knock your socks off”, “It will save you millions” “Why do it any other way?” And a user “It captures all my weird and wonderful ideas and all done without telling me that I am expecting too much!”

The fact we do not need “IT” has been a huge barrier as we are seen as a “challenge” or completely nuts taking on the big vendors.....! All early adopter have been business and user driven.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Don Schuerman Accepted Answer
Hi, vendor here (cue boos and hisses...).

We made an explicit decision not to make BPMN (or process flows in general) the central metaphor for defining applications precisely because of the points many of you have raised above. Modern "processes" are becoming less "processes" in the traditional, linear sense and more a series of loosely coupled "stages" that link together in an often unpredictable order to deliver an outcome. Some stages may involve structured work that is best represented as a process diagram using BPMN notation. Others may be completely "social" in nature...the work to be done will be discovered by runtime collaboration between users. The order of stages themselves may be decided at design time, or decided at runtime.

Providing a runtime engine to support this mix of structured and ad hoc work is not an unsolvable problem. It is a combination of technologies (process management, case management, event management, predictive rules, etc.) that are well known. (One could make a legitimate technical argument that social networks and "chatter"-style feeds are really just human-centric event systems.)

The challenge for vendors like us will be coming up with the visual tools that allow users to mix the pieces of work that should be (or for regulatory reasons must be) structured processes, with the ad hoc work that will be increasingly developed on the fly by users. And tools to analyze the ad hoc work and capture it into new best practices. Personally, I think we've made some great progress on this, but it involves stepping outside the limitations of process modeling standards like BPEL and BPMN. And we still have work to do.

To repeat a bit of Max's insight, the key to "solving" the social aspect of BPM is to understand that BPM is not just about process, its about outcomes. Maybe we should just rebrand the whole thing Business Outcome Management. ;) Practitioners of BPM (and builders of BPM tools) need to help our clients deliver the outcomes they need: an easier customer experience; happier, more productive employees; compliance with changing regulations; repeatable efficiencies that drive profitability, etc. That will take a world of traditional, structure process merged in real time with social collaboration.
Comment
I like that: Business Outcome Management :-)
  1. Keith Swenson
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 14
John Morris Accepted Answer
Peter Schooff just retweeted this discussion as worth visiting, and it is! Lots of great insights for sure. Especially a focus on business outcomes and the difference between stateful and stateless systems is interesting.

I like to put ERP and BPM in their governance context: ERP and BPM software only exist to help organizations execute work with greater productivity for given resources. And per economist Ronald Coase, organizations exist at a specific size where the cost of coordination is optimized. From this, and probably common sense too, it is possible to conclude that organizations therefore are necessarily about repeatable work.

And thus we get to the technology which explicitly supports repeatable work, namely BPM. (This is also true of ERP.)

Why mention the economics of organizational behaviour in a discussion of social ERP and social BPM?

Because there's a tendency to see traditional software and BPM software as a straight-jacket limiting the human potential and business capabilities of individuals. And if only we could give individuals more autonomy, life would be better. But the premise is faulty.

If work still needs to be done by humans, then by definition a large portion of that work in organizations is necessarily structured in some way. So-called social software is quite interesting for sure, but really quite difficult to employ in the services of organizational outcomes.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.