ഒരു OD, ടാലന്റ് പ്ലാറ്റ്ഫോമിനുള്ള ബിസിനസ് കേസ്: സോഫ്റ്റ്വെയറല്ല, തീരുമാനമാണ് വിൽക്കേണ്ടത്
സംഘടനാ വികസന, ടാലന്റ് സോഫ്റ്റ്വെയറിനുള്ള മിക്ക ബിസിനസ് കേസുകളും ആദ്യ പത്തു മിനിറ്റിൽത്തന്നെ പരാജയപ്പെടുന്നു, കാരണം അവ ഫീച്ചറുകളും ലാഭിക്കുന്ന മണിക്കൂറുകളും വിവരിക്കുന്നത് അവ്യക്തമായ നേട്ടങ്ങളുള്ള ഒരു ചെലവ് മാത്രം കാണുന്ന ലീഡർഷിപ്പ് ടീമിനോടാണ്. ഒരൊറ്റ തീരുമാനത്തിന്റെ ബിസിനസ് കേസ്, നേതൃത്വം ഇതിനകം അനുഭവിക്കുന്ന ചെലവേറിയ ഒരു പ്രശ്നത്തിൽ അഭ്യർഥനയെ നങ്കൂരമിടുകയും, ബജറ്റിനു മുമ്പ് ഒരു പൈലറ്റ് ആവശ്യപ്പെടുകയും ചെയ്യുന്നു.

സംഘടനാ വികസന, ടാലന്റ് സോഫ്റ്റ്വെയറിനുള്ള മിക്ക ബിസിനസ് കേസുകളും യോഗത്തിന്റെ ആദ്യ പത്തു മിനിറ്റിൽത്തന്നെ തോൽക്കുന്നു, അതും ഒരേ കാരണത്താൽ. അവ സോഫ്റ്റ്വെയറിനെ വിവരിക്കുന്നു: ഫീച്ചറുകൾ, മൊഡ്യൂളുകൾ, ഇന്റഗ്രേഷനുകൾ, ഓരോ മാനേജർക്കും ലാഭിക്കുന്ന മണിക്കൂറുകൾ. മുതിർന്ന നേതൃത്വം കേൾക്കുന്നത് അവ്യക്തമായി തോന്നുന്നതും വൈകി എത്തുന്നതുമായ നേട്ടങ്ങളോടുകൂടിയ ഒരു പുതിയ ചെലവാണ്. അംഗീകാരം ലഭിക്കുന്ന കേസുകൾ നേരെ മറിച്ചാണ് കെട്ടിപ്പടുക്കുന്നത്. നേതൃത്വം ഇതിനകം അനുഭവിക്കുന്ന, ചെലവേറിയ, ആവർത്തിക്കുന്ന ഒരു സംഘടനാ പ്രശ്നത്തിൽനിന്ന് അവ തുടങ്ങുന്നു, ആ പ്രശ്നത്തിന് എന്തു ചെലവു വരുന്നുവെന്ന് കാണിക്കുന്നു, അതിനു പണം നൽകുന്നത് നിർത്താനുള്ള ഏറ്റവും ചെലവുകുറഞ്ഞ വിശ്വസനീയ മാർഗമായി പ്ലാറ്റ്ഫോമിനെ അവതരിപ്പിക്കുന്നു. ബജറ്റ് ചോദിക്കുന്നതിനു മുമ്പ് അവ ഒരു പൈലറ്റ് ചോദിക്കുന്നു.
ഈ സംഭാഷണത്തിന്റെ ഇരുവശത്തും ഞങ്ങൾ ഉണ്ടായിരുന്നിട്ടുണ്ട്: കേസുകൾ കെട്ടിപ്പടുക്കാൻ എച്ച്ആർ, തന്ത്ര നേതാക്കളെ സഹായിച്ചും, അവയിൽ തീരുമാനമെടുക്കുന്ന ലീഡർഷിപ്പ് ടീമുകളുടെ എതിർവശത്ത് ഇരുന്നും. ഓരോ തവണയും ഞങ്ങൾ നൽകുന്ന അസ്വസ്ഥതയുണ്ടാക്കുന്ന ഒരു ഉപദേശമുണ്ട്: പ്ലാറ്റ്ഫോം മാറ്റാൻ പോകുന്ന തീരുമാനത്തിന് പേരിടാൻ നിങ്ങൾക്കാവില്ലെങ്കിൽ, നിങ്ങൾ അതു വാങ്ങരുത്. ഞങ്ങളുടേത് വാങ്ങുന്നതും അതിൽ ഉൾപ്പെടുന്നു.
«അത് എന്തു ചെയ്യുന്നു എന്നു നിങ്ങൾ പറഞ്ഞു, എന്തു മാറുന്നു എന്നു പറഞ്ഞില്ല»
ഏകദേശം മുന്നൂറ് ജീവനക്കാരുള്ള സൗദി അറേബ്യയിലെ ഒരു കമ്പനിയുടെ എച്ച്ആർ ഡയറക്ടർ ഒരു ടാലന്റ്, സംഘടനാ വികസന പ്ലാറ്റ്ഫോമിനുള്ള ബിസിനസ് കേസ് തയ്യാറാക്കാൻ ആഴ്ചകളോളം ചെലവഴിച്ചു. അത് മുപ്പതു സ്ലൈഡുകളോളം നീണ്ടു: നാല് വെണ്ടർമാരുടെ ഫീച്ചർ താരതമ്യം, പ്രകടന അവലോകനങ്ങളിലും റിപ്പോർട്ടിംഗിലും ലാഭിക്കുമെന്ന് കണക്കാക്കിയ മണിക്കൂറുകൾ, വെണ്ടർ കണക്കുകളിൽനിന്ന് നിർമിച്ച ഒരു നിക്ഷേപ വരുമാന കണക്കുകൂട്ടൽ.
ഏകദേശം പത്തു മിനിറ്റിനുള്ളിൽ ചീഫ് ഫിനാൻഷ്യൽ ഓഫീസർ അതു നിരസിച്ചു. എച്ച്ആർ ഡയറക്ടറുടെ മനസ്സിൽ തങ്ങിനിന്നത് കാരണമാണ്: «അത് എന്തു ചെയ്യുന്നു എന്നു നിങ്ങൾ എന്നോടു പറഞ്ഞു. എന്തു മാറുന്നു, ആര് അതു മാറ്റുന്നു എന്നു പറഞ്ഞില്ല.»
രണ്ടാമത്തെ ശ്രമം ഒരൊറ്റ സ്ലൈഡായിരുന്നു. ഏതാനും മാസം മുമ്പുള്ള ലീഡർഷിപ്പ് ഓഫ്സൈറ്റിൽ, വർഷത്തിലെ മൂന്ന് തന്ത്രപരമായ സംരംഭങ്ങൾ നിലച്ചുപോയെന്നും അവയുടെ ഉടമ ആരാണെന്ന് ആർക്കും പറയാനാകുന്നില്ലെന്നും സിഇഒ പരാതിപ്പെട്ടിരുന്നു. പുതിയ കേസ് ആ പ്രശ്നത്തിന് പേരിട്ടു, മൂന്നിൽ ഒരൊറ്റ സംരംഭത്തിൽനിന്നുള്ള വൈകിയ വരുമാനം മാത്രം കണക്കാക്കി, ആ മൂന്ന് സംരംഭങ്ങൾക്ക് ഉടമസ്ഥത നിശ്ചയിക്കാനും അവയെ പിന്തുടരാനും ലീഡർഷിപ്പ് ടീം പ്ലാറ്റ്ഫോം ഉപയോഗിക്കുന്ന തൊണ്ണൂറു ദിവസത്തെ ഒരു പൈലറ്റ് നിർദേശിച്ചു, മുൻകൂട്ടി യോജിച്ച ഒരു അളവ് പൈലറ്റ് കൈവരിച്ചാൽ മാത്രം ഫണ്ട് ആവശ്യപ്പെട്ടു. അതേ യോഗത്തിൽത്തന്നെ അതിന് അംഗീകാരം ലഭിച്ചു.
ഒരൊറ്റ തീരുമാനത്തിന്റെ ബിസിനസ് കേസ്
രണ്ടാമത്തെ ശ്രമത്തിനു പിന്നിലെ ഘടനയ്ക്ക് അഞ്ചു ഭാഗങ്ങളുണ്ട്; സോഫ്റ്റ്വെയറിനു മാത്രമല്ല, ഏതാണ്ട് ഏതു സംഘടനാ നിക്ഷേപത്തിനും അതു ഫലിക്കും.
- പ്രശ്നം. നേതൃത്വം ഇതിനകം അനുഭവിച്ചിട്ടുള്ള, പേരിട്ട, ആവർത്തിക്കുന്ന, ചെലവേറിയ ഒരു സംഘടനാ പ്രശ്നം, സാധ്യമെങ്കിൽ അവരുടെ സ്വന്തം വാക്കുകളിൽ. നിലച്ച സംരംഭങ്ങൾ, അവ്യക്തമായ തീരുമാനാവകാശങ്ങൾ, ഒരു നിർണായക ടീമിൽനിന്ന് നഷ്ടപ്പെടാൻ പാടില്ലാത്തവരുടെ കൊഴിഞ്ഞുപോക്ക്, ഉറയ്ക്കാത്ത ഒരു പുനഃസംഘടന. പ്രശ്നം നിലവിലുണ്ടെന്ന് നേതൃത്വം ഇതിനകം വിശ്വസിക്കുന്നില്ലെങ്കിൽ ഒരു ബിസിനസ് കേസും അവരെ ബോധ്യപ്പെടുത്തില്ല; പകരം അവിടെനിന്ന് തുടങ്ങുക.
- ഒന്നും ചെയ്യാതിരിക്കുന്നതിന്റെ ചെലവ്. പ്രശ്നം തുടർന്നാൽ അതിന് എന്തു ചെലവു വരുമെന്നതിന്റെ ശ്രേണികളിലുള്ള ഒരു കണക്ക്, നേതൃത്വം ഇതിനകം ഉപയോഗിക്കുന്ന പദങ്ങളിൽ: വൈകിയ വരുമാനം, നഷ്ടമായ കരാറുകൾ, പകരം ആളെ കണ്ടെത്താനുള്ള ചെലവ്, മുകളിലേക്ക് കയറ്റിവിടുന്ന പ്രശ്നങ്ങൾക്കായി ചെലവഴിക്കുന്ന മാനേജ്മെന്റ് സമയം. വലുതും തർക്കവിഷയവുമായ ഒന്നിനെക്കാൾ നല്ലത് മിതവും വിശ്വസനീയവുമായ ഒന്നാണ്.
- മാറ്റം. ഏതു തീരുമാനമോ പെരുമാറ്റമോ വ്യത്യസ്തമാകും, ആര് അതു വ്യത്യസ്തമായി ചെയ്യും. മിക്ക കേസുകളും ഒഴിവാക്കുന്ന ഭാഗം ഇതാണ്; കഥയിലെ സിഎഫ്ഒ ചോദിച്ചുകൊണ്ടിരുന്നതും ഇതുതന്നെ. സോഫ്റ്റ്വെയർ സ്വയം ഒന്നും മാറ്റുന്നില്ല; അതുപയോഗിച്ച് ആളുകൾ വ്യത്യസ്തമായി തീരുമാനിക്കുന്നതാണ് മാറ്റം.
- തെളിവ്. യഥാർത്ഥ പ്രശ്നത്തിൽ, തീരുമാനങ്ങൾ മാറേണ്ടവരെ ഉൾപ്പെടുത്തി, തുടങ്ങുംമുമ്പ് യോജിച്ച ഒരു അളവോടെ, സമയപരിധിയുള്ള ഒരു ചെറിയ പൈലറ്റ്.
- ആവശ്യം. പൈലറ്റിന്റെ ഫലവുമായി ബന്ധിച്ച ഘട്ടംഘട്ടമായുള്ള ഒരു പ്രതിബദ്ധത, ആന്തരിക സമയം ഉൾപ്പെടെ പൂർണ ചെലവ് വ്യക്തമാക്കി, ഫലിച്ചില്ലെങ്കിൽ നിർത്താനുള്ള വ്യക്തമായ വഴിയോടെ.
ഇങ്ങനെ കെട്ടിപ്പടുത്ത ഒരു കേസ് പലപ്പോഴും ഒരു പേജിൽ താഴെയാണ്. അതൊരു ദൗർബല്യമല്ല; ആ മാസം എടുക്കാൻ മറ്റു നാൽപ്പതു തീരുമാനങ്ങളുള്ള ഒരു ലീഡർഷിപ്പ് ടീമിന് അതു വായിക്കാനാകുന്നത് അതുകൊണ്ടാണ്.
ഇതാ വിരുദ്ധമായ കാഴ്ചപ്പാട്
ഒരു ആർഒഐ ശതമാനംകൊണ്ട് തുടങ്ങരുത്. ഒരു സോഫ്റ്റ്വെയർ ബിസിനസ് കേസിൽ നേതൃത്വം ഏറ്റവും കുറച്ചു വിശ്വസിക്കുന്ന ഭാഗം അതാണ്, കാരണം അതു വെണ്ടറിൽനിന്നു വന്നതാണെന്ന് അവർക്കറിയാം; ചർച്ചയെ അതു പ്രശ്നത്തിൽനിന്ന് സംഖ്യയ്ക്കു പിന്നിലെ അനുമാനങ്ങളിലേക്ക് മാറ്റുകയും ചെയ്യുന്നു. വിശ്വാസത്തിന്റെ പുറത്ത് സ്വീകരിക്കേണ്ട ഒരു വലിയ വരുമാനത്തെക്കാൾ എത്രയോ കൂടുതൽ ബോധ്യപ്പെടുത്തുന്നതാണ്, നേതൃത്വം ഇതിനകം വിശ്വസിക്കുന്ന ഒരു ചെലവിന്റെ മിതമായ കണക്ക്.
നിങ്ങൾക്ക് വേണ്ടതിലും കുറച്ചു ചോദിക്കുക. ഒരു വലിയ വാർഷിക കരാറിനെക്കാൾ അംഗീകരിക്കാൻ എളുപ്പമാണ് പൈലറ്റോടുകൂടിയ ഘട്ടംഘട്ടമായുള്ള പ്രതിബദ്ധത; നേതൃത്വം ഉത്തരം നൽകുന്ന ചോദ്യത്തെ അത് «ഇത് ഈ പണത്തിനു തക്ക മൂല്യമുള്ളതാണോ?» എന്നതിൽനിന്ന് «ഇത് തൊണ്ണൂറു ദിവസത്തിനു തക്ക മൂല്യമുള്ളതാണോ?» എന്നതിലേക്ക് മാറ്റുന്നു. പൈലറ്റ് ഫലിച്ചാൽ, ആദ്യത്തേത് ആകുമായിരുന്നതിനെക്കാൾ വളരെ എളുപ്പമാണ് രണ്ടാമത്തെ അംഗീകാരം.
മറഞ്ഞ ചെലവുകൾ നിങ്ങൾ തന്നെ ഉൾപ്പെടുത്തുക. ഒരു സംഘടനാ പ്ലാറ്റ്ഫോമിന്റെ ഏറ്റവും വലിയ ചെലവ് ലൈസൻസാകുന്നത് അപൂർവമാണ്. നേതൃത്വത്തിന്റെ സമയമാണ് അത്, പിന്നാലെ ഘടനയെയും റോളുകളെയും കുറിച്ചുള്ള ഇപ്പോഴത്തെ ഡാറ്റ തയ്യാറാക്കാനുള്ള ജോലിയും ആളുകൾ അതു യഥാർത്ഥത്തിൽ ഉപയോഗിക്കാൻ വേണ്ട മാറ്റവും. ഇവ ഒഴിവാക്കുന്ന ബിസിനസ് കേസുകൾ കൂടുതൽ ബോധ്യപ്പെടുത്തുന്നവയല്ല. നേതൃത്വം എന്തായാലും അവയെക്കുറിച്ച് ചിന്തിക്കും; ആ ഒഴിവാക്കൽ എഴുതിയയാളുടെ വിശ്വാസ്യതയാണ് കളയുന്നത്.
ഇത് എന്തുകൊണ്ട് ഫലിക്കുന്നു
തീരുമാന ഗവേഷണത്തിൽ കാരണങ്ങൾ നന്നായി രേഖപ്പെടുത്തിയിട്ടുണ്ട്. 1980-കളുടെ അവസാനം Samuelson-ഉം Zeckhauser-ഉം സ്റ്റാറ്റസ് ക്വോ ബയസ് വിവരിച്ചു: ഇപ്പോഴത്തെ അവസ്ഥ നിലനിർത്തുന്നതിനും മാറ്റുന്നതിനും ഇടയിൽ തിരഞ്ഞെടുക്കുമ്പോൾ, അർഹിക്കുന്നതിനെക്കാൾ കൂടുതൽ ആളുകൾ ഇപ്പോഴത്തെ അവസ്ഥയെ അനുകൂലിക്കുന്നു. അതിനാൽ ഒരു ബിസിനസ് കേസ് നിലവിലുള്ള അവസ്ഥയെ ഒരു നിഷ്പക്ഷ സ്ഥിരസ്ഥിതിയായല്ല, സ്വന്തം ചെലവുകളുള്ള ഒരു തിരഞ്ഞെടുപ്പായി ദൃശ്യമാക്കണം. ഒന്നും ചെയ്യാതിരിക്കുന്നതിന്റെ ചെലവ് എന്ന ഭാഗം ചെയ്യുന്നത് അതാണ്.
ഉള്ളടക്കത്തോടൊപ്പം അവതരണരീതിയും എന്തുകൊണ്ട് പ്രധാനമാണെന്ന് Kahneman-ന്റെയും Tversky-യുടെയും പ്രോസ്പെക്ട് തിയറി വിശദീകരിക്കുന്നു. തുല്യമായ നേട്ടങ്ങളെക്കാൾ വലുതായി നഷ്ടങ്ങൾ തോന്നുന്നു; അതിനാൽ നേതൃത്വം ഇതിനകം പണം നൽകിക്കൊണ്ടിരിക്കുന്ന ഒരു പ്രശ്നത്തിന്, അവർക്ക് ലഭിച്ചേക്കാവുന്ന ഒരു നേട്ടത്തെക്കാൾ ഭാരം കൂടുതലാണ്. Leading Change-ൽ John Kotter ഇതേ കാര്യം സംഘടനാ പദങ്ങളിൽ പറഞ്ഞു: ഏതു മാറ്റത്തിലെയും ആദ്യ ചുവട് അടിയന്തരതാബോധം സ്ഥാപിക്കലാണ്; ഒന്നുമില്ലായ്മയിൽനിന്ന് അടിയന്തരത സൃഷ്ടിക്കേണ്ട ബിസിനസ് കേസ് കയറ്റം കയറുകയാണ്.
ഒടുവിൽ, ഇതുപോലുള്ള പ്ലാറ്റ്ഫോമുകളിൽനിന്ന് മൂല്യം നേടുന്ന സ്ഥാപനങ്ങളിൽ ഞങ്ങൾ കാണുന്നതുമായി ഇതു ചേരുന്നു. മൂല്യം ഏതാണ്ട് ഒരിക്കലും സോഫ്റ്റ്വെയറിൽനിന്നു മാത്രം വരുന്നില്ല; തങ്ങൾക്കു വേണ്ട ഘടനയും ഉടമസ്ഥതയും അളവുകളും ഒടുവിൽ ഒരിടത്ത് ദൃശ്യമായതിനാൽ ഒരു ലീഡർഷിപ്പ് ടീം വ്യത്യസ്തമായി തീരുമാനിക്കുന്നതിൽനിന്നാണ് അതു വരുന്നത്. ആ ദൃശ്യതയ്ക്ക് പണം നൽകാൻ തക്ക മൂല്യമുണ്ടാക്കുന്ന പ്രശ്നങ്ങൾ തന്ത്ര നിർവഹണം എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു, തീരുമാന വ്യതിയാനം എന്നീ ഞങ്ങളുടെ ലേഖനങ്ങൾ വിവരിക്കുന്നു.
ഒരു പ്രായോഗിക ചെക്ക്ലിസ്റ്റ്
- നേതൃത്വത്തിന്റെ സ്വന്തം വാക്കുകളിൽ പ്രശ്നം കണ്ടെത്തുക: ഓഫ്സൈറ്റ് കുറിപ്പുകൾ, ബോർഡ് ചർച്ചകൾ, സിഇഒ ആവർത്തിച്ചുകൊണ്ടിരിക്കുന്ന പരാതി.
- പ്രശ്നത്തിന്റെ ഒരൊറ്റ സംഭവത്തിന്റെ ചെലവ് കണക്കാക്കുക, മിതമായി, ശ്രേണികളായി, എച്ച്ആർ പദങ്ങളിലല്ല ബിസിനസ് പദങ്ങളിൽ.
- എന്ത് ആര് വ്യത്യസ്തമായി തീരുമാനിക്കും എന്ന് ഒരു വാക്യത്തിൽ എഴുതുക. അതിനാകുന്നില്ലെങ്കിൽ നിർത്തി വാങ്ങൽ പുനഃപരിശോധിക്കുക.
- യഥാർത്ഥ പ്രശ്നത്തിൽ ഒരു പൈലറ്റ് രൂപകൽപ്പന ചെയ്യുക, സമയപരിധിയോടെ, തീരുമാനമെടുക്കുന്നവരെ ഉൾപ്പെടുത്തി, മുൻകൂട്ടി യോജിച്ച ഒരു അളവോടെ.
- പൂർണ ചെലവ് പട്ടികപ്പെടുത്തുക, നേതൃത്വത്തിന്റെ സമയം, ഡാറ്റ തയ്യാറാക്കൽ, കോൺഫിഗറേഷൻ, പരിശീലനം, മാറ്റത്തിനുള്ള പിന്തുണ എന്നിവ ഉൾപ്പെടെ.
- പൈലറ്റിന്റെ ഫലവുമായി ബന്ധിച്ച ഘട്ടംഘട്ടമായുള്ള പ്രതിബദ്ധത ആവശ്യപ്പെടുക, എങ്ങനെ നിർത്തുമെന്നതും ഉൾപ്പെടുത്തുക.
- അവതരിപ്പിക്കുംമുമ്പ് അനുയോജ്യത സത്യസന്ധമായി പരിശോധിക്കുക. Green Apple ആർക്കുവേണ്ടിയാണ് നിർമിച്ചത്, മറ്റു പ്ലാറ്റ്ഫോമുകളുമായി അത് എങ്ങനെ താരതമ്യം ചെയ്യുന്നു എന്നീ ഞങ്ങളുടെ വഴികാട്ടികൾ, ഞങ്ങളെ തിരഞ്ഞെടുക്കാൻ മാത്രമല്ല ഒഴിവാക്കാനും നിങ്ങളെ സഹായിക്കാൻ എഴുതിയവയാണ്.
സ്വയം ചോദിക്കുക
- ഈ വർഷം നമ്മുടെ നേതൃത്വം ഒന്നിലധികം തവണ പരാതിപ്പെട്ട സംഘടനാ പ്രശ്നം ഏതാണ്?
- ആ പ്രശ്നത്തിന്റെ കഴിഞ്ഞ സംഭവത്തിന് ഏകദേശം എന്തു ചെലവു വന്നു, സിഎഫ്ഒ തിരിച്ചറിയുന്ന പദങ്ങളിൽ?
- ഈ പ്ലാറ്റ്ഫോം ഉണ്ടായിരുന്നെങ്കിൽ ആര് ഏതു തീരുമാനമാണ് വ്യത്യസ്തമായി എടുക്കുക, നാം അവരോട് ചോദിച്ചിട്ടുണ്ടോ?
- തൊണ്ണൂറു ദിവസത്തെ പൈലറ്റിൽനിന്നുള്ള ഏതു ഫലമാണ് വിപുലീകരിക്കാൻ നമ്മെ ബോധ്യപ്പെടുത്തുക, ഏതു ഫലമാണ് നിർത്താൻ ബോധ്യപ്പെടുത്തുക?
- നാം ഇതു വാങ്ങുന്നത് ഒരു പ്രശ്നം പരിഹരിക്കാനാണോ, അതോ നമ്മെപ്പോലുള്ള മറ്റു കമ്പനികൾക്ക് ഇതുള്ളതുകൊണ്ടാണോ?
സാരാംശം
മുതിർന്ന നേതൃത്വം സോഫ്റ്റ്വെയറിന് ഫണ്ട് നൽകുന്നില്ല. ഇതിനകം പണം നൽകിക്കൊണ്ടിരിക്കുന്ന ഒരു പ്രശ്നത്തിന്റെ അവസാനത്തിനാണ് അത് ഫണ്ട് നൽകുന്നത്. നേതൃത്വത്തിന്റെ സ്വന്തം വാക്കുകളിൽ ആ പ്രശ്നത്തിന് പേരിടുക, അതിന്റെ ചെലവ് സത്യസന്ധമായി കണക്കാക്കുക, ആര് വ്യത്യസ്തമായി തീരുമാനിക്കുമെന്ന് പറയുക, യോജിച്ച ഒരു ഫലവുമായി അളക്കുന്ന ചെറിയ പൈലറ്റിലൂടെ അതു തെളിയിക്കുക, ഘട്ടംഘട്ടമായുള്ള പ്രതിബദ്ധത ആവശ്യപ്പെടുക. പ്ലാറ്റ്ഫോം മാറ്റാൻ പോകുന്ന തീരുമാനത്തിന് പേരിടാൻ നിങ്ങൾക്കാവില്ലെങ്കിൽ, ഏറ്റവും വിശ്വസനീയമായ ബിസിനസ് കേസ് നിങ്ങൾ സമർപ്പിക്കാത്തതാണ്.
പതിവ് ചോദ്യങ്ങൾ
- ഒരു ടാലന്റ് മാനേജ്മെന്റ് അല്ലെങ്കിൽ OD പ്ലാറ്റ്ഫോമിനുള്ള ബിസിനസ് കേസ് എങ്ങനെ എഴുതാം?
- നിലച്ചുപോയ തന്ത്രപരമായ സംരംഭങ്ങളോ ഒരു നിർണായക ടീമിലെ കൊഴിഞ്ഞുപോക്കോ പോലെ, നേതൃത്വം ഇതിനകം തിരിച്ചറിയുന്ന, ആവർത്തിക്കുന്ന, ചെലവേറിയ ഒരു സംഘടനാ പ്രശ്നത്തിൽ അതിനെ നങ്കൂരമിടുക. ഒന്നും മാറിയില്ലെങ്കിൽ ആ പ്രശ്നത്തിന് എന്തു ചെലവു വരുമെന്ന് കണക്കാക്കുക, ഏതു തീരുമാനമോ പെരുമാറ്റമോ വ്യത്യസ്തമാകുമെന്നും ആര് അതു മാറ്റുമെന്നും വിവരിക്കുക, മുൻകൂട്ടി യോജിച്ച ഒരു അളവോടെ ഒരു ചെറിയ പൈലറ്റ് നിർദേശിക്കുക, പൈലറ്റിന്റെ ഫലവുമായി ബന്ധിച്ച ഘട്ടംഘട്ടമായുള്ള ബജറ്റ് ആവശ്യപ്പെടുക.
- സംഘടനാ വികസനത്തിന്റെ ആർഒഐ എങ്ങനെ കണക്കാക്കാം?
- സത്യസന്ധമായി, ശ്രേണികളായി. നിക്ഷേപം ലക്ഷ്യമിടുന്ന പ്രത്യേക പ്രശ്നത്തിന്റെ ചെലവ്, നേതൃത്വം ഇതിനകം ഉപയോഗിക്കുന്ന പദങ്ങളിൽ കണക്കാക്കുക: വൈകിയ വരുമാനം, നഷ്ടമായ കരാറുകൾ, പകരം ആളെ കണ്ടെത്താനുള്ള ചെലവ്, മാനേജ്മെന്റിന്റെ സമയം. പൊതുവായ ഉൽപ്പാദനക്ഷമതാ ഗുണകങ്ങൾ ഒഴിവാക്കുക; മിക്ക ബിസിനസ് കേസുകളിലെയും ഏറ്റവും വിശ്വാസ്യത കുറഞ്ഞ ഭാഗം അവയാണ്. നേതൃത്വം വിശ്വസിക്കാത്ത ഒരു വലിയ സംഖ്യയെക്കാൾ മൂല്യമുണ്ട്, അവർ ഇതിനകം വിശ്വസിക്കുന്ന ഒരു ചെലവിന്റെ മിതമായ കണക്കിന്.
- സോഫ്റ്റ്വെയറിനുള്ള ഒരു ബിസിനസ് കേസിൽ സിഎഫ്ഒമാർ എന്താണ് കാണാൻ ആഗ്രഹിക്കുന്നത്?
- പേരിട്ട ഒരു പ്രശ്നം, അതിന്റെ ചെലവിന്റെ വിശ്വസനീയമായ കണക്ക്, എന്തു മാറുമെന്നും അതിന് ആര് ഉത്തരവാദിയെന്നുമുള്ള വ്യക്തമായ വിവരണം, ആന്തരിക സമയം ഉൾപ്പെടെയുള്ള പൂർണ ചെലവ്, ഫലിച്ചില്ലെങ്കിൽ നിർത്താനുള്ള ഒരു വഴി. ഒരു പൈലറ്റും യോജിച്ച അളവുമുള്ള ഘട്ടംഘട്ടമായുള്ള പ്രതിബദ്ധത ഒരു സിഎഫ്ഒയുടെ മിക്ക എതിർപ്പുകൾക്കും അവ ഉന്നയിക്കപ്പെടുന്നതിനു മുമ്പുതന്നെ ഉത്തരം നൽകുന്നു.
- ഒരു ടാലന്റ് അല്ലെങ്കിൽ OD പ്ലാറ്റ്ഫോം വാങ്ങുന്നതിനു മുമ്പ് പൈലറ്റ് ചെയ്യണോ?
- വേണം, അതും ഒരു ഡെമോ സാഹചര്യത്തിലല്ല, ഒരു യഥാർത്ഥ പ്രശ്നത്തിൽ. പൈലറ്റിന് സമയപരിധി നിശ്ചയിക്കുക, പ്ലാറ്റ്ഫോം ആരുടെ തീരുമാനങ്ങളാണോ മാറ്റാൻ ഉദ്ദേശിക്കുന്നത് അവരെ ഉൾപ്പെടുത്തുക, അതു വിപുലീകരിക്കുന്നതിനെ ഏതു ഫലം ന്യായീകരിക്കുമെന്ന് തുടങ്ങുംമുമ്പ് യോജിക്കുക. യോജിച്ച അളവില്ലാത്ത പൈലറ്റ് അഭിപ്രായങ്ങളാണ് ഉണ്ടാക്കുന്നത്, തെളിവല്ല.
- ലൈസൻസിനു പുറമേ ബിസിനസ് കേസിൽ എന്തൊക്കെ ചെലവുകൾ ഉൾപ്പെടുത്തണം?
- നേതൃത്വത്തിന്റെയും മാനേജ്മെന്റിന്റെയും സമയം, സാധാരണ ഏറ്റവും വലിയ ചെലവ് അതാണ്; ഇപ്പോഴത്തെ ഘടനയും റോളുകളും പോലുള്ള ഡാറ്റ തയ്യാറാക്കാനുള്ള പ്രയത്നം; കോൺഫിഗറേഷനും പരിശീലനവും; ആളുകൾ അത് ഉപയോഗിക്കാൻ ആവശ്യമായ മാറ്റ പ്രവർത്തനം. ഇവ ഉൾപ്പെടുത്തുന്നത് കേസിനെ കൂടുതൽ വിശ്വസനീയമാക്കുന്നു, കാരണം നേതൃത്വം എന്തായാലും അവയെക്കുറിച്ച് ചിന്തിക്കും.
അനുബന്ധ ലേഖനങ്ങൾ
ഓർഗനൈസേഷൻ ഡെവലപ്മെന്റ്ബോർഡിനായുള്ള സംസ്കാര മെട്രിക്സ്: കാലാവസ്ഥാ റിപ്പോർട്ട് നിർത്തുക6 മിനിറ്റ് വായന
ഓർഗനൈസേഷൻ ഡെവലപ്മെന്റ്സർക്കാർ ഘടനയും സ്വകാര്യ മേഖലാ ഘടനയും: വ്യത്യസ്ത ഉടമകൾ, വ്യത്യസ്ത രൂപകൽപ്പനാ നിയമങ്ങൾ5 മിനിറ്റ് വായന
ഓർഗനൈസേഷൻ ഡെവലപ്മെന്റ്നൂറു പേർ കടന്നാലും ഫ്ലാറ്റ് ഘടന: ശ്രേണി ഇതിനകം നിലവിലുണ്ട്, എഴുതപ്പെട്ടിട്ടില്ലെന്നു മാത്രം5 മിനിറ്റ് വായന
ഓർഗനൈസേഷൻ ഡെവലപ്മെന്റ്ഹോൾഡിംഗ് കമ്പനി ഘടന: വരയ്ക്കുംമുമ്പ് കേന്ദ്രം എന്തിനുള്ളതാണെന്ന് തീരുമാനിക്കുക6 മിനിറ്റ് വായന