Где-то в 2012 году перед нами всерьез маячила задача строительства 10К++ в год типовых объектов. На тот момент было совершенно очевидно, что ни одна методология проектного управления не будет эффективна для массово-параллельного проекта, куда необходимо вовлечь сотни компаний и тысячи людей, обеспечив прозрачность, управляемость и приемлемый по качеству результат. Тогда и была разработана эта методология, как подмножество процессного подхода. Идеи – мои, а детальная проработка — Юрия Корецкого. К сожалению, обстоятельства изменились радикально, и это, в числе многих других наработок, оказалось невостребованным. Но это не значит, что мысли утратили актуальность.

Проблематика

К тому времени мы имели немалый собственный опыт массового строительства со своими набитыми шишками, да и экспресс-анализ подобных проектов показал, что большинство заказчиков идут по избитому пути декомпозиции:

1. Взять множество объектов и разделить на лоты
2. Разыграть лоты между «большими» подрядчиками
3. Большие подрядчики делят на меньшие лоты
4. «Разыгрывают» лоты между меньшими подрядчиками
5. Цикл повторяется до конкретного исполнителя, чаще всего даже не компании, а бригады.

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

1. «Жадность исполнителя» — в погоне за объемами каждый старается на старте «захватить» кусок побольше и пожирнее не особо думая о последствиях.
2. «Длинный цикл». Из практики строительства сотовиков – конечные исполнители порой ждут денег многие месяцы пока вся вертикаль «сдастся».
3. Отсутствие контроля в динамике. Мы ни в какой момент времени не можем реально сказать в каком состоянии проект. «Вертикальная» отчетность приукрашивается и искажается.
4. Затруднен маневр ресурсами. См. п. 1, даже если очевидно, что кто-то выходит из графика – совершенно невозможно перераспределить работы и ресурсы.
5. Каждый конечный исполнитель не сбалансирован по составу работ конкретного объекта. У кого-то больше сварщиков, у кого-то – монтажников, у кого-то – инженеров. Дефицитный ресурс создает «узкое место» на конкретном исполнителе, а их совокупность замедляет динамику проекта в целом.

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

Условия

Речь идет строго о массово-параллельных проектах, как пример —  строительство типовых объектов. Типовых не в смысле идентичности технических решений или облика, а в смысле этапности и промежуточных результатов. В силу этого метод применим там, где:

1. Объектов много. Очень много.
2. Полный цикл каждого объекта может быть определен как последовательность операций с формализованным, проверяемым по качеству и количеству промежуточным результатом каждого этапа.
3. Требования к каждому этапу (операции) могут быть формализованы с достаточной для исполнителя детальностью.

Например, строительство базовой станции достаточно отчетливо делится на этапы, каждый с конкретным результатом:

1. Поиск и контрактование позиции. Результат – соглашение с владельцем недвижимости.
2. Обследование позиции (site survey). Результат – исходные данные для проектирования
3. Проектирование. Результат – рабочий проект.
4. Монтаж. Результат – смонтированная позиция и исполнительная документация
5. Пусконаладка. Результат – готовая к включению БС.

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

Концепция

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

В плане подготовительной работы должно быть сделано:

1. Разделение на этапы, формализация требований к каждому этапу и требований к приемке его результатов.
2. Определение ролей (целевых компетенций) для выполнения каждого этапа
3. Предварительный ресурсный анализ проекта на предмет необходимого для исполнения в желаемые сроки ресурса.
4. Оценка и классификация задач и этапов с целю установить начальные лимиты системы (см. далее)
5. «Регистрация» потенциальных исполнителей и «декларирование» ими ресурсов требуемых типов (см. далее)

Итак, на каждом шаге объект перемещается по конвейеру из пула предыдущего шага в пул следующего, либо в состояние «сделано» если этот шаг последний, как на рисунке. Идея проста, на каждом шаге выполняется операция Ox и контроль ее качества Kx. Но самое интересное происходит внутри.

Внутри каждого этапа работает одна и та же логика следующего вида:

1. Каждый исполнитель имеет определенное число «слотов», заданное ему в соответствии с заявленными ресурсами по профилю, требуемому для выполнения задачи данного этапа.
2. Одна задача (объект) – один слот.
3. Исполнитель может получить новую задачу только в «свободный слот».
4. Слот высвобождается в момент, когда результат этапа прошел контроль качества.

Таким образом, каждый исполнитель в любой момент времени имеет в распоряжении ровно столько задач определенного типа, сколько ресурсов требуемого профиля для их выполнения он реально выделяет, с очень коротким циклом реакции системы. При этом необходим механизм «динамической подстройки» количества слотов в зависимости от фактической динамики исполнения.

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

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

Логика распределения по исполнителям должна учитывать географию и иные факторы и может быть построена на следующих механизмах ценообразования:

1. Нормативном, цена задана  (выигрываем время, лишаемся возможности экономии)
2. Динамическом нормативном (никто не берет, конкуренция низкая – цена растет, конкуренция высокая – цена падает)
3. Автоматической микро-аукционной системе. Раз за период времени T разыгрывается задача из пула. Давший минимальную цену получает ее в свободный слот

В общем случае не система назначает задачи, а исполнитель «выбирает» из текущего пула задачу, имея свободный слот. Точно так же он может и не задействовать свой слот если, к примеру, у него произошла временная убыль ресурсов – отпуска, параллельные работы и т.д. То есть система ограничивает максимальное количество слотов но не принуждает к их заполнению.

Функция контроля качества на каждом этапе также может выполняться подрядчиком «особого типа» для которого контроль качества будет основной и единственной задачей в проекте. В силу очевидной «конвейерности» процесса достаточно просто контролировать его загрузку и временные характеристики. Возможные временные лаги на проверку могут быт компенсированы дополнительными слотами для исполнителей. По результатам проверки возможно не только принять работы или вернуть на доработку, но и полностью «выбраковать» результат и вернуть его в пул невыполненных задач, а также «выбраковать» исполнителя по совокупности накопленных отрицательных результатов проверки.

Технологические взаимосвязи, определяющие порядок работ, могут учитываться в виде приоритетов и условий для отдельных объектов. Например, для набора объектов А не может быть выполнена пусконаладка если она не завершена для объекта Б. В этом случае набор объектов блокируется в пуле и не передается в работу на данном этапе пока «блокирующая» задача не будет выполнена.

Приоритеты проекта могут быть заданы через разницу в стоимости (разная «выгодность») объектов, и через определенный порядок «загрузки» в начальный пул, поскольку наполнение начального пула на 100% необязательно для начала исполнения, напротив, наполнение начального пула выступает дополнительным регулятором динамики.

Оптимальным режимом оплаты видится ежемесячная оплата по факту принятых работ по всем типам задач, в разрезе юрлиц. Такой подход мощно мотивирует исполнителей на выполнение максимальных объемов при сохранении качества на должном уровне и является дополнительной ценностью, привлекающей их к участию.

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

Результат

В результате мы получаем систему управления массово-параллельными проектами, которая:

1. Дает отчетливую картину состояния проекта в динамике виде числа объектов, находящихся на каждом этапе (в каждом пуле).
2. Быстро, в считанные недели, накапливает объективные данные по динамике исполнения, позволяющие с высокой точностью прогнозировать сроки завершения.
3. Дает равномерную нагрузку на все звенья, в том числе на контроль качества. Отсутствует «шутрмовщина» и «массовая приемка работ»
4. Позволяет каждому участнику по максимуму загрузить соответствующие ресурсы несмотря на дисбаланс по профилям. Также делает возможным участие узко специализированных на тех или иных этапах компаний.
5. Позволяет «на ходу» корректировать параметры для достижения целевых показателей, например, вовлекать дополнительные ресурсы, балансировать вовлечение ресурсов стоимостью и т.д., при этом делать это на макро-уровне управления.
6. Самостоятельно «локализует» проблемные объекты, не позволяя им блокировать нормальный ход работ, в том числе их сдачу и оплату. При этом автоматически сохраняет и усиливает мотивацию исполнителя — проблемный объект занимает слот, а его долгое пребывание там приведет к еще большему урезанию слотов вплоть до того, что этот объект останется единственной задачей.
7. Создает оптимальную систему мотивации для всех участников. Объективно ранжирует их на д’Артаньянов и.. нерадивых работников, позволяет строить очень гибкие и эффективные схемы мотивации для исполнителей.
8. Исключает непроизводительные «генподрядные» звенья, весь смысл существования которых сводится к распределению работ по более мелким исполнителям.

Естественно, такая система немыслима без высочайшего уровня автоматизации, и должна представлять собою единую информационную среду проекта, в рамках которой и происходят все описанные процессы. Система управления на описанных выше принципах может быть построена на базе BPM-системы с добавлением требуемой бизнес-логики, ибо суть происходящего на 100% процессная.

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

Заключение

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

Мы успели обсудить эту идею с определенным кругом исполнителей, не «генподрядчиков», а конечных людей, непосредственно работающих «в поле». К нашему удивлению, вместо ожидаемого скепсиса и консервативных оценок «так не работают!» — мы получили исключительно позитивную обратную связь. Люди были готовы включаться и работать, так как схема «чем быстрее делаешь – тем больше каждый месяц зарабатываешь» оказалась намного более привлекательной, чем ожидалось.

Надо отметить, что данный подход, к сожалению, плохо ложится на широко распространенные «положения о закупках» крупных компаний и их бизнес-практики. Он требует от Заказчика не просто «провести два-три формальных конкурса», а активно включиться в проект, выстроить «рабочую среду» и разумно регулировать процесс на макро-уровне вплоть до полного успеха, приняв на себя существенную долю ответственности за результат и организацию его достижения. К этому, к сожалению, крупные компании не готовы, однако я не оставляю надежду, что кому-то этот подход пригодится, ибо проекты такого типа — не редкость.