Herding Cats Across the Supply Chain
Supporting customer relationship management processes across a network of trading partners requires careful attention to people and perceptions
By Ram Reddy
Different people define customer relationship management (CRM) in different ways, calling it everything from “contact management on steroids” to “customer-focused enterprise systems and processes.” The definition that best captures the essence of CRM, however, is this one: the commitment of all enterprise processes and systems toward sensing and responding to customer needs on an ongoing basis.
But even under this definition, CRM would be incomplete without this additional, crucial directive: Provide customized products and services at a cost customers are willing to pay. This directive, of course, usually requires a realignment of business processes — both within the original equipment manufacturer (OEM) and across its supply chain—around CRM.
In this article, based on my recent experience consulting for a CRM project in the automotive manufacturing sector, I’ll offer a detailed view of the challenges involved in making such business process changes.
Sense and Respond
Let’s consider the real-world example of one of my clients, an OEM that makes and supplies customized car seats for multiple firms. The manufacturing requirements for the OEM’s customized components change frequently based on user satisfaction surveys and quality- related warranty work. For example, if many customers express dissatisfaction with a particular feature of the product, the OEM will change its engineering and manufacturing specifications for that feature. Thus, the primary objective of the company’s CRM initiative was to implement processes and supporting systems that could sense and respond rapidly to changes in customer (and hence manufacturing) requirements. Before the project, it would take two to three months for changes in customer requirements to “trickle down” to the supply chain. Because of this “time-lapse” view of customer requirements, every participant in the supply chain had a different view of what they were at any given time. Thus, these companies were forced to stock up on various combinations of components, incurring costs in terms of inventory holding overhead as well as working capital requirements. In this environment, implementing a CRM solution focusing on delivering customized solutions, at an affordable price, and with reduced cycle time was like trying to put out a fire with gasoline. Runaway inventory holding and working capital costs inflated the cost of customized products, turning customers off.
Our project’s goal, therefore, was to realign business processes and supporting systems across the supply chain to enable CRM cost-effectively. As I’ll explain, the team was constantly pulled in different directions by various functional groups within the OEM and its suppliers throughout the five-month reengineering effort. However, the focus on customer requirements, the creation of a business process realignment team charter (derived from an actionable definition of the business problem), and executive sponsorship helped overcome these problems.
What’s the Problem?
Before we could realign processes and systems to support the CRM initiative, we needed to clearly define the business problem at hand. This task proved to be quite challenging. The first attempt at getting a clear definition of the business problem resulted in a simple “We need a CRM system!” This goal was obviously too vague to be actionable, so I was asked to interview key personnel from the OEM and its supply chain partners.
I asked each interviewee to describe the problems they faced in their particular operational area, without any thought to upstream or downstream processes. Interestingly, although all of them emphasized the need to increase the internal efficiencies of their particular functional group, none of them described the problem in terms of the customer. Rather, the business problems they described were inward-facing and involved streamlining existing processes.
Eventually, the executive sponsor from the OEM (the VP of manufacturing operations) became disappointed about the disjointed problem definitions arising out of the one-on-one interviews. Consequently, we invited all the key stakeholders -- such as the VPs of sales, comptrollers, and directors of purchasing -- from the OEM and across the supply chain to a one-day "visioning session." The objective was to collectively define the problem from a customer standpoint and use it as the basis for our effort. During this session, we managed to define two main business problems: Reduce cycle time for communicating customer requirements across the supply chain and reduce working capital requirements, inventory holding, and unplanned shipping costs across the supply chain to make the product more affordable for customers.
Now that we had clearly defined these business problems, the suggestions for solutions arrived fast and furious. The OEM executives wanted to implement an ERP system across the supply chain, but I reminded them about the difficulty they were already having realigning internal processes in an ongoing internal ERP implementation. That experience highlighted the enormous difficulty of implementing a complex, integrated ERP- type solution within a single firm, let alone across multiple firms.
Furthermore, the OEM's infrastructure consisted of a hodgepodge of legacy and client/server systems across which various pieces of customer information were distributed. These systems were unable to store and communicate customer requirements reliably within the firm or across the supply chain. Multiple systems of record contained customer requirements and changes; no single system could access customer information inside the OEM or from supply-chain partners.
Unfortunately, this situation is all too common. Data warehouses and data marts may aggregate information from various systems of record, but by definition they do not support the level of customer detail needed for CRM efforts.
Proposed Solution
We asked the stakeholders who had articulated the business problem to define a high-level solution. This experience turned out to be quite educational. The stakeholders had no problem defining a high-level process flow that addressed communication issues across the supply chain.
The challenge in implementing the solution became evident as we examined each individual component of the solution in greater detail. At first glance, each item seemed relatively easy to implement. However, the domino effect on the entire supply chain would be substantial. For example, realtime changes in customer requirements for an existing order would lead to a lengthy analysis on the disposition of work-in-process inventories, intermediate goods in shipment between suppliers, and so on.
The OEM had brushed aside previous discussions on these details and deemed them "a supplier problem." However, these details could no longer be overlooked, and the company was forced to consider implementing a channel partner relationship management system, such as one of those available from Partnerware, Trilogy Software Inc., or Pivotal Corp. (These systems differ slightly from traditional CRM applications in that they extend CRM functionality to the supply chain.) Selecting and implementing partner relationship management would require many infrastructure changes across the supply chain. Thus, the OEM decided to pilot the business process changes initially with a Web-based workflow system before considering a partner relationship management system.
Next, the complex task of implementing all facets of CRM -- product and service information, field service management, and so on -- forced the stakeholders to prioritize different areas of functionality for implementation. They based this prioritization on the business benefits and operational feasibility of each CRM deliverable. For example, although the proposed CRM solution covered areas such as marketing automation, sales, product and service information, and product and service configuration, the stakeholders drilled down and defined only small pieces of functionality that addressed the most pressing business problems. This task became relatively painless, given that the same group of stakeholders had defined the common business problems to begin with. Eventually, each process and system deliverable was allotted a two to four month cycle time from the visioning session to implementation.
Now that we had clearly defined the business problem as well as implementation scope, the team was eager to realign processes and draft functional specifications for a solution.
Channel Master Dictator
John Kotter, who wrote the seminal article "Leading Change" in the March-April 1995 issue of Harvard Business Review, has related an anecdote in which researchers asked employees across multiple firms to define what qualified as "major" or "minor" changes in their work environments. The overwhelming majority said that a major change is one that affects them personally, regardless of the magnitude of change. Conversely, they characterized a minor change was one that did not affect them personally, even though the change had a significant impact on the firm.
The business process alignment and functional specifications for our CRM effort nearly became victims to this mindset. When the "channel master" (OEM) for the supply chain began to dictate the processes and systems for the solution, it nominated groups from different functional areas of the company that were underrepresented in the initial visioning and prioritization sessions to help define the solution. However, these groups did not share the same vision as the original stakeholders; rather, they focused on addressing their immediate operational needs.
As it turned out, these groups wanted to arbitrarily change our system functionality and process alignment specs. For example, the more powerful functional areas pushed changes in processes out of their areas to less powerful ones, ensuring that the status quo was maintained for their respective parent departments. They also asked for automated system workarounds instead of changing their processes directly to support CRM. For example, the customer service department opposed any change in the way they record information about warranty work authorizations. The customer service manager was reluctant to add any additional data capture tasks to his staff and wanted an automated workaround instead.
When these functional areas then began to push the majority of the changes out to the suppliers, that was the last straw: The resulting "business process realignment" and system specifications became disjointed and infeasible. Furthermore, the less powerful departments within the OEM and the supply chain partners were alienated from the project and didn't believe the solution would truly address their business problems.
Eventually, the original stakeholders had to review and sign off on the proposed solution. During this review, it became clear that the group's vision was not reflected in the proposed solution. Stakeholders from less powerful departments and the supply chain were very vocal about the lopsided nature of the business process alignment and system changes. It became clear that attaining our objectives required the willing participation of the entire supply chain and all OEM departments. If some of these groups did not participate in the process design and "take ownership" of the solution, the CRM implementation would never fulfill its business objectives. As a result, the stakeholders decided to build a team that could define a solution acceptable to the entire supply chain.
The Team
We unanimously characterized the initial failed attempt at process alignment as trying to "herd cats." Fortunately, the new team was committed to getting the right membership, charter, and executive access for success.
First of all, the team leader came from outside the OEM. This element would be critical in gaining the trust of the supply chain partners. Furthermore, team members were nominated from across the supply chain and had operational knowledge of the processes to be realigned. They were also empowered to make process decisions -- a critical step, in that they were expected to sell the redesigned processes to their respective organizations. In contrast, in the initial failed effort, the most expendable people were assigned to participate on the design team.
The time requirement for process design and developing functional specifications was a single, focused, two-day work session. As each prioritized deliverable's cycle time was three months on average, the solution was not very hard to design.
Given the previous resistance to pro- cess change across the supply chain, the team members were expected to deliver a CRM solution acceptable to the entire supply chain. Thus, they were chartered to use the agreed-upon business problem definitions to guide their process redesign efforts. They were also empowered to evaluate whether a process change or functional specification contributed to solving the business problem; for example, they considered any functional specification requests that were cosmetic in nature to be lacking in any real business value.
Any proposed changes to process or functional specifications were subject to a change-control process managed by the team. This approach helped protect the credibility of the team members in selling the process redesign and solution to their respective firms.
Fighting Alligators
I'm not from the bayou myself, but I am told that draining swamps is a tough business. Instead of tackling their primary task -- draining the water -- many people deplete their energies fighting alligators instead.
A similar fate awaited the newly chartered team as it embarked on its mission. The OEM's various departments found innovative ways to define hitherto non-CRM functions and features as critical to the project's success. An imaginative sales manager insisted that this project could not succeed without upgrading his company's contact management software. Closer examination revealed that the proposed changes did not directly interact with any component of the contact management process.
Furthermore, the supply-chain partners wanted to get some of their stalled projects implemented under this initiative. Suddenly, the IT departments from the OEM and supply chain partners needed new hardware and software upgrades. In essence, sensing that the team would successfully develop and implement a solution, the whole supply chain tried to add "pork" to it.
Ultimately, the team fought off these "alligators" and completed its mission successfully. This success was due in no small part to access to executive leadership within the OEM and across the supply chain.
A Word From Your Sponsor
Based on this experience, I've learned that executive sponsorship and access are mandatory for implementing solutions that cut across the OEM and supply chain. This access is the most important element in implementing process redesign solution deployment. The team leader has to insist on weekly face-to-face meetings with key executives, especially those in the OEM. This weekly "face time" helps keep scope creep in check.
For example, the team's attempts to explain impending process changes can be preempted by direct reports from managers who have regular operational contact with the executives. Often, these reports don't present proposed process changes in the best possible light. Without regular face time with the team leader to discuss impending changes in an objective way, the executives can become alienated from the team's objectives.
The team leader should also have direct access to the executive sponsors, not to some intermediary acting on the team's behalf. Perception turns out to be more important than reality when successfully selling process changes to the executives of each supply-chain partner.
The team leader also needs immediate access to executives on an as-needed basis to address sudden showstoppers. Most showstoppers come from the operations area during process redesign. In such situations, people who are good at operations tend to overanalyze and fail to make decisions quickly. In contrast, executives usually evaluate problems from a big-picture standpoint, take decisive action, and then communicate with their respective organizations. Similarly, the executive sponsors have to communicate project status, features, and functionality to their respective organizations with staff support from the team. This makes the final executive sign-off on the CRM solution easy and predictable.
Succeeding and Surviving
Succeeding and surviving the implementation of such process changes requires the footwork of Fred Astaire. We are often dazzled by technology but ignore the organizational changes that come along with its implementation. If you manage people and perceptions effectively during process realignment, the process and technology components will be relatively easy to implement.
First, the team leader has to learn and work within the organizational culture of the firm. A team leader may be brilliant technically, but a lack of sensitivity to organizational culture can stall the process changes associated with CRM. Rather, the leader has to possess a sense of empathy and understanding of challenges facing a group before asking them to change their processes. For example, the customer service area at the OEM in our case study was under stress because of staff turnover rates approaching 45 percent annually. Given this background, it required significantly more time to convince that group of the need for process changes that affected them.
Second, the process redesign team should constantly remind themselves that people dislike change, not the team or its leader. Getting defensive or confrontational is a natural response to change; you have to listen patiently to people who do so. If you agree that they have legitimate concerns and then shift their focus to the long-term benefits involved, more often than not, their resistance to change will decline. In fact, on a couple of occasions, we found that dissenting voices raised legitimate concerns that were not evident during the process design. The dissenters then became advocates for the proposed process and solution within their respective departments. This development helped us gain credibility for the proposed solution and organizational buy-in across the supply chain.
Third, ensure that non-IT executive sponsors and stakeholders get credit for defining and deploying the solution. It is the team's job to ensure that the day-to-day operations staff who will work with the CRM solution take ownership of the realigned processes. CRM across the supply chain requires multiple individuals across different organizations to work in unison to support a customer they do not directly interact with. An incentive structure for key operatives within the OEM's organization and across the supply chain to use the solution has to be instituted to ensure the success of the realigned processes.
Finally, implementing CRM across the supply chain requires a fundamental shift in the way the dominant channel partner interacts with its supply chain. Implementing limited process realignment across the supply chain lays the foundation for this new relationship, or supply-chain community. In such a community, everyone works together as peers despite the presence of a dominant OEM, collaboratively squeezing waste out of the chain, optimizing processes, and sharing the gains equitably among all members.
Without this change in mindset, supporting CRM across the supply chain will be impossible. The traditional "arm's length" relationship between suppliers and the dominant channel partner can't support the processes to sense and respond to the customer with products and services at an affordable price.
Ram Reddy (ramreddy@tacticagroup.com) is the managing member of Tactica Consulting Group (www.tacticagroup.com), a technology and business strategy consulting firm.
|
