В IT-среде до сих пор живёт уютный миф: аналитик - это человек, который переводит пожелания бизнеса на язык разработчиков, в лучшем случае ещё и красиво рисует схемы. Для многих на этом зона ответственности заканчивается и формально они правы: именно так чаще всего описана роль в должностных инструкциях.
Важно проговорить: всё, о чём я пишу дальше, формально не входит в стандартный набор обязанностей системного аналитика. Это зона, куда аналитик может войти по своему выбору, если хочет влиять на риски и бюджеты, а не только на постановку задач.
Проблема в том, что когда на кону юридическая чистота всей компании, а цена ошибки измеряется не в часах разработки, а в статьях УК РФ и десятках миллионов рублей потенциальных потерь, роль аналитика резко меняется. В этот момент часто происходит подмена: аналитика делают ответственным за операционный хаос и сырые требования стейкхолдеров, потому что он “ближе всех к системе”.
Для меня переход в позицию внутреннего кризис-менеджера - это не вынужденная мера, а мой личный выбор. Я сознательно беру на себя координацию распределения зон риска между отделами, потому что вижу в этом не дополнительную нагрузку, а возможность влиять на устойчивость бизнеса и расти как эксперт. Да, эта работа выходит за рамки классической роли аналитика и затрагивает юриспруденцию, налоговое регулирование, складскую логистику. Но именно способность видеть всю картину целиком и переводить риски в понятные решения отличает аналитика, на которого можно опереться.
Кейс: зависшие коды маркировки.
В одном из проектов по маркировке “Честный Знак” мне пришлось быть одновременно ведущим системным аналитиком, владельцем продукта и внутренним кризис-менеджером и это был осознанный шаг за рамки моей формальной роли.
На первый взгляд ситуация выглядела рутинной: в системе накопились тысячи зависших кодов маркировки -“хвосты” от продаж двухлетней давности. Товар продан, деньги получены, а остатки по КИЗ продолжают числиться. Для разработчика это «расхождение статусов», для аналитика - технический долг, а для бизнеса - потенциальная мина замедленного действия.
Для контролирующих органов картина однозначна: либо фиктивные остатки, либо нелегальный оборот, а дальше - блокировки счетов, доначисления, проверки. В такой ситуации ошибка - это уже не про “переделаем в следующем спринте”, а про реальные деньги и ответственность.
Мой подход: не фиксировать проблему, а упаковать риски.
Большинство аналитиков на этом месте оформят задачу в системе и передадут дальше. Формально они всё сделали правильно: описали проблему, перевели её в язык задачи и отдали на реализацию.
Мой выбор был другим: начать не с ТЗ, а с матрицы рисков, где каждому сценарию соответствовали конкретные статьи КоАП, НК РФ и УК РФ и оценочные финансовые последствия. Я не просто показывала риски - я переводила их на язык денег и юридических формулировок для каждого стейкхолдера:
- главному бухгалтеру - как расхождения в статусах КИЗ могут привести к разрывам в АСК НДС-2 и доначислениям;
- генеральному директору - где начинается “крупный размер” по ст. 171.1 УК РФ и как цепочка неучтённых остатков может превратиться в уголовное дело.
Только после того, как риски были упакованы в цифры и юридический язык, проект получил высший приоритет и необходимый административный ресурс. Это уже работа на уровне риск-менеджмента, а не классической аналитики.
Архитектура на фундаменте процессов, а не хаоса.
Самая опасная ошибка в крупных проектах - автоматизировать хаос, о чем я постоянно и много пишу. Если процессы не согласованы, а зоны ответственности размыты, любая система лишь закрепит проблемы и умножит риски.
Поэтому первым делом я ввела жёсткое правило: никаких ручных правок базы без актов комиссии и понятных оснований. Руководитель, который отказывается навести порядок в процессах до старта разработки, осознанно берёт на себя риски будущих штрафов. Это не “каприз аналитика”, а честное обозначение границ: IT не должно быть крайним за отсутствие регламентов в бизнесе.
Отдельно я проговорила для стейкхолдеров важную вещь: ответственность за регуляторные нарушения не может “по умолчанию” ложиться на аналитика или IT только потому, что они ближе к системе. Их роль - формализация требований, составление ТЗ, архитектура , а не “груша для битья” за чужие процессы.
Распределение ответственности.
В проектах с высокими регуляторными рисками зона ответственности часто размыта: юристы кивают на бухгалтерию, бухгалтерия - на склад, склад - на IT. В итоге никто не хочет ставить подпись, а бизнес тем временем рискует деньгами и репутацией.
Моё решение было системным: я разделила задачу на блоки и закрепила за каждым руководителем конкретные действия и сроки:
- юристы - безопасные формулировки причин вывода из оборота и подготовка актов комиссий;
- бухгалтерия и внутренний контроль - график поэтапной очистки базы и оценка налоговых последствий;
- склад и продажи - назначение МОЛ, изменение процессов приёмки/отгрузки, работа с инвентаризацией;
- аналитик/IT - архитектура мониторинга жизненного цикла КИЗ в 1С и отказ от массовых ручных правок без документальной базы.
Это уже про сознательное распределение рисков, а не про попытку “спрятать” проблему за спиной IT.
Бумажный след как защита команды.
Многие считают письма, протоколы и акты лишней бюрократией. В проектах с высокими рисками это - главный инструмент защиты команды.
Я не ограничилась документом: отправила письма коллегам (продажи, юристы, бухгалтерия) с предложением совместной работы и зафиксировала в письменном виде, что источник проблемы - организационные процессы, а не сбой 1С. Отдельным письмом руководству IT я попросила подтвердить факт получения документа и проговорила границы ответственности: где зона бизнес-подразделений, а где задачи IT и аналитики.
Когда через полгода начнётся проверка, устные договорённости никого не спасут. Останутся документы и именно они покажут: система была запущена вовремя, зоны ответственности согласованы, риски разделены осознанно, а IT-команда не была по умолчанию ответственной за чужие бизнес-решения.
Результат и ключевой вывод.
В итоге архитектура мониторинга КИЗ в 1С будет разрабатываться не в вакууме, а на базе утверждённых юридических оснований. Бизнес получил прозрачный процесс, который снижает риски, а мой департамент - чёткий периметр ответственности и понятные границы участия.
Ключевой вывод для меня: рост аналитика не в том, чтобы молча принимать на себя чужую ответственность и закрывать хаос, а в осознанном расширении своей роли, от “переводчика требований” до партнёра по управлению рисками. Это не обязанность по должностной инструкции, а выбор уровня игры для тех, кто готов развивать бизнес-мышление и брать на себя масштаб.
Аналитик с таким подходом - это не про расширенный сервис “описать подробнее задачу”, а стратегический партнёр по риск-менеджменту. Он заранее подсвечивает угрозы, переводит регуляторные требования в понятные процессы и защищает команду от того, чтобы стать крайними за чужие управленческие решения.