Organizācija, kas paslēpta programmatūrā

Ievads

Saruna reti sākas ar organizācijas dizainu.

Parasti tā sākas ar programmatūru.

Vadības komanda secina, ka kaut kas vairs nestrādā tā, kā vajadzētu. Projekti kustas pārāk lēni. Klienti gaida ilgāk, nekā plānots. Darbinieki sūdzas par atkārtotiem uzdevumiem. Jaunajiem kolēģiem vajadzīgi mēneši, līdz viņi kļūst pilnībā produktīvi. Atskaites patērē arvien vairāk laika, bet lēmumu pieņemšana, šķiet, prasa vairāk sapulču nekā pašu lēmumu.

Galu galā uzmanība pievēršas tehnoloģijām. ERP sistēma tiek raksturota kā smagnēja. CRM tiek kritizēts kā neintuitīvs. Palīdzības dienesta sistēmā kļūst grūti orientēties. Kāds neizbēgami secina, ka organizācija ir izaugusi ārpus savām sistēmām un ka jauna platforma atjaunos efektivitāti.

Tas ir saprotams secinājums.

Mūsdienu organizācijas paļaujas uz programmatūru gandrīz visās nozīmīgajās darbībās. Finanses, operācijas, klientu apkalpošana, iepirkumi, loģistika un iekšējā komunikācija notiek caur digitālām sistēmām. Kad darbs kļūst grūtāks, programmatūra ir visredzamākā pieredzes daļa. Tā ir saskarne, ar kuru cilvēki mijiedarbojas katru dienu, tāpēc tā dabiski kļūst par neapmierinātības adresātu.

Tomēr redzamību nevajadzētu jaukt ar cēlonību.

Dažādās nozarēs atkārtojas pārsteidzoši līdzīgi stāsti. Divas organizācijas ievieš vienu un to pašu uzņēmuma platformu, bieži ar līdzīgiem budžetiem, ieviešanas partneriem un tehniskajām iespējām. Viena vēlāk apraksta projektu kā transformējošu. Otra pēc dažiem gadiem klusi sāk plānot platformas nomaiņu. Programmatūra nav mainījusies. Funkcionalitāte lielā mērā ir identiska. Pat pamatā esošā tehnoloģija var būt tā pati.

Atšķiras organizācija, kuru šai programmatūrai ir lūgts atspoguļot.

Uzņēmumu programmatūra reti izgudro veidu, kā organizācija strādā. Tā to pieraksta, formalizē un, iespējams, vēl svarīgāk, padara redzamu. Katra darba plūsma atspoguļo lēmumu, ko kāds reiz uzskatīja par saprātīgu. Katra apstiprinājumu ķēde atspoguļo pieņēmumu par risku. Katrs obligātais lauks atspoguļo informāciju, ko kāds uzskatīja par būtisku. Laika gaitā šie atsevišķie lēmumi uzkrājas, līdz programmatūra sāk līdzināties kaut kam daudz atklājošākam par digitālu rīku kopumu.

Tā kļūst par pārsteidzoši precīzu pašas organizācijas aprakstu.

Nevis tās organizācijas, kas redzama stratēģijas prezentācijās vai procesu shēmās, bet tās, ko darbinieki piedzīvo katru dienu. Tās, kuru veidojuši gadiem krāti izņēmumi, kompromisi, vēsturiski lēmumi un labu nodomu vadīti mēģinājumi atrisināt vakardienas problēmas. Šajā nozīmē uzņēmumu programmatūra izdara kaut ko tādu, ko organizācijas reti sagaida.

Tā pasaka patiesību.

Programmatūra reti izgudro sarežģītību

Šī atšķirība ir svarīga, jo no programmatūras bieži tiek gaidīts, ka tā atrisinās problēmas, kas sākotnēji nemaz nebija tehnoloģiskas.

Kad organizācijas gatavojas jaunai ieviešanai, sarunas parasti grozās ap funkcionalitāti. Kuri moduļi ir vajadzīgi? Kuras integrācijas trūkst? Kurām atskaitēm jābūt pieejamām pirmajā dienā? Tie ir saprātīgi jautājumi, bet tie reti pieskaras fundamentālākam jautājumam: ko tieši šai programmatūrai tiek lūgts atspoguļot?

Katra organizācija nes sev līdzi savu operacionālo vēsturi. Lēmumi, kas reiz atrisināja īstas problēmas, turpina veidot darba veikšanas veidu arī pēc daudziem gadiem. Papildu apstiprinājums, kas ieviests pēc dārgas kļūdas, reti tiek noņemts, kad sākotnējais risks ir pagājis. Pagaidu risinājums, kas izstrādāts lielam klientam, klusi kļūst par standarta praksi. Nodaļas izveido paralēlus procesus, jo vairs neuzticas informācijai, kas rodas citur. Katrs pielāgojums atsevišķi šķiet saprātīgs. Kopā tie sāk pārdefinēt pašu organizāciju.

Programmatūra neierodas organizācijas vakuumā. Ilgi pirms pirmās konfigurācijas darbnīcas bizness jau ir izveidojis tūkstošiem noteikumu, pieņēmumu un izņēmumu, kas ietekmē to, kā darbs pārvietojas no viena cilvēka pie otra. Ieviešanas process vienkārši piespiež šos lēmumus kļūt redzamiem. Jautājumi, kas iepriekš varēja palikt neatbildēti, pēkšņi prasa precīzas atbildes. Kurš apstiprina šo pieprasījumu? Kādos apstākļos procesu drīkst apiet? Kura nodaļa kļūst atbildīga, ja kaut kas noiet greizi? Kura informācija vienmēr jāfiksē, un kura vienkārši būtu ērta?

Šīs sarunas bieži šķiet tehniskas, jo tās notiek programmatūras projekta laikā. Patiesībā tās ir sarunas par organizācijas dizainu.

Tieši tāpēc ieviešanas darbnīcas bieži kļūst negaidīti sarežģītas. Pati programmatūra reti ir lielākais izaicinājums. Lielāks izaicinājums ir tas, ka dažādas organizācijas daļas bieži dzīvo ar atšķirīgiem pieņēmumiem par to, kā bizness patiesībā darbojas. Tas, ko viena nodaļa uzskata par būtisku kontroli, citai šķiet nevajadzīga birokrātija. Tas, ko viens vadītājs sauc par elastību, cits atpazīst kā nekonsekvenci. Programmatūra vienkārši prasa vienu atbildi tur, kur organizācija klusi ir dzīvojusi ar vairākām.

Tajā brīdī tehnoloģija sāk spēlēt negaidītu lomu. Tā vairs nedefinē organizāciju.

Tā sāk to atklāt.

Kāpēc organizācijas vaino tehnoloģiju

Ir vēl viens iemesls, kāpēc programmatūra tik bieži kļūst par organizācijas neapmierinātības centru. Atšķirībā no kultūras, vadības vai lēmumu pieņemšanas tehnoloģija ir taustāma. To var nomainīt, atjaunināt vai pārprojektēt. Tā rada mierinošu iespaidu, ka sarežģītību var atrisināt ar iepirkumu, nevis refleksiju.

Tāpēc organizācijas reizēm nonāk pazīstamā ciklā. Kad esošā platforma sāk šķist ierobežojoša, uzmanība pāriet uz jaunas platformas izvēli. Tiek apkopotas prasības, vērtēti piegādātāji un nozīmēti ieviešanas partneri. Gaidas reti tiek izteiktas tieši, tomēr tās gandrīz vienmēr ir klātesošas: nākamā sistēma būs vienkāršāka.

Dažreiz tā arī ir.

Tomēr biežāk jaunā platforma pārmanto tos pašus organizācijas pieņēmumus, ko iepriekšējā.

Apstiprinājumu ķēdes tiek izveidotas no jauna, jo neviens nejūtas pietiekami drošs tās apšaubīt. Vēsturiskie izņēmumi tiek saglabāti, jo tie kādreiz kalpoja svarīgam klientam. Atskaites turpina augt, jo informācijas noņemšana šķiet riskantāka nekā tās ievākšana par daudz. Programmatūra var izskatīties pilnīgi citādi, bet tās pamatā esošā loģika paliek pārsteidzoši pazīstama.

Pēc dažiem gadiem darbinieki sāk izteikt tās pašas neapmierinātības, kas pavadīja iepriekšējo ieviešanu.

Saskarne ir mainījusies.

Organizācija nav.

Tehnoloģija izpilda lēmumus

Tas nenozīmē, ka programmatūra nav svarīga. Gluži pretēji, labi projektētas uzņēmumu sistēmas var būtiski uzlabot konsekvenci, pārskatāmību un operacionālo efektivitāti. Slikta programmatūra neapšaubāmi pastāv, un slikts dizains pats var radīt nevajadzīgu berzi.

Tomēr programmatūra reti spēj vienkāršot lēmumus, kurus pati organizācija nekad nav vienkāršojusi.

Gaidīt, ka tehnoloģija atrisinās organizācijas neskaidrību, nozīmē uzlikt tai neiespējamu atbildību. Programmatūra nevar noteikt, kam jābūt procesa īpašniekam, ja vadība par to nekad nav vienojusies. Tā nevar noņemt nevajadzīgus apstiprinājumus, ja organizācija nevēlas pārskatīt, kāpēc tie pastāv. Tā arī nevar radīt skaidrību tur, kur dažādas nodaļas turpina strādāt pēc pretrunīgiem pieņēmumiem.

Tehnoloģija ir ārkārtīgi laba lēmumu izpildē.

Tā ir daudz mazāk spējīga tos pieņemt.

Iespējams, tieši tas izskaidro, kāpēc veiksmīgākie ieviešanas projekti bieži šķiet pārsteidzoši mierīgi. Tos ne vienmēr īsteno organizācijas ar lielākajiem budžetiem vai sarežģītākajām tehnoloģijām. Tos īsteno organizācijas, kas grūtāko darbu ir paveikušas pirms ieviešana sākas. Tās ir apšaubījušas ilgstoši pastāvējušus procesus, izaicinājušas mantotus pieņēmumus un pieņēmušas, ka vienkāršošana ir tikpat lielā mērā organizācijas lēmums, cik tehnisks lēmums.

Šādās organizācijās programmatūra nekļūst par risinājumu.

Tā kļūst par skaidrākas domāšanas sekām.

Organizācijas rentgens

Iespējams, šis ir noderīgāks veids, kā domāt par digitālo transformāciju.

Gadu desmitiem organizācijas ir uztvērušas programmatūru kā ieguldījumu kapacitātē. Jaunas sistēmas sola lielāku efektivitāti, labāku pārskatāmību un kvalitatīvāku lēmumu pieņemšanu. Šie solījumi bieži tiek īstenoti. Tomēr to panākumi ir atkarīgi no kaut kā daudz mazāk tehnoloģiska nekā ieviešanas plāni vai funkciju saraksti.

Tie ir atkarīgi no tā, vai organizācija ir gatava saskarties ar realitāti, ko programmatūra tūlīt atklās.

Uzņēmumu sistēmām piemīt neparasta īpašība. Tās ļoti slikti slēpj nekonsekvenci. Procesi, kas iepriekš balstījās neformālās sarunās, pēkšņi prasa skaidrus noteikumus. Atbildības, kas agrāk tika pieņemtas kā pašsaprotamas, ir jāpiešķir. Izņēmumi, kas gadiem klusi krājās, kļūst redzami ikvienam, kurš pieskaras sistēmai. Tas, kas iepriekš pastāvēja kā organizācijas ieradums, pārtop operacionālā loģikā.

Tieši tāpēc programmatūras ieviešanas var justies negaidīti neērtas. Tās atklāj ne tikai tehniskus ierobežojumus, bet arī organizatoriskus. Tās parāda, kur īpašumtiesības nav skaidras, kur procesi izauguši ap vēsturiskiem kompromisiem un kur sarežģītība klusi ir pieņemta kā normāla biznesa cena.

Šādā skatījumā uzņēmumu programmatūra sāk līdzināties kam vērtīgākam par infrastruktūru.

Tā kļūst par organizācijas rentgenu.

Lūzums jau bija tur

Rentgens nerada lūzumu, ko tas atklāj. Tas vienkārši padara redzamu to, kas jau bija tur. Attēls var būt neērts, bet tā vērtība ir tieši tā godīgumā. Bez tā ārstēšana kļūst par minējumu.

Tas pats attiecas uz organizācijām.

Kad programmatūra atklāj dublētus apstiprinājumus, sadrumstalotas atbildības vai arvien augošu izņēmumu ainavu, ir vilinoši secināt, ka pati platforma ir izgāzusies. Tomēr daudzos gadījumos tā ir izdarījusi tieši to, kam tā bija paredzēta. Tā ir uzticami pārtulkojusi organizāciju sistēmā, kas vairs nespēj noslēpt tās pretrunas.

Šāds skatījums maina sarunu.

Tā vietā, lai jautātu, vai programmatūra ir pietiekami elastīga, lai pielāgotos katram vēsturiskajam izņēmumam, vadītāji var jautāt, vai katrs izņēmums joprojām ir pelnījis pastāvēt. Tā vietā, lai meklētu jaunu funkcionalitāti pieaugošas sarežģītības pārvaldībai, viņi vispirms var jautāt, kāpēc šī sarežģītība vispār radās. Mērķis pārvietojas no sistēmu būvēšanas, kas spēj atbalstīt organizācijas neskaidrību, uz organizāciju veidošanu, kurām vajag mazāk neskaidrības, lai efektīvi strādātu.

Tas nav tehnoloģisks izaicinājums.

Tas nav programmatūras izaicinājums.

Tas ir vadības izaicinājums.

Noslēgums

Tehnoloģija var paātrināt skaidrību, bet tā nevar to radīt. Tā var nostiprināt labus organizācijas lēmumus, bet nevar tos aizstāt. Pirms programmatūra kļūst par konkurences priekšrocību, skaidrībai jākļūst par tādu.

Iespējams, tā ir klusā mācība, kas paslēpta tik daudzos digitālās transformācijas projektos. Programmatūra nekad nemēģināja pateikt organizācijai, kā tai jāstrādā.

Tā vienkārši parādīja organizācijai, kā tā jau strādāja.