BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, March 30 2017, 09:55 AM
  4.  Subscribe via email
As the last discussion brought up the different interpretations of the term workflow, what do you think continue to be the most misunderstood or misused terms in BPM?
Bogdan Nafornita Accepted Answer
Process.
Managing Founder, profluo.com
Comment
Misunderstood? It's a picture of boxes and arrows, isn't it?
  1. Emiel Kelly
  2. 2 months ago
+1 to Bogdan.

Keith et al. did a great job by developing a commonly-agreed BPM definition but we still aren't even close to common business process definition. What's worse, the range of interpretations is tremendous.
  1. Anatoly Belaychuk
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Emiel Kelly Accepted Answer
Bogdan stole my answer.
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
1st place - process (Thanks to Bogdan)
2nd place - case
3rd place - BPM

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
John Morris Accepted Answer
"Work".

Because work is the "why" of technology, and in turn, BPM is a technology of work, specifically "the work of business".

It's surprisingly infrequent that one sees BPM tied to work and the work of business. Not referencing the why of technology counts as a misunderstanding of BPM technology. And the benefits of BPM technology too.
Comment
It's worth being a specific as possible conderning "work".
Here's the discussion on work, from the Paper referenced above:
---------------------------------------
"All Organized Activity Is Work"
"Business or any organized endeavour starts with a purpose. And then that business executes on that purpose by the expenditure of effort. This is our starting point then: purposeful effort. And that’s called work. All organized human endeavour is about performing “work”, the expenditure of effort in support of some purpose. And in a macro organizational context, organizational work then adds up to a value chain."
"The job of management is to organize work in support of that value chain. Specifically, the job of the executive is to decide what work should be done, i.e. what effort should be expended in support of defined purposes. All business or government or non-profit managers and executives want to organize work. That’s what managers do."
"Following from this, if work is what organization is for, then the use of technology to be more productive in our work would be very important."
---------------------------------------
One could add a reference to work and systems theory. The purposeful expenditure of effort (i.e. "work") enables the change of a system from one state to another (or the creation of a new system or object ex nihilo).
---------------------------------------
The paper reference again here on BPM.com: Paper I, Part 2 -- " Introduce The Work Of Business".
http://bpm.com/bpm-today/blogs/1148-why-bpm-is-unique-important-part-2-introduce-the-work-of-business
  1. John Morris
  2. 2 months ago

Ah, "work" (as in "workflows" -> "work" -> objectives", orchestrated by processes/process fragments / ad hoc interventions).

Here is a carry-forward of part of a comment at Tuesday's Question (relating to "workflows").

"
I understand what Keith is saying i.e. that workflow has several definitions.

For me, all work "flows" - there is no point to work that does not have some objective and usually there are several/many transformations of inputs to outputs required to go from the start of any initiative to reaching the objective of that initiative.

If we consider a process comprising a number of steps linked by directional arrows and we remove the arrows, we still have a process (albeit unpredictable in terms of sequencing of the steps) AND the steps will remain linked, as a result of the passage of time.

There are (3) reasons for the linking

1) most organizations do not have sufficient resources/capacity to undertake all of the steps making up an initiative at a particular point in time.
2) different steps take longer to perform than others, so, whereas given near-infinite resources, you might be able to start all steps at one point in time, but it is not possible to finish all steps at the same time.
3) some steps have practical/physical constraints (i.e. you cannot put together an assembly and then proceed to manufacture the parts that are needed to make up that assembly).

So, work "flows"

The progress of work in many cases is evidenced by data recorded at steps. It is not sufficient to simply declare that a particular work step is "complete" - it may be essential to capture operational data needed downstream at, for example, an algorithm. Therefore, data "flows" as well. Where? Along each Case timeline

The focus of some work also "flows" . .

A document can "flow" from one department to another, picking up data; parts can "flow" along a production conveyor belt as parts morph over to sub-assemblies, to assemblies, to a final product.

We can have people that "flow" in/out of a site where the focus of attention might be a aircraft under maintenance/overhaul/repair. Parts "flow" to the site and become part of the aircraft. Tools that are not disposable "flow" in/out.

WORKLOAD is different - it is a state of affairs that exists at a particular point in time at an individual's desk, across individuals; within Cases, across Cases.

Workload impacts workflow - add more resources and you increase the flow, take away resources and you decrease the flow.

Getting back to the impact of Apple "Workflow" - as various commentators have pointed out it seems geared to individuals, not teams, not corporations, not multiple corporations (related or not related).

What is lacking in Apple "Workflow" is communication under the scenario where an initiative cannot be entirely performed by one individual.

Absent Cases or end-to-end processes, it becomes difficult to set objectives and track progress toward meeting such objectives.

If you have never seen either Apple "Workflow" or a run-time Case UI, it probably is difficult to walk up to a person at a desk, take a screenshot, then go away and figure out whether orchestration and governance are at work behind the scenes.

Both users are likely to have a "to-do" list on one side of their screen, both users are likely to have a calendar on the other side of their screen.

I figure many workers only care about two things:

a) emptying their intrays
b) making sure they go the right places at the right time for calendar events.
  1. Karl Walter Keirstead
  2. 2 months ago
In the BPM.com paper series "BPM As Revolutionary Enabler", work is the subject of discussion in Paper I, Part 2 -- " Introduce The Work Of Business".
http://bpm.com/bpm-today/blogs/1148-why-bpm-is-unique-important-part-2-introduce-the-work-of-business
  1. John Morris
  2. 2 months ago
I should probably add "work" to my list of things to explain. Its definition has expanded quite a bit too.
  1. Rachel
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Kay Winkler Accepted Answer
In addition to the above, I often found challenges of users to keep apart the terms and concepts of process rules (engines) and business rules (engines).
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Rachel Accepted Answer
All of my answers have been entered already!

I sell and market process automation and analysis products. These are the top three things I have to change clients' perceptions about (as well as to our newly hired sales staff). With the bonus of how I usually do it. Would love to hear how others accomplish this.

1) Process.

When I am talking with new clients, I always have to help them redefine this concept. Processes are not rigid or constraining. Processes aren't limited to C follows B which follows A. There are lots of types of processes, and some are better than others for achieving the business outcome you desire.

2) BPM.

If they are a greenfield client it is fantastic; I don't have to battle preconceived notions based on past failed projects.
When they have had a few high profile "BPM" projects that cost millions and took 24 - 30 months then nothing came out of it, or what did come out of it was not useful... you have an entirely different battle/sales cycle on your hands. I jokingly refer to this as the six sigma stigma. This is the point where I start talking to them about traditional processes and projects and contextual processes and projects. They have different purposes, achieve different outcomes, and have different time investments.

3) Case.

Even I have to admit we need a new name for this. What it covers has expanded so much that "case" doesn't even get close to describing it. I don't have a pithy explanation for this one (yet). I just tell them it is a holdover from its origins and explain the history a bit.
Comment
When Case is a post-relational dbms cursor position, you basically have a "container" that can accommodate pretty much anything you can throw at it (structured data, unstructured data, files, documents, images, video/audio).

With 4K and 8K recordings you quickly discover it is not practical to park these IN cases. You are better off pointing to external files - unfortunate in that it violates the 'rule' that everything should be "in" the case.

We do need a new word - it causes eyebrows to raise (or heads to tilt) in some industry/application areas.
  1. Karl Walter Keirstead
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
John Reynolds Accepted Answer
+1 to the previous responses...

I think the "M" in BPM is in jeopardy of being meaningless. Is it Management? Is it Modeling? Is it Monitoring or Measuring or Mentoring?
Perhaps it's just Money (as in Money Pit)?

Customers know that their Business Processes are important - but they're focused on fixing (what may be derivative) Problems, and it's not always crystal clear how a vendor's focus on "BPM" is going to fix those problems.
Comment
@John Reynolds -- true, but the happier of two scenarios 1) what can we do with surplus cash? 2) how are we going to re-design our airbags to kill less people? clearly is the first.
  1. Karl Walter Keirstead
  2. 2 months ago
+1 everyone who approaches a BPM sales opportunity from the "point of view of the customer" -- or even better "the point of view of the customer with a problem that we can fix". This is canonical sales of course.
But I do have a question concerning how adoption of new technologies differs from on-going commodity market processes. And my question is especially applicable to circumstances where a new technology requires management involvement.
Compare the adoption of BPM technology to the adoption of accounting, which was not only about "problem-solution", but also required business to adopt a demanding new vocabulary of debits and credits and cash flow etc. etc.
The question of management responsibility around adoption of demanding new technology also applies to BPM . . . there's no free lunch.
  1. John Morris
  2. 2 months ago
Good point Karl... But every opportunity has at its root solving somebody's problem.
  1. John Reynolds
  2. 2 months ago
2nd time this week I have seen BPM in reference to "problems" - what if the best bang for the buck is not solving a problem but moving forward with an initiative?

Many initiatives are solutions (i,.e. opportunities seeking attention).
  1. Karl Walter Keirstead
  2. 2 months ago
Great point @John, that is why we never approach our mid-enterprise customers with a "we have a process" message. We always ask "what's your biggest problem?" and then we propose a fix. That fix is part of a process that gets deployed to the customer.
  1. Bogdan Nafornita
  2. 2 months ago
The reason they are focused on fixing is they don't spend enough time on planning, part of which anticipates/avoids situations that end up needing fixes.
  1. Karl Walter Keirstead
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Zachary Kelemen Accepted Answer
People who are unfamiliar with BPM seem to struggle with the idea of modelling process and using a platform just for process. For some people (generally the ones experiencing the process problems) it clicks immediately. Others don't see the value and always seem to bring up "why cant we just create a custom application to do what we want?" as opposed to using standards and a platform meant for such a thing.

Ultimately I think its really going to depend on the organization and the individuals aptitude in process. So i'll +1 the process comment.
Zack Kelemen - Digital Process Practice Lead at Rightpoint
Comment
@Karl, Actually, we need both of them and extra knowledge how to use them together.
  1. Dr Alexander Samarin
  2. 2 months ago
@Alexander .. Precisely. And I wonder what Forum participants pick as their understanding of BPM?
  1. Karl Walter Keirstead
  2. 2 months ago
Management [of business] by/via business processes vs. Management of business processes per se.
  1. Dr Alexander Samarin
  2. 2 months ago
There is , for me, a big difference between [Business "Process Management"] and ["Business Process" Management[
  1. Karl Walter Keirstead
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
E Scott Menter Accepted Answer
Blog Writer
Task.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
Good one, "task". The specific instantiation of a unit of "work". And a binary object including "signifier" and "signified", or persistent BPMN symbol and the actual but ephemeral work itself. Thus we have semiotics. And the ever present danger of reification - thinking that the task symbol *is* the work. And then the actual work and the actual workers are forgotten. (I'm sure this never happens . . . )
[Maybe it would have been better if I had "left it right there" -- but, hey, why not have some fun with BPM?]
  1. John Morris
  2. 2 months ago
I'm just gonna leave that right there...
  1. E Scott Menter
  2. 2 months ago
Surely you jest?
Activity trumps Task ;-)
  1. John Reynolds
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
David Chassels Accepted Answer
BPM itself has yet to be truly recognised as the formalised way to think when looking at how information is created and used in a business. It is not a technology yet to think BPM it is important that business understands in their language just how their thinking can be readily converted into a real deployable solution. Just producing a picture is not enough and if that is all BPM can deliver requiring IT to take forward then no surprise becomes an exercise that business users are unlikely to support.... Big vendors have no interest is seeing BPM take this next big step...it will bring simplification where too much is at stake with current complexity.... but just a question of time......?
Comment
I think the horse left the barn a long time ago.

I don't think our records go back far enough to track when we first linked our graphic mapping environment our run time Case Management environments via a compiler.

The RT environment we manufacture has users needing IT or, more likely, a BA for complex rule set building in the mapping environment and IT for writing parsers and formatters that allow local and remote third party apps and systems to talk to RT environment Cases via a generic data exchanger product that we also manufacture.

Aside from these two areas, functional units can build/ model/ rollout/ test/ improve and then have a process librarian deploy their processes.

EXCEPT THAT. some functional units do not seem to have any resources able to "think" process, or willing to map out processes, or able to find the time, so someone has to step in.

The Case Management environment our group develops and uses internally does not support (or need to support) any coding of any kind (aside from rule set "coding") - any customer who adds / changes / deletes database fields immediately violates their support agreement.

Standing rules if you find the system is unable to carry out specific processing, look for a 3rd party solution you can link to or come to us with a "development request".

If we get enough requests for a certain function that is a good "fit" and we can make it generic to the point where it does not encumber ,we may respond.

If a customer absolutely wants a feature/function, is willing to fund it, agrees they will not own any part of it, then we will add if, again, there is a good fit and the feature/function does not encumber.
  1. Karl Walter Keirstead
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
John Reynolds Accepted Answer
I cannot find words to express my respect for the self-restraint of the folks in this forum...

I was absolutely sure that someone would respond that "B" is the most misunderstood aspect :p
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Boris Zinchenko Accepted Answer
All. In short, all terms in BPM are misunderstood. This misunderstanding objectively appears due to mixing enterprise contexts.

Being in the center of enterprise architecture and processes, BPM objectively appeals to versatile groups and enterprise divisions. Each of these groups has very specific terminology and vision of every model and term, which it routinely uses. It is hopeless and counterproductive to convince every given group to think in terms of a different group. However, all groups still share a single model describing given organization. How to resolve this contradiction?

Since a singular enterprise model objectively exists (even if not explicitly expressed) and different groups of users work with it in their own ways, we can deduce that every group of users utilizes individual projection of the entire model. Multiple projections of the same model or process can be written in different notations, use different modeling methodologies, have non-similar visual symbols and appearances on diagrams but still consistently express valid projections of the single model behind. EPC, BPMN, UML, XPDL and whatever more notations can well coexist and complement each other.

This situation explains crucial role, which play process repositories and master data management for a successful BPM implementation. Well configured process repository serves as a single point of truth and implicitly translates aggregated enterprise model into projections and terms understood by each group of stakeholders.

Single BPM terminology cannot be achieved similarly to a single world language. Just on the contrary, a mission of BPM is to maintain versatility of terminologies, which are comfortable for each user group, similarly to maintenance of all world’s cultures and individuality. In this situation, well established model translation services acquire same crucial role as automatic translators of natural languages.

Please somebody knowing a word in Japanese comment on how well Google did with translation.

http://caseagile.com/wp-content/uploads/BPM_Japaneese.png

To illustrate it we can also refer to renowned parable of the blind men and the elephant originating in ancient India:

https://upload.wikimedia.org/wikipedia/commons/thumb/4/45/Blind_monks_examining_an_elephant.jpg/640px-Blind_monks_examining_an_elephant.jpg
References
  1. https://translate.google.com
  2. https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
Comment
@Boris, re ". . . . all groups still share a single model describing given organization."

Can we do a few rounds on this?

By "groups" do you mean all groups within a particular organization OR all groups that are outside but are looking (objectively, we hope), at an organization?

It probably does not matter because it seems to me that different clusters within an organization and outside of an organization probably have surprisingly different views, which they may or may not communicate.

So, my initial impression is everyone views a particular corporation differently.

It is not altogether impossible that the members of the board of your typical corporation have no way to focus on what is core/what is not core to their organization.

RBV (Resource Based VIew), IMO would allow them to put a focus on mission/strategy development.

We use it, it seems to give good results, but I don't find that RBV has had that much success. The model here is very simple ".. Be the best you can be" so it would appear it is on solid ground.

Just another methodology that a few people wrote up a few papers on, but try to get a top management team to embrace RBV - it is not easy.

My take on the lack of enthusiasm is these groups have not had tools to allow them to dynamically focus on RBV. It's one thing to attend a weekend seminar on an topic but come Monday morning the usual outcome is it's back to standard protocol

Take a look,. tell me why you think RBV has generally not be able to achieve liftoff and let me know if you think 3-D free-form search Kbases have the potential to change this?

See
"Theories of the Firm – Expanding RBV using 3D free-form search Kbases"
http://wp.me/pzzpB-Ms

Looking forward to comments from anyone who tunes into this Forum.
  1. Karl Walter Keirstead
  2. 1 month ago
@Karl, thank you for so detailed feedback.

By groups I mean any internal or external users of BPM system. Of course, they can be members of organization or just clients or partners. Naturally, every such group requires own projection of an enterprise model for many reasons. Information disclosure, technical background and job functions are among primary motivators for distinction. Normally, it is achieved on diagram and folder level of enterprise publishing to delimit access for individual groups to specific parts of the entire model. For instance, our BPM publishing portal works in exactly this way.

However, it this comment I suggested to move this segregation substantially further and filter information even on the level of individual diagrams. Moreover, specific diagrams of one and the same model may appear in different notations and layouts for different groups based on their role in an enterprise, while still rendering one and the same core model. It is very much along with popular MVC (Model View Controller) principle widely applied in software design but less known in BPM where one model may have multiple views (diagrams) and controllers (e.g. form flows). RBV (Resource Based VIew), which you mentioned, looks close to this but not exactly same.

On another hand, I’m deeply impressed with your excellent link on 3-D free-form search Kbases. It definitely has a lot of potential. I can remember also visual designer of semantic queries in HP CMDB. Semantic search is also among most widely used features of our process hub. Hopefully, we will borrow something from your materials in our further development.
  1. Boris Zinchenko
  2. 1 month ago
The idea of an enterprise model which exists de facto is powerful. It is also a statement which puts software engineering on a scientific basis. On the basis of this assumption then, "projections" are possible (I think this is a reference to mathematics) as required by different roles. And thus a BPMN-based BPM model is one such projection. I would argue that the enterprise model itself is not ultimately unique to a given enterprise, but that any enterprise model is itself a projection of all enterprise models, defined in terms of work and economics. (The article series "BPM As Revolutionary Technology Enabler" on BPM.com starts from this premise.)
So, why does all this matter? Because if one accepts that there is the possibility of a common semantic or ontological foundation for enterprise and work, then there is the possibility of software technology artefacts that can be built and shared. And there is the possibility that these artefacts, although based on a common language, will also be compatible with the requirements of unique enteprises and roles. This is therefore the scientific basis that software engineering and software business is possible on a rational basis as opposed to what today is mostly a craft basis. The market and social implications are significant; the difficulty however is high.
  1. John Morris
  2. 1 month ago
@John, thank you for remarks. Of course implications of model projections are much wider and actually manifest universal bridges between an enterprise and technology in general. One can say that every physical implementations of an enterprise, such as partner relations, production facilities, IT infrastructure, distribution channels etc. all manifest narrowed projections of the aggregated enterprise entity distinguishing and outlining it in surrounding economic environment.

To illustrate it we can refer to renowned parable of the blind men and the elephant coming originating in ancient India: https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
  1. Boris Zinchenko
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Amit Kothari Accepted Answer
The most misunderstood concept in BPM is the assumption that someone holier-than-you knows how to create a ridiculously complex flowchart so that they then "empower" you to follow it via "change management" supported by "execution" by the underworld of IT in a basement in order to ensure that you can be automated away more easily and can be boxed up properly to eliminate the chance of being creative.
Comment
I don't think that is called BPM ;-)
  1. Emiel Kelly
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13
  • Page :
  • 1


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