Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

[DSC Europe 22] The Making of a Data Organization - Denys Holovatyi

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio

Eche un vistazo a continuación

1 de 16 Anuncio

[DSC Europe 22] The Making of a Data Organization - Denys Holovatyi

Descargar para leer sin conexión

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.

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.

Anuncio
Anuncio

Más Contenido Relacionado

Más de DataScienceConferenc1 (20)

Más reciente (20)

Anuncio

[DSC Europe 22] The Making of a Data Organization - Denys Holovatyi

  1. 1. The Making of a Data Organization Denys Holovatyi, OSNOVA GmbH 14 November 2022
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Pieces of a solution: Skills & roles Skills & roles Business user Data scientist Source system expert KPI expert Master data manager Legal Controlling
  14. 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. 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
  16. 16. Thanks for your time!

Notas del editor

  • 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.

×