Measuring the success of your customer service by using a single metric is impossible. It’s like flying a plane by just looking at your speed without taking the altitude into account. You need to measure a set of competing metrics to make up a Balanced Scorecard that includes the cost of doing business and customer satisfaction. Service operations that have sales responsibilities should also track revenue generated. And in industries with strict policy requirements, like healthcare, insurance, and financial services, compliance with regulations is yet another set of metrics to track.
Choosing the right set of metrics to measure also depends on the stakeholders that use this information. For example:
Service managers need operational data that tracks activities, while executives want strategic KPIs that track outcomes of customer service programs.
Service managers need granular, real-time data on their operations, while executives need to see only a small number of KPIs on a periodic basis.
I always think of it as a two-step process to pinpoint the right metrics for all your stakeholders:
Understand the strategic objectives of your company; choose the high-level KPIs for your contact center that support your company’s objectives. These are the metrics you will report to your executives.
Choose the right operational activity metrics for your contact center that map to these KPIs and which the customer service manager uses on a daily basis to manage operations. Here’s an example of this mapping:
In 2006, Forrester found that organizational structure, internal enterprise goal systems, and most urgent business requirements were key obstacles on many firms’ journey toward broad multichannel solutions with rich cross-channel capabilities. At that time, a few advanced firms tried to establish a multichannel organization, an organizational layer to coordinate multichannel requirements and solutions between the different business groups and the IT organization. Has this changed over the past five years?
Recent Forrester inquiries from enterprise infrastructure and operations (I&O) professionals show that there's still significant confusion between infrastructure-as-a-service (IaaS) private clouds and server virtualization environments. As a result, there are a lot of misperceptions about what it takes to get your private cloud investments right and drive adoption by your developers. The answers may surprise you; they may even be the opposite of what you're thinking.
From speaking with Forrester clients who have deployed successful private clouds, we've found that your cloud should be smaller than you think, priced cheaper than the ROI math would justify and actively marketed internally - no, private clouds are not a Field of Dreams. Our latest report, "Q&A: How to Get Private Cloud Right," details this unconventional thinking, and you may find that internal clouds are much easier than you think.
First and foremost, if you think the way you operate your server virtualization environment today is good enough to call a cloud, you are probably lying to yourself. Per the Forrester definition of cloud computing, your internal cloud must be:
Highly standardized - meaning that the key operational procedures of your internal IaaS environment (provisioning, placement, patching, migration, parking and destroying) should all be documented and conducted the same way every time.
Highly automated - and to make sure the above standardized procedures are done the same time every time, you need to take these tasks out of human error and hand them over to automation software.
Over the years we’ve learned how to address the key business intelligence (BI) challenges of the past 20 years, such as stability, robustness, and rich functionality. Agility and flexibility challenges now represent BI’s next big opportunity. BI pros now realize that earlier-generation BI technologies and architecture, while still useful for more stable BI applications, fall short in the ever-faster race of changing business requirements. Forrester recommends embracing Agile BI methodology, best practices, and technologies (which we’ve covered in previous research) to tackle agility and flexibility opportunities. Alternative database management system (DBMS) engines architected specifically for Agile BI will emerge as one of the compelling Agile BI technologies BI pros should closely evaluate and consider for specific use cases.
Why? Because fitting BI into a row-oriented RDBMS is often like putting a square peg into a round hole. In order to tune such a RDBMS for BI usage, specifically data warehousing, BI pros usually:
Denormalize data models to optimize reporting and analysis.
Build indexes to optimize queries.
Build aggregate tables to optimize summary queries.
Build OLAP cubes to further optimize analytic queries.
I recently attended the second annual “Canonical Model Management Forum” at the Washington Plaza Hotel in Washington, DC (see here for my post about last year’s, first meeting, including Forrester’s definition of canonical modeling). Enterprise or information architects from a number of government agencies as well as several of the major banks, insurance companies, retailers, credit-card operators, and other private-sector firms attended the meeting. There was one vendor sponsor (DigitalML, the vendor of IgniteXML). There were a number of presentations by the attendees about their environments, what had motivated them to establish a canonical model, how that work had turned out, and the important lessons learned.
Last year I also had some recent Forrester survey results to share – we have not yet rerun that survey, but we are on the verge of rerunning it, so I’ll post some key results from that once the data is available.
Last year’s post is still the place to go to get the general overview about why to do canonical modeling, the main use cases, some areas of controversy (still raging), and a list of best practices I heard attendees agree upon.
What’s New In 2011?
Based both on what I heard at this meeting and on other recent interviews:
Today Google announced its Google Wallet product, along with partners Sprint, Citi, MasterCard, and First Data (Forrester clients can read our more detailed take on this announcement here). While Google Wallet will initially support Citi-branded MasterCards, the product is open and will accept payment solutions from multiple networks and issuers. Google introduced its Wallet by saying, “This is just starting,” and Google’s right — the path to the new world of transactions that the company painted will be a long and arduous one for consumer product strategists. Why?
Not many phones. Today the number of phones on the market that support Google Wallet is as close to zero as makes no difference — the Nexus S that Sprint launched on May 8th. That will change — by the end of 2012, we expect that virtually every smartphone sold will include NFC.
Not many issuers. Consumers want to be able to use their existing payment options, not have to sign up for a new credit or debit card in order to use their phone.
Not many merchants. Consumers don’t want to have to look for an acceptance mark; they expect that the merchants they frequent will support the payment options in their wallet. While PayPass terminals are becoming more prevalent, they are a long way from ubiquitous.
Not much incentive for consumers. Some consumers might say it’s convenient to just carry their phone, but wallets hold a lot more than just payment instruments. And it’s not clear that pulling out our phone, opening an app, inputting a PIN, and waving our phone at the POS is more convenient than swiping a credit card or exchanging cash.
What is one of the most important decisions infrastructure & operations (I&O) professionals face today? It's not whether to leverage the cloud or build a private cloud or even which cloud to use. The more important decision is which applications to place in the cloud, and sadly this decision isn't often made objectively. Application development & delivery professionals often decide on their own by bypassing IT. When the decision is made in the open with all parts of IT and the business invited to collaborate, emotion and bravado often rule the day. "SAP's a total pain and a bloated beast, let's move that to the cloud," one CIO said to his staff recently. His belief was if we can do that in the cloud it will prove to the organization that we can move anything to the cloud. Sadly, while a big bang certainly would garner a lot of attention, the likelihood that this transition would be successful is extremely low, and a big bang effort that becomes a big disaster could sour your organization on the cloud and destroy IT's credibility. Instead, organizations should start with low risk applications that let you learn safely how to best leverage the cloud — whether public or private.
In my last blog I asked the question, “What’s it take to be a smart city?” One of the critical elements lies in smart governance. Smart governance takes leadership, coordination, and collaboration. (Take a look at my recent report, "Smart City Leaders Need Better Governance Tools.") Part of this leadership is finding innovative and cost-effective solutions to intractable problems – and that often lies in engaging constituents for input on the problems and feedback on the solutions. As Charles and I were working on another project, we came across a great example of a US state looking outside the box to solve a real and frustrating problem faced by its citizens.
When Cisco began shipping UCS slightly over two years ago, competitor reaction ranged the gamut from concerned to gleefully dismissive of their chances at success in the server market. The reasons given for their guaranteed lack of success were a combination of technical (the product won’t really work), the economics (Cisco can’t live on server margins) to cultural (Cisco doesn’t know servers and can’t succeed in a market where they are not the quasi-monopolistic dominating player). Some ignored them, and some attempted to preemptively introduce products that delivered similar functionality, and in the two years following introduction, competitive reaction was very similar – yes they are selling, but we don’t think they are a significant threat.
Any lingering doubt about whether Cisco can become a credible supplier has been laid to rest with Cisco’s recent quarterly financial disclosures and IDC’s revelation that Cisco is now the No. 3 worldwide blade vendor, with slightly over 10% of worldwide (and close to 20% in North America) blade server shipments. In their quarterly call, Cisco revealed Q1 revenues of $171 million, for a $684 million revenue run rate, and claimed a booking run rate of $900 million annually. In addition, they placed their total customer count at 5,400. While actual customer count is hard to verify, Cisco has been reporting a steady and impressive growth in customers since initial shipment, and Forrester’s anecdotal data confirms both the significant interest and installed UCS systems among Forrester’s clients.
Today we’re kicking off Forrester's IT Forum 2011 at The Palazzo in Las Vegas. Prepare for three exciting days of keynote presentations and track sessions focused on business and technology alignment. Use the Twitter widget below to follow the Forum conversation by tracking our event hashtag #ITF11 on Twitter. Attendees are encouraged to tweet throughout the Forum and to tweet any questions for our keynote presenters to #ITF11.