1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 21 February 2017
  5.  Subscribe via email
With smaller staffs and smaller budgets, what do you think smaller companies need to do differently to take full advantage of BPM?
Accepted Answer Pending Moderation
In last discussion on small companies, I was made a fool off because I believe small companies are much better in BPM (make their processes do what they promise to their customers) than most large companies (who think they can implement or buy BPM on top of their daily business).

So, I think I won't comment this time.
Sharing my adventures in Process World via Procesje.nl
Hi, Emiel. The last laugh will probably be yours.

I agree small companies can be much better in BPM. Whether they are or not depends on how BPM is explained to them.

If the pitch to them is right, they can implement quickly and easily whereas the larger companies have to have meetings to decide whether to have a meeting, then another to decide the agenda, another to decide who to invite, followed by several meetings to pick a date/time.

  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Emiel, I wouldn't make a fool of you because I think I understand, and agree with, your essential point. :-) I would say, though, that the issue is more about company culture than company size, since so much of BPM success involves people's willingness to use adopt the mindset. In this way, I think small companies and individual departments of large companies have much in common. And to both I say, in answer to the original question, be realistic in your expectations and be consistent in your commitment to the cause.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
I really depends on what you consider to be BPM. The classical enterprise style BPM will just not work for small businesses and isn't really necessary or at least shouldn't be necessary. For SMBs who want to to streamline operations simple and easy wins are the ticket since you'll never find the person who is ready to source, implement, and manage a complex BPM methodology
  1. https://connecteam.com
Some of the smallest "job shop operations" routinely embrace BPM - most do not know they are practicing BPM.

These organizations do not feel a need to learn languages/notations so they never get to "complex BPM methodology".

They do achieve improved staff/equipment efficiency, improved throughput, decreased errors, they are compliant with internal and external rules and regulations and they get better outcomes. All without much fanfare.

Their entire focus is on doing the right things, the right way, at the right time, using the right resources with a strong focus on meeting customer delivery needs.
  1. Ian Gotts
  2. 3 years ago
  3. #3375
Here's a thought. Don't "manage a complex BPM methodology" Keep it simple.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
I like @Walter's comment that @Emiel will probably have the last laugh. In the previous discussion ( search Google for "BPM.com SMB BPM" ) I commented that SMB "needs" BPM, but that the only viable way for SMB to afford and do BPM is via boutique BPM consultancies.

Also in that discussion in May, 2016, @Ian insightfully commented that SMB typically can't and won't spend on something like BPM ( and I add "maybe even via boutique consultants" ) -- although I see that problem as a sales and governance hurdle, rather than an eternal rule. Compare for example the fact that all SMBs consume accounting services.

Interestingly, the idea of boutique BPM consultancies is now showing up in analyst commentary (as well as in real life). As I say in one of my tag lines, "there's a bright future for channels, because that's where the domain knowledge is".
@John, what a wonderful observation about "boutique" channels! How I missed it earlier?! I bet, it is an essence of modern promotions.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Two points before this approach is addressed by SMBs First small companies with less than say 20 people stick with a good accounting system, database spreadsheet etc. If expansion occurs and owners feel they are losing control and business needs better real time feed back then maybe a step change to adoption of new software is needed. Whatever they should NEVER buy an ERP system...! If that is a thought then BPM will have a place as more effective alternative. Second depends upon what are the objectives and if scaling is likely then BPM could have a place early on which will support rapid expansion.

It is likely business will take interest in what they are buying and should want to see how the supporting will actually support people and their processes. They should ask for a trial using their processes and involve users and if it works and all are happy to move forward then the biggest hurdle satisfied with users on board. The project will likely have C level interest and any issues could be resolved quickly to point of abandon the project if early results fail to deliver. This is where business will feel relaxed if the software supports change as will the users. Keep IT out of this loop other than making sure hardware and communications are ready. This will be easier to achieve for SMBs?

As discussed in this forum having a Platform which addresses all requirements will remove that existing complex mix of software that is needed to support BPM and is a current challenge holding back BPM? No/low code should be on agenda ...again without IT barriers? With good leadership much could be achieved by adopting BPM with knowledge of "how".
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Keep it simple. Keep it small. Keep it sane. Iterate frequently.
CEO, Co-founder, Profluo
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
I noticed that SMBs like to see and purchase a BPM tool with already implemented processes and SMBs consider to “slightly” modify those processes for their needs (flexibility is an essential selling point for BPM as we know). But, usually, the reality is not as simple as marketed. (Those processes are not implemented to be easy to adapt).

Agree with David that a platform-based approach maybe a better choice for SMBs because in such a platform everything can be reused or replaced.

Agree, this is our approach and implementation pattern (on top of my input above): start with something pre-configured and iterate on it to customize lightly. And of course only a DBP can accommodate this coherently, because SMB's business needs jump wildly, from cost control to receivables dunning to absence management to business intelligence to ERP to CRM. And you could, as a vendor, start putting out multiple small fires - the only way to keep yourself sane is to work with a coherent architecture - a DBP.
Oops. what's a DBP?
Sorry, Digital Business Platform - I took the liberty of not explaining as we recently had an entire topic about it on this forum.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Two things..

I have no problem with use of a combination of two logical approaches . . . .

a) delivery of a platform with already-implemented processes
b) delivery of an empty platform that allows easy mapping/forms/rule set implementation.

It makes sense to use the first approach to adopt (not adapt) processes in business areas where there are "standard practices"

e.g. In the area of behavioral healthcare, there are over 1,000 scales/instruments/measures that are considered "standards".

Why have each healthcare agency re-invent these?

Otherwise, it makes sense to use approach (b) for processes that are core to an organization's competitive advantage.

What entrepreneurial organization spends decades building competitive advantage through policy and procedure only to all of a sudden cast these aside and take on operational protocols developed, in many cases, by armchair managers?

Good of you to raise the issue "reality is not as simple as marketed".

We can probably agree that unless a vendor goes out of their way to make process mapping difficult, mapping is "easy".

Except that . . . take rule set construction as an important example. If one is adept at rule set construction then it's "easy" to build algorithms, if not, then the same scope of activity is 'difficult'.

Senor Wences was right " Easy for me, difficult for you".

There is little point implementing processes that do not have rule sets (rules at steps, rules on entry to steps, rules on exit from steps, rules at the Case level).

Most perplexing is the generic finding that keeps facilitators gainfully employed - many folks in silos are unable, unwilling, overly protective of their turf, or "too busy" to "think" process.

I find it fascinating to go into organizations where I do little more than ask " . . . . and then what do you do?" and go off site two days later with most of what is needed to complete a set of 20-30 processes at a distance.

See the link below "The Facilitator Is Coming"

As for . . . processes are not implemented to be easy to adapt - this, surely, mirrors what healthcare software vendors have done for years i.e. making it difficult to export patient data/import patient data under the false assumption that holding customers hostage is the route to customer retention.
  1. http://wp.me/pzzpB-aG
RE "adopt (not adapt)" - I think that "adapt" may become the primary adoption pattern.
  1. John Morris
  2. 3 years ago
  3. #3378
We have touched on adaptation a few times; it's both interesting and extremely important. Certainly one must adapt to change. But there's a difference we could explore between guided adaptation and opportunistic adaptation -- it can be shown that the latter leads to a higher probability of failure.
RE "guided adaptation and opportunistic adaptation -- it can be shown that the latter leads to a higher probability of failure" Yes, recently, I had a chat with a chief enterprise architect from a huge insurance company. He said that they do not like BPM-suite tools because only some gurus can program those tools and attempts to copy work of those gurus made a lot of mess. I think, in addition to "guided adaptation" and "opportunistic adaptation" it is mandatory to offer "architectured adaptation".
I see Adaptive is very important for delivery of BPM...but that requires business people not gurus as Alexander said. Karl hits a sensitive button on the customer "lock in" by vendors. Both these issues need to be addressed to see BPM take lead position in enterprise software putting the customer first....?
RE "requires business people not gurus" - again, reality is worse than imagined. Even certified "architects" can't adapt gurus' creations. Agree with David that customer must be put first and I would add, during the whole life-cycle of BPM-based solutions, thus adaptability is the main characteristic of any BPM-based solution. How to measure? An idea - put your BPM gurus in a corner and ask somebody from your team to change a solution.
How can we accommodate Alexander telling us that there is a need for "gurus" whilst David is telling us at the same time that ordinary business people can map out processes?

Both are right, both are wrong, IMO.

My position all along is, yes, ordinary folks can map out their own processes BUT they do need help from IT building rule sets and they do need help from IT linking Case run-time environments to / from local & remote 3rd party systems and applications.

The root cause of these opposite positions lies with some of the process mapping environments where you have to master a language / notation.

My approach to mapping requires no languages and very minor use of notations.

Please, everyone, take the time to click on the URL and see how a process can be built using very little beyond square boxes and directional arrows. Of course, the example in the video is trivial, the video only runs for a few minutes but you WILL see mapping, compilation, rollout and run time use.


Please comment- is it difficult or is it easy?

Looking back, I figure I have a lot of expertise working with complex computer languages/notations - I did 17 years in APL (now a museum curiosity), where I suspect the aficionados would all agree that in the absence of a narrative, the code was a very tightly packaged set of absolutely incomprehensible (other than to the programmer) of mathematic symbols (e.g. you could write entire programs in one source code line with APL).

My take today, as we seem poised to start putting AI between users and back-end engines, is we are headed closer to Alexander's position on the subject of "difficult / easy”.

David, I, and others, meanwhile, can continue to say that a FAIR portion of business process mapping can be done by ordinary business people BUT it might be good to qualify such statements with " . . little point implementing processes that do not have rule sets" and ". . . .little point having run time environments that cannot seamlessly import and export data to / from the environment.

IT has nothing to worry about going forward.

Someone the other day tried to tell me that writing parsers/formatters was "easy" - my response was we don't write parsers/formatters - easy, but way too tedious.

What we write are programs that write parsers/formatters - not tedious at all, not easy.

Of course, the whole subject of the need for parsers/formatters can be debated - standardize all BPM processing and run-time environments plus all IoT device interfaces and you can freely exchange data in multiple directions. Not likely to happen.

I will stick with generic data exchangers/parsers/formatters. The proliferation of these is self-correcting - people get tired of inventing new formats when they see an inventory of say 100 pickable data transport formats. Much easier if you are designing a new app to use an existing format than to invent a new one.

Sorry for the long rant - the main message here is click on the URL and comment


@ Alex: +1+1+1+1+1 "I think that "adapt" may become the primary adoption pattern"
Sure, but my original comment on this was in reference to 'industry standards" - I should have said "medical standards" because that is what I had in mind when I wrote up the response to this forum question.

Get a grant, do a clinical trial where you make a very modest adaptation to a the standard and there will be two outcomes 1) rejection of the clinical trial results 2) greatly increased difficulty getting new grants.

For ordinary corporate process building the logical approach its to start with what you can get from a process library and adapt it.

We can go too far though by overloading libraries with trivial "start -> end" processes, where it probably is easier to start with a blank canvas.

@Bogdan Thanks.

Implementing processes in a highly adaptable manner does need a consistent and architected approach to BPM (actually, my book was about such an approach). Coordination, rules , roles, events, data, services must be easy reusable and easy replaceable. Of course, each BPM-suite tool does it in its own way by tools’ gurus, but many common practices are available. For example, business people work with a view which shows the happy path only and a simulation view, process template are available, automation scripts are externalised, etc.

@Karl, Did you look at autonomous data exchange? The article http://www.iec.ch/whitepaper/pdf/iecWP-loT2020-LR.pdf recommends this technique. "For autonomous data exchange between entities including devices, equipment, IT systems and platforms, the profile, which manages data communication, plays an important role. "
@Alexander ... Thank you.. Important subject area. I will print out the 193 pages and get read it with my felt marker.
  1. John Morris
  2. 3 years ago
  3. #3391
+1 @Alexander "architectured adaptation" (offered as complementary to "guided adaptation" versus "opportunistic adaptation").
Here's a question: Is architectured adaptation possibly synonymous with "guided adaptation"? I was thinking maybe they were orthogonal to each other, because existing in different spaces (business strategy space versus quality of technology space).
The issue with opportunistic is there is no corporate identity (the idea of "guidance") and opportunism can be shown to be a random walk. The result for an individual member of a population engaging in low-level encoded opportunism is likely extinction.
If however the idea of architecture includes the idea of corporate identity, then "guided" and "architected" are the same thing.
And thus architects now have a new message for selling architecture: Architecture leads to a much higher likelyhood of corporate survival and success, because architecture encodes identity. Corporate strategies resulting from architected technology are no longer opportunistic and the life-path of the corporation is no longer a random walk of soon-to-be-eaten grasshopper.
(There is a little literature on this, but not much . . . )
@John, "Guided" implied that there is a guide (person or thing) who/which helps someone. Obviously, two guides may have three opinions. But, it is necessary to guarantee that two different people in similar situations will follow the same way. Thus "architected" is always "guided" but not all "guided" are "architected".
  1. John Morris
  2. 3 years ago
  3. #3394
+1 @Alexander [Thus "architected" is always "guided" but not all "guided" are "architected".]
  1. John Morris
  2. 3 years ago
  3. #3401
Does BPM.com pioneer new insights? Perhaps yes, at least if the idea of "architecture encodes identity" (referred to above and below) and the discussion of random walk is a new insight.
The evidence is this: The phrase in quotes ("architecture encodes identity") turns up zero hits on Google as of Feb 23, 2017. A slight variation ("architecture defines identity"), which doesn't mean the same thing though, gets only eight hits. What does this mean?
Possibly that the insight isn't an insight at all, mere randomness. Or the lack of hits could indicate opportunity.
Leadership studies show increasing interest in the value of corporate identity (a.k.a. "corporate culture"). At the same time business architecture and software architecture are slowly getting more traction -- very slowly it seems.
The intersection of culture and architecture is captured in our phrase "architecture encodes identity" and the combination could be powerful.
And BPM software technology is at the heart of it all.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Sure, "architecture encodes identity" or, if it does not within its current definition, it easily can.

We have "good" protocols for evolving strategies, selecting initiatives and allocating/authorizing promising initiatives.
We have, thanks to ACM/BPM, "good" protocols for controlling the implementation of these initiatives
We have "good" ways and means of monitoring and challenging KPIs.

Rule 1 don't allocate resources/activity that does not sustain/enhance corporate advantage
Rule 2 don't perform work that is outside of the scope of ROIs or annual budget allocations.
Rule 3 make sure Rule 1 knows what is going on under Rule 2 and make sure that Rule 2 knows what is going on under Rule 1

When there are fails, you get this

"Woman admits $1M stolen from employer paid for luxury lifestyle (USA Today)

Simple analysis : dumb (the woman) and dumber (the employer). [kwk Facebook post]

What employer fails to put in place basic admin checks and balances?
  1. http://www.usatoday.com/story/news/nation-now/2017/02/21/woman-admits-1m-stolen-employer/98227390/
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
For clarity I see the supporting platform for BPM needs to include rules capability and of course ability to import and export data as required. Yes you might need a "guru" for sophisticated manipulation of data such as an algorithm but build of all process requirements are business analyst type skills. We have found that it is not the users "job" to change and best having leader to facilitate collaboration to build and change with users direct and linking to IT as required. A process guru maybe but deep technical coding not required....!
"Very small businesses" probably are well advised to follow John's advice "the only viable way for SMB to afford and do BPM is via boutique BPM consultancies".

It's all too easy to elevate someone who writes up corporate procedures to "business analyst". And, putting these folks in a corner office with a title of "guru" takes only a brief lapse of rational thought.

The definition of SMB tends to be all over the place, hence the reference to "very small businesses" - In the EU "small/medium" means less than 250 employees, in the USA "small" means having less than $10 million in assets, the next step up being "large". Either way, a resident BA probably can be justified but headcount and/or $$ assets are not the only ways to size a business.

Overall, I don't have a problem with titles - my son, at the time he was about 8 years old, when asked what he would like to be, responded with "supreme intergalactic potentate" .
  1. John Morris
  2. 3 years ago
  3. #3405
Glad you caught the note @Walter on SMB and boutiques -- this could be a Forum question topic . . .
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
BPM exists in every company, even a smallest one. However, it is not always recognized or acknowledged as such. Because small companies significantly outnumber larger ones, BPM in small companies is most wide spread and demanded kind of BPM.

BPM projects in small companies have a small or even zero budgets. For this reason these projects are not viable for BPM vendors. These user cases will hardly shine as a bright report or a viable promotion. As a result, BPM in small companies is poorly covered in reviews and research compared to large BPM projects. This creates a false impression about real spread and importance of SMB BPM practices.

In many cases BPM in small organization is even more efficient than in bigger companies. This appears due to its relative simplicity and smaller number of workers, as well as due to overall higher efficiency and flexibility of small business.

Of course, BPM in small organizations differs in its manifestations and tools from BPM in large companies.

1. Most well-known and long proven BPM tool in all types of organizations is human voice. Manager giving tasks to workers is a perfect example of business process management. Despite this BPM tool is oldest among all others, it still far more widespread and efficient than any other BPM tool.

2. Eventually, even tiny companies accumulate a critical amount of business rules, which become hard to keep in mind. Then, the second most popular BPM tool is a classical notebook with various sorts of business notes.

3. Next most popular and more contemporary tool, which gradually takes over voice and notes, is a messenger. All types of messengers are widely used across organizations to set tasks and control workflows.

4. Since more and more companies use computers or mobile devices, business rules tend to migrate into various electronic documents. Therefore, various office packages are among most popular BPM tools in small companies. As a rule, process maps appear in them in forms of various internal instructions where a process appears in a form of list with steps and notes. Classical documents with chapters and paragraphs, spreadsheet tables, slides, all can serve as process mappings depending on preferences of company management.

5. As a next step, many companies begin to depict processes in a form of diagrams. This stage is already close to normal process mapping in classical BPM. Although, in small companies resulting process diagrams typically appear ad-hoc and deprived of rigorous rules and methodology.

Small companies rarely embark on cross-application automation and orchestration of processes. Maximum, some elementary automation is made in terms of customization of rules in dedicated business application, such as CRM. Further inter-process communication is done in a form of written or depicted instructions according to process mapping options listed above.

Of course, above BPM practices are far behind modern BPM achievements. Nevertheless, it does not justify neglecting them or diminishing their role in overall BPM landscape. We routinely work with such BPM implementations and transform these basic BPM assets into more formal and contemporary BPM models.

Illustration: sample process map in an office application.

  1. John Morris
  2. 3 years ago
  3. #3417
+1 especially the mention of voice as a segment where business process has been successful and widely used. At least one of the leaders in this space is actually pioneering BPMN-based BPM now.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
How about we turn this question around on its head. What does BPM need to do differently to be applicable for SMBs. I think that's a better question. Small businesses have less time, less budgets, and less resources overall. So, for BPM top be viable it needs to be leaner and meaner. This is already happening with workflow management or task management systems that simplify (or redact, depends who you ask) BPM.
+1 Eyal, fantastic idea and observation! It should be really put all upside down in regard to SMBs.
  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.