Avval tartib, keyin dastur: tartibsiz jarayonni avtomatlashtirish xatolari

Nega xorijiy mijozlarning hisoblari burchakdagi stolga yuboriladi? Hammer 1990 yildagi maqolasida shu savolga javob beradi: 20 yil oldin Meri fransuz tilini bilardi va aynan shu stolda oʻtirardi. Meri allaqachon ketgan, kompaniya Fransiya bilan ishlamaydi, lekin xorijiy hisoblar hamon oʻsha stolga boradi. Bu tartibni dasturga solsangiz, burchakdagi stol dastur ichida abadiy qoladi.

«Avval tartib, keyin dastur» shiori aynan shu xavfdan ogohlantiradi. Lekin uning ichida ikki savol yashiringan: «tartib» nimani anglatadi va dastur eski tartibni qanchalik saqlab qoladi? Tizimlashtirish bilan avtomatlashtirish orasidagi farq alohida mavzu, bu yerda esa gap amaliy mezon va odatiy xatolar haqida, yaʼni dasturga topshirishdan oldin nimani tekshirish kerakligi haqida.

Eski qoida dasturga qanday joylashadi

Eski qoida dasturga kirgach, uni olib tashlash qiyinlashadi. Hammerning kuzatuvi aniq: jarayonlarning koʻpi kompyuter va aloqa vositalaridan oldin paydo boʻlgan va axborot tanqisligining oʻrnini toʻldirishga moslangan, yaʼni nusxalar, tasdiqlar va takroriy tekshiruvlar shundan kelib chiqqan. Bugun axborot yetarli, lekin shu moslamalar avtomatlashtirilgan tizimlar ichiga chuqur oʻrnashib qolgan. Fordda ham shunday boʻlgan: «hisob-faktura kelganda toʻlaymiz» qoidasi hech qayerda yozilmagan, ammo butun jarayonni aynan u belgilab turgan.

Misol gipotetik, mantiq esa Hammerniki. Aytaylik, kompaniyada har bir hisob-fakturaga uch imzo kerak, chunki oʻn yil oldin bitta xato katta zarar keltirgan. Qogʻozda xodim shoshilinch holatda imzoni qisqartirishi mumkin edi, dasturda esa shart istisnosiz bajariladi, hatto sababi allaqachon unutilgan boʻlsa ham va uni olib tashlash uchun alohida talab yozish kerak boʻlsa ham.

Dastur oʻz mantigʻini olib keladi

Dastur ham jarayonga oʻz mantigʻini yuklaydi, yaʼni xavf ikki tomonlama. Davenport 1998 yilda tayyor tijorat dasturlari, yaʼni korxona tizimlari haqida yozgan. Jurnal sahifasidagi kirish qismi ularni «orzu amalga oshgandek» deb taʼriflaydi: moliya, kadrlar, taʼminot va mijoz axborotini bir paketga yigʻishga vaʼda beradi. Maqolaning ommaviy tavsifi esa boshqa tomonni koʻrsatadi: tizim kompaniyaning oʻz talabiga yozilmagan, tayyor yechim, u oʻz mantigʻini kompaniya strategiyasi, madaniyati va tashkilotiga yuklaydi va koʻpincha ish usulini oʻzgartirishga majbur qiladi. Shu sababli tavsif tizim tanlovini faqat texnologlarga emas, umumiy rahbarlarga ham topshirishni maslahat beradi.

Brooks bu holatni tarixiy nuqtadan koʻrsatgan. 1950–60-yillardagi tadqiqotlar foydalanuvchilar ish haqi, ombor va debitor hisobi uchun tayyor paketlardan foydalanmasligini koʻrsatgan edi, chunki talablar juda maxsus va holatlar orasidagi farq katta. 1980-yillarga kelib bunday paketlar keng tarqaldi. Paketlar oʻzgarmagan, oʻzgargan narsa dastur va uskuna xarajatining nisbati. Maxsus ish haqi dasturiga puli yetmagan xaridor oʻz ish haqi tartibini mavjud paketga moslashtiradi.

Brooks tayyor paketni dasturiy yechimlarning eng radikali deb ataydi: dasturni umuman qurmaslik. Demak, «avval tartib» har doim ham «avval oʻzimizga moslab yozaylik» degani emas, koʻp hollarda tartibni paketga moslash arzonroq boʻladi. Lekin bu tanlov ongli boʻlishi kerak: nimani oʻzgartiramiz va nimani saqlaymiz, buni oldindan hal qilib qoʻyish zarur.

Tanlov ikki yoʻnalishda boʻlishi mumkin. Jadval ularning har birida nima yutilishi va nima yoʻqotilishini manbalardagi gaplar asosida solishtiradi.

Brooks: dasturdan nimani kutish mumkin

Dastur ishning eng qiyin qismini hal qilmaydi, chunki nima qurilayotganini aniqlash baribir odamning ishi boʻlib qoladi. Brooks 1986 yilda konferensiyada oʻqigan va 1987 yilda IEEE Computer jurnalida chop etilgan maqolasida dasturiy ishdagi qiyinchilikni ikkiga ajratadi. Birinchisi mohiyatiy qiyinchilik: murakkab tushunchalar tuzilmasini, yaʼni maʼlumotlar, ular orasidagi aloqa va algoritmlarni yaratish. Ikkinchisi tasodifiy qiyinchilik: shu tuzilmani dasturlash tili va kompyuter xotirasiga koʻchirish. Brooksning hukmi qattiq: ishning eng qiyin qismi shu tuzilmani aniqlash, loyihalash va sinash, uni yozib chiqish emas.

Biznes uchun bu gap muhim. Dastur tasodifiy qiyinchilikni olib tashlaydi: hisob-kitobni tezlashtiradi va qogʻozni yoʻqotadi. Jarayondagi chalkashlik esa mohiyatiy qiyinchilikka kiradi, chunki uni dastur yozilishidan oldin kimdir aniq hal qilishi, qaysi holatda nima boʻlishini aytib berishi kerak. Brooks shunday yozadi: dastur qurishning eng qiyin yagona qismi nima qurilishini aniq hal qilishdir. Mijoz odatda nimani xohlashini bilmaydi, hatto «yangi tizim eski qogʻozli tizimdek ishlasin» deyilganda ham bu juda sodda javob, chunki mijoz aslida buni xohlamaydi.

Murakkablikning yana bir qismi dasturchining oʻziga bogʻliq emas. Dastur tashqi tashkilotlar va tizimlarga moslashishi shart, bu moslashuvning murakkabligi esa «sababsiz va asossiz», chunki ular turli odamlar tomonidan yaratilgan. Bunday murakkablikni dasturning oʻzini qayta loyihalash bilan yoʻqotib boʻlmaydi. Mantiqan, jarayondagi tartibsizlik dastur uchun talab boʻlib kiradi: dastur uni hal qilmaydi, faqat aks ettiradi.

Brooks amaliy xulosaga ham olib boradi. Uning yozishicha, mijoz mahsulotning bir necha versiyasini qurib, sinab koʻrmaguncha talabni toʻliq, aniq va toʻgʻri koʻrsata olmaydi. Demak, tartibni qogʻozda «yakunlab», keyin dasturga topshirish kam hollarda ishlaydi, tartibni esa kichik oqimda sinab, dastur bilan birga aniqlashtirib borish ishonchliroq.

Telefónica O2: avval yoʻq qilish, keyin robot

Britaniyadagi Telefónica O2 robotni qoʻyishdan oldin jarayonlarni tartibga keltirdi, bu tartib esa RPA, yaʼni robotli jarayon avtomatlashtirish bilan solishtirilganda yaxshi koʻrinadi. Van der Aalst va hamkasblari RPA ni «tashqaridan ichkariga» yondashuv deb ataydi: axborot tizimi oʻzgarmaydi, odamlar oʻrniga dasturiy agentlar qoʻyiladi. Mantiqan, robot mavjud jarayonni qadamma-qadam takrorlaydi. Qadamlar soni ham, ketma-ketligi ham joyida qoladi, faqat bajaruvchi almashadi.

2010 yilda kompaniya 60 dan ortiq asosiy jarayonni va taxminan 400 ta ostki jarayonni yuritardi. Back Office xizmatlari rahbari Wayne Butterfield xarajatni qisqartirish vazifasi bilan qiymat qoʻshmaydigan jarayonlarni yoʻq qilishga, qolganlarini esa soddalashtirishga kirishdi.

Bir misol: buyurtmalar joʻnatilganini tekshiradigan eski nazorat. Buyurtma jarayoni shu qadar yetuk boʻlib qolganki, uning aniqligi 99,99 foizga yetgan, tekshiruv esa yuz minglab buyurtmani koʻrib chiqib, faqat bittasini topardi. Butterfield uni «maʼnosiz jarayon» deb atadi va yillar davomida hech kim uning qiymatini soʻramaganini aytdi. SIM almashtirilgandan keyin blokni olib tashlash tekshiruvi ham bekor qilindi, chunki blokni olib tashlashning oʻzi avtomatlashtirilgan edi.

Yoʻq qilish, soddalashtirish va optimallashtirishni oʻz ichiga olgan bu ish ikki yil davom etdi va xodimlar sonini oʻn foizga kamaytirdi. Shundan keyingina RPA ikkita jarayonda sinab koʻrildi. Sinov uchta savolga javob izladi: robot mavjud tizimlarni buzmasdan ulanadimi, sifatli ishlaydimi, yetarli foyda beradimi? U ikki hafta ichida tugadi. Butterfield RPA ga mos jarayon yetuk va qoidalarga asoslangan boʻlishi, aniq boshi va oxiri boʻlishi kerak, deydi. Tartib avval keldi, dastur keyin.

Van der Aalst esa 1990-yillardagi toʻgʻridan-toʻgʻri qayta ishlash, yaʼni STP gʻoyasi atigi bir necha jarayonga qoʻllanganini eslatadi. Hamma jarayon ham avtomatlashtirishga yaramaydi.

Besh odatiy xato

Yuqoridagi manbalardan besh takrorlanadigan xatoni ajratish mumkin. Jadval tahririyat tasnifi boʻlib, har qatorda tayanadigan manba oxirgi ustunda koʻrsatilgan.

Birinchi xatoga Ford misoli yaxshi toʻgʻri keladi. Uchta hujjat orasidagi 14 ta maʼlumot elementini tezroq solishtiradigan dastur yozish mumkin edi, Ford esa elementlarni uchtaga tushirdi va hisob-fakturani umuman yoʻq qildi. Eski tartibni shundayligicha raqamlashtirsangiz, oʻsha elementlar qoladi, faqat tezroq solishtiriladi. Uchinchi xato ham Fordga tegishli: kreditor qarzlar boʻlimini alohida qayta loyihalash befoyda chiqdi, chunki muammo xarid va qabulni ham qamrab olgan edi.

Amalda nima qilish mumkin

Avvalo shiorning oʻzini aniqlashtirish kerak. Hammer «tartib»ni oddiy silliqlash deb tushunmaydi: u jarayonni oqilona qilish ham, avtomatlashtirish ham kutilgan sakrashni bermaganini yozadi. Demak, tartib qadamlarni chiroyli joylashtirish emas, har bir qadam nima uchun borligini tekshirishdir.

Tahririyat xulosasi sifatida dasturga topshirishdan oldin uchta savol qoʻyish mumkin.

1. Bu qoidani kim va nima uchun kiritgan, hozir ham sababi qolganmi? Hammer buning uchun nazorat vositasi bilan qaror nuqtasini ajratishni tavsiya qiladi.
2. Bu murakkablik oʻzimizdan chiqqanmi yoki tashqaridan, yaʼni qonun, bank yoki hamkor talabidanmi? Brooksning moslashuv murakkabligi aynan shu tashqi qismga tegishli.
3. Biz jarayonni dasturga moslaymizmi yoki dasturni jarayonga? Davenport va Brooks bu tanlovni ochiq qoldiradi.

Kichik biznes uchun amaliy minimum oddiy: jarayonni qadamlar boʻyicha varaqqa yozing va har qadam yoniga «nima uchun?» hamda «kim hal qiladi?» deb belgi qoʻying. Sababi yoʻq qadam nomzod boʻladi, uni olib tashlash yoki dasturga oʻtkazmaslik mumkin, sababi bor qadam esa avtomatlashtirishga tayyor. Masalan, buyurtmani tasdiqlash toʻqqiz qadamdan iborat deylik. Varaqqa yozib, har qadamga savol berilganda, uchtasi uchun hech kim sabab ayta olmasa, dasturga oʻtkaziladigan jarayon uch qadamga qisqaradi va oltita qadam qoladi, uni sozlash, sinash, keyin oʻrgatish ham shunga mos yengillashadi. Bu gipotetik hisob, ammo ish tartibi Hammerning savolidan chiqadi.

Hammer oʻzi ham ogohlantiradi: bunday qayta koʻrish «hammasi yoki hech narsa» boʻlib, natijasi aniq emas. Tartib ham vaqt va tashkiliy sarf talab qiladi, shuning uchun kichik kompaniya uni bitta oqimdan boshlab, natijani koʻrib, keyin kengaytirgani maʼqul. Asosiy savol esa shu qoladi: sizning jarayoningizda qaysi qadam tartib sifatida emas, odat sifatida yashab kelmoqda?