Ang Business Case para sa OD at Talent Platform: Ibenta ang Desisyon, Hindi ang Software

Karamihan sa mga business case para sa organizational development at talent software ay natatalo sa unang sampung minuto ng pulong, at sa iisang dahilan. Inilalarawan nila ang software: mga feature, module, integration, oras na natipid kada manager. Ang naririnig ng senior leadership ay isang bagong gastos na may mga pakinabang na parang malabo at huli pang dumarating. Kabaligtaran ang pagkakabuo ng mga kasong naaaprubahan. Nagsisimula sila sa isang magastos at paulit-ulit na problema sa organisasyon na nararamdaman na ng pamunuan, ipinapakita kung magkano ang gastos ng problemang iyon, at inihaharap ang platform bilang pinakamura at kapani-paniwalang paraan para tumigil ang pagbabayad para dito. At humihingi sila ng pilot bago humingi ng budget.

Naranasan na namin ang magkabilang panig ng usapang ito, sa pagtulong sa mga lider ng HR at strategy na bumuo ng mga kaso at sa pag-upo sa harap ng mga leadership team na nagpapasya sa mga ito. May isang hindi kumportableng payo kaming ibinibigay sa bawat pagkakataon: kung hindi ninyo mapangalanan ang desisyong babaguhin ng platform, hindi ninyo ito dapat bilhin. Kasama riyan ang pagbili ng sa amin.

"Sinabi mo sa akin kung ano ang ginagawa nito, hindi kung ano ang nagbabago"

Ang HR director ng isang kumpanya sa Saudi Arabia na may humigit-kumulang tatlong daang empleyado ay gumugol ng ilang linggo sa paghahanda ng business case para sa isang talent at organizational development platform. Umabot ito sa tatlumpung slide: paghahambing ng mga feature ng apat na vendor, tantiyang oras na matitipid sa performance reviews at pag-uulat, at kalkulasyon ng return on investment na binuo mula sa mga numero ng vendor.

Tinanggihan ito ng chief financial officer sa loob ng mga sampung minuto. Ang tumatak sa HR director ay ang dahilan: "Sinabi mo sa akin kung ano ang ginagawa nito. Hindi mo sinabi kung ano ang nagbabago, o sino ang nagbabago nito."

Isang slide lang ang ikalawang pagtatangka. Sa leadership offsite ilang buwan bago noon, nagreklamo ang CEO na natigil ang tatlo sa mga estratehikong inisyatiba ng taon, at walang makapagsabi kung sino ang may-ari ng mga ito. Pinangalanan ng bagong kaso ang problemang iyon, tinantiya ang naantalang kita mula sa isa lang sa tatlong inisyatiba, nagmungkahi ng siyamnapung-araw na pilot kung saan gagamitin ng leadership team ang platform para magtalaga ng pagmamay-ari at subaybayan ang tatlong inisyatibang iyon, at humingi ng pondo kung maaabot lamang ng pilot ang sukatang napagkasunduan nang maaga. Naaprubahan ito sa parehong pulong.

Ang One-Decision Business Case

Limang bahagi ang istruktura sa likod ng ikalawang pagtatangka, at gumagana ito para sa halos anumang pamumuhunan sa organisasyon, hindi lang sa software.

1. Ang problema. Isang pinangalanan, paulit-ulit at magastos na problema sa organisasyon na naramdaman na ng pamunuan, mas mabuti kung sa sarili nilang mga salita. Mga natigil na inisyatiba, malabong decision rights, pinagsisisihang pag-alis ng mga tao sa isang kritikal na koponan, isang restructuring na hindi lumapag. Kung hindi pa naniniwala ang pamunuan na umiiral ang problema, walang business case na makakukumbinsi sa kanila; doon muna magsimula.
2. Ang gastos ng walang ginagawa. Isang tantiya, sa mga saklaw, ng gastos ng problema kung magpapatuloy ito, na ipinahayag sa mga terminong ginagamit na ng pamunuan: naantalang kita, nawalang kontrata, gastos sa pagpapalit ng tao, oras ng management na nagugugol sa mga escalation. Mas mabuti ang konserbatibo at kapani-paniwala kaysa sa malaki at pinagtatalunan.
3. Ang pagbabago. Aling desisyon o ugali ang magiging iba, at sino ang gagawa nito nang iba. Ito ang bahaging iniiwan ng karamihan sa mga kaso, at ito ang bahaging hinihingi ng CFO sa kuwento. Walang binabago ang software nang mag-isa; ang mga taong gumagamit nito para magpasya nang iba ang nagbabago.
4. Ang patunay. Isang maikli at may takdang oras na pilot sa tunay na problema, kasama ang mga taong ang mga desisyon ang dapat magbago, at sukatang napagkasunduan bago ito magsimula.
5. Ang hiling. Isang hati-hating pangako na nakatali sa resulta ng pilot, na nakasaad ang buong gastos, kasama ang panloob na oras, at malinaw na paraan para huminto kung hindi ito gumana.

Ang kasong binuo sa ganitong paraan ay kadalasang mas maikli sa isang pahina. Hindi iyon kahinaan; iyon ang nagpapabasa rito sa isang leadership team na may apatnapu pang desisyong gagawin sa buwang iyon.

Narito ang salungat na pananaw

Huwag magsimula sa porsyento ng ROI. Ito ang bahagi ng business case para sa software na pinakahindi pinagkakatiwalaan ng pamunuan, dahil alam nilang galing ito sa vendor, at inililipat nito ang talakayan sa mga palagay sa likod ng numero sa halip na sa problema. Mas nakahihikayat ang katamtamang tantiya ng gastos na pinaniniwalaan na ng pamunuan kaysa sa malaking return na kailangan nilang tanggapin nang walang patunay.

Humingi ng mas kaunti kaysa sa kailangan ninyo. Mas madaling aprubahan ang hati-hating pangako na may pilot kaysa sa malaking taunang kontrata, at binabago nito ang tanong na sinasagot ng pamunuan mula sa "sulit ba ito sa pera?" tungo sa "sulit ba ito sa siyamnapung araw?" Kung gagana ang pilot, mas madali ang ikalawang aprubasyon kaysa sana sa una.

Kayo na mismo ang maglagay ng mga nakatagong gastos. Bihirang ang lisensya ang pinakamalaking gastos ng isang organizational platform. Ang oras ng pamunuan ang pinakamalaki, kasunod ang trabaho ng paghahanda ng kasalukuyang data tungkol sa istruktura at mga tungkulin at ang pagbabagong kailangan para talagang gamitin ito ng mga tao. Hindi mas nakahihikayat ang mga business case na nag-iiwan sa mga ito. Naiisip din naman ng pamunuan ang mga ito, at nababawasan ng pagkukulang ang kredibilidad ng may-akda.

Bakit ito gumagana

Mahusay na nakadokumento ang mga dahilan sa pananaliksik sa pagpapasya. Inilarawan nina Samuelson at Zeckhauser ang status quo bias noong huling bahagi ng dekada 1980: kapag pumipili ang mga tao sa pagitan ng pagpapanatili ng kasalukuyang kalagayan at pagbabago nito, mas pinapaboran nila ang kasalukuyang kalagayan kaysa sa nararapat batay sa merito. Kaya kailangang gawing nakikita ng isang business case ang status quo bilang pagpiling may sariling mga gastos, hindi bilang neutral na default. Iyan ang ginagawa ng seksyon tungkol sa gastos ng walang ginagawa.

Ipinaliliwanag ng prospect theory nina Kahneman at Tversky kung bakit mahalaga ang framing gayundin ang nilalaman. Mas mabigat ang pakiramdam ng mga pagkalugi kaysa sa katumbas na mga pakinabang, kaya mas tinitimbang ang problemang binabayaran na ng pamunuan kaysa sa pakinabang na maaari nilang makuha. Ginawa ni John Kotter ang parehong punto sa mga terminong pang-organisasyon sa Leading Change: ang unang hakbang sa anumang pagbabago ay ang pagtatatag ng pakiramdam ng pagkaapurahan, at ang business case na kailangang lumikha ng pagkaapurahan mula sa wala ay paahon ang laban.

Panghuli, tugma ito sa nakikita namin sa mga organisasyong nakakakuha ng halaga mula sa ganitong mga platform. Halos hindi kailanman nagmumula ang halaga sa software lamang; nagmumula ito sa isang leadership team na nagpapasya nang iba, dahil sa wakas ay nakikita na sa iisang lugar ang istruktura, pagmamay-ari at mga sukatang kailangan nila. Inilalarawan ng aming mga artikulo tungkol sa kung bakit nabibigo ang strategy execution at sa decision drift ang mga problemang nagpapasulit sa pagbabayad para sa ganoong linaw.

Isang praktikal na checklist

• Hanapin ang problema sa sariling mga salita ng pamunuan: mga tala sa offsite, mga talakayan ng board, ang reklamong paulit-ulit na sinasabi ng CEO.
• Tantiyahin ang gastos ng isang pangyayari ng problema, nang konserbatibo at sa mga saklaw, sa mga terminong pang-negosyo sa halip na pang-HR.
• Sumulat ng isang pangungusap tungkol sa kung ano ang pagpapasyahan nang iba at nino. Kung hindi ninyo magawa, huminto at pag-isipang muli ang pagbili.
• Magdisenyo ng pilot sa tunay na problema, may takdang oras, kasama ang mga nagpapasya at may sukatang napagkasunduan nang maaga.
• Ilista ang buong gastos, kasama ang oras ng pamunuan, paghahanda ng data, configuration, training at suporta sa pagbabago.
• Humingi ng hati-hating pangako na nakatali sa resulta ng pilot, at isama kung paano kayo hihinto.
• Tapat na suriin ang pagiging akma bago mag-pitch. Isinulat ang aming mga gabay sa para kanino ginawa ang Green Apple at sa paghahambing nito sa ibang mga platform para matulungan kayong ekisan kami gayundin ang isama kami.

Tanungin ang sarili

• Aling problema sa organisasyon ang higit sa isang beses nang inireklamo ng aming pamunuan ngayong taon?
• Magkano, humigit-kumulang, ang ginastos namin sa huling pangyayari ng problemang iyon, sa mga terminong makikilala ng CFO?
• Sino ang magpapasya nang iba sa aling desisyon kung umiiral ang platform na ito, at natanong na ba namin sila?
• Anong resulta mula sa siyamnapung-araw na pilot ang makakukumbinsi sa aming palawakin ito, at anong resulta ang makakukumbinsi sa aming huminto?
• Binibili ba namin ito para lutasin ang isang problema, o dahil may ganito ang ibang kumpanyang katulad namin?

Ang pangunahing aral

Hindi nagpopondo ng software ang senior leadership. Pinopondohan nito ang pagtatapos ng isang problemang binabayaran na nito. Pangalanan ang problemang iyon sa sariling mga salita ng pamunuan, tantiyahin nang tapat ang gastos nito, sabihin kung sino ang magpapasya nang iba, patunayan ito sa pamamagitan ng maikling pilot na sinusukat laban sa napagkasunduang resulta, at humingi ng hati-hating pangako. Kung hindi ninyo mapangalanan ang desisyong babaguhin ng platform, ang pinakakapani-paniwalang business case ay ang hindi ninyo isusumite.