,.

Archive for the ‘Business Process’ Category

Integration is so easy, IT can’t do it!

Thursday, August 5th, 2010

I stumbled across Mike Vizard’s post, Managing Borderless Applications.  Mike’s contention is that IT is facing a support headache caused by integration that they don’t know about.  Integration carried out by business users using web based tools integrating web based applications.  Integrations and automations that will ultimately become mission critical, and then break, at which point the business will stare over at IT and ask for help.  And, as web apps race for ubiquity, this problem will inevitably increase.

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.

Business Ops should have more control

Wednesday, May 19th, 2010

Do you remember the days of early websites?  Come on you don’t have to be that old.  I wrote a paper for my Masters in 1997 that recommended that banks, for example, ought to have more transactional websites even though, at the time, there was not a huge business case for the investment.  Hard to believe that was only 13 years ago.

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.

Why IT and the business don’t trust each other

Wednesday, March 24th, 2010

Ask any business operations head what they think of their IT department and they will moan about IT being too slow, not connected enough to business strategy, too focussed on its own goals, too expensive, not addressing everyday business needs etc.

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.

Operational Agility

Wednesday, July 9th, 2008

My previous post mentioned that Blue Prism’s new message is based on operational agility, so I thought I better explain what that means.

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.

The difference between IT specification and business requirements

Thursday, October 25th, 2007

I had a rude awakening this week when visiting an important customer.  We were trying to persuade this customer to buy more Blue Prism software to automate new processes, and early in the meeting we were stunned to hear a really negative reaction.  “Of course, I am really keen to do some more work with your product but we will have to persuade the business users who are very negative about your current solution”.

(more…)

BPM versus the people

Thursday, October 11th, 2007

I read Ann All’s post about putting a human face on BPM this morning which is understandably pro-BPM, but I started to get confused about whether there is a move towards automating everything, bringing people back into processes to enable process improvement, or there is just a “horses for courses” thing going on.

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.

Banking on process improvement

Friday, September 7th, 2007

It is becoming ever apparent that Financial Services companies, and in particular banks, in the UK are adopting process improvement methodologies from the manufacturing sector.

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?

(more…)

UK Banks are not as evil as you might think

Tuesday, August 7th, 2007

When you work in an industry as highly regulated as financial services (and I have worked there both directly, and indirectly) you come to expect the odd scandal.  Pensions mis-selling, current account charges, ATM usage fees are just a handful of the recent uproars from financial services customers in the UK.

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.

(more…)

“New” mashup platforms taking over the enterprise? Not yet.

Monday, July 23rd, 2007

Wow, Dion Hinchcliffe at ZDNet has looked at the enterprise mashup space in much more depth than I did a couple of months ago.

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:

(more…)

Business process centric architecture

Monday, July 23rd, 2007

I am feeling quite pleased with myself for managing to get the word thrice into my last post.  Such a fine word don’t you think?

This post comes to you with the word analyst.  A dirty word in some parts of the blogosphere.

I have never paid an industry analyst but I am thinking of doing so.  Not to write some white paper promoting my company’s solutions and position us positively against our competitors.  I can write that free of charge and just as many potential customers will ignore it as if an analyst had written it.

What I actually want to achieve is to look at a wider industry trend.  I want to test whether today’s view of IT architecture is really becoming business process focussed.

(more…)