Ignorance can be bliss. Knowledge can be dangerous. You have been warned!
Several years ago, I remember reading about a top business executive who commented on the arrogance of IT. Paraphrasing his statement, “IT is the only function that is so arrogant that IT professionals insist their business clients learn and speak the language of IT.” Of course, IT professionals don’t try to teach programming to the non-IT folks. So where does the arrogance of IT lie?
Consider that the IT-business divide is difficult to bridge precisely because IT keeps thinking of “special technical solutions” for what are essentially ‘end-to-end’ problems in business processes. Rules can’t be managed? Use a BRMS. Data can’t be managed? Use EDM. You don’t know what the data means? Use metadata. You don’t know what happened? Use BI. Need to manage customers and prospects? Use CRM. Can’t find all your documents? Use ECM. Need to comply with SOX? Buy some shrink-wrapped panacea.
But business users don’t think or operate this way. They don’t compartmentalize their minds while running their company. Only IT forces them to do so. Let us say a business executive wakes up one day and says, “I think we have a problem with our loan processing. I hear anecdotes about our competition undercutting us. I have to find out what the data actually shows. Are all our financial products suffering equally? Do we have similar issues in Europe? I wonder how well our underwriting rules perform. In fact, where are our underwriting policy documents? Is everyone using the same policy document? I know we made some changes, so maybe there are different versions floating about. I must solve this problem.”
Unfortunately, the moment this executive encounters an IT manager in the corridor, he says, “We have a problem. We can’t locate the data. We are struggling with dropping loan revenues. Can you get me some reports?”
The IT manager says, “Sure, what you need is a BI solution.”
The executive then encounters an IT program manager. “I am afraid our salespeople are using different rate sheets. In fact, I think even our underwriters are working with different versions of the underwriting policy. Everywhere, it is the same problem. How do we fix this?”
The program manager says, “There are ways to manage our enterprise content. There are software applications called ECM suites. We should buy one of those. I’ll start the evaluation process right away.”
Executives don’t verbalize their internal problem definitions in front of IT, partly because they have been conditioned to ‘simplify’ requirements, partly because they don't think gets it.
A few years later, this company is saddled with a BI application, an ECM suite, a CRM package, and a bunch of other applications. What’s more, there is now a huge IT staff maintaining all those applications. However, the executive is no closer to solving the original problem that brought on all this investment. To crack that problem, this hapless executive (or their equally frustrated employees) must now run to all of the above applications and try to make sense of them. Some IT people don’t understand this, because they never face those problems. Of course, if pushed, they will profess an intellectual appreciation, but it is not part of their emotions or their DNA. Those that do get it are bogged down administering the complexity of the existing systems that were bequeathed to them.
This—the forced segmentation or compartmentalization of requirements that business users employ in talking to IT—is the subtle sense in which IT has indoctrinated their business colleagues into adopting IT-speak. Why else would someone in the business walk up to a developer and ask for one additional field to be programmed into their CRM screen?
If IT professionals actually sit in the hot seat running a non-IT business for a few months, their outlook would change. They might just build a business architecture platform that actually works, even if it runs on paper.
(It’s not too late to stop reading!)
Fortunately, whether through design or happenstance, we do have such a business architecture platform today. It is called BPM. It is the one platform that ties all these functional capabilities together and gives them a complete business context. How it accomplishes all this, and how it should co-exist or coordinate with these compartmentalized solutions and legacy systems (which do have specialized uses), are deeper issues.
In the past, ignorance and lack of technological sophistication were good excuses for proliferating the 'arrogant' attitude. But if you read this far, despite my warning, you now know about BPM. You have no excuse for not adopting it. Sorry!
BPM isn’t just one more application package. It is not BRMS. It is not ECM. It is not BI. It is not CRM. It is not ERP. IT doesn't matter. As Smith and Fingar say, "Business processes do."
And for that, let us be thankful.
(To learn more about what BPM is and what it does, sign up for a BPM Master Class!)