Работа с заявкой на доработку ИТ продукта

Что это за процесс

Процесс описывает внутреннюю службу поддержки и развития ИТ-продуктов, реагируя на потребности других подразделений компании. Цикл начинается со стартового события «Возникла потребность доработать ИТ продукт» и запуска бизнес-процесса заявки. Завершается схема одним из финальных событий: успешным внедрением и оценкой доработки, её отклонением или отклонением самой заявки на ранних этапах.

Как читать эту схему

Схема построена на последовательном прохождении этапов с проверками через эксклюзивные шлюзы. Например, шлюз «Проверить есть ли изменения в бизнес процессе?» имеет ветки «да» и «нет», где путь «нет» ведет к согласованию доработки, а «да» — к дальнейшим действиям. Шлюз «Решить о необходимости подготовки ТЗ» также раздваивает поток: если ответ «да», процесс переходит к подготовке ТЗ, если «нет» — заявка может быть отклонена. Параллельные шлюзы используются для одновременного выполнения задач, таких как тестирование и подготовка документации. Событие-таймер «дней использования» контролирует период оценки популярности доработки после её внедрения.

Кому подойдёт

Эта схема актуальна для ИТ-отделов и владельцев продуктов в компаниях с развитой внутренней сервисной моделью. Основные участники — роль 1.13 (вероятно, менеджер процесса или аналитик), которая координирует согласования, подготовку ТЭО и ТЗ, а также заказчики из других подразделений, тестирующие решения.

Как адаптировать под свою компанию

• Замените абстрактную роль 1.13 на конкретные должности вашей компании (например, «Руководитель ИТ-проекта» или «Бизнес-аналитик»).
• Настройте критерии для шлюза «Проверить есть ли изменения в бизнес процессе?», чтобы автоматизировать решение о необходимости обновления репозитория.
• Определите четкие сроки для события-таймера «дней использования», чтобы метрики популярности собирались за фиксированный период.
• Интегрируйте документы «Технико-экономическое обоснование» и «Требования к ТЗ» с вашими внутренними шаблонами и системами документооборота.
• Уточните условия ветки «нет» → «согласовано?» в шлюзах согласования, чтобы избежать циклических возвратов без четких причин.

Типичные ошибки

Частая ошибка — игнорирование ветки «Заявка отклонена» на ранних этапах, что приводит к накоплению неактуальных задач. Другая проблема — отсутствие четкого разделения между этапами «Согласовать доработку» и «Согласовать ТЗ», что создает путаницу в ответственности. Также часто забывают про этап «Получить статистику/метрики использования», считая внедрение завершающим шагом, хотя оценка эффективности критична для будущих доработок.