In your experience with companies that are just starting out, what do they most frequently get wrong about BPM?
Just like most companies, start-ups don't think they need BPM. However, unlike most companies, start-up actively avoid BPM, for two reasons:
- they believe that they are too small to derive significant benefits from defining and managing processes. And they tend to replace a healthy task collaboration with quick hacks or cool apps.
- the inexperienced ones drink the koolaid of "less process = more freedom"
Of course, the well-managed ones have a COO that is in charge with day-to-day management cadence and rigor and that screams process everywhere in the organization.
Another funny trait of start-ups is that the ones that survive tend to recollect that the key of their success was how well they did something - which was in fact how well they managed a certain business process - like managing customer service, proactively managing the sales funnel, dealing with bad press, the build-measure-learn cycle, the hiring formulae etc etc.
Maybe it's just too simple, but if customers see value in what you do and in the end you can earn a buck with it, who can say you are not doing BPM well?
But if I have to say one thing it would be that they should never forget that a good process starts at the end. Every process is just a means to deliver a result. So is anyone waiting for what you offer?
Sometimes I have the idea that's not always the case with a
start-app start up. Who needs the next app to compare hotel rooms? Or the next fitness thing on your body?
But it's the same for every company. If you offer stuff nobody needs, it's useless to take a look at your processes.
If it is something useful, than the process should fit the product/service you are offering. And maybe that's done more organically in a startup than in larger and older companies wher they think they can do BPM as a separate thing in some kind of Center of Excellence.
Startups go through several critical stages we can generically call "building infrastructure".
The first thing they need to do is to identify and inventory the corporate assets they will need (concept, financing, partners, market/prospective customers, product/service designers) and then proceed to move these from "pending" to "in progress" to "in place".
No point spending all of your seed money if you do not attend to arranging for financing.
No point trying to start up if you lack key resources and need partners without setting a focus on finding partners.
No point moving forward with a concept if you don't have a tentative marketing plan that identifies prospective customers.
No point hiring staff to design products/services if you are not clear on your concept.
The danger starting up is that you neglect the long term and end up in a permanent state of firefighting.
IMO success in business hinges on maintaining a reasonable balance between long term and short term.
Process mapping comes later rather than earlier.
Once they get to where they need BPM, here's how they often get into trouble.or avoid trouble.
Most startups face two contradictory impulses when it comes to processes. On the one hand, one of their main advantages over larger established companies is that they can 'do things that don't scale'. Paul Graham, a co-founder of YCombinator wrote this well-regarded article on this subject. On the other hand startups are extremely short-staffed and need to be hyper-efficient, especially as they find product-market fit and start to scale.
It is in this latter phase that some startups start making mistakes. Most will recognize the need have a process mindset in order to scale. And in fact there are many apps that help startups scale and startups tend to utilize these well. It is where apps don't exist that many do not invest in processes. Another way of phrasing this is that they let their apps do their process thinking for them. They essentially muddle along in areas where readymade apps don't exist or don't fit their business.
In some sense it is hard to blame them as they are unlikely to divert scarce resources to building bespoke apps. The BPM industry can help them by providing them tools that enables process scaling without coding and without a large cognitive overhead in terms of mindset, jargon, tooling, cost etc.
ps) Now, for that specialized startup beast called the BPM startup, I would surmise that (as @JohnReynolds observed) not eating their own dogfood is their biggest mistake.
With all the other things to do when starting up and scaling a company, "getting processes defined and communicated" is always put to the bottom of the list, until something HUGE puts it to the top of the list (CX disaster, compliance, revamp of systems). You can always get along with porr/no process and heroic efforts by staff.
What they don't realise is: Defining processes are easier when you are smaller, so why put it off? You are going to have to do it some day. Do it today and start getting the benefits.
Ranjit seems to me to be correct on all fronts. Building processes that scale is a good thing, but at an early stage, just building processes that work is challenging enough. Just knowing what processes to focus your attention on is hard enough.
Obviously, modern software development start-ups are using BPM "à la IT" very intensively from the day one. All agile techniques and devops are their core processes. The problem starts when a program becomes a programming software product (shipped or clouded). “Mythical man-month” on the page 5 tells us that the latter costs nine times as the former. This is the place for BPM "à la business" to reduce that huge factor.
Ideally, any service-centric start-ups must start from perfecting their processes to get their CX correctly. Unfortunately, the current state of BPM will not help them (as we have discussed recently – see ref1).
Agree with Scott my experience of most start-ups will not have BPM on agenda until scaling support needed. However the big well financed start up should really have on agenda but is the BPM message spread widely enough...?
As for a BPM start up needs to be driven by business thinking not contaminated by old IT business software and then have top grade programmers who build tools as a platform that business people use to build those adaptive applications supporting BPM.
Interesting the major consensus seems to be that start ups, a) don't do BPM, b) if they do, thsy usually get it wrong, and c) in many cases they are drinking from the koolaid fountain of bad experience/knowledge. Of course all this could be true. But, I am more inclined to agree with Karl Walter points. As I am currently going through precisely these decision points for a start up.
Speaking as someone who started (up) in 2007, and still running the business, I can share my perspective on BPM in startups.
1. Most people who start up a company don't know the first thing about BPM or BPMS, per se. That's not a criticism, it is just stating the facts (it isn't widely taught in schools, and likely still a majority of people founding companies have experience with BPM or a BPMS. )
2. When a company is small, less than 5 people for example, most startups have no repeatable, volume processes. And each person may be the *only* process participant for a given process. So, the value in automating processes is low,and the value in defining them for others is low.
3. If you're BPM knowledgable as we were at BP3, you still have a problem - we're out there doing BPM and BPMS implementations for customers. The shoemaker's children run barefoot, as they say.
The most important priorities for a startup are:
- securing funding from investors or customers (aka Revenue)
- finding product market fit
- (later) sales
- (later) recruiting
processes that support those things actually get a lot of attention, and processes that don't... don't. But eventually your processes have enough volume and value that you'll invest in making them better. Invoicing. Customer onboarding. Development process.
But if you think startups don't care about processes, I would disagree. The good ones do. You see it in the language they use to describe their solutions- the process for fleshing those solutions out; the process the customer or user experiences. The process for hailing a cab... The process for getting a loan. The process for paying at a register. Good stuff.
I think that Paul Graham's post on doing the things that don't scale is a great example of how a startup would approach learning and improving a process. It's a good read.http://paulgraham.com/ds.html