- 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
Wednesday, May 26, 2010
You are nothing without a public API
I am going to build an API. Who wants to help me shape it? After all, every self-respecting web 2.0 service has an API. And my self-respecting web 2.0 service wants to be the best platform in the cloud for developers to build super-profitable applications.
For those of you who aren't familiar with the concept of an API on a web-based service (for those of you that are, bear with me) the API is like Lego for geeks - it gives smart developers with a wish to "get rich quick" the opportunity to build out their killer-app, using the building blocks of an application that already has done some of the grunt work for them. This isn't just a way for developers to leach off the hard work of others. Its really about a service being able to bring in smart, innovative individuals, at minimal cost, and in return for the talent and ideas they put into building applications around your service you take much of the mundane stuff out of the picture for them. Innovation can thrive and isn't stifled by maintaining servers, doing backups, or building login and security. And both developers and service providers make sure that there is a way they can make a good healthy profit if one or other sells the new application.
APIs are great if the service that you build on hits one of two criteria:
- It is so successful that you stand a chance of picking up some of the available market of 50 million people using it
- It is so useful and makes the development of your applications so much faster that your app can offer real business benefits
- Workflow - real, structured workflow, tracking work as it flows through a series (possibly very long) of activities performed by people
- Task tracking - allowing simple ad-hoc tasks to be created, delivered to users and tracked through time
- Structure - an obvious way of structuring applications where work or activities performed by one or many people fit together really easily
- Notification - configuration by users of how they want to be informed about work targeted at them
- Search - ensuring that work you create can be found
- Storage - of data, documents and related information
- UI - yeah, you don't necessarily want to have to build all the stuff that's been done before, just build on it
- Security - authentication, authorization, roles, audit, user and password management, etc
A post from the Improving It blog
Tuesday, May 25, 2010
I am a client, not a case folder
Over on Redux, Tom Shepherd talks about Case Management, and how the WfMC (Workflow Management Coalition for people outside the industry) is attempting to put some relevant thoughts around the non-workflow aspects of business processes. There have been many attempts at defining what Case Management is, and I don't care to write yet another one - I've blogged enough times before and frankly nobody cared then either!.
An important point for case management is the case folder. Okay, so this is the core differentiation of the product that Tom manages, and what allows it to call itself a case mysanagement product, rather than an imaging and workflow (document-centric BPM, in industry lingo) product. Its a great product - from a consulting side, I managed the implementation of an insurance underwriting and policy management solution based on it in under three months with just a few pains and late nights along the way. But aside from the product, is the case folder concept really anything special?
The problem for all product vendors is that they need a name for each feature of their product. Especially with business process management, the business problems that you can solve with a product are often so broad and unrelated that trying to give a piece of functionality a name that is meaningful to a business person just pigeon-holes it into one industry. That is the problem with the case folder - it is meaningless to a business person, but its virtually impossible to find a name that is more useful.
I've seen case folder concepts from multiple software vendors - hell, Consected has its own take on the concept (though it borrows none of the intellectual property from Tom's product, or the Tower/Vignette/OpenText product I worked with previously, before random corporate organizations with no better way of generating income start trying to make my life miserable). The approach I take though is this: to assume nothing about the case folder up front, beyond the fact that it is a way of representing business information or entities (a client, an insurance claim, a 'know your customer' (KYC) bank application review, an invoice, an employee, an account, a securities trade). A 'case folder' may or may not have structured database-style information. It may or may not have documents associated with it. It may or may not capture comments or discussions from users. It may or may not sit inside or contain workflows. It may or may not have checkbox tasks, deadlines or whatever. It may or may not be related to other business entities.
Most businesses don't get what a case folder is. Trying to beat them over the head to understand the term, just to make it easier for vendors to sell them software is not really the best approach (in my opinion). If we sell solutions, we conveniently forget the functionality and buzzwords of our software, and instead pick up the needs and buzzwords of the industry we are working with.
So, I agree that information, processes and 'case folders' must work together sometimes, standalone sometime, and not exist at all many times. The name and the functionality of a particular vendor's manila folder approach to organizing information does not interest me or the business I'm working with. As a business user, what matters to me is the 'something' I'm working with. Businesses benefit from focusing on their customers, as much as software vendors do, and helping them do that by putting a 'client' not a 'case folder' in front of users is a huge benefit in a solution.
A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com
Monday, May 24, 2010
Despite Twitter, email is still where we communicate
I have a love-hate relationship with email. For tracking work and tasks to be performed, especially in common workflows, email sucks. For communicating with people, the 'offline' nature of email is perfect, since you can send a message and that message will sit and wait in the recipient's inbox until they get a chance to read it. At the other end of the spectrum, Twitter and Facebook feeds just can't claim that: the messages are so transient that they are more like watching TV or listening to the radio, so if you weren't staring at the screen when a post came through, it is likely you'll never know about it.
So my renewed love of email (over social networks, at least) was given a little spark by the news that Constant Contact (don't claim you have never received a newsletter or event invitation from a company using them, because I won't believe you!) acquired Nutshell mail. Why is this interesting to me, or you? Well, quite honestly Twitter and Facebook really start to stress me out when work/life balance skews itself in the 'work' direction. I want to follow what is going on in the network of my friends, associates and the companies I follow, but keeping my head in an application like TweetDeck is unreasonable and a terrible distraction. So the idea of getting a notification email summarizing everything that has happened in my social network world, that sits there until I'm ready to decompress a little and read it, seems like a great idea. Finally, there is a better chance that I will not miss the last minute wedding announcement from a certain friend the far side of the world (you know who you are...), and that I will not miss another VIP announcement related to a local event that my small business is sponsoring. This is what Nutshell mail can offer, a nice summary of what is going on in your online social world, in a consumable email, ready to read when you are ready to read it.
So I still think that email sucks for work that people do in offices that is routine and repeatable: HR recruitTell him its about self-promoing; employee onboarding; travel expense claims; account payable and invoice tracking; new customer account opening; and so on. If you do these types of work regularly, you don't want the tasks getting lost in your email inbox, the same way as you don't want to have to stare at your Twitter and Facebook feeds all day long to know what is happening that affects your business or makes your sales efforts generate more leads. Email is great for less distracting communication, since it isn't just the Twitter equivalent of a crowd of people standing in a room shouting and waving 'HEY, LOOK AT ME!'.
I'll be interested to see where Constant Contact takes Nutshell Mail. It seems like a great addition, as it puts important messages for you where they should be: in your inbox. This ties in really nicely with the process improvement work I do with companies, where we work to free up employee's email inboxes by taking the routine work out of them, leaving the inbox to do what it does best: hold messages you need to know about but can deal with later.
A post from the Improving It blog
Edit ... OK. So the scoop is I'm married to a senior-ish person at CTCT. I'm not being paid for this blog post (the obvious pay-back is no more than you'd expect - and a whole pile of chores to complete at the weekend). And if you have read my blog before you'll know that this post is as relevant to the constant information sharing (and subsequent self-promotion) that is a blog such as mine. There you go - official cya declaration done. Oh, and the second declaration is that as much as I enjoy the concept of Facebook and Twitter, they really do stress me out. But please do follow me anyway at http://twitter.com/consected
Cheers, Phil
Friday, May 21, 2010
Paper reports keep everybody else in business
- Generates on average 200 paper reports each night (including the weekly and monthly runs of some special reports).
- 5000 pages are printed at the print bureau nightly
- The print bureau charges the firm $10k to print and courier the reports to Firm A HQ
- A full-time employee organizes the reports and delivers them to individual desks, shredding any reports that are unassigned
- 200 pages are printed directly in Firm A HQ
- 100 pages are scanned at firm HQ and emailed to different offices, taking an hour of one administrator's day
- Individual employees work with the reports, ranging in activity from: picking it up and shredding it immediately, to examining it line by line and noting the review performed in pencil for later audit.
- Many draws of filing cabinets are filled to capacity
- A box of reports per night are made available for off-site storage, eventually
