I get a lot of inquiries asking me to name the best CRM professional services providers (PSPs). Business and IT managers worry about the cost and risk of failure when engaging consultants and systems integrators to improve the performance of their mission-critical customer-facing business processes.
Organizations entrust PSPs with important tasks – not just "screwing in software.” In a survey of 119 companies I did a few years ago: nearly 28% used PSPs to help develop their strategic vision for CRM, 42% used PSPs for defining business objectives for CRM, 44% for aligning business processes with the CRM strategy, and 56% to define the conceptual design for CRM technology solutions. PSPs were used by 60% of enterprises to establish detailed design requirements and by 64% to implement CRM solutions.
However, there are huge risks to working productively with CRM consulting or systems integration providers. In the same study, I found that four out of 10 would not recommend their CRM PSP to others after the work was completed.
I recommend that you use 12 evaluation criteria to increase your odds of success. How well does your CRM PSP stack up against these standards?
Demonstrable knowledge of the technical characteristics of CRM applications. This is the most important of the 12 criteria. Business and IT executives expect their PSP to bring an expert understanding of the specific CRM applications and related technologies to the projects they are engaged to support.
Demonstrable knowledge of the requirements of the industry. Organizations expect their CRM PSP to have a deep knowledge of the business challenges in their industry and insight into unique sector characteristics and to be familiar with industry jargon and culture.
As much fun as the juicy details of the Oracle-Google lawsuit are, the meaning of the suit for enterprise application development managers is, well, philosophical. Aside from sweating over the legal status of your Android phone (if you own one), the lawsuit won’t create drama for your shop. But the long-term implications are serious. Henceforth, Java will be a marching band rather than a jazz collective. Oracle’s action will reduce the independent innovation that has made Java what it is, causing developers to seek new ideas from sources outside of Java. Your Java strategy, as a result, will get more complicated.
A little background: Since the late ’90s, the primary source of Java innovation has been open source projects that either fix Java limitations or provide low-cost alternatives to vendor products. But Java’s position as a wellspring of innovation has been declining in recent years as many Web developers shifted their attention to dynamic languages, pure Web protocols, XML programming, and other new ideas. This trend has been particularly pronounced in the client tier for Web applications, where alternative rich Internet application technologies including Ajax frameworks like Dojo and container-based platforms like Adobe Flash/Flex have replaced client-side Java. Java virtual machines are a foundation of these efforts, but the enterprise and mobile Java platforms are not.
In choosing Java’s future course, Oracle had two philosophies to choose from.
Open source software (OSS) and business intelligence (BI) are two related market segments where Forrester sees continually increasing interest and adoption levels. BI specifically continues to be one of the top priorities on everyone's mind. The main reason? Enterprises that do not squeeze the last ounce of information out of their data stores and applications, and do not focus on getting strategic, tactical, and operational insight into their customers, products, and operations, risk falling behind competition. And when it comes to open source, 2009 could best be described as "the year IT professionals realized that open source runs their business." The reason is simple: Over the past few years, we've seen that developers adopt open source products tactically without the explicit approval of their managers. This has shown up in numerous surveys where the actual adoption of open source ranks higher than what IT managers report. Well no longer: Forrester's Enterprise And SMB Software Survey, North America And Europe, Q4 2009 shows that management has caught on to the fact that developers increasingly use open source to run key parts of their IT infrastructure. And management has grown increasingly comfortable with it. In fact, throughout 2009, most client inquiries Forrester received regarding open source were focused on how to move from tactical adoption to strategic exploitation.
Yet, when you put the 2 and 2 together (OSS and BI), you mostly get a mixed market, where one unfortunately has to compare apples to oranges. Why? Before plunging into a tool evaluation and selection process, ask yourself the following questions, and make sure you are doing a like-to-like comparison:
During a vendor conference, I sat down with 12 application development professionals and asked them a very simple question: "What will be the biggest themes for application lifecycle management be in the next 5 years?" The resulting debate and discussion highlights some key areas that application development professionals should look to when building their ALM strategy.
Who owns the code?
The reality of open source, partner-developed code and vendor value add-ins was not lost on the group. The overarching theme from this discussion was that customer organizations not only need to own the overall supply chain but also are responsible for ensuring its quality. That means, as writing code decreases, inspection, validation, and testing increase. The result is that traceability, workflow, and reporting are inclusive of customer code but also supplier code. For example, defects with an open source project need to be captured, shared, and tracked in a similar way to internal defects. The difference is that, unlike with internal development, those defects will also feature in the open source project and be fixed by people outside of the customer's organization. The implication of licenses and IP ownership was discussed, with one in the group painting a very bleak picture. He described a scenario where because of the result of one massive IP infringement a company is forced to stop operating, with the resulting fallout being a massive, wholesale movement away from open source software and associated complex IP and licensing issues. Though this example was extreme, the group agreed that licensing should be part of the governance for any ALM solution. This increased complexity of code ownership will require ALM solutions to: