BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 22 June 2017
  5.  Subscribe via email
A question Dr. Alexander Samarin brought up in this discussion, what would you say are some of the key ways agile BPM can become less agile?
Accepted Answer Pending Moderation
Two of the more common ways of crippling agile efforts are to require (1) excessive progress reporting and (2) excessive documentation of work done. A third way is to hold too many formal meetings instead of simply huddling when there's something to work out. Progress reports can be brief and informal. Documentation can be developed later. Formal meetings are necessary only to kick off the effort and to wrap it up.
Comment
P.S. For a look at an early effort often cited as seminal in the development of "agile" see my paper titled "Prototyping: Systems Development in Record Time." You can find it atwww.nickols.us/prototyping.pdf Although it focuses on the development of a computer-based processing system, it applies to process work in general.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
In BPM, the true Agility is your ability to adapt the Process solution quickly when needed.
It's "nice" to be able to develop a process solution using an Agile Development Process, but not useful in the long run unless the solution is Architected for the Agility that matters down the road.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Agile where?

In mapping (fast?, easy?, ability to expand real estate in the middle of a flowgraph to accommodate more tasks? ability to clone a case to set up a new case)?

Or, during testing (change roles?, change data collection forms?, change logic connections? recompile and roll out new templates)?

Or, agile in terms of performing tasks at run time to achieve goals/objectives and balance workload across users?
References
  1. http://www.kwkeirstead.wordpress.com
Comment
Looks like the term "agile" is more closely aligned to "process discovery/prototyping" of BPM process maps [as in @Fred's paper]

Except that it seems to me if you talk to ACM/BPM enthusiasts, "agile" refers more to the ability to impact the evolution of run-time cases (i.e. Case Management) in terms of being able to skip steps, re-visit steps already committed, insert steps not on any process template, and record data at not-yet-current steps.
where ? end-to-end

Thanks, @Alesander - I had figured as much.

This market surely is shrinking, but likely to take off with IoT, where, with increased automation, business processes will become somewhat the same as highly automated industrial process control systems.
@Karl, yes, there are a lot of opportunities for BPM right now. In addition to your list, I can add
- smart contracts as inter-organisations processes
- security by design (i.e. for IoT)
- privacy by design (i.e. from the GDPR)
- various verticals, e.g. Smart Cities
Again, it maybe another question for Peter to ask about current BPM opportunities.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
1. Too much documentation
2. Too little documentation
3. Too much end-user training
4. Too little end-user training
5. Too much time spent on requirements
6. Too little time spent on requirements
7. No explicit, future-proof architectural concept
8. Building overhead as per the agile religious literature
CEO, Co-founder, Profluo
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Define the budget and the deliverable timeline before anything else or work is even started.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
From an implementation perspective:
There are certainly challenges to align the concept of agile, agile project management or lean agile with BPM since business process management as a discipline entails certain groups of activities that shouldn't be simplified, shortened or avoided at all (for instance a thorough discovery of the process as-is and the process to-be). For process implementations it is also important to identify the appropriate project and also functional process deliverables as part of an agile initiative. For example the final process design documentation and testing scenarios are usually viable delivery milestones. Process wise the “time to yes” portion of a typical human centric process could be a good deliverable of a scrum sprint.
I would say a deal maker or breaker for agile during a BPM implementation would be precisely that, not identifying the adequate deliverables that can be properly tested and more importantly used later on in production on their own.

From a production perspective:
There, an interpretation for lean could be the fluidity of the workflow (e.g. required steps and working time) and it's correlated quantity of still existing manual activities as well as reprocessing occurrences. In that sense, agile inhibitors are represented in the form of a lacking level of automation or even worse - an increased level of complexity that has been unnecessarily added to the process during design time. Both issues are usually intimately related to a lacking “BPM leadership and project management” during the process design and its implementation phase. In these instances end users tend to fear the loss of controls they are accustomed to have in the manual process. On the other hand, one can also face users that are so excited by the prospect of BPM that they end up adding even more controls, features and functionalities to the process that don't necessarily contribute to an improved process outcome or its optimization.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
First of all, why be agile? If agile is just opportunism, then you're on a random walk to oblivion. Instead you should know who your are and chart a path.

OK, you've justified being agile as just good project management and you want to constantly test your hypotheses (per Steve Blank) regarding new ideas. What will kill the success of your hypothesis testing? And what will kill the success of any new capabilities pipeline?

You can be sure not to be agile if you bury yourself in bits and bytes. Instead of wrangling things that matter -- specifically business semantics, governance, economics, sales and marketing, customers journeys etc. etc., -- if you're up to your neck in data chaos (the "MDM" problem) and interface h*ll and code -- then you won't achieve agility.

When you do achieve agility, then BPM software technology will be at the core of any such programme -- because BPM is the core technology of the business semantics of work. In other words, BPM is the business semantic technology of the work of business. To be agile is almost by definition then to work with BPM technology.

Agility is when business leadership can lead, and then have required technology artefacts, especially including BPM software artefacts, rapidly constructed which support the resulting vision and strategy. That won't happen unless business semantic technology can operate on it's own, floating above an infrastructure of data and interface. Mostly this hasn't happened yet, even though all necessary tools are available.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
John is right “Agile development practices” and “Architected for the Agility” are complete different (fortunately not contradictory) imperatives. See my ref [1].

Surprisingly, BPM (discipline, tools and practices) are naturally agile (if done correctly, of course). Very surprisingly, a lot of people (who claimed being agilysts) are killing this BPM agile nature by their working practices. Two real examples:

1. A workflow-based legacy application (actually, HR onboarding process) has been selected for agile refactoring with a modern (and very good) BPM-suite tool. Although we had all the business processes well documented, a tool guru (self-claimed agilyst) told us preparing user stories in accordance with SCRUM. When we asked why we can’t use existing processes to define user stories, this agilyst told us that we follow SCRUM. As the result, it was understood that this approach is too expensive (without counting the cost of this BPM-suite tool) and this project has been cancelled.

2. I was chatting last February with an chief enterprise architect from a big bank in Amsterdam. He told me that they have the best BPM-suite tool and they have successfully implemented a few applications with this tool. Those applications were done by tool gurus in a very agile and appreciated by users way. But, less capable tool specialists didn’t manage to maintain those applications. As the result, the bank put this BPM-suite tool aside.

Thanks,
AS
References
  1. https://www.slideshare.net/samarin/from-agile-development-to-agile-evolution-of-enterprise-systems
Comment
  1. John Morris
  2. 1 year ago
  3. #4135
+1 @Alexander for interpreting my comments for accessibility! And your examples are maddening! In the first example we have "agile-as-ideology" and in the second one we have "agile-becomes-entropy". In both cases, disappointment. Missed opportunity. My model is what Japanese car manufacturers did: took responsibility for what was inside the black box of car manufacturing. And identified the work processes that would result in better outcomes (along the way front-line staff were empowered -- in other words, the brain power of workers was an important part of the solution). How does this apply to your examples? Business leadership cannot ignore what happens inside the black box of technology artefact manufacture. Business leaders need to understand "agile" and "SCRUM" and "API entropy" etc., because this understanding is now a strategic part of corporate life today. Perhaps automation artefact manufacturing is not that different from car component manufacture.
TPS worked very well. Especially, I like its “looking over the shoulder” recommendation. But, as we remember, a few years ago Toyota surprisingly lost the first place as the top-seller. Toyota suffered the low quality of some spare parts from its suppliers. It was not possible with the Japanese culture. But Toyota started to use suppliers from other countries to reduce the cost. Thus, an implicit assumption put them down.

So, it seems that there is an implicit assumption that “Agile development practices” is equal “Architected for the Agility”.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Enterprise customers spend a lot of time acting as though they'd like very much to rid BPM of its agility. Generally speaking, such organizations fail to make the shift from a programming mindset to a high-productivity, model-driven development mindset. Such failure is often characterized by deficiencies in these and other areas:

  • Adjusting rigid SDLC requirements to accommodate an iterative process
  • Distinguishing skillsets required for coding from those required for model-driven development
  • Articulating benefits and trade-offs to the business

Or, to put it another way: what we're doing here is revolutionizing how custom business applications are produced, enhanced, and deployed. Treating BPM platforms as merely “accelerators” for the way things have been done to date is unlikely to produce the hoped-for benefits.
http://www.bplogix.com/images/icon-x-medium.png
-Scott
Comment
  1. John Morris
  2. 1 year ago
  3. #4137
+1 @Scott -- well stated on the BPM "cultural issue". This topic is so important, it would make a good question for BPM.com. To compare to accounting again, it would be as if we spent all day balancing books by hand (perhaps with abacuses), an exhausting activity which leaves no time or mental space for considering higher-order accounting and finance questions such as questions of cash flow, the effect of DPO and DSO on working capital, or whether higher interest rates will affect the decision to keep our currently under-utilized warehouse in Cincinnati etc. etc.
It's as if an entire world of management possibility is missing from management discourse and possibility. (Your mention of "BPM-as-accelerator" is especially evocative.)
For my part I see the BPM cultural question as a sales opportunity. Because sales is fundamentally about change. But there has to be the will to sell BPM, and the belief that BPM can make a real difference. (My language should not be interpreted as being quasi-religious -- BPM is just another technology for sure! It just has untapped potential.)
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Actually, a properly implemented BPM must become more and more agile because of:
- learning of new tools
- optimizing the whole BizDevOps for process-based solutions
- accumulating in your Corporate Unified Business Execution (CUBE) platform more and more your business services which are reused (also as code fragments) for the implementation of next solutions

Thanks,
AS
Comment
cannot concur more :-)
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
There is so much cynicism about any IT project and remember BPM created in IT era needs to have plan for implementation that "agile" adds to mockery.....? So if you want to maintain this status do nothing and have a good time on theoretical exercise. To deliver real support for users and accountability for managers start by explaining it is not an IT project and show how processes can be quickly created from direct input in their language. Once all on side agile structures not really needed...it happens intuitively.
Comment
Good point " . . . it [BPM] is not an IT project"

But, organizations absolutely need one of Business Analyst or IT to

a) build rule sets
b) link in data from local and remote 3rd party systems and apps.

I still get people telling me that you can practice BPM without rule sets or data links but it is close to driving on a two-lane highway wiith no center line and no guardrails on either side. Works fine until you have an accident.

I don't understand what you mean by "Once all on side agile structures not really needed" - if you mean once users are all on side, removing structure that gave you agile will result in removal of agile.

Most of agile comes from structure not intuitive activity"
As for rules all taken care of in platform via very flexible links (workflow to IT but incorporating conditions) and ability to manipulate data as required. In built capability to orchestrate created data as required e.g. people, the task, the data, audit trail, time etc this includes link to legacy data/ systems but of course requires cooperation of IT with APIs whatever. All this removes the traditional concept of "agile" remember no coders.....!
I can’t understand how “an environment” can take care of rules.

I suppose it depends on the types of rules and their complexity and, as discussed, whether ordinary users in functional units can be motivated to build these rule sets, even when they are super simple.

In psychiatry, we had, up to recently, algorithms for disorders (over 100 of these)

In respect of one disorder, Posttraumatic Stress Disorder, the diagnostic threshold went like this, in English:

Cluster A: needs 2 of 2 questions
Cluster B: needs 1 or more of 5 questions
Cluster C: needs 3 or more of 7 questions
Cluster D: needs 2 or more of 5 questions
Cluster E: needs 1 of 1 question
Cluster F: needs 1 of 1 question

Not altogether intuitive, we need a counting variable for each of A, B, C, D (j, k, l, m) plus one master counting variable (i)

Each question within each cluster has a pickable value of 0,1,2,3
0: no info; 1: absent or false; 2: sub-threshold; 3: threshold or true

There is a rule set at each cluster that reads (21 rules):

2 rules for Cluster A: If in Radio Group 3, is checked then j+1
5 rules for Cluster B: if in Radio Group 3, is checked then k+1
7 rules for Cluster C: if in Radio Group 3, is checked then l+1
5 rules for Cluster D: if in Radio Group 3, is checked then m+1
1 rule for Cluster E: if in Radio Group 3, is checked then i+1
1 rule for Cluster F: if in Radio Group 3, is checked then i+1

We then have a consolidating rule set (4 rules):

If j=2 then i=i+1
If k>0 then i=i+1
If l>2 then i=i+1
If m>1 then i+i+1

Lastly, one final rule that reads:

On Exit, i =6 then “Meets Diagnosis”

26 rules for what is a relatively simple algorithm
All of the PTSD rules are parked at one form and, in terms of workflow, post when a process step "Diagnosis" becomes current along the pathway it is part of.

Users only see what looks like an ordinary form where they just record data. The users, unless they go out of their way, don't see the workflow, they don't know what the prior steps are to "Diagnosis", all they know is that with a routing of "Clinician" wheneve a step with the name Diagnosis posts to their InTray, for any of 10,000 patients, they are expected to carry out a diagnosis.

When they have finished considering the questions, they click on Commit, the data flows to the Case History AND to a data exchanger for consolidation at several local and remote systems and apps.

Note that if our environment lacked a diagnostic module the users would still get to a step called "Diagnosis", fill in a form (no rules on/at this form), the data would go to the data exchanger, some remote app would do the diagnosis and return back the calculations. The processing might take a few seconds llonger.

Again, all of this takes place in the background, the user would not be aware of, or care, where the processing takes place.

My point in all of this is that you can have logically-connected steps along a workflow. with reasonable assurance that pre-conditions have been satisfied OR you can have ad hoc interventions at a Case (same steps, not logically connected) where it is imperative that there be pre-conditions (i..e. are we ready to engage processing at this step or are key data values missing?)

Bottom line, in ACM/BPM you pretty much need pre-conditions everywhere and, while you are at it, you might as well also have post conditions everywhere to check to see if any data that was input or calculations performed are reasonable.

Do we do all of this, everywhere ?

No, too much effort so the compromise is a few Process Control Point steps that sniff out the Case and make you loop back if things are not in a proper state.
Yes all sound logic as most rules are as reality is business is full of rules some simple some complex There should be no need to compromise and it is where benefits for automation can be significant not just efficiency but better outcomes with greater transparency. Rules and workflow or a more appropriate term collaboration should intrinsically linked into the DBP with no barriers in thinking in build and of course supporting continuous improvement.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
My interpretation of the process work agility is to increase cycle time of any process you might have. How can we increase cycle time in the process?

1) In the context of process management we push the decision making to those people who are on the field near to the customer. Get rid of all kind of waste such as unnecessary actions, testing, reporting, information, tools, equipment, it-systems, material, meetings, performance metrics.... but be sure that what is needed is there right on time available to those people who help the customer to create value.....The BPM (and business) gets less agile, if we keep the "operative" decision power at the top of the organization.

2) In the context of process improvement we push experimentation when ever it is possible. The faster we can experiment the faster we learn what works or fails. In the experimentation don't ask permission, ask for forgiveness. The challenge here is that you might easily loose the direction and jump into swamp of "Random Kaizen".....here the key element is to have good process architecture guiding the experimentation.... The BPM (and business improvement, growth and profit) gets less agile not putting time enough to develop value driven process architecture.

br. Kai
Comment
@Kai . . .

For sure, "The BPM (and business) gets less agile, if we keep the "operative" decision power at the top of the organization."

I got locked up once in a vendor-customer contracting exercise where a proposed initiative had to be approved by 5 levels of "management".

The top-level executive's main question was "Who are xyz?"

Xyz, the handlers explained, was the subsidiary making the funding request. The exec didn't know that xyz was part of the empire.

When organizations have rational ROI processes, funds are released, objectives at the project (i.e. case) - level get set, periodic progress toward attaining objectives (by Case Managers) gets carried out, variations receive evasive and/or corrective actions, senior management gets what they signed off on.

Senior management has enough to do keeping a focus on increasing competitive advantage - they need to stick to their knitting.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
  • Page :
  • 1


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