Data teams often struggle to deliver value. KPIs, data pipelines, or ML driven predictions aren't inherently useful - unless the data team enables the business to use them. Having worked on 37 data projects over the past 5 years, with total client revenue clocking at about $350B, I started noticing simple success factors - and summarized those in the Operating Model Canvas & the Value Delivery Process. With those, I branched out into what I call data organization consulting and help clients build their data teams for success, the one you see not only on paper but also in your P&L. In this talk, I'll share some insight with you.
[DSC Europe 22] The Making of a Data Organization - Denys Holovatyi
1. The Making of a
Data Organization
Denys Holovatyi, OSNOVA GmbH
14 November 2022
2. Work on a project for half a year
and see it put into the drawer...
That's what happens a lot in IT, especially in the data space –
85% of the data projects never see the light of day, acc. to Gartner
3. How do I know?
Having worked in the space of data science for the past 6 years, I’ve seen many teams, successful and
not so much, across my customers’ organizations. Those vary in size between ~$1M and >$50B in
revenue across manufacturing, insurance, recruiting, consulting etc.
Co-founder & Head of Delivery at OSNOVA GmbH
Founder at EnterpriseAI, consulting for data analysis
Founder at Technology Messenger Munich, AI community
• 37 data science projects in customer service, marketing, sales
• Total customer revenue clocking in at about $350B
• World-class expertise in process analysis and design of operating models for data teams
Celonis and KPMG alumnus
4. Typical hurdles
Why do data projects fail? Reasons are plenty but there are some typical hurdles that tend to happen.
NO DATA
NO CONSUMABLE
ARTIFACTS
CHANGING
OBJECTIVES
WEAK ADOPTION MISMANAGEMENT
5. No data
Let’s analyze material management data!
Oh but the workflows are not being recorded.
We can’t join the materials tables.
Is there anything in that field?..
6. No consumable
artifacts
● Don’t make a marketer use a machine
learning model
● “AI” on its own is not a product.
● Ship something: an app, a tool etc.
● Make sure IT knows how to deploy it.
● Make sure API endpoints are documented.
7. Changing
objectives
Let’s analyze this department and these 20
products!
vs.
We need to work across 5 departments and a
complete product palette of 3000 items!
Easy pilot project for 2-3 months for 2
people
Global rollout implementation for 1y for 5-
7 people
8. Weak adoption
There’s already this Excel file they’re using…
Change is hard
It’s company’s money, not people’s personal
They’ve always done it like that
9. Let’s align once again…
So who wants to do this task?
Next week is the SteerCo, we need to finish this task.
I really need to be in your daily meetings too!
10. What is the cause?
ALIGNMENT
Data science projects tend to be
multidisciplinary – and experimental in
nature.
Poor alignment between executive
decision makers, functional business
leaders, line workers, and IT / data
scientists causes flawed goal setting,
wrong expectations, etc.
BUSINESS NEED
How many times you’ve seen a project
get kicked-off because someone saw a
new shiny tool / read about an AI model
solving all their issues / was approached
by a salesperson from a vendor?
Way too often, the real need of the
business is forgotten, and the problem
being solved is derived from what is
available in the final solution already.
ENABLEMENT
Business users are faced with a new tool
they don’t know how to use – and if it’s
really needed if they can just log into
their ERP.
Most people who haven’t worked in
data, need support & training to learn
working with data. Basics of statistics,
finding insights in data, answering
common operational questions – need
to be taught.
11. Pieces of a solution: Organizational
hierarchy
Organizational
hierarchy
goaling, strategy, roadmap
prioritization, expectations
data maturity (organization)
Strategy
team workings
team in context (other data
teams, BW, data architects, BI)
team maturity
Tactic
project setup
internal processes
communication
Operations
12. Pieces of a solution: Process
Data science
implementation
process Pilot
Problem definition User testing / pivoting
Value showcase Go decision Big kick-off Rollout
Data
modelling
KPIs Dashboards Enablement
Value
realization
13. Pieces of a solution: Skills & roles
Skills & roles
Business user
Data scientist
Source system expert
KPI expert
Master data manager
Legal
Controlling
14. Puzzle coming together
SOOP
Strategic-operational & organizational plan
Data strategy
Operating Model Canvas
Project setup in context
What does the company want
to achieve?
Defines high-level approach to
using data in the organization.
Global goals are specified, data
use cases, and budgets.
How does the data team work
together?
Defines org structure, Value
Delivery Process, resource
planning, information
architecture used in the data
team.
How does a project team
implement a use case?
Defines project setup with roles
of all members (business user,
data scientist, KPI expert etc),
and a long-term vision to
compensate for temporary
nature of a project.
This approach is the basis for what I call „data organization consulting“
15. Case study from insurance
Problem
A large Swiss insurance company had trouble with their claims management process, resulting in slow claims resolution,
low customer satisfaction scores, and high cost per claim.
Data strategy OMC Project
Discovery & selection of the
business process:
– Based on the insurance value
chain, product development,
sales, claims management
identified as 3 core processes
– Claims selected as the process
with the most perceived
inefficiencies – and available data
Understanding the organization
(departments involved, customer
outcomes)
Connecting to global initiatives in
Process Excellence and Claims 2.0
Setting up internal processes for
process discovery, KPI validation,
writing SQL code
Defining data architecture with the
Data Management & Warehouse
team (cloud BI, Azure data lake, built-
in ETL)
Training 2 data engineers on
technical (extraction, SQL,
dashboards) and business side (claims
process basics, jargon, department
goals)
Building data integration pipelines
(database access, programming the
pipelines, data extraction & in-tool
storage)
Developing dashboards (visualization,
finding generation, root cause
analysis)
Training business unit employees
(enablement on software usage,
data-driven process analytics)
Development of an action plan to
mitigate inefficiencies
Digital Journey
along with a
SOOP
Results 5 million € of savings opportunities in claims reserves were identified
A new approach for the First Notice of Loss was developed to improve appraisal quality and speed
Cost drivers were identified, incl. cost categories and expensive claim types
No (or not enough) data.
Imagine you meet a customer, they’re like wanna analyze QM.
Me: yeah I can use EDA, modeling, prediction of inventory etc etc
Next week you meet your contact, let’s call her Amanda. She invites SAP basis team. You name tables, QMEL etc. They tell you: no data! Yeah, no workflows for QM, only sales and CS.
e.g., can’t join materials tables. Then you’re fucked. Problem becomes unsolvable.
Sometimes there are workarounds, e.g., take older data.
You ship something at the end of every project: solution, app, model.
In AI – often nothing at the end. Modes are not consumable, no business user can get value out of it. Try sending a pickle file to marketing folks.
Make sure to build at least some simple interface.
Make sure IT knows how to deploy it.
Make sure API endpoints are documented.
New people will come and know where to start!
Comes from the essence of PM.
In a perfect world, you’d need to scratch the whole project when the objective changes.
How many defect parts we produce vs. How many defect parts our vendors produce? – sound similar, but very different at their core.
It’s your internal production – or supplier screening and control, purchasing questions. You need to talk to a different internal team and solve a completely diff problem. New tables, columns, process definition etc. In real life, people pivot.
Imagine, you’re in the middle of your AI studies at Hyper Island and wanna now become a singer. Some qualities needed: persistence, goal oriented, time money effort investment.
Imagine, you deployed the app.
Amanda, now you know what to do with the inventory. Weeks go by, no answer. You call: How’s the model? She: we don’t use it coz I got that simple Excel forecasting file.
Then she describes her workflow, where your model doesn’t fit.
First, you cry. Then, you learn.
She doesn’t want change. Money wasn’t hers. She doesn’t care.
Enablement must be an integral part of the project.
Your solution is faster, better, it saves them time and effort personally – no one cares about company’s money.
Good luck getting a second project if the first one wasn’t adopted.
Imagine, you deployed the app.
Amanda, now you know what to do with the inventory. Weeks go by, no answer. You call: How’s the model? She: we don’t use it coz I got that simple Excel forecasting file.
Then she describes her workflow, where your model doesn’t fit.
First, you cry. Then, you learn.
She doesn’t want change. Money wasn’t hers. She doesn’t care.
Enablement must be an integral part of the project.
Your solution is faster, better, it saves them time and effort personally – no one cares about company’s money.
Good luck getting a second project if the first one wasn’t adopted.