Меня зовут Ирина Гертовская. Много лет я анализирую и проектирую, внедряю и поддерживаю, развиваю крупные ИТ‑системы, как аналитиком, разработчиком, так и руководителем аналитиков и разработчиков, руководителем проектами.

Мой опыт показывает: недостаточно разработать, важно и внедрить. И это относится не только к системе, но и ее изменению. И внедрить даже небольшое изменение иногда не так просто, как кажется на первый взгляд. За формулировкой «просто добавьте проверку» могут скрываться изменения сразу в нескольких частях системы, корректировка данных и процессов, обучение пользователей и подготовка плана Б (что делать, если что‑то пойдет не так и потребуется откатить запуск).

В этой статье я разберу такой случай на примере небольшой доработки в уже эксплуатируемой ERP‑системе крупной компании. Задача выглядела просто: перед отправкой платежа проверять, не превышен ли установленный лимит. Однако быстро выяснилось, что одной проверки недостаточно.

1. Исходные условия и запрос на изменение

В компании работают производственные подразделения с отдельными бюджетами. Ранее платёжные документы создавались в ERP‑системе и направлялись в банк без контроля расходов по подразделениям. Поэтому фактические расходы могли значительно превышать запланированные.

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

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

2. Обследование

На первый взгляд задача выглядит простой: сравнить сумму платежа с остатком и при необходимости заблокировать документ. Но появились вопросы: кто устанавливает лимиты? можно ли их менять? что делать с заблокированным документом? и так далее. И аналитик провел обследование, которое ответило на эти и другие вопросы команды. Результаты ниже.

2.1 Соответствие запроса бизнес‑требованиям

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

Однако расходы подразделений стали превышать запланированные и на какие‑то расходы производства финансов стало не хватать. В финансовом управлении решили ввести ежемесячные лимиты расходов для каждого подразделения и контролировать эти лимиты.

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

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

1. Корректировать лимиты в течение месяца по представлению подразделения.

2. По результатам 3 месяцев эксплуатации лимитов проанализировать и возможно уточнить решение.

2.2 Уточнение запроса на изменение

В процессе обследования и с инициатором запроса часть вопросов была решена, но часть осталось нерешенными.

Согласовано

Ввод и корректировка лимитов

• Лимитирование (начальное и изменение лимита на месяц) выполняется финансовым управлением по представлению подразделения.

• Лимиты вводит/корректирует сотрудник финансового управления. На первом этапе эксплуатации (условно — 3 месяца) ввод/корректировка лимитов выполняется в экранной форме в основном модуле системы.

• Корректировка лимитов нужна. Информация о корректировке (история изменений) нужна.

• После корректировки лимита подразделения перерасчет заблокированных ранее платежей не нужен.

• Разблокирование платежей не требуется.

Роль Управляющего лимитами

• Нужна отдельная роль пользователя, который будет управлять (вводить/корректировать) лимиты.

• Будут определены профили пользователей, имеющие права на назначение роли Управляющего лимитами.

Лимитирование расходов для подразделения

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

2. При формировании платежа система предупреждает пользователя об остатке лимита подразделения.

3. При увеличении лимита подразделение формирует новый платеж взамен заблокированного.

4. По запросу пользователя система информирует об использовании и остатке лимитов подразделения.

Не решено

1. При увеличении лимита следует ли пересчитывать заблокированные платежи?

2. Нужно ли помечать окончательную отработку заблокированных платежей? Интересно ли, отклонен платеж или продублирован и в дальнейшем исполнен?

2.3. Нефункциональные требования

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

Требуется изменение ролевой модели. Появилась новая роль — Управляющий лимитами.

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

С DevOps‑командой и архитектором обсудили частоту резервного копирования и возможность более частого копирования для обеспечения бесперебойного проведения платежей. По результатам согласовали с инициатором изменения — на период пробной эксплуатации частоту резервного копирования оставляем без изменений.

2.4 Итоги обследования

Итак, в результате обследования было выявлено, что требуется:

1. Добавление нового процесса (Ведение лимитов расходов подразделений на месяц).

2. Изменение процесса (Формирование и проведение платежей).

3. Изменение структуры данных, изменение статусной модели платежей.

4. Добавление расчета превышения лимита и принятия решения о блокировании платежа.

5. Доработка ПО.

6. Изменение регламентов работ пользователей и пользовательской документации.

Чтобы не сорвать финансирование критических производств совместно с финансовым управлением решили внедрять не во все подразделения сразу, а выделить 3 пилотных подразделения и отработать на них в течении 3 месяцев (условно), а затем распространить на всю компанию. После пилотирования — уточнение по результатам и открытым вопросам, затем доработка и тиражирование на другие подразделения.

3. Подготовка внедрения

Опустим процессы проектирования, разработки и тестирования и перейдем к подготовке внедрения. Рассмотрим:

• пилотирование,

• методика внедрения,

• проверка бизнес‑процессов и функций ПО,

• документирование и обучение,

• информирование о внедрении,

• план Б,

• внедрение в пилоте,

• тиражирование.

3.1 Пилотирование

Пилотирование — это контролируемое «боевое» внедрение на ограниченном участке, где мы можем безопасно ловить все ляпы. Цель пилотирования:

• успешно запустить систему в одном выбранном сегменте;

• выявить нестыковки в процессах, данных, интерфейсах, ролях и так далее;

• доработать систему и методику внедрения, прежде чем идти «вширь».

Относимся к пилоту как к проекту в проекте: у него есть задачи, сроки, ответственные, критерии успеха и собственные артефакты (чек‑листы, методика, скрипты, отчёты по ошибкам).

Выбор пилотных подразделений

Мы выбрали пилотные подразделения, отбирая:

• Подразделения с типовыми операциями. Не берем уникальный «зоопарк» бизнес‑процессов. Мы хотим отладить типовой сценарий, который потом можно размножать.

• Благорасположение и готовность к сотрудничеству. В пилотных подразделениях должны быть люди, которые хотят получить пользу от изменений в системе, у которых «горят глаза». Методисты, технологи, исполнители операций, с которыми можно договариваться и работать напрямую.

• Достаточная «похожесть» на остальные площадки. Если пилот уникален, вы его героически внедрите, а потом на остальных придётся всё делать заново.

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

3.2 Методика внедрения

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

В нашем случае корректировку разработчики реализовали в ПО, изменение поставлялось в дистрибутиве. Поэтому при внедрении мы лишь проверяем эти изменения.

1. Список справочников и сущностей, которые корректировались. Мы перечислили:

   • внутренний справочник Роли пользователей — добавлена роль Управляющий лимитами,

   • внутренний справочник Статусы платежа — добавлен статус Заблокирован,

   • добавление новой сущности Лимиты подразделений.

2. Контрольные метрики. Сколько записей было, сколько стало; почему число может меняться (агрегации, денормализация, расщепление записей и так далее). У нас все просто: в каждый из справочников добавлено по одной записи и добавлена сущность.

3. Описание проверок: что и как мы сравниваем «до» и «после»; допуски по расхождениям; примеры типичных отличий. Мы описали проверки наличия и корректировки справочников и сущности, указанные выше.

4. Описание вспомогательных инструментов. Скрипты, отчёты, выборки которыми мы корректируем и проверяем. Эти проверки и скрипты задокументированы и доступны тем, кто будет внедрять систему «в полях».

3.3 Проверка бизнес‑процессов и функций системы

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

1. БП Управление лимитами — ввод и корректировка лимитов подразделений на месяц.

2. БП Проведение платежей в разных условиях:

   • платеж не превышает сумму лимита (после ввода и после корректировки лимита);

   • платеж превышает сумму лимита (после ввода и после корректировки лимита),

   • тоже самое, когда платежей несколько.

3. Проверяем:

   • правильный расчет блокировки и отсутствия блокировки платежей,

   • корректность предупреждений о лимитах,

   • корректность сообщений об ошибках,

   • корректность отчетов.

4. Убеждаемся в том, что работают:

   Функции основной функциональности:

   • ввод/корректировка лимитов подразделений,

   • история ввода/корректировки лимитов,

   • контроль платежей на не превышение лимита,

   • блокирование и информирование о блокировании платежа с указанием причины блокировки,

   • отчеты о блокировании и остатках лимитов.

   Обеспечивающая функциональность:

   • определена роль Управляющий лимитами,

   • реализовано назначение/снятие на роль Управляющего лимитами.

   Дополнительная функциональность (для службы сопровождения):

   • наличие корректных сообщений об ошибках,

   • логирование действий пользователей в части ввода/корректировки лимитов,

   • логирование блокировки платежей,

   • логирование назначений /снятий роли пользователя ввода /корректировки лимитов..

3.4 Документирование и обучение

Проверяем, что:

1. Добавлен регламент ведения лимитов (ввод и корректировки).

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

3. Измененная документация доведена до пользователей.

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

3.5 Информирование о внедрении

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

В случае отката внедрения (выполнения плана Б) информируем всех участников внедрения.

3.6 План Б

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

Если изменение значимо для выполнения основных или критичных функций производства следует предусмотреть План Б: что будем делать, чтобы откатить изменение, если вдруг что‑то пойдет не так. В нашем случае решили, что достаточно:

1. Копирование, выполненное перед установкой патча.

2. Восстановление из копии, выполненное перед самым накатываем патча.

3. Сообщение пользователям о работе в предыдущем режиме.

После восстановления проверить:

• справочник Роли пользователей — отсутствует роль Управляющий лимитами,

• справочник Статусы платежа — отсутствует статус Заблокирован,

• отсутствует сущность Лимиты подразделений,

• установлен предыдущий патч ПО.

План Б мы прорабатывали и тестировали совместно с DevOps‑командой. Как правило, они хорошо знают, чтои как копировать и восстанавливать. Но участие аналитика тоже нужно, так как понимание бизнеса снизит риски.

План Б был протестирован и его применение описано в методике внедрения.

4. Внедрение

4.1 Права доступа

Одна из самых частых ошибок при внедрении — забытая или не настроенная ролевая модель. На этапе внедрения об этом легко забываем, особенно когда настройки прав перекладывают на админов, DevOps‑команду, отдельных администраторов пользователей.

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

4.2 Внедрение в пилотных подразделениях

На пилоте система часто ещё «сырая», поэтому: часть операций «выносим на руках»: консультируем, проверяем силами аналитика, подключаем разработчиков и DevOps‑ов при необходимости.

Ключевые моменты

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

4.3 Тиражирование

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

Финансовое управление приняло решения по открытым вопросам:

1. При увеличении лимита следует ли пересчитывать заблокированные платежи? Решение: пересчитывать заблокированные платежи не требуется.

2. Нужно ли помечать окончательную отработку заблокированных платежей? Интересно ли, отклонен платеж или продублирован и в дальнейшем исполнен? Решение: следует отмечать окончательную отработку заблокированных платежей. Вопрос как именно отмечать передан на дальнейшую проработку аналитику.

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

5. Выводы

Внедрение — значительный процесс жизненного цикла разработки ИТ‑системы. К сожалению, встречаются ситуации, когда система не эксплуатируется или эксплуатируется со значительными недостатками и нареканиями из‑за неуспешного внедрения.

Фраза «тут работы на пять минут» часто становится ловушкой как для заказчика, так и для самой команды. На примере простой проверки лимитов видно, как одиночное локальное условие обрастает каскадом связанных процессов: от управления правами доступа и переработки пользовательских сценариев до пилотирования на отдельных подразделениях и подготовки сценариев отката.

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

Замечания и уточнения приветствуются. Успешных вам внедрений!

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

• 4 августа, 20:00. «Как аналитику работать с рисками». Записаться

• 5 августа, 20:00. «Влияние нефункциональных требований на архитектуру». Записаться

• 6 августа, 20:00. «Пользовательские сценарии (Use Cases) на реальном примере: от бизнес‑требования заказчика до формулирования задачи для разработчика». Записаться