BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 02 August 2018
  5.  Subscribe via email
Would would you say are the BPM skills that are most needed, and often times most lacking, in companies today?
Accepted Answer Pending Moderation
Ability to architect an enterprise as a system of explicit, formal, machine-readable and machine-executable processes, of course. See ref [1].

Thanks,
AS
References
  1. https://improving-bpm-systems.blogspot.com/2014/03/enterprise-as-system-of-processes.html
Comment
that's not an ability, it's a superpower!
Everything is relative - A system for somebody is a component for somebody else.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
If we are talking about BPM in the context of a larger Digital Operations transformation, I think the 2 biggest blockers are -

  1. The ability to recast their current work in a process framework. (Process Centric Approach)
  2. The requisite skills and decision capability around the job reengineering required as digital transformation makes its way through the organization
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
In my opinion, hard skills (like process Modeling using BPMN; Automation using BPM Suites; Apps Integration using WebServices or IfTTT tools; etc) are majorly available in big companies.

On the other hand, soft skills are usually the scarce resource. And they are as important as hard skills. Just two examples (probably there are many more):


  • Ability to make the internal sale; convincing people to get on board of digital transformation or process automation projects.
  • Proper change management; avoiding or mitigating the disruptive change when changing the way people work.


Best regards,
CEO at Flokzu Cloud BPM Suite
Comment
  1. John Morris
  2. 4 months ago
  3. #5575
+1 Juan "ability to make the internal sale". This challenge is greater now with the advent of agile and de facto zero-based budgeting. IT used to be administered inside the corporation in a way that could only be described "Soviet-style". In that top-down environment decisions were more a function of politics and organizational behaviour than anything requiring sales.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
This is hard and very important question. All success is based on competences, skills and knowledge. It also depends how narrowly or broadly we define BPM. IT related BPM includes a lot of technical skills such designing the process by using notation which can easily transformed to code to develop application, automation, digitalization, AI....

Management related BPM includes a lot of business skills such as strategy, systems theory, Improvement and innovation methods (Six Sigma, Lean...), understanding knowledge creation and learning, change management and facilitation....

br. Kai
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
As BPM is becoming increasingly intuitive, from a technical perspective, skills like being knowledgeable on an architectural level, being versed in a BPM methodology and fluent in notations like DMN, UML and BPMN are gaining importance as variables for success.
Additional areas were we have witnessed a scarcity of skills, are in the fields of process BI and data driven process simulations (that provide statistical depths and insights on dynamic processes and process-to-be-models).
At times, a lacking "BPM-seniority" has, still to this date, an inhibiting factor on the required negotiating skills that project stakeholders should hold in order assure the different BPM deliverables to be successful in terms of the triple project restrictions (time/budget/scope...).
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
The core BPM skills are

1) the ability to facilitate process mapping
2) the ability to put in place a "proper" run-time workflow/workload/case environment.


MAPPING

Functional departments frequently lack even one single person who can "think process" - they know their processes backwards and forwards but when it comes to putting down circles on a graphic canvas and connecting these with directional arrows (never mind branching decision boxes and the much more complicated auto-exec branching decision boxes with rules that "fire" automatically), they just can't/won't do it.

The inability to "think process" is totally perplexing to the consultant/facilitator because one hour on site or at-a-distance hosting of real -time mapping of a process usually results in identification of one stakeholder being willing/able to do much of the basics on their own.

[Skip the rest of the response if you expect/require your stakeholder to learn or use a "notation" or "language" - no point continuing]

Typically, the consultant leaves with the false notion that a new maturity stage has been attained.

Go away, though, then come back in 1 week/2 weeks and the likely scenario is no additional mapping will have been done.

The easy remedy is to facilitate another mapping session where the stakeholder does 99 pct of the work demonstrating clearly they could have continued the mapping on their own.

Ongoing "handholding" seems to be only solution.

Now, following a brief off-line intermission to build data collection forms and encode these to process steps, add rules at the forms, add rules at auto-branching decision boxes, set up skill categories and encode these to process steps, and the organization is ready to compile the map.

[Again, skip the rest of the Response if compiling the process map involves more than a couple of mouse clicks]

RUN-TIME CASE MANAGEMENT

Now, the organization (having picked a proper run-time environment) is ready to start managing Cases using ACM/BPM.

ACM gives the organization the flexibility - do what you like, when - rules will "keep things on the rails".

BPM gives the organization orchestration for processes (via BPM template instances).

Again, if the run time environment is "proper", there is no problem onboarding users and no problem keeping them on board (all this requires is a UI where using the UI is less effort than not using the UI).

"Must haves" for the RT environment are :

a) an inventory of process templates
b) RALB (resource allocation, leveling, balancing) or just plain "3-tier task scheduling"
c) something like FOMM for non-subjective assessment of progress toward meeting Case goals/objectives - (remember, most work advances along an "S" curve, so in the absence of a method, unless you know that a Case is an early/late riser, you won't know how things are progressing).
d) a formal Case History (if you don't know where you came from, you won't know how to get to where you want to get)

Of course, the environment needs to be able to seamlessly export/import data to/from the outside world (otherwise your environment becomes an island).

Is that all there is?

'Fraid so . . .

Peggy Lee figured all of this out in 1969.

Take a break and listen to her recording at my 2104 blog post.

https://wp.me/pzzpB-tR
References
  1. https://kwkeirsted.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
What BPM skills? I want to answer a slightly broader question: "What business process enabling skills are most needed in today's enterprise"?

And let's define "need" as derived from either of two different labour/technology markets: (1) a well functioning labour market where supply and demand reflect known costs and benefits and (2) a poorly functioning market where, for whatever reason, costs and benefits associated with a given technology and its uses are not well known.

EXAMPLE FROM NO. 1 -- The costs and benefits of analytics are reasonably well-known, and the market for analytics technologies and labour is taking off (along with associated markets such as AI). Both demand and supply are reasonably rational. Sure, there is hype.

EXAMPLE FROM NO. 2 -- There are some marvelous answers above (if not entirely unexpected). Dr. Samarin advocates for architecture. The application of greater enterprise architectural vision and discipline would enable wonderful benefits. I fear however that architecture is an example of a poorly functioning market. So there is "theoretical need" articulated by a vanguard of architectural champions. But architecture has not yet begun technology adoption take-off. (This is not to say that many organizations have not had success with architecture, and are not committed to architectural programmes. On the other hand I think it's fair to say that enterprise architecture is not, as a general rule, "at the table" in the executive suite.)

Given the nexus of new technologies (e.g. IoT-related) and ever-improving BPM software engine technology (impacting on the round-trip problem), I believe there ARE process enablement skills that should be on executive shopping lists.

1. Relational database skills..
2. Business analysis skills.


Along with "everything else" listed above.

The two skills I've listed above concern systematic attention to business semantics, systematically organized. We see cultural prejudice against relational technology for so many reasons. Simplistically it comes down to "performance" versus "business semantics". Modeling a domain is not easy; it requires persistent accumulation of knowledge, a challenge in today's gig economy. AI-based data mining will not deliver the business semantics that enterprise requires. The price in business inflexibility resulting from performance shortcuts is much, much higher than any business executive has ever realized. What, we can't bring this new service to our customer base in less than six months? And of course process sits on top of data. Business analysts are the cadres that should be or could be shepherding the whole thing.
Comment
RE "Business analysts are the cadres that should be or could be shepherding the whole thing." - knowing that "Modeling a domain is not easy", such works must be carried by specialists in building ontologies and creating a system of ontologies. For example, an ontology of any domain must be aligned with "more" fundamental ontologies such as system-thinking, activities (processes), etc. Ontology works is not in “business analysis” agenda although it is very popular in Canada. Also, analyst can’t propose any solutions because this is a responsibility of architects. And “forgetting” architects is not good for digital transformation which is a creative activity ( see also https://go.forrester.com/blogs/the-sorry-state-of-digital-transformation-in-2018/ ).

So, the relation between architect and analyst is similar to doctor and nurse.
  1. John Morris
  2. 4 months ago
  3. #5600
Nice analogy comparing doctor/nurse and architect/analyst. And I agree re: the importance of architecture (and ontology) for enterprise success. I was answering though a more limited question specific to BPM.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
@John. . .

Interesting mention of "Relational db technology skills" and "business analysis skills".

We went to post-relational in 1985 (we were distributors for several years for mdbs inc of Lafayette, IN who developed "KnowledgeMan", one of the first user-friendly post-relational dbms), so in all of the Case Management apps we push out today you won't find Form Design facilities that make any reference to "database fields" - all of this is automated.

As for Kbase technology skills, core to "business analysis skills", the environment of choice for us, hands down, has been multi-root hierarchical databases which most folks reckon were "current technology" in the 1960's (e.g. IBM IMS).

The thing is how would you go about building the 6, 000 document Kbase featured in the screenshot below where we showcase a consolidation of (at the time) all orbiting satellites, with characteristics, plus launch sites and launch vehicles?

Satellite Inventory

Other examples abound

e.g. worldwide kbase on Autism - evidence-based protocols/clinical trials, grants, research centers, researchers, published articles, advocacy groups (country by country), individual healthcare facility inventory of best practices;

Dept of Justice law enforcement library comprising more than 200,000 documents).

US Dept of State Country Profiles (all countries)

What these four Kbases have in common (satellites, medical [one small specialty out of 200+), and DOJ/State Dept libraries is that all of their respective "documents" are easily accessible from a "Russian Doll" layout at ONE computer screen.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. John Morris
  2. 4 months ago
  3. #5580
+1 @Walter total mastery of the business semantics of a very specific business domain.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Common sense, business experience and an uncanny curiosity for the "how".
CEO, Co-founder, Profluo
Comment
  1. John Morris
  2. 4 months ago
  3. #5578
"Common sense" = the "tacit" . . . +1
"Business experience" = "domain knowledge" . . . +1
"How" = opening up the "black box" of work . . . +1
---------------------------------
Overall +3

OK, "common sense" versus "experience", not 100% sure of my mappings . . . :)
@John.. the problem with common sense is that it is not common.
  1. John Morris
  2. 4 months ago
  3. #5583
LOL @Walter "common sense". Can we say that "common sense" might even be becoming "less common"? For many reasons? The more ideological is social discourse, the less room there is for so-called common sense. It's "crowded out".
What is unique for BPM from this list?
  1. David Chassels
  2. 4 months ago
  3. #5585
It is vital that business understands how actual delivery is implemented; sadly industry analysts just do not dig deep to understand and articulate in business language. Big vendors still rule but change is coming....mapping without such understanding makes no sense....which of course suits old IT!!!!
  1. John Morris
  2. 4 months ago
  3. #5586
Re: "what is unique about BPM from this list", if BPM is the THE technology of the work of business, then the questions of (1) tacit work knowledge, (2) explicit domain work knowledge and (3) the question of actually taking responsibility for what's inside the black box of work -- all these skill descriptors are tightly coupled with the technology domain of business process management.
These three "abilities" are present in scientific research, systems approach, architecture, etc. What is unique for BPM?
@Alexander

Looking back to CPM, what is unique for BPM is the ability to accommodate branching decision boxes and loopbacks.

However, it may be these features were not invented by BPM practitioners, rather by CPM/PERT practitioners who tried to move to GERT. Seems to me GERT never achieved liftoff.

Not sure how/whether there actually was a transition from GERT to BPM. It's possible that the GERT enhancements to CPM/PERT were independently re-invented by BPMers but GERT had these features for sure by the mid/late 1960's - I never worked with GERT but Google searches attribute the invention of GERT to Dr. Alan B. Pritsker of Purdue University and WW Happ.

See the fascinating writeup at PMI

https://www.pmi.org/learning/library/gert-graphical-evaluation-review-technique-5716

a summary of which I have posted here . . .

"
Virginia Polytechnic Institute and State University
Application of network analysis to project planning and control has been extensive since the late 1950’s [12], PERT and CPM, the best known network modeling techniques, have been applied to a diverse number of projects for planning and control purposes. However, PERT and CPM do have limited capabilities which prohibit modeling of many complex project network forms. A more flexible generalized network tool which has received increased attention recently is GERT (Graphical Evaluation and Review Technique) [5], GERT includes features such as probabilistic branching (stochastic models), network looping (feedback loops), multiple sink nodes (multiple outcomes), and multiple node realization (repeat events) which are unavailable in PERT/CPM. These GERT features provide the user with the capability to model and analyze projects and systems of a very general form. Since many real-world system problems do involve probabilistic occurrences, false-starts, activity repetition, and multiple outcomes, GERT is an ideal tool for the modeling and analysis.
The purpose of this paper is to describe the GERT network modeling technique and simulation package, and demonstrate its capabilities via an example of R&D project planning. Included in this overview of GERT will be a discussion of the use of GERT output for management planning and control including sensitivity analysis and implementation.
"

My view on the uniqueness of BPM, to answer your question . . .

BPM is all about doing the right things, the right way, using the right resources, at the right time, all with the objective of getting the "right" outcome.

Since no "best practice" is best all of the time, BPM orchestration should be a core, but background service, in a run-time Adaptive Case Management environment that provides workload management (across Cases) and includes some non-subjective means of assessing progress toward pre-defined goals/objectives at each Case.

Success in business requires mastering A,B,C,D,E in reverse I.e. ECM or Enterprise Content Management, DCM or Document Content Management, CPM or Critical Path Method (for once through initiatives), then BPM and ACM

See a new blog post (2018-07-05)

"Closing the gap between strategy and operations – is as easy as A, B, C, D, E"

https://wp.me/pzzpB-Sm
  1. John Morris
  2. 4 months ago
  3. #5601
Re: @Alexander and "These three 'abilities' are present in scientific research, systems approach, architecture, etc. What is unique for BPM?" -- had to recall some logic. You are correct that the three skills we are discussing NOT unique to BPM (and you've provided several examples from other domains). But all the domains in question (and we could add the domain of "picking carrots") ARE domains of work. And all work can be characterized according to tacit knowledge, explicit knowledge and intentionality. BPM automation technology can be used more successfully when @Bogdan's three suggestions are part of the programme. This does not preclude the possibility that ALL work benefits from the same approach, whether automated or not.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
In today's enterprise Alexander sums up highlighting need for architect knowledge in recognition of the existing complexity in both legacy and current notation components etc. However tomorrow's skills to deliver on BPM is going to be as John summed up Business Analysts will be the drivers. This will be achieved using Digital Business Platforms DBP where the pre built architecture allows very quick delivery of all requirements direct from user input with in built RPA to manage legacy systems and data. This will be delivered without need to code the core business logic as just needs to configure custom requirements and where coders needed for complex algorithms the BA manages and controls exact need.

Now we have that capability to build via a graphical model will even reduce complexity for BA skills and put emphasis on good communication skills with Business users as there will no longer be requirements to interpret for coding. Indeed a detailed spec of the required application no longer required with a brief overview engaging end users ready to fill in the detail with direct input into build where change is readily supported in build and for the future changes. This future view will put BPM in prominent position and readily understood by business executives to allow for their support with confidence for successful delivery.
Comment
" tomorrow's skills to deliver on BPM is going to be" - forgetting architects is not good for digital transformation which is a creative activity ( see also https://go.forrester.com/blogs/the-sorry-state-of-digital-transformation-in-2018/ ).
  1. David Chassels
  2. 4 months ago
  3. #5594
Digital in the UI has 2 key elements. First the delivery and collection of data in a format that intuitively supports the user and may include a degree of automation such as entering data only once. This is readily handled by the business analyst. The second is design and that may well require marketing input with a good web designer. The back office is or should be all managed automatically based upon the requirements. Think of it as SOA in box all architecture pre built so whilst having access to an architect may help with legacy it isn't a driving need. However quite likely a business focused architect could quickly learn skills to build end to end application.
I already heard something similar a couple years ago - digital is about having good UI, APIs are already available and we don't need architects. Unfortunately for companies (or fortunately for architects) the current sorry state of digital transformation doesn't support this approach (sometimes it is called "Potemkin village").
  1. David Chassels
  2. 4 months ago
  3. #5596
Well our pioneering started over 15 years ago and it really does work but sadly industry analysts ( including Forrester) just did not want know as it was so different from established ways. However it will happen.......!
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Some really great points! in this discussion.
Agree with John's point - basics of relational database and business analysis are no-compromise
In addition, the BPM skills that will help in today's enterprise are

  • understanding business, process & architecture in its purity, than viewing it through the lens of a specific product as "tool jockeys" with drag-&-drop features/palettes. The pace and scale at which we are moving in the industry, and adopting new advancements - thinking just within the box solves a part of the puzzle.
  • understanding the problem statement first, than directly jumping to the IT solution approach
  • the art of story-telling (complementing the customer journeys and defining e2e day in a life of a user)
Comment
  1. John Morris
  2. 4 months ago
  3. #5590
+1 @Pritiman re: "#story-telling" (see also #narrative). We are only beginning to scratch the surface of this topic. The combo of BPM process technology and story-telling or narrative (or journey, which has been explored in this venue a little) could be a great question - or three ...
For me, "story-telling" has always been important for onboarding (any domain) - how else do you keep an audience from falling asleep?

I would include in story-telling a) bad jokes b) consultant experiences c) customer experiences d) history/background of methods being proposed etc. etc.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Cross-disciplinary architecture is among crucial and often neglected factors of BPM initiatives. Compatible multi-domain modeling is rarely available or seen as priority in BPM projects in favor of local automation tasks. However, exactly transparent and scaleable process collaboration across an organization determines long term success of the digital transformation.

The ability to capture a consistent view of an organization through precise mapping of relevant notations is a cornerstone of all subsequent BPM implementation. The goal of BPM is not a replacement of existing processes and technologies but their skilled alignment, which should ensure most effective and transparent interaction of the existing corporate infrastructure at minimum cost and modification.

Unfortunately, too many BPM initiatives go as vendor driven disruptions, revolutions, breaks through and other scenarios similarly dubious in terms of attractiveness and suitability for a continuous corporate growth. BPM is merely about bringing a harmony into established business structures, which is a skill too rarely found or distinguished as a demand.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
To my opinion the two most differentiating skills/capabilities in BPM are (or should be):

1. The ability to explain BPM (the philosophy, not the tool set) in business language. I really like how Boris Zinchenko explained it with the word "harmony". If you start from the top with the strategy, it all needs to be aligned until you reach the SOP or work instructions at the proverbial bottom of the organization. If you are able to explain that in normal business language to the all relevant levels in the organization, you might have a chance to convince the decision takers and secure their commitment throughout the implementation.

2. Think cross-functional and in E2E
Many process modeling efforts I encounter (and process modeling is one of the fundamental cornerstones of BPM) are too often only mono-functionally oriented and certainly not end to end. You cannot expect to achieve great results if you only stay in your own vertical, functional silo. The world doesn't work like that.
BPM is all about mindset first and toolset later....much later
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
Just add to above input. Business is simple when you analyse down to step by step what is required. Mapping these steps has been around for many decades long before BPM! Yet this forms the basis of BPM thinking. Yes some steps/ tasks may involve complexity such as manipulating data or even use of machines but they fit into that step model. These steps can have options on how and where next...all very simple and logical...and easy to learn how to "map". However BPM needs that vital software support and this is where the current failings and complexity sits.

There is little merit in embarking upon a BPM project unless you understand just how it is to be delivered as a working application. The most important "task" is the UI which should directly be supported by back office use and supply of data. Supplying the end to end process needs is readily supported by multiple graphical maps to be joined up; for example a case management could have over 50 maps. Where the graphical map is the build environment this becomes effectively the "new code" but built by business.

In summary we must not over analyse what in reality is a actually a simple exercise. The big issue is business have had to live with hugely complex and expensive inflexible systems and presenting such simplicity is not going to be believed...or welcome by big vendors and "old IT"...!
Comment
Agree.... "The most important "task" is the UI which should directly be supported by back office use and supply of data"

Except that the pre-requisite to putting any UIs in place is to have a suitable enterprise architecture - figuring out what that should be is difficult in an organization with a mix of legacy application systems and corporate culture.
  1. David Chassels
  2. 4 months ago
  3. #5603
This is where a good platform removes such complexity as it should have in built architecture ready to support all tasks but in particular the UI. Think of a a green field of such capability around the brown field of legacy and yes corporate culture changes to business driven needs not IT....
  1. more than a month ago
  2. BPM Discussions
  3. # 14
  • Page :
  • 1


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