As outlined in Technology Management In The Age Of The Customer, the age of the customer will fundamentally change how app-dev groups operate and interact with business leaders. This post is intended to open a discussion around the likely changes that the age of the customer will bring in the next few to several years — a reasonable planning window. I’ve seen a fair amount of change in this industry. As background, my tenure in the IT industry dates back to 1982, when at the tender age of 25, I left the Cambridge Institue for Computer Programming with a full head of hair and a fire in my belly to do great (programming) things. My first job as a batch programmer for the Massachusetts Department of Public Health lasted long enough to land my next job at Boston University, where I wrote batch and online Natural/Adabas code for a few years. In 1985, I joined Cullinet Software in Westwood, Mass. to develop commercial ERP applications in ADSO/IDMS (before the “ERP” acronym even existed). Online, fully integrated manufacturing, HR, and financial apps based on a network DBMS — it was cutting-edge technology at the time, as were the IBM PCs that began gracing our desktops circa 1987. Ironically, today my iPhone has more power than these early XT machines.
This got me thinking: Should efficient code management be the primary rationale when developing for the mobile Web or mobile apps?
IMHO, no. Judging from my conversations with vendors, agencies, and end users, manageable code bases are a solid goal when developing mobile strategy for digital customer experiences, but by no means the top priority (AKA “strategy first, execution second”). On the flip side, customer experience, customer intelligence, and digital marketing professionals are unlikely to put code considerations up front — or anywhere in the top 10, for that matter — and thus AD&D needs a voice when mobile strategy is discussed (AKA “iterative strategy should be based on execution feedback loops”).
I spoke with the “two birds with one stone” exec after the presentation and he clarified: If the use cases for the adaptive mobile site and a mobile app are largely the same, then it makes sense to leverage the hybrid app code base as your mobile website. OK, that makes sense now: The content and audience will be the same, and therefore repurposing the code base is a worthy effort.
My takeaway: A great deal of confusion persists around mobile — even when experts present to informed audiences. Forrester has been thinking about this question re: mobile development at length to help reduce the confusion:
I hear people talking about Agile 2.0 a lot. But when I look at what’s happening in the application development and delivery space, I see that many organizations are just now starting to experience Agile’s true benefits, and they’re not yet leveraging those benefits completely or consistently. So let’s stop talking about Agile 2.0 for a moment and instead digest and operationalize what’ve learned so far. There’s plenty to improve upon without getting into inventing new practices and acronyms to add to the Agile transformation backlog!
What I see is that app-dev leaders want to understand how they can optimize existing use of AD&D Agile practices like Scrum, XP, Kanban, improve the practices around the more advanced ones like TDD, continuous testing, CI and CD and leverage all with what they’ve learned over the years (including waterfall). Scaling the whole thing up in their organization in order to have a bigger and more consistent impact on the business is what their next key goal is. We fielded the 2013 version of our Global Agile Software Application Development Online Survey to find out how. I present and analyze this data in my latest report. The survey addressed common questions that clients ask me frequently get in inquiries and advisory, such as:
How can we test in a fast-paced environment while maintaining or improving quality?
How can we improve our Agile sourcing patterns to work effectively with partners?
Microsoft was kind enough to invite me to its fall analyst event at its headquarters in Redmond, WA on October 22. It’s a two-day event packed with product, strategy, customer, and partner information. About two dozen industry and independent analysts attended this event, including Forrester’s Paul Hamerman. Here are my thoughts of this event with a focus on the CRM news:
The Dynamics product is doing well. The numbers speak for themselves: 12% revenue growth in FY13; Dynamics AX and CRM growing by double digits worldwide and 30% in the Americas and Asia; and CRM Online growing by 80% in FY13, with two out of every three new customers opting for cloud. Microsoft Dynamics has 359,000 customers and 5 million users, while Microsoft Dynamics CRM has 40,000 customers and 3.5 million users.
The Microsoft Dynamics CRM 2013 product solidifies.The Dynamics CRM 2013 product, available in the cloud in July and on-premises this month, delivers a cleaner, more usable UI, simplified data entry, an integrated business process workflow, consistent experiences across devices, integration of Yammer, and more. A writeup of the new version’s features are available in its release preview guide. These enhancements mature the product, yet still leave gaps in multichannel management, knowledge management, and web self-service.
Hadoop’s momentum is unstoppable as its open source roots grow wildly into enterprises. Its refreshingly unique approach to data management is transforming how companies store, process, analyze, and share big data. Forrester believes that Hadoop will become must-have infrastructure for large enterprises. If you have lots of data, there is a sweet spot for Hadoop in your organization. Here are five reasons firms should adopt Hadoop today:
Build a data lake with the Hadoop file system (HDFS). Firms leave potentially valuable data on the cutting-room floor. A core component of Hadoop is its distributed file system, which can store huge files and many files to scale linearly across three, 10, or 1,000 commodity nodes. Firms can use Hadoop data lakes to break down data silos across the enterprise and commingle data from CRM, ERP, clickstreams, system logs, mobile GPS, and just about any other structured or unstructured data that might contain previously undiscovered insights. Why limit yourself to wading in multiple kiddie pools when you can dive for treasure chests at the bottom of the data lake?
Enjoy cheap, quick processing with MapReduce. You’ve poured all of your data into the lake — now you have to process it. Hadoop MapReduce is a distributed data processing framework that brings the processing to the data in a highly parallel fashion to process and analyze data. Instead of serially reading data from files, MapReduce pushes the processing out to the individual Hadoop nodes where the data resides. The result: Large amounts of data can be processed in parallel in minutes or hours rather than in days. Now you know why Hadoop’s origins stem from monstrous data processing use cases at Google and Yahoo.
The bank I mainly use for my daily banking needs does not offer that many examples of great customer experiences. The two reasons why my family continues to use that bank are the high number of ATMs in the area where we live and a very customer-oriented branch advisor. Our most recent interaction with that bank (but not with that advisor) delivered yet another example of “great” customer service across channels, an experience that will likely cause us to look for a new bank. The chances that this yet-to-be-determined bank can offer better cross-channel capabilities at least at some point in the future are not bad at all: Many financial services firms are evolving beyond using just a single channel to get in touch with their customers (see the figure below).
To succeed in the age of the customer, IT leaders that that support “front-office” business processes cannot afford failed technology initiatives. In recent blogs, I have been sharing the results of a recent survey of practioners to define and quantify the best practices for CRM success.
Working in partnership with CustomerThink, Forrester collected opinions from more than 600 individuals who had been involved in a CRM technology project as a business professional in sales, marketing, customer service, or IT. Previously, I reported that our data show that CRM technology deployments require a balanced and multifaceted approach that addresses four critical fundamentals: process, people, strategy, and technology.
Notwithstanding the relative maturity of the CRM solutions available on the market today, more than one-third (35%) business and IT professionals that we surveyed report specific technology snares that you must navigate around.
The top technology challenges to implementing a CRM solution include difficulties in consolidating customer data (45%); lack of the skill sets required to implement and support the solution (45%); poor usability of the CRM solution (34%); system performance shortfalls (32%); perceived functional deficiencies in vendor solutions (29%); and integration challenges (25%). These can become key roadblocks to the effective use of CRM solutions to achieve better business outcomes.
Good customer service is the result of the right attention to strategy, business processes, technology, and people management. This seven-post series focuses on customer service technology and explains the what, why, how, and when technology questions.
Part 1 reviewed the customer service technology ecosystem.
Part 2 reviewed the challenges caused by the complexity of this technology ecosystem.
Part 3 reviewed the tactical outcomes of poor customer service.
Part 4 focused on the ways that the customer service technology ecosystem is changing.
Part 5 categorized technologies based on their ecosystem maturity.
Part 6 focused on what this analysis means to customer service managers.
In this final post, I will focus on where do you go from here, now that we know what the core customer service technologies are, how mature they are, and what their business value is. I recommend a three-step process:
On the one hand, I saw highly prescriptive, standardized, catalog-type collections that fit well together but which are rather boring and maybe don’t make the best of my ramshackle old house. On the other hand, I visited a lot of junk shops with interesting but incompatible pieces, ranging from a Victorian birdcage (really!) to an Art Deco lampshade. It made me think about the challenges that application development and delivery professionals face in formulating application portfolio strategies.
When should they single-source and when should they choose a best-of-breed strategy? For which applications should they consider SaaS solutions? What is the best way to use systems integrators to help reach a target portfolio at the lowest opportunity cost?
Join us at Forrester’s Forum for Application Development and Delivery Professionals on October 17 and 18 in Indianapolis, where my colleagues Paul Hamerman, Liz Herbert,and Jost Hoppermann will be discussing their research into application portfolio strategy. and answering questions about applications portfolio transformation such as:
What’s the difference between application upgrade and transformation?
Where do you find the help you need for applications portfolio transformation?
If technologies like mobile, social, and in-memory analytics are so important, why don’t we deploy them ourselves? Why are we waiting for vendors to bundle it with their releases?