Self-service analytics requires aligning centralized technical expertise with decentralized domain knowledge. This is a delicate balancing act that requires a strong operating model and ample oversight and communication. Business users in every department and division need to know where to turn when they have a request or issue, and they need to have a voice in creating enterprise standards for governing the use of data and analytics content. 

Having the right people in the right roles doing the right things throughout an organization enables organizations to “push down” development and support from the enterprise team to local developers and business users. This push-down strategy only works if there is also a well-planned and highly choreographed process at the enterprise level for promoting and prioritizing requests that are either too small or too big for local resources to handle. It also requires cross-functional oversight of the enterprise program to ensure that all voices are recognized and heard, all needs are scoped and prioritized, and everyone uses the same standards and governance processes. 

In short, to succeed with self-service analytics, enterprise teams need to create a cross-functional analytics council, cascade support from experts to novices, establish a process for submitting and prioritizing project requests, and explicitly allocate resources to various types of development. As you can see, self-service analytics has a lot of moving parts—it requires a leader with the skills of a circus juggler to keep all the plates spinning without any crashing to the ground. 

Analytics Council

One of the nasty side-effects of ill-designed self-service programs is the proliferation of data silos and spreadmarts that undermine the integrity and value of data. To prevent data silos, organizations need to create a cross-functional committee of analytics managers that serves as a board of directors for data and analytics activities in the organization. This Analytics Council is responsible for setting standards and aligning activities across the organization. This body manages one or more of the governance processes listed in table 1, with direction and support from a chief data officer or vice president of data and analytics, who functions as program manager. 

Table 1. Governance Processes Required to Support Self-Service Analytics

The Analytics Council usually consists of a working committee composed of analytics managers from each business unit and an executive committee consisting of business sponsors. The working committee is the workhorse of the Council since it’s comprised of analytics managers who experience the “pain of bad data” every day. (See figure 1.) 

Figure 1. Data Analytics Council Composition and Responsibilities

A working committee may have subcommittees that tackle various governance processes, such as reviewing and approving data definitions, prioritizing projects, governing reports, governing analytics, setting tools standards, and creating a data literacy or training program, among other things. Sometimes, independent groups manage these processes, such as a data governance committee or prioritization board. For example, the Analytics Council may define terms critical for analytical processes and pass them to the enterprise Data Governance committee for consideration. 

Bidirectional Communications

To take root and flourish, self-service analytics also requires bidirectional communications between centralized technical experts and embedded domain experts who use data to answer questions. 

Here, knowledge trickles down, while requests trickle up. 

Trickle Down. The enterprise data team trains and coaches embedded data analysts residing in business units. (In the ideal scenario, it also hires and evaluates the performance of those data analysts even though they report to a business unit head. See “The Modern Data Analytics Organization: Federating the Center of Excellence.”) To support the embedded analysts, the enterprise experts establish office hours and encourage analysts to schedule one-on-one meetings. The enterprise team may also run data labs where analysts can work on a project with the help of an enterprise specialist. The enteprise team should also organize a community of practice (CoP) so embedded analysts can network regularly to share tips and tricks.

From there, knowledge continues to trickle down in a stepwise manner. Embedded data analysts build local solutions (i.e., dashboards) for their department and coach data-savvy business users (i.e., data explorers) how to customize existing reports. In turn, data explorers coach regular business users (i.e., data consumers) how to use their data analytics tools and gain more value. (See figure 2.)

Figure 2. Support Trickles Down and Requests Trickle Up

Trickle Up. While coaching and support trickle-down, requests trickle up. Data consumers send their questions about the data or requests for new features to data explorers, who address them if possible. In turn, the data explorers relay their questions and requests to data analysts—their local data experts—who may build a quick solution or prototype a more complex one to show to enterprise specialists. (See figure 2.) 

At the same time, business users submit trouble tickets to a data analytics help desk which triages the request. The help desk handles break-fix issues and small or simple requests. It is staffed by entry-level business analysts or support specialists. They forward more complex issues to the appropriate developer and project requests or are forwarded to the data prioritization committee. (See below.)

Project Management 

A data analytics prioritization committee is the focal point for handling larger requests that exceed a certain threshold, say projects exceeding $100,000 or three months in duration. Typically, a project manager works with technical experts to triage requests, estimating complexity, duration, and skill requirements. A robust triage process enables the prioritization committee to know exactly how many requests it can fulfill in a development cycle. Sometimes, this triage and prioritization process happens in an offsite quarterly forum where business leaders take turns presenting requests and then negotiate with each other and the development leads to determine priorities for the period (usually each quarter.) 

Project requests usually come from department leads, the project management office (PMO) which represents executive or enterprise needs, and the enterprise data team itself, which often needs to initiate projects to build out infrastructure required to support current and future business needs. The Help Desk may also forward requests. 

Departmental Requests. Within each department, an analytics manager coordinates a team of business analysts. The manager scopes, consolidates, and prioritizes requests that come from departmental users and assigns them to a local business analyst. If the request is too large or complex, the manager submits the request to the data analytics prioritization committee. (See figure 3.) 

Figure 3. Project Request Pathways

Each business analyst works for a single department, even if they reside on a central team, and a department may have multiple analysts. The enterprise data team often is responsible for recruiting, hiring, and evaluating the performance of the business analysts. Analysts are classified into job tiers based on their ability, experience, and domain knowledge. Departments have a different mix of analysts based on their analytics needs and maturity. 

Corporate PMO Requests. The prioritization committee also fields requests from the enterprise PMO and enterprise data team. The PMO specifies data analytics work in large enterprise IT projects, such as the implementation of a new enterprise resource planning application or a cloud migration project. The enterprise data team might be asked to build streaming pipelines or migrate a data warehouse to a public cloud platform to support these initiatives. 

Enterprise Data Team Requests. The enterprise data team submits projects that involve enhancing the data infrastructure, whether adding new sources to the data warehouse, automating data pipelines or building subject-area models to support specific departments or corporate processes. Often these “internal” requests get crowded out by urgent corporate PMO and departmental requests, sacrificing the long-term health of the organization’s data infrastructure. To avoid this problem, enterprise data teams with sufficient resources dedicate a subset of developers to focus on data infrastructure. 

Resource Allocation 

To make this top-down request model work, it’s critical that the enterprise data team and departmental analyst teams allocate a specific percentage of their time to each request pathway. (See tables 2 and 3.) This manner of allocating resources requires each team to accurately estimate its development capacity. 

Departmental Allocations. Ideally, developers allocate a fixed percentage of time to various types of requests, depending on their skills and interests. For example, departmental analysts might allocate 60% of their time to work on departmental projects, 10% on help desk tickets, 10% on data infrastructure and 20% on self-directed projects (20%). (See table 2.) 

Enterprise Allocations. Enterprise developers might divide their time among departmental projects (30%), PMO requests (20%), help desk requests (10%), data infrastructure (20%), and self-directed activities (20%). Or they might be assigned to one area 80% of the time, such as a SWAT team to work on departmental projects, or an operations teams to handle PMO projects, or an internal team to build data infrastructure. In this case, it’s best if developers rotate teams after one or two years. 

Summary 

Self-service analytics requires a strong operating model and enlightened leaders who excel at communicating across departmental and corporate boundaries. The goal is to align data and analytics activities across the enterprise so people work as efficiently and effectively as possible. This requires an Analytics Council and a federated operating model that pushes down development and support work from an enterprise team to local data analysts. It also requires significant coordination, cooperation, and planning among enterprise and departmental teams to ensure they remain aligned.