A client recently asked us to referee between business and information technology. IT, with concurrence of the CFO—but prior to the arrival of a new sales and marketing management team—had contracted with its vertical ERP software developer to provide an integrated CRM component running off the same database as the ERP app.
There was logic to this decision, however awkward the timing. Sales, marketing and service need real-time access to ERP data for CRM to have much impact. But this ERP system lacks pre-built links (APIs) to outside applications and their respective databases, and integrating a third-party CRM application with the ERP system would be costly and challenging.
Before the ink was even dry on the contract with the ERP developer, along came the new sales and marketing management team—including an individual who’d implemented CRM technology previously and was highly concerned over what CRM functionality this ERP developer could or would provide. And he had reason to be concerned. If the CRM outcome was not what business needed, our client would continue to suffer from dysfunctional sales, marketing and service functions; would be left with ongoing friction (an understatement) between business and IT; and would pour a bundle of money down the drain.
To bring matters to a head, the manager with prior CRM technology experience traveled to see an Alpha version of the new CRM app. He utterly rejected it and proceeded to insist that third-party CRM solutions be considered. And that, in turn, led to an impasse—and our entry into the situation.
So how do you bridge a business-IT knowledge gap like this—where each side, in its opinion, is acting to advance the company’s interests? As is typically the case, we had to first define the common ground that business and IT must share, then encourage constructive behavior from both sides. Then we had to address the three constraints that keep business and IT separated: communication, role definition and metrics.
No round table
Back in the early days of CRM, IT was a castle separated by moat from the remainder of the company (the business side or "business")—with communication between the two sides typically limited to business wrapping messages around stones and tossing them across the moat.
But now the moat has dried up; the alligators have been shipped to gourmet restaurants; and IT’s castle walls have been dismantled by orders of the corporate kings. Now, all that’s separating the two sides is a gaping knowledge gap. But this ethereal gap is proving formidable.
Let’s start with language—as in: Both sides hear each other, but neither understands the other. There are opposing role definitions. IT typically believes that technology should be a strategic driver. But business wants technology pushed to the background—for support. And there’s the rule of numbers, which IT adheres to, versus "fuzzy" measures of accomplishment, which business clings to. What are the costs of not bridging this gap?
Based on our client experiences, the top contenders are operational dysfunction, the pernicious effects of internal conflict and dollars flushed buying technology that doesn’t support business operations.
In this instance, as in almost all other business-IT gap situations, we found the common ground in business process. The workflow component of business process (how work moves from function to function, including to/from customers and suppliers) is virtually synonymous with information flow, which means that business and technology must be in sync. And when we drill down to the work process aspect of business process (how individuals within functions do their work), work process defines application software requirements, which again means that business and technology must be in sync.
But once we joined together our client’s business and IT interests in the business process realm, how would we encourage them to cooperate?
Team approach
Our approach to maximizing cooperation and minimizing friction, which we applied here, is an outgrowth of working in cross-functional teams that include representatives from multiple business disciplines—including IT. By working in team environments, we’re able to keep everyone focused on what’s good for customers first and for the company next—and not on their individual silos. Plus, we’re able to create behavior standards that mitigate unconstructive behavior by group members.
To keep all communication "on the table," we set team rules prohibiting in-meeting—or, worse yet, ex-meeting—sidebars among subsets of team members. Never under-estimate the power of team disapproval to discourage factional behavior—although in this case, we started off with respectful, professional people in both camps, which helps a ton.
First we eliminated what we perceive to be the most common contributors to miscommunication between business and IT: technical symbology, process symbology, tech jargon and process jargon. Then we discussed "as-is" workflow/information flow in English and mapped it using a custom palate of literal, clip-art symbols.
Whereas business people can’t read IT-type process mapping and IT-folks can’t read esoteric process mapping, anyone can understand moving work from an outbox to an in-box, including manually deleting a tracking number for the work folder from one system and reentering it in the next. And not only do they understand it, but also they know it needs fixing.
Continuing to use straightforward verbal and visual communication, we led the group through analysis of the "as-is" workflow and information flow—and subsequent design of the optimal "to-be" state. In addition to producing "group think" on the way things should be, this exercise answered the question of whether technology or business is the legitimate driver—and as anyone participating in one of these meetings will tell you, business requirements rule.
Finally, we drilled down to create a "to-be" process level, which gave us the remaining input we needed to write business-needs-driven technology requirements for the new CRM app, including fields, forms, menus, navigation and data access and integration requirements. Then we called in the ERP vendor, and business and IT jointly presented revised requirements for the new app.
The bottom line? The vendor is going to comply—albeit for some additional design money; the CRM system should support redesigned and improved business process; when the system is deployed, both sides will understand the importance of applying proper metrics; and business and IT functions now share an understanding of the common ground connecting their functions.
All of which is a very long way from our starting point.
