Architecting for Analytics

Have you ever worked with — or in — an organization that had lots of data but little ability to translate that data into useful insights? If so, the following scenario will likely sound familiar to you; and the rest of this post, which describes how architecting for analytics addresses this all-to-common scenario, will help you avoid it.

The ABCNFP non-profit organization (not their real name) was made up of amazing, talented people supporting a wonderful, noble cause. Salesforce had been in place for several years at ABCNFP and was — with the help of a consulting partner — highly customized to suit the organization’s complex services model. User adoption of their bespoke CRM was good, and they weren’t lacking valuable data. What they were lacking was meaningful insights.

Reporting on services delivered was extremely difficult, and sometimes impossible. For example, every quarter, in preparation for a critical board report, the head of research at ABCNFP exported about 20 reports from Salesforce and imported them into a giant spreadsheet. She then spent three whole days combining, aggregating, and transforming the data from these reports into a single sheet that would give the board the information they required — services delivered across Australia, broken down by region, demographic, and service. Once the head of research had finished preparing these insights, they were captured as a screen shot, embedded in PowerPoint slides, and shared with the board as static numbers.

In fact, by the time the board actually saw these numbers, it had taken so long to prepare everything that the data was not even accurate anymore! As a result, the board was making decisions based upon outdated information, greatly hindering their ability to make data-driven decisions to improve service delivery and maximize social impact.

Why was the analytics of ABCNFP such an awful mess? Why was it so difficult to get their Salesforce reports and dashboards to deliver what the team needed? Why did a high-value analyst waste three entire days every quarter preparing reports manually in spreadsheets? Why was the board depending upon inaccurate and outdated information? The answer is simple: ABCNFP and their consulting partner had architected Salesforce for process and operations, not for analytics.

As a former Salesforce admin, business analyst, and consulting partner, I have seen a great many stories like that of ABCNFP. I’ve spoken with countless organizations who are living with the difficulties, inefficiencies, and limitations of drowning in data, when they should be swimming in insights, given their investment in data-rich platforms like Salesforce. The root cause is almost always that the Salesforce org was architected for process and not for analytics.

Let’s examine this problem, evaluate its impact, and understand how it can be solved.

The problem

When a Salesforce solution is designed, the primary consideration is usually business process requirements: How can organizational processes be modeled and reflected in CRM? What is often not considered when designing the architecture is the key deliverable of business intelligence, and this failure results in a great many problems down the track.

A key benefit of Salesforce is that it is incredibly customizable. This flexibility is a two-edged sword, however, as all of that customizability can be a challenge as well. Careful, deliberate, and strategic solution design is critical for a great long-term outcome. A good design includes architecting for analytics, and not doing so has serious business impacts.

The impact

Technical debt

Salesforce customers who do not architect for analytics will generally need to rework their Salesforce architecture to support analytics deliverables at a later date. The alternative is ending up like ABCNFP, and not being able to make timely business decisions with current data. This architectural rework is expensive, wasteful, slow, and frustrating.

Poor analytics

A CRM architecture that is not designed for insights will deliver poor data analytics. Symptoms of this include:

• Incomplete data. Data that is not complete results in a deficient and inaccurate picture of the state of an organization.
• Wrong data granularity. Data that does not capture the level of detail required for decision-making will yield incomplete, inaccurate insights.
• Stale data. When information is outdated, decision-makers are constantly behind the current state of affairs and unable to take proactive steps.
• Siloed reports. Fragmented, disconnected data sources and business reports produce fractured, incomplete views of the organization.
• Dirty data. Dirty, incomplete data never leads to accurate conclusions and powerful insights. The root causes of dirty data include a lack of proper governance, unclear data policies, and inferior processes.

All of these lead to the same outcome: the inability to make informed, proactive decisions.

Dependence upon spreadsheets

Salesforce reports and dashboards that cannot meet analytics requirements due to poorly designed architecture lead to an unplanned and unwelcome reliance upon spreadsheets. Customers are forced to export data from Salesforce and combine it using a slow, tedious, and error-prone manual process. This process also creates multiple, potentially conflicting sources of truth for business decision-making.

Scope creep and cost overruns

When a promised deliverable of game-changing analytics does not materialize, customers demand satisfaction. Reworking architecture and/or building complex reports to deliver business insights is time-consuming and expensive — not to mention the potential need to design and build advanced analytics in a BI platform like Tableau. Therefore, the failure to architect for analytics often results in scope creep and cost overruns for the project.

How do you solve this problem?

Design your architecture to support both processes and analytics

Early in the discovery and design process, data analytics must be front of mind, in addition to the business process. As decisions are made regarding Salesforce architecture, data storage, and data integration, all relevant stakeholders need to consider the impact of these upon reporting and insights. What can you do to ensure this takes place?

• Identify current and future projects where you can help ensure that the architecture reflects analytics requirements as well as operational requirements.
• Discuss this issue with your broader team and formulate a strategy for addressing it. Drive from the front by providing examples of “what good looks like” for innovative peers and industry leaders.
• Make a list of key factors to consider when architecting for analytics. (The following section lists several examples.)
• Consider performing a post-implementation review (PIR) for a recent project and assess how well it was architected for analytics.

Ensure that stakeholders understand that analytics is a core deliverable

For many customers, the decision to use Salesforce stems from a desire to be a data-driven organization. They are sold on the data analytics and business insights. Therefore, data analytics must be prioritized as a key project deliverable — a part of the minimum viable product (MVP), not phase two or three. If this is not the case, analytics requirements will not be reflected in the CRM architecture. How, exactly, can you put data analytics front and center?

• Clearly identify and scope key analytics deliverables at the beginning of the discovery process.
• Clarify and agree on the data that will drive these deliverables, including source, granularity, integration, relationships, provenance, historical trends versus current snapshot, and refresh rate.
• Create high-level mock-ups of the key analytics deliverables for sign-off by end users and service providers (architects, consultants, and so on). This must precede solution design for the greater project and Salesforce architecture.
• Collaborate with stakeholders and SMEs to understand how these analytics requirements will impact the Salesforce architecture and schema, as well as the overall project architecture. For example, should external data be brought into Salesforce to drive operational processes, or should it be combined with Salesforce data and embedded in Salesforce as dashboards via CRM Analytics (formerly Tableau CRM)?
• For enterprise, cross-functional analytics, engage cross-functional leads to point out relevant cross-industry use cases and show what good looks like in the analytics strategy space.

In the end, ABCNFP was able to rearchitect their data model and their board was happy with the results. It did, however, take a significant amount of time and expense to finally get things right. So, if you spot scenarios like this in your own implementation, address them as early as possible to help your business stakeholders get the complete, timely, and accurate insights that they need — without painful, wasteful, and expensive rearchitecting later on.