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