Thursday, July 17, 2008

Start at the End

Functional Requirements Part A

Now that you have assembled your Business Process Team (Executive Sponsor/Champion, Process Manager, and IT person), you most likely have identified the business function groups that you will interview to develop very detailed process charts and the goals and objectives documentation.

Each business function group (e.g. Sales, marketing, customer service, IT, case management, manufacturing, research, front office, and back office to name a few) will include the managing executive, key managers, and key employees. As the interview process advances, the Business Process Team will start to take notes regarding the “wish list.” The Business Process Team will start to draft functional specifications.

For functional specifications here is the real deal – start at the end.

What you say? That’s right. Most people start drafting functional specifications with what’s needed for input. After all computer applications are based on:

Input > Process > Output

The key element of output is reports. Such a key element for managing the business allows for being proactive versus reactive (remember the 70% of work hours spent in meetings handling the crisis of the day or hour?). Imagine implementing a great CRM system and then managers start complaining and requesting reports thereby slamming IT into overload. And then imagine the requested report has a column of data that is not captured anywhere. Well, you may know the drill of revising the process charts, database, screens, etc. That’s why detailed process documentation is mission critical.

Reports examples:

Report scenario 1

A key measure is capturing time spent on activities such as phone calls, meetings, composing and sending emails, and other tasks. CRM can easily capture this data if planned for. Therefore as time spent starts spilling into overtime, it will start throwing costs out of control. A report of early alerts will allow the management team to be proactive. For sales this might be opportunities that have sticking points in the sales process. For customer service it could be too much time handling complaints. For a medical facility it could be having patients waiting too long after their appointment time before seeing the doctor. Be sure that all the required data is captured.

Report scenario 2

Suppose a report is requested by the marketing business function group for Lead Source Effectiveness. A report is designed that by lead source includes % Total Leads, % Qualified Leads, % Became Revenue, Revenue from Won Opportunity, % Overall Revenue, and Average Revenue per Lead.

Looks like a great report and is included in the initial implementation. Then the CEO wants the revenue from Lost Opportunity included in the report. Whoops. The opportunity is tagged won or lost but the revenue lost is not captured. Looks like more rework is required before the report can be updated.

In summary, the first key element of CRM success is starting functional requirements with output definition. The form can be an online listing, printed report, or preparation for export to a spreadsheet like MS Excel. If a field is required from a legacy system like payroll or inventory, then planning for integration can be done.

As always, comments are welcomed.

No comments: