Comparison Overview
Comparing Microsoft Dynamics CE (CRM) and Dynamics Business Central (BC) for the same use case is like comparing apples and oranges. This document will help any business or IT decision maker understand the differences in these important applications. Let’s start by defining these business application archetypes.
BC is a leader in mid-market ERP: its mission is financials + supply chain operations. Its solution portfolio enables ledger & subledger, financials, tax, payroll, inventory, sales, vendors, supply chain, etc.
CE functions as a leading marketplace CRM: This domain treats lead generation, sales funnel, forecasting, deal management, all models – B2C, B2B, reseller relationship management, marketing, QTO, CPQ, project-based sales and ops, field services, customer service, call center, knowledge management, portals and mobile for demand management, activity management, sales & account planning, Outlook, Teams, and SharePoint integration
The category of CRM is not ERP or a subset of it
ERP (BC) sales and service modules are not CRM
CRM is demand management + marketplace coordination + commercial transactions
ERP is supply chain and accounting
ERP & CRM are better together. While there is functionality overlap, we do not recommend “mixing the streams”. We recommend a solution landscape with both applications to manage your business. The two applications coordinate like the left and right hemispheres of the brain. The trick is to use the parts of each solution that satisfy its mission without overlap; then integrate them.
Comparing BC and CE for suitability to demand management is inappropriate. The applications serve different purposes
The Turnkey Mission
Microsoft has built its popular, award-winning applications to compete against many other products in similar marketplace categories. But we do not always recommend all features of all products to all clients. We are a longstanding Gold Microsoft business partner across all primary business application workloads, as well as a licensing partner. While we are big supporters of Microsoft’s solutions, their software features and functions are not perfect; no solution is perfect or perfectly applicable out-of-the-box to every client. Every deployment needs smart configuration. As a result, we offer you approaches to evaluate fit and optimize the implementation for your business. That is why you hire us, not just to train on what Microsoft offers, but to help you optimize the tools that run your business and assure success.
Below is a helpful review of the differentiators between Dynamics BC and CE for demand management.
Dynamics BC vs. CE (CRM) Core Functionality & Architecture
With BC you will need to give an accounting/ERP solution license to all users including sales users. It isn’t modular and there is not a discount for sellers who only need to use the sales portion. You’ll overpay if sellers only need to sell, because they will receive all functionality, and you will use security to obscure the financial aspect for sellers who do not want to be accountants…and show only the limited sales aspect. Because BC is more expensive than CE, this may not be optimal, especially when it contains only a fraction of commonly needed sales capabilities.
The BC customer card. This data set is designed the way we would expect an ERP to capture data, it’s a great placeholder for a bill-to and ship-to, and the object of accounts receivable. It is expressed with a fixed database model and assumed practices in mind for data and process management. BC is designed to control and make it easy to define your data model. Dynamics CE (CRM) deliberately lets you configure the customer entity and let’s you decide how to capture and manage prospect and customer data profiles with respect to: your business model, industry and “special sauce”. You tell CRM how to represent your data model—and this makes all the difference in the world to seller success and marketplace agility. With BC, the way data is managed is more like “pass/fail”. It has some common data points and limited configuration changes. With CE, the customer entity as an account record, and accounts of different kinds can have a different set of parameters to manage; out of the box, it’s a baseline best-practice in Microsoft’s Dataverse, plus a spectrum of variations to let you manage the marketplace.
BC, like any good ERP is inclined to take an accounting view of data and business processes. To ERP, anything in sales and customer support exists to serve ERP. It’s more about controlling data and process toward document-style transactions (orders) and the resulting financial management. The sales module becomes transactional, somewhat authoritative, and static. But CRM is intended to be empowering to the users. With Dynamics CRM, accounting structures exist to serve and guide commerce and selling drivers with relationship-enabling features. The CRM application becomes strategic, holistic, relationship-oriented, and enabling. The CRM’s are designed to be flexible.
At its root, all ERP’s fundamentally seek to manage and track the outcomes of selling and servicing, the end transaction, but that is not what CRM does. CRM manages the upstream causes and drivers of those outcomes…all the work that must be done to “make it rain” or encourage long lasting customer retention or assure all customer-facing resources can do what is necessary before the final transactions.
Prospect & Customer Management
With BC you must regard prospective customer accounts (households and organizations not yet recognized as customers) as actual customers with ID’s. This tends to clutter ERP with account records that carry no transactions because you have not yet converted them. Often—and if you are aggressively marketing, prospect records will be the majority of your records. But the rules of data management for prospects vs. onboarded customers will be quite different. Unfortunately, BC is not wired for prospecting and offers only one set of data validations.
Note, capturing prospect data is not the role of a CRM Lead or any Opportunity. Leads are process records that control the key functions of attribution and qualification; and as any business with good, assertive marketing will already have the prospect accounts in mind and in CRM where all segmentation is done, so leads are associated to --not replacements for the accounts and contacts that comprise the marketplace. This is important and a key reason never to use ERP as a CRM.
BC does not offer a hierarchy of accounts. CE has easy to use hierarchical account links for more complete market definition and appropriate assignments to sellers for proper lines of business, and decision-making entities that interoperate to form a more complex set of relationships.
BC commingles the notion of an address with an account. Accounts are businesses and households, not accounts receivable or distribution metadata. The marketplace participant represented by one Account in CRM may have many addresses, both past and present that must be managed. It is N-1 to account. These addresses can be integrated to and from BC as necessary for commercial transactions.
BC does not administer the notion of record ownership and promote how that can allow roles-based security and data custody. To ERP everything is enterprise administered. But in most business models, several layers of account management exist, and a layer of roles must be assigned. This is no trivial matter. For the sake of reasons of data quality, data security, seller focus, and true commercial engagement/ territory assignment, you need to assign a matrix of responsibilities to specific sales projects and accounts. BC has only one user assignment field for customer accounts. It has a bypass opt out of visibility feature, sort of a 1-off.
BC blends the notion of a contact with that of an account. This is simple to manage, but not sustainable for relationship selling where there are several decision makers and influencers and roles at one account that confers important roles-based relationship and commercial responsibilities. BC offers a hack to track N contacts, but this does not relate to other entities in a normalized manner.
In CRM, an account as a business or as a household has N contacts and the contacts can be tracked across their org relationships. And customers can bill to N billing accounts in ERP, so it is good at tying everything together for a “360’ view” of the customer. In BC, an account can have a default bill-to and a ship-to address. It’s possible that you have other sales reasons to manage locations, and that neither of these ERP types represents decision-maker locus or servicing location. Other addresses are restricted to the order transaction documents.
BC does not allow you or your accounts to indicate relationships with other accounts as any CRM would enable, such as for dealers, partners, resellers where both the CRM owning company—you, and your reseller participate in sales processes where the end consumer (business or residential) are named and recognized.
CE has unlimited segmentation and attribution capabilities for 360’ marketplace comprehension and customer coverage. Org level and contact parameters and segments can be quickly filtered into lists for scaled communications and marketing actions.
CE provides a focus on activity scheduling and completed communications management, tracking collaboration and correspondence so sellers can truly manage their time inputs and let the application surface next best actions, so they do not need separate tracking or over-reliance on Outlook, which is disconnected from BC.
BC does not offer a lead entity, which is a presales function that we strongly recommend. Leads are top-of-funnel process record (not accounts or contacts, but a place to clarify fuzzy inbound sales potential, resolve qualification and assign attribution). This gap forces you to use the more verbose opportunity management aspect for business potential that may not really be an opportunity. This causes over-representation of true opportunities and will lower productivity.
Options for configuring BC opportunities to fit your business model and process are very limited. First they are contact-centric, not account-centric. Also, they do not recognize complex workflows with if/then gates, and do not allow multiple internal participants. It may assume the work is handled by one seller operating autonomously.
There is limited data validation and guidance to build the opportunity as you go, and use workflows to govern the lifecycle for various kinds of deals
Because opportunity management is limited, BC is not intended to provide good bottom-up revenue and pipeline-based forecasting. CRM encourages no-code, rules-based configuration for many forecasting models.
BC does not offer solutions for proposal or contract management
CRM gives robust templated document-merge and email-merge capabilities that bring selected database information into documents for personalization and process-specific document and email communications to enforce best practices.
In BC, the opportunity record is a reference point for sales quotes. But quoting is not necessarily the main driver of opportunity functionality. Selling interaction as a process, especially for complex sales projects is really the use case for opportunity management: how to win. BC is passive in its expression before the sales order, CE is assertive in sales enablement for all actions that must occur before the order. BC is more valuable for sales order capture and internal distribution, but if selling enablement is needed, it forces the Microsoft customer to use both a sales license and an accounting license. We recommend customer-facing processes be handled entirely in your CRM, including Configure-Price-Quote (CPQ) and Quote-to-Order (QTO).
CE gives a visual stage-based process map within opportunities called the BPF, with checklists and accountability mechanisms, so all sellers are progressing in your methodology in the same way for any process type, driving forecasting commonalities; all that is absent in BC, and we expect that from ERP. That is classic CRM territory.
In CE, sales stages are based on the completion of process actions, and these processes can be dynamically branched based on upstream drivers. BC opportunity status is manually designated, giving subjective room for sellers to define where they are individually based on individual guidance that can be subjective between sellers.
BC allows closed opportunities to be deleted. CE inactivates them as closed (archived) but we don’t recommend deleting them as that can disrupt good BI on marketplace momentum.
Other CE Features for Sales Enablement not available in BC—or ERP’s generally
Deep Outlook integration at Exchange level with may automation features
Deep SharePoint presales and customer service document/media management integration
Deep and easy to use Teams chat, Teams site/channel, and Teams calling features
Improved CPQ and QTO capabilities with robust offering management, price and discount approvals, and complex selling, scenario selling abilities
Sales media/collateral management and search-to-deliver across channels
Sales team management, goals, supervision of performance
Account to revenue planning module
Portal based lead and agent/partner coordination without CRM licenses
Product and offer/promotion management capabilities, campaigns
Advanced Sales strategies and planning
Better BI for marketplace and demand management
Enables different revenue streams to have different processes and data management rules
Service Delivery
Like sales, BC Service vs. CE Customer Service and Field Services is a comparison of apples and oranges. The products are not intended for the same use cases.
BC Service is not intended to treat customer care. Like the sales module is sales order management, BC service is a service order management solution, for example return and repair, but without the benefit of advanced CE Field Services delivery management capabilities.
BC’s focus is on products and inventory, and the sold item being serviced, not the customer interaction requirements.
Service items in BC are limited to warranty type cards and again are product/item oriented. But the items are not managed as assets/installed base. The card is a placeholder for aftermarket decisions about future sales orders. In CE, assets or installed base can include items sold and third-party competitive assets in the marketplace for powerful cross-selling and replacement timing. We do like the way BC treats non-asset items sold for good customer service replacement and resell. But CE provides broader aftermarket coverage, including subscription style engagement tracking, service business model sales tracking, and project style tracking that BC does not.
BC moves from service items (cards showing items sold) to service orders (transactions). But how do you know if you must commit to a service order? What causes that transaction? BC servicing functionality is downstream from the CRM impact, so it is not CRM. The way to manage customer interaction and requests for service, issues, warranty claims is missing. But these important customer-facing workloads must occur beforehand, which might or might not result in a need to generate a service order. Again, BC is transactional, which is what you want from ERP.
BC was not designed to provide the notion of a case: clients submit cases across many channels. BC has no concept and cannot build it without difficulty.
Cases initiate support treatments. Businesses with informal or no central case-tracking are generating risk and certainly are fragmenting customer care. CE joins the customer-facing Case with the work order treatments downstream. These can be sent to accounting as service orders, but customer care agents need CRM to be effective and holistic.
Case management should be omnichannel like CE enables, such as email to case, portal to case, social to case, chat to case, apps to case, call to case.
Businesses that provide customers with portals and self-service mechanisms like chat and chatbot technologies that will deflect expensive calls and improve responsiveness. CRM is needed for this. Most support agents need call center features and treatment processes beyond service orders. They must manage all transactions from a single universal desktop and manage numerous asynchronous cases, with interruptions and still maintain process context over all of them. All this before any service order may be considered.
After case, which is customer facing, your agents and customers need knowledge base, missing from BC.
Case treatment workflows usually need an entitlement scheme that may be contractual or based on general business policies, and entitlements can have limits. These are part of CRM.
Eventually as your business retention practices mature, you will need a way to gauge VOC and resolutions for customer sentiment about your brand that results from the perception of inadequate customer care.
You need credit memos, RGA’s, re-order, trace, insurance claims, and may more treatments. Not all businesses are product/item oriented; some organizations are services, project, or asset oriented (installed base). Some models are government, NFP or NGO. True CRM, like Dynamics CE can manage those critical differentiators.
Good practices allow for root cause and cases that contribute to commonalities in the business that may be causing risk or need for a program to overcome a production or servicing issue.
Dynamics CE allows volume management and process differentiation based on segments and criticality, with routing and queues to optimize processing
Dynamics CE leverages work orders and tasks that must be included in a process to fully treat the customer are naturally definable in dynamic workflows, just as in sales workflows as above.
Dynamics CE joins all tasks and transactions into the context of the Case, so no detail is left uncontrolled or untracked. BC goes order by order and loses the ability to join it all together. Once again it is transactional, not relationship building and keeping
Dynamics CE tracks all correspondence and allows agents to work across many channels
Dynamics CE provides customer care agent performance management and goals
Dynamics CE allows a field service module to make work orders that can be scheduled for satisfaction of efforts on site at customers by remote, distributed workers
Dynamics CE Field Services has a master-scheduling function for work orders for any kind of resource: people, equipment, etc.
Dynamics CE Field Services is more sophisticated and coordinates with shop scheduling which is SCM. E.g., CRM field services work orders and projects can have templates that drive repeatable work sets and helps encourage consistency.
The Dynamics CE Field Services module has a more robust skills-based assignments, routing, and capacity management than BC.
Field Services
Microsoft Dynamics CE/CRM provides a robust, industry leading field Services solution that is a blend of customer-facing functionality with remote supply chain features. This module is a native extension of the sales and customer care database and application suite. It delivers, field asset management (installed base), resource management, billable transaction management, universal scheduling and routing for resources, teams and shifts, work order instructions and knowledge base to field technical workers, contract and pricing recognition, mobile transaction management and mobile geo-services, IoT and more. BC has some features in its item card and service order capabilities, but not service delivery management.
Commenti