Є одна доволі цікава особливість, яку доводиться регулярно спостерігати під час розмов з представниками українського бізнесу про автоматизацію. Практично в кожній компанії можна почути скарги на застаріле програмне забезпечення, нескінченні Excel-таблиці, необхідність кілька разів переносити одні й ті самі дані з однієї системи до іншої, відсутність нормальної аналітики, незручні звіти, помилки та величезну кількість ручної роботи. Керівники цілком справедливо нарікають на те, що отримання найпростішої інформації займає години або навіть дні, бухгалтери скаржаться на програму, менеджери — на бухгалтерію, бухгалтерія — на менеджерів, а власник бізнесу зрештою доходить цілком логічного висновку, що все це потрібно нарешті замінити чимось сучаснішим. І ось саме в цей момент нерідко відбувається дивна метаморфоза: система, яку ще вчора всі дружно критикували, раптом виявляється не такою вже й поганою, а навколо ідеї її заміни починає виникати безліч аргументів, чому цього робити не варто, принаймні зараз.
В українських реаліях останніх років до звичайного питання технологічної модернізації додалася ще одна обставина — необхідність відмови від російського програмного забезпечення. Після початку повномасштабної війни здавалося б, що тут принаймні мотиваційна частина питання повинна була зникнути сама собою. Залежність від російських розробників, ризики для даних, проблеми з легальним придбанням і підтримкою, санкції та, зрештою, саме небажання продовжувати фінансувати технологічну екосистему держави, яка веде проти України війну, створюють більш ніж достатній набір причин для переходу на українські або західні продукти. Проте на практиці й тут часто можна побачити ту саму картину: компанія декларує намір мігрувати, розглядає альтернативи, проводить презентації, іноді навіть починає певні підготовчі роботи, після чого процес поступово зупиняється, а стара система продовжує працювати ще рік, два або п’ять років.
Система, яку всі критикують, але ніхто не хоче міняти
Причини цього, звичайно, далеко не завжди зводяться до банального небажання людей вчитися чомусь новому. Навпаки, у багатьох випадках спротив є цілком зрозумілим, а подекуди навіть раціональним. Уявімо бухгалтера, який десять чи п’ятнадцять років працює з однією програмою і за цей час вивчив не лише її штатні функції, а й усі особливості, помилки, обхідні рішення та неочевидні способи отримати необхідний результат. Він знає, який звіт потрібно сформувати перед закриттям періоду, де доведеться вручну підправити дані, що робити, якщо чергове оновлення щось зламало, як обійти обмеження системи і до кого звернутися, коли не допомагає вже нічого. З погляду людини, яка вперше бачить цей процес, значна частина такої роботи може виглядати як безглузда втрата часу, однак для працівника всі ці знання є накопиченою роками професійною компетенцією, яка до того ж робить його цінним і важко замінним спеціалістом.
Саме тут виникає конфлікт, який рідко формулюється вголос. Сучасна система може автоматизувати значну частину операцій, для виконання яких у старій потрібні специфічні знання, а разом із цим частково знецінити той досвід, який людина накопичувала роками. Учора вона була фахівцем, що знав усі тонкощі складного механізму, а завтра повинна знову навчатися майже з нуля, причому разом із колегами, які можуть мати значно менший досвід роботи. Не дивно, що в такій ситуації переваги нової системи оцінюються набагато критичніше, ніж її недоліки. Стара програма може бути незручною, повільною і застарілою, проте вона знайома і передбачувана, тоді як нова обіцяє певні переваги в майбутньому, але вже сьогодні вимагає додаткової роботи, навчання та зміни звичних процедур.
Прозорість, яка подобається не всім
Інший тип спротиву можна зустріти на рівні керівників підрозділів. Однією з головних переваг сучасних CRM, ERP та інших корпоративних систем є прозорість процесів, що одночасно є однією з причин, через які їхнє впровадження подобається далеко не всім. Коли інформація зберігається в особистих таблицях, електронній пошті, месенджерах і головах співробітників, визначити, де саме виникла затримка, хто не опрацював заявку, чому не відбувся продаж або скільки часу фактично займає певна операція, буває досить складно. Після впровадження нормально налаштованої системи значна частина цих питань отримує цілком конкретні відповіді, і часом вони виявляються не надто приємними для керівництва окремого відділу.
Наприклад, може з’ясуватися, що проблема падіння продажів полягала не в «складній ринковій ситуації», а в тому, що частина заявок по кілька днів залишалася без відповіді, менеджери не робили повторних контактів, а інформація про потенційних клієнтів губилася між поштою, телефоном і таблицями. Так само може виявитися, що відділ, який постійно потребує додаткових людей, витрачає значну частину робочого часу на механічне перенесення даних між кількома системами. У подібних випадках автоматизація змінює не лише технологію виконання роботи, але й можливість оцінити її реальну ефективність, а отже, певною мірою змінює і баланс відносин усередині компанії.
Особливо добре це видно на прикладі CRM. Поки менеджер зберігає контакти клієнтів у власному телефоні, домовленості — у месенджерах, а історію спілкування частково пам’ятає сам, клієнт фактично залишається пов’язаним із конкретним співробітником. Після впровадження CRM уся історія комунікації стає доступною компанії, і клієнт із «клієнта менеджера» перетворюється на клієнта організації. Для власника бізнесу це цілком природний і бажаний результат, однак для працівника така зміна може означати втрату частини неформального впливу, який він мав раніше. Подібні речі рідко обговорюються під час презентацій програмного забезпечення, хоча на успішність його впровадження вони іноді впливають значно сильніше, ніж набір функцій або зручність інтерфейсу.
Коли складність системи працює на статус фахівця
Дещо парадоксальна ситуація може складатися і з внутрішнім ІТ-відділом. За логікою саме ІТ-директор або системний адміністратор мав би бути одним із головних прихильників оновлення технологічної інфраструктури, і в багатьох компаніях це справді так. Проте в організаціях, де інформаційні системи розвивалися десятиліттями без єдиної архітектури, поступово виникає складна конструкція з серверів, старих баз даних, самописних інтеграцій, скриптів, нестандартних налаштувань і програм, частина з яких давно не підтримується виробником. Часто повністю розуміє принцип роботи цієї конструкції лише одна людина або невелика група спеціалістів, які роками її підтримують.
Для компанії така ситуація є очевидним ризиком, оскільки критична інфраструктура фактично залежить від конкретних працівників. Для самих працівників вона одночасно створює особливий статус: вони є людьми, без яких ніхто не знає, чому певний сервер не можна перезавантажувати в робочий час, яким чином одна база обмінюється даними з іншою і що потрібно зробити, якщо після чергового оновлення перестає працювати система, написана ще попереднім підрядником. Перехід на стандартизовані рішення, нормальна документація процесів, використання сучасних інтеграцій або хмарних сервісів знижують залежність компанії від такої сакральної експертизи, а тому цілком природно можуть викликати певний спротив.
При цьому аргументація проти змін зовсім не обов’язково буде неправильною. Міграція справді може бути ризикованою, хмарні системи мають свої недоліки, залежність від конкретного постачальника програмного забезпечення є реальною проблемою, а перенесення десятків років накопичених даних іноді виявляється надзвичайно складним і дорогим процесом. Саме тому технологічний консерватизм важко відокремити від цілком професійної обережності, адже в реальному бізнесі вони зазвичай існують одночасно. Проблема виникає лише тоді, коли перелік реальних ризиків автоматично перетворюється на універсальне обґрунтування необхідності залишити все без змін.
У випадку з рядовими працівниками мотиви можуть бути ще простішими. Якщо компанія автоматизує операцію, на яку раніше витрачалося кілька годин щодня, власник отримує економію, клієнт — швидше обслуговування, а працівник — необхідність освоїти нову систему та цілком логічне запитання, що саме він робитиме після того, як значна частина його роботи більше не буде потрібна. Популярна теза про те, що автоматизація звільняє людей від рутинної роботи для виконання більш творчих завдань, безумовно, іноді відповідає дійсності, однак не варто забувати, що в інших випадках вона просто скорочує потребу компанії в певній кількості людей. Очікувати від працівника щирого ентузіазму щодо технології, яка потенційно може зробити його посаду непотрібною, було б щонайменше наївно.
Саме тому спроби пояснити весь спротив фразою про те, що «люди не люблять змін», видаються мені надто примітивними. Люди чудово сприймають нові технології, коли бачать у них очевидну користь для себе, що легко перевірити на прикладі смартфонів, банківських застосунків, месенджерів або будь-яких інших побутових сервісів. Значно складнішою стає ситуація, коли вигоду від зміни отримує компанія, а безпосередні витрати — у вигляді навчання, додаткової роботи, втрати звичного статусу або контролю над інформацією — лягають на конкретного співробітника.
Двадцять років у системі як аргумент
Історія з відмовою від російського програмного забезпечення лише зробила цю проблему помітнішою. Формально аргументація на користь міграції тут настільки сильна, що дискусія, здавалося б, давно мала б завершитися. Проте чим довше компанія користувалася певною системою, тим більше вона встигла навколо неї побудувати: інтеграції, звіти, інструкції, процедури, зв’язки з підрядниками, знання працівників і навіть частину своєї організаційної структури. Тому фраза «ми працюємо в цій програмі двадцять років» одночасно є і поясненням складності міграції, і хорошою ілюстрацією того, чому її потрібно було починати значно раніше.
У цьому проявляється одна з неприємних властивостей технологічного боргу: він має здатність сам себе виправдовувати. Чим довше відкладається заміна застарілої системи, тим більше грошей, часу й специфічних знань компанія вкладає в її підтримку, а отже, тим дорожчим стає майбутній перехід. Через кілька років саме висока вартість міграції використовується як аргумент на користь того, щоб її знову відкласти. У результаті підприємство продовжує платити не стільки за старе програмне забезпечення, скільки за власну багаторічну нездатність від нього відмовитися.
Втім, було б неправильно робити з цього висновок, що будь-який спротив працівників потрібно просто ігнорувати. У багатьох компаніях люди мають цілком вагомі причини скептично ставитися до чергового проєкту «цифрової трансформації». Вони могли вже пережити впровадження CRM, якою через пів року ніхто не користувався, ERP-систему, яку кілька років допрацьовували, а потім частину процесів усе одно повернули в Excel, невдалу міграцію даних або консультантів, що залишили після себе красиву презентацію та систему, яку ніхто не зміг нормально підтримувати. Такий досвід формує цілком зрозумілу недовіру, і якщо керівництво її ігнорує, воно ризикує повторити ті самі помилки.
Однак є велика різниця між обережністю, що ґрунтується на попередньому досвіді, і ситуацією, коли будь-яка невдала спроба модернізації перетворюється на аргумент проти модернізації як такої. Фраза «ми вже пробували» сама по собі нічого не говорить про те, чи потрібні зміни зараз; вона лише свідчить про те, що попередня спроба з певних причин завершилася невдало, і набагато корисніше було б розібратися саме з цими причинами.
Новий софт змінює більше, ніж інтерфейс
Мабуть, головна помилка власників бізнесу полягає в тому, що заміну програмного забезпечення вони часто сприймають передусім як технічний проєкт, хоча на практиці це майже завжди ще й організаційна реформа. Впровадження CRM визначає, кому належить інформація про клієнтів, автоматизація бухгалтерії змінює частину усталених функцій працівників, ERP робить прозорішим рух товарів, грошей та документів, а модернізація внутрішньої ІТ-інфраструктури може змінити роль людей, які її десятиліттями підтримували. Навіть відмова від російської системи на користь української або західної означає не просто заміну одного програмного продукту іншим, а руйнування цілої технологічної екосистеми, що встигла сформуватися навколо нього.
Тому перед початком серйозної автоматизації поряд із питаннями про функціональність, інтеграції, вартість ліцензій і строки впровадження, на мою думку, варто поставити ще одне, значно менш технічне питання: хто саме всередині компанії щось втратить у результаті цих змін? Це може бути частина звичних функцій, контроль над інформацією, статус незамінного спеціаліста, неформальний вплив, необхідність виконувати певну роботу вручну або, зрештою, саме робоче місце. Саме в цій точці, швидше за все, і варто очікувати найбільший спротив, причому виявити його на початку проєкту значно дешевше, ніж через рік з’ясувати, що нова система формально впроваджена, але половина працівників продовжує паралельно вести старі таблиці та користуватися звичними програмами.
Застаріле програмне забезпечення взагалі має дивну властивість поступово ставати частиною самої організації. Навколо нього формуються процедури, посади, компетенції, неформальні зв’язки та залежності, а іноді й цілі професійні кар’єри. Тому, коли власник підприємства вирішує нарешті замінити систему, яка давно перестала відповідати потребам бізнесу або взагалі не повинна використовуватися в Україні з міркувань безпеки та здорового глузду, він нерідко помилково вважає, що йдеться лише про придбання нового програмного продукту. Насправді змінювати доводиться значно більше — і саме тому спротив старому софту іноді виявляється набагато сильнішим, ніж можна було очікувати від звичайної заміни програми.
Спротив як підказка для змін
Втім, у всій цій історії є й позитивний бік. Сам факт спротиву ще не означає, що зміни приречені на провал; швидше він показує, які саме місця в організації потребують найбільшої уваги. Якщо заздалегідь розуміти, кого торкнеться нова система, які звичні функції вона змінить, де виникне потреба в навчанні, а де — страх втрати статусу або контролю, більшість таких проблем можна вирішити ще до початку впровадження. Успішна автоматизація, на мою думку, починається не з вибору CRM чи ERP і навіть не з технічного завдання, а з розуміння того, як компанія працює сьогодні і як вона повинна працювати після змін.
У цьому сенсі старий софт навіть може виявитися корисним діагностичним інструментом: навколо нього добре видно слабкі місця процесів, надмірну залежність від окремих людей, дублювання роботи, інформаційні монополії та операції, які давно варто було автоматизувати. І якщо підходити до міграції не як до простого встановлення нової програми, а як до поступової перебудови бізнес-процесів, то результатом може стати не лише сучасніша система, але й значно здоровіша організація, менш залежна від випадкових людей, застарілих технологій і рішень, прийнятих десять чи двадцять років тому.
Можливо, саме це і є найкращим аргументом на користь змін. Хороший софт не повинен робити людей менш важливими для компанії — він повинен робити менш важливими ті проблеми, на подолання яких люди змушені витрачати свій час.
