СТРАШНЫЙ АНАЛИТИК
Страшный бизнес-аналитик
Я знаю одного человека по имени Игорь.
Официально он, старший бизнес-аналитик.
Но среди своих мы зовём его немного иначе.
Страшный бизнес-аналитик.
И да, разница между "старший" и "страшный" всего в одну букву. Мы сами заметили это не сразу, а когда заметили, прозвище прижилось намертво.
Не потому что он громкий.
Не потому что ему нравится доказывать, что все неправы.
И уж точно не потому, что он хочет, чтобы людям было некомфортно.
Прозвище появилось совсем по другой причине.
Когда знаешь, что скоро встретишься с Игорем, ты готовишься.
Не потому что кто-то тебя заставляет.
А потому что знаешь: он спросит.
Назовёшь цифру, спросит, откуда она.
Сошлёшься на отчёт, захочет знать, кто его готовил.
Сделаешь вывод из предположения, тихо уточнит, проверял ли кто-нибудь это предположение в последнее время.
Скажешь "я думаю", скорее всего услышишь в ответ: "А откуда ты знаешь?"
Никогда агрессивно.
Никогда, чтобы поставить в неловкое положение.
Просто потому, что он искренне считает: важные решения заслуживают честных ответов.
Первые разговоры с ним выматывают.
Не потому что они сложные.
А потому что заставляют думать.
Ты начинаешь проверять собственную логику ещё до того, как он успевает задать вопрос.
Перепроверяешь документы.
Пересматриваешь цифры.
Отделяешь факты от предположений.
Перестаёшь говорить "наверное", когда от этого зависит бизнес.
Со временем я понял странную вещь.
Люди становятся аккуратнее рядом с Игорем не потому, что боятся его.
А потому что он слишком уважает правду, чтобы позволить кому-то, включая себя самого, соглашаться на удобные ответы.
Такая дисциплина большая редкость.
Куда более редкая, чем техническая экспертиза.
В большинстве компаний есть люди, которые умеют в 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.
- Поделиться
-
-
-
-
