[For earlier posts in this series, click here, here, and here.]
Imagine yourself back in childhood, sitting in the back seat of the family station wagon, en route to one of those long, high-stress family vacations that Americans have honed to perfection. Mom and Dad are arguing over what went wrong so far on the trip, and of course, how they could have avoided these mishaps. Why didn't we ask for directions at the last gas station, instead of letting Dad navigate by dead reckoning? Should someone have called ahead to ensure that there wasn't a problem with the hotel reservations? Who was supposed to remember to pack the camera? Was it reasonable to expect a travel rate of 500 miles a day? Quickly, your vision of vacation as a straight line into the heart of fun evaporates. Replacing it is a circuitous flowchart, each serpentine twist representing a different set of decision points, estimates, and possible outcomes. Who knows what might happen next? The wheels will fall off on a desert highway, and someone will have forgotten to renew the AAA membership?
DevOps is a term used to describe better communication and collaboration between application development professionals and infrastructure operations professionals. "Dev"+"Ops"="DevOps." The goal of DevOps to make the process of deploying applications faster and smoother. DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together. Developers and operations professionals are often at odds. Developers want to release software more frequently; operations professionals want to protect the stability of the infrastructure. I applaud the goal of DevOps to improve the process of deploying application releases.
The last thing many application developers want to do is have a sit-down with the ops guys. Besides which, they don't understand. Sure, the ops guys efforts are critical to our applications because they have to run on something. But, developers should look to spend more of their time getting closer to the business, not getting closer to the hardware. I fully acknowledge that there is a need for quicker and less-rickety deployment processes. But, I think DevOps is a step backward. Instead I propose NoOps. The goal of NoOps is also to improve the process of deploying applications. But, NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them. Of course, this is not just about getting virtual machine instances. It is also about release management. Ops can run this public, private, or hybrid infrastructure and give developers the tools they need to responsibly deploy applications faster.
I got a lot of feedback from my last blog post, and I’d like to share my thoughts on each of these statements about customer service. I am sure my point of view is contentious, so please keep comments coming. It will force me to rethink my stance. I’ll cover each of my categories in a separate blog post.
Social Customer Service Myths
Reason behind my POV
Social CRM is giving customers control
Paul Greenberg defines social CRM as the The "company's programmatic response to the customer's control of the conversation." Its about the company taking hold of the reins of the conversation, not the other way round.
Have a look at what Paul Greenberg says here about this topic:
Twitter works for customer service
It sometimes does if the answer can be communicated in 140 characters. It shows that you, as a company are listening and acting on comments.
However, instead of engaging in customer service over Twitter, it is often more effective to take the conversation offline to a more suitable communication channel based on the issue at hand and the customer’s channel preference.
Whoa. My post Java Is A Dead-End For Enterprise App Development received record-breaking readership and passionate comments. Thank you for reading, and thank you for your comments. Clearly it hit a nerve. Many of the comments legitimately called for an expansion of my arguments. Fair enough. I have done that in a 50 slide presentation that I delivered as a teleconference on January 24, 2011. Forrester is making this presentation available to download, free to anyone who registers at the site. Registration is free, so please feel free to register and download the presentation. I welcome your comments on the presentation here, at the original post, or on Twitter.
SAP Has Managed A Turnaround After Léo Apotheker’s Departure
In February 2010, after Léo Apotheker resigned as CEO of SAP, I wrote a blog post with 10 predictions for the company for the remaining year. Although the new leadership mentioned again and again that this step would not have any influence on the company’s strategy, it was clear that further changes would follow, as it doesn’t make any sense to simply replace the CEO and leave everything else as is when problems were obviously growing bigger for the company.
I predicted that the SAP leadership change was just the starting point, the visible tip of an iceberg, with further changes to come. Today, one year later, I want to review these predictions and shed some light on 2010, which has become the “Turnaround Year For SAP.”
The 10 SAP Predictions For 2010 And Their Results (7 proved true / 3 proved wrong)
Internal pilots (a.k.a. "eating your own dog food," or "drinking your own champagne") are important tools. But how? What kind of feedback do you get from these exercises, and what sort don't you get?
That's the topic of a new research project that we just launched. While Forrester starts hundreds of new research efforts this year, I'm highlighting this one for two reasons: (1) I'm doing the research, and I think that everything I do is interesting; (2) this is the second time I've done a research project in a very transparent way. From start to finish, we're going to work in the open, to give you, Dear Reader, an opportunity to comment on the research as we do it.
The first project done in this fashion, which investigated "thought leadership" (whatever that means) in the technology industry, resulted in this RoleView document. Along the way, we solicited comments on the basic research plan, the questions we asked our interview subjects, and the content of the document. We threw out questions to Forrester community members along the way, and at the end, we did a brief retrospection on how well we succeeded.
We're Interested In Your Feedback Again. No, Really.
We're following the same game plan this time. Three documents just went live in The Forrester Community For Application Development & Delivery Professionals:
It is often said that managing a call center is more of an art than a science. Some customer service managers use standard operational metrics to manage their business to – like average hold times (AHT), first contact closure rate (FCR) agent, agent productivity numbers, escalation rates, etc. Others apply established customer service best practices to their organizations without understanding the intent behind these best practices. Yet other companies adopt the current trends without an analysis of their strategic importance.
Here is my list of “half truths and total nonsense” about management philosophies and technologies in customer service. Which ones resonate with you? Which ones do you believe are not myths and work for you?
Kate’s List of Common Services and Support Myths
Social customer service myths
Social CRM is giving customers control
Twitter works for customer service
I don’t need to interface my social processes with my traditional customer service processes
If I have a forum, I don’t need a knowledgebase
Multichannel customer service myths
Established best practice apply to my call center
I am special - Established best practices do not apply to my call center
Front-line support agents don’t know anything
When you measure operational activities, you measure business outcomes
Support can act independently of brand –Support can have a different brand identity than the rest of the company