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