E-commerce News Blames Small Businesses for not Adopting BPM Faster

Scott Francis
Next Post
Previous Post
In an article titled “Getting Small Firms on Board with BPM“, the author starts with the following assertion:
The greatest obstacle small business operators face in adopting business process management (BPM) is themselves. That factor could account for the underutilization of BPM by small businesses[…] Of course, the abundant offerings of vendors can be confusing, and the trade jargon (SOA, Saas, ROI) can be daunting. Still, the reluctance of small firms to fully utilize BPM often comes down to one thing: attitude.
Of course, the first problem is that the author fails to define “small business” for purposes of the discussion, so that we can all operate with the same assumptions in mind.  Is a small business 3 people? 30 people?  300?  3000?  Or if we size by revenue, how much revenue makes one no longer a small business? In the very next quote we’re given the example of a six-person automotive shop that has a finance system, sales and customer management, and a website, but no BPM.  Shame on you, automotive shop.  Of course, this belies the literally thousands of successful automotive shops around the country (and world) who have perhaps nothing more than Excel or Quickbooks and a few three-ring binders. The focus of the article is on the bad attitude of the small business owner.  I think this is misplaced.  The beginning of any discussion of the applicability of BPM should start with something small business owners can relate to:  the bottom line.  Will BPM generate ROI for the small business?  Will it pad the bottom line?  Will it create more free time for the business owner to focus on other endeavors? I read the whole article… didn’t see a single mention of business value in quantifiable terms.  But several points were made that make it clear that some of the benefits of BPM are inherent in the small business – such as the lack of silos, and the ability to see and understand the end-to-end process without software implementing it. The most bizarre quote in the article is this:
“A consultant is definitely not called for,” added WinterGreen’s Eustis. “What is most significant for BPM in a small business is service and support. The best way to find out what is a good product and what works well in a local area is to ask your friends and employees. Ask around and check out what others recommend.”
Right, so if I just ask around amongst my friends I’ll find the best BPM product?  I challenge you to try this at a dinner gathering – BPM may be gaining in currency but it is hardly a household term, and the vast majority of people out there have no direct experience with the BPM software offerings on the market (not least of which – most are not freely available).  This is hardly a good way to buy BPM software. Secondly, Eustis challenges the idea of using consulting help.  Keeping in mind that the average six-person automotive shop isn’t likely to have their own IT staff – and in particular, they aren’t likely to have a BPM expert on staff, or time to give someone to become an expert.  If the BPM project has good ROI, it will likely be better for them to invest money in outside help to get them over the initial investment hump rather than pay the price of all the ramp-up. Adding insult to injury on the “you don’t need consulting help” thread, Software AG and IBM are given as examples of BPM vendors who are cultivating small businesses.  I can’t think of two vendors that have more complicated software offerings to master in order to deploy your solutions (though admittedly I’m much more familiar with IBM’s offerings). And then open-source offerings are touted, but of course those offerings require even *more* technical know-how than the commercial solutions- precisely the skills that are scarce at most small businesses (or, in high-demand with competing needs) I just found the whole article puzzling at best.  If you’re a small business, and you have processes that are costing you money or causing you pain, look for opportunities to outsource those functions, to deploy off the shelf software (or SaaS solutions), or to deploy BPM.  But whatever you do, make sure it is capital efficient because capital is the most important thing for the livelihood of small businesses.  And make sure it is time-efficient because, after all, that’s the second-most scarce resource in a small company.
  • BPM is in use in small business, just not in the way enterprises think about it. It is embedded in the software that runs the business. For example, auto shops use a software package that manages scheduling and invoicing, and it has rudimentary workflow specific to managing and optimizing the repair life cycle baked in. It is simple, and not at very flexible, but it gets the job done with minimal overhead and none of the complexity that is traditionally associated with implementing BPM.

  • BPM is in use in small business, just not in the way enterprises think about it. It is embedded in the software that runs the business. For example, auto shops use a software package that manages scheduling and invoicing, and it has rudimentary workflow specific to managing and optimizing the repair life cycle baked in. It is simple, and not at very flexible, but it gets the job done with minimal overhead and none of the complexity that is traditionally associated with implementing BPM.

  • The last line of your comment implies that the complexity comes from BPM, but I would say rather, in many small businesses simplifying assumptions can be made that result in solutions with minimal overhead being applicable, and result in reducing the complexity traditionally involved with deploying to those large enterprises. The BPM in large enterprises gets more complex because the problems it is addressing are more complex at that level.

  • The last line of your comment implies that the complexity comes from BPM, but I would say rather, in many small businesses simplifying assumptions can be made that result in solutions with minimal overhead being applicable, and result in reducing the complexity traditionally involved with deploying to those large enterprises. The BPM in large enterprises gets more complex because the problems it is addressing are more complex at that level.

  • To be fair, most big companies also have workflow baked into their applications, like ERP. The idea of separating out the process from the application is an unnecessary bit of overhead if your processes are perfectly met by the (relatively) static workflow inside your app.

  • To be fair, most big companies also have workflow baked into their applications, like ERP. The idea of separating out the process from the application is an unnecessary bit of overhead if your processes are perfectly met by the (relatively) static workflow inside your app.

  • Right – at some point the baked in workflow isn’t good enough, and the ROI for real BPM is high enough, that it makes sense to invest. Or, you want the freedom to manage a process and change out some of those packaged apps (maybe not all of them can be, but some can be) , and BPM isolates one from the other, instead of muddying things together.

  • Right – at some point the baked in workflow isn’t good enough, and the ROI for real BPM is high enough, that it makes sense to invest. Or, you want the freedom to manage a process and change out some of those packaged apps (maybe not all of them can be, but some can be) , and BPM isolates one from the other, instead of muddying things together.