TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Adopting a Data-Centric Culture (Part 3 in a Series)

In the final part of our series, we look at the characteristics of a data-centric culture and how to adopt such a culture in your own enterprise.

• By Jonathan Fowler
• April 6, 2018

In Part 2 we introduced five key aspects of a data-centric culture and discussed what that culture is not. In this article we will look at what a data culture is and how to move your enterprise in that direction.

Let's look at the same principles of a data-centric culture.

Access

A data-centric culture breaks down the barriers of siloed data. It is unreasonable to expect all departments to drop their systems and adopt an integrated ERP. However, you can establish a data warehouse (DW) environment and assess how each system of record can contribute to that DW every day.

Each department remains comfortable with its native system of record and integrates its data with the rest of the organization. Everyone knows what data is available, where it can be found, and why it is important. The data and processes are governed by common standards agreed upon by stakeholders.

Buy-In

Executive leadership of a data-centric culture is critical. This could include managers using data to share insights with teams, executives taking the time to collaborate on their desired metrics for dashboards, or best-practices workshops across the organization. Leadership action largely depends on your existing culture and the needs of your organization. Overall, the examples provided by managers will ripple across the organization. Data is everyone's business, not just the domain of developers in IT. If company leadership doesn't buy into this mentality, efforts within the organization have no roots.

Courage

In an environment of ad hoc needs and the driving desire to produce, you'll need courage to step back and stop kicking underlying issues down the road. Repeating unscalable processes and duct-tape fixes only wastes your company's time. It holds scalability and replicability hostage. Stand up, step back, and assess the product and process from end to end. Spending four extra hours of unbillable time once to fix underlying data issues can save countless additional hours down the road.

Documentation

As good as BI developers are, they don't know your subject matter like your SMEs and end users do. Leaving them to create reports and visualizations without mapped processes that reflect what is important and how the processes can be understood is asking for failure. The most overlooked strengths of a BI developer are helping others think differently about their data and crafting requirements around that greater understanding. Collaboration between BI developers and end users should produce better documented outcomes and project maps that connect the origin data to the desired end views.

Empowerment

Technology serves to empower and enable the BI solution but can be a major roadblock if the right tool is not selected or the chosen solution upends your internal processes. Rather than thinking of the technology solution first and then backing into the requirements and processes, choose the specific technology package after establishing your enterprise's goals, desires, and specific needs. Don't let the software package dictate the end products it provides. Doing so undermines both your own goals and the strengths of the software package itself. Your company is left with unfulfilled needs and a skewed impression of the chosen technology.

Best Practices in Action

Let's apply these ideas to Acme Widgets.

Assuming we are hired as consultants and have carte blanche to get Acme turned around, we would start with an assessment of the organization's BI maturity. There are a number of rubrics for this. Everyone in the organization should independently complete the assessment. Between this and a short survey designed to solicit each employee's views on information sharing, ownership, and collaboration, a credible assessment of everyone's true attitudes towards the organization's existing data culture emerges.

The next step involves workshops. These take on different objectives, but we typically look for:

• Asset information such as existing systems of record and ownership
• Silos and bottlenecks
• Existing lines of communication between end users and developers
• Communication gaps
• Foundational issues that haven't been addressed
• Outcomes and desires
• Documentation

This begins data-centric communication that stresses both ownership (data is everyone's business) and buy-in (with executives present and engaged). What will follow are discussions about what departments own which data assets, what they tell us now, what they should be telling us, what reports are needed, and who the go-to person is for each particular process.

Business units and subject matter experts will emerge to outline functional requirements and useful metrics. Database developers will collaborate to design the data environment to support these desires. Managers and executives will work with SMEs and developers to craft relevant dashboards and reports.

Finally, specific software packages will be assessed and debated based on the needs identified by the group.

The benefits from this process go further. Taking this "step back" helps you establish a data-driven culture in which the foundation is addressed first. From there, your organization understands where it came from, where it is going, and how your data assets will drive you forward.