For many of my clients, 2009 was a difficult year as they struggled in response to the sudden and dramatic downturn in the economy. Although many CRM technology projects were deferred or cancelled last year, I see this trend being strongly reversed in 2010. Every day I get calls from companies large small who tell me that they now releasing funds to invest in improving their customer-facing business processes neglected during the past 18 months.
The underlying trends driving the need for effective and efficient customer management processes have not disappeared. In fact, the need for companies to effectively engage with their customers has never been more important. Locking in customer loyalty through deeper engagement and differentiated experiences will continue as critical priorities, but navigating the complex CRM solution vendor landscape and organizing projects for success will continue to be challenging. In 2010, you must focus on choosing the best opportunities for quick wins carefully, spend wisely on the right CRM solutions, and manage project risk. Take advantage of Forrester data, methods, and tools to capitalize on the improving economic climate to drive top-line growth.
I have designed this webinar offer you a roadmap to the specific Forrester data, techniques, and tools that you can immediately put to use to implement our six-step methodology for CRM success.
1. Understand the customer of the future
2. Define the right CRM strategy and priorities
3. Build a rock-solid business case
4. Risk-proof your project
5. Resolve customer data management dilemmas
6. Negotiate the right software pricing and licensing agreements
Here is the link to the registration page. You do not have to be a Forrester client to join in.
Last December I wrote about Building B2B Technology Markets, looking at how to penetrate a market with almost none of the traditional characteristics of a mature technology market? As technology vendors increasingly look to emerging markets as a significant opportunity and source of growth, this question becomes more pressing. The report explored some of the elements of Cisco’s Country Transformation initiatives in order to identify steps in the process of building market infrastructure:
For example, the report looked at partnering with governments to encourage market-friendly policies and investment in the necessary technology infrastructure to support market development and overall economic growth. And, from a sales perspective, trade associations provided an alternative channel to reach small and medium businesses in markets where distributors and resellers weren't available.
But, another element critical to successful market development is the ecosystem of partners developing solutions specific to the particular market, or even just contributing local innovation for new approaches to broader global issues. Building B2B Technology Markets discussed finding local organizations to act as partners in the market, and even investing in educational initiatives, but missed the next step of how to help create these new local ecosystem partners.
During a recent set of interviews with IT service providers on how they help their client’s innovate, I had the opportunity to speak with K Ananth Krishnan, CTO at Tata Consultancy Services (TCS). Ananth described to me what I consider to be one most progressive innovation programs I encountered during these interviews – it was consistent with TCS’s capabilities, holistic in scope, and has the potential to be a important part of the company’s long-term evolution.
A few key findings from my discussion with Ananth:
Today, Oracle announced yet another acquisition - this one of Phase Forward, a clinical research suite that helps life sciences companies manage their R&D process. Oracle paid $685 million in cash for this acquisition. While my research role focus does not encompass life sciences software specifically, Oracle's overall apps strategy is definitely of interest to me. My thoughts about this deal are as follows:
Oracle continues to aggressively acquire industry-specific applications to complement its core ERP solutions (e.g., EBS, PeopleSoft, J.D. Edwards, and the yet-to-be-released Fusion Applications). Industry apps enable Oracle to achieve deeper relevance with specific types of businesses, and sell them additional products, including middleware, integration accelerators, BI, databases, core ERP applications, and now even computer hardware.
The Phase Forward clinical trials software puts Oracle into the mix in large pharma accounts, where SAP tends to have the lion's share of the wallet for applications.
Healthcare overall is a massive market opportunity for which Oracle has only scratched the surface. Oracle only recently established a Health Sciences Global Business Unit, and more acquisitions can be expected in and around the healthcare ecosystem. Healthcare provider solutions may fit into this build-out at some point.
Your thoughts on Oracle's apps strategy and portfolio? Feel free to comment here.
Recently, I discussed complexity with a banker working on measuring and managing complexity in a North American bank. His approach is very interesting: He found a way to operationalize complexity measurement and thus to provide concrete data to manage it. While I’m not in a position to disclose any more details, we also talked about the nature of complexity. In absence of any other definition of complexity, I offered a draft definition which I have assembled over time based on a number of “official” definitions. Complexity is the condition of:
Late last year, Forrester published a “big idea” research report identifying Product-centric Development as a distinctive, value-based approach to software development characterized by highly-successful commercial software companies. As part of this research, we made the call that product (or service) centricity can occur regardless of whether internal or outsourced resources do the bulk of the work – rather, it is a team’s orientation to the company’s value chain, their partnership with customers and business stakeholders, and the ownership for the business results that their software ultimately delivers that are all really the more important, defining characteristics of a ‘product-centric’ development shop.
Recently, I came across a great example of this kind of high-value development work spanning internal and external resources in Dr Pepper Snapple Group’s (DPS) partnership with HCL. Why does this mixed-development model work? Two key success factors include:
- HCL’s service delivery team is continually in step with DPS’s business environment. By staffing dedicated service delivery managers (SDMs) on site, DPS can call on HCL to help tackle both strategic management issues, such as reducing shrinkage and achieving on-time delivery, and day-today problems, such as app latency and downtime, with a "one-stop-shop" liaison who can own the problem and seek resolution across technology silos.
Recently, I’ve been getting more inquiries around risk based testing. In addition to agile test methods and test estimation, test teams turning their eyes to risk based testing is just another positive step in integrating quality through out the SDLC. Yes, I still see QA engineers as having to put their evangelist hats on to educate their developer brothers and sisters that quality is more than just testing (don’t get me wrong, consistent unit and integration testing is a beautiful thing), however, any time that business and technology partners can think about impact and dependencies in their approach to a solid, workable application elevates quality to the next level.
Keep asking those questions about risk based testing – and make sure that you’re covering all of the angles. Make sure that you’re covering:
This week, I talked with an IT group that had an organizational unit called “IT Business Management” with the charter to help IT run like a business. Well, it’s about time! I know a lot of IT strategists and consultants push the idea that IT should be an integral part of the business and shouldn’t be thought of as an independent organization. And that may be what it should be, but it’s not what it is today. Today’s IT is by and large a separate organization even when it is distributed across multiple business units.
In many companies IT is a large, complex business unit in its own right with a significant chunk of the business’s operating budget. When CIOs control hundreds of millions of their company’s dollars, shouldn’t they be thinking about what business value they are delivering on that capital? And isn’t a great way to do that by looking at and managing IT like a business?
When I first started talking about building a capability model for IT, I received a lot of blank stares and comments like: “Why would anyone want to do that?” My question is: ”Why wouldn’t everyone want to do that?” IT execs spend a significant portion of their time managing business demand to fit current IT resources but very little time improving IT’s ability to respond to increasing business demand. An IT capability model provides an excellent starting place to view IT like a business and identify what is most important to IT’s success and where to invest the few dollars we have to make it better. Many architects I talk with are having real success with business executives using capability maps to focus the conversation and their attention on what parts of the business are most important. With an IT capability map, we can do the same thing for IT.
The word for “crisis” in Chinese apparently comes from two roots meaning “risk” and “opportunity” – there is both a downside, and the potential for an upside. That’s how César Alierta, Telefónica Chairman and CEO, began the opening keynote of their 2010 Leadership Conference in Miami (where I spent several days last week). For Telefónica, that definition has played out with the global economic crisis. While results in Spain have been their downside, Latin America has been the opportunity. Telefónica has a presence in 15 countries in Latin America (and 42 countries worldwide), with offerings in mobile and fixed telephony and in IT services. Not all offerings are available in all markets but in many countries Telefónica has leveraged a strong position in one offering to expand into the others becoming the first integrated operator in the region.
According to José Maria Pallete, CEO of Telefónica Latinoamérica, Latin America represents 65-70% of their total customer base, 40% of revenues and about 40% of the operating income. In the enterprise space (as opposed to consumer services), 37% of Telefónica revenue comes from Latin America. That corporate segment (including public sector) marked double digit growth in Latin America in 2009, with its biggest markets in Brazil and Mexico.
A couple of days ago, Texas Stadium was reduced to a pile of rubble. Wow. The former home of my Dallas Cowboys, the site of victories and record-setting performances — gone in a matter of minutes. Was I sad? Yeah. But also a bit relieved. The Cowboys have moved to their new, super-duper (and quite ostentatious) stadium, Texas Stadium memorabilia has been auctioned off, and the poor, neglected building had become quite an eyesore.
Sometimes destroying something unusable is the best way to move forward.
Run that statement past your approach to documenting software requirements. When was the last time you took a step back to evaluate how your organization represents requirements? If it’s been awhile and your business analysts are still delivering massive, text-heavy, all-encompassing business requirements documents (BRDs), it’s time for some demolition of your own.
Why? Compelling forces have converged, drastically changing the way application development teams author software requirements. Organizations are recognizing the connection between software failure and poor requirements, and authoring better requirements has become a major initiative in many firms. At the same time, Lean and Agile are front and center, so right-sizing requirements documentation is on everyone’s radar. Bottom line, you need to do more with less: author stronger requirements while minimizing waste and being as lean as possible.