Между риском и доходностью

Исходная ситуация

Эксперту предложили руководить проектом по автоматизации учёта рабочего времени, расчёта заработной платы и распределения затрат. Проект был масштабным: 6000 человек, около сотни подразделений — 20 крупных производственных, около 150 видов начислений, сменная работа. На первый взгляд, проект казался несложным — ничего такого, с чем руководитель проекта не сталкивался ранее. Задачи были понятны и знакомы: запустить учёт кадров, наладить учёт рабочего времени, рассчитать зарплату и отразить её в бухучете.

Однако несколько „мелочей” портили общую картину:

• территориальная распредёленность подразделений (на площади более 200 га);
• высокий средний возраст персонала предприятия — 57 лет;
• отсутствие какой-бы то ни было регламентирующей документации (положения о заработной плате и пр.);
• отсутствие штатного расписания (ни в каком виде);
• огромная номенклатура выпускаемых изделий по множеству переделов;
• сложная межцеховая кооперация;
• отсутствие производственного учёта;
• расчёт зарплаты вёлся в самописной системе, разработанной на базе FoxPro;
• для автоматизации учёта рабочего времени, расчёта заработной платы и распределения затрат была выбрана система «1С:Зарплата и управление персоналом КОРП 3.0», которая на момент старта проекта находилась на стадии альфа-версии;
• с системами фирмы «1С» на предприятии работает только кадровая служба;
• отрицательный опыт внедрения предыдущего проекта.

Анализ рисков и планирование проекта

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

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

Исходя из собственного опыта и опыта команды, полагаясь на свою интуицию, руководитель проекта и увеличил сроки реализации проекта. Работу по устранению приведённых выше „мелочей” точно оценить довольно трудно. Ещё труднее понять их взаимное влияние и синергетический эффект от них. Поэтому он доверился своей интуиции.
Замечу, что хороший руководитель проекта обычно старается учесть все возможные риски, хотя заказчик обычно говорит, что «такого не может быть, не может произойти в принципе». На мой взгляд, важно зафиксировать все риски, даже те, которые не были приняты заказчиком, потому что скорее всего эти события всё равно произойдут. Зафиксировать пусть не в плане проекта, но в замечаниях к нему.

Первый этап проекта как устранение неопределённости

Неопределённость, связанная с влиянием „мелочей” на проект, была высокой, поэтому руководитель проекта принял решение вначале провести описание и реинжиниринг текущих автоматизируемых бизнес-процессов: кадрового учёта, учёта рабочего времени, расчёта заработной платы и отражения заработной платы в бухучёте. Это был сильный ход, который нечасто используется в таких проектах, ведь кажется, что всё понятно, всё не раз делали. Особенно такое описание необходимо в ситуации, когда взаимосвязь мелких фактов понять невозможно, как в нашем проекте.
Естественно, у заказчика возник вопрос: «Зачем? Ведь и так всё понятно, мы уже давно считаем зарплату». Но руководителю проекта повезло: во-первых, предприятие было государственным; во-вторых, уже был негативный опыт внедрения, поэтому он просто сказал «так надо» и это сработало. Описание и реинжиниринг процессов был завершён за 3 месяца, но доводка процессов продолжалась до окончания проекта.
В ходе обследования выяснилось, что распределение ФОТ на затраты — это „шаманский ритуал”, который так никто и не смог описать словами, кроме как «мы знаем как». Оказалось, что у одних подразделений не хватает компетенций, у других — нет желания работать (потому что они никогда и не работали!), третьи подразделения не работали никогда с компьютером, а расчётный отдел никогда не считал заработную плату.

На развилке

Как быть в такой ситуации? Этапы и вехи проекта необходимы, чтобы вовремя остановиться. В Высшей школе менеджмента при Высшей школе экономики предлагался такой кейс: вы едете на машине по навигатору; навигатор показывает, что необходимо повернуть, но поворота в действительности нет. Ваши действия? Правильный ответ — остановиться. И неважно, что вы будете делать потом. Остановка позволит без спешки оценить своё положение и принять оптимальное решение. В проекте аналогично: если после выполнения этапа понятно, что дальше идти некуда, необходимо или изменить план проекта, или честно отказаться от его дальнейшего выполнения.
По-хорошему необходимо было удлинить проект как минимум на год. Но в этот момент плюсы проекта обернулись минусами: государственный заказчик не может выделить финансирование без серьёзного обоснования, а объяснение в стиле «мы не знаем, как ФОТ распределяется на затраты» никто не подпишет.

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

1) закрыть проект;
2) выполнить только часть работ проекта (с риском для руководителя проекта оказаться „козлом отпущения” и соответствующего наказания, а для исполнителя не получить оплату по выполненным этапам);
3) упрямо двигаться согласно намеченного плана несмотря ни на что и надеяться, что „повезет”;
4) расширить границы проекта и попросить под это дополнительные ресурсы.

Расширение границ проекта

Здесь следует сказать о границах проекта, так называемом SCOPE проекта. Любой исполнитель за одни и те же деньги хочет сделать как можно меньше, а заказчик — как можно больше потребовать с исполнителя. В результате, как показывает опыт, к текущим границам проекта заказчик всегда хочет присовокупить что-то ещё, то есть увеличить, расширить границы проекта. Риск расширения границ проекта — один из наиболее опасных для самого проекта. По моему опыту, ещё не было ни одного проекта, у которого остались бы неизменными границы. И обычно границы расширяются.
Аналогичная ситуация была и в обсуждаемом нами проекте — в текущих границах проект был просто не реализуем. Я уверен: если расширения проекта не избежать, то его лучше возглавить. Если расширение границ проекта — единственный способ спасти проект, на это надо идти. Так наш руководитель проекта и поступил. В описываемом проекте пришлось:

• изменить процессы для того, чтобы они стали реализуемы в текущих условиях;
• углубиться в производственный учёт и методологию разнесения ФОТ по затратам;
• провести не только обучение, но и аттестацию персонала.

И хотя не удалось удержаться в первоначальных границах проекта, по крайней мере, процесс расширения был под полным контролем руководителя проекта. И это сработало.
Расширение границ проекта — несомненно, „зло” для исполнителя, но не стоит его сильно бояться. На мой взгляд, в ходе выполнения проекта можно несколько расширить его рамки, чтобы предвосхитить пожелания заказчика, так как от расширения проекта заказчик всегда в плюсе. А ещё лучше это расширение предвосхитить и запланировать. Например, сделать дополнительные отчёты, специальные рабочие места и пр. Особенно полезно это, когда при описании процессов выявляются новые процессы для автоматизации, которые потом могут быть сведены в новый проект. Это приятный бонус для заказчика и запланированные затраты для исполнителя. В описываемом проекте, например, заказчик попросил дополнительно указать все источники, которые передают информацию в процессы учёта рабочего времени, расчёта зарплаты и распределения затрат. Эти работы были выполнены, поскольку руководитель проекта заранее запланировал ресурсы на такое расширение.

Причины расширения границ проекта, как правило, очень важные. Зачастую заказчик требует расширения рамок проекта, потому что «необходимо сдавать отчётность в вышестоящую организацию». Всё это понятно, но, тем не менее, важно и ограничить расширение рамок проекта. Если требования заказчика выходят за рамки проекта, следует аргументированно отказать только для того, чтобы выполнить те работы, которые входят в проект, потому что время и ресурсы всегда ограничены. Не нужно стесняться говорить заказчику «это за рамками проекта», говорить уверенно, обосновывая, почему это именно так.
Так, например, было с формой П-4. Предприятие собирало эту форму не по ОКВЭДам, а так, как „исторически сложилось”. На совещании по формированию данного отчёта был предъявлен приказ от 2004 года, в котором не было ни слова про ОКВЭД. Понимания видов деятельности не было ни в документации, ни у топ-менеджеров. Поэтому на совещании было принято решение провести анализ алгоритма формирования отчёта по форме П-4 (с учётом специфики предприятия) силами дополнительных специалистов заказчика, утвердить его, а далее предоставить его команде проекта. Таким образом, границы проекта в этой части были сохранены.

Планируем резерв

Как заранее запланировать ресурсы для расширения проекта? Проект — это не просто равномерная и нормальная работа. Проект — это всегда сверхусилия, качественный и количественный скачок для заказчика. Количество сверхусилий запланировать сложно, но резерв ресурсов обязательно должен быть.  Из практики — это не менее 15 — 20% от всех ресурсов проекта. По сути это плановое расширение рамок проекта.
В описываемом проекте резерва по разным причинам не было. Поэтому после расширения границ проекта работали все, кто был в наличии, в том числе руководитель и даже куратор проекта. Когда требуется „совершить чудо”, необходим правильный настрой в команде, чтобы каждый выполнял ту работу, которая у него получается лучше всего. В данном проекте пришлось работать 15 дней по 12 часов без выходных, но при этом удалось выплатить аванс и заработную плату в срок, согласно коллективного договора предприятия. Для руководителя проекта это возможность проверить, кто в команде сильный, а кто слабый, правильно распределить нагрузку в команде.

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

Текущая ситуация

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

• выполнен расчёт аванса;
• сдан табель;
• выполнен предрасчёт;
• рассчитаны премии;
• выполнен расчёт зарплаты;
• затраты распределены и отражены в бухучете.

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

* * *

Итак, подведём итоги. Правильное определение границ проекта, удержание проекта в рамках позволяет команде проекта выполнить работы в срок. Но, как показывает практика, в большинстве проектов расширения его границ не избежать. Значит, надо подготовиться к этому, покрыть основные риски проекта резервными ресурсами и возглавить это расширение. И тогда вы получите запланированные результаты проекта на каждом его этапе.

Комментарии 0