It's going to be interesting to see what Apple does with it, my guess is they will be enhancing iOS with its capabilities.
Nothing to do with BPM, except the name.
- Keith Swenson
- 3 months ago
No, agree with Bogdan; except from a BPM-ish name, it doesn't have much to do with "Managing your organization by process"
btw, stupid term 'workflow'. I haven't seen many processes where the work flows. Works usually happens at static places and cases flow. From work to work.
That's why I installed the "Caseflow" app on my Nokia 3310, lately.
- Positive side: put the Workflow term in everybody's mouth. The world is talking about it once again
- Negative side: misunderstanding of the term, given it is not used in the business process context that we would like.
The second is pretty important to me. In the IFTT case, the acronym is very different, and the target market narrower, so I think the impact was smaller. Now, I think every BPM and Workflow (for business) vendor, should make some efforts to make their value proposition clear (maybe leveraging on the workflow trend).
Best regards !
Think about the effect Web 2.0 and social sites have had on the UI requirements for BPM platforms. In the past five to ten years, it has become unacceptable for a BPM platform not to have an outstanding UI solution. This was primarily driven by the great improvements in consumer facing websites. People just grew to expect this from their interactions with applications and the web, regardless of whether the site was a corporate one or not. I don't know if this is the case, but I am just wondering if these simple workflow tools could start to drive expectations for the way corporate processes are performed.
I imagine I will get hung out to dry for this perception, but that is what Forums are for
Many silo dwellers don't get it that work needs to be coordinated across silos.
Many managers of silo dwellers feel that work efficiency is not their job (i.e. we are very busy taking courses so we can update our CVs)
There are parallel lessons to be learned from the addition of cameras to smart phones . . . .
"Why do we need to hire a videographer with a large sensor camera/tripod/light bank/field audio recording equipment to videotape our wedding at $1,200 per day? Your nephew, Jeremy, has a smartphone and he's 'very good' at videotaping."
then, when the couple sees the footage . . . .
"Hey, the video images taken by Jeremy are all over the place! Parts of the recording are under exposed/other parts overexposed. The bridesmaids dresses were green, not blue. You and I are in focus but the cake is not. Almost every scene is jittery.'
"I don't understand why you are complaining - we saved $1,100, besides, Jeremy's footage Is no worse than the selfies we take every day with our smartphones."
"Well, I don't want Jeremy to do the company picnic, call the $1,200 a day guy".
"Sorry, the recording says the number has been disconnected"
My take is the demise of pro-video started with a change in consumer attitude as a result of new technology. So, we may get a repeat of this across BPM as services like Apple "workflow" are promoted and rise up. Or, it may be business-as-usual, with increased resistance, from the subset of corporate staff who remain convinced that planning / operations management can be done on the back of an envelope.
It is still valid that the current BPM practices are non sustainable - BPM is often the reinventing the wheel in each enterprise, in each process and in each BPM tool. I think that the root-cause is the vendor-centric nature of the current BPM.
The majority of BPM vendors consider their products as “the centre of the enterprise universe”, but as the result, their super-powerful products are deployed for marginal applications.
Recently I had a chat with the chief architect of a big bank from the Netherlands. He said that they use a BPM-suite tool from a very respectable vendor, but only top-level consultants can develop applications in this tool because any attempts of lower-level specialists to repeat the work of those top-level consultants generate a lot of mess. Thus that bank preferred to go to agile.
It seems that the current way to implement of BPM by vendors is fundamentally broken. I know that a lot of architecture services are necessary to incorporate BPM-suite tools into enterprises but professional services are locked in the BPM-suite tools.
Hope that low-level BPM-like tools, RPA, etc. creates a critical-mass effect in the BPM industry.
In terms of the performance and management of work, all you need to host in any Case environment is work that gets assigned out of a common resource pool.
What you need to host at any Case is different i.e. work that advances the state of a set of goals/objectives.
Say you order a private airplane - from your perspective, this is ONE deliverable but the manufacturer is free to sub out the wings, fuselage, engines. They may have three divisions at one location, they may have three separate divisions, they may have none with all work being done by individual different contract suppliers.
In this example, you could have 5 Cases running (you the customer, the manufacturer, the three subs) each with its own resource pool
For tracking, each entity will have in-transactions and out-transactions i.e the wing supplier has a Case that ends with "ship", in their Case History, the manufacturer will have a "receive" transaction in their Case History. Blockchain, anyone?
Thank goodness we have generic data exchange software.
- Workflow automation
- Rapid application development
Workflow automation recognizes the commodity nature of many simply personal and business tasks. IFTTT (which I have found to be entirely useless; is anybody doing anything interesting with that service?) and its friends have correctly identified a gap that was only kinda-sorta addressed by BPM. All of the mobile apps and web apps and social media sites on which we rely every day are isolated isles in an archipelago, just begging for a ferry to connect one to the next. Such a service is essential on the surface, of course, albeit more or less invisible when you're overflying the island chain at 35,000 feet.
Rapid application development does include, as a vital component, the integration of multiple solutions and data sources. But that integration serves a larger purpose, which is to drive enterprise-scale digital business applications (sorry, my SEO overlords demand that I say "digital" at least twice per paragraph). Those strategic applications form the stratospheric cloud cover for lower-level apps like IFTTT. An app you download from the iOS or Android store is not likely to reach that altitude.
- Brian French
- 3 months ago
After reading the news, I do agree with previous posts that Workflow is not necessarily within the same space as typical, business BPMS platforms and solutions. It seems to be focused on personal automation solutions within the iOS confines, only.
That's not say that it doesn't indirectly influence "our realm" at some level. Conceptually, process automation may become more mainstream, understandable and accessible. There maybe also a resulting push that makes traditional BPM software keep trending even more progressively into the space of "commodities". That in turn will force vendors and integrators such as ourselves (NSI) to become more innovative and vertical oriented (enhanced industry specific solutions vs. general BPM products).
There is, however, a large part of the world that uses "workflow" as a name of a technique for passing data from application to application, typically in a single user environment. For example, a photographer will take raw photos, pass to one program for conversion to JPG, and another program to some other form of enhancement, such as color correction. "Work" here means a digital artifact that is being produced. This is a "flow of "work" from application to application.
This is not BPM.
We probably need to help clarify the two meanings of workflow. Apple is purchasing "Single User Workflow"
> given any workflow process fragment of minimum viable complexity (task, step, branch)
> if workflow process fragment (n) exists
> if workflow process fragment (n+1) exists
> workflow process of arbitrary complexity exists
> we call it a new name: business process
- Boris Zinchenko
- 3 months ago
Only BPM pundits declare efficiency and strongly coordinated flows are a thing of the past and the future lies in white-collar, right-brained type of unstructured work.
It is almost an exclusive feature of the BPM industry - to decry automation while being in the very middle of it, technologically.
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.
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, 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.
However, on a wider scale, it has clear and wide going implications to BPM in general. It clearly illustrates that BPM techniques and approaches quickly turn from a specialized narrow field of corporate management into a mainstream technology. BPM becomes an indispensable part of both corporate and end user consumer segments, so that every large player in IT field considers mandatory owning or acquiring this type of service.
One may assume that this acquisition is just one of many upcoming events and marks a new wave of BPM growth moving it into primary application stack, along with standard office tools found on every workplace or private device. No doubt, it will trigger many new startups and development in BPM field.
- think back to what Apple did to the value of mobile apps with the iTunes store when it devaluated them all to 99c It dropped the perceived value and it has taken years to claw back to $4.99
- whilst this forum has been arguing ACM vs BPM vs workflow over the last 3 years, ManyWho.com built an elegant, low-code, workflow solution targeting point solutions. With a small dev team, focused message (rapid apps now) and limited investment they built a growing and profitable business. Dell Boomi bought it last week. I have no idea of the price, but knowing the founders it was a very healthy exit.
- Salesforce continues to throw huge resources to develop their automation solutions. They are developing point and click tools to build very sophisticated workflow solutions. And before you say "But that is just Sales-CRM" those solutions can be used on the App Cloud to build ANYTHING. The App cloud is an entire custom point&click dev environment.
- Smartsheet you may not have heard of, or like me discounted it. It is "Managing and Automating Collaborative Work" the love child of a spreadsheet, Trello and a BPM engine. It may not be functionally rich, but they have revenues of over $100m and Fortune500 companies are adopting it enterprise wide.
Apple Workflow, ManyWho, Salesforce Process Builder and Smartsheet may not be comprehensive, enterprise-wide solutions, but increasingly the business user does not want, need or is prepared to pay for anything more,
(BTW a cynic is what an optimist calls a realist)
Methodology - how to use business processes to run business better - will certainly survive and will be more appreciated because more people will be able to use it for wider range of problems and the will be more autonomous
Tools - also known as BPM-suites (which, often, have, architecture "programmable monolith") - will be the main loser because the traditional BPM vendors must change application architecture of their products to compete with light-weight tools
Practice - portfolio of the business processes of an enterprise, and the practices and tools for governing the design, execution and evolution of this portfolio - will be the main winner of moving from "vendor-centric" BPM to "customer-centric" BPM. As tools become more granular and more interoperable, advanced coordination techniques like RALB and FOMM can be easy to plug in.
- Dr Alexander Samarin
- 2 months ago
Except that if vendors/customers take the time to prepare an ROI, some initiatives end up generating positive cash flow, so does this not result in the business getting "more" at no cost?
ref: increasingly the business user does not want, need or is prepared to pay for anything more"
Methodology - steps linked by directional arrows (post-its, whiteboard, e-mapping)
Tools - form painter, rule sets, e-map compiler
practice/architecture - run time Case management comprising auto-posting of steps, accommodation of ad hoc steps, RALB (resource alloc, leveling, balancing), FOMM (figure of merit matrices).
I suspect different participants here have different ideas of "what is behind the abbreviation of BPM" so examples are needed before they can./ should declare any of the three categories as RIP.
Notice I put RALB and FOMM under practice/architecture - they are tools but not, it seems, generally recognized as BPM tools.
A search for RALB at Google yields disappointing results - "Ras-related protein Ral-B (RalB) is a protein that in humans is encoded by the RALB gene on chromosome 2" so each time I reference RALB I feel obligated to spell it out.
A search for FOMM is equally disappointing - I even phoned the Rand Corp to get a copy of their original paper that I cited in an MSc thesis, they have no record. I am tempted to drive 150 miles to my uni to get a copy of what I wrote - the uni has my paper on microfiche but no resources apparently to make/send me a paper copy.
I wish someone would come forward to shoot down my notion that a Case Manager cannot manage Cases without RALB and FOMM.
Equally perplexing is how corporations can fund initiatives in the absence of hierarchical free-form-search Kbases w/ SWOT.
But as for BPM RIP, I'm tempted to paraphrase a misquote of American humorist Mark Twain's comment that "reports of my death are greatly exaggerated". (Then again, Mark Twain is dead.)
Perhaps your quip about realism is a clue to what might happen. Either BPM technology has content, or it doesn't. Either the concerns of the traditional BPM community are real, or they aren't.
I hold the view that business reality is rich, that business process is centrally important, that math-based BPM technology is challenging -- and that BPM business analysis is non-trivial. If one holds these views, then the amazing and laudable successes of the companies you mention are inherently limited.
The simple BPM or workflow technologies offered cannot support the increasing demands of globalized, ever-more-complex business models. (Which isn't to say that these products and technologies can't do interesting things!)
Of course we are now in the territory of Clayton Christensen and the Innovator's Dilemma -- where lots of high-end products met their doom while holding on to every smaller pieces of a pie, and while having their lunch eaten by exactly the type of low-end competitors you have mentioned here.
So there are two processes going on -- BPM technology-in-itself and BPM technology-adoption-processes. Low-end workflow and BPM products will probably gain lots of traction -- and more power to them. And they'll be enormously successful -- until they aren't. (Just like spreadsheets. Spreadsheets are ubiquitous. But ask any Treasury department about closing the books every quarter based on spreadsheets.) And over time, according to the Christensen model, today's low-end winners will grow into tomorrow's BPM behemoths.
Considering that there are three different concepts behind the abbreviation BPM (methodology, tools and practice/architecture) then which of them is RIP? and what's about others?
- Dr Alexander Samarin
- 3 months ago
- Page :
However, you are not allowed to reply to this post.
Join the Discussion
Webinar:Your Digital Disruption Survival Plan
Thursday, July 13th @ 1:00pm Pacific/4:00pm Eastern
In this fast-paced and informative roundtable discussion, three leading experts on business process management will explore the right methods and capabilities that make difference between success and failure with enterprise process management initiatives