Why risk the road less taken when selecting business software? Why not stick with what most companies do?
If you’ve been burned by bad business software selection techniques, you know what goes down during and after software selection. It happens all the time with CRM software. But it also happens with ERP, SCM, PLC, GL, ERM, HRM, BSC, LM and even janitorial management and school cafeteria menu planning software.
Here’s the typical drill. You need new software to integrate your workflow and information flow with non-integrated functions—and automate labor-intensive manual work processes. You call IT. IT has a "business analyst" map your current process, finds a solution and brings you and your cohorts together with the vendor for a "design/fit" session trying to find common ground between the functionality the system provides and the functionality you need. Where there’s no fit, the business side is supposed to "adapt."
When the new software is deployed, the real fun begins. First, the software bombs because you can’t change your work to adapt to the software; then finger-pointing becomes pervasive; soon everyone involved is mad at everyone else; and finally the CFO says, "Tough. Live with it."
So, why do people repeat an approach that doesn’t work? Because they don’t know any other way. But there is. Here’s a field-tested alternative that produces predictable outcomes—positive ones.
The alternative approach starts with a philosophical shift. Consistent with today’s increasingly customer-centric business environment, the motivation for implementing new technology becomes adding new value to customers, not satisfying internal business or IT goals. This mitigates the "which department gets its way?" struggle—and makes business and IT allies instead of adversaries fighting over turf.
Sound Pollyannaish? Perhaps. But High-Yield Methods successfully uses this approach with client after client.
Take our recent work with a financial services firm to determine technology requirements for CRM software, new investment and insurance technology and migration to an updated legacy transaction system.
We began by assembling a cross-functional team from each business function directly involved, plus IT. Then the team selected additional, on-call "resource" members to represent functions only indirectly involved and to diversify input regarding critical software functionality. Very importantly, this cross-functional team had senior management’s imprimatur as the decision-making body for defining business requirements. Neither individual functions nor IT should be able to overrule team decisions.
Before we dove into business process analysis and redesign, which would identify technology requirements, we made a critical distinction, one that changes the whole complexion of business process design. We divorced workflow—how work and supporting information move from function to function—from work process—how individual functions perform. This enabled us to limit our initial scope to higher-level workflow and accompanying information flow, which, in turn, allowed us to identify how our client was operating across all functions quickly and with relative ease.
We led the team in "marker mapping" on flip chart pages the way work and information were passing from function to function—the "as-is" state. Because integrated financial institutions may be the most complex of all business models, this required about 12 days over a six-week period, two to three times the time a B2B manufacturer would need. But it was well worth the effort.
Then, we converted the abstract flip-chart pages into what we call "pictographs," replacing boxes and labels with literal clip-art images. Now the entire cross-functional team—and everyone in the company—could see exactly how the company was working, or wasn’t working.
Among other things, at this level, we found significant variances from individual to individual and branch to branch in the way work was being performed, caused by a lack of clear business rules and discipline. We also found that people had labor-intensive manual methods of transferring information from function to function and sharing information among functions.
With these pictographs in front of us, we held new team sessions to create "to-be" workflow and information flow designed to:
- Carry out the work required to implement new, customer-centric business strategies
- Directly add new value to customers
- Indirectly add new value to customers by reducing cycle times, which speeds up delivery, and eliminating non value-adding cost, which helps bring prices down.
- Automate work wherever possible.
The new workflow, developed in another six days over a two-week period, reduced the potential for errors, shortened time cycles, eliminated numerous redundant steps that were adding cost and automated bucket-loads of manual work.
And, of course, we created a new set of pictographs to communicate the "to-be" state to all concerned.
After 12 weeks (including mapping time), we had in hand:
- Redesigned workflow across the company for all functions affecting customers (including much of the back office).
- Redesigned information flow among functions, i.e., a data integration map.
- Graphic depictions of both "as-is" and "to-be" flows that provided broad-based insight into what would change and why.
- Agreement among disparate functions (and factions) to support change.
But we weren’t done yet. We still had to address lower-level work process, where application software requirements are expressed in full detail—but which, all too frequently, becomes a quagmire where business analysts get bogged down. Fortunately, with higher-level "to-be" workflow already designed, drilling down to work process becomes a much more manageable exercise. Why? Because work process is dependent on workflow, and "to-be" workflow provides a cogent map showing where and how to change process.
Also, and this is very important, we reengineer processes, working with sub-teams of workers within each individual function (otherwise, we would completely burn out our prime team members).
After another month, with the work process drill-down completed and mapped using an automated system, we could readily develop application software requirements—down to a keystroke-by-keystroke level, when necessary. Thanks to the level of detail provided, we thoroughly understood user navigation requirements, collaborative aspects of the new work process and a host of forms automation requirements. And then we provided not only these requirements but also the mapping documentation to competing vendors. Forget the typical post-selection "design/fit." In this case, every vendor knew the full requirements and the context surrounding them.
Thanks to the thoroughness of this process, there was little doubt which vendor was best. The full team vote was 23 for the vendor selected and one vote each for the other two contenders—who had both seemed more appealing to the entire team before we got down to detail.
Now that’s a simple and effective alternative to the road most companies travel when selecting technology.