СТРАШНИЙ АНАЛІТИК
Страшний бізнес-аналітик
Я знаю одну людину на ім'я Ігор.
Офіційно він, старший бізнес-аналітик.
Але серед своїх ми звемо його трохи інакше.
Страшний бізнес-аналітик.
Так, різниця між "старший" і "страшний" усього в одну літеру. Ми самі помітили це не одразу. А коли помітили, прізвисько прижилося намертво, і тепер від нього нікуди не подітися.
Не тому що він голосний.
Не тому що йому подобається доводити, що всі неправі.
І вже точно не тому, що він хоче, аби людям було некомфортно.
Прізвисько з'явилося з зовсім іншої причини.
Коли знаєш, що скоро зустрінешся з Ігорем, готуєшся заздалегідь.
Не тому що хтось тебе змушує.
А тому що знаєш: він запитає.
Назвеш цифру, запитає, звідки вона.
Пошлешся на звіт, захоче знати, хто його готував.
Зробиш висновок із припущення, тихо уточнить, чи хтось перевіряв це припущення останнім часом.
Скажеш "я думаю", швидше за все почуєш у відповідь: "А звідки ти знаєш?"
Ніколи агресивно.
Ніколи, щоб поставити в незручне становище.
Просто тому, що він щиро вважає: важливі рішення заслуговують на чесні відповіді.
Перші розмови з ним виснажують.
Не тому що вони складні.
А тому що змушують думати.
Ти починаєш перевіряти власну логіку ще до того, як він встигає поставити запитання.
Перевіряєш документи.
Переглядаєш цифри.
Відокремлюєш факти від припущень.
Перестаєш казати "напевно", коли від цього залежить бізнес.
Із часом я зрозумів дивну річ.
Люди стають уважнішими поряд з Ігорем не тому, що бояться його.
А тому що він занадто поважає правду, аби дозволити комусь, включно із самим собою, задовольнятися зручними відповідями.
Така дисципліна велика рідкість.
Значно рідкісніша за технічну експертизу.
У більшості компаній є люди, які вміють в Excel.
У багатьох є люди, які розуміються на фінансах.
У деяких є блискучі аналітики.
Але дуже рідко трапляється людина, чий інстинкт полягає в тому, щоб тихо покращувати якість кожного рішення, яке ухвалюють навколо неї.
Озираючись назад, я думаю, що його головний талант зовсім не аналітика.
Це інтелектуальна чесність.
І достатньо попрацювати з такою людиною хоча б раз, і це змінює те, як ти думаєш, назавжди. Навіть якщо перші пару місяців ти потайки мрієш, щоб він пішов у відпустку якомога довшу.
НЕ ПРО EXCEL
Таблиця, яка ніколи не була про Excel
Коли Ігор уперше показав мені свою таблицю, я очікував побачити щось видатне.
Я вже знав, що компанія спирається на неї в найважливіших рішеннях. Уявляв собі грізну фінансову модель, яку будували десятиліттями, тисячі формул, нескінченні листи, щось, що здатен зрозуміти лише сам автор.
Натомість я побачив Microsoft Excel.
Рядки.
Стовпці.
Зведені таблиці.
Графіки.
Нічого революційного на перший погляд.
Якби хтось зробив скриншот і виклав його в мережу, більшість пролистала б повз, навіть не замислившись.
Побачили б просто таблицю.
Я й сам мало не припустився тієї самої помилки.
А потім Ігор почав пояснювати, на що я насправді дивлюся.
Наступні кілька годин ми майже не говорили про Excel.
Ми говорили про людей.
Про десятки відділів, які надсилають документи в різних форматах.
Про звіти, що приходять із запізненням.
Про цифри, які виглядають правильними, але їм не можна довіряти.
Про інформацію, яку треба перевірити, перш ніж вона отримає право стати частиною фінансового прогнозу.
Він пояснював не формули.
Він пояснював, чому ці формули взагалі мали з'явитися.
У кожного листа була своя історія.
Один з'явився, бо два відділи по-різному трактували одну й ту саму подію в бізнесі.
Інший виник після помилки в прогнозі, яка показала, що важливе припущення непомітно застаріло.
Третій створили, бо "офіційний" звіт стабільно приходив надто пізно, щоб бути корисним, і бізнесу довелося шукати інший спосіб розуміти, що відбувається.
Жодне з цих рішень не прийшло з самого Excel.
Вони прийшли з багаторічних спостережень.
Зі звички ставити незручні запитання.
З відмови приймати цифри лише тому, що вони виглядають переконливо.
Тоді я зрозумів те, що залишилося зі мною назавжди.
Ця таблиця не організовувала дані.
Вона організовувала реальність.
Кожне вдосконалення було ще одним шматочком знання про бізнес, відкритим, перевіреним, оскарженим, доопрацьованим і врешті визнаним вартим довіри.
Це була не колекція формул.
Це була жива модель того, як насправді працює складний бізнес.
І це назавжди змінило те, як я думаю про софт.
ЯК ПОЧИНАЮТЬСЯ СИСТЕМИ
Кожна корпоративна система починається однаково
Того дня я перестав думати про Excel.
Бо справа ніколи не була в Excel.
Таблиця була просто місцем, де записали роки роздумів.
А це зовсім інша річ.
Ми звикли уявляти, що корпоративний софт починається з великого бюджету, консалтингової компанії, місяців воркшопів і команди розробників, які малюють архітектурні схеми на дошці.
На практиці це рідкість.
Набагато частіше все починається з однієї людини, яка намагається розв'язати одну проблему.
Засновник відкриває порожню таблицю, щоб відстежувати продажі.
Бухгалтер вигадує зручніший спосіб звіряти платежі.
Операційний менеджер збирає просту таблицю для контролю складу.
Бізнес-аналітик помічає, що два звіти ніколи не збігаються, і вирішує розібратися чому.
Ніхто з них не намагається побудувати корпоративну платформу.
Вони просто хочуть, щоб завтра було трохи краще, ніж учора.
А потім трапляється дещо примітне.
Бізнес росте.
Приходять нові співробітники.
З'являються нові продукти.
Нові постачальники.
Нові регуляторні вимоги.
Нові ринки.
Те, що починалося як просте рішення, поступово перетворюється на систему.
Одне вдосконалення тягне за собою наступне.
Один виняток народжує нове правило.
Один виявлений патерн змінює модель прогнозування.
Одна помилка запобігає десяти майбутнім.
Рік за роком таблиця стає дедалі менше про розрахунки, і дедалі більше про накопичене розуміння бізнесу.
У якийсь момент компанія доходить спільного висновку:
"Ми переросли Excel".
Зазвичай вони мають рацію.
Але часто неправильно розуміють, чому.
Проблема не в тому, що Excel став затісним.
Проблема в тому, що бізнес став занадто розумним.
Те, що більше не вміщується в таблицю, це не дані.
Це знання.
Зв'язки.
Винятки.
Логіка рішень.
Невидима архітектура, яка вибудовувалася роками.
Ми написали окрему статтю саме про таку невидиму структуру, Most Companies Don't Own Their Website. They Own a Collection of Dependencies.
Саме тому так багато проєктів цифрової трансформації буксують.
Компанії думають, що замінюють софт.
Насправді вони намагаються зберегти десятиліття людського розуміння бізнесу.
І якщо це розуміння не знайдене, не задокументоване й не поставлене під сумнів до того, як почнеться розробка, жодна мова програмування, жодна AI-модель і жодна корпоративна платформа не зможе відтворити його заново.
Технологія вміє виконувати логіку.
Вона не вміє вигадувати бізнес-логіку, яку ніхто й ніколи не зафіксував.
НЕ ЛИШЕ МАЛИЙ БІЗНЕС
Це стосується далеко не лише малого бізнесу
А ось що здивувало мене найбільше.
Це трапляється не тільки із засновниками, які працюють із вільної кімнати, і не з компаніями, яким просто бракує грошей на нормальні системи. Це трапляється з одними з найресурсніших і найдосвідченіших організацій світу, бо річ ніколи не була в бюджеті. Річ у тому, де саме живе знання.
У 2012 році підрозділ JPMorgan Chase з управління ризиками вважався одним з найпросунутіших у світових фінансах, банк щойно пройшов кризу 2008-го впевненіше за майже всіх на Волл-стріт. Усередині цієї машини була ризик-модель, яку частково вели вручну, копіювали і вставляли значення між таблицями. Формула, яка мала усереднювати два числа, натомість їх додавала. Одна тиха помилка допомогла торговій позиції вийти з-під контролю. Підсумкові втрати перевищили шість мільярдів доларів, до них додалися слухання в Конгресі, штрафи регулятора і вдвічі урізана річна зарплата CEO. У JPMorgan ніхто не вважав себе "конторою на Excel". Радше навпаки, за репутацією це була пряма протилежність. Не допомогло. Знання того, як саме влаштована ця таблиця і що передбачають її формули, було в дуже вузького кола людей, і ніхто поза цим колом не міг спіймати помилку до того, як вона перетворилася на кризу. Кумедно, що банк з одними з найкращих ризик-моделей у світі зрештою постраждав саме від ризику, який ніхто не змоделював.
У 2020 році, у розпал пандемії, національне агентство охорони здоров'я Англії збирало позитивні результати тестів на COVID-19 у форматі таблиці, який датувався ще 1997 роком, із жорстким лімітом приблизно на 65 тисяч рядків. Ніхто не вирішував втрачати дані. Але щойно щоденний файл заповнювався, кожен новий рядок понад ліміт просто зникав, без помилки, без попередження. Майже 16 тисяч позитивних тестів пропали з офіційної статистики більш ніж на тиждень. До 50 тисяч людей, які контактували з хворими, вчасно не змогли знайти служби відстеження контактів. Система працювала рівно так, як її спроєктували. Просто її ніхто не спроєктував так, щоб урахувати все, що їй одного дня доведеться вмістити.
Схожі історії, тільки менші за масштабом, трапляються постійно. Канадська енергетична компанія втратила двадцять чотири мільйони доларів через одну помилку copy-paste в таблиці хеджування. Відомий виробник фототехніки завищив зобов'язання з виплат співробітнику на одинадцять мільйонів доларів, через один зайвий нуль. Впливова наукова робота про зв'язок держборгу й економічного зростання, на яку спиралися рішення про austerity-політику в Європі після 2008 року, виявилася побудована на формулі середнього в Excel, яка непомітно виключила з розрахунку дані кількох країн.
Жодна з цих організацій не була недбалою. Жодній не бракувало таланту, бюджету чи технічної підготовки. Спільним було інше, набагато простіше й універсальніше: критична бізнес-логіка жила всередині одного файлу, була повністю зрозуміла дуже вузькому колу людей, і залишалася невидимою для всіх інших, доки одного дня не ламалася.
У цієї закономірності достатньо повторень, щоб отримати одразу кілька назв, їх незалежно одне від одного вигадали люди, які натикалися на неї з різних боків.
Ризик-менеджери називають це Key Person Dependency Risk, ризиком залежності від ключової людини: момент, коли бізнес настільки покладається на знання однієї людини, що її втрата суттєво порушить роботу компанії. Це давно перестало бути просто питанням HR. Британський регулятор FCA включив цей ризик у вимоги до операційної стійкості фінансових організацій, а американська SEC зобов'язує публічні компанії розкривати цей ризик у річній звітності.
Інженери називають це Bus Factor, "фактором автобуса": грубувато кажучи, скільки людей має зникнути, щоб критична система стала. У здоровій команді відповідь, кілька. У набагато більшої кількості команд, ніж прийнято визнавати, для найважливішого процесу чесна відповідь, одна людина. І якщо це людина на прізвисько "страшний аналітик", вам, як не дивно, пощастило: принаймні хтось намагається знизити цей ризик, а не створює його.
ІТ-відділи мають назву для систем, які з'являються без їхньої участі: Shadow IT, "тіньовий ІТ". Так називають інструменти, таблиці та обхідні рішення, які бізнес-підрозділ будує сам, бо чекати офіційного рішення виходить дорожче, ніж зробити неофіційне. За деякими галузевими оцінками, понад третину всіх рішень про корпоративні технології ухвалюють саме так, тихо, в обхід офіційного процесу, поки хтось одного дня не помітить.
А операційні команди самé це знання називають Tribal Knowledge, "знанням племені": те, що живе тільки в чиїйсь голові або в чиїйсь таблиці, і більше ніде в організації.
Чотири різні назви з чотирьох різних дисциплін, і всі вони описують рівно те, чим тихо займалася таблиця Ігоря, лист за листом.
ПЕРШ НІЖ БУДУВАТИ
Перш ніж будувати софт, ми шукаємо Ігоря
Та розмова змінила для мене дещо фундаментальне.
Роками я вважав, що софт-проєкти починаються з вимог.
Сьогодні я думаю, що вони починаються в іншому місці.
З людей.
Не тому що люди важливіші за технології.
А тому що технологія не здатна створювати розуміння.
Вона здатна лише його зберігати.
Відтоді щоразу, коли хтось просить нас зробити сайт, внутрішню платформу, кастомний застосунок, AI-рішення або цілком новий цифровий продукт, я ловлю себе на іншому запитанні.
ХТО ВАШ ІГОР
Хто у вас Ігор?
Не буквально.
У кожній компанії його звуть по-різному.
Іноді це аналітик.
Іноді операційний менеджер.
Іноді бухгалтер.
Іноді інженер виробництва.
Іноді це сам засновник.
Іноді це людина, яку ніхто не помічає, поки вона не йде у відпустку.
Вони рідко бувають найгучнішим голосом у кімнаті.
У них рідко найефектніша посада.
Але за роки вони встигли зробити дещо видатне.
Вони провели тисячі годин, спостерігаючи за бізнесом.
Знаходячи закономірності.
Ставлячи під сумнів припущення.
Прибираючи зайву складність.
Покращуючи процеси, які їх офіційно ніхто не просив покращувати.
Навчаючи колег, які справді хотіли вчитися.
Не тому що це було прописано в посадовій інструкції.
А тому що вони фізично не могли ігнорувати систему, яку можна було зробити кращою.
Ці люди будують софт задовго до того, як розробники напишуть перший рядок коду.
Їхньою мовою програмування є розмови, документи, таблиці й досвід.
Рано чи пізно кожен успішний бізнес доходить до однієї й тієї самої розвилки.
Таблиці більше не вистачає.
Процеси переросли інструменти, які їх створили.
Треба будувати нову систему.
І ось тут багато компаній роблять дорогу помилку.
Ми детально розбирали саме цю закономірність у статті How to Choose a Web Development Company.
Вони починають із технології.
Python чи Java?
Кастомна розробка чи SaaS?
AI чи автоматизація?
Хмара чи власні сервери?
Це важливі запитання.
Просто це не перші запитання.
Перше запитання набагато простіше.
ЩО ЗНАЮТЬ ЛЮДИ
Що ваші люди вже встигли дізнатися про те, як насправді працює цей бізнес?
Бо саме це знання є фундаментом будь-якої системи, яка колись успішно запрацює. І саме це, як з'ясували на власному досвіді JPMorgan і служба охорони здоров'я Англії, та річ, яка тихо вирішує: чи виявить компанія власні сліпі зони сама, на своїх умовах, чи дізнається про них із заголовків новин.
Добре спроєктована платформа не замінює таблицю.
Вона успадковує її мудрість.
Вона зберігає роки рішень, уроків, помилок і відкриттів, прибираючи водночас обмеження, через які ці відкриття було важко масштабувати, і точки єдиної вразливості, через які вся система трималася на волосині.
Саме тому наш процес discovery починається з людей, а не з технологій.
Це те саме переконання, що лежить в основі статті The Hidden Cost of Choosing the Wrong Architecture.
З розмов раніше, ніж з архітектури.
З цікавості раніше, ніж з коду.
Іноді ці розмови підтверджують: бізнесу справді потрібна кастомна розробка.
Іноді з'ясовується, що наявній системі треба лише розвинутися.
Іноді правильна відповідь на диво проста.
Технології змінюються.
Інструменти еволюціонують.
AI продовжить змінювати те, як ми будуємо софт.
Але один принцип залишався правдивим у кожному значущому проєкті, у якому я брав участь.
НАРОДЖУЄТЬСЯ З ЛЮДЕЙ
Хороший софт ніколи не народжується з технології
Він народжується з людей, яким було не байдуже, і які захотіли зрозуміти бізнес, перш ніж хтось спробував його автоматизувати.
У кожного бізнесу є свій Ігор. І майже в кожного бізнесу є свій "фактор автобуса", що дорівнює одиниці, просто їм ще не настільки не пощастило, щоб це з'ясувати.
Перш ніж рекомендувати сайт, кастомну розробку, інтеграцію AI чи цифрову платформу, ми вважаємо першим кроком розуміння того, як насправді працює ваш бізнес. Саме для цього створені наші Strategic Sessions.
- Поділитися
-
-
-
-
