True Causes
ML

മൂലകാരണ വിശകലനം

എന്തുകൊണ്ട് ഒന്ന് പിഴച്ചു എന്ന്, ഉത്തരം അനങ്ങാതാകുന്നതുവരെ, ചോദിച്ചുകൊണ്ടിരിക്കുന്ന ശാസ്ത്രമാണ് മൂലകാരണ വിശകലനം. വേര് പരിഹരിച്ചാൽ അതിനുമുകളിലുള്ള ലക്ഷണങ്ങളും പോകും; ഒരു ലക്ഷണം പരിഹരിച്ചാൽ അത് തിരികെ വരും. ഗുണനിലവാര മാനേജ്മെന്റും IT സംഭവ പ്രതികരണവും രോഗി സുരക്ഷയും വ്യോമയാനവും ഒരു പരാജയത്തിനുശേഷം ഇത് നിർബന്ധമാക്കുന്നു. രീതികൾ തമ്മിലുള്ള പ്രധാന വ്യത്യാസം ആരാണ് യുക്തിവിചാരം ചെയ്യുന്നത് എന്നതിലാണ്.

രീതികൾ

അഞ്ച് എന്തുകൊണ്ടുകൾ
പരാജയത്തോട് “എന്തുകൊണ്ട്” എന്ന് ചോദിക്കുക, പിന്നെ ഉത്തരത്തോട്, അഞ്ച് തവണ. ഒരാൾ അല്ലെങ്കിൽ ഒരു ചെറിയ ടീം. വേഗമേറിയതും ചെലവു കുറഞ്ഞതും; അത് കാരണങ്ങളുടെ ഒരു ശൃംഖല കണ്ടെത്തുന്നു — ചോദിക്കുന്നയാൾ ഇതിനകം സംശയിക്കുന്നത്. ഒരൊറ്റ സംവിധാനമുള്ള ഒരൊറ്റ സംഭവത്തിന് നല്ലത്; കാരണങ്ങൾ പരസ്പരം ഇടപെടുന്നിടത്ത് ദുർബലം.
ഫിഷ്ബോൺ (Ishikawa) ഡയഗ്രം
കാരണങ്ങളെ വിഭാഗങ്ങളായി തിരിക്കുന്നു — ആളുകൾ, പ്രക്രിയ, ഉപകരണങ്ങൾ, സാമഗ്രികൾ, പരിസ്ഥിതി — ഒരു നട്ടെല്ലിൽ നിന്നുള്ള മുള്ളുകളായി വരയ്ക്കുന്നു. ഒരു സംഘത്തിന്റെ നിർദേശങ്ങളിൽ നിന്ന് ഒരു നടത്തിപ്പുകാരൻ അത് പൂരിപ്പിക്കുന്നു. ആഴത്തിലല്ല, വീതിയിലാണ്: സാധ്യതയുള്ളവയെ പട്ടികപ്പെടുത്തുന്നു, പക്ഷേ ഏത് കാരണം ഏതിനെ സ്വാധീനിക്കുന്നു എന്ന് ഒന്നും പറയുന്നില്ല.
ഫോൾട്ട് ട്രീ വിശകലനം
പരാജയത്തിൽ നിന്ന് AND/OR ഗേറ്റുകളിലൂടെ അടിസ്ഥാന സംഭവങ്ങളിലേക്ക് മുകളിൽ നിന്ന് താഴോട്ടുള്ള ഒരു യുക്തിവൃക്ഷം. ഘടകങ്ങളും അവയുടെ പരാജയ രീതികളും അറിയാവുന്ന എഞ്ചിനീയറിങ് സംവിധാനങ്ങൾക്ക് കണിശമായത്. നിർമിക്കുന്നത് ഒരു വിശകലന വിദഗ്ധൻ; സാമൂഹിക ലോകത്ത് അപൂർവമായേ ഉള്ള ഡാറ്റ ഇതിന് വേണം.
പരേറ്റോ വിശകലനം
സംഭവങ്ങളെ വിഭാഗമനുസരിച്ച് എണ്ണി, അവയിൽ ഭൂരിഭാഗത്തിനും കാരണമാകുന്ന വിഭാഗങ്ങൾ പരിഹരിക്കുക. വേദന എവിടെയാണെന്ന് പറയുന്നു, അതിന് കാരണമെന്തെന്നല്ല — മുൻഗണന നിശ്ചയിക്കാനുള്ള ഉപകരണം, കാരണം കണ്ടെത്താനുള്ളതല്ല.
Structured Democratic Dialogue
പ്രശ്നം അനുഭവിക്കുന്നവർ തന്നെ സാധ്യതയുള്ള കാരണങ്ങൾ എഴുതുന്നു, അവ വ്യക്തമാക്കുന്നു, എന്നിട്ട് — ഒരു സമയം ഒരു ജോടി, 75% പരിധിയിൽ — ഓരോ കാരണവും മറ്റേതിനെ കാര്യമായി സ്വാധീനിക്കുന്നുണ്ടോ എന്ന് വിലയിരുത്തുന്നു. ഉത്തരങ്ങൾ ഒരു അൽഗോരിതം (interpretive structural modelling) സ്വാധീന മാപ്പായി കൂട്ടിച്ചേർക്കുന്നു; മാപ്പിന്റെ അടിയിലുള്ള കാരണങ്ങളാണ് വേരുകൾ. അമ്പത് വർഷത്തെ പ്രയോഗം, രേഖപ്പെടുത്തിയ നൂറുകണക്കിന് സംവാദങ്ങൾ. ഈ സൈറ്റ് നടത്തുന്നത് ഇതാണ്.

സംഘം വിശകലന വിദഗ്ധനെ മറികടക്കുന്നത് എപ്പോൾ

ഒരു ചോദ്യമാണ് തീരുമാനിക്കുന്നത്. കാരണം മുറിയിലുള്ള ആർക്കെങ്കിലും അറിയാമോ? ഒരു യന്ത്രം തകരാറിലായാൽ, ലോഗുകളുള്ള ഒരു എഞ്ചിനീയർ പതിനഞ്ച് പേർ വോട്ട് ചെയ്യുന്നതിനേക്കാൾ വേഗത്തിൽ കാരണം കണ്ടെത്തും. ഡെലിവറികൾ വൈകുകയോ, രോഗികൾ കാത്തിരിക്കുകയോ, ഒരു സ്കൂളിന് അധ്യാപകരെ നഷ്ടപ്പെടുകയോ, ഒരു പട്ടണത്തിന് വിശ്വാസം നഷ്ടപ്പെടുകയോ ചെയ്യുമ്പോൾ, കാരണങ്ങൾ ഉൾപ്പെട്ട ആളുകളിലായി ചിതറിക്കിടക്കുന്നു — ഒന്ന് രാത്രി ഷിഫ്റ്റിന് അറിയാം, മറ്റൊന്ന് ഡിസ്പാച്ചർക്ക്, മൂന്നാമത്തേത് ഉപഭോക്താവിന് — ഒരു വിശകലന വിദഗ്ധന്റെ കൈയിലും അവ മുഴുവനില്ല. അപ്പോൾ രീതി എല്ലാവരിൽ നിന്നും കാരണങ്ങൾ ശേഖരിക്കുകയും ബന്ധങ്ങൾ എല്ലാവരെക്കൊണ്ടും വിലയിരുത്തിക്കുകയും വേണം; അല്ലെങ്കിൽ വിശകലന വിദഗ്ധൻ ഇതിനകം വിശ്വസിച്ചിരുന്നത് മാത്രമേ അത് കണ്ടെത്തൂ.

സാധാരണ ഒരു സംഘ ചർച്ചയും ഇത് ചെയ്യാത്തത് എന്തുകൊണ്ടെന്ന് ഗവേഷണത്തിലെ രണ്ട് കണ്ടെത്തലുകൾ വിശദീകരിക്കുന്നു. കാരണങ്ങൾ തമ്മിലുള്ള ബന്ധങ്ങൾ പരിശോധിക്കുന്നതിന് മുമ്പ് അവയെ പ്രാധാന്യമനുസരിച്ച് റാങ്ക് ചെയ്യാൻ ആവശ്യപ്പെട്ടാൽ ആളുകൾ തെറ്റായി റാങ്ക് ചെയ്യുന്നു — തെറ്റായ മുൻഗണനാ ഫലം — അഭിപ്രായം ചോദിച്ചാൽ ഒരു സംഘം അവ ഒന്നിനും ഭൂരിപക്ഷം കിട്ടാത്തവിധം ചിതറിക്കുന്നു — സ്പ്രെഡ്‌തിങ്ക്. ഘടനാപരമായ സംവാദം ഇവ രണ്ടിനെയും മുൻനിർത്തിയാണ് നിർമിച്ചിരിക്കുന്നത്: ബന്ധങ്ങൾ വിലയിരുത്തുന്നതുവരെ റാങ്കിങ്ങില്ല, ബന്ധങ്ങൾ ഓരോന്നായി വലിയ ഭൂരിപക്ഷത്തോടെ വിലയിരുത്തുന്നു.

നല്ല മൂലകാരണ വിശകലനം നൽകുന്നത്

ഏഴ് ഘട്ടങ്ങളുള്ള മാതൃക · യഥാർഥ സംഖ്യകളോടെ ഒരു ഉദാഹരണം · എത്ര സംഘങ്ങൾക്കും വേണ്ടി ഈ സൈറ്റ് ഇത് എങ്ങനെ നടത്തുന്നു