Your 'Systems Group' is the reason you business teams (are) disintegrated

One of the big selling points of business process management (BPM) is the way it can provide order to the activities of disparate groups of workers so they can work better and more efficiently. To achieve this, you have to answer the big question 'how did groups that have to work together so closely end up so separated?'. In parts of a businesses that handle customer requests and new accounts (such as insurance underwriting or claims, banking account management, credit card disputes, telco and utilities customer service), it is typical to see separate systems forcing the business groups apart. When groups of users have to operate systems that don't work the same, don't share data and require swivel-chair integration, the way they work together as teams disintegrates.

It is the 'Systems Group' (or groups with other vague technical-ish names) that runs the line of business systems. And it is these owners that perpetuate the separation of business teams by failing to integrate their systems. So it seems obvious where to place the blame - the 'Systems Group'. But it is not their fault.

Repeated observation has shown me that the systems group are experts in what they do: they understand their systems better than anyone. They understand how the systems work, how to keep them working, and how to work around their faults. Because of this they are also often the designers of new 'applications' that fill a need of the business, in the form of Access databases or enormous Excel macros, that further separate and distinguish the roles of individual business users. And they are rarely experts in integration, largely due to the time and patience they must expend on nursing their current systems through another painful situation.

I have a recent example on a project I was leading - I had to teach various highly experienced technical people in the system group about XML, what it was, what it looked like, why it was different from EDI, and how a BPM system could use it to capture data from other systems (including that big Excel spreadsheet that is core to the business). XML is really not that new a concept or technology, but the guys had not had the opportunity to understand it.

With a limited knowledge of the available technologies, and even more limited time to burn, an organization's 'systems group' is not the team to apply to even basic integration tasks. If it was, the integration would have been done already.

So who should do targeted integration associated with BPM projects? That consulting team you have onsite already to build the new BPM solution may cost more than your internal team per hour, and may not be pure software developers, but it is likely that they understand integration mechanisms better than most. And if they represent a decent boutique firm, even if they can't build the integrations themselves they should have access to a team that can. Although it may cost a little more overall, the integration will get done, which is more than can be said for the situation many companies find themselves in currently.

The 'Systems Group' is the reason that your business teams (are) disintegrated. But it is not their fault. So help them improve, the same as you are trying to do with your business processes.

A post from the Improving It blog

Download the podcast of this blog post