Over the years, I've recieved several emails from users of FetchXML Builder about how to pull the data retreived by CrmService Fetch method into variables. When you use FetchXML Builder, you will see rather quickly that the results are returned as XML so it makes sense to use the XmlDocument class to manipulate this data. So start by placing a "using System.Xml;" clause at the top of your C# file and modify the code below to fit your needs.

string result = service.Fetch(fetchXML);
string attributevalue;

XmlDocument doc = new XmlDocument();
doc.LoadXml(result);

foreach(XmlNode node in doc.DocumentElement.ChildNodes)
{
     attributevalue = node.SelectSingleNode("mycrmattribute").InnerText;
}

Whenever business users make a request to IT for a new business application, the traditional choice has been to build or buy. Cloud computing added a variation on the theme, to buy or build in the cloud. Line-of-business application platforms like Dynamics CRM provide a third choice, which falls someplace between buying and building. It is like buying in that there are licenses and some out-of-the-box functionality. It is like building in that you will need to define new entities, attributes and relationships, new workflow processes, and new user interfaces.

The advantages that Dynamics CRM has over building an LOB application from scratch using a programming framework like Java or .Net is that it makes it possible for business analysts, or other non-programmers, to build basic applications on their own and enables developers to build applications in dramatically less time. I listed many of the features that make this possible in an earlier post on XRM.

While Dynamics CRM cannot in all cases effectively substitute for specialized LOB applications, it does offer quite compelling advantages that make it worth considering.

Licensing
Licensing is the first obvious advantage. Rather than paying licensing fees per user per application, each user requires only a license to Dynamics CRM. No matter how many additional applications an organization builds on top of Dynamics CRM, no additional licenses are required.

Maintenance
Building applications on top of Dynamics CRM as opposed to buying multiple proprietary systems dramatically reduces maintenance costs. It removes the need for staffing a help desk with expertise on each specific application, following the upgrade schedule of multiple vendors, meeting the specific infrastructure requirements for each application, and provisioning accounts and managing permissions across applications. The consistency of the user experience across Dynamics CRM apps also reduces training costs. Just train users in Advanced Find once and they can query data across any application and build their own reports all without calling the IT department. The seamless integration with the ubiquitous Office products further enhances usability.

Customization
Because each business has its own unique business model and processes, there is almost always a need to customize LOB applications, even applications built for very specific purposes such as project management and time sheet entry. IT departments are often frustrated when trying to customize proprietary systems because of a lack of documentation and dependence on specialized consultants hired out at a high price by the software vendor. In some cases, a vendor will inform IT that the customization is simply not possible and that they will have to wait until the next release, which might include the requested customization as a feature. Dynamics CRM was designed to make customization easy, it is well documented and the work can be performed a power user. More extensive customizations require a .Net programming but this skill is more generally available than are the skills required to customize most proprietary applications.

Integration
There are few challenges in IT more frustrating than integrating applications that were never intended to play nicely together. Despite years of hype over XML, web services, and service oriented architectures, integration remains painstaking and expensive. The more LOB applications an organization installs, the greater the cost of integration. Dynamics CRM offers a simple answer. Create all of those applications within Dynamics CRM and they are integrated from the get go.  Just use the web interface to create relationships between new entities and existing entities and you have instant integration. This integration ties together the user interface, reporting, business logic and workflow.

So whenever you face that buy or build decision, give Dynamics CRM serious consideration.

I met Ben Riga yesterday evening when he presented on Dynamics CRM at the SDForum in Mountain View, which is a short drive from where I'm working in Sunnyvale. The crowd of .Net developers were quite open to the platform and had a lot of questions. Check out Ben's blog and his many great presentations on Dynamics CRM as a platform.

I'd encourage CRM developers to follow the events at the XRM Virtual User Group. It is a great way to keep up with what other developers are doing with Dynamics CRM such as extending it with Silverlight and SharePoint.

The Dynamics CRM team at Microsoft have been busy promoting the XRM theme. xRM means using CRM as a platform for line-of-business applications that either extend the traditional functionality of CRM or add new functionality completely unrelated to sales, marketing and service.

Whether we call it CRM or XRM, Dynamics CRM is an ideal platform for line-of-business for two fundamental reasons.

First, LOB applications are intended to make business processes more efficient. Because the primary business processes of an organization are those that serve its customers, it makes sense to build those processes into a tool that already contains customer data. I’m now working on a project that incorporates certain project management information into CRM. Building the functionality in CRM saves time because it is easy to relate the data to customers and opportunities. It also enhances the value of CRM because the CRM system can display more of a 360 degree view of the customer.

Second, Dynamics CRM offers tremendous technical advantages as a development platform for LOB applications.  I find the easiest way to think of the difference between what you get when you create a custom entity without any custom development.

• Consistent user interface
• Data model with SQL views filtered for security
• Web Services Interface (both strongly typed and dynamic)
• Event framework
• Workflow Workflow Framework with easy-to-use interface and monitoring
• End-user search and reporting with Advanced Find and a Reporting Wizard
• Office integration (Outlook, Excel, Word)
• Offline synchronization
• Notes and Activities easily associated with records
• Role-based Security
• Import wizard for user's to easily import data from .csv files

Just click a button to create a new entity and the platform automatically generates what would have taken several months of development. And Dynamics CRM provides all of these additional features without limiting the developer’s ability to extend the solution through .Net coding.

So whether you call it CRM or XRM, the key point is not to limit the potential of the platform by staying with the traditional bounds of marketing, sales and service.

Paul Greenberg has posted a great blog entry about the amazing power of Dynamics CRM as a platform. Paul does a great job of explaining how five different companies were able to develop applications on top of Dynamics CRM in just five days. He was clearly blown away.

The research giants Forrester and Gartner have also stepped up their praise. Forrester has given Dynamics CRM very high rankings (above Salesforce.com) for the midmarket and enterprise and Gartner has ranked Dynamics CRM highly (above Salesforce) in its magic quadrant for contact centers.

Dell has acquired my employer Allin Consulting, a Microsoft Gold Partner and Microsoft Northwest Partner of the Year for 2008. Through the acquisition, Dell has expanded its consulting capabilities and now offers customers complete solutions from hardware to unified communications, collaboration, business intelligence, and business software – including Dynamics CRM.

Dell is committed to simplify IT. By offering customers complete solutions on the Microsoft platform with the promise of excellence and efficiency inherent in the Dell brand, customers gain the simplicity of a single vendor for hardware, software, and service.

Visit Dell's website for more information on the Microsoft Consulting Practice.

Out of the box, Dynamics CRM workflows give users the ability to add and subtract days in order to dynamically populate attribute values. If you wanted to set a task due in two days, you could use the dynamic value editor below and click Add. Simple enough but what if you wanted to set the task due within two business days. Unfortunately, the out-of-the-box CRM workflow tool does not provide this functionality. When it adds by days it does not skip weekends and holidays.

 
Because I don’t care to work on holidays and weekends, I’ve created custom workflow activities that can add and subtract business days. After compiling the code and registering the assembly and activities with CRM, just add a step to a workflow and under Date Utilities select Add Business Days.

 
Enter the starting date for the calculation and the number of business days to add.

 
Make sure to give the step a meaningful name such as Calculate Due Date. 

 
You can then use this date to populate a date field in a following workflow step. For example, add a Create Record step and select Task. With the Due field selected, select the Calculate Due Date step and then select the Output Date from the drop down list below. 

 
And that’s it. Now just publish the workflow and try it out.

In order to add the date utilities to the CRM workflow tool, download the assembly and register it with CRM. Learn how to register a plugin on MSDN and then download the plugin registration tool.

Download Assembly

Download Code

(Code is a free download with no warranty and no support. If you send me a question by email, I’ll try to answer when I find time.)

If you prefer to compile the code yourself, create a Workflow Activity Library project in Visual Studio, add the three code files in the download, and add references to the Microsoft.crm.sdk.dll and Microsoft.crm.sdktypeproxy.dll.

I’m a big fan of custom workflow activities for Dynamics CRM. It is the ultimate in code reuse. Just write a custom activity and register it with CRM and then power users can use it as a building block to create powerful workflows.

 

Share knowledge and collaborate. Salespeople and others involved in forecasting will make better decisions if they have more knowledge available to them. The information may include the factors that went into the quantitative forecasts; information on relevant economic data such as leading indicators; industry trends; market research; and information on past forecasting accuracy including the rationale that led to errors. Marketers may have information to share on plans for pricing and promotions that would influence sales. Operations and logistics may have information available on problems that could limit availability and sales. Clearly, there is much to be gained in forecast accuracy when information is shared.

Document decisions. Requiring documentation for every qualitative adjustment to forecasts services two purposes. First, forecasters will give more thought to a forecast whenever they need to write out a rationale. Second, reviewing the rationales of past forecasts is a great way to learn how to improve forecasting. It is important not to request that a forecaster adjust so many forecasts that they would not have time to explain their decisions at least briefly. When a forecaster has too many forecasts to adjust, they will not be able to devote sufficient focus to each and will start to just enter numbers to get done with it.

Train the forecasters.  The analysts who perform the quantitative analysis obviously need training in quantitative techniques if they do not already have those skills and ongoing training is always helpful to refine skills. It is also beneficial to train salespeople in forecasting so that they better understand the basis for the quantitative forecasts, how best to interpret information that is provided to them, and what to consider when adjusting forecasts.

Include forecasting in job descriptions and performance reviews. Most people involved in forecasting do not consider forecasting an important part of their job and it is generally not part of performance reviews or compensation. Most salespeople consider forecasting an unpleasant distraction from their real work. Obviously, forecasts are unlikely to improve if the work is not taken seriously. That which is measured is rewarded and that which is rewarded gets done.

Integrate systems. Much forecasting and business analysis is performed in spreadsheets. Although convenient, spreadsheets can make collaboration difficult and result in islands of analysis and data inconsistencies.  An enterprise system for performance management such as Microsoft PerformancePoint Server can combine the convenience of spreadsheets with the power of centralized data storage and data warehousing. A CRM system would work well for collecting qualitative adjustments to quantitative forecasts and presenting forecasters with data drawn from an enterprise performance management system.
 
Measure, learn, and improve. To improvement forecasting, measure how well you are doing, learn from mistakes, and continuously refine the process. Learning to improve forecasts not only improves business efficiency but also encourages everybody in the organization to better understand the market environment and why products and services are selling or not. Forecasting is a key to operational excellence and greater insight into the business.

For additional resources on sales forecasting, I recommend the following two titles:

Sales Forecasting Management: A Demand Management Approach by John Tom Mentzer and Mark A. Moon

Excel Sales Forecasting for Dummies by Conrad Carlberg

Sales forecasting is a sore topic in many organizations. In the majority of cases, C-level executives demand sales forecasts from sales managers, who delegate the task to salespeople, who consider forecasting a tedious chore that distracts them from the important work of selling. Unsurprisingly, the salespeople deliver inaccurate and biased forecasts. Knowing the biases, sales managers at each level of the hierarchy adjust the results as do the executives who demanded the forecasts.

Most organizations settle for this result as good enough. Few compare the forecasts against actual sales to evaluate the accuracy. Fewer still calculate the cost of inaccuracy.

The costs of sales forecasting inaccuracy can be huge. Operations may produce either too much or too little of a product resulting in high inventory costs or lost sales. Or operations may under or over invest in plant and equipment. Logistics might deliver products to the wrong distribution sites resulting in higher transportation costs. Finance may misjudge revenue resulting in higher costs for managing cash flow and investments. Marketing may promote products that would have already sold beyond the firm’s capacity to supply or fail to promote products that needed a push to meet goals. The organization might hire too many or too few people to meet demand, a problem that affects service organizations as well as manufacturing.

It is not uncommon for functions such as operations and logistics to so distrust the forecasts that sales produces that they create their own forecasts, resulting in redundant, inconsistent forecasts throughout the organization.

Forecasts require looking into the future and depend on many variables beyond the control of the organization. Certainly forecasts will never be completely accurate but can be made more accurate through better processes and improved collaboration. I offer the following suggestions for organizations ready to tackle the forecasting challenge.

Know why you are forecasting. This is important for two reasons. First, by knowing why you are forecasting, you can decide what to forecast. Are you forecasting sales in revenue or units? Are you forecasting by year, quarter or month? Do you need to forecast by distribution or retail location or just by product line? In many cases, you will need more than one type of forecast because the forecasts serve more than one purpose.  Generally, marketing and finance are concerned with revenues, operations with units, and logistics with units and location. Operations will need short-term forecasts for material purchases and long-term forecasts for plant and equipment.

Second, by knowing why you are forecasting, you can know the value of forecasting. If raising the accuracy of forecasts by five percent could save millions of dollars a year in inventory cost, then it may well be worth investing in accuracy. If the organization runs with great flexibility and adapts quickly and cheaply to changing demand, then an increase in accuracy may not be worth the cost. Keep in mind that forecasting has a cost in time, salaries, and resources. Only make the effort to forecast accurately if there is a value to accuracy.

Do not confuse forecasting with planning and targets. Forecasts are what you believe to be the most likely sales outcome given an expected set of market conditions. Plans are what you intend to do to accomplish those sales outcomes. And targets are stretch goals intended to motivate salespeople. Confusing forecasts and targets will lead to faulty and biased forecasts that will misinform other functions in the business that depend upon the accuracy of forecasts.

Basing the forecast on the plan is just mere thinking without grounding in reality. To the contrary, the forecast should inform the plan. If forecasted sales do not achieve revenue needs, the plan must address through marketing and promotions what the company will do to increase sales. The work of planning and forecasting should be iterative but in no way should the forecasts be based on the wishes of the planner.

Combine quantitative and qualitative approaches. Salespeople have unique insights into the circumstances and plans of customers but are not so good at making large numbers of forecasts, discovering patterns in past sales data, and calculating the effects of multiple variables on sales outcomes. The trick to better forecasts is to use quantitative methods effectively to achieve what those methods can best achieve and then to adjust those results through the rich qualitative knowledge of the salespeople. Generally, salespeople are more effective at adjusting a quantitatively derived forecast than making up a forecast out of nowhere.

There are two types of qualitative techniques for sales forecast: time series and multiple regression analysis. In time series, we look only at past sales data and try to find patterns for trend and seasonality. In multiple regression analysis, we look for relationships between a predicted variable, sales, and a set of predictor variables – price, money spent on advertising, the consumer confidence index, housing starts, a stock index representing the health of business customers. By plugging the values for the predictor variables into an equation, the forecaster can make predictions for sales based on changes in the market environment. While these techniques require some study, they are not rocket science and can be mastered by anybody with reasonable mathematical skills. And they do not require very expensive statistical packages. Excel could do the trick.

Quantitative analysis falls short in that it cannot predict changes from past patters. Time series analysis assumes that the patterns of trend and seasonality will continue unchanged into the future. Multiple regression analysis assumes that the relationship between the predictor and predicted variables will continue unchanged. The value of using qualitative analysis to adjust the quantitative forecasts is that salespeople, marketers, and other knowledgeable people in the organization may well know that changes are underway that are not yet captured in the data.

Because qualitative analysis is the most expensive approach to forecasting because it takes up the most time, it is better to focus qualitative analysis on only the most important forecasts, perhaps forecasting only the leading product lines or the purchases of only the largest customers. This follows the 80-20 rule that a few products or a few customers will account for the bulk of revenue. Indeed, the salespeople will generally only have rich knowledge regarding these few products or customers.