Software-Driven Company - Creating and Defining a Data-Driven Culture

About 9 months ago, I moved to the Business Intelligence and Analytics department in Michelin Americas as a technical architect. I've been with Michelin for almost 10 years in various technical roles, but this was a whole new challenge and opportunity. During that short 9 months, I've learned quite a bit, and been humbled even more. Each time I learn something new, I discover 5 additional things that I don't yet know. It is an intriguing, challenging, fulfilling, and even sometimes frustrating role.

One of my biggest challenges is finding the best way to create and implement a technical strategy that fits a vision and direction, which I will detail in this post.

Our initiatives

We have several initiatives I'm helping push forward with respect to our back-end systems and processes:

• Moving to the Azure cloud. We have back-end systems for many production flows running on legacy, on-premise systems and databases. Back-end systems in the cloud allow easier scalability, a more efficient cost structure, and ability to interface with a wider variety of data and reporting tools.

• Implementation of new tools. Dremio is a tool selected for POC by the enterprise architects in our central team. I'm performing a POC specifically in the Americas researching how we can use this as a virtualization layer, allowing users to access our Azure file storage via SQL rather than directly querying the flat files, increasing flexibility.

• Creation of a data custodian network. We need experts and direct contact points for all source systems that share data to make sure shared data is understood and being used accurately and efficiently. These people will be conduits for using technology to access the data and use the data.

• Creation of a data ownership network. This one sounds similar to the previous point, but is complementary and very different. We need a responsible party for each piece of data from a business standpoint. While custodians are focused on specific tasks, such as documenting the parameters of the data and facilitating access, owners are the directly accountable party for the data, its use, and the value it generates. I will touch on the important distinction between those two later in this article.

• Self service. This one is a bit more ambiguous. We want users to become more autonomous and knowledgeable with data and reporting across the board, not just limited to those in the Business Intelligence department.

The Problem

Above are all initiatives designed to move our company forward. Most agree on that across our IT department and in our interactions with business stakeholders. All of these are under the umbrella of the overall vision we're moving forward towards: becoming more data-driven. We need to have more access to data. We need to understand data better. We need to make decisions off of data. That data needs to be correct.

But it begs the question, when you step back to analyze the situation, moving forward towards what?

What does that mean?

What does that look like?

Why?

A few weeks ago, I got into a debate with one of my colleagues that really challenged me to think. He was challenging why we were pursuing some of the self-service initiatives to have users doing business intelligence themselves in areas of the business.

"The business hasn't defined the problem. What problem are we solving by implementing this? How do we solve a problem that isn't defined?" he asked me. And I sat there speechless. Because I had never thought about it that way, and I didn't have a good answer. Why were we doing this? Was it possible I was so focused on action that I missed, overall, this might not even be a worthwhile exercise?

I thought on this quite a bit the next few days. And I still couldn't answer what problem we were solving. Our overall systems are generally reliable. The cloud systems we are moving towards are even more robust. Our industrialized reports are being utilized, and aside from a vocal minority in the business, the user community seems to be mostly content either using those reports or doing limited BI work via spreadsheet. There was no evidence this was broken. There were areas we could improve on our systems, sure, but this wasn't really addressing any of those.

And then it clicked. We were identifying and addressing a problem, but not one presented to us directly by the business. And that wasn't just okay, it was good.

Traditional IT in a Manufacturing Organization

Michelin started as a company back in 1889 in Clermont-Ferrand, France. Michelin makes the best tire in the world, and continues to improve its ability to do so with technological innovations, cutting-edge design, and an undying insistence on quality products.

Although methodologies, people and the world in general have changed drastically in that 130 year span to present day, those core principles have remained. Staying true to those core principles while adapting with the world around it is the primary reason Michelin has been successful.

Michelin started without computers, as did all businesses founded in that timeframe. And as time went on, Michelin started to incorporate computers into their work to facilitate more efficiently making high quality products. It did so as a support organization for the core business.

This has been the model for years across the manufacturing industry.

Need a new system to better make tires? Give IT your requirements and funding, then they'll build it.

Need a more efficient sales system to interface directly with dealers? Mobilize IT to create it or integrate it from a third party vendor.

Computer system testing the tire designs breaks? Call IT; their job is to ensure those systems are up and running, and fix said systems when they aren't.

Systems are outdated? IT can propose the company look at upgrading, but if the systems are still working, this will have to be weighed against other costs to the company in next year's budget.

Transition to a Software-Driven Company

Yves Caseau, our company Chief Digital & Information Officer, provided a great post about our software-defined excellence for Michelin, and journey to become a software-driven company. I have linked it here, and highly recommend reading it as well.

https://blogit.michelin.io/software-defined-excellence-for-michelin/.

Several things stood out to me, such as this quote below:

In a world where agile software is eating the world fast, there exists a risk of digital disruption for companies that fail to adapt the ways of working of the digital native companies. Fortunately, both the tools and the practices of the Web giants have been widely popularized, so learning from the best is definitely possible. Second, because change must accelerate, “Taylorism” (to separate thinking from doing) is no longer efficient: technology is business and business is technology. Short decision cycles demand a mindset shift in the company, where people with business responsibilities have a keen interest with technology that is matched by the business interest of those in charge of technology.

-Yves Caseau

The world is changing. The world without enterprise computers from when Michelin was founded no longer exists, the world that Michelin was successful in with IT as solely a support organization does not either. We need to stop acting like it does.

Business Intelligence and Analytics is under our IT umbrella. And I'm not naive enough to think supporting back-end systems and providing business-requested enhancements won't be a large part of our responsibility. But it won't be all we do.

Our organization needs to partner with the business, proposing new solutions and ways of working.

Our group needs to lead the business, providing new tools that haven't been requested yet, educating them on how it can help their job efficiency.

We need to challenge the business so we work towards the best solution possible, not just what is asked of us.

Alignment with Data Mesh Approach

This lines up well with our enterprise approach of data mesh. I will briefly provide some details pertinent to my article here, but my colleague Joris Nurit wrote a detailed and thoughtful article on the subject I'd highly recommend reading for more information: https://blogit.michelin.io/3-years-after-data-mesh-lessons-learnt-from-early-believers-of-the-mesh/.

In short, this approach pushes away from a fully rigid framework, and provides flexibility and separated ownership. A command-and-control approach works well for standardization, but becomes a large bottleneck to progress, especially as usage of data grows in a global company.

Domains will hold the ultimate responsibility of making their data available for consumption by those who want to report from it. Business Intelligence will provide and support a technical platform to help facilitate it, but the responsibility sits with the teams that own the data.

The same principle applies to reporting from this data. There will always be industrialized reporting through the Business Intelligence department, but the platform and approach should facilitate and empower those closest to the data and the need to perform analysis and reporting as well.

Defining a Data-Driven Culture

This brings me to creation of a data-driven culture. But to create it, we must first define it.

We need a user community more literate with data. We need people more well-versed on data analysis tools. We need people that understand how data relates to their jobs and related decisions they make. So there's several areas we're looking at in our department to help improve that:

Training

The department is working on creating training sessions for the business community. These sessions range from PowerBI tool usage to locations and access to our data lake environments.

Accessibility

Our organization is on a legacy Azure Data Lake Storage Generation 1. The core team is working to upgrade this to Generation 2, which will allow users to directly query parquet format files (our standard data lake file format) without having to download them.

We are piloting tools like Dremio, which I mentioned earlier, to provide a virtual SQL front-end for this data, allowing interfacing from a wider variety of mediums. We are looking at offerings in Azure in parallel that have similar capabilities.

Standardization and Governance

In my opinion, this is our biggest hurdle. For data that is to be used across multiple groups, the purpose and scope of the data, fields, confidentiality, and more, all need to be documented. There need to be a clearly defined data owner and data custodian, i.e. a responsible party and a technical contact point for accessing and using the data.

This perfectly encompasses how we need to work as partners. Data ownership does no good without technology, direction, documentation, and application of that data. Likewise, data custodianship just becomes administration and paperwork without a larger vision and business direction. This is where two separate groups with different responsibilities and skillsets can complement each other, moving towards a common goal.

What does all this look like when we accomplish it? I don't know, and that's part of the point. This issue is big enough that it cannot and should not be entirely defined by one individual, one team or one group. Our department understands the tools and methodologies, the business understands their jobs and decisions that need to be made. Let's partner together to bridge that gap.

The world is changing rapidly. And if we wait until we are presented with a problem when something is broken to take action, we have already failed.

We're not working to address a business-identified problem. We're working to prevent one.