Despite the popularity of CRM solutions, business process pros tell us they still struggle with how to define the right customer management strategies, re-engineer customer-facing business processes, and effectively acquire and deploy the right supporting technology solutions that will meet their needs. Looking ahead, what trends will dominate the planning agendas of business and IT professionals responsible for transforming customer-facing business processes in 2011? Here is a summary of the 12 trends and links to our key research reports for those who want to take a deep-dive into the underlying Forrester data and analysis.
Trend 1: The negative revenue impact of poor multichannel customer experience is recognized.
Social networking is hot, and it’s smart to think about how your organization might use it to generate benefit equal to the market hype. As you develop your social technology strategy, it’s particularly important to steer clear of a fallacy of thought that often creeps into technology strategies for enterprise communication and collaboration.
Oftentimes, an enterprise social strategy, like enterprise collaboration strategies before them, will have among its goals a phrase suggesting that the technology should “change the way people communicate.” Superficially, this phrase may accurately describe part of the effect, but at a more fundamental level, it violates a very important change management principle. To make my point, I’ll back up and start with a little history.
I used to communicate via paper memos and phone calls, but it was cumbersome and time-consuming. Email has come to replace much of that. So, the “way I communicate” has changed, right? On the face of it, yes, but, looking more closely, not really, at least not at first. Compared to my “before email” days, I still communicate the same types of things with the same kinds of people — only email made these communications easier (for the most part). I started using email because (1) it could improve the existing way I communicated and (2) it fit my work and life context — it was just a new program to use on my handy desktop PC. Once email became part of my context, I realized that I could use it for communications that were too costly before. At this point, it did, to a degree, change the way I communicate.
There are blog posts that you can write without doing any prior work (he says, looking meaningfully at himself in the mirror), and then there are blog posts that require real work. This very interesting post about how the Facebook development organization operates is in the latter category. Instead of pointlessly summarizing the author's findings, compiled from sources who know Facebook from the inside, I'll add a few reactions:
If, as reported, the development team comprises about a quarter of the company's employees (and operations another quarter), that's an unusually high ratio for any tech vendor, whether or not it's in the software-as-a-service (SaaS) business. At salesforce.com, R&D comprises 15% of the company, which is high for the tech industry. Facebook's 25% R&D is staggeringly high.
Even though Facebook regularly confuses the heck out of the people with changes to security features, the company does pilot features before shipping them.
Facebook developers bear a lot of responsibility for their own code, across many dimensions of quality (design, testing, justification, etc.).
The ops team has a more gradual approach to deploying new code than it might appear.
During one of my gigs as a product manager, an executive in our company was overjoyed to have a US Defense Department client. He was eager to land a reference customer, but he fundamentally misunderstood how easy it would be to get a military organization to join the ranks of success stories. He wrongly assumed, in this very hierarchical organization, successful adoption of our collaboration tool was the simple process of (1) the general in charge ordering people to use it, followed by (2) people under his command dutifully using it. The military doesn't work that way, in large part because, when faced with a bad order that might kill them, military professionals learn how to wriggle out of these diktats. (Which is why there's a fine line between initiative and insubordination.)
Even if our executive's assumptions about how the military operated were correct, that formula might spell doom for the project. What happens when the general in charge moves on to another post? No assignment is forever, and the next officer in charge might have a far lower opinion of our product. The crisis might happen earlier, if the current general got impatient with the progress of the project. Fearful of these potential outcomes, this executive bet the entire project on maintaining good relations with the general and his immediate subordinates, including the irascible project lead, whose view of technology adoption was summarized in his comment during a meeting with us: "Users are stupid, so they don't know what they want."
I get many inquiries on the differences and pros and cons of MOLAP versus ROLAP architectures for analytics and BI. In the old days, the differences between MOLAP, DOLAP, HOLAP, and ROLAP were pretty clear. Today, given the modern scalability requirements, DOLAP has all but disappeared, and the lines between MOLAP, ROLAP, and HOLAP are getting murkier and murkier. Here are some of the reasons:
Some RDBMSes (Oracle, DB2, Microsoft) offer built-in OLAP engines, often eliminating a need to have a separate OLAP engine in BI tools.
Some of the DW-optimized DBMSes like Teradata, SybaseIQ, and Netezza partially eliminate the need for an OLAP engine with aggregate indexes, columnar architecture, or brute force table scans.
MOLAP engines like Microsoft SSAS and Oracle Essbase can do drill-throughs to detailed transactions.
Semantic layers like SAP BusinessObjects Universe have some OLAP-like functionality.
Businesses, in 2011, are refocusing on strategies that differentiate them from their competitors. One way to do this is by focusing on customer service. We see that organizations are ramping up their multichannel customer service initiatives. In fact, 90% of customer service decision-makers told Forrester last year that a good service experience is critical to their company’s success, and 63% think the importance of the customer service experience has risen. However, customer expectations are getting higher. Customers are increasingly online, want self-service options, and demand responses in real time, often through their mobile devices. Moreover, social media, such as Twitter and Facebook, has grown to be an important new channel for interacting with customers and engaging in innovative ways.
To meet these challenges, organizations continue their search for solutions to address their most pressing customer interaction management problems. Leaders of customer service and product support organizations tell us that they want to strengthen five key capabilities:
Delivering the same customer service across communication channels. It is critical to standardize the resolution process and customer service experience across communication channels (email, phone, web self-service, chat, etc.)
Empowering agents and customers with knowledge management (KM) tools. Advanced knowledge management and search tools are a critical necessity for delivering contextual, personalized self-service and agent/customer experiences.
Supporting agile customer service with a strong foundation of business process management. Organizations are extending BPM to customer service to standardize service delivery, minimize agent training times, ensure regulatory and company policy compliance, and control costs.
Java’s future will be constrained by the bounds of Oracle's business model.
Drama has been running high since Oracle began to shape up the Java technology it acquired along with Sun Microsystems. Oracle ended the impasse over a new core Java release, set out a road map for the next two years, and began reorganizing Java's ineffectual governance. Oracle's Java road map and commitment to invest reassured enterprise customers and prevented a split with IBM but alienated many in the open source community. But Oracle's plans so far fail to address Java platforms' inherent complexity, which remains Java's Achilles' heel in head-to-head competition with Microsoft's.NET platform. Moreover, a controlled, top-down innovation model will limit Java's role as the basis for the "cloud" generation of platforms, rich Internet applications, and new development techniques ranging from languages such as Ruby to approaches such as business process management (BPM) and business rules. Conclusion: Java's future in the enterprise is alive and well but limited.
Oracle’s strategy for Java will change the Java ecosystem that has existed for 11 years.
Oracle will direct Java innovation. Oracle has made it clear that from this point forward, it will direct all innovation in core Java (Java SE). Oracle will happily accept the contributions of others through OpenJDK as long as those contributions align with Oracle's priorities.
With the seventh generation of its WebSphere software, IBM redefines the state of the art in Java platforms for the enterprise.
The WebSphere 7 product family provides application development and delivery pros with new ways to optimize their application architectures, more development frameworks, automatic transactional reliability, simpler configuration and management, and improved stack integration for BPM, portal, and eCommerce projects. For shops struggling with scale, complexity, and high performance in their Java applications, WebSphere 7 may offer both relief and a simpler, easier-to-manage stack. WebSphere 7 also lays the foundation for cloud architectures and multicore hardware.
IBM, Oracle, and Red Hat JBoss will play leapfrog in Java platforms for the foreseeable future. But clients should evaluate the three leading vendors of Java platforms based on their primary goals for their software, not just by comparing features (and certainly not by comparing public benchmarks). With WebSphere 7, IBM has created a transaction monitor for Java. This goal reflects IBM's primary goals of reliability, integrity, and manageability in WebSphere. In this way, WebSphere is IBM's CICS for the Internet age.
IBM's second primary goal is to create integrated platform stacks. The WebSphere Process Server-WebSphere ILOG-Business Space-WebSphere Application Server combination is one such stack; WebSphere Portal and WebSphere Commerce are other integrated stacks.
Customers should always check the reality before assuming comprehensive integration in IBM's burgeoning WebSphere portfolio. Stack integration will always be a moving target for customers because IBM adds so many acquisitions every year. But IBM's product management regime makes it fairly easy for clients to identify which IBM stacks have high internal integration and which do not.
Another excellent post from Scott Sehlhorst, this time pointing out that, even without product managers, product management still happens. Scott’s post is a response to Jason Calcanis, the founder of Mahalo, who wrote the following:
In under 30 days, we completely overhauled our product-development process, removing everything between the developer and iterating on the product. We eliminated positions and process. We made it clear the developers were to make the decisions even if those decisions resulted in a developer being 50 percent slower because they were busy *thinking* about the product (as opposed to just transcribing features from the product manager wireframes).
If Calcanis is arguing that his company doesn’t need product managers, because they just are in the way, Scott makes the obvious counterargument:
When I was still writing software and leading teams that were writing software, I would occasionally point out that all software is designed – even if someone sits down and just starts typing code. There is, at the minimum, implicit design happening in the mind of the programmer. It might not be “good” design, but there is always design. There is always a method to the madness, just not always a considered method. The same is true of product management...Eliminating product managers does not eliminate product management.
It's nice to see that SAP has managed the turnaround to leave the recession behind and pick up growth again. The company reported a strong 34% SW revenue growth in Q4 2010 as compared with the previous year - "The strongest software sales quarter in SAP's history" as stated by Co-CEO Bill McDermott. However, one has to keep in mind that one year ago SAP was in deep crisis and reported a YoY -15% SW revenue decline in Q4 2009 followed by the departure of CEO Léo Apotheker in February 2010 and other subsequent executive changes.
Indeed Q4 2010 was the strongest SW sales quarter in SAP's history but the fourth quarter is always the strongest in SAP's annual sales cycle. Actually Q4 SW revenue declined for 2 years since 2007 (€1,4 billion) to 2008 (€1,3 billion) to 2009 (€1,1 billion), and it was about time to turn around the curve again. While Q4 2010 was the best SW revenue quarter, the full year 2010 was still not the best in SAP's history. In 2007, SAP reported total SW revenues of $3,4 billion, followed by 2008 (€3,6 billion), 2009 (€2,6 billion), and now total SW revenue 2010 with €3,3 billion – SW revenues are still below the level of 2007! While total revenue (€12,5 billion) looks to be back on track, net new SW license revenue still remains a challenging point in SAP's balance sheet!
The new Q4 2010 revenue announcement is a very positive and promising signal, but the company needs to continue to innovate its portfolio to accelerate again new SW revenues for long-term sustained growth.