Understand Your Business Process

To provide the aforementioned customer-centricity, you need to evaluate your business processes to understand them and to know whether they need changes.

The Goal

Your goal is to understand the existing business process to support, redefine where necessary, and enable it through technology. The recommended way to do this is to conduct a series of interviews, which provide the basis for building the following:

• A map of current business functions for customer-relationship management

• Business usage of current application systems (if any)

• Business process components and major interfaces

• Integration views

Your approach should be iterative (repeats the steps until enough information is gathered), and will require some improvisation along the way. For instance, when you come across a “gimme”—a benefit that would be easy to obtain and could quickly be implemented—that's known as an early return, and is used to help build support for the project by showing a visible success.

Figure 15.1 shows a process model for conducting a business process redesign.

To understand your business processes, you need to identify members of your organization with expertise in the relevant processes, including sales, service, and marketing. Usually, the experts are the department heads or the people appointed to the task. It's critical to engage these experts early in the process.

The first step is to analyze the current business processes by doing the following:

Identify Roles and Resources

The first step is to introduce the new roles required specifically for the CRM project: the champion, the contributors, and the integrator. The next several sections describe these roles.

Champion

The champion is the process owner and chief persuader, the overall coordinator and internal public relations agent for the project. He performs the following functions:

• Helps build enthusiasm

• Educates others on the project's benefits

• Generates support throughout the organization

Monthly and sometimes more frequent meetings are held with the champion to provide ongoing updates and midcourse corrections for the duration of the project.

Contributors

Business Area Representatives from across functions provide a sounding board for the duration of the project, giving input on what works and what doesn't (from the field). Contributors are also responsible for ongoing prioritization of needs. Represented areas include

• Sales— Can include the senior executive for the sales area. Would also include sales people from the field and branch or regional managers.

• Marketing— The vice president of marketing becomes an important project ally, working closely with the project champion to set direction and provide organizational support.

• Corporate Management— Includes CEO, president, and vice president levels. Interview results are summarized and applied to help define the goals and priorities of the project.

• MIS (Senior Technical Analysts)— Systems managers and senior technologists knowledgeable about the company's systems environment are essential to the success of the project.

• Product Engineering— New product development, research and development, managers, and technical specialists are included.

• Business Planning— Strategic planners, senior marketing executives, investor relations experts, and sometimes legal counsel can be included depending on the goals of the project.

• Service Delivery— Line managers, customer service providers and their managers, regional executives, and branch staff can all be included from this perspective.

Integrator

The role of the integrator is flexible and fluid. It requires a tolerance for ambiguity and the ability to provide reflective feedback to project stakeholders. Some of the functions of the integrator include

• Conducting the project— The integrator assumes responsibility for the success of the CRM project by defining roles, marshalling resources, modeling desired behaviors, and mentoring project resources. He can define project plans, assign project management resources, and/or work with the program management office to set up overall guidelines. The role has been likened to a project shepherd who continually clarifies the vision and sees that participants remain on track for success.

• Conducting open-ended interviews— Subject matter experts and representatives of the business areas affected by the project or business initiative will be identified and interviewed. The recommended method is the open-ended interview as opposed to predefined surveys. The idea is to explore and conduct a process of discovery, turning up business innovations wherever they occur.

• Starting outside the box— A strength of the integrator is the capability to start from outside the box, with experiences gained on many projects that can provide perspective on the particular project. When a key project participant remains outside the box, she is able to continually raise the bar, engaging creative thinking and new learning strategies in project participants.

• Stepping in to define issues— Sometimes the integrator will step into a particular role on a project, whether it be project manager, technical architect, or requirements analyst, to respond to specific issues. Or he might define a new role required by the project, with no current knowledge in the organization. An effective way to instigate a new role for your company is to have an experienced integrator play that role, define its requirements and infrastructure, and then identify candidates (internal or external) to take up the role going forward.

• Identifying candidates to resolve issues— After a new role has been defined and profiled, candidates who fit the profile are identified and oriented to the job requirements. The integrator enjoys a unique vantage point from having moved around the organization in the course of an enterprise project. Often this background comes in handy in identifying promising candidates for new roles. The issues identified earlier become the selected person's responsibility to carry forward and resolve.

• Getting back out of the box through a phased approach The integrator's final step on any given CRM project is to phase herself out in a supportive way. This can be accomplished through setting up various supports for the project team, including

  • Ongoing mentoring program

  • “Playbook” for team members to follow

  • Periodic check-ins from team members

  • Periodic communications with ongoing information exchange

  • Web community built and supported

When the new roles have been introduced and understood, the integrator works with the project sponsors to identify and assign the initial resources required, including

• Internal experts to be consulted, such as subject-matter experts and representatives of the business areas affected by the project or business initiative

• External sources such as industry associations, online information, consultants, and competitors

• Existing models, systems, and information repositories that will be consulted to gather information for the project

Just as the consultation of the initial resources identified proceeds, additional contacts and sources surface and can be added to the list. Depending on the time availability and the depth of organizational contacts of the project sponsors, the initial list can be limited or it can be fairly comprehensive, but it should not be exhaustive.

Build “Best Guess” Models

The goal of the next step is to develop a starting point for viewpoint analysis models that capture the essence of each significant point of view represented in the project. The integrator does just enough preliminary research to pull together a straw man, or discussion starter, as a basis for interviews. The straw man is a descriptive model set up so people can knock it down and correct it, which is easier than starting from scratch.

Validate “Best Guess” Models

Validate the starting point models by reviewing with members of the technical team, and by reviewing existing documents. If necessary, do some external research on the industry to make sure you understand the basic concepts of doing business in the target market space. Test your models against a brief review of industry norms.

Conduct Interviews with Internal Experts and External Sources

Serial interviewing is the preferred method of gathering information in viewpoint analysis models. The goal is to understand the different viewpoints without having them modify one another, as usually happens in a group setting such as Joint Application Design or focus groups.

Interviews should start by introducing the goals of the project, the point of the models, and the conventions of the models. Interview subjects can depart from the preliminary models and just describe their situation, or they can offer updates to the models. Use them as conversation starters, not as formal controls on where the interview can go. In the same vein, predetermined survey questions are usually not recommended. If desired anyway, send them out ahead of time and collect responses at the interview, only clarifying verbally what's not clear from the written responses.

Analyze and Improve Models

This is the point where you step back, review the viewpoint analysis models, and begin to apply the desired improvements. Scenarios and view models typically reveal the integration issues of the project, surfacing the concerns of the business area representatives.

As you begin to identify solutions, you will update the models and return them to interview subjects for their feedback and corroboration. This process is an iterative cycle that terminates when the new models have become clear and project participants understand the responses to their particular concerns.

Generate Recommendations

The outcome of one or more iterations of analyzing and improving viewpoint models is formulated into a set of recommendations for the overall solution. The recommendations should include action items at two levels: near-term deliverables and long-term plans.

An effort is needed to identify areas of opportunity where relatively simple, minor, or low-cost improvements can be made in such a way that significant benefits are accrued. These opportunities are considered “low-hanging fruit” because they are most within reach and available to be harvested early on in the CRM project.

The purpose of introducing a tactical element at this time in the project is twofold:

• Early returns

• Visible successes from the project early on to build credibility and support throughout the organization

The recommendations presented should provide both interim solutions and long-term or strategic solutions.

Present Deliverables

Deliverables presented should draw on the pool of scenarios, view models, and business models developed. They are organized to present the recommended solutions in the context of their business setting.

Recommended solutions are presented to the project champion and business-area contributors. They provide the requirement basis for configuring the CRM package. The integrator will collaborate with specialists knowledgeable in the installation requirements of the package selected.

Recommended solutions provide the basis for subsequent technical models. A subset of the solutions models and subsequent technical models are presented to the technical teams that carry out the actual implementation of the packaged solution.

Understand Different Viewpoints in Your Business

Our approach introduces two feedback mechanisms, user scenarios and viewpoint-analysis models, which are used in preparation for selecting and applying CRM models.

User Scenarios

Narrative descriptions that illustrate a user, business-area representative, or a customer's perspective on system usage, scenarios provide a neutral reflection of project concerns. In developing scenarios you are not drawing conclusions, just feeding back the information you are collecting, primarily through interviews, and sometimes through surveys and focus groups. The story of Mac from sales presented earlier in this chapter is a scenario to describe the view of the sales organization in a particular situation.

In customer portal development, scenarios are used to support user interface design, demonstrating the expected flow of events for visitors interacting with the features of a Web portal.

Scenarios are crucial to CRM because they identify potential problems and possible solutions and highlight the most important requirements of a particular system's use. Embracing the multiple-use scenarios on a project ensures that you don't end up with narrow design solutions that only work for one type of user or one type of Web-site visitor. It also positions your project to align all points of view with the customer's point of view.

The rules for developing scenarios are as follows:

• Capture one viewpoint at a time— Make it a point to align yourself with the owner of the view, seeing how the world looks from her perspective. Don't try to correct her assumptions, just surface them and describe them.

• Keep the scenario loose and informal— Modify its presentation to suit your audience. Some people like verbal feedback with no time committed to writing and reviewing formal scenarios. Others like visuals, and still others want to read a short capsule that captures the essence of what they said to you. Sometimes you need to combine all three, so play it by ear.

• Keep it focused— The initial interview should not be longer than one hour, and less is even better. People get to the point faster when the time is limited. (Don't get carried away with this however. Ten minutes is not enough. The point is to listen, and help your interviewee get to the point.)

• Keep it short— One scenario per page. You might have to start with several pages to capture all the information. The process of condensing information into one page will help you become clear about what is essential.

• Feed it back— This is your chance to get buy-in and promote ownership from your project constituents. Ask for, listen to, and apply corrections. Then feed it back again.

Viewpoint Analysis Models

Whereas scenarios provide a narrative method of describing the system requirements from more than one point of view, capturing those multiple viewpoints for the design of an integrated CRM solution requires a modeling repository. It must be one that is flexible, easily modified, taken in at a glance by the owner of the viewpoint, and questioned or corrected on the spot.

Viewpoint analysis models are about perspective. They offer a quick way to develop a sophisticated knowledge of a problem set by capturing several perspectives against it prior to synthesizing them into one solution.

The rules for developing viewpoint analysis models are as follows:

• Adopt conventions— You need to adopt conventions to have enough structure so people don't get lost, and you need to present them as a preface to reviewing your models.

• Go sit with the user— Capture what he sees. Use size and position on the model to indicate importance and priority. Let the relative positioning of components tell the story.

• Visualize it for them— Start with a best guess and let him correct it. Modeling is easier for the interview subject if you provide the starting point.

• Show him other viewpoints— People begin to catch on when they see the variations in views. If a view is too foreign for them, don't show it.

• Use his terminology— If marketing calls a system by one name and sales calls it by another, let the two views use two different names. This can provide an important indicator when it's time to reconcile the meanings of the business entities.

Scenario and Viewpoint Summary

User scenarios and viewpoint analysis models set the stage for the solutions design work that is yet to come. They clarify the issues for CRM, and let project contributors know you've understood their concerns and prioritized them correctly. Presenting both a visual and narrative description, the two techniques work together to deliver a balanced picture of the business context in which the project must proceed.

Aligning with the Customer View

After you develop analysis models you should have a good understanding of the many points of view that occur within your project. You must now pay attention to the one point of view that will be used to organize all the others, the customer point of view. The following steps will serve as a starting point:

1.	Put the customer view on top
2.	Walk through other views looking for overlap
3.	Identify differences—places where the other views conflict with the customer view
4.	Resolve conflicts, based on customer priorities
5.	Continue to adjust divergent processes until all processes reflect and support the customer view