Когда компания маленькая, многое держится на памяти директора. Он знает, кто что делает, где тормозит, где надо позвонить, где написать письмо, где у проекта есть особенности. На первых проектах это работает.

Но потом проектов становится больше, а вместе с ними растёт и команда. Появляются РП, ГИПы, подрядчики, коммерческий блок, финансисты, новые договоры, авансы, сроки.

Несмотря на то что новых сотрудников обучали одной и той же логике, различия всё равно появлялись. Графики каждый вёл немного по-своему. Бюджеты собирались немного в разной структуре. И каждый раз эти различия казались обоснованными: проекты же разные.

Но все эти отличия в голове уже не удержать. Одной памятью не обойтись. Нельзя позволять знаниям о проектах храниться только в головах сотрудников, пусть и самых светлых.

На повторное разъяснение деталей проекта всем участникам процесса уходили часы. Данные вручную переносились из затрат в бюджеты, из бюджетов в коммерческие предложения, из коммерческих — в договоры, из договоров — в графики и отчёты.

Единого источника правды не было. И на этом длинном пути исходные смыслы понемногу искажались. Делали когда-нибудь копию копии?

Я понял, что здесь нельзя просто объявить: «теперь у нас будет система». У меня было видение, но идти к нему пришлось небольшими шагами. Операционная модель не появляется от одного регламента, одной таблицы или одного совещания по понедельникам. Она появляется, когда несколько скучных вещей начинают работать вместе.

Сначала мы стали приводить к единой логике графики в MS Project. Не для красоты. График должен был показывать не только набор работ, но и управленческий каркас проекта: этапы по договору, контрольные точки, связи между работами. При этом не нужно было полностью загонять РП в жёсткий шаблон. Важно было стандартизировать именно управленческую часть.

Потом появилась форма затрат. РП и ГИП раскладывали проект на работы и давали по ним часы, исполнителей, расходы на подрядчиков. Постепенно эта форма стала уже не отдельным документом с расходами, а первой моделью будущего проекта: что делаем, кто делает, сколько стоит, когда нужен аванс, где возможен кассовый разрыв.

Потом бюджет проекта. Потом отчёт по срокам. Потом структура хранения документов. Потом правила для договоров. Потом роли РП и ГИП. Потом мотивация, которая должна была быть связана не с ощущениями в конце года, а с экономикой этапов.

Каждая отдельная вещь выглядела небольшой. Что такое форма бюджета? Просто таблица. Что такое структура папок? Просто порядок на диске. Что такое единый график? Просто шаблон. Что такое еженедельный отчёт? Просто регулярная встреча.

Но вместе они начали менять качество управления.

Появилась возможность не спрашивать каждый раз: «а что у нас по проекту?», а смотреть в одну и ту же логику, структуру данных.

Обосновывать сроки стало возможно не личным опытом, а графиком. Обсуждать денежные потоки — не ощущениями, а расчётом. Проверять проект — не по памяти, а по связанным между собой документам.

Конечно, не всё прижилось сразу.

Часть вещей приходилось переделывать. Какие-то формы люди заполняли формально. Где-то всё равно приходилось проверять руками. Договоры с подрядчиками до сих пор отдельная боль. Фактические часы — тоже не та часть системы, которую можно считать закрытой.

Но для меня здесь и был главный вывод. Операционная модель проектной компании строится не одним красивым решением. Она собирается постепенно, из связей между обычными рабочими вещами.

Каждую передачу информации стоит делать максимально бесшовной. Для каждого вида данных должен быть один источник правды. А ещё нужно проектировать формы так, чтобы ошибиться было сложно: не через нотации и постоянные замечания, а через автоматизацию, ограничения ввода и понятную структуру.

Только тогда компания начинает управляться не через память одного человека и не через героизм команды, а через понятный управленческий контур.