Self-service BI best practices

In my previous post, I discussed some of the drivers and enablers behind the current push within many IT organizations to implement or enhance “self-service” business intelligence and analytics. In addition to all the benefits for business users, IT also sees opportunities to benefit from driving down their development and maintenance burden, increasing speed to delivery, and freeing up resources to focus on infrastructure and governance responsibilities. Of course, this all depends on a successful implementation and roll out. This is far from a given, as many shops have discovered. There are, however, some best practices I can share that can enhance user acceptance and help generate demonstrable business value. I’ll break them out by people, process, and technology.

People: Adapting an IT organization to support a self-service BI model is often a major hurdle. It is generally accepted that some variation of a “hub and spoke” model is desirable. This implies a central group of shared data and application resources along with process experts. These combine with analysts directly aligned with one or more business units. It is not that simple though. I have seen several examples where a team of business analysts, project managers, and developers have attempted to stand up self-service delivery and found it impractical without a significant re-definition of roles. The key to success in self-service is to convert the organizational model from a development orientation to one focused on effective support and overall customer service. It is absolutely necessary to reserve enough bandwidth from all resources to remain engaged with users after applications are released or enhanced. Self-service environments are never quite finished. They must evolve as business requirements and priorities change and the size/composition of the user base changes. Initial successes will spawn new requirements as users see what is possible and new subject areas are folded in.

Ideally, the role distinctions between developers, business analysts, QA, and project managers break down in favor of a core group of BI practitioners who can perform in all of these roles to some extent. Ideally, the specializations shift to subject areas and business segments; e.g. Marketing, Finance, HR, CRM, Supply Chain, etc. This facilitates the alignment with user organizations. If practical, co-locating them is ideal. Cross training is also desirable to add necessary staffing flexibility. This type of support team can shift from the traditional reactive service model (“please fill out an enhancement request”) to a proactive one that is directly involved with business area decision processes and their users’ overall experience. They can resolve issues and train as necessary; while monitoring user acceptance, usage, and satisfaction. When additional development work or tuning is required, it can be handled directly by the dedicated spoke resources; working with the hub as necessary on shared tasks involving data acquisition and administration.

The other key consideration is to what extent business-side organizations can devote bandwidth to the support effort. Ideally, some can be carved out to support and train fellow users, help debug applications and data, and participate in data stewardship. In reality though, the roles do not change, only the organization that is providing the staffing and controls the budgets. Business organizations that are shifting from hosted to SAAS BI environments are likely better served by providing their own support staffing and relying on in-house IT hubs for data acquisition and governance. This tends to be a natural fit as the SAAS vendors tend to be more customer service oriented than in-house IT departments out of necessity.

Process: Customer-focused organizations enable customer-focused processes that begin within the spokes and work their way back to the hub. One example is training. If this solely takes the form of generic tools training for all users, it will not be as effective as training that is customized by role and business area. This can be easier than it sounds if a template is provided that includes all the basic concepts that can be customized and delivered by spoke staff to specific groups with similar tasks and requirements. Commonly desired enhancements to the templates, including those corresponding to application enhancements, are communicated back to the hub for inclusion in the templates.

An analogous approach can be applied to development of generic “accelerators”. These can include report and dashboard templates, portal designs, collaboration tools, data dictionaries, provisioning models and security schema. One practice I highly recommend is a “promotion” process for successful designs. For example, when a report or dashboard design gains high acceptance within one business area, it can be adapted to others or become an enterprise standard that is centrally maintained.

This brings up another important success factor for self-service BI: Creation of a formal group that includes representation from the hub, the spokes, and accomplished users that collaborates actively and meets regularly either physically or virtually on a regular basis. I like to call it a “community of practice” but I have seen it go by many other names, including “center of excellence” although that one always sounded a little pretentious to me. These groups are very effective for knowledge sharing, promotion of the technology tools, and overall two-way communication with the user community at large. I also encourage members to show successful new applications of the technology, tools, and models off to the group. This is a great way for architects within the hub to stay close to trends and changes in business requirements.

One note about the testing process: It also has centralized and de-centralized aspects, but it is a bit different in the sense that integrated systems tests usually involve the entire user community and requires a high level of coordination and central project management. As such, it generally requires central administration with user area validation.

Technology: I do not have as much to say about technology because, contrary to popular misconception, the technology choices and system architecture are generally not a key to success. In fact, on occasion I see technology platforms completely replaced to solve what is really a process issue. Most, if not all of the mainstream tools and data platforms out there can underpin a successful self-service platform, as long as there is a well thought out user interface that is easy to use. Often, this is in the form of a portal; but can be as simple as the universal front end known as Excel. The goal is remove barriers to availability and utility by making:

1. your applications easy to acquire and use on multiple devices
2. your data reliable, transparent, relevant, and timely, and
3. help available when and where it is needed

My last post in this series will discuss some of the favorable and unfavorable environmental factors as it relates to standing up a self-service BI environment.