Как проходит
автоматизация.

Начинаем с процесса, который можно увидеть.

Автоматизация начинается с разговора о работе: где теряются заявки, кто ждёт согласования, какие сведения приходится переносить руками.

Сначала выбираем участок, у которого есть понятный владелец и наблюдаемый результат. Например, обращение клиента должно превратиться в заказ, попасть исполнителю и вернуться в виде подтверждения выполненной работы. Разбираем, кто участвует в этом пути и что каждый человек делает сейчас.

На первой встрече обсуждаем цель, действующие системы, ограничения по доступам и данные, которые понадобятся. Уточняем, что уже пытались изменить и почему это не прижилось. Назначаем человека со стороны компании, который сможет отвечать на вопросы и согласовывать решения.

Аудит: разбираемся, как работа устроена сейчас.

Слушаем сотрудников, смотрим реальные операции и сопоставляем их с тем, что компания считает своим процессом.

Интервью с руководителем показывает ожидания. Наблюдение за рабочей сменой показывает, где человек переключается между чатами, таблицами и программами. Для анализа берём несколько обычных случаев и исключения: отмену, повторное обращение, ошибку в документе, отсутствие ответственного.

Отдельно составляем карту программ и данных. Где хранится актуальная карточка клиента? В какой системе учитывается оплата? Кто может исправить заказ? Как сведения попадают из одной системы в другую? Проверяем доступные способы подключения и ограничения поставщиков.

Предлагаем решения и сравниваем последствия.

Для одной задачи может подойти настройка текущей системы, готовый инструмент или собственная разработка. Сравниваем варианты на вашем процессе.

У каждого варианта описываем, что изменится для сотрудников, как будут двигаться данные, какие ограничения останутся и кто станет поддерживать решение. Показываем, что можно сделать в первую очередь, а что имеет смысл отложить.

В оценку входят разработка, лицензии, подключение внешних сервисов, перенос данных и сопровождение. Срок и бюджет даём с допущениями: доступы, качество исходных данных, участие сотрудников, возможности существующих программ. Внешний сервис может изменить тариф или способ подключения; такую зависимость отмечаем заранее.

Инженерный консилиум: собираем решение вместе.

Бизнес, разработка, эксплуатация и безопасность рассматривают один процесс с разных сторон. Их разногласия превращаем в решения, которые можно проверить.

Для обсуждения готовим карту процесса, ограничения и несколько вариантов. Представитель компании объясняет рабочие правила. Разработчик оценивает связи между системами. Специалист по эксплуатации смотрит на размещение, восстановление и наблюдение за сбоями. Специалист по безопасности разбирает доступы и возможное злоупотребление функциями. Если нужен ИИ, отдельно рассматриваем качество ответов и обращение с данными.

Состав участников зависит от задачи. В небольшом проекте несколько ролей может выполнять один человек. Когда требуется независимая проверка или отдельная экспертиза, согласуем её участие и объём заранее. Названия ролей здесь описывают ответственность, а не обещают отдельный штатный отдел на каждый проект.

Проектируем будущую работу до написания кода.

Описываем, как будут работать люди и программы после внедрения. Пользовательский путь и устройство системы должны совпасть.

На схеме будущего процесса показываем состояния операции, действия участников и условия перехода. Для заказа это могут быть черновик, согласование, выполнение, завершение и отмена. Статус оплаты рассматриваем отдельно: выполненная работа сама по себе не подтверждает поступление денег.

Составляем модель данных и определяем, какая система отвечает за каждую сущность. Продумываем, как новые функции войдут в привычные рабочие экраны. Делаем прототип важных действий и проверяем его вместе с будущими пользователями: можно ли понять статус, исправить ошибку и продолжить прерванную работу.

Соединяем системы так, чтобы видеть ошибки.

Передача заявки в CRM выглядит просто, пока внешний сервис не отвечает или отправитель не присылает одно событие дважды.

Для каждого подключения фиксируем, какие данные передаются, кто их принимает и как подтверждается результат. Проверяем способы авторизации, ограничения частоты запросов и формат ошибок. Если документации не хватает, сначала делаем небольшой технический эксперимент на согласованных данных.

Продумываем повторную доставку и защиту от дублей. Если ответ не пришёл, система не должна создавать ещё один заказ при каждой попытке. Там, где это возможно, операции получают устойчивый идентификатор. Очередь, история попыток и сверка между системами помогают найти зависшую передачу.

Проследите путь одной заявки.

На учебном примере видно, что автоматизация должна делать при обычной работе, повторной отправке и сбое.

Выберите сценарий и запустите прохождение. Названия систем и правила условные. В реальном проекте они определяются после аудита.

Разрабатываем по рабочим сценариям.

Первая версия должна пройти один процесс от начала до конца. Так команда раньше замечает ошибки в правилах и подключениях.

Разбиваем работу на небольшие законченные части: например, приём заявки, назначение исполнителя и подтверждение результата. Для каждой части есть описание, критерии проверки и демонстрация заказчику. Обратная связь сотрудников возвращается в список задач.

Код и настройки храним с историей изменений. Изменения проходят проверку другим участником, когда это предусмотрено составом команды. Подключения и перенос данных сначала проверяем в отдельной среде; рабочие доступы не копируем в документы и переписку.

Новые пожелания обсуждаем вместе с их последствиями для сроков и бюджета. В журнале решений отмечаем, что меняется, почему и какой ранее согласованный сценарий это затрагивает. Заказчик видит готовность по работающим функциям и результатам проверок.

Безопасность проверяем на протяжении проекта.

Доступ к заказам, документам и операциям нужно ограничить ещё при проектировании. Перед запуском проверяем, что ограничения действительно работают.

Начинаем с модели рисков: какие сведения чувствительны, кто может действовать в системе и что произойдёт при ошибке или злоупотреблении. Определяем границы доверия между пользователями, внутренними сервисами и внешними подключениями. По этой модели составляем программу проверок.

Аудит безопасности охватывает согласованную область проекта. Разбор кода, настроек и прав дополняет проверки работающей системы. Если требуется тестирование с имитацией атак, заранее определяем окружение, допустимые действия, время работ и порядок остановки. Результаты одной проверки не означают, что вся инфраструктура компании исследована.

При составлении требований можно использовать OWASP ASVS, а для организации безопасной разработки NIST SSDF. Объём и применимость требований определяем для конкретного проекта; использование этих материалов само по себе не означает сертификацию.

Приёмка проверяет работу целиком.

Успешное открытие экранов недостаточно. Проверяем, проходит ли операция все этапы и сохраняются ли данные при ошибках.

Программу приёмки готовим вместе с требованиями. В неё входят обычные действия, граничные случаи и сценарии отказа. Сотрудники проверяют, можно ли выполнять ежедневную работу, а инженерная команда проверяет поведение системы и обмен данными.

Переносим данные и готовим сотрудников.

Перед переходом нужно понять, какие сведения переносить, как проверить их полноту и когда прекратить изменения в старой системе.

Для переноса готовим правила преобразования полей, обработки дублей и связей между записями. Делаем пробную загрузку и сверяем результат. Записи, которые не удалось перенести, попадают в отдельный перечень с причиной и порядком исправления.

Согласуем окно перехода, ответственность за подтверждение и порядок отката. Для длительного переноса определяем, как учитывать изменения, сделанные после исходной выгрузки. Старые данные сохраняем на согласованный срок и ограничиваем доступ к архиву.

Обучение строим на реальных действиях каждой роли: принять обращение, исправить ошибку, завершить заказ, найти зависшую операцию. Руководителю показываем, как оценивать результат; администратору, как выдавать доступы и обращаться за помощью.

Запускаем на ограниченном участке и наблюдаем.

Пилот позволяет проверить систему в повседневной работе, пока объём операций ещё можно контролировать.

Выбираем группу сотрудников, филиал или категорию заказов. Определяем срок наблюдения и показатели, по которым будем оценивать результат. Участники знают, где сообщать о проблемах и как работать, если новое подключение временно недоступно.

Во время пилота смотрим на завершённые операции, ошибки, очередь ожидания и расхождения данных. Собираем обратную связь и сравниваем результат с исходным состоянием. Если проблема связана с рабочим правилом, обсуждаем его с владельцем процесса.

Передаём систему вместе со знаниями о ней.

Компания должна понимать, что у неё работает, кто за это отвечает и как действовать при сбое.

Состав передачи определяем в договорённостях по проекту. Для собственной разработки отдельно фиксируем права на код и порядок предоставления репозитория. Для готовых сервисов описываем владельцев аккаунтов, лицензии и ограничения доступа.

• Описание процесса и согласованных бизнес-правил.
• Схема компонентов, подключений и размещения.
• Код, настройки и порядок выпуска версии в согласованном объёме.
• Инструкции сотрудникам и администратору.
• Протокол приёмки и отчёт по безопасности с открытыми ограничениями.
• Порядок резервного копирования, восстановления и обработки инцидентов.
• Реестр доступов и ответственных, условия поддержки и внешних расходов.

Пароли и ключи передаём через согласованный защищённый канал. После передачи пересматриваем временные доступы участников проекта. Материалы должны позволять обслуживать систему без зависимости от памяти одного разработчика.

После запуска следим за работой и развиваем её.

Процессы меняются. Поддержка помогает заметить сбой, восстановить работу и оценить следующую доработку.

Условия сопровождения обсуждаем отдельно: время работы поддержки, способы обращения, приоритеты, сроки реакции и границы ответственности. Ответственность за внешний сервис или инфраструктуру должна быть понятна обеим сторонам.

Настраиваем согласованные признаки проблем: зависшие операции, ошибки подключения, рост очереди, истечение доступов и неудачное создание копии. У уведомления есть получатель и ожидаемое действие. Проверяем не только появление сигнала, но и его прекращение после восстановления.

Для инцидента фиксируем влияние, временный способ работы и порядок восстановления. После устранения разбираем причину и необходимые изменения. Обновления и новые интеграции проходят проверку до выпуска.

Периодически возвращаемся к исходной цели. Если сотрудники продолжают вести параллельные таблицы, это повод разобраться в причинах. Дальнейшие улучшения выбираем по наблюдаемым проблемам и согласованному эффекту.

Где в процессе может пригодиться ИИ.

ИИ уместен там, где нужно работать с неструктурированной информацией: читать документ, находить сведения или готовить черновик.

Такую часть проекта оцениваем отдельно. Определяем допустимые ошибки, источники информации и действия, которые требуют проверки человеком. Сначала проверяем качество на рабочих примерах, затем решаем, имеет ли смысл включать помощника в процесс.

Для подключения уточняем, куда передаются сведения, как ограничивается доступ и что сохраняется в журнале. Проверяем попытки заставить помощника обойти инструкции или раскрыть лишние данные. Действия с деньгами, правами и документами получают отдельные правила подтверждения.

Стоимость использования и скорость ответа могут влиять на работу. На пилоте наблюдаем эти параметры вместе с качеством. Если для задачи достаточно обычного правила или поиска по точному полю, рассматриваем и такой вариант.

Что стоит обсудить до начала.

Несколько вопросов, которые помогают оценить масштаб и подготовить проект.