Found this quote from this San Ramon article interesting: "Any growing business is likely to encounter growing pains. But 'growing pains' is just a mild way of saying a business’ process are not adequately scalable." What are your thoughts?
This is a long-held belief, which is being discovered by the new kids of unicorns as well. They start out with the "we are flexible, we hate processes, we hate bureaucracy" and, as they scale, they increasingly need to find repeatable methods of successful execution of operations.
It's just that they don't call them business processes and business rules (boring legacy crap). They use much cooler names, like growth engine, Scrum, service design, customer journey mapping, lean analytics, sales acceleration formula.
I actually have a big entrepreneur that works with us that said: "I want to scale internationally and I know I cannot do it without processes".
That's a very important consideration, since the current legacy BPM approaches make pretty flowcharts that nobody looks at.
I think that's not such a weird statement.
Assume I own a pizzeria and my process "Deliver pizza" has to process 25 orders an evening. I have everything set up for that. Personel, oven, supplies, delivery scooter(s)
If I wanna grow, i should not only focus on marketing that suddenly makes that I receive 40 orders an evening. Befor that I should have taken a look if my deliver process is able to cope with this growth.
Do I need more people?
Do I need another oven?
Do I need more supplies?
Are 2 Scooters still enough?
But more important; if yes, how fast can I set this up?
Or is it better not to grow? Be happy with what I have, serve my customers and enjoy my family and friends.
BPM is about making your processes do what you promise to your customers. So many small companies are great in BPM. Till someone decides growth is good.
And this is only a pizzeria. Assume you're a big computer game manufacturer and your latest game app thing goes viral....
- Patrick Lujan
- 1 year ago
Commercial link in 1,2,3:
I strongly believe (and also experienced) that scalability either rock or fail, depending on your process culture and the means you have in order to cookie cut your processes.
- Walter Bril
- 1 year ago
Not processes are the key to scalability, but the way you manage them...
A properly architectured use of BPM (as a trio of discipline, tools and practices) is scalable in the several dimensions. For example:
intra-business-entities (B2B) coverage
inter-business-entities (end-to-end processes)
customer-experience (B2C) coverage
“scale-out” (i.e. handling more processes instances which are very independent)
“time-to-market” (thanks to "snowball" effect)
load/performance forecast (i.e. predictive analytics thanks to process models and previous audit trails)
enabling innovation by making a lot of routine operations “perfectly”
cross-industries by achieving synergy between uniformity and diversity
I (unsurpringly) think that is even more than that.
A brand is a
[b]promise[/b]you make to your customer. You build your brand by keeping your promise. Every time. And that requires at least consistency in
[b]meeting[/b]the expectations (and if you're really brilliant, consistency in
Consistency is done with amazing processes, not with Illuminati that accept to work for the minimum wage just so they have the amazing opportunity to please your customer from their call center cubicle.
I don't believe that processes are "the" key to scalability.
They are, for sure, key to efficiency during scale-up, but Emiel's "Deliver Pizza" process scale-up to 40 pizzas per evening has an element of sub-optimization in it.
Delilver Pizza wants to scale up - is it essential that they focus exclusively on their existing process to achieve this objective?
Adding capacity for the evening shift is one way, . . . except that they could optionally scale-up by setting up a lunchtime sidewalk canteen at some appropriate location, stick with the evening capacity of 25 and use the existing (idle, but available) infrastructure to make and one-time-deliver 15 lunchtime pizzas to the proposed canteen.
It's always best in my view to have on hand a strategic knowledgebase to look at when contemplating optimization of processes.
Strategies without processes are problematic, tweaking processes reasonably should be done with some reference to strategy and, in some situations, with changes to strategy.
The early stages of a business are relatively informal it's just get on with it.....basic book keeping will likely be In place issuing invoices etc. Very likely spreadsheet used and shared. The smart entrepreneur with ambitions to grow quickly and scale will recognise the need to see processes become formalised but want flexibility and of course engagement of customers will likely be "digital".
So planning will avoid too many growing pains and should have knowledge just how all this will actually work to deliver the future where all users get what they need with real time feed back on the outcomes of the process activity. Change is inevitable in such an environment and will be an important consideration in choosing the supporting software platform...as will cost....the cheaper it is the earlier likely to be adopted?
Honestly, my first reaction was, YES of course it is!
However, if you look at the BIG picture, there are a number of factors that contribute to successful scalability. It is true that process is important, but so is strategy( which includes vision, goals and objectives), good leadership, good people and depending on how much you're scaling, good Information Systems.
I agree with the comment that process alone isn't the answer. Good process management is key.
[i]Not scaleable[/i]" means that
[u]costs rise more than linearly[/u]with increased volume. And "n
[i]ot linear[/i]" then likely turns into "
[i]exponential[/i]" very quickly.
There are lots of good comments here but how
[u]what can we say about scaleability that doesn't result in an answer that encompasses most of management best practices[/u]? In which case the value of the question is lost:
[u]We all know we should be good at everything[/u]!
So the original question could be generalized to
[u]what distinguishes a firm that successfully scales a given business from one that doesn't[/u]? And what specifically can we say about this distinction which is
[u]directly concerned with "process" or how work is managed[/u]?
Our original definition of scaleability was based on costs. Specifically this is "
[u]process efficiency[/u]", the same or greater output for the same inputs.
Therefore, what can we say about process efficiency and scaleability together?
1) PROCESS EFFICIENCY ENABLES TECHNICAL SCALEABILITY -- Scaleability is possible when we continually
[u]bring the work of business under management control[/u]. As we scale and new bottlenecks are identified, we evolve controls and flows. This is the work of automating business. When work follows
[u]a repetition pattern, that work is a process, by definition[/u].
2) PROCESS EFFICIENCY ENABLES FINANCIAL SCALEABILITY -- Scaleability isn't only a technical/managerial challenge. It's also a funding challenge. If we are throwing off cash because we are efficient, we can either fund or be financed for growth, i.e. to scale the business upwards.
The fact that some business cadres don't like the word "process" is irrelevant. It doesn't matter that someone doesn't like the word "food". Whatever you call it, you have to eat. And managers have to manage. A well-managed process scales costs correctly with volume, as permitted by underlying engineering and business limits.
[i](Economist Ronald Coase's work on the optimal sizes of firms is relevant here I think.)[/i]
BPM software itself is critical to scaleability. It is the technology, by definition, which presents the concepts of the work of business as first class citizens of that technology. BPM software is an enabler for managers who want to build the most efficient ways of performing their work-of-business.
Everybody struggles to establish scalable processes. In a growing business, though, the issues are typically more prosaic: people and money. In a growth stage, it's less about building scalable processes than about maintaining the agility and creativity required to re-invent your company—including your business processes—at a moment's notice. You might say that it's not a process issue, but rather a meta-process issue (if you're that kind of person, which I most decidedly am not): the ability to rapidly discard your old process and replace it with a better one is far more critical than the ability to scale the process you have in place today.
I strongly believe that process provides the vehicle to enforce consistency as you grow and scale. Without this we lose consistency and we accumulate debt down the line. I think it is more critical that the process can morph and adapt very easily so that it can adapt to the new challenges and conditions businesses need to adapt as they grow bigger (more internal and external compliance and regulations). No business knows exactly the future that lies ahead. Being able to quickly adapt is the key to succeeding or failing!
No, infrastructure is. No, wait, wait... that's BPMSs.
Then again, I kind'a, sort'a wanna stick with that answer. Think about it.
Process maturity is a necessary requirement for cash-efficient scalability. Anyone can scale a company if they have $500m to burn. Even I could do it!!! But to scale whilst driving down the cost of sale is where aligned operatinal processes come in - top down, end to end, connected to apps. And in the new digital world it is EVEN more important, because the margins on these new businsess are razor thin. https://q9elements.com/the-stage-is-set-for-disruption/
Interestingly we are getting a lot of companies coming to us at 300-400 staff having raised $100+m of VC realising that they have grown through heroics and the sheer will of the CEO, but now they need to put some structure in place - operational processes (or whatever they choose to call it as Per Bogdan's earlier comment).
However, "scaling a company" isn't the same as "building a company" (or wasting $ 500m):
The Investopedia definition is a systems oriented definition -- maintains functionality under increased workload.
- John Morris
- 1 year ago
The biggest challange for fast growth companies is "we are rock stars, we are innovative, we are scaling rapdily" with high-ego CEOs who wouldn't recognize a process is it bit them in the arse, which menas there is no process culture driven from the top. This burns up lower level managers and staff who desperately need processes so that they can work efficiently. Which means that operational managers need to take the lead and stay under the CEOs radar, because the CEO would see process as "constraining, boring, creativey killer, stifles innovation".
How wrong could they be.....
But again we need to rebrand "process" so it is palatable by these CEO's. So maybe a supplementary question fo r this group is "What do we call 'process' so the high growth CEO will see it as important?"
*We know everything is a process. Processes convert inputs to outputs.
*We know that a "process" can be a linked set of steps or a single step, and at a practical level any mix of these (the "processing" remains the same - inputs get converted to outputs).
*We know that managing a business is all about evolving strategies, defining goals/objectives, with periodic assessment of progress toward meeting these goals/objectives.
The problem is few processes are end-to-end in b2b, so we end up having to accommodate random mixes of linked sets of steps and ad hoc steps. We need a place to manage these steps - call it Case, if no one can come with a better suggestion.
Case is nothing more than a cursor position in a post-relational database management structure. The structure is not restricted to pre-defined data storage tables/fields. A Case record can accommodate objects that require apps to view the content (images, spreadsheets, .doc/.pdf/.rtf, even audio/video recordings).
Some of these objects are stored in specific database fields, some in Binary Large Object fields, some are too large and need to be "stored" in external files with links to these objects. Bottom line, Case can accommodate anything and if you need sub-Cases (multiple orders for the same customer, multiple claims on an insurance policy, multiple episodes for a patient), no worries.
What is Case Management? - is this really not part of "Business Performance Management" - relying on what we probably could call "best practices" (i.e. process fragments consisting of linked steps, plus ad hoc interventions by resources who use experience, judgment, intuition and decision support).
Surely CEO’s would relate to Business Performance Management (BPM) as an alternative to Business Process Management i.e. they set strategy, resources are allocated to Cases via ROI submissions and via annual operating budgets – this ensures, to an extent, that the only work undertaken is work that is supportive of strategy.
Phase II is to monitor progress at the operational level toward meeting Case goals/objectives. Where are these goals/objectives? Surely not plan-side as the end steps in flowgraphs (i.e. we have moved from end-to-end processes to process fragments).
The answer is we find goals/objectives at Cases (run-time side) and Case Management breaks down to performing interventions at Cases that advance Case goals/objectives.
Now, few knowledge workers deal with only one Case – the reason is progress at Cases is often held up for various reasons (handoffs, wait times), so most workers will be working on 10, 20, possibly 50 Cases at a time (yes, for healthcare, yes, for insurance claims, yes, for job-shop manufacturing), so, the role of supervisors is not to manage individual Cases but rather that of allocating, leveling and balancing resources across multiple Cases.
Enter KPI’s at the strategy level – this is where we narrow the gap between operations and strategy.
Strategy -> Initiatives -> Cases -> KPIs – strategy
Here, all we need is the ability to consolidate Case data from multiple Cases to an environment hosting corporate KPIs and CEOs have what they need to ‘steer the ship’. I.e. Business Performance Management.
Almost, but not quite.
Missing is the ability to challenge the statistics and, to do this, CEOs need corporate knowledgebases where they can, on their own or, with a little help from staff, test KPIs trends against information in the corporate Kbase (i.e. our sales in country ABC are up 10%, sales in ABC for our three main competitors are up 20%, so reporting that “10%” is “good” needs to be investigated).
Structured sequences of steps plus ad hoc steps can collectively be called “best practices”, Case provides the environment for performing work, the way goals/objectives are set up at Cases and the way Cases are managed helps ensure that work is at all times supportive of strategy.
Business Performance Management is what the organization does to build, maintain and enhance competitive advantage.
To me this Taylor style process is just one type of process, which indeed is often supported by lots of managerial layers. But is that still needed? Even if growth happens to you?
Couldn't other ways of managing processes (network style, self steering) be an option?
Do lower levels need processes? Some might (I think they should be called procedures, not processes) if the products and services delivered, fit that way of working.
Or do they just need goals and are free to figure it out themselves with some coaching.
All kind of ways to manage processes (or better: do what you promise to your customers).
So it always comes down (or is it up?) to a more strategic level on what are your desired process results, what do you promise about that and what is the best way to execute and manage a process that delivers that promise.
....Still thinking about a better acronym
+1 "constraining, boring, creativity killer, stifling innovation" . . . it's almost an aesthetic or Nietzschean view of business, the leader as "hero". The process world-view is different.
- John Morris
- 1 year ago
- pro-level workhacks
- FlOps ("flow operations" :-) )
Everything we do to make shareholders happy
Yes, I am still working on a cooler acronym
Interesting narrative about scalability in the Feb 17th, 2016 Atlantic:
[b]The Wrongheaded Belief That Every Business Should Scale Up[/b]
[url="https://en.wikipedia.org/wiki/E._F._Schumacher"]E. F. Schumacher[/url], author of [url="https://en.wikipedia.org/wiki/Small_Is_Beautiful"]Small is Beautiful[/url] is mentioned.
Schumacher, born in Bonn, Germany, was very familiar with the business ecosystem of small German mainly manufacturing businesses known as the [url="https://en.wikipedia.org/wiki/Mittelstand"]Mittelstand[/url]. These materials provide food for thought concerning scaleability, ideal business size and the Internet of Things.
Interestingly, the Wikipedia entry on the subject lists one of four characteristics of the Mittelstand as: "
[b]World class performance in core processes[/b]".
I like 'People act more responsibly in the context of personal relationships that are meaningful to them than in strictly commercial transactions". Easily believable!.
I like "bicycle bankers" - I was not familiar with this term.
We had those in Singapore - I lived there for 9 years and we had many visitors with a curious correlation between the timing of visits and whether the visitors were visiting during their "winter season".
They always needed to convert currency and each time they said "I need to go to the bank" we would say, no, lets go to a money changer.
The money changer typically was a person sitting on a stool in an alleyway.
I took particular delight in the process.
The visitor would give $1,000 to the money changer who would immediately run down the alley (desire to give good service).
First time visitors would panic at this stage "he is running away with my money".
As someone said, there are only two things in nature that grow just for the sake of growth: business and cancer.
Process in general is the backbone for how businesses get things done. Proper management of those processes is definitely the key long term success. Good BPM assists in making those processes more scalable.
Processes are key to scalability but ONLY if people come first in executing them. Today's world refuses to be treated like a line in a swim lane. That's why collaboration tools are exploding, even though they are so unstructured.
The future of tapping into processes in order to scale your business is to respect people by letting anyone model a process in 5 minutes (because they want to - not because they have to) and doing it on any device. More on this in the context of digital transformation is on the URL cited within this post.
Silicon Valley, CA
@Amit . I am with you re "people first". It's been that way, actually, in medicine, for centuries (Case Management).
The approach I have taken in healthcare systems design has been to put the Case History (the "chart") front and center to make it easy for people to review patient charts prior to each and every intervention.
The users automatically receive guidance from any engaged BPM processes for the patient and, in the normal course of events, are incentivized to follow the "best practice", except that they can, subject to governance (rule sets that prevent extreme variations away from best practice), insert one or more ad hoc steps.
Clearly, collaboration (i.e. often called "2nd opinions" in healthcare) should not and need not be "cast in concrete" in BPM flowgraphs.
Collaboration in healthcare is nothing more than discussion re a possible ad hoc intervention, or reinforcement to not perform an ad hoc intervention.
According, users should be free to engage a dialog with any number of peers/superiors at a Case (the environment hosting the mix of structured and unstructured interventions).
Collaboration is likely to have a focus at the top level of a Case ("how is the Case progressing?") but just as likely to have a focus at a particular in-progress step or about-to-be-in-progress step (i.e. what is your recommendation regarding the starting dose for this medicine for this patient?)
E-mail is a poor choice for collaboration due to problems threading messages together OUTSIDE of Cases (risk of disclosure of PHI). No better are discussion papers posted to cloud data stores, for the same reasons.
Clearly, the better approach is for the Case Manager or his/her delegates to reach out to potential collaborators at Portals, with responses automatically coming back to the Case or to a Case\step.
Depending on the need for confidentiality, the recipient of an outreach posting need not know the identity of the patient.
The thought "Actually, I must look at the flowchart" is definitely not the first thing that comes to mind for anyone doing any work these days, in any business. How do we solve that problem?
Healthcare is different as many questions of the type "Why did John Doe not receive an X-Ray last February?" are frequent.
Healthcare services providers like to be able to go back to the flowchart to see why the patient treatment plan took a turn along one direction as opposed to another direction.
For most industry areas, workers care first about what they need to do now, and why, then what are we likely to need to do in the future to meet objectives /
Looking back at what was done is a lot less of interest.
Predictive analytics holds the promise of future decision making re patients a lot easier.
And of course they get up from their chairs, talk to real people, either in person or over the phone.
Aside from process designers, I have yet to see one single employee doing work by staring at flowcharts.
Re . . . ". "They just simply trust the workflows to propose and suggest to them relevant activity steps".
Not in healthcare, you can load up a roomfull of physicians and not get agreement on the appropriate starting dose for a particular patient/condition.
Re . . ."And of course they get up from their chairs, talk to real people, either in person or over the phone."
Yes, and not all of this needs be documented in Case Histories because the protocol requires that only one person is able to "commit" any process step.
Re . . . ."Aside from process designers, I have yet to see one single employee doing work by staring at flowcharts."
It happens a lot in the construction industry with CPM flowcharts,but CPM is not BPM.
Software suites that do not let process designers click at a complex flowchart to "compile" the chart to obtain templates\instances that are managed by R.A.L.B. (Resource Allocation, Leveling and Balancing) are covering a small subset of what is needed to "manage processes"
- Page :
However, you are not allowed to reply to this post.