From a white paper that I’m working on now:
I think that the whole “BPM versus ACM” debate has completely blown out of all sensible proportion, when we’re really talking about a spectrum of functionality that ranges from structured process management (or what some people think of as BPM) to completely dynamic process management.
The key, to me, is that it’s not an either-or situation: almost every business process that I’ve ever seen lies somewhere in the middle, with both structured and dynamic aspects: in some cases, different workers may perform either highly structured or highly dynamic functions, depending on their role. We need both end of the spectrum – and everything in between – to manage our processes, and we need them to work together in a cohesive environment.
I’ll publish the link to the white paper, which explains this concept in a lot more detail, when it’s complete.
Thanx for that post. The customer is driven crazy with all the 3 letter acronyms. We should more speak about platforms supporting the daily work on tasks of a worker in manners you have described.
Nice diagram, I believe it covers all patterns.
There may be only one aspect worth to mention: the time dimension. Some “things” born as cases become processes when the company matures.
Anatoly, I write about that in the paper. I’ve certainly seen situations where dynamic cases become structured processes based on some process mining to detect patterns, but there are also the opposite: structured process implementations where the recognition of the dynamic parts comes after implementation, when the users have to do too many work-arounds to make it work.
Sandy, I fully agree and have written about this a number of times! It is about business needs and not about acronyms. But there is always someone who asks: ‘So is this BPM?’ Meaning: ‘can I do this with my BPM?’
In terms of the process landscape I put a very similar chart in ‘Mastering The Unpredictable’, just that I expanded it along the axis from programmed processes in ERP to Social on the right.
http://isismjpucher.files.wordpress.com/2010/11/process-spectrum.png
Let me point out that in MY definition (others may not agree) ADAPTIVE supports all of the above (structured, structured+ad-hoc, adaptive (user created templates)+flows, and purely adaptive.
From Dec. 2009 – http://isismjpucher.wordpress.com/2009/12/04/adaptive-process-defined/
‘I propose that we need to provide Adaptive Process technology that exposes structured (business data) and unstructured (content) information to the members of structured (business) and unstructured (social) organizations to securely execute – with knowledge interactively gathered previously – structured (process) and unstructured (case) work in a transparent and auditable manner.’
It is purely a matter of what the users choses to do!
I have also written (for years) that this needs a comprehensive, consolidated environment, infrastructure or platform (supporting an architecture and rules) that also includes inbound and outbound content handling. Thanks for supporting my proposals. Look forward to read the White Paper. Regards, Max
Sandy,
I agree there are way too many arguments about BPM vs. ACM. It is a spectrum and you need different tools to cover it.
The only argument I have is that using a processexample like “innovation management” makes the unstrucured end of the spectrum sound very esoteric. I would claim that is actually where many (most?) real world processes actually reside – processes like decision management, investigations and many other types of knowlege work. It is the process part of what people like us use do everyday.
Jacob Ukelson – CTO ActionBase
Jacob, I think that your example of investigations is a good one for the dynamic end of the spectrum — I may use that in the final version of the diagram!
Max, nice diagram on your site, I hadn’t seen it before. I agree that it captures much of the same sentiment.
Whether “adaptive” products and definitions expand to include everything from adaptive to structured, or structured products expand to include adaptive, the end is the same: a consolidated environment for the entire range of process management.
Sandy, I don’t have to repeat that I’m completely inline with this thought process. I really like the way you’ve laid out the continuum. In fact, your post reminded me of a picture that I had posted on Redux some time back, I have reposted it here few mins back, just couldn’t stop myself!
http://ashishbhagwat.wordpress.com/2011/03/16/five-styles-of-process-revisited/
The continuum continues…!
Cheers,
Ashish
Ashish, I saw that research at a Gartner conference a few years ago and think that it plays well with this discussion, thanks for re-introducing it. I just addressed the structured-to-dynamic dimension since that seems to be at the heart of the BPM-ACM arguments these days; they incorporate many other factors into their process patterns. Funny, the chart that you show is from 2005 and has 5 patterns; in 2007, they were discussing 6 patterns. Wonder how many they’re up to by now.
Sandy, I’m sure there are at least a couple more added recently due to the two key advances, one around mobility and another around social networking. They definitely add another flavor or styling to add effectiveness to certain processes to leverage on these technologies. Not that I subscribe to the notion of creating a “separate” industry out of every niche advances that we go through though!
I’m really looking forward to your white paper, (nothing wrong with focusing only on this dimension of structuredness – very important for focused clarification!) I’m sure there are debates raging in content/documents centric BPMS (Filenet, Documentum, Sharepoint parts of the world) and the Integration/transactions-centric BPMS (in the middleware parts of the world – TIBCO, Oracle Fusion, etc…), but that’s for another day! That reminds me of another post of mine on Redux (that evaporated with it) that went something like “It’s time SOA wrapped BPM gave way” 🙂 🙂 🙂
Good one Max! been reading your stuff for sometime, like the holistic approach! 🙂
It are not the acronyms that are confusing. It are the concepts themselves. BPM is supposed to manage business processes. Including processes that require runtime flexibility. ACM is just an attempt to create yet another sweet spot to differentiate. And what do we get? Completely alienated audience. Who on earth will buy into this?
We should first focus on the requirements for true enterprise wide process management and move away from discussions to position rules, stp, case management, BPMN, BPEL, ECM, orchestration, etc, that are irrelevant as long as we as an industry are not even close to compete against enterprise solutions based on ERP. Why can this from a business process perspective inferior technology achieve enterprise wide implementations, while most BPM projects are limited to single processes or departments? Why do we keep having these inside out discussions? Look what is happening in the market. Pure play vendors move away from BPM or get acquired. BPM is now just a little component in big suites form Oracle, IBM and even SAP. Of course it is BPM bullshit what they sell, but at least they have an external audience. BPM events these days host vendors, analysts and consultants. Less and less business audience. We have to get our act together and broadcast a coherent vision, success stories and enthusiasm about BPM, instead of making things complex or confusing.
Sandy –
Just came across your post here, and I ‘m delighted to have found it. Your spectrum is a great way to frame the times when structure is needed, and when you flexibility should be the focus.
I’m VP of Product at Spigit, which is a SaaS innovation management provider, focused particularly on crowdsourcing. We just released SpigitFusion, which is an adaptive workflow application for handling the best of the crowdsourced ideas. I notice you’ve got innovation management slotted to the right of your spectrum, and that’s where we’re seeing it as well.
In describing the need for an adaptive approach to innovation, I put it this way:
“The unpredictable nature of ideas requires structure without process rigidity”
I blogged a fuller description of the thinking behind the release as well:
http://www.spigit.com/2011/01/fusing-evaluation-with-crowdsourcing-to-accelerate-innovation/
To be honest, our enterprise clients demand a bit more structure than purely adaptive, even in innovation management. Max has a smart approach with his more holistic thinking around adaptive.
Anyway, saw your post and thought it was great. This is an area I’ve put some thought into, and found your spectrum to be a great framework.
Hutch Carpenter
VP Product
Spigit, Inc.
http://spigit.com
Reply to John Hoogland: There are points you make that I agree with and others that I don’t. First, the acronyms aren’t produced by vendors but really when analysts certify them as a valid market segment. Then they split them up further so that they can rate more products. I use BPM as a management paradigm and BPMS for the products. Pure play BPMS are a waste of time and money. They are way to complex to implement and manage because they need IT AND a process Center of Execellence.
I thus totally agree with you on the BPM implementation situation, but it won’t be improved by a more coherent message, it will only be improved by more coherent and holistic software platforms. The reason the ERP made it big is that they provide businesses with embedded knowledge. BPM doesn’t do that and the BPM vendors that made it big are the ones that sell ‘DROP-IN’ process frameworks or who sell an implementation package. Most large businesses are quite inept at running their show and they look to the software to do it for them.
Where I do disagree is that ACM is a BPMS that looks for a sweet spot. ACM is a different approach in principle and the ADAPTIVE process concept it employs goes even further. But both do in principle do process management, just not in the normal flowcharting sense. Just because you can show something after the fact as a flowcahrt doesn’t mean you can plan and execute it that way!!! All adaptive processes can be viewed in a BPMN diagram, but no one would have known in advance that they would pan out that way.
There is in principle also nothing wrong with Outside-In. It is just a very limited perspective on how to DESIGN processes, when ‘moments of truth’ CAN’T be designed. They can be enabled and supported but they happen from person to person ONLY!
The input to an Adaptive Process concept must be holistic and start from defined and embedded business objectives and targets, related capabilities and process goals, and yes, most of all it needs to verify the customer outcomes that can’t be guaranteed by a rigid execution. Adaptive Process is mostly about using an architecture perspective and then apply business strategy to define the goals and let people loose to create and adapt until you fulfill the goals and outcomes. No external bureaucracy needed.
I agree with you too on the BPM events. They are a waste of time too. Regards, Max
Hi Sandy,
Great to see support for an integrative approach to Business Process.
A good reference for your paper, you might already know it, is Paul Harmon’s Review of the Adaptive Case Management Book. In it Paul provides a thoughtful review of his own experience and various approaches to process. http://bit.ly/gdh6WE
Two good quotes –
“Most categorization approaches tend to oversimplify the endless variety of interactions between human, system and information resources that happen in any process…” Janelle Hill, Gartner, Mapping Process Problem Spaces to Solution Spaces, April 6, 2010
“The key point here is not that a dynamic approach is inherently better in all use cases; it is that without the ability to dynamically bind process elements, the purely procedural approach inhibits the potential architecture… After a while, one discovers that long term TCO is closely related to the ability to elegantly handle exceptions.” Derek Miers, Forrester, Finding The Sweet Spot, March 31, 2010
I’ve been promoting an integrative approach for several years (I know others have too), but as in politics, anytime you take an embracing view, you risk getting nailed from people on the extremes.
I have found that ACM folks idealize the user and BPMS folks idealize central planning – both are wrong. Structured and unstructured work are polarizing views, there really is just work, which has varying requirements based on its context.
From a business perspective, structure shouldn’t be a function of a technology, or a defined process, it should be a function of an interaction (i.e. the work and hand, the current circumstances, and the applicable policies that apply (transaction controls, governance policies, and business rules)).
Good luck with your paper. I’d love to see it.
Dave
Dave, I agree that (HUMAN) interaction is the key (and thus not all ACM folks see structure as the devil).
From my blog post in Dec. 2009 – Adaptive Process Defined:
http://isismjpucher.wordpress.com/2009/12/04/adaptive-process-defined/
“I propose that we need to provide Adaptive Process technology that exposes structured (business data) and unstructured (content) information to the members of structured (business) and unstructured (social) organizations to securely execute – with knowledge INTERACTIVELY gathered previously – structured (process) and unstructured (case) work in a transparent and auditable manner.”
Max – I am happy that we can agree. We have different technological approaches, but I believe we seek to address the same fundamental challenges.
Regarding the graphic, I know its instructive to put archetype processes under each header, but in a way it unintentionally reinforces old views that run counter to your theme. For instance, we work in highly-regulated environments, which do have procedural compliance requirements, but the requirements are highly-variable and subject to routine change, making them poor candidates for static models. Compliance is not really a static notion, rather you stay in compliance, so requirements must follow interactions.
An interaction driven system can enforce a sequence of steps without requiring fixed flowchart snippets. This approach can support the range without technology switching – that’s holistic. This doesn’t mean that it can’t interoperate with other systems, or that other systems don’t provide good value, but it does provide a path to consolidation.
Thanks all for the great comments — I had to step away for a day and haven’t had a chance to reply to everything. Certainly, there’s a lot of food for thought here for me, and you can all take credit for helping to refine and improve my ideas for the white paper.
Dave, certainly your last comment on the archetypal processes that I use on the spectrum is useful, I’ll be reviewing those to see how I can make them more representative.
Max (16),
We are in sync when it comes to definitions. It is better to just refer to BPM and BPMS. I am working on case management for 20 years now and I still believe Case management functionality should be part of every BPMS. I object to the idea that a BPMS landscape could exist of multiple BPMS flavors, each serving a specific process type. ACM is NOT a different approach. There are BPMS in the market for a long time that support case management and real time adaptation. There is no need to set it apart as something different to BPM(S).
I think your view on BPMS is too narrow. Your line of reasoning seems to be that a BPMS works on a flowchart and therefor that unplanned behavior cannot be supported. That is a very very obsolete idea. Many BPMS have the ability to handle execptions, empower users to defer form the predefined path, adapt rules realtime, etc. I think the cause why many implemations do not get to the enterprise level has to do with the fact that they are not implemented pure play. Most BPMS are not implemented as a process layer, but as an application development framework, where applications are built in stead of process controll environments. As a consequence process and data get mixed up, generating the spaghetti systems many BPM believers objected to in the first place when justifying BPM to cope with the empbedded process logic of monolythical systems. And as a consequence adapation becomes as rigid as before. Changing rules, process or data, then require new versions and high IT involvement.
I have seen (not many) succesful projects at enterprise scale where the business is in control ( and not IT). The reason for this success was a clear cut between process, data and content.
John, thanks for replying. I do not think my view of BPM is too narrow. There is a shift related to the purpose of BPM and exsiting BPMS simply aren’t capable of dealing with it. As you say in your last line BPM use is very narrow in most real-world implementations and the reason is the technology and management perspective used.
Anyway, ACM is not just about dynamic or Ad-Hoc processes. ADAPTATION is not just about modifying the currently executing process. Some see it that way but I clearly defined that it is about embedding the management into the platform as a runtime capability and not just the process design and execution. Just modifying processes at runtime does not modifiy the future execution template and it does not allow business users to create processes as they see fit in a social networking like manner.
A pure process.control environment is exactly the reason why BPMS are too limited. Processes are about applications which is why people build them. I rather would say that all business applications are processes or can be seen as processes. But just defining who interacts with whom when doesn’t supply a functional process. All that is pushed aside by the perspectives of social collaboration.
You exactly describe the limitation of current BPMS and BPM perspective:
“As a consequence process and data get mixed up, generating the spaghetti systems many BPM believers objected to in the first place when justifying BPM to cope with the empbedded process logic of monolythical systems. And as a consequence adapation becomes as rigid as before. Changing rules, process or data, then require new versions and high IT involvement.”
A PROCESS LAYER is exactly the BPM perspective that I am arguing against and this is where technology, management and IT people need to step beyond what they imagine a BPM/ACM system to be. Provide the platform and the architectural structure with technology that sets the business free to do as it pleases. Pull a data element into a process and use it without needing an IT person. Write a business rule based on that without needing an IT person, create completely new processes using the five elements of data, content, rules, goals, GUI without needing IT people. Provide top-down and bottom up transparency. But IT is needed to provide that infrastructure and to run it. That gives most IT managers the shivers …
John, I completely agree: when a BPMS is used as an app dev framework, and completely customized, that’s when it becomes rigid and unable to adapt. If these systems were used as designed, even more conventional BPMS would have a lot more dynamic capabilities than most people give them credit for.
An interaction-driven approach establishes a feedback loop.
It ensures that the system always uses the latest version of related system resources (e.g. any data, code, services, etc.) unless directed otherwise. This supports non-disruptive and continuous evolution.
The feedback loop also allows users to configure process/resources at run-time based on authority.
The feedback loop facilitates context-driven directions/recommendations based on inline analytics. Therefore usage patterns and success measures can adapt the application (i.e. Version/update the relevant resources).
Think that covers dynamic, emergent, adaptive and human-centered.
John – I like your post, that’s an honest assessment. BPMS is more agile without data integration and coded functionality, but it is also impoverished by that acknowledgment.
BPMS arms length relationship with data and capabilities, beyond basic process variables and built-in vendor features, limits its value to the enterprise as a whole.
Standalone processes reinforce the ‘let a 1,000 stovepipes bloom’ culture that is usually ascribed to SharePoint.
I understand that is convenient for lines of business, but in the end that creates a greater enterprise integration challenge.
Process drives data collection and data collection should feedback to process for informed decision-making. This divide between process and data is one of the biggest failings of the enterprise; BPMS has not addressed it.
Taken a while to read all the comments here, but there is a lot interesting thought.
Personally business needs a holistic approach to how IT is delivered to meet business needs, that means getting rid of certain silos (especially BPM, ECM and CRM) and bringing them to a single platform. Secondly, with regards to managing processes, we need platforms that can facilitate any way a business needs to operate a process, be that highly structured, unstructured, a blend of the two or something inbetween. You can argue that everythign is BPM (ACM, ADAPTIVE, APG etc) but that doesnt actually inform us of HOW processes are managed if we do that.
If you are the key decision maker in a business and you are looking at a way of managing processes (no matter if they are structured or not) you need to know how the solution tackles the problem, so that you can make an informed choice. By lumping everything as BPM someone outside of the IT or “BPM” world wont have a clue which one works for what type of processes best. This is wrong.
So arguments about “is it BPM or not” are pointless. BPM = structured approach, ACM = unstructured approach, and business wants both, hence we see terms such as APG or ADAPTIVE out there because they deliver that full spectrum of management capabilities to a business…
Finally, BPM is still seen as a silo, and silos arent holistic. Business needs solutions that are aligned to their needs far greater, and that means silos being destroyed…
Andrew, I disagree that BPM = structured. I think that disagreement on this definition is at the heart of this entire argument.
I would argue that it is highly structured, simply because we look to design processes and place them into a flowchart type environment. As soon as we do that, we are structured…In addition, with BPM to make changes, we go through similar processes of rigid structure, a change is identified, reviewed, then a BA or “process author” makes the changes, which typically only take effect on new items within the process. This is a structured framework, and makes processes quite rigid. It is also this rigidity that stops BPM working / working for so many other processes in organisations and why so many smaller businesses dont adopt BPM
Sandy,
I try to link your classification with http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html
Structured – variant 1
Structured with ad-hoc.. – nothing
Adaptive with structured snippets – variant 4
Adaptive – variant 3
And the result — it is necessary to go to the next level of complexity and consider sets of coordinating process-instances.
Thanks,
AS
Great response Andrew! Not because you are right, but because you are wrong. You exactly pinpoint the basic problem of how BPM is perceived. BPM is so much more than drawing a flowchart and put this into execution. See my previous remarks. But how you translate BPM is exactly how most vendors position BPM themselves. They claim code free development, instant agility, all based on a simple flowchart that easily can be defined and deployed by business users. This of course is not true and a joke in large organizations where you have so many processes, variations, complex integrations with other systems and all kind of localization issues (cynically enough, it could only work in smaller organizations that according to you do not adopt BPM for this reason….).
The whole point I try to make for years now, is that the BPM community is not open and honest about its capabilities. There are a number of BPM products that are able to cope with exceptions without the need to make them explicit on beforehand. There are also products that in different ways, allow the operational behavior of the system to be changed without the need to release new versions of the underlying process model, so without needing new versions etc. But the market place is made confused with false claims about standards, agility and hypes.
We cannot blame the market place for not adopting BPM. We have to look at ourselves, how we as a community create confusion and vaporware.
We have to return to the basics of BPM, which are
– Understanding your processes
– Analyzing processes
– Designing new processes
– Execute designed processes integrated with the existing application infrastructure. AND MAKE SURE NOT TO MIX DATA AND PROCESS. The runtime engine should allow profiled users to at instance to defer from the mainstream model, without the need to change the model itself (many product support this these days)
– Adapt processes, again without the need to change the process model definitions (I mean the ability to change routing, rules, work assignments, variables, roles and profiles, etc)
– Measure and monitor runtime
– Loop back to start.
We have to explain that BPM is a philosophy and a management approach that does not come for free. BPM is not successful by projects but by programs. It is not easy, not inexpensive and it is complex from a technical, managerial and cultural point of view. But rewards are true flexibility, control and ROI.
@John, I think everything you have written here confirms my statements that BPM is rigid and structured. Everything you discuss follows a structured pattern, and delivers a structured working process at the end of it, the BPM engine is highly structured and follows a set of determined rules (most of which have been designed very much up front).
I know what you are saying re methodology as opposed to implementation but the fact is BPM = BPMS. Lets not pretend it doesnt for the majoyrity of businesses out there.
I have yet to see a BPM implementation that allows my end user agent to create a completely new sub process – including the rules, guidance, data, attachments, interopability capabilities etc etc. BPM solutions have far to many overheads in terms of process and structure. In addition, BPM solutions still dont allow teams and workers to work in their desired fashions. BPM is not flexible in how agents choose to work that work. Lets look at swarming. I havent seen a BPM solution that allows a team to swarm around work and complete it, simply because that doesnt fit into a nice little process.
This could all be the fault of vendors, BAs or whoever, but to me and to business it doesnt matter whos fault it is. The point is thoug that BPMS delivers structured rigid working environments (which means BPM does to)…Which for 20% of processes is PERFECT. But we shouldnt be saying BPM solutions work for all processes, because they dont. Why do we see so many organisations opting for Case Management or ACM? Its because they dont have to enforce a structured process, they dont have to go through so many beuracratic layers and because they want to work flexibly…Traditional BPM doesnt deliver this
dear Andrew,
I think we are more in sync that it looks like. I just agree with Sandy’s remark about the fact that not all BPM – structured. I am not challenging the requirements for case management. I am defending that good BPM suites have ACM capabilites as an integrated part of the software. I am a strong believer in ACM. But not as another or separate solution. Many processes have both structured and unstructured parts. Any BPM engine that wants to manage end to end processes needs to be able to support both structured and unstructured process parts. A BPM engine that wants to manage end to end processes needs to cope with the complexity of process variations based on variables like product properties, localization, departmental size, user profiles, etc. And it just is not true that every exception needs to be modelled on beforehand (I always say that once you make an execption explicit, it is not an exeption anymore). There are good examples where BPM is deployed in such a way that end users can handle exceptions, that even at instance level they can defer from the predefined path, even without needing to model the alternative path. Many requirements with regards to real-time changing the operational behaviour of processes are supported. There is more flexibility in BPMS’s then people realize.
Sandy,
I’m hesitant to throw my hat in the ring with such illustrious company, but just wanted to say that I found the post thought-provoking, as I’m an ECM practitioner by trade who’s trying to learn more about ACM…great to find a concise, no-nonsense take on the subject.
I was even inspired enough to use it as the starting point for my own little post on ACM and BPM (http://bit.ly/fhtWMh)–so thanks for making me think, and I’m looking forward to reading the white paper once it’s out…
Cheers, and keep up the good work!
Joe
Have a look at this funny blog. Why is it funny? Because there is truth in it. It illustrates in an exaggerated way ACM cannot do without BPM.
http://adamdeane.wordpress.com/2011/03/28/acm-radical-man/
By the way, BPM needs Case Management as well.
“The Structure of Ill-Structured Problems”
From Foss, Kirsten and Foss, Nicolai J., Simon on Problem-Solving: Implications for New Organizational Forms (October 2005). Available at SSRN: http://ssrn.com/abstract=982084:
Simon’s 1973 paper is a strong defence of artificial intelligence against the critique that certain problems are too ill-structured (or ill-defined) to be computationally solvable. Against this argument he submits that any ill-structured problem can be made structured through certain processes of transformation (hence the title), and that this renders them computable (solvable). In fact, Simon (1973: 186) forcefully argues that virtually all problems presented to problem solvers are, from the outset,
“… best regarded as ill structured problems. They become well structured problems only in the process of being prepared for the problem solvers. It is not exaggerating much to say that there are no well structured problems, only ill- structured problems that have been formalized for problem solvers.”
Thus, well-structured problems are outcomes of problem-defining processes. Neglecting for the moment the nature of the processes, these outcomes may be characterized in terms of a number of requirements; thus, problems are well-structured when
1) All initial elements that enter into the solution of the problem are known and described or example, in chess the initial elements are the pieces, the board and rules of the game.
2) Trials on all level can be practically evaluated with respect to some effectiveness or efficiency criteria; also, the final proposed solution to the problem can be evaluated with respect to some such criterion.
3) The way in which the problem is solved must completely reflect the relevant laws that govern the external world for example, the solution to a marketing problem must completely reflect how consumers react to changes in styles, prices, etc.
4) Solving the problem requires only practicable amounts of computation (i.e., at a cost substantially below infinite) and the relevant information which is needed to solve the problem can be gathered by means of practicable amounts of search (i.e., at search costs substantially below infinite).
Evidently, these are very strict requirements, and few, if any, problems fully meet them. Even the playing of chess is not well-structured, since
“[p]laying a game of chess viewing this activity as solving a single problem involves continually redefining what the problem is. Even if we regard chess playing as a [well-structured problem] in the small (i.e., during the course of considering a single), by most criteria it must be regarded as an [ill-structured problem] in the large, i.e., over the course of the game (Simon 1973: 186).”
Any problem that does not meet all of the above requirements is an ill-structured problem. The implication is that the distribution of problems between well-structured and entirely ill- structured (i.e., none of the above requirements are met) is a continuum.
Joe – the white paper is complete, I’ll link when it’s published.
Chuck — thanks for bringing the academic posse to back up my original idea!
Hello Sandy:
Very important post. It shows the importance of blending Structured and Unstructured processes to translate it’s differentiation proposition from competition, and that it’s done though process execution.
I posted a framework how to put this all together here:
http://ultrabpm.wordpress.com/2011/04/18/the-decorator-enabling-structured-and-unstructured-processes/
Regards
Alberto.
Hi Sandy,
can you tell us where to get your Whitepaper?
Very much appreciated!
John
John, if you go to Software AG’s white paper download site (http://www.softwareag.com/corporate/res/wp/default.asp), you can find it there although you will need to register in order to download it. It’s called “Case Management and BPM”.
Looking at the diagram I wonder (western cultural bias) if it would be better ‘starting’ with the unstructured stuff on the left, as that is the origin.
Also there are several kinds of unstructured and informal systems that people use. I would consider private to shared as an important continuum dimension.
Michael, it’s not clear (to me) that things “start” with unstructured — my location of structured on the left was because of the bias (again, mine) towards the large body of existing BPM systems that use primarily structured processes, then moving to the right to discuss some of the characteristics that we’re seeing in the newer ACM systems.
If you check the presentation from my keynote yesterday at the BPM 2011 conference, you’ll see that I do consider other dimensions in characterizing processes, although I still think that the structured-unstructured spectrum is one of the key ones. I also consider the spectrum from controlled participation to on-demand collaboration (which may be similar to your private-to-shared notion), as well as internal to externally socialized, since the latter can have implications in platforms and user interfaces, e.g., if the external users participate in the process using a social media platform rather than an external manifestation of the BPM system.
Great discussion!
It is the case that most business processes are a mix of structured and unstructured behavior. In the research community, some workshops have recently started to address these ‘semi-structured business processes’ : http://cgi.cs.indiana.edu/~dsiweb/tc4sp11/ and https://sites.google.com/site/dma4sp/ and focusing on social BPM. http://www.bpms2.org/ Although BPMS2 is not directly about semi-structured processes, truly making people and their expertise first class citizens in the BPM paradigm has to introduce an ad-hoc component into the fully structured world. This is true even in the simplest way of adding well defined islands of people collaboration/interaction in a fully structrued uber-process with automated parts (in a very structured way via things like BPEL4People or most open like using Lotus Activities in parts of a Business Mashup like in (http://bit.ly/nIRKfT)).
Seamlessly moving across this spectrum will be an interesting challenge. Does it always make sense to do so or does one have to shift methodology and approach as one moves through the spectrum?
Rania, I agree that moving along the spectrum seamlessly is the biggest challenge. I also believe that this is truly a spectrum, so while some methods might shift as you move along it, there is a bit of any of those methods regardless of where you are in the structured to unstructured range.
Hi Sandy
I wanted to get a copy of the white paper and the software AG website does not complete the process of registration. Plus it seems to be in Deutsche / German. Do you have another link?
I would also like to chime in that the spectrum of structured and unstructured is exactly what we see in our community. Further, I believe, (dare I say) the execution semantics of BPMN 2.0 are rich to support some of this spectrum; if only folks take the time to read thru the chapter.
THanks
Vishal
Vishal, I posted a copy of the white paper on Slideshare at https://www.slideshare.net/skemsley/case-management-and-bpm since it doesn’t appear to be on the Software AG site any longer.