Kristen Daihes
Jan 27th, 2017

I often get asked what organization design construct is most effective in building out analytics capabilities within an organization. In canvassing our client base, all approaches broadly fit into three organization design constructs: centralized, center-led, and de-centralized. Other than the presence of an Analytics COE, there is no common construct in organization design that I observe resulting in higher ability to build out analytics capabilities.

There are, however, nine best practices that stand out in those clients who are most successful. And in my own experiences, I have found success and failure in building out analytics capabilities – and share three pitfalls to avoid. I hope the sharing of these nine best practices and three pitfalls to avoid from my own experiences provide value to you in your journey to build out analytics capabilities within your organization.

Nine Best Practices

1. Create a culture that embraces experimentation

Timothy Lee published an interesting article on Vox.com over the holidays about how Amazon innovates in ways that Google and Apple can’t. Amazon’s small teams experiment with an idea, continuing to nurture it and as the idea demonstrates viability, more resources and investment are put into the idea to deliver against more challenging milestones. These teams start small to determine viability following the two-pizza rule. That is – the teams supporting the idea must be small enough to be fed with just two pizzas. Many traditional manufacturing organizations underestimate the impact that learnings from the tech industry can have on their own enterprises.
Think about it – in most companies if the CEO endorses an idea, it becomes an imperative of everyone across the organization to support – making it nearly impossible to kill if it is a bad idea. Not only is it critically important to create a culture that embraces experimentation, people also have to be courageous in quickly shutting down ideas that are not viable, no matter who endorses them.

2. Nurture and grow capabilities both top-down and bottom-up

In the book Scaling Up Excellence, JetBlue is a great example of a company that has nurtured capabilities from the bottom-up. A mid-level manager showed the value of her work and it eventually changed the organization. The Google Operations Research team is a good example of a company that has nurtured analytics capabilities from the top-down. A recent INFORMS article shared that in peer reviews and presentations, a key expectation for all participants is engaging to improve the analysis. The Google OR team views being a spectator in a presentation and just applauding at the end a failure of engagement. The expectation is active interjections and debate to lead to a better outcome.

3. Focus on meeting user needs leveraging an AGILE framework

Uber and others have changed expectations of how easy a solution is supposed to work. Think about the Uber app, hit a button and a car shows up. Companies who are very effectives at this leverage an AGILE framework. Henrik Kniberg published the illustration below which quickly went viral – reinforcing the identification of the need to fulfill quickly, than learning and iterating. No longer is it effective to go into lengthy engagements working months to support the development of a solution which is unveiled at the end of this process. Success is in quickly launching the “minimal viable product”, learning from feedback, and quickly iterating to improve, such that at the end of the engagement stakeholders are happy with the outcome. This is not just for nimble start-ups, GE’s FastWorks framework also embraces this approach.

4. Build out teams with the right talent

It is not enough to just go after IT and math savvy talent. Of course talent skilled in machine learning, data engineering, operations research, programming, and statistics are important – but so is business translation, curiosity, visualization and storytelling. One of our talented data scientists said, “good analytics well told are much more powerful than great analytics poorly communicated.” It is important to build out complementary teams.
In addition to deep technical backgrounds, also look for generalist problem solvers. Remember when ATMs began popping up all over the place? People said it would be the death of tellers. Interestingly it changed economies of scale for the banking industry and we started to see the building of more, smaller branches. While the tellers per branch decreased, the overall rise of branches lead to an overall increase in tellers.
Next think about driverless trucks and the belief that this will lead to the elimination of millions of blue collar jobs in the trucking industry. What if these driverless trucks replace OTR trucking between warehouses, ultimately lowering transport costs, and leading to more regional warehouses and faster service times. This focus on delivery in the last mile then could lead to more local drivers. When building out analytics capabilities, you need to look for talent that can think creatively about how automated decision making may change things in ways you do not think about.

5. Adopt flexible operating models

Building out a centralized, center-led, or de-centralized organization construct is not what is important. What is important is adopting flexible operating models that enable you to evolve as the maturity level of your organization changes. And analytics needs context – sometimes you need different solutions for different markets. I remember one visit I made to a supplier in Oman and how quickly I realized that a solution we were building out for Western Europe markets just would not work for this supplier. You have to be open to adopting flexible operating models and considering different solutions required for different markets.

6. Embed analytics into existing processes

I hear a lot of stories about heroes “parachuting in” to put out fires across the organization. This hero mentality is worn with a badge of honor. Creating analytics capability through one-off projects will not lead to widespread adoption and sustainability. Instead focus on predicting and preventing, and eliminating failure modes completely. Reward people for preventing fires from occurring versus quickly putting them out. It is hard to shift out of the hero mentality, but success is about leveraging analytics as the way of solving problems in the organization.

7. Create an analytics COE and augment with strategic resources

The right resources can support you in continuing to push the boundaries of possibility within the organization and help you build out internal capability, driving a growth mindset across the organization. Leverage academia, consultants, and peer and industry forums to unhook your teams from marginally improving on the status quo – unleash the power of your organization to think differently about how to expand your business. Use these strategic resources to augment your COE in order to quickly staff up or ramp down to size up new opportunities and go after them. In a COE model, you can measure successful ROI on a portfolio of experiments through a balance of safe bets and high risk, high reward projects.

8. Create self-serve analytics

End-user requirements are changing rapidly. To keep up, functional areas will have to do more themselves. They now have the tools to do more without relying on IT – with an increasing landscape of advanced tools to enable them. Those organizations leading are rapidly building out self-serve analytics capabilities across their organization.

9. Use open source software

There are many advantages to adding open source software to your toolset. The open source approach allows you to identify a problem, start quickly building an algorithm, test it, and get the solution into production. These four steps can frequently happen in the time it normally takes to build a business case to tackle a problem using the traditional approach. This approach to solving problems allows you to tackle smaller problems, take more risks, and over time, implement many more solutions.

Let me give you a very real example. We are currently working with a transportation provider and just one week ago were asked whether we could help tackle a pain point they have, driving more automation into the process of determining how to best get a driver home. Let’s say a driver is currently in Chicago and wants to be in St. Louis for some off days in one week time. What is the best way to route the driver home, and how many loads could this driver pick up on the way? Within three days we had a working app for our client to test out that could optimize loads for a driver working the route back home, and could also identify incremental loads to take for a one day delay, allowing the driver to determine whether the incremental revenue was worth a later return.

Open source allows you to create functionality to suit your problem, and the integration level is defined by you. You can quickly tweak and adjust, and fill gaps between existing systems. Best of all this can be done at limited expense. Open source creates a new way to think about tools. In thinking about the traditional approach versus the open-source approach, remember one approach is not better than another. Both should have a place in your business.

Three Pitfalls to Avoid

1. SAP is not always the answer to everything

It is time for some true confessions. I have been in a few organizations where the belief was to standardize on common toolsets and focus on maximizing what you could get out of your of-the-shelf ERP and advanced planning solution implementations. I can tell you through my own struggles that SAP is not always the answer to everything. An ERP backbone coupled with a good advanced planning system is instrumental, but sometimes you need to explore different options to complement your existing systems in order to operationalize improvement opportunities.

For example, in one business data scientists built some pretty neat algorithms with cool analytics to predict when a mosquito outbreak was coming. This lead to tremendous speed to insight, all we had to do was figure out how to operationalize this insight to ensure we were moving stock to the right locations in time. We struggled to operationalize this insight with our existing systems, with a pressure to figure out how to go after this using only our current advanced planning solutions.

Another one of my favorites – “The Yard”. Admit it, we all have them. At least four times in my career I have become all too familiar with a yard full of drop trailers, and the constant struggle to determine how to best order unloading them. Which trailers have “hot loads” on them, and how do I get those unloaded first? In each case, it was not worth the time or money to solve this problem with a commercial package so it became a very laborious manual task to deal with. We are working with a retailer and recently discovered one of their “Yards”. Their openness to consider new options allowed us to go from idea to solution in just four weeks, and now
unloaders have a tool to be a little more efficient every single day – a small savings that will add up. The point is, SAP is not always the answer to everything – you should be open to exploring new ways of solving operational pain points.

2. Reign in and fulfill the data scientists

I was part of an organization that brought some phenomenal data science talent on board. These were smart resources, but we were not leveraging them in a smart way, and paid for it through retention challenges. We bogged them down with working the “IT plumbing”. And while this is important, it is not the end in mind. There was a lot of bickering about how to sell-in the right visualization packages versus exploring what was most appropriate to solve the problems at hand. If you plan to bring in a lot of smart talent in the analytics space, be clear on what you expect of them and keep them focused on the core of solving business problems in a different way.

3. What’s appropriate for solving the problem at hand

When building analytics capabilities, it is important to stay outcome focused – the priority is in how to best solve the problem at hand. I have been fortunate enough to be a part of building out a COE that is a success story and still contributing to a positive growth story. I also have had the misfortune of being a part of building out a COE journey that while successful at the time, was not sustainable. What was different in these two experiences? The disaster focused on tools, training talent on standard tools, building prescriptive models in a standard commercial software application. The models built were complex and hard to maintain. We delivered some good business recommendations, but as talent was poached to other parts of the business, we had to go outside for continued support. It was not a sustainable model and the focus was too much on tools versus solving business problems. The success story focused on solving a variety of business problems, and training talent to think differently. Commercial software was used where necessary, and with the appropriate level of complexity. We focused on standardizing the process of solving problems, not on tools. And believed in the strength of storytelling. Stay focused in your journey on what is most important – creating value through the continued solve of business problems, and be open to new ways of finding these solves.

Final Thoughts

Other than the presence of an Analytics COE, there is no common construct in organization design that we observe resulting in higher ability to build out analytics capabilities. I have shared nine best practices that stand out in our clients who are most successful in building out analytics capabilities, and three pitfalls to avoid. I hope you find value in the application of these Best Practices and Pitfalls to Avoid in your journey.