Avstanden mellom operative og analytiske behov med Theory of Constraints

Strategiske mål i en virksomhet er som regel sterkt koblet til data og innsikten som dataanalysen kan gi. Produktutvikling av operasjonelle systemer ender allikevel med å prioritere andre behov enn analytiske behov, spesielt i større virksomheter. Dette resulterer som ofte i uklarheter om produktet som utvikles oppnår effekter som samsvarer med strategien. Spørsmålet blir om det er mulig å tilpasse produktutviklingen slik at det er forenelig med å prioritere analytiske behov på lik linje med andre behov? Svaret er todelt. Taktisk og operativt ligger stort potensiale i desentraliseringen, av både ansvar og beslutningsprosesser. Strategisk kan vi anvende Theory of Constraints, en ledelsesfilosofi som fokuserer på å avdekke begrensninger (aka. Constraints) som hindrer virksomheten i å oppnå sine mål. Ved å kombinere dette får vi noen prioriteringsregler som bidrar til å drive et prosjekt i retning av langsiktige strategiske mål uten at det går utover prosjektets kortsiktige behov. Foredraget vil vise eksempler fra konkrete prosjekter i ulike domener der Theory of Constraints var anvendt eller kunne bli anvendt med suksess.

Transcript

1. Avstanden mellom operative og analytiske behov om desentralisering, tverrfaglighet og Theory of Constraints Make Data Smart Trondheim 2024 Mufrid Krilic Domain-Driven Design Coach, CoWork
2. Hva er problemet vi skal løse? • Hvordan kan vi se helheten i komplekse omgivelser? • Uten å se helheten hvordan vite at vi prioriterer riktig ting til enhver tid?
3. Forstå helheten for å forstå behovene • Vi har en tidlig tendens å klassifisere behovene uten å forstå de skikkelig • Utfordringen er at klassifiseringen fører til motstridende prioritering Operative behov Analytiske behov
4. Grunnleggende ulikhet i behovene Operasjonelle behov • forankret i data som er transaksjonsbasert • holder rede på tilstand om forretningsentiteter til enhver tid Analytiske behov
5. Grunnleggende ulikhet i behovene Operasjonelle behov Analytiske behov • forankret i data som representerer aggregert perspektiv over forretningshendelser over tid • ment å tilby retrospektiv eller fremtidig innsikt
6. Grunnleggende ulikhet i behovene Operasjonelle behov Analytiske behov aggregert perspektiv over tid tilstand til enhver tid
7. Agenda i dag • Prioritering i komplekse omgivelser • Forstå behov eller planlegge konkrete oppgaver? • Tverrfaglighet og desentralisering for å forstå behovene • Hvordan prioritere på behov?
8. CoWork – metodikk for håndtering av kompleksitet • Tight Loose Tight – TLT • Strategisk og smidig ledelse • Domain-Driven Design • Produkt- og teknologiledelse With Courage to Make Changes Domene-drevet produktorganisering
9. • Desentralisering tvinger frem tverrfaglighet • Ekte tverrfaglighet krever desentralisering Oppsummering • Forutsetningen for å kunne prioritere riktig mellom analytiske og operative behov er å forstå behovene • Involver interessentene (stakeholders) • «Hvem er sluttbruker/interessent/beslutningstager?» • Domene-drevet produktorganisering for å oppnå ekte tverrfaglighet • Rask data-drevet feedback for å håndtere kompleksitet • Finn begrensningen som hindrer deg i å få rask nok feedback
10. Prioritering i komplekse omgivelser Forstå behov eller planlegge konkrete oppgaver?
11. En historie fra komplekst domene • Helsedomenet • Spesialist-helsetjeneste
12. Generiske og «stabile» datamodeller • I helse møter vi ofte kompleksitet gjennom generelle abstraksjoner • Analytiske behov blir • enten generalisert på samme måte • eller overlatt til «noen andre»
13. Stabilitet i data og teamstruktur • «Stabile» begreper • Journaldokumenter • Henvisninger • Medikamenter • Behandlingsplan • Operative produktteam • Journal team • Henvisning team • Medikasjon team • Behandlingsplan team
14. Det er ikke bare leverandørene som bruker generiske modeller • Helsestandarder snakker om det samme • Patient • Organization • Health Care Service • Medication
15. Hvorfor lager vi generiske og «stabile» modeller stadig vekk? • Forstår «noen som helst» i IT- industrien behovene i helsedomenet?
16. Avstanden mellom operative og analytiske behov • Komplekse og varierende behov => generisk datamodell • Generisk datamodell => generisk produktteam struktur • Generisk produktteam struktur => Stor avstand til behovene Vi generaliserer oss vekk fra behovene!
17. Avstanden mellom operative og analytiske behov • Analytiske behov er gjerne beslutningstager behov • Beslutningstagere er som regel på periferien av operativ produktutvikling Liten forståelse for analytiske behov hos produktteam!
18. Hvordan minke avstanden? • Kan vi prioritere på behov istedenfor på konkrete oppgaver? • Først må vi legge til rette for det….
19. Hvordan legge til rette for prioritering på behov? Domene-drevet produktorganisering med Levels of Alignment og Domain-Driven Design
20. Hva er problemet vi skal løse? • Hvordan kan vi se helheten i komplekse omgivelser? • Uten å se helheten hvordan vite at vi prioriterer riktig ting til enhver tid?
21. Systemtenkning! • Tilbakekobling sløyfer • «Feedback loops» • Innflytelsespunkter • «Leverage points» Feedback • Varmt eller kaldt vann Innflytelsespunkt
22. Kompleksitet • Domenet der forholdet mellom årsak og konsekvens fremkommer først i etterkant • Ingen «riktige» svar • Påvirker du systemet vil systemet kunne reagere på en uforutsigbar måte
23. Kompleksitet og systemtenkning • Systemtenkning lærer oss at vi ikke kan kontrollere komplekse systemer • Vi må lære gjennom feedback • Systemtenkning = data-drevet
24. Anvendt Systemtenkning • Innta to ulike perspektiver 1. Utside fokus: Hva slags behov skal systemet dekke? 2. Innside fokus: Hvordan skal behovene dekkes?
25. Levels of Alignment, CoWork modell Hva er vi lojale mot? Utside fokus Innside fokus 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise
26. Levels of Alignment Utside fokus Innside fokus 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise Behovene på nivå 4 og 5 er kun mulig å forstå om du forstår konteksten til sluttbrukere eller interessenter
27. Levels of Alignment Utside fokus Innside fokus 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise Prioritering på nivå 1-3 betyr prioritering av konkrete oppgaver, ikke behov
28. Levels of Alignment Utside fokus Innside fokus 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise Hva betyr dette i praksis?
29. Tight-Loose-Tight (TLT), CoWork ledelsesmodell Utside fokus Innside fokus 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise Første Tight (T): Forstå kontekst og gi retning på nivå 4 og 5 Loose (L): Oppnå mål slik teamet mener er best Andre Tight (T): Lytt og planlegg ut fra feedback
30. Domenegrensene gir kontekst => Domain-Driven Design
31. Samarbeid og læring Domene-drevet produktorganisering Utside fokus Innside fokus 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise
32. Oppfølgings- spørsmålet alle bør stille seg….. Hvem er bruker?
33. Historie fra helsedomenet Forskrivning av resepter i norske sykehus
34. • Forordning av legemidler • Forskrivning av resepter • Psykiatri • Psykofarmaka er en samlebetegnelse for legemidler hvis hoved effekt er å påvirke psykiske funksjoner • Somatikk • Legemidler for behandling av fysiske sykdommer Domene: Medikasjon
39. Tegnet med egon.io
40. Bok anbefaling
41. Oppfølgings- spørsmålet alle bør stille seg….. Hvem er bruker?
42. Hvem er bruker? Farmasøyt
43. • Forordning av legemidler • Forskrivning av resepter • Psykiatri • Psykofarmaka er en samlebetegnelse for legemidler hvis hoved effekt er å påvirke psykiske funksjoner og dermed brukes i behandlingen av psykiske lidelser • Somatikk • Legemidler for behandling av fysiske sykdommer Domene: Medikasjon Forretningstjenester! Hvem er bruker?
44. • Forordning av legemidler • Forskrivning av resepter • Psykiatri • Psykofarmaka er en samlebetegnelse for legemidler hvis hoved effekt er å påvirke psykiske funksjoner og dermed brukes i behandlingen av psykiske lidelser • Somatikk • Legemidler for behandling av fysiske sykdommer Domene: Medikasjon Veldig spesifikt behov for psykiatrien
45. Samarbeid og læring Teamene organiseres rundt brukerens oppdrag Organiseringsform Ytre fokus Indre fokus 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise
46. Forretningstjeneste somatikk Teamene organiseres etter forretningstjenester Organiseringsform 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise Forretningstjeneste psykiatri
47. Domene-drevet produktorganisering • Ekte tverrfaglighet • forutsetter desentralisering • betyr å involvere sluttbrukere, interessenter og beslutningstagere • Uten desentralisering eller involveringen blir behovene fremdeles fjernt for teamene
48. Forretningsområde somatikk Samarbeid og læring Prioritering ut fra Levels of Alignment Organiseringsform 5. Samfunnsoppdrag 4. Bruker 3. Prosjekt 2. Rolle og prosess 1. Ekspertise Forretningsområde psykiatri Samarbeid og læring Nivå 4 og 5 fokus gir prioritering av behovene Nivå 1,2 og 3 fokus gir prioritering av features
49. Desentralisering koster • Desentralisering av beslutninger! • Forutsi punktet der verdi og mulighetene med desentralisering blir større enn kostnader
50. Så hvordan kan vi prioritere på behov? Theory of Constraints
51. Forstå behovene raskest mulig i komplekse omgivelser • Systemtenkning er tydelig på at vi lærer komplekse systemer først og fremst gjennom feedback • Rask data-drevet feedback blir da et konkurransefortrinn!
52. Flyt for å få feedback • «Speed trumps everything» • For å få flyt må vi finne begrensninger i systemet
53. Bok anbefaling
54. Theory of Constraints • Metodikk for å identifisere og håndtere flaskehalser i operasjoner eller prosesser • «Styringsparadigme som ser på et system som begrenset til å nå sine mål av et få antall begrensninger» • Wikipedia
55. Theory of Constraints 1. Identifiser begrensningen 2. Bestem hvordan optimere begrensningen 3. Underordne alt annet til beslutningen tatt i trinn 2 4. Utvide begrensningens kapasitet 5. Hvis en begrensning er brutt, gå tilbake til trinn 1
56. Utvide begrensningens kapasitet Bestem hvordan optimere begrensningen Underordne alt annet til beslutningen tatt i trinn 2 Hvis en begrensning er brutt, gå tilbake til trinn 1 Identifiser begrensningen Bilde av Konstantin Smirnov
57. Hva er hindringen for å få rask nok data-drevet feedback? • Istedenfor å ha nok kapasitet til å levere det du har planlagt…. • …optimaliser på flyt av det som er til enhver tid mest prioritert
58. Flyt for å få feedback • «Speed trumps everything» • For å få flyt må vi finne begrensninger i systemet
59. Hvordan minke avstanden mellom analytiske og operative behov? • Prioriter begrensningen som hindrer/forsinker data-drevet feedback • Vær veldig forsiktig med andre, lokale, optimaliseringer!
60. Lettere sagt enn gjort…. • Vær forberedt på å måtte bryte organisasjonshierarkiet…. • …. eller i hvert fall muliggjøre kommunikasjon på tvers i virksomheten
61. Hva skjedde med analytiske behov i vår historie? • Team Medikasjon • Bestilling på konkret analytisk oppgave: • En rapport som viser oversikt over antall foreskrevne resepter over tid sortert på type resept og organisatorisk enhet på sykehuset • Avdeling, post, seksjon etc.
62. Stabilitet i data og teamstruktur • «Stabile» begreper • Journaldokumenter • Henvisninger • Medikamenter • Behandlingsplan • Operative produktteam • Journal team • Henvisning team • Medikasjon team • Behandlingsplan team
63. Generisk team får generiske oppgaver • Vi sliter å prioritere konkrete operative oppgaver mot konkrete analytiske oppgaver • Fordi vi er ikke tilstrekkelig tverrfaglig organisert til å ha direkte kontakt med de som har behov
64. Viser seg å være problem i flere team • Hvordan prioritere konkrete operative oppgaver mot konkrete analytiske oppgaver? • Interessenter får ikke feedback og data innsikt de har behov for • …. Men, hvem er sluttbrukere/ interessenter/beslutningstagere?
65. Hvordan finne begrensningen? • Vi etablerte Community of Practice • Bypass av organisasjonshierarkiet! • Samle behovene til produktteamene og "pain points"
66. Finn begrensningen! • Største begrensningen viste seg å være tungvint leveranse-pipeline for rapportene mot kundens miljø • Global begrensning!
67. Optimaliser rundt begrensningen! • Forbedring av leveranse-pipeline • Begrensningen flyttet seg til: • Forståelse av behovene og kjennskap til interessenter
68. Forstå behovene gjennom domene- analyse • Opprinnelig bestilling • En rapport som viser oversikt over antall foreskrevne resepter over tid sortert på type resept og organisatorisk enhet på sykehuset • Avdeling, post, seksjon etc.
69. Nå ble det lettere å prioritere…. • Kunden ønsker innsikt i hvor mange H-preparater som foreskrives • Veldig kostbare legemidler der sykehuset dekker hele utgiften • Økonomibehov til ledere for å følge med på hvor ofte foreskrives såpass dyre medisiner • Viste seg at rapporten kjøres en gang i året
70. Oppsummering
71. • Desentralisering tvinger frem tverrfaglighet • Ekte tverrfaglighet krever desentralisering Prioritere på behovene! • Forutsetningen for å kunne prioritere riktig mellom analytiske og operative behov er å forstå behovene • Involver interessentene (stakeholders) • «Hvem er sluttbruker/interessent/beslutningstager?» • Domene-drevet produktorganisering for å oppnå ekte tverrfaglighet på «nivå 4 og 5» • Rask data-drevet feedback for å håndtere kompleksitet • Finn begrensningen som hindrer deg i å få rask nok feedback
72. Takk for meg og ta gjerne kontakt! • Tight Loose Tight – TLT • Strategisk og smidig ledelse • Domain-Driven Design • Produkt- og teknologiledelse With Courage to Make Changes Domene-drevet produktorganisering
74. Bilder • https://vecteezy.com • https://medium.com/@smidesign/theory-of-constraints- 4216f04ae9b5