Microsoft prepares to deliver new Dynamics CRM capabilities

Microsoft yesterday announced that it will release new capabilities in the Q2 2014. Redmond Channel Partner’s Gladys Rama provides an overview of what to expect. The updates are based on technology acquisitions by Microsoft over the past year or so.

Pivotal 6 Service Pack 11

Pivotal 6 Service Pack 11 is just days away and here are a few highlights in this new release:

  • Support for rich client in the browser – this should ease the transition from 5.9 to 6
  • Better pricing for SMB (which approximately applies to user counts of less than 40)
  • iPad app – check out the video
  • …still no floating licenses but we can dream, eh?


Pivotal 5.9 support update

Not too surprisingly Pivotal 5.9 is still deployed widely and remains popular, so “how long will it be supported” is a key question for many.

CDC Software has recently let it be know that 5.9 support will follow support by Microsoft for Windows — up to Windows 7. So as Windows versions, such as XP, are end-of-lifed, so shall 5.9 meet a similar fate.

Since Windows 7 seems like a very popular replacement for Windows XP and the generally unpopular Windows Vista, it bodes well for a long life. This is further likely as Windows 8 seems set to present some radical changes in user experience, which no doubt will be steadfastly resisted by the corporate universe.

For some, the upcoming support for rich clients in Pivotal 6 will speed up and smooth the transition from 5.9, but to know that there is clear support for 5.9 for a while will be a relief to many others.

Microsoft switches to Dynamics CRM

Microsoft has been using Siebel CRM for years, but has now successfully switched to its own Dynamic CRM. This article in InformationWeek by Josh Greenbaum discusses the implications. It will be interesting to see what a little dog-fooding will do for Dynamics CRM.

Dashboard Dangers: Old and New, Part 1

Very few people can remember when dashboards were not an indispensable part of business intelligence (BI). Since the Web started playing its current role in our lives in the late 1990s, dashboards became one of the focuses of BI efforts. Surely, after so many years of evolution, the science of dashboards must be perfected and common pitfalls documented and avoided, right? Wrong.

As almost anything within business intelligence domain, dashboards are still more art than science, mastered by the talented and skillful. Despite the fact that everyone wants them and the proliferation of tools and techniques, perfect dashboards stay elusive and still require as much effort to create as ever. It is important to understand why and be prepared, for both producers and consumers of dashboards. There are some factors in play as old as a concept of dashboard itself, and there are some new ones that started emerging recently.

The presentation danger

Dashboards are glamorous. The old adage that “a picture is worth a thousand words” is demonstrated through dashboards in all its glory. A well presented dashboard allows fast processing parts of our brains to understand situations and make decisions within seconds. The presentation of information and facilitation of decision making processes are the main purposes of dashboards, and as such, they have to be approached the most carefully.

One would hope that your BI efforts have been well defined and delivered, and the data behind your dashboard is reliable, clean and consistent. If it isn’t, all other dashboard concerns are irrelevant.

The most accurate and consistent data is just a bunch of numbers and there are as many ways to represent it as there are pieces of information you collect. A very common mistake is to take the available figures and concentrate on presenting them without first defining the reasons and goals for putting that data on a dashboard at all. A pie chart or a graph? Old fashioned gauge or a series of bullet charts? It is assumed that if a business already collects numbers that are supposedly relevant, reporting on them will benefit business. This approach does not necessarily lead to failure but it will not lead to great success either.

A second approach which sadly is still not the most popular is to start with the strategy, forgetting about the figures for a while. Questions must be asked about what a business is trying to achieve, what will create real value, and which numbers will help to reach that goal. The numbers themselves need to be analysed to understand if they are as accurate, relevant and meaningful as required by the strategy. Only then can candidate data be selected and its presentation defined. This approach can lead to some lengthy discussions which might at time be seen as waste of time and budget, but in a long run it will deliver better business intelligence and better business practices.

The TV effect

Anyone who ever tried to tell a story knows that there must be just the right amount of details for every genre (are you writing a novel or a newspaper column?), and if the story has too much of what is perceived as irrelevant, the meaning will be lost. Users are not supposed to spend hours analysing dashboard information, it has to be perceived quickly and effortlessly. Which necessarily leads to selection of most relevant information and often, oversimplification. I call it “TV effect” by analogy with a simplified reality TV presents to people, where real life is reduced to a set of labels and the viewers do not choose which labels to apply.

One outcome of oversimplification is reliance on top level picture and neglect of lower level details and underlying causes. If the indicator for sales in one region is green and red in another, we are immediately called to action by red light and soothed by green. But what if the first region is missing some large opportunities while still meeting its sales targets? One answer is to develop more indicators, thus increasing complexity. Another answer is to review the lower level details and periodically re-evaluate criteria for relevancy and accuracy.

Another outcome of oversimplification is a tendency for early conclusions and premature changes of course. It is unnerving to be faced with red indicators for any prolonged period of time. An almost flat or slightly falling real time graph of new product sales might lead to a decision of abandoning the product earlier than it would happen with a different reporting approach. True, this can be a blessing and allow a business to minimize its losses. But what if an original decision would yield positive results given more time? One answer can be more data, another – setting relevant goals and keeping them in mind when making decisions.

Business decision makers have to remember that dashboards are only a tool and any tool is only good if it serves its purpose.

To be continued.

Getting more out of your systems through data integration

All your systems — CRM, website, accounting package, etc. — contain extremely valuable information. But for many companies (maybe most?), these are islands of information, between which communication is like a row boat paddling its way from one island to the next. Maybe it’s an exported CSV file that paddles your latest customer information from your CRM over to your accounting system. But however it happens, it takes time, mistakes happen too easily, and it’s a one way trip — any changes made on the accounting island makes have a hard time making it back to the CRM island. Data integration solves this.

Before networks, the information islands were physically disconnected, but in effect not much has changed. Using the network to transfer the CSV file to the other computer instead of a floppy disk is no real gain when the real work is getting the data into the target system without making a mess. And usually only one person really knows how to do that, so when Bob is on vacation the whole process takes vacation too.

If your company is really big there’s no problem, you can spend the pile-o-cash to get the fully customized integrated six-ways-to-Sunday solution. Let’s focus on solving this for everyone else.

Most system now have ways to send and receive data in a structured manner, it may be an API (application programming interface) or web service, which means that a programmer can write some code to talk to the application instead of using the user interface. If two systems have these data pathways, it’s possible to create a connector so information can be shared automatically. Of course, the more systems you have that you want talking together, the more programming has to be done, and it can get a little gnarly, but the end result, if done with thought and planning, can save lots of time, errors and headaches. The islands are now connected in the ways that makes sense your business, and Bob can go on vacation whenever he wants.