Core processes automated long ago like billing, statements, payment decisions, customer letters etc have pretty much given the enterprise IT industry its meat and gravy for the last 50 years. More recently, because many of the solutions implemented were centred on accounts, or customers, or staff, or products, there was a realisation that the one dimension that had been forgotten was process. And so was born workflow and subsequently BPMS. Process-centric platforms that finally acknowledged that the efficiency of your back office could be used to differentiate yourself from your competitors, despite the common use of industry standard back end systems such as ERP (and the ubiquity of SAP for example).

But even BPMS has limits. The speed of business these days is driven by the Twitter generation. Customers demand instantaneous responses; competitors launch new products on a sixpence; even regulators expect customer refunds to be done urgently. Consider three common scenarios where processes typically do NOT get automated:

1. Temporary or one-off processes. Correcting processing errors, billing recalcs, customer compensation etc. These are often processes where an automated solution is needed in days, not months.
2. Business as usual (BAU) processes where there is no economic case to automate because there is only a small handful of people doing the process now.
3. Processes where there is a core IT solution coming but it is, say, 18 months away. Business Ops may need a “pontoon bridge” to get some portion of the benefits right now to manage the business until the core solution is delivered.

The truth is that in every large organisation there is a “long tail” of automation represented by a 500 item (or more) change list. BPMS and traditional core IT automation never has the resources, the priority, or the budget to address all these requirements so they simply remain unfulfilled. This results in Business Ops having to resort to inefficient ways of getting stuff done – outsourcing, off-shoring and “Rogue IT” to name but three.

Forrester has recently started talking about Empowered Business Technology as a “mega-trend”.  Other commentators are observing that IT needs to become a trusted advisor rather than a provider of hardware and software which is ever more available to buy (and be managed from) outside the organisation.  Google around by all means but for a concise and insightful piece read Todd Biske in a post I have referenced previously (thereby warranting its quality). This trend is happening and it is not just Cloud, SaaS and Social Media that is driving it. There are tools around that can deliver real business value to your Operations teams, without being held within the usual cost and time constraints of a core IT program.

So how do we adapt to the faster business environment, and address the long tail? In short, the answer is self-service. From petrol pumps, through supermarkets and ATMs, to online shopping and banking, today’s consumer expects to be able to do it for themselves. And they can….except, to their frustration, when they come to work.

The rise of Business Ops is unstoppable. Smart IT functions are already empowering their business users with innovative ideas and products. It is the only economic way of addressing the long tail of automation.

It is an interesting conundrum that we spent a lot of time thinking about at Blue Prism.  The reason business users run off and do their own integration, is because IT takes too long to deliver in the context of the speed of business today. So the business gets its solution quickly, but this type of end user computing carries a high risk of failure in the medium term due to lack of documentation, security, maintenance and support.

We realised that end-user integration and process automation, whilst technically possible, needs controlling.  The trick is to find the balance between IT discipline and user freedom and flexibility.

We found that this works best if IT sets out a corridor of governance within which the business users can operate.  Some of the components of this approach need to be built into the integration/automation technology.  Some need to come from a new “light touch” governance methodology that both IT and the business subscribe to.

The business gets an agile response to rapidly changing business requirements, but IT knows about the computing initiatives and helps the business to deliver them within a supported environment.

Not easy to resolve, but worth the effort for the competitive advantage that comes from agile operations.

In those days, if your organisation was lucky enough to have a website, you were starting to gain competitive advantage.  Especially if you could keep it up to date more quickly than your competitors.

However, that depended on your IT dept and an army of HTML programmers, who wanted a specification, a design document, a test environment, methodology, design authority, sign off procedures etc etc.

Then someone invented Content Management Systems.  The purpose of a CMS was to enable the business to make their own website changes in real time but, and this is a crucial but, within a corridor of governance enabled by the IT dept.  So it was possible to change the text, but not corrupt customer data.  It was possible to change pictures, but not corporate design rules.  It was possible to change the database contents, but not the database itself.  So business users can do a whole load of useful stuff without the risk of bringing down the site.

Of course, other governance is required.  Someone still needs to take responsibility for the content that, in an instant, is representing your organisation around the globe.  But without this level of flexibility how can your company compete with the speed of business today?

This type of flexibility (I prefer to think of it as agility) is now finding its way into the operational world.  Giving business ops a way of doing their own process integration, orchestration and execution for example is freeing the business to react to the daily challenges of the changing world.  At Blue Prism we call it Business Led Computing.  It is a growing movement.  People are used to being able to do their own computing at home.  The next big thing in corporate computing might just be self serve.

In truth, most experienced business heads are a bit more pragmatic than that.  They understand the IT side of the argument.  The importance of data integrity and security, system stability, centralised procurement of technology, coherent architectural strategy.

Whilst these are all very plausible and necessary requirements, the fact is that the speed of modern business requires operational responses measured in hours and days, rather than the months and years associated with traditional IT projects.

IT people are not dumb.  They recognised this ages ago.  Initiatives like SOA and BPMS are designed to provide business flexibility, speed of response, agility.  But these are major IT programmes in themselves and in business eyes can take too long to deliver even small benefits.  They can also be disproportionately costly, so the economic case only makes sense for major business requirements.  What about the 750 item (and growing) change list?

The business is coming under ever greater pressure to reduce headcount so the old option of simply recruiting a few more operational staff is no longer available.

The result is that well intentioned business ops people create their own solutions under the guise of “end user computing” but more likely referred to by EAs as ”Rogue IT”.  Spreadsheets, local databases, emulator macros, even amateur VB programming.  All delivered without any control, governance or thought for future maintenance.  So, guess who gets called in to fix a “mission critical” system when the creators have moved on?

No wonder IT doesn’t trust the business to do IT.

The last thing IT needs is maverick business users creating their own solutions, so maybe they clamp down on end user computing, causing further frustration in the business.  A spiralling circle of distrust is normally masked by a resigned acceptance of “that’s just the way things are”.

Random quote I’ve heard from an operational head “IT have slowed the organisation down to a pace where we can’t react to business opportunities and it takes an age to get anything done”.

Random quote I’ve heard from an EA “Business Ops are continually doing their own skunkworks initiatives with no regard to data protection laws, system resilience, disaster recovery or central IT strategy and yet when they fall flat on their face, it becomes our problem to fix”.

As an external vendor interacting with business and IT, I can genuinely see both sides of this argument.  I also think there are ways of reconciling the two views.  More in a later post.

In today’s complex business world, front and back office customer service operations have to contend with a non-stop barrage of change.  Whereas traditional IT projects deliver systems against timescales measured in years, human beings on the front line have to react to events happening right now, today.

The long term IT strategy is generally based on what is known today with some future forecast factored in.  The business users, though, have little more idea of what is coming tomorrow than the poor EA faced with a blank sheet of paper.  Of course, the major systems still need to exist, CRM, core operational software, billing and collections etc.  It’s just that when these systems are conceived they have to be designed with a “best guess” of future requirements and this results in range of functions available to the front line that is then frozen in time.

The problem with this approach is that operational staff might need to do something new.  A merger or acquisition creates process duplication; a new product launch requires operational support with sketchy forecasts of process volumes; management want to push a certain product whilst sunsetting another; a processing error needs quickly reversing.

One of our customers had a processing problem caused by a mail strike.  Several thousand accounts were debited with a late payment penalty whilst the cheques really were “in the post”.  A decision was taken to refund these payments (very noble – glad I am a customer of this organisation!).  When the customer accounting system was designed, nobody thought that there might be a bulk requirement to selectively cancel debits applied to a range of accounts.  The traditional way of solving this problem is to take a few call centre agents off the phones for a few weeks to process these refunds manually.  With Blue Prism software the team was able to quickly piece together a new automated process flow that required no human involvement and the process was completed in one day.

Here’s the science bit.  Blue Prism retrospectively componentises the existing and legacy apps and allows you to re-purpose them into new operational scenarios and business processes.  Using point and click integration techniques (no code required), new methods can be clicked together into a process flow using a simple flowchart interface.  This gives operational staff the means to manage and react to short term change and therefore operational agility is enhanced.

Sounds like similar objectives to BPM/SOA?  Possibly some.  Except we are talking about delivery in days and weeks, not months and years.  I’ll go into more detail on this in a later post.

Looking back through our fault reports there was barely an issue raised in the last few months.  The IT people in charge of day to day running were reporting that everything was fine and “to specification”.  Yet the business users were reporting too many exceptions, not enough capacity, and functional issues.

Since our product is designed to be flexible and offer the agility to adapt quickly to new business requirements, this was highly embarrassing.

Turns out that the problem is that the business requirements have moved on, some of the people have changed who did not understand why some of the original design decisions were made, and when the business users asked the IT dept why the system didn’t do exactly as they wanted, they were told it met specification ,and that exceptions and responses were within SLAs.

The lesson I learned from this is to understand who your real customers are.  In enterprise sized companies this is often extremely difficult, but talking to the business users of the solution is always a good starting point.

One of the advantages a vendor solution has over an internally built one, is that the vendor is normally a specialist in a specific area and brings the benefit of working with many other organisations, hopefully with the expertise gained having been internalised into the software product.  Here we fell into a hole on this occasion.

I am so embarrassed, that I have scheduled a free review by one of our consultants, to reassess what the current problems are and what options there are for improvement, a redrafting of the business requirements as it were, not just in relation to our product, but the whole solution.  Then maybe we can get the IT spec changed to match?  And maybe that spec can include some flexibility to meet changing business requirements of the future – D’Oh!

I am definitely in the latter camp.  BPM is about managing processes.  If there is a need for consistency and accuracy, but the process cannot be automated then it can at least be managed, and people undertaking the process can be guided to the right actions.  This can be a powerful way of ensuring consistent customer service, or to meet compliance requirements for example.

But what if the process is rules based?  Why does that need any management?  Surely it just needs automating?  Well, perhaps this is where the process improvement comes in.  Even automated processes need to be monitored and can (and should) be improved.  At a minimum there is an ongoing requirement to change automated processes to meet new laws, regulations, marketing initiatives etc and this means that the automated processes need to be both visible and flexible.

So where does this leave the people then?  Just managing some super BPM dashboard like a modern day Joe 90?

Of course people have a role to play in business processes.  The example mentioned in Ann’s article was the new hire process.  I don’t believe the world is ready to see this fully automated yet, since there is always a judgmental element to the process on both sides and this necessitates human contact.  However, in the UK and US at least, there are detailed and highly complex laws relating to recruitment and selection to ensure no discrimination occurs, for example.  This means the process lends itself to being managed by a BPM system.

Other processes are simpler and rules based.  For example, lost and stolen card blocks.  When a bank receives notice that a customer has had their bank cards stolen, a clerk has to trawl round the various systems blocking the various cards.  Accuracy is essential here to prevent fraudulent use of the cards, but the process is entirely rules based with no room for judgment.  This is a process that should be automated.

So horses for business process courses?  People are good at negotiation and expert judgment.  Computers are good at munching through rules based processes.  I’ve seen nothing yet to persuade me that the implicit negatives of those two statements are any less true.

One bank that I know well, specifically refers to its back office as “the factory”.  I was at another bank last week meeting the Director of Business Process Re-engineering (BPR).  The very appointment of this title at such a high level is an indication of the importance of process excellence in the financial sector.

Just about every UK bank I am aware of has some capability based around Lean/Six Sigma or similar flavour and many of the recruits are coming from manufacturing, retail, and other service companies.

There are big gains to be made since (although the banks wouldn’t like to admit it) they are horribly inefficient.  A further concern is the cost/income ratio.  Most senior executives have some target set around this ratio.  Major investments in technology can take years to pay back.  This increases costs in the short term and brings any benefits way down the line, which adversely affects the cost/income ratio in the short term.  Call me cynical but most senior execs will have moved on by that point, so they will not see the benefits in their bonus payments.  So there is a degree of short-termism and BPR fits the bill because it is about making low cost investments in continuous improvement.

I would argue that this actually benefits both the short and the long term, and you have certainly heard me argue before in favour of incremental rather than big bang projects for a whole range of reasons.

So it is clear to see why they are doing it.  What about how?

Most process improvement work starts by reducing defects.  Removing unnecessary steps in the process, reducing rework, and minimising non-value adding activity are obvious routes to achieving this.

My area of interest is in clerical processes.  When looking at the future state of such a process, once streamlined, there are frequently technical constraints on making the improvements.  These are usually caused by a lack of systems integration.  Bank staff are bound by manual processes that are demeaning, unnecessary and costly.

But if the option of major IT investment is ruled out, are there lower cost options?  Perhaps something that can deliver payback within the current budget cycle thereby keeping the cost/income ratio healthy?

Automating at a local level makes sense in this regard.  There are various ways of achieving this using UI integration, for example.  This serves a local purpose, is not a strategic IT investment and can deliver super quick results at low cost.  Most modern applications are easily interfaced with.  In designing such a system you will of course need to consider scalability, security, ease of use, ability to make constant change to the processes, code maintenance, technical resources needed.

Or you could use a product with all these features inherent.  Blue Prism has published a free white paper on Lean/Six Sigma and clerical process automation if you are interested further.

The latest decent sized revolt has been over “unfair” bank charges imposed on customers whose accounts have gone beyond their borrowing limits.

There is a danger of victimless crime syndrome here.  People who say “the Government should pay for our rubbish to be recycled” conveniently ignoring the fact that the Government is funded by us, the taxpayers.  People who make bogus insurance claims believing that “the insurance company has loads of cash and can afford it”, conveniently ignoring the fact that if everyone took that view, then the insurance industry would implode, meanwhile the do-gooders suffer ever increasing premiums.

Most people look after their bank accounts and service their borrowing requirements by agreement with their bank.  When a customer breaks that agreement, then it is fair for the bank to apply some (pre-agreed) penalties.  This represents a contribution to the cost of servicing a delinquent account and collecting/recovering the amounts owed.  If these fees are not charged, then the bank has to cover those costs somewhere.  I’ve seen estimates that the processing cost is as low as £2.50.  Don’t make me laugh!  When I worked at Bradford & Bingley in the 1980’s the cost of sending a single letter to a customer was measured at £15 and this is just one part of the process.  The £2.50 estimate conveniently forgets the costs of staff, premises, technology, insurance, heat, light (I could go on).  Even if technology has brought down costs (and I am not 100% convinced), the £2.50 is a mile away from realism.

Perhaps everyone would be happy if we went back to fee based banking (remember when you had bank charges for every debit and credit item on your statement)?

By the way, before anyone writes in and points out how unfairly they have been treated, I am aware that there are cases where the bank has not kept to its side of the bargain and charged fees that were not pre-agreed, or has made charges in error.  In these cases, the bank should (and will) pay up.  However, the general principle I am arguing for is that good customers should get a better deal than bad customers.  This seems to work quite satisfactorily in other industries (retail, general insurance, telecoms etc), why not banking?

(Retail) Banking is a highly competitive industry and is working on thinner and thinner margins, in the UK at least.  The largest part of most banks’ profits are coming from investment banking, where times are currently very good but will not always be on the top of the cycle.  So if retail banks are not allowed to collect fees from “bad” customers, then they will have to collect them from “good” customers.  Or do they?

Maybe we are missing a trick here.  Whilst it is true that retail banking margins are getting tighter, it is more true that banks are horribly inefficient.  You wouldn’t believe some of the business processes I’ve seen on my travels.  They provide neither good, timely service to the customer, nor low enough processing costs to make some products profitable for the banks.

The smart banks are addressing this issue of processing costs with technology (not offshoring) and using this as a lever to increase margins.  In an environment with ever more revolting consumers, this may be the sweet spot leading to the nirvana of profitable banking and happy customers.

He raises some interesting issues, though, about why some of these tools are struggling to gain acceptance in the enterprise.  I believe that there are some unique features that need to be addressed to meet enterprise requirements:

1.  Security.  Mashups are playing with corporate and often customer data.  This is why SaaS (software as a service) may not be a suitable model.

2.  Scalability. This sounds really obvious but enterprises normally have massive amounts of data and massive amounts of data processing.  Any mash up tool must scale.

3.  Legacy applications.  It not just about web apps.  Mashup tools need to get data from a wide variety of software architectures:  Client server, mainframe, Java, Windows etc.

4.  Robust error handling.  When something goes wrong something needs to be fixed, or someone needs to know about it.  This is a layer that is not obviously apparent in many of the current offerings.

5.  User experience.  There is no point in a mashup tool if a business person can’t use it.  If technical resources need to be deployed, or additional code needs to be written then the mashup tool is only of use to the scarcest of resources in the enterprise, the software developer.

6.  The focus on building new GUIs as a mashup has only addressed one small part of the enterprise need.  Most enterprises have back office processes that only require human intervention because of systems integration issues.  No GUI is needed.  The process just needs to be automated end to end.  In call centres, activities post-call prevent the agent taking the next call and would be better handed off to an automated process.

This is why I am still not sure whether our product, Blue Prism Automate is a mashup tool or not to be honest.  The concept came directly from a real enterprise requirement (a retail bank call centre/back office to be precise) and the product has matured and been proven in many live environments for security, scalability, and compliance.  The development has been genuinely customer driven and, now at Version 3 the product has (finally!) addressed the ease of use issue.

But it cannot build a new GUI with, or without widgets.  It merely automates processes or parts of processes.  So it is useless in a back bedroom or even a small business, but the growing customer base contains some of the Europe’s largest companies which is hopefully testimony to its suitability for enterprise use.  Horses for courses I guess.