Извлечение реальных бизнес-процессов в проектном бюро КМ/КЖ (35–100 человек): практическое и методологическое руководство
0. Главная идея
В любой организации одновременно сосуществуют минимум четыре разные «версии» процесса:
- espoused theory — то, что говорит руководитель в интервью и что записано в регламентах
- theory-in-use — то, что реально делается
- work-as-imagined менеджмента — упрощённая модель в голове ГИПа/РП
- work-as-done — фактическое поведение инженеров-исполнителей со всеми обходными путями, неформальными согласованиями и «костылями»
Задача исследователя — не выбрать одну из версий как «правильную», а сделать дельту между ними наблюдаемой: именно дельта показывает, где находятся узкие места, риски качества и точки приложения улучшений.
Эта работа в проектном бюро КМ/КЖ имеет ряд особенностей: цикл ПД→РД длинный (месяцы), труд преимущественно когнитивный (расчёт, моделирование, согласование), а ключевые артефакты (CAD/BIM-модели, замечания экспертизы, переписка с заказчиком — ПИК/Самолёт) сами являются богатым event-log’ом, который большинство руководителей не используют.
1. Проблематика асимметрии восприятия
1.1. Почему у уровней разная картина
- «Пасть зрения» роли (Hollnagel): чем дальше человек от «sharp end» — от непосредственной работы, — тем более идеализированной и устаревшей становится его картина работы. ГИП в кабинете видит план-график; инженер видит, что в плане не учтено двое суток на пересчёт стыка после замечания заказчика.
- Защитные рутины (Argyris): люди системно скрывают информацию, которая угрожает им или ставит в неловкое положение. На уровне Model I theory-in-use доминируют односторонний контроль, выигрыш, рационализация — поэтому интервью с менеджером даёт espoused theory, а не реальность.
- Информационные пузыри иерархии: сводки фильтруются «вверх» — об отставаниях и переделках сообщается мягче, чем они есть. Это «silent killers» Beer & Eisenstat — стратегия проваливается, потому что низы не доносят неудобной правды до верхов.
- Front-stage / back-stage (Goffman): сотрудники ведут себя по-разному при наблюдателе и без него. То, что вы увидите на «открытом» совещании, — спектакль; реальная координация идёт в личке Telegram и в коридоре у кофемашины.
- Когнитивные искажения исследователя и информантов: ретроспективное искажение, availability heuristic, social desirability bias.
1.2. Типовые расхождения в проектном бюро КМ/КЖ
| Уровень | Картина мира | Что реально |
|---|---|---|
| Руководитель бюро | «У нас процесс по ISO: ТЗ → расчёт → КМ → проверка ГИПа → выпуск → авторнадзор» | 30–50% задач идут параллельно, проверка ГИПа сжата до 1 часа за день до сдачи |
| ГИП / РП | «Lencon Tracker отражает статусы корпусов» | Инженеры ставят статусы постфактум или «оптимистично», истинный статус — в DWG mtime |
| Инженер КМ | «Я делаю по техзаданию» | 40% времени — переделки после поздних правок АР, ожидание ответа смежников, ручная сверка с КЖ |
| Реальность | — | Критический путь идёт через 2–3 «незаменимых» инженеров, которые тащат на себе согласования и держат знание в голове |
1.3. Академический фрейм
- Argyris & Schön (1974): разрыв между espoused theory (что мы говорим) и theory-in-use (как мы действуем). Single-loop learning исправляет действие; double-loop — пересматривает governing values.
- Hollnagel (Safety-II, FRAM): work-as-imagined ≠ work-as-done не из-за лени, а потому что реальная работа требует постоянной адаптации к изменчивым условиям. Задача — не «закрыть» этот зазор, а понять, какие адаптации (workarounds) делают систему устойчивой.
- Mintzberg (1973, 2009): структурированное наблюдение показало, что план/контроль/координация — идеализация; реальная работа фрагментарна, реактивна, разговорна.
- Snowden (Cynefin): проектирование КМ/КЖ — смесь Complicated (расчёты по СП) и Complex (согласования, экспертиза, авторский надзор). В Complex-зоне процессы нельзя «описать» сверху — их можно только probe через микро-нарративы.
- Edmondson: без psychological safety люди не сообщают об ошибках и обходных путях — а именно они и есть real process.
- Latour (ANT): «follow the actors» — реальный процесс идёт не там, где организационная схема, а там, где движутся артефакты (DWG, RVT, замечания) и где они трансформируются.
2. Методы извлечения «задекларированных» процессов (быстро, для контраста)
Это базовая линия, от которой будем мерить дельту. Делается в первую неделю, занимает 3–5 дней.
- Интервью с собственником/директором (60–90 мин): «Опишите ваш процесс выпуска РД от получения ТЗ до сдачи». Записать дословно.
- Сбор регламентов: должностные инструкции, СТО организации, ISO 9001 process maps, договорные шаблоны, RACI, регламент работы с Lencon Tracker.
- Структурированный опросник по ГОСТ 21.501 / Постановление 87: сравнение «что должно быть по нормам» с тем, как описано внутри.
- BPMN «as-designed» в Camunda Modeler / Bizagi: рисуется по интервью с руководителем. Это не реальность — это гипотеза, которую мы пойдём опровергать.
Артефакт: «BPMN-Declared v0» + «Перечень декларируемых правил» (10–20 утверждений вида «Расчёт всегда верифицируется ГИПом до выпуска»). К каждому утверждению — гипотеза о том, как это можно проверить эмпирически.
3. Методы извлечения реальных процессов (детально)
3.1. Process Mining
Суть (van der Aalst): из event-log’а — таблицы (Case ID, Activity, Timestamp, Resource) — алгоритмы (Alpha, Inductive Miner, Heuristics Miner) восстанавливают фактическую модель процесса, потом сравниваются с моделью «as-designed» (conformance checking). Качество модели — четыре метрики: fitness, precision, generalization, simplicity.
Что является event-log’ом в проектном бюро 35–100 человек:
| Источник | Тип события | Case ID |
|---|---|---|
| Lencon Tracker | смена статуса корпуса/этапа, назначение исполнителя | Корпус × Раздел |
| Файловая система / NAS | save/modify DWG, RVT, DOCX | Имя файла или папка корпуса |
| Git/SVN/Vault для CAD | commit, branch, merge | Файл модели |
| BIM 360 / Revizto / Trimble Connect | issue created/closed, clash detected, model published | Issue ID, Model ID |
| Корпоративный email (метаданные) | отправлено/получено письмо | Subject thread + проект |
| СЭД (Directum, 1С-Документооборот) | согласование, подпись, отправка | Документ |
| Helpdesk / задачник | смена статуса задачи | Issue |
| Корпоративный Telegram | сообщение в чате проекта | Channel |
Инструменты для размера 35–100 человек:
- Disco (Fluxicon) — самое простое; лицензия около €1–2K/год, бесплатный academic. За 5 минут получаешь фактическую карту процесса.
- PM4Py (Python) — бесплатно, open-source от Fraunhofer FIT. Позволяет встроить process mining в pipeline (читать логи из Lencon → строить модель → сравнивать с эталоном еженедельно).
- Apromore Community Edition — open-source с UI; хорошо для conformance checking.
- ProM — академический «швейцарский нож», много плагинов.
- ❌ Celonis — избыточен для 35–100 человек: десятки тысяч евро, рассчитан на ERP-масштаб.
Что можно увидеть в первой же модели:
- Реальный средний цикл «ТЗ → выпуск» против планового
- Доля кейсов с переделкой (loop) и количество итераций
- Где скапливается work-in-progress (узкое горлышко: обычно проверка ГИПом или согласование с заказчиком)
- Кто из инженеров — настоящий узел (max in-degree в social network of handovers)
- Расхождение модели и регламента (например, «выпуск без проверки ГИПом» в 18% случаев)
3.2. Этнография / Shadowing / Gemba
- Выбрать 3–5 фокусных ролей: ГИП, РП, инженер КМ, инженер КЖ, проверяющий.
- Каждого сопровождать 2 полных рабочих дня (с 9:00 до 19:00). Сплошняком, с фиксацией каждой смены деятельности.
- Лог-формат:
время | действие | артефакт | контрагент | переключение причина. - После дня — 30-минутное debrief-интервью.
- Gemba walk по Toyota: руководитель + исследователь молча ходят по местам работы. Правило: спрашивать «почему» 5 раз, не предлагать решений, не оценивать.
Эффект Хоторна: (a) сначала просто присутствовать без записи 1–2 часа; (b) использовать бумагу, не диктофон; (c) одни и те же люди повторно — на 3-й день поведение возвращается к норме; (d) триангулировать с event-log’ом.
3.3. Day-in-the-life и time-and-motion
Сотрудник заполняет таблицу 15-минутных интервалов в течение недели. Категории заранее: «расчёт», «моделирование», «согласование», «ожидание данных», «совещание», «правки после проверки», «прочее».
Типичная находка: 25–40% времени уходит на координацию и ожидание, а не на «инженерную работу», хотя руководители думают наоборот.
3.4. Diary studies / experience sampling
Случайные пинги 4–6 раз в день в течение 2 недель: «Что вы делаете прямо сейчас? Что мешает? Кого ждёте?». Реализуется как простой Telegram-бот. Даёт срез реальной фрагментированности труда без фильтра памяти.
3.5. Contextual Inquiry (Beyer & Holtzblatt)
Четыре принципа: Context (у его монитора), Partnership (мастер–ученик), Interpretation (вслух проговариваю свои интерпретации), Focus (заранее выбранная зона интереса).
Артефакты: sequence model, artifact model, flow model, cultural model, physical model.
3.6. Value Stream Mapping для проектирования
Адаптация Lean: VSM для knowledge work показывает не материальный, а информационный поток.
- Выбрать «образцовый» (но реальный) проект — например, КМ корпуса №3.
- Расположить все шаги от запроса ТЗ до подписания авторнадзорного журнала.
- Для каждого шага: Process Time (чистая работа) и Lead Time (календарь). Соотношение PT/LT в проектировании обычно 5–20% — остальное это ожидание.
- Отметить handoffs (передачи между ролями) — каждый генерирует 30–50% потерь.
- Отметить возвраты (replan, переделки) красным.
Типичные находки:
- «Согласование марки бетона занимает 11 дней календарных, при чистой работе 40 минут»
- «КЖ ждёт нагрузки от КМ 6 дней, потому что инженер КМ привык собирать их в конце недели»
3.7. Анализ артефактов работы
В проектном бюро это золотая жила, потому что артефактов много и они версионируются:
- История DWG/RVT: timestamp’ы сохранений + размер файла → паттерн интенсивности работы, ночные правки, выходные.
- BIM 360 / Revizto issue log: кто кому ставит замечания, сколько висят, сколько раз reopen.
- Email-треды с заказчиком: где задержка ответа от ПИК/Самолёт, кто фактически коммуницирует.
- Версии PDF замечаний экспертизы: путь замечание → ответ → корректировка → повторная подача.
- Чат проекта в Telegram: реальное «командование» процессом часто идёт там, а Lencon Tracker заполняется потом «для отчётности».
3.8. Организационный сетевой анализ (ONA)
Цель: показать реальную сеть коммуникаций vs формальную оргсхему.
Passive ONA на email-метаданных:
- Выгрузка с MX-сервера:
from, to, cc, timestamp, subject_hash(без тела). Период — 3–6 месяцев. - Анонимизировать в роли:
inj_KM_01,GIP_02. - Построить граф: ребро (i,j) с весом =
min(sent_ij, sent_ji). - Визуализировать в Gephi (бесплатно).
- Метрики: degree centrality, betweenness centrality, modularity.
Active ONA (опросник): «Кому вы задаёте технические вопросы?», «От кого вы ждёте данные?», «Без кого этот проект встанет за неделю?». 10–15 вопросов, 5 минут, анонимно.
Этика: соблюдение 152-ФЗ, согласие сотрудников, агрегация на уровень роли, никакого content analysis.
3.9. Triangulation
Никакой одиночный метод не даёт правды. Сила — в сопоставлении:
| Источник A | Источник B | Что вскрывается |
|---|---|---|
| Интервью с РП | Process mining Lencon | Где статусы ставятся постфактум |
| Регламент | Email-метаданные | Кто фактически согласовывает (часто не тот, кто прописан) |
| Shadowing | Diary | Что человек делает vs что помнит, что делал |
| ONA активная | ONA пассивная | Расхождение «к кому я обращаюсь» и «с кем я реально пишу» |
| VSM | Process mining | Скрытые петли переделок |
3.10. Critical Incident Technique (Flanagan)
Очень мощно для проектного бюро: критические инциденты — это поздние правки, замечания экспертизы, срывы сроков.
Шаблон вопросов: «Опишите случай, когда вам пришлось обойти стандартный процесс, чтобы получить результат. Не для отчёта — между нами. С чего всё началось? Что вы пытались сделать сначала? Почему это не сработало? Что вы сделали? Кто помог?»
3.11. Storytelling / SenseMaker
Метод Snowden’а: вместо «опишите процесс» — «расскажите историю про последний проект». Затем сам рассказчик через dyads (би-полярные шкалы) проставляет, где находится: безопасно ↔ рисково, мой выбор ↔ навязано, понятно ↔ хаос. Получается квантифицированный массив микро-нарративов.
3.12. Walk-through / talk-through
«Покажите мне на экране, как вы делаете эту задачу. Каждый клик проговаривайте». 60 минут. Обнажает количество переключений между окнами, копипасту, использование «своих» Excel-шаблонов в обход корпоративных.
3.13. Photo / screen elicitation, видеозапись
С согласия — запись экрана 1–2 часа работы. Затем совместный просмотр с инженером.
3.14. Anonymous surveys, suggestion systems, exit interviews
Exit-интервью увольняющихся — наиболее честные данные о теневых процессах, потому что человеку «нечего терять». Правило: exit делает не HR и не руководитель, а нейтральный facilitator.
3.15. A/B и hypothesis-driven discovery
Сформулировать гипотезу: «Если мы введём ежедневный 10-минутный sync между КМ и КЖ, то задержка передачи нагрузок сократится с 6 до 2 дней». Пилотировать на 1 корпусе, сравнить с контрольным. Safe-to-fail probe в духе Snowden’а.
4. Комбинированная методология (последовательность)
Фаза 1. Декларация (1 неделя). Интервью с директором, ГИПами, сбор регламентов, BPMN as-designed.
Фаза 2. Цифровые следы (2 недели). Выгрузка Lencon Tracker, email, файловой системы, BIM-issue-log. Сборка event-log. Прогон через Disco/PM4Py.
Фаза 3. Прямое наблюдение (3–4 недели). 5 shadowing-сессий, 8 contextual inquiry, 1 VSM-воркшоп, 15 critical incident-интервью.
Фаза 4. Сеть (1 неделя). Active ONA опросник + анализ email-метаданных.
Фаза 5. Триангуляция и gap analysis (1 неделя). Сводная таблица.
Фаза 6. Валидация с командой (workshop, 1 день). Показать находки самим инженерам и ГИПам. Не как обвинение, а как зеркало.
5. Работа с сопротивлением и искажениями
- Хоторн-эффект: длительные циклы наблюдения, повторные визиты, фокус на артефактах, а не на «оценке человека».
- Социальная желательность: задавайте вопросы про конкретный последний случай, а не «как обычно». Спрашивайте про коллег («как ваши коллеги обычно поступают?»).
- Политика: важно отделить роли исследователь и оценщик. Тот, кто собирает данные, не должен влиять на премии.
- Психологическая безопасность (Edmondson): 7-вопросный валидированный опросник в начале и в конце.
- Гарантии анонимности: granted immunity — формальное письменное обязательство.
- Нейтральный facilitator: для критичных интервью наймите внешнего модератора.
6. Инструменты (с учётом размера 35–100 человек)
| Категория | Доступно для SME | Избыточно |
|---|---|---|
| Process mining | Disco, PM4Py, Apromore Community, ProM | Celonis, UiPath PM, ARIS |
| ONA | Gephi + Python networkx, Polinode, Viva Insights | OrgMapper, Worklytics enterprise |
| BPMN | Camunda Modeler, Bizagi Modeler, draw.io | Signavio |
| Анализ интервью | Dovetail (~$30/мес), Notably, Reduct.video, Otter.ai | Atlas.ti на полной лицензии |
| Pulse / sentiment | Telegram-бот, Google Form, Officevibe | Culture Amp, Lattice (для 500+) |
| Diary studies | Telegram-бот + Google Sheet | Indeemo, dscout |
7. Специфика knowledge work и проектных бюро РФ
- Невидимый труд: think-time не виден в логах. Компенсируется shadowing и diary.
- Многопроектная матрица: один инженер ведёт 2–4 корпуса параллельно. Event-log срезать по сотруднику, не только по корпусу — context switching главный убийца производительности.
- CAD/BIM как первичный артефакт: file mtime, history Revit, clash-detection log — это уже event-log.
- ГИП и ГАП — узкие точки санкционирования; одновременно creative-эксперт и bottleneck. Классический Mintzberg-паттерн: managerial work хаотичен и реактивен.
- Стадии П/Р, экспертиза, авторнадзор: каждая — отдельный sub-process. Заказчик (ПИК, Самолёт) обладает огромным неформальным влиянием — он меняет ТЗ в процессе.
- Российская нормативная база: espoused theory часто = «работаем по ГОСТ». Реальность: ГОСТ — нижняя граница, а основной поток замечаний идёт от внутренних стандартов заказчика.
8. Конкретный план для бюро 35–100 человек
Неделя 1.
- Интервью с директором, 2 ГИПами, главой проектного отдела
- Постановка контракта с CEO: что вы делаете, зачем, гарантии для сотрудников (immunity)
- Выгрузка истории Lencon Tracker за 6 месяцев в CSV
- Базовый замер psychological safety (Edmondson 7-item)
Месяц 1.
- Первый process mining-разрез в Disco/PM4Py
- 4 shadowing-сессии (по 2 дня)
- 8 contextual inquiry
- Email-метаданные за 3 месяца → ONA в Gephi
- VSM-воркшоп на 1 «образцовый» корпус
Месяц 2–3.
- 15 critical incident-интервью
- Сбор 100–150 микро-нарративов
- Diary study на 2 недели для 10 человек
- Триангуляция, gap analysis, отчёт
- Workshop валидации с командой
Артефакты на выходе:
- BPMN AS-IS (declared) и BPMN AS-DISCOVERED (mined) — рядом с подсветкой расхождений
- RACI AS-IS vs RACI фактический
- Карта сети коммуникаций (Gephi)
- VSM с метриками PT/LT, % FPY (first pass yield), % переделок
- Реестр workarounds (теневых процессов) — без имён, с причинами
- Gap analysis: топ-10 расхождений declared vs actual
- Каталог критических инцидентов
- Метрики psychological safety baseline
Continuous discovery: после первичного цикла — еженедельный автоматический re-run process mining (PM4Py в pipeline → отчёт в Telegram), ежеквартальный pulse, ежегодная полная переоценка.
9. Риски и антипаттерны
- ❌ «Boil the ocean» — попытка описать сразу все процессы. Лучше один процесс на глубину.
- ❌ Document-centrism — увлечение красотой BPMN-диаграмм. Модель — побочный продукт; цель — изменения.
- ❌ Игнорирование неформального — если ваша картина только Lencon + регламент, упустили 30–60% реального процесса.
- ❌ Confirmation bias исследователя — формулировать гипотезы письменно ДО сбора данных.
- ❌ Слом trust через «доказывание неправоты» команды — артефакты в формате «вот что система делает, чтобы выжить».
- ❌ Заморозка — фиксация процесса «as-is» как нового регламента создаёт следующий уровень разрыва WAI/WAD.
- ❌ Чрезмерная вера в инструмент — Celonis сам по себе не даст правды, если статусы ставятся формально. Качество process mining = качество event-log’а × качество вопросов.
10. Финальный тезис
Реальная картина процессов в проектном бюро — это не один документ и не одна диаграмма. Это живой триангулят из четырёх источников:
- что говорят люди
- что показывают цифровые следы
- что видно при прямом наблюдении
- что вскрывается в критических инцидентах и историях
Дешёвый и быстрый способ начать для компании 35–100 человек — PM4Py + Disco на ваших же Lencon-логах, плюс 10 contextual inquiry, плюс passive ONA на email-метаданных. Это даёт 80% картины за 6–8 недель и за бюджет до полумиллиона рублей.
Полный академический цикл с SenseMaker, diary, видео и валидацией — ещё 2–3 месяца. Окупается тем, что у руководителя и команды появляется общий язык про то, как они работают на самом деле. Это и есть условие для двойной петли обучения по Argyris — и единственный известный путь к устойчивым изменениям.
Связи
- Применимо к: Lencon-vault — текущая база знаний уже содержит часть event-log’а (история карточек, frontmatter статусы)
- Похожие идеи: Плейбук фаундера. как строить AInative стартап — там схожая логика про domain expertise и continuous discovery
Что взять для ЛЕНКОН
- Mini-process-mining на основе Lencon-vault: timestamps
последняя_проверка,год,статус_данных→ видна динамика наполнения - Event-log из CAD: DWG/RVT mtime в проектных папках на O:\ — пассивный источник интенсивности работы
- Email-метаданные через info@lencon.ru — passive ONA для понимания кто с кем реально работает
- Critical incidents: интервью с Виталием, Олегом, Олей про последний крупный срыв или переделку → каталог типовых workarounds
- VSM на одном корпусе: взять текущий активный проект и нарисовать его поток от ТЗ до сдачи с метриками PT/LT
- Diary study через Telegram-бот (когда будет готов в Inbox-фазе) — 4 раза в день: «что делаешь, что мешает»
- Psychological safety baseline (Edmondson 7-item) перед любыми инициативами по изменению процессов