- There is little agreement on whether BPM is a management methodology, a class of software, or just a bunch of marketing garbage
- The methodology people and software people can not accept that the other side has a right to exist
- BPM as a software is too complex, expensive, and lacking in appeal to CxOs to ever be as successful as ERP or CRM
- Success seems to be measured by the amount of profit the software vendors make, rather than the positive impact on a business
Business processes, business technology, online marketing. I am Phil Ayres, 20 years in enterprise software and business improvement. And blogging on and off since 2006.
Tuesday, June 29, 2010
BPM taking off should not be about software vendor profit
Wednesday, June 23, 2010
Another natural order to processes and records
Monday, June 21, 2010
'I hate working with documents on-screen', and other issues we reinforce
Wednesday, June 16, 2010
Pigeon-holes are for the successful
Unfortunately this 'fun' discussion wasn't as a result of something I blogged, but its worth a look. According to Adam Deane:
My view is that Case Management should be implemented by ECM vendors, not BPM vendors.
Case Management revolves around data, documents and data therefore should be dealt by ECM professionals.
ECM requires a different set of skills than BPM.
It would be in the customer’s best interests to have separate systems for BPM and ECM.
I personally believe that it doesn't matter where Case Management sits. Its the business value that this type of solution can bring to businesses that is important. And until my business, or somebody else's is as synonymous with the that specific category of solution as SAP is with ERP, we all need to just accept that the industry is a bunch of pigeon-holes.
Follow along with the comments on Adam Deane's blog. Its getting fun...
A post from the Improving It blog
Wednesday, June 09, 2010
Avoiding rat-holes by working backwards
I'm working on business process improvement with a client in a way that some people would consider to be 'backwards'. I'm not starting by obsessively picking at a business process being performed and constantly refining it so that it works better. I'm actually looking at all the records of transactions generated by the company, which are filed and stored off-site, and I'm working my way backwards into the business processes that created them. For me at least, this is a great way to approach things.
So many times, in business process improvement, especially when selling or implementing BPM software, we already have been told which business process we are working on. A client contact has already made a business case to fix up a specific part of a business process, as she owns the particular department affected by that piece of the puzzle. As much as BPM'ers love to believe they think holistically with end-to-end business processes, the reality of the situation is that they really are just rubbing ointment on a sore spot to take the pain away in that area. Less pain for their primary stakeholder signifies success for the BPM solution, and everybody is happy - except for the fact that the organization as a whole is suffering.
My current backwards view of an organization is turning out to show a stunning landscape of interrelated business processes and information. At this point I'm not talking about 'enterprise architecture'. Oh no, nothing that technical yet. From looking at all the printed reports, paper forms, photocopied documents, Excel spreadsheet and printed then scanned emails, I'm seeing an amazing interconnectedness of activities that is hard to get at when you look at a process as just a series of tasks to be performed.
Now that I've convinced myself that the organization is like one living organism and Mother Nature has overtaken my client, how does that help me actually make things better? Well, there are two approaches to mapping out the way to take process improvement: I can ignore this new view and select a business process that appeals, starting to fix it up, digging in from the 'request' in my diagram; or I can follow the paper trail backwards, from the final result of all the work that is going on (the record), back through all the high-level activities that produced the result.
What I'm finding is that by working backwards, I'm getting a clearer picture of the best-practice straight-line business processes I'm hoping to nurture than working start-to-finish. By working from the absolute end result of the process, which is the records to be kept that are evidence of a successful transaction, I can track back through all the activities that were performed to get there. For a start this allows me to discard the waste output that is often filed because nobody really knows if they can throw it away. More importantly, working backwards tends to hide the rat-holes, exceptions and distractions that typically appear from working the other direction (the benefit of hindsight?), allowing me to see what I really need: what a successful, streamlined business process is supposed to look like within the context of the whole organization. I can then use that information to select the most valuable business processes to focus on fixing, while already having a great view of how they should work.
I like this approach to starting a business process improvement project, although I know I'm going to have to avoid confusing my client with what appears to them to be an ass-backwards view of the world.
A post from the Improving It blog
Wednesday, June 02, 2010
The cloud is not so fuzzy after all
In technology many of us are comfortable voicing opinions about what is good, and what is not, without any practical experience. I'm as guilty as anybody. After all, you just can't touch and play with everything that exists (some of its just way beyond the prod and play level of trial and error attempted my mere mortals). But the cloud is a different matter. It is a whole mass of technology and unconventional (for software) business models that us mere mortals can touch and hopefully understand. So why was I still talking about it without truly experiencing it?
Last week, I kicked off a new program for developers who wanted a nice platform on which to build those killer business applications that they had been struggling with for so long. The Consected API was born -- or at least conceived, since its still a way from being much more than a glint in a developer's eye. So what better opportunity did I have than to put together a new environment for my little developer community than in the cloud? None really, so I bit the bullet, pulled out my credit card, and signed up for the Rackspace Cloud. Yes, the kings of server hosting, with the tag line for their level of customer service service being 'Fanatical Support' have a cloud offering. I'm pretty sure they bought the technology from somewhere, but if the hardware is supported according to Rackspace doctrine, then I'm sure I'll be in good hands.
So why Rackspace and not Amazon with its elastic compute cloud (EC2)? Because the name, the presentation of the service and some of the feedback I've been reading suggests that Amazon EC2 is way more techy than I want to be prodding and playing with while I have better things to be focusing on. Hell, it sounds like your servers can disappear at a moment's notice, reappearing elsewhere in the cloud without data or anything intact (OK, so I oversimplify), so you have to build your solution around the complexity of an underlying server that is so elastic it just rebounds to nothing, but can stretch to enormous if your processing demands. Nope, for me Rackspace offered a cloud solution I could get my head around. Its just like renting a space for a virtual machine, but the business model doesn't tie you to that space. You can shrink it to nothing, or grow it to, well frankly larger than I'm going to need.
The nicest thing for me is that I don't need to rebuild my applications to benefit from the flexibility of the cloud. I don't need specialized developer toolkits. I don't need the cloud API. There is a real operating system (of my choice) under the covers. I get full permissions to install the software I need on my virtual machine while its running, then generate an image of it online, redeploying if I screw something up, or making copies if I need new instances of that server. All from a simple web page in my private control panel. I own the spot I'm running my image on, until I choose to shrink it or grow it. Then the machine will be stored as a snapshot and moved to its new (larger or smaller) home in the cloud. No data lost. No difficult architectures. Just like clicking a button and having a virtual tech come and install more CPU, memory and hard-disk in your server. In under 10 minutes.
So, what is the Rackspace cloud? In my opinion its a different way of charging for a nice, large, well put together virtual machine environment, backed up with Rackspace's 'Fanatical Support'. I like it when some technology is as easy as you hoped it would be. In this case, it really seems to be.
A post from the Improving It blog