Technology Automation In Action

Our simulated case of Rauha Communications and its CRM project in the wireless services division helps to illustrate how technology automation addresses some of these industry trends. First, Rauha Communications uses technology automation to define requirements for a new customer service application in a way that traces back to business and process, and also includes the end-users of the system early on in the project. Next , the company's vendor selection process illustrates how technology automation improves communication between the IT department and third-party vendors and service providers. Finally, Rauha Communications enforces key architectural standards during technology automation, and maintains a unified technology architecture that is both robust and extensible.

Define Requirements for the Customer Service Application

After completing process optimization, the Project Alpha team moves on to technology automation. Their first task is to identify the high-level applications that will be required to achieve the project's goal. After comparing some industry research supplied by an IT analyst firm to the requirements captured in the process model, they identify two major applications: campaign management and customer service (see Fig. 7.6).

Figure 7.6. Project Alpha requires a campaign management and customer service application

From the start, one of the key objectives of Project Alpha has been to improve service in order to minimize the attrition of high-value customers. The project team determines that to achieve this objective they will need to integrate the customer service experience across two key touch points: their existing call center and the Rauha Communications Web site. This will involve installing and integrating new software, so the Project Alpha technology automation team begins by examining the current state of the wireless services division's technology architecture. Then, they define requirements for the new applications that will be required to achieve their goals.

Technology automation kicks off in Project Alpha when an enterprise architect recommends an existing technology model to use as a starting template. This model, which was developed during a previous IT project, represents an up-to-date snapshot of the company's technology architecture, and specifically the applications that relate to customer service (see Fig. 7.7).

Figure 7.7. Rauha Communications currently employs a legacy call center application and a customer service website that aren't integrated

After spending some time examining this model and determining how the current applications help support customer service activity, a team composed of software engineers , customer support representatives, a process analyst, and Rauha Communications' webmaster sits down to perform gap analysis and determine what new systems are required. The customer support representatives begin by reporting that their existing call center application, a legacy system developed some years ago, is both familiar and efficient. The webmaster verifies that Internet support is currently limited to a series of static HTML pages that list and answer some frequently asked questions. Clearly, the team determines, they will need to improve Web support to include a searchable knowledgebase of problems and solutions, and perhaps, as the webmaster suggests, even live chat staffed by support representatives.

This conclusion leads the team to their first major decision: should the project aim to augment the legacy call center application, or should the team look to replace it with a single, integrated CRM platform? In general, they would prefer to reuse the existing, popular system if possible. But since one of the requirements for the project is to integrate information from each touch point and product into a single, unified view of the customer, they recognize that this could be a challenge. The team determines that both are viable options, and decides to create a technology scenario model for each and postpone the decision until they have a better understanding of how both impact the underlying architecture, the related support processes, and ultimately the overall business objectives of Project Alpha.

First, they tackle the scenario where a new CRM system replaces the existing call center application, and develop requirements for the new application. To address concerns early on, avoid buy-in problems, and generally make sure that the requirements service the needs of the customer, they work with the customer support representatives and the process analyst to develop requirements and link them to individual activities in the corresponding process model. Figure 7.8, for example, illustrates how the customer sign-in process depends upon specific requirements that map to user profiling and portal display components within the new Web service application.

Figure 7.8. Requirements that have been developed for Project Alpha map both to an application flow diagram and also the application that provides the underlying functionality

The visual nature of the models that are developed during this portion of technology automation helps the end-users, the customer support representatives, visualize how the new systems will impact them. By getting these people to sign-off on the changes as early as possible, the Project Alpha team helps to mitigate some of the cultural inertia that can weigh IT projects down. In addition to getting sign-off and preparing users for an upcoming change, technology models also help to democratize input into the design. Even though they aren't technical wizards in any sense of the term , the customer support representatives can provide valuable insights into how they do their job and can make sure that detailed requirements make their way into the system before costly coding or implementation begins. For example, after viewing the preliminary model, one of the Rauha Communications' customer support representatives remarks that he would like to be able see every product that the current caller has purchased when taking a support call, since it might help him to pinpoint confusion in bill presentation. This leads the development team to include a new requirement detailing this request, and ultimately improves the utility of the Web service application that gets implemented.

Examine Vendors and Make Intelligent Trade-offs

Eventually, after weighing the full impact of both scenarios, the team responsible for technology automation determines that sharing data between the legacy call center and new Web service applications won't be prohibitively difficult, and decides to pursue that course of action. Since Rauha Communications doesn't have the capability to develop a leading-edge Web-service system in-house, they elect to purchase an off-the-shelf CRM application (which includes a Web services component) and then modify that to achieve the project's objectives. This decision leads to the next phase of technology automation where a purchasing manager, technology architect, and an external consultant collaborate with account representatives and sales engineers from leading CRM software vendors to select an appropriate package and negotiate a contract.

The external consultant, although she is an expert in CRM software solutions, comes into the project with little in-depth understanding of either Rauha Communications or Project Alpha. In order to get up to speed, she sits down with the project team leader who uses each of the business, process, and partially completed technology models to describe the project's objectives and scope, and to visually demonstrate the important decisions leading up to the current vendor selection.

The consultant begins her research; identifies relevant analyst reports , news articles, and product descriptions that pertain to possible vendors; and attaches them directly to the model itself. By contextualizing this information, she helps to make sure that even after her engagement with Rauha Communications ends, the Project Alpha team can trace her decisions back to the supporting evidence. Eventually, the consultant submits RFPs and associated technology models to each vendor. Although this particular vendor selection is concerned only with selecting a CRM application, the package includes business and process models, as well as the systems portion of the technology model. This gives the sales engineers a better understanding of the requirements they are being asked to address, and allows them to generate a more accurate prediction of which requirements their software meets out of the box, and which will require customization. Including the systems side of the technology model serves another important purpose: The new application will need to work with Rauha Communications' current technology architecture, including underlying systems. It is important for the vendor evaluation to consider not just functional requirements that link back to process optimization, but also technology requirements such as event notification and work flow that are mandated by the current systems that make up the company's technology architecture.

After the vendors respond to the RFP, the consultant sits with the rest of the team to determine which package best meets their needs. Predictably, no single package is able to tackle every requirement out of the box, and the team will have to make some trade-offs in order to minimize customization while maximizing the project's business benefit. But since each of the vendors' proposals were generated against the end-to-end models developed for the project, it is relatively easy for the team to evaluate the overall impact of choosing each solution: One of the options, from Vendor Bravo, provides strong search and categorization functionality for its knowledgebase, but doesn't offer online chat. Another, from Vendor Charlie, touts its chat functionality as a differentiator, but is weaker in knowledge retrieval. The consultant is able to trace each of these requirements back to the processes that they support and then from those processes to the original business model, which indicates that the knowledgebase is essential for the project, but that chat is not. As a result, she recommends Vendor Bravo, and helps to assure that the final technology solution delivers upon the project's original objectives.

Establish and Enforce Application and Architecture Standards

Eventually, the project team selects a vendor, completes technology automation, and uses the end-to-end enterprise model to construct a sound business case for moving Project Alpha into implementation. Rauha Communications' CIO and the firm's IT investment committee approve of the design, the project is given the green light, and the new CRM system becomes a key component in the company's wireless services division.

Project Alpha is a success. It is such a success, in fact, that the PMO decides to try and replicate Project Alpha in other business units. Specifically, a program manager wants to establish Vendor Bravo as the standard CRM package throughout the company. The program manager knows from experience that, left to their own devices, far-flung project teams will often forget or ignore standard packages, especially when doing so might benefit them ”even at the expense of the enterprise as a whole. But BTM gives him a mechanism to counter this tendency. Recall from earlier in the case that in each of the activities of BTM, the Project Alpha team began with a standard template that it modified to accomplish its own, specific objectives. The program manager recognizes that by placing the models developed during Project Alpha in a central repository and providing them to upcoming CRM projects, he can strongly encourage teams to adopt the standards that he sets, even to the point of reusing the real software and hardware assets already developed for the wireless services division.

BTM, then, provides benefits to Rauha Communications on two levels. First, it gives the team responsible for designing Project Alpha a mechanism to experiment, gain consensus, and validate conclusions before beginning a costly software implementation program. Business model definition helped the Project Alpha team to capture an as-is current business model and to develop business scenario models for impact analysis. Process optimization enabled them to examine the as-is process environment, and perform gap analysis and determine requirements. Finally, technology automation helped to define requirements for the customer service application, examine vendors and make intelligent trade-offs, and establish and enforce application and architecture standards. Ultimately, addressing these concerns in the "aim" rather than "fire" phase saves time, money, and helps to deliver a better end product. But even after these important tasks are accomplished, Rauha Communications continues to derive real business benefits from BTM: By helping the company's program manager and his team to define and enforce standards for enterprise architecture, BTM lowers the cost of and shortens the time that is required to complete similar upcoming projects.