Tuesday, June 29, 2010

If you have ever followed a Group on LinkedIn, you'll recognize that most of the discussions fail to pick up steam. A few people drop by, lob in their short comment to try and get noticed, then step away again. The discussion Why do you think BPM could not take off like ERP or CRM? apparently caught some attention. Its up at 80 comments, the vast majority well thought out and directed from individual opinions that are not just shameless plugs selling a product. Beyond its size, the discussion is interesting since it highlights the follow points:

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

For most businesses, there is room to organize information, processes and people better. There is a need to keep client files electronically, relying less on paper and making savings on printing, copying,filing and offsite storage. There is a need to be able to simplify and control repeatable business processes, so that they take less time and less brain-power to complete, reducing the cost and number of errors. And there is a need to make it easier to track work that is not necessarily repeatable, but is easy to lose inside email inboxes. In short, with well thought out BPM, businesses can do more work, more accurately, with fewer errors, happier customers at a lower total cost.

This is what my kind of business process management would solve. Either the guy holding the purse strings gets the value of what is offered, or he moves on. No need for constant bickering between vendors that their spin on a product is better. The software and methodology says what it will do, without a vast education of needs. I like that form of business process management.

Wednesday, June 23, 2010

Just a couple of weeks back I talked about how you can work backwards from corporate records to get a clearer view of the high-level business processes being run in an organization. The approach here basically was saying that if you can identify the records of business transactions in an organization (and in any fairly mature organization this should be relatively easy), you can step backwards through the processes that created them, avoiding all the rat-holes and exceptions that muddy the picture. This is great, but what happens when you don't have a clear view of where records are created? Well, this is where I'm going to aim for a quick win and get "two for one". And, yes there is a reason for the incredible animated image.

As you are reading this, bear in mind that I have the benefit of working with a financial services firm as my client of the moment. This tends to make things easier for me, since the regulators have always insisted on a decent structure for record keeping that means I'm not working from a completely blank page when trying to identify records. But still it is true that many firms don't have a corporate file structure that shows a heat-map of where records are produced and what they contain. So I can walk around the building talking to the owners of the business functions, or I can consider an alternative starting point. As much as I love talking to people, many of them have real jobs to do.

This is where the org chart kicks in. Yes, many employees wonder why it is so important for companies to build that 'tree' of people, beyond inflating the managerial ego. In my case, the org chart is an incredible tool to help me get started understanding not only where business functions are performed, but it gives me therefore the starting place to look for filed records and the business processes that created them. Its like the computer generated fractal pictures (the crazy animation) that follows natural effects. You jump to the major focal points, then drill down in a never ending fashion into the details of the business and the records that are produced. If I was really detailed-oriented, this type of work could keep me occupied for years. Even though I'm not, there is a certain natural order to things that yet another holistic view of the organization can provide. Perhaps the organizational studies will not result in a beautiful image, but there should be a nice structure that helps keep things organized.

Monday, June 21, 2010

You've heard the phrase "Knowledge is Power". There seems to be a human character trait that says by keeping documents close at hand, preferably within steps of my office chair, I am more powerful. Filing cabinets for individuals, and "working copies" of client files are everywhere in offices. Take that easy access to information away and people fight back. You are removing some of their ability to hoard information, all of which is a duplicate of something available elsewhere, but it exposes a frailty that leaves them uncomfortable. "What if somebody else has the file the one time in a million I actually need it?", or, "What if I'm caught off-guard, a client calls and I don't have their information to hand?". This is just one of the ways employees resist the introduction of enterprise content management (ECM), case management and business process management (BPM) solutions that try to limit the amount of paper moving and filed in the organization.

I have had the 'exciting' opportunity to spend some time working with lawyers over the last couple of years. From helping smooth immigration paperwork to cleaning up company contracts, it doesn't seem to matter who I work with I experience the same thing: paper. When it comes to the workings of a law office, I am frustrated by the apparent waste of paper (and the subsequent charges for photocopying applied to my account). When I think about it though, the issue is obvious with a lawyer because the multiple copies of documents happens typically right in front of you, while you're sitting there in the office. Although not so obvious, regular offices experience the same issue. Most of us I'm sure have seen the pervasive footer on emails, "Do you really need to print this email?". There is no way to know how much paper is wasted on unnecessary printing and copying in offices, because it is not charged per page.

For the 14 years I've been working with electronic imaging technologies, I've always encountered the concern that it is hard to work with text on a screen, but early on companies worked hard to limit the concerns of employees. In the UK at least, as a user of a screen and keyboard, an employer was required to ensure your working area was set up to avoid discomfort and to improve your posture. Companies investing in document imaging put in place minimum specifications for screens, and usability requirements for applications to make it easier and more productive for people to work without paper. These lucky people of the 90's working with electronic documents had it good.

Now when I visit clients, it is not unusual to see LCD monitors in every cube. Screen technology has progressed to a level where great quality should be available on every desk, but we have instilled the concept in the heads of employees that it is hard to work with documents on screen. Why, beyond an aversion to change, does this persist?

I think that the problem comes not from the screen, but from the documents. Many regular people think of Word documents when reading on screen. Word is an editor, not a document viewer, and it does a terrible job of making documents easy to read. People remember this. Adobe Viewer for PDFs presents nicely prepared documents beautifully. But so often we end up reading marketing brochures prepared in multiple columns for glossy printing, needing to scroll around with every paragraph read, that we learn to hate it. The same with the trend to scan documents to PDF. The viewer does a generally poor job of making scanned documents appear attractive and clean.

My feeling is that companies wanting to become more paperless need to concentrate on the underlying issues of the documents they try and have people use. If your scanned documents look ugly on screen, people won't want to use them. If you force people to use daily reports by scrolling around left, right, up and down, they complain of RSI and general reduced performance. If you archive Word documents for constant reference and record-keeping you're asking for trouble in so many ways. As an aside, I saw a Word document archived in a large government agency that was unreadable, because the pretty font used by individuals was no longer available. This applied to thousands of documents.

Maybe it is time for companies to focus on how they can make the information that gives people the power to make good decisions not only available, but easy to use. This isn't just document scanning. Good application design and recognizing that people want to organize information their way will help people work better. Companies need to focus their investments in document management, business process management, and case management on making users actually want to use the new applications, since this desire to use the application is so important to getting paper off everybody's desk.

Wednesday, June 16, 2010

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...

Wednesday, June 09, 2010

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.

Wednesday, June 02, 2010

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.