To me, it's common sense that in order to automate something, we all better understand the current business process. That understanding is sometimes a responsibility that gets delegated to a business analyst or a process modeler. Too often, however, that critical step is brushed or skipped over completely. Then the proverbial Chris Alexander cartoon below comes fact.
"It's great, but this isn't what we wanted" the business person says.
"But it's what you asked for," the IT person says in exasperation.
Maybe it was, maybe it wasn't. The technically elegant solution may give little business value. So what went wrong?
For a while now, my passion has been on how those of us in IT can step back from the sandbox of cool technology toys and figure out what will really work to solve business challenges.
We sometimes expect the "business folks" to be separate and distinct from those crazy "IT folks." IT is part of the business. It shouldn't be off in the corner. IT needs to be intimately involved with both the strategic and tactical operations of the business. Some companies have gone as far as to define a best practice where programmers physically work inside the department for which they typically write software. For example, you might have programmers who locate in the Finance department, or in Customer Service. The programmer still reports to the IT CIO/CTO's organizational structure so they get the technical support they need, but they are involved in the business departmental team meetings and other activities. They even participate in departmental parties. They sit with the customer support reps on the phones, and may even take customer service calls.
For many IT departments, that immersion just isn't possible because of the wide range of required skills and supported departments. But the principle still holds true. Only if you walk in someone’s shoes can you appreciate their pain.
But when it comes down to building the systems, we hit “The Rub:” We often find that the business processes (rules) we want to automate aren’t really “rules,” but “suggestions.” We find two departments define things slightly differently. For example, “sales commission” may be defined by Finance as “x percent of sale plus payroll tax.” Sales may calculate it exclusive of payroll tax. The governance team needs to define which is the true business rule. They are called “business rules” for a reason. They should not be left for IT to define.
Documenting those business rule definitions are the job of the Governance Team. There can be many teams; IT Governance, Information Governance, SOA Governance, etc. The bottom line is that governance is not just about adherence to rules and process, but about alignment to the business.
This is also where the Use Case documents are so useful as they capture each scenario in detail for those processes. Only when there is agreement on those use cases and business rules should the software design start.
Business Governance needs to ensure that this alignment is taking place consistently. That communication gap that exists between the “business folks” and “IT folks” has to be addressed. Some of it is just agreeing on a standard lexicon. Yes, many of us in IT are geeks - and that gap can be a stretch for some.
The responsibility lies with the business executives to define a process that makes that alignment possible. Business managers should sit on IT committees and teams that work on technical solutions. Unless the “Business” is driving the change, we’ll continue to have to deal with the glorified tire swing that IT thought was asked for.