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