Задача
Часть действий существовала только в практике сотрудников и нигде не была записана. Часть была записана, но в регламентах, которые давно отстали от реальной работы. Решения по технологическим проектам хранились разрозненно — в почте, в презентациях, в протоколах встреч.
Из-за этого три базовых вопроса не имели быстрого ответа. Какой порядок работы действует сейчас — тот, что в регламенте, или тот, по которому работают? Где заканчивается зона ответственности одного подразделения и начинается зона другого? Что стало с изменением, которое обсуждали полгода назад, — его приняли, отклонили или про него забыли?
Пока на эти вопросы отвечали отдельные люди по памяти, документация не была активом. Нужна была общая система описания, согласования и дальнейшего обновления.
Решение
Реестр с владельцем и версией. Прежде чем моделировать, собрали имеющиеся регламенты, инструкции, проектные документы, схемы и шаблоны, а затем провели интервью и рабочие сессии с участниками процессов. На этой основе построили реестр процессов, документов, ролей и терминов, где у каждой сущности есть владелец и актуальная версия. Дальше любой вопрос об актуальности адресовался реестру, а не памяти сотрудника.
As-Is в четырёх нотациях. Основные процессы моделировались в BPMN и IDEF0, потоки данных — в DFD, взаимодействие систем и участников — подходящими UML-диаграммами. Модель описывала фактическое состояние, а не желаемое.
Разбор разрывов. На готовых моделях отмечали пять типов проблем: дублирование операций, ручные передачи между системами и людьми, отсутствующие контрольные точки, неясную ответственность и расхождения между регламентом и фактической работой. Такая разметка превращала схему из иллюстрации в инструмент — было видно не «как устроено», а «где именно больно».
To-Be вместе с владельцами процессов. Целевые модели проектировались не кабинетно: убирали лишние шаги, назначали роли, определяли входы, результаты, точки контроля и правила обработки исключений вместе с теми, кто за процесс отвечает. Диаграммы использовались как рабочий инструмент согласования между подразделениями — спор о границе ответственности решался на схеме, а не в переписке.
Ответственность и трассировка. Для ответственности применялись RACI-матрицы. Для требований выстраивалась цепочка трассировки: бизнес-задача → процесс → регламент → системная функция → проверяемый результат. По этой цепочке можно пройти в обе стороны — от бизнес-цели к конкретной функции и обратно от функции к причине, по которой она существует.
Единый стандарт. Все материалы перевели в общую форму: структура документа, обязательные разделы, нумерация, словарь, правила именования, статусы, версии и порядок согласования. В комплект вошли каталог процессов и глоссарий, модели As-Is и To-Be с границами процессов, регламенты подразделений, рабочие инструкции и описания ролей, требования и описания технологических проектов, интерфейсов и потоков данных, RACI-матрицы, таблицы трассировки, шаблоны и правила управления версиями.
Журнал решений. Предложения, которые не были приняты, не исчезали: они сохранялись вместе с обоснованием и принятым решением. Это давало возможность позже восстановить контекст и не возвращаться к уже разобранным вариантам без новых оснований — обычно именно эта часть теряется сразу после встречи.
Результат
Siemens получил согласованную модель текущих и целевых процессов и единый комплект регламентов с правилами дальнейшего ведения.
У каждого процесса появились понятные границы, владелец, роли, входы, результаты и связь с проектными требованиями. Документы разных технологических проектов стали сопоставимыми: одинаковая структура и общий словарь позволяют читать незнакомый проект без переводчика из соседнего отдела и поддерживать его силами другой команды.
История утверждённых и отклонённых изменений сохранила причины решений. Документация перестала быть набором независимых файлов и стала общей системой знаний, у которой есть владельцы, версии и понятный порядок обновления.
