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