In the health and life sciences (HLS) space, speaking of CRM is often met with some degree of puzzlement by industry personnel outside of sales and marketing functions. After all, the “H” of HLS prides itself on having patients, not customers, and the “LS” is much more inclined toward the quality and regulatory aspects of a business than anything else once outside sales and marketing.
Even in sales and marketing for the life sciences, there is little prospecting or lead generation on the scale found in other industries. The “customers”—doctors, allied health professionals, hospitals—are well known. For this reason, sales tends to focus more on delivering a compelling marketing message about the competitive advantage of a particular treatment, drug, or device vs. an alternative.
In the health and life sciences, perhaps more than any other industry segment, the concept of “XRM”—where “X” is a variable that can represent almost anything—is critical to understanding how Dynamics 365 can be successfully implemented. In other industry segments, XRM has been used to configure and customize Dynamics 365 to support diverse applications including supply chain management, inventory control, membership lists, insurance field assessor activities, and even storing customer preferences for haircuts! These are all XRM applications, which Dynamics 365 makes possible by virtue of its platform attributes, as opposed to what we call “point solutions.”
In order to develop a common understanding, it’s worth defining the terms used in this chapter. A point solution, in terms of software, is a program developed to meet a particular need in a particular industry. In the health and life sciences, one might think of software that schedules patient visits or supports a call-center—that’s all it does.
Point solutions are generally stand-alone. They require only the basics of IT infrastructure such as a PC or terminal, an operating system, and perhaps a base level of hardware (memory, disk space etc.) to operate. A point solution may or may not integrate with other programs, share information with other systems, or leverage the features of other software to achieve an objective. Point solutions are necessarily narrow in their focus in solving a single problem—which they often do quite well, but frequently at the expense of broader, overarching organizational needs.
A platform, by contrast, provides a foundation or base upon which applications can be developed. Using a platform—which in this context is akin to a software application framework—enables designers, consultants, and developers to focus on specific project needs rather than low-level base programming code required to make a working system. Platforms allow businesses to rapidly develop specific solutions. Because the underlying platform is common, solutions share data attributes and allow for integration between other software products.
Let’s extend the example of the call center noted above. If a call center is built on a Microsoft Dynamics 365 platform, it can easily integrate with SharePoint. This would allow users to easily access reference documents. These documents could also easily be emailed to the caller, tracked in Outlook, without writing any software code or adding any third party tool. If management wanted to review call-related activities within an Excel file, they can easily call that real-time data in Dynamics 365 to get a 360-degree view of the customer interaction.
So a platform brings with it the ability to integrate with other systems and develop solutions rapidly. But it also brings with it a set of built-in tools, utilities, and structures that support the operation of those solutions. In Dynamics 365, for example, workflows are built-in and don’t require coding skills. They can be configured to automatically perform actions within the solution.
How does a workflow work? Let’s return to the call center example. Instead of manually selecting a document and crafting an email to attach it to for the caller, a preset workflow can allow call center staff to check a box on the call record and automatically send an email, saving time. In this example, if the call center rep selects a box that says “Send Living with Heart Failure document,” the workflow would select the relevant document, apply a predefined email template, personalize the mail with the caller’s name, and track the email as an activity.
Often within the health and life sciences—or at least within the “health” space—organizations tend to think in terms of point solutions first. Many times this comes down to an organization’s culture and mission, which are often focused on the concept of health and putting the patient first. This isn’t to say that business imperatives don’t exist within healthcare, but they often take second place to patient health.
The net effect of this type of outlook can translate into an unwillingness to invest in a platform. The logic is that, even if a platform facilitates rapid solution development by non-programmers, someone must undertake the task, and finding the appropriate person can be difficult. Personnel in these organizations tend to be aligned functionally in a fashion that supports the mission directly rather than indirectly.
Culture also plays a significant role in avoiding platform solutions, usually in the form of risk aversion. Risk aversion is not a bad thing—few of us want to be the subject of a “let’s try this unproven therapy” approach to healthcare. It can, however, lead to a situation where only “tried and true” solutions are countenanced. While this approach is laudable in patient care, it is inherently limiting when approaching software innovation. For example, there is currently no mechanism for running a clinical trial on a software solution and getting an FDA stamp of approval, so innovation can be hard to implement.
Even developers of point solutions face difficulties in getting their products adopted in the health and life sciences. Hospitals looking for solutions often want to know who is currently using the product in their space. If a solution or platform provider can’t point to a current user (or preferably a dozen or more), the future is bleak, no matter how innovative or robust the solution. Often, this risk-averse perspective on the part of hospital customers spills over into the rest of the space, which makes it very difficult to position a platform as a solution effectively.
Customers in the health and life sciences can benefit from understanding that the Dynamics 365 platform is extremely robust with proven successful implementations. Millions of users and tens of thousands of companies worldwide (including some major hospital systems, pharma/med device, and even small clinics) use it.
Once this message is internalized, the next step is to convey that the platform—while developed and sold by Microsoft—is most often implemented and configured by approved Microsoft partners like PowerObjects. Thus, specialized “off-mission” personnel are not required in order to develop solutions specific to the organization’s needs.