Кто должен отвечать за автоматизацию в компании
Автоматизация почти никогда не проваливается потому, что разработчики не смогли написать код.
Гораздо чаще проблема возникает раньше.
Компания не определила, кто отвечает за результат автоматизации.
ИТ считает, что бизнес должен сформулировать требования.
Бизнес считает, что ИТ должно само понять, что нужно сделать.
Возникает неудобный вопрос:
Ответ: не один человек.
Но и ситуация, когда «отвечают все», тоже не работает.
Нужна понятная система ответственности.
Автоматизация — это не ИТ-проект
Одна из самых распространённых ошибок — считать автоматизацию исключительно задачей ИТ.
Например:
Но ИТ не владеет складским процессом.
Поэтому автоматизация находится на пересечении бизнеса и инженерии.
Если один из уровней отсутствует, система начинает работать хуже.
Кто такой владелец автоматизации
Не обязательно директор.
И не обязательно руководитель ИТ.
Владелец автоматизации — это человек, который заинтересован в изменении конкретного бизнес-результата и имеет полномочия принимать решения по процессу.
Например:
— для автоматизации склада;
— для автоматизации обработки заявок;
— для финансового контура;
— для производственного процесса;
— для сквозного процесса между подразделениями.
Его задача — не писать техническое задание.
Его задача — отвечать на вопрос:
«Зачем мы вообще это делаем и какой результат должны получить?»
Почему нельзя отдать автоматизацию одному сотруднику
Иногда в компании появляется человек, который становится «главным по системе».
Он аккумулирует всю экспертизу:
Пока он работает — всё нормально. А потом:
Это называется не автоматизацией, а персональной зависимостью от носителя знаний.
Хорошая система должна быть устроена так, чтобы критические знания находились не только в голове одного сотрудника.
Но и назначать «ответственным ИТ» неправильно
ИТ может отвечать за техническую часть:
Но ИТ не должно самостоятельно решать, как должен работать бизнес-процесс, если владельцем процесса является другое подразделение.
Например, система может идеально автоматически проводить заказ.
Но если бизнес-процесс изначально содержит барьеры и требует пяти ненужных согласований, ИТ не устранит эту проблему одним программным кодом.
Получится:
автоматизированная неэффективность.
Что происходит, когда бизнес сам ставит технические задачи
Обратная крайность тоже опасна.
Руководитель может сказать:
Но бот — это не бизнес-задача.
Настоящая задача может звучать совершенно иначе:
И тогда после анализа может оказаться, что бот вообще не нужен. Возможно, правильнее:
Поэтому бизнес должен формулировать результат и проблему, а не диктовать технологию.
Кто за что отвечает
Удобнее всего разделить ответственность на несколько уровней.
Распределение зон ответственности на этапах жизненного цикла:
Последняя строка особенно важна.
Разработчик может отвечать за работоспособность и архитектуру самой системы.
Но за то, что автоматизация принесла бизнесу результат, должен отвечать владелец процесса.
Почему «сделали по ТЗ» ещё не означает успех
Представим проект. В техническом задании написано:
Но на практике: менеджеры продолжают вручную переносить часть информации, потому что форма не содержит необходимых данных.
Вот почему критерии успеха должны выглядеть не только формально («Функция работает»), но и через бизнес-метрики:
Время обработки заявки сократилось с 15 минут до 3 минут.
95% обращений автоматически маршрутизируются без ручного распределения.
Количество ручных операций снизилось на 70%.
У автоматизации должен быть измеримый результат
До начала проекта полезно зафиксировать хотя бы несколько показателей.
Например:
Теперь проект можно оценивать не по количеству реализованных экранов.
А по изменению процесса.
Это принципиальная разница.
Кто принимает решения, если участники не согласны
Это один из самых важных вопросов.
Представим классическую коллизию:
Кто выбирает?
Если ответа нет, проект начинает зависеть от бесконечных согласований. Поэтому заранее должен существовать уровень принятия решений.
Не каждый вопрос должен доходить до директора.
Но должен существовать человек, который имеет право поставить точку.
Особенно опасна коллективная ответственность
Фраза:
звучит правильно.
На практике она иногда означает: «Никто конкретно не отвечает».
Если проблема возникает, начинается классический пинг-понг:
«Мы так не просили».
«В требованиях этого не было».
«Мы реализовали утверждённое ТЗ».
«А нас вообще никто не спрашивал».
И система оказывается формально выполненной, но фактически неудобной.
У каждой зоны должен быть конкретный владелец.
Что делать с крупными проектами
В больших системах один человек физически не может управлять всем.
Тогда появляется несколько уровней ответственности.
Такая структура позволяет не смешивать разные виды ответственности.
Где нужен руководитель, а где — инженер
Руководитель не должен выбирать технологию только потому, что она популярна.
Инженер не должен самостоятельно решать, какой бизнес-процесс выгоднее компании.
Правильное разделение выглядит примерно так:
• зачем это нужно;
• какой приоритет;
• какой результат успешен.
• какие требования есть;
• какие исключения есть;
• что нужно изменить.
• какая архитектура нужна;
• как связать интеграции;
• как дать надёжность.
• какие проблемы есть каждый день;
• какие сценарии нельзя терять.
Это четыре разных источника знаний.
Почему нельзя проектировать систему только по словам руководителя
И у каждого будет своя картина.
Пример многослойного расхождения:
«Менеджеры слишком долго обрабатывают заявки».
«Мне приходится переносить данные из трёх систем».
«У систем нет нормального обмена данными».
«Можно построить единый контур и убрать ручную передачу».
Все говорят об одной проблеме.
Но видят разные её уровни.
Поэтому:
Хорошая автоматизация начинается не с разработки. Она начинается с совместного понимания процесса.
А если подрядчик внешний?
Здесь появляется ещё один уровень ответственности.
Внешняя команда может отвечать за техническую реализацию контура:
Но подрядчик не может стать владельцем вашего бизнеса.
Он не должен самостоятельно определять внутренние правила:
Подрядчик должен помочь компании принять эти решения и реализовать их технически.
Почему хороший подрядчик иногда спорит с заказчиком
Это может показаться странным.
Но зрелая инженерная команда не должна превращаться в исполнителя любой технической идеи.
«Давайте просто добавим ещё одну кнопку».
«Какую проблему эта кнопка решает?»
Потому что иногда за внешней «кнопкой» скрываются глубокие системные деструкторы:
И тогда правильным решением будет не новая кнопка.
Как понять, что автоматизация управляется правильно
Есть несколько простых признаков.
Есть человек, который отвечает за бизнес-результат
Не «отдел». Не «команда». Конкретный владелец.
Есть понятные показатели
Можно сравнить состояние до и после.
Есть единый источник решений
Понятно, кто определяет приоритеты и разрешает спорные вопросы.
Бизнес участвует в приёмке
Система принимается не только по техническому ТЗ.
Команда отвечает за инженерное качество
Архитектура, безопасность, производительность и надёжность не определяются голосованием пользователей.
Знания не принадлежат одному сотруднику
Есть документация, доступы, описание архитектуры и понятная передача знаний.
Что происходит, если всё это отсутствует
Сценарий обычно развивается постепенно.
Самое неприятное — в конце компания может решить:
«Автоматизация у нас не работает».
Хотя проблема была совершенно не в технологии.
Проблема была в управлении проектом.
Автоматизация должна иметь не одного ответственного, а одного владельца результата
Это, пожалуй, главное различие.
Ответственных много.
Но владелец результата — один.
У него не обязательно есть все технические знания. И не должно быть.
Его задача — держать связь между всеми слоями контура:
А рядом должны находиться специалисты, каждый из которых отвечает за свою область.
Зрелая модель ответственности
В хорошо организованном проекте цепочка замыкается в управляемый контур:
Именно последняя стрелка важна. После запуска проект не должен исчезать.
Необходимо провести финальную валидацию контура:
Если нет — выяснить почему и изменить систему или сам процесс.
Итог
Автоматизация — это совместная работа бизнеса, аналитиков, ИТ и инженеров.
Но это не означает размытую ответственность.
Должен отвечать за то, что именно и зачем меняется.
Отвечает за то, как это изменение реализовано технически.
Отвечают за стабильность, безопасность и работу в рантайме.
Отвечают за обратную связь о реальном процессе на практике.
А конкретный владелец процесса должен отвечать за главное:
И именно с этого начинается зрелая автоматизация — не с выбора платформы, не с написания ТЗ и даже не с разработки.
С понимания того, кто отвечает за изменение бизнеса после того, как система будет запущена.
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870