Результат № 2: Оценка ресурсов

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

В качестве самых очевидных ресурсов отметим следующие:

• Люди.

 Время.

 Оборудование.

 Деньги.

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

Но, допустим, один и тот же человек должен и смету разрабатывать, и тендер для подрядчиков проводить. И, допустим, затраты на эти работы в часах таковы, что он может успеть выполнить либо одно дело, либо другое. Тогда связь между этими делами была бы ресурсная. Или, например, для того, чтобы вовремя согласовать смету, необходимо согласовать время встречи. Тогда в сетевом графике появилось бы мероприятие «направить приглашение на встречу для согласования сметы», и выполнить это мероприятие было бы правильно одновременно с началом разработки сметы – на всякий случай, чтобы не рисковать тем, что у контрагента в этот день все уже будет расписано, когда вы, завершив разработку сметы, захотите ее как можно быстрее согласовать. Программа дает возможность прямо в сетевом графике отметить характер связи (причинно-следственная либо ресурсная) путем введения в файл колонки, в которой это можно указать.

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

Очень важно обращать внимание на степень загрузки ресурсов. В рамках увеличения производительности системы у нас может возникнуть похвальное на первый взгляд стремление к максимальной загрузке всех ресурсов. Однако загрузка оборудования более чем на 75 процентов времени (в среднем, конечно) приводит… к уменьшению производительности (производственные нормы обычно учитывают этот эффект). Это связано с тем, что возрастает напряженность работы и требуется уже не оптимизация, а идеализация буквально всех основных и поддерживающих процессов, что невозможно на практике. Поэтому малейший сбой или просто естественное для процессов, в которых участвуют люди, отклонение от жесткого графика приводит к эффекту домино и буквально сносит всю цепочку.

Мы выходим на странную, казалось бы, идею: система будет работать лучше, производительнее, если у каждой ее «единицы» будут резервы. Элияху Моше Голдратт сформулировал это так: «Максимальная загрузка всех элементов системы вовсе не приводит к максимальной производительности системы». Это справедливо как для станков, так и для людей. Стремление (часто неосознанное) загрузить подчиненных «по максимуму» часто приводит к непрерывному «сбрасыванию» на их головы недостаточно проработанных идей, поручению задач с низким приоритетом, а иногда и к выполнению вообще ненужных работ, ибо главное – чтобы подчиненные вкалывали. Иногда такой подход становится следствием «синдрома собственника»: мол, эти люди «едят» мои деньги, стремятся отлынивать от работы, поэтому чтобы деньги выплачивались не зря, пусть пашут. Дополнительным катализатором может служить и то, что стоимость рабочей силы у нас растет быстрее, чем ее квалификация и производительность. В общем, на то вроде бы есть объективные причины, но такой подход приводит вовсе не к увеличению производительности труда, а, наоборот, к снижению общей эффективности системы, так как делается, может быть, и больше, но не то, что надо, не так, как надо и не тогда, когда надо. А иногда делается и меньше, так как в итоге, после всех пролитых ведер пота и ажиотажной суеты с выпученными глазами, оказывается, что до конца и в нужном качестве не сделано вообще ничего, а все работы находятся «в процессе».

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

Одной из ошибок при планировании развивающих проектов является попытка оптимизировать их сразу. Давайте порассуждаем: можно ли спланировать все точно? И насколько точно? Ведь если речь идет о новом проекте, рассчитать необходимые ресурсы мы можем только ориентировочно. Мы не знаем, сколько часов понадобится на выполнение работы; пусть по предварительным прикидкам мы пришли к цифре в 8–11 часов. Сколько закладывать в план? На первый взгляд, 8 или даже 7 часов: пусть сотрудники покрутятся, будут стараться – глядишь, и справятся, а если что – разрешим опоздать.

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

Мы предполагаем, что первые результаты будут не совсем оптимальны по временны?м и прочим издержкам. Это не страшно. Мы учимся производить нужные результаты, а уже потом, при переходе от развития к рутине, оптимизируем все нужные показатели. Эти этапы развития могут быть дополнительно «проиллюстрированы» и сменой приоритетов в «дереве целей». Кстати, такой подход не несет в себе ничего нового: еще в СССР существовали «экспериментальные» расценки на запуск в серию нового изделия. Об «экспериментальности» планируемого времени мы можем предупредить всех участников.

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

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

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

• Вариативность задач: чем более однородна работа подчиненных, тем более высокую их загрузку мы можем планировать. И, наоборот, чем более разнообразны повседневные задачи, тем больший резерв нужно оставлять. Вариативность может зависеть от разных факторов: функционала, определяющего набор рутинных работ, количества одновременно выполняемых проектов по развитию и «турбулентности» внешней среды, а также от уровня владения… хаос-менеджментом, так как эта компетенция позволяет компенсировать высокую вариативность (независимо от вызвавших ее причин).

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

Кроме того, на все вышеизложенное не может не влиять уровень исполнительской дисциплины. Его же, в свою очередь, определяет уровень культуры execution, которая уже формируется профессиональным управлением.

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

Чтобы точнее рассчитывать время выполнения работ, можно воспользоваться рекомендациями PERT. Ожидаемое время выполнения работ (expected time, EТ) рекомендуется вычислять по следующей формуле:

ЕТ = (OT + 4*MLT + PT): 6

OТ – optimistic time, оптимистическое время: минимальное возможное по предварительной оценке время выполнения работ, определенное исходя из предположения, что все происходит именно так как нужно: все делается с первого раза правильно и без опозданий.

PТ – pessimistic time, пессимистическое время: максимально возможное время, требующееся для выполнения работ, определенное исходя из предположения, что все происходит по наихудшему сценарию: все, что может быть сделано неправильно и потому потребует переделки, будет сделано неправильно или с опозданием, а все, что не может быть сделано неправильно и потому потребовать переделки или не может быть сделано с опозданием, тоже будет сделано неправильно. Иными словами, все будет сделано «через пятую точку». Эта оценка не предполагает возникновения реального форс-мажора, просто все идет не так, как надо.

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

Таким образом, ожидаемое время в методике PERT предлагается рассматривать как средневзвешенное, с учетом того что наибольший вес (4) придается наиболее вероятному времени, но при этом мы также принимаем во внимание оптимистический и пессимистический сценарии. Такой подход позволяет скомпенсировать слишком оптимистические ожидания. Практика показывает, что, как правило, реальное время выполнения чаще превышает значение наиболее вероятного времени.

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

Нужно ли использовать подобные изыски? Решать вам. Очевидно одно: точно определить время выполнения работы нелегко. «Вы хочете песен? Их есть у меня!» А выбор за вами: значимость проекта, критичность ошибки и т. п. Кроме того, вовсе не обязательно заниматься этим самому, можно делегировать такие расчеты подчиненным, знающим технологию оценки.

Для качественного анализа ресурсов мне также кажется весьма полезным используемое Голдраттом понятие ресурса-барабана (drum resource). Это ресурс, который максимально загружен, не имеет резервов и на момент выполнения работ не может быть увеличен. Таким образом, являясь ограничением, этот ресурс задает ритм работы всей системы (отсюда его название). В сетевом графике мы можем выявить такие ресурсы и учитывать обусловленную ими жесткость графика.