Rethinking 'Single Sources of Truth' in the new AI era

Building and maintaining a ‘Single Source of Truth’ (SSOT) is top of mind for many strategic finance leaders. Nowadays, finance teams are expected to be objective data stewards, ensuring that data across the organization is being used to effectively drive decision-making and value.  

Over the years, planning has moved beyond complex financial models to leverage both financial and operational data and both internal and external factors in near real-time. With AI advancements, the scope of data that can be processed is expanding from numbers to text, images, audio, and video.

To leverage AI, having data centralized and structured properly is critical, so building an SSOT has never been more important. With that said, this new world means that SSOTs of the past will look much different than the SSOTs of the next decade.

‍

Building an SSOT at Sunrun

A few years after Sunrun’s 2015 IPO, revenues had grown to above $500M, but like many high-growth companies, there were significant growing pains. Teams were struggling with common planning challenges for a vertically integrated business, including consistent sales misses, disconnected sales and operations plans, supply chain shortages, highly variable demand, and working capital constraints.

The strategic finance team had been freshly reorganized, and we were tasked with overhauling and building best-in-class planning processes and systems fit for a public company. At that time, planning was done across a myriad of tools including Google Sheets, Salesforce, Anaplan, and Python models, and processes were such that quarterly forecasts took nearly the entire quarter to produce.

Sunrun was in the early stages of implementing Anaplan, so we used it as our primary technology platform. Over three years, we:  

• Transitioned the organization to a monthly rolling forecast with 2-week turnaround times (including accounting close).
• Built sales forecasting models covering each of Sunrun’s major sales channels – Direct, Partner, and Retail – and dialed in forecasting accuracy to <10%.  
• Built operations models providing full end-to-end visibility into cycle times and cancel rates from lead to installation (often 6+ month processes), enabling our customer realization team to target weak points and improve realization by several percentage points
• Aligned sales and operations on an org structure that bridged sales territories with field branches, providing downstream teams with accurate volume forecasts.
• Rightsized overcapacity issues in both sales and operations (labor and materials).
• Enabled project finance to model project cash flows at the customer-level for the first time.
• Introduced a new contribution margin metric that segregated variable and fixed costs by market, channel, and product and reconciled operational metrics with financial results (EPS, NPV, free cash flow).

Anaplan became our SSOT during this process, housing all structured financial data, both forward-looking and historical, as well as a significant amount of operational data to support planning. Anaplan directly fed board materials, monthly reporting, weekly S&OP executive meetings, and budget reviews. At some point nearly all of Sunrun’s corporate team (hundreds of users) leveraged Anaplan on a regular basis.

Evolving the SSOT at Sunrun

While the results were largely successful, building so much into Anaplan had several key downsides that intensified over time:

• Storing transactional data in Anaplan, which is optimized for in-memory multidimensional modeling, was expensive (nearly ~$1k per GB now).
• Increasing data complexity and number of data connections required heavy data engineering know-how (some folks on our finance team moved on to lead BI/analytics functions).
• Granting Anaplan licenses to every person in the organization was not feasible from a cost perspective and was also a challenge from an administrative standpoint.

Running in parallel to our planning initiative was a broad rollout of Google Cloud Platform (GCP) and Looker to replace Oracle BI. While this deployment naturally took a bit longer than Anaplan, once it was ready, we transitioned much of the day-to-day operational reporting back into GCP/Looker to relieve pressure on Anaplan.  

In the end, GCP/Looker became the SOT for operational reporting (and some planning outputs) and Anaplan continued to be the SOT for planning and financials. Many folks longed for the user-friendliness, pivotability, and ability to manipulate data in Anaplan versus the relative rigidity of Looker, but it simply was not feasible to use Anaplan for everything.

While this outcome of two complementary SOTs (one more unstructured and operational, one more structured and financial) was still a win for our goals at Sunrun, it nonetheless feels sub-optimal in today’s context.

‍

Updating the Meaning of an SSOT

What we built at Sunrun was best-in-class for finance teams in the mid- to late-2010s, but it is insufficient for where things are going. In an attempt to redefine the meaning of an SSOT now, we start with Mulesoft’s definition below:

A single source of truth (SSOT) is the practice of aggregating the data from many systems within an organization to a single location. An SSOT is not a system, tool, or strategy, but rather a state of being for a company’s data in that it can all be found via a single reference point.

This definition technically stands on its own, but a few clarifications make it more actionable:

Scope of Data: With AI, the potential scope of data is magnitudes larger – structured and unstructured, qualitative and quantitative, historical and forward-looking, human-generated and system-generated. That’s a LOT of data to bring into one space, far beyond anything contemplated by planning (and even BI) solutions in the past.

There still needs to be some kind of line in the sand on data required for decision-making and all possible data and there is now more pressure on leadership to philosophically align on what input and output metrics will be utilized to forecast and measure performance before starting to centralize and structure data.

Accessibility: centralizing data is not valuable if it’s only accessible to skilled data engineers. An effective SSOT should be organized, available, and accessible to business users who don’t have a technical background.

Technology: it’s important to note that an SSOT is not one system or tool. Many software providers will market their solution as an SSOT - that messaging should be taken with a heavy grain of salt. While the SSOT is not a strategy itself, having a data-centricity strategy (and frankly, a cogent overall business strategy) are necessary to building an SSOT. If the organization is not aligned on objectives, organizational structure, key metrics, and a tech roadmap, an SSOT will not be feasible.

‍

The SSOT of the Future

How can finance teams prepare for this expanded vision of an SSOT?

Pairing cloud data warehouses with business analysis software such as Looker, Tableau, Anaplan, Alteryx, Sigma, etc., is still a viable approach, but it is subject to high costs and a natural tendency for organizations to silo into their preferred analysis tools, which eliminates the SSOT.

Planning solutions are becoming less viable to be the SSOT due to the challenges above. Most are opting to simplify their scope and focus on FP&A use cases after seeing the roadblocks that Anaplan encountered. None can handle operational data as effectively as Anaplan can.

And while modern data warehouses, lakes, and oceans (however you define them) can handle massive amounts of data, when viewed on their own, most still require too much technical aptitude for average business users to adopt and turn that data into decisions. A tool (or suite of tools) that can satisfy the modern definition of an SSOT needs to not only have the data, but also be easily accessible.  

‍

Microsoft Dataverse as the new SSOT

So where do we go from here?

Our bet is on Microsoft Dataverse, which is the back-end data architecture for Microsoft’s Dynamics solutions. Microsoft has largely done away with the traditional CRM/ERP definitions and has stripped away enterprise interfaces (now optional ‘apps’) to present Dataverse instead as a low-code structured data platform, breaking down silos at the foundation-level.

We like Dataverse for many reasons:

A true platform: with direct connectivity to the entire Microsoft ecosystem - Microsoft 365, Power BI, Power Apps, Power Automate, Power Query, Azure, Azure ML, Copilot, and hundreds of connectors with other systems, Dataverse is a true platform and a natural option to be an SSOT for all structured business data needed for strategic planning and decision-making.

Accessible to all: A clean, simple, and entirely customizable interface makes it easy to explore and analyze data. Data can be updated and linked by business users, adding key business context to data. The vast majority of users are familiar with the Microsoft ecosystem and are already provisioned with access.

Cost-effective: Dataverse will also be much more cost-effective than standalone solutions, with many of the Microsoft products already included in Microsoft 365 (our 10-person team is using the same low-code platform as a $3T enterprise!). You do pay for storage by the GB with Dataverse but it’s a fraction of the cost of planning solution licenses.

Collaborative: cloud-based software created schisms in many organizations between IT teams and business teams, moving system ownership from IT control to finance and business operations teams. These teams will all need to work together to effectively manage systems and data in a modern SSOT, and Dataverse could be the hub that links technical and business minds back together.

AI-ready: teams are already leveraging AI/ML models and chatbots to assist in forecasting and analysis, but it’s inefficient to move data into a planning solution, then into an ML model, then back into the planning solution (remember those storage and integration costs!).

Running models directly on data in Dataverse and then moving into the planning solution is much more efficient and allows for consideration of many more data points and parameters.  In Dataverse, you’ll eventually be able to prompt AI to pull both structured and unstructured data, perform analysis, run models, visualize data, or reconcile data all in one place.

‍

Looking Forward

Reflecting on the past decade or two, it’s remarkable how much progress organizations have made in leveraging data and building SSOTs with solutions like Anaplan. But with AI innovation accelerating, it’s critical that finance teams continue to innovate as well and consider new alternatives such as Microsoft Dataverse to move toward a truly data-centric vision.

‍