График реализации проекта пример. Организационный план. Создание Бизнес-процессов, поручений и напоминаний


Статья предоставлена редакцией информационно-аналитического журнала "Управление Проектами" в рамках совместного проекта с Финансовой академией “Актив”.

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

Для кого эта статья

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

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

Планирование проекта

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

Если говорить об управлении сроками, то можно сформулировать следующие требования. Хороший график проекта:

  1. Приспособлен для информирования заказчика и проектной команды. Для этого он должен быть понятным, компактным, логичным, хорошо структурированным.
  2. Легко модифицируется в случае изменений сроков и состава задач. Его легко поддерживать в актуальном состоянии.
  3. Позволяет контролировать сроки, обнаруживать проблемы и принимать по этому поводу решения.

Для того, чтобы составить такой график предлагаем следующий план действий:

1. Принять решения о способе планирования

1.1. Планирование от начала

Более привычный для большинства способ. Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.

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

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

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

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

Чтобы избежать раннего начала задач и распределить задачи во времени, можно использовать ограничения на задачи типа «Не ранее чем», «Фиксированная дата начала».

Иногда используют задержки и сдвиги между задачами.

Рисунок 1


Однако пользоваться задержками лучше по возможности меньше.

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

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

1.2. Планирование от конца

Если конечная дата проекта жестко определена, то правильнее планировать «от конца». Устанавливается дата окончания проекта, и во всех новых задачах автоматически устанавливается тип ограничения «Как можно позже».

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

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

Многие скажут, что откладывать задачи на потом рискованно. Что если задача займет больше времени, чем запланировано, и результат опоздает? А она обязательно опоздает, и тогда следующая задача сдвинется и неизбежно сдвинется окончание проекта. Чтобы избежать этого, в график добавляются временные буферы. Подробнее об этом ниже.

2. Избавиться от лишнего и упростить план

Лишним считается все, что не помогает планировать сроки проекта.

2.1. Примеры задач, от которых можно избавиться

Рассмотрим группу задач «Управление проектом». Понятно, что задача управления проекта необходима, но она не определяет длительность проекта, а проект определяет ее длительность. Если мы сосредоточены на планировании сроков, можно ее убрать.

Рисунок 2



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

Рисунок 3



План, в конечном итоге, нужен чтобы ставить задачи и проверять факт и качество исполнения. Это очень хороший критерий, чтобы определить, с какой степенью детализации его делать. В план должны попадать только те задачи, которые РП собирается ставить и проверять их исполнения. Более мелкие задачи переносятся за пределы плана — в Excel, в JIRA или в связанный план рабочей группы в MS Project.

2.2. Пример излишней детализации

Расписать задачи до отдельных шагов и действий можно, но что это дает? С точки зрения оценки длительности — ничего. Скорее, приводит к ошибке, т.к. в каждой задаче заложена значительная погрешность.

Рисунок 4


  • «Письмо Пятнициной» — «Ответ Пятнициной». Можно спокойно исключить из плана. Если какие-то задачи зависят от получения письма от Пятнициной, и это действительно шоу-стоппер, то вводим веху «Получение списка ключевых пользователей от Пятнициной». То, что для получения списка нам нужно связаться с Пятнициной, может остаться за кадром.
  • «Назначение встречи» — 1д. Скорее всего должно занять несколько минут. Вместо этого можно было бы вставить одну задачу по подготовке презентации и веху «Встреча с директорами обществ». Не нужна группировка задач. Вместо четырех строк — две.
  • «Выпуск организационно-распорядительной документации» может быть одной задачей. В заметках по задаче, можно перечислить, кому нужно выслать письмо. Длительность задачи определяется суммарным временем подготовки всех документации. И эта информация будет точнее, растягивать эту задач на неделю нет никакой необходимости.

3. Установить взаимосвязи между задачами

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

3.1. Используйте минимум видов связей

В MS Project вы можете использовать разные виды связей между задачами «Окончание-начало», «Начало-начало» и т.д. По возможности, избегайте разнообразия использования разных типов связей. Читать график с разными видами связей сложно. Его поведение графика при модификации становится трудно предсказуемым. Чем проще, чем однообразнее — тем лучше.

3.2. Не используйте связи с суммарными задачами

Рассмотрим упрощенный пример проекта, состоящего из двух этапов. Иногда план выглядит так:

Рисунок 5



В результате мы имеем неоптимальный план. Иванов и Петров будут простаивать, ожидая завершения работы Сидорова по Этапу 1. Если у нас есть задача максимально сжать график проекта, мы начнем работы по Этапу 2, не дожидаясь завершения всех работ по Этапу 1. И тогда график будет выглядеть следующим образом. Связи между задачами, в данном случае отражают последовательность работ каждого из ресурсов.

Рисунок 6



Если же действительно нужно закончить все работы по Этапу 1 и только после этого начинать Этап 2, то можно организовать план следующим образом, не прибегая к связям между суммарными задачами — вставить вехи завершения этапа 1 и начала этапа 2.

Рисунок 7



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

3.3. Используйте Сетевую диаграмму

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

Рисунок 8



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

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

Рисунок 9



Рисунок 10


4. Оценить длительность задач

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

При оценке исполнителями нужно делать поправку. Учитывайте следующие факторы:

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

Задачи не должны включать запас «на всякий случай». Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок. Реальность такова, что все опоздания накапливаются, а опережения съедаются. Почему так? Причины могут быть следующие:

  • «Студенческий синдром» — выучить курс в ночь перед экзаменом. И в проекте начинаем задачу когда до ее сдачи осталось минимум времени.
  • Перфекционизм — если осталось время, надо работу довести до совершенства.
  • Отсутствие доверия — «если сегодня я сделал быстрее, то в следующий раз моим оценкам не поверят, и урежут запрашиваемой мной время».
  • Возможность работать менее интенсивно — «зачем напрягаться, если есть запас по времени?»

Поэтому придерживайтесь следующих правил при планировании работ:

  • Вероятность выполнения в указанный срок установите в 50%. Это сократит оценку длительности по сравнению с 90% оценкой вероятности примерно вдвое. Сокращение времени позволит добавить в график временные буферы, которые вы будете расходовать из-за неизбежного опоздания по задачам. О добавлении буферов смотрите ниже.
  • Ресурсы не должны быть перегружены. Люди не должны выполнять несколько задач одновременно. В этом случае их производительность будет максимально возможной.

5. Избавиться от распараллеливания задач

Часто можно увидеть в планах параллельные задачи, назначенные на одних и тех же исполнителей. Например,

Рисунок 11



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

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

6. Выровнять ресурсы

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

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

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

Альтернатива — это ручное выравнивание с помощью установки последовательности задач, выполняемых одним ресурсом. Это возможно, если план не очень сложный.

Например, модифицируем предыдущий пример:

Рисунок 12



В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова. Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней. Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.

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

7. Исключить жесткую привязку задач к датам

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

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

8. Выявить критический путь

Если задачи выстроены правильно, то MS Project покажет вам критический путь проекта — цепочку задач, которая определяет длительность. Изменение длительности или задержка начала выполнения любой задачи на критическом пути меняет дату окончания проекта.

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

  • Уделять задачам критического пути ежедневное внимание, контролировать готовность всех необходимых ресурсов для их выполнения.
  • Мотивировать участников на сокращение длительности выполнения задач критического пути, не допускать отвлечения на другие задачи.
  • Использовать временные буферы, страхующие отклонение по срокам.

Например, заканчивается разработка функционального блока. Далее заказчик должен протестировать этот блок. Когда до окончания разработки остается 2 дня, необходимо предупредить ключевых пользователей о том, что через 2 дня они должны быть готовы принять разработку в тестирование. И зафиксировать это формально (электронным письмом, решением оперативного совещания, и т.п.). Разрыв между задачами критического пути приводит к увеличению срока проекта, поэтому управлять этим процессом нужно жестко.

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

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

Рисунок 13



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

Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».

9. Добавить временные буферы в график

Добавление буферов в план позволяет избежать нарушений конечной даты проекта или этапа при неизбежном изменении сроков по задачам.

Как правило, мы добавляем запас в каждую задачу, чтобы нас не наказывали за опоздания. Мы предпочитаем заложить запас на все риски, которые могут случиться — отвлечение на совещания, изменения требований заказчика, длительные согласования, технические проблемы и личные обстоятельства. Стараемся дать оценку необходимых сроков с вероятностью 90% их соблюдения. И несмотря на это, часто их срываем. Выше мы уже говорили о студенческом синдроме и прочих психологических моментах, которые приводят к нарушению сроков несмотря на все резервы, которые мы делаем в каждой задаче

В результате, опоздания всегда накапливаются, а опережения — практически никогда.

Выход следующий – избавиться от резервов в задаче и вынести их в общий буфер проекта. Установить целевую вероятность выполнения задачи в срок в 50% Это значительно сокращает оценку сроков по каждой задаче, согласно статистике – вдвое. В половине случаев он будет нарушен. И это может быт не вина исполнителя, а влияние обстоятельств и неправильной оценки. При таком подходе вы не будете наказывать исполнителей за нарушение сроков, а относиться к этому как к неизбежному.

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

Рисунок 14



Различаются буферы проекта (этапа) — запас создаваемый в конце критической цепочки. И питающие буферы — временные резервы на входе в критическую цепочку, страхующие поток задач вне критического пути.

Размер буфера определяется длиной цепочки, которую он страхует, а также степенью неопределенности и рисков. Классики рекомендуют отводить на буферы около 50% длительности всей критической цепочки. Руководитель проекта должен исходить из собственной оценки рисков и возможностей графика проекта.

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

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

10. Проанализировать график

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

10.1. Сокращение сроков

Рассмотрим пример:

Рисунок 15



Посмотрим, нельзя ли сократить этот график. Самые длинные задачи — номер 17 и 21. 18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.

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

Рисунок 16



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

10.2. Риски, связанные с графиком

Интересно посмотреть на график проекта с точки зрения управления рисками. Какие риски может обнаружить график проекта?

  • Параллельное выполнение множества блоков работ или функциональных направлений. Необходимо решить, влечет ли опоздание одного из них серьезные последствия для всего проекта? Сложные проекты включают в себя до десятка направлений. Внедряется одновременно финансы, бюджетирование, HR, логистика и т.д. Если не предусмотрены работы по интеграции и координации направлений, не заложены резервы на отклонения по каждому из направлений, нет этапа интеграционного тестирования, велика вероятность неуспеха проекта в целом, а не только срыва сроков.
  • Отсутствие периода опытной эксплуатации. Если ОПЭ невозможна, то нужно рассматривать возможность поэтапного запуска, по функциональным областям или организационным единицам.
  • Излишне агрессивный график, отсутствие или недостаточный размер резервов. Об этом уже говорили. Такой проект вероятнее всего опоздает.
  • Этапы проекта или ключевые работы идут внахлест, с перекрытием. Во многих случаях это увеличивает риск переделки по уже выполненным задачам.
  • Если в графике отсутствуют работы и вехи, закрепленные за заказчиком, то возможно, мы плохо контролируем работы со стороны заказчика. Необходимо обратить внимание на то, что некоторые работы могут быть некорректно отнесены к зоне ответственности исполнителя.
  • Отсутствие в графике вех, означающих формальную приемку работ, может означать, что мы не до конца понимаем, какие промежуточные результаты и в какой момент должны подтвердить. А это чревато проблемами при сдаче результатов в конце проекта.

Заключение

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

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

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

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

Этап и составляющие его работы;

Продолжительность работ;

Объекты и типы активов;

Способ учета затрат.

Для сложных проектов могут быть представлены календарные или сетевые графики производства работ.

7. ОЦЕНКА РИСКА И СТРАХОВАНИЕ

В данном разделе излагаются возможные риски на пути реализации проекта и основные методы защиты от их влияния.

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

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

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

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

8. ФИНАНСОВЫЙ РАЗДЕЛ БИЗНЕС-ПЛАНА

8.1. Финансовый план

Финансовый раздел является одним из главных разделов бизнес-плана. Именно на основании данных финансового раздела предприниматель, а также его инвесторы и кредиторы, получают представление о доходности предлагаемых инвестиций, потребностях в материальных и финансовых ресурсах, источниках их поступлений и расходов, а также об ожидаемых результатах деятельности предприятия.

Этот раздел включает финансовый план и стратегию финансирования.

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

Чаще всего финансовый план, входящий в состав бизнес-плана, включает следующие документы:

Прогноз объемов выручки от реализации продукции и услуг;

Баланс денежных поступлений и расходов;

Сводную таблицу доходов и затрат;

Прогнозируемый баланс активов и пассивов предприятия;

Расчет минимального объема производства или так называемой критической точки (т.е. точки достижения безубыточности).


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

При составлении финансового плана необходимо решить две основные проблемы:

Определить, какова желательная динамика отношения прибыли к вложенному капиталу (показатель ROI).

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

8.2. Стратегия финансирования

Следующая часть финансового раздела бизнес-плана - стратегия финансирования.

При планировании стоимости основного капитала надо определить, сколько средств и когда именно он планирует направить на новые капиталовложения в машины, оборудование, недвижимость и другие виды основных средств.

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

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

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

Сколько всего необходимо средств;

Откуда и в какой форме предполагается получить эти средства;

Когда можно ожидать полного возврата заемных средств и получения инвесторами дохода;

Каков будет доход.

Ответ на первый вопрос дает финансовый план.

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

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

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

8.3. Обоснование экономической эффективности

Общепринятыми динамическими критериями при оценке инвестиционных проектов являются:

Чистый дисконтированный доход ЧДД, NPV (Net Present Value);

Внутренняя норма доходности ВНД, IRR (Internal Rate of Return);

Индекс доходности ИД (PI);

Дисконтируемый срок окупаемости.

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

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

Создать проект по шаблону можно и из основного списка проектов, доступного по команде Проекты раздела Проекты . Для этого служит команда меню Создать по шаблону .

В данном меню для быстрого доступа выводятся первые 10 шаблонов проектов. К остальным можно перейти по команде Показать все

Создание проекта по шаблону полностью автоматическое - вы выбираете шаблон и через пару секунд открывается форма нового проекта с рассчитанным управляющим расписанием.

Изначально Плановая дата начала нового проекта устанавливается как текущая дата и от нее рассчитываются все задачи согласно указанным в них смещениям и длительностям. Но можно изменить плановую дату и все даты будут автоматически пересчитаны.

Для проекта доступны следующие Статусы :

  • Планируется;
  • В работе;
  • Завершен;
  • Отменен.

Плановые даты возможно менять, пока проект находится в статусе Планируется .

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

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

Проект можно перевести в статус Завершен только в том случае, если все задачи и контрольные точки завершены или отменены. В противном случае будет выведено предупреждение со списком незавершенных задач.

Управляющее расписание представлено в двух режимах: Дерево и Диаграмма Ганта .

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

Пересчет дат при редактировании непосредственно в сроке управляющего расписания полностью аналогичен алгоритму в форме задачи. Например, при сдвиге плановой даты начала на 5 дней плановая дата окончания тоже сдвигается на 5 дней. При уменьшении длительности уменьшается дата окончания . А указание фактической даты начала переводит запланированную задачу в статус В работе .

В режиме Диаграмма Ганта рядом с информацией по этапам и задачам выводится диаграмма Ганта, позволяющая визуально оценить Управляющее расписание проекта. Для каждой строки дерева этапов в диаграмме Ганта выводится два значения - плана и факта.

Ползунок Масштаб Ганта позволяет изменять масштаб диаграммы для удобства просмотра.

В диаграмме отображаются 2 шкалы: помесячная и понедельная.


Если какие то задачи оказываются просроченными, то на диаграмме Ганта они будут отображаться красным цветом. Также ответственные получат уведомления о просрочке.


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

Флаг Отображать в АРМ "Планирование ресурсов проектов" указывает, что данный проект будет отображаться соответствующем АРМ для планирования исполнителей.

Ниже находится область дополнительных реквизитов


На закладке Описание можно указать информацию, касающуюся всего проекта в целом. В описании поддерживается расширенное форматирование текста (выделение размером, цветом текста и фона), создание нумерованных и маркированных списков, вставка картинок, гиперссылок и специальных символов.

В форме проекта есть возможность распечатать Управляющее расписание с диаграммой Ганта при помощи кнопки .

Помимо печати, печатную форму можно отправить по почте.

В меню Отчеты доступен отчет Карточка проекта , который выводит сводную информацию по проекту.

Этап проекта

В этапе даты рассчитываются на основании дат входящих в него задач и контрольных точек. Ручное редактирование недоступно.

На закладке Описание можно указать произвольную информацию. В описании поддерживается расширенное форматирование текста (выделение размером, цветом текста и фона), создание нумерованных и маркированных списков, вставка картинок, гиперссылок и специальных символов.


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

Общая сумма затрат по всем этапам выводится в форме Проекта.

Задача/контрольная точка проекта

Данный объект служит для планирования и контроля выполнения конкретных действий сотрудников в рамках выполняемого этапа проекта.

Для задачи и контрольной точки проекта доступны следующие Статусы :

  • Планируется;
  • В работе;
  • Завершен;
  • Отменен.

В отличии от проекта, статус задач и контрольных точек недоступен для непосредственного изменения. Его изменение зависит от статуса проекта:

  • Если проект в статусе Планируется , то задача может быть только в статусе Планируется или Отменена (перевод в данный статус выполняется по кнопке Отменить );
  • Если проект в статусе В работе , то задачу можно перевести в аналогичный статус по кнопке Принять в работу (аналогичное действие будет при вводе фактической даты начала и записи задачи);
  • В статус Отменена задачу можно перевести по кнопке Отменить ;
  • Вернуть в работу отмененную задачу можно по кнопке Вернуть в работе .
  • В статус Завершена задача переходит после ввода фактической даты окончания . Либо при установки флага Сделано в дереве этапов или диаграмме Ганта.

Раздел Описание .

Описание цели задачи в свободной форме.


Раздел Результат .

Описание результата выполнения задачи.


Раздел Участники .

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

Установка флага Ответственный указывает, что данный участник отвечает за выполнение поставленной задачи, а не просто принимает в ней участие. Первый ответственный в списке считается Основным ответственным . Порядок участников можно менять стрелками “вверх/вниз”.

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

Раздел Чек-лист .

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

По мере выполнения или проверки задачи пользователь отмечает флажками выполненные действия.

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

Если у пользователя полные права либо он является ответственным этапа или проекта, то он может добавлять и удалять строки чек-листа, редактировать текст.

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

Проверка контекста присоединенных файлов

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

Если при попытке завершить задачу не будут добавлены файлы с определенным контекстом, будет выведено сообщение:

Создание Бизнес-процессов, поручений и напоминаний

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

Отражение задач и контрольных точек в календаре

Задачи и контрольные точки отображаются в календаре пользователя, если они включены в списке объектов календаря:

В заголовке календарной записи отображается количество запланированных дней по задаче:

Режим Месяц :

Изменение сроков доступно только через форму задачи/контрольной точки.

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

В английском языке для определения сетевого графика используется термин Project Network — is a graph depicting the sequence in which a project’s terminal elements are to be completed by showing terminal elements and their dependencies.

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

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

Виды сетевых графиков

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

На практике же чаще используется другой вариант сетевого графика, когда вершинами графа являются работы, а дуги обозначают взаимосвязь между ними. Такой вид сетевого графика является частью (англ., CPM — Critical Path Method ).

Рассмотрим второй вариант графика и алгоритм его построения подробнее.

Алгоритм построения сетевого графика

Алгоритм построения сетевого графика по методу критического пути состоит из 10 следующих шагов.

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

Шаг 2. Выявить ограничения

Выявить ограничения, влияющие отдельные работы проекта или весь сетевой график. Типовыми ограничениями являются доступность ресурсов, сроки или стоимость. Кроме этого, ограничения могут быть заданы законодательными требованиям.

Определить состав работ , необходимых для достижения цели, поставленной на шаге 1 .

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

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

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

Начало выполнения параллельных работ должно быть строго привязано к завершению предыдущих работ.

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

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

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

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

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

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

Пример построения сетевого графика

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

Шаг 1. Определить основную цель проекта

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

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

Шаг 2. Выявить ограничения

Бюджет не более 100,000 руб., ремонтные работы можно вести только в рабочие дни с 10:00 до 18:00 с обязательным перерывом с 12:00 до 14:00. Итого получается — 6 рабочих часов в день.

Шаг 3. Определить состав работ

Немного поразмыслив мы накидали основные работы, которые надо сделать, а именно:

  • Нам нужен дизайн-проект новой комнаты;
  • Нам надо закупить материалы для ремонта;
  • Надо составить смету ремонта;
  • Надо выполнить сам ремонт;
  • И т.к. мы решили сделать небольшую перепланировку, то надо согласовать ее с ТСЖ.

Отобразим эти работы в виде блоков:

Рисунок 1. Состав работ

Шаг 4. Оценить длительность работ

Мы решили оценивать длительность работ в днях, т.к. до начала учебного года еще достаточно времени, то такая точность планирования нас вполне устраивает.

Рисунок 2. Длительность работ

Шаг 5. Определить последовательность работ

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

Рисунок 3. Последовательность работ

Шаг 6. Указать связи между работами

Укажем стрелками связи между работами.

Рисунок 4. Связи между работами

Шаг 7. Определить раннее начало и раннее окончание

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

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

Рисунок 5. Раннее начало и окончание работ

Шаг 8. Определить поздние начало и окончание

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

Рисунок 6. Позднее начало и окончание работ

Шаг 9. Определить временной резерв

Вычислим временной резерв для каждой из работ. Он вычисляется как разница между поздним и ранним началом или поздним и ранним окончанием работы.

Рисунок 7. Временной резерв

Шаг 10. Выявить критический путь

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

Рисунок 8. Критический путь

Задачи «Разработать дизайн-проект «, «Согласовать проект с ТСЖ » и «Закупить необходимые материалы «, «Провести ремонтные работы » составляю критический путь, а его длина составляет 19 дней. Это означает, что в текущем виде проект не может быть выполнен быстрее, чем за 19 дней. Если мы хотим сократить сроки проекта, то нам необходимо оптимизировать задачи, лежащие на критическом пути.

Например, мы можем начать ремонтные работы раньше получения согласования на перепланировку от ТСЖ, приняв на себя риски того, что согласование может быть не получено.

Просмотры: 31 961


,

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

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

  • собственное время, необходимое для выполнения конкретной работы;
  • ограничения, накладываемые требованиями взаимосвязи данной работы со сроками начала или окончания других работ проекта;
  • объективными ограничениями, не связанными с проектом (климатические, сезонные и т.п.)

Одним из аналитических инструментов планирования и расписаний является метод критического пути (МКП). МКП помогает менеджеру увидеть, каким образом можно завершить проект в наикратчайшие сроки . Рассмотрим использование МКП на примере. Предположим, вы планируете открыть производство а главные задачи этого проекта приведены в Табл. 8.1 :

Таблица 8.1. Задачи проекта
Код задачи Описание задачи Предшествующие задачи Время исполнения
A Найти помещение нет 6
B Заключить договор аренды A 2
C Ремонт помещения A,B 8
D Найти менеджера нет 8
E Закупить оборудование A,D 2
F Отработать технологию D 2
G Набрать персонал D,F 8
H Установить и протестировать оборудование A,B,F 4
I Провести испытания все 1
Общее время 41

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

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

В рассматриваемом примере можно выделить два независимых направления ("оборудование" и "продукт"), которые выполняются параллельно. Направление "оборудование" (задачи A, B, C , Е) включает в себя подготовку пространства для производства и закупку оборудования. Направление "продукт" (задачи D, F ,G) включает в себя наем менеджера, персонала и отработка технологии.

Для определения критического пути в схему добавляются сроки выполнения задач (Рис. 8.6).


Рис. 8.6.

Самый длинный путь в проекте называется критическим. В нашем примере это путь от точки А к точке I, имеющий продолжительность 23 недели. Это означает, что весь проект может быть выполнен за 23, а не за 41 неделю, как планировалось изначально.

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

Средняя взвешенная оценка срока выполнения () рассчитывается по следующей формуле:

Предположим, что наиболее вероятный срок решения задачи составляет 10 недель, пессимистический вариант – 14 недель, а в соответствии с оптимистическим вариантом для решения задачи хватит 8 недель.

По формуле ПООТ получим расчетное время:

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

Рассмотрим пример: компания имеет два возможных варианта расширения своего бизнеса. Для каждого варианта подсчитывается ожидаемая прибыль в течение ближайших пяти лет (Табл. 8.2).

Дерево решений для нашего примера будет выглядеть следующим образом:

ожидаемая стоимость для варианта 1 будет определяться как

Для варианта 2 -

Как видно из расчетов, вариант 2 имеет большую "ожидаемую стоимость ". Поэтому он предпочтительнее. В реальной жизни, естественно, нельзя делать окончательный выбор только на основе анализа дерева решений. Наряду с ним необходимо использовать и другие инструменты анализа. Широкие возможности по формированию графиков выполнения проектов, выбору критического пути предоставляют программные пакеты, такие как Microsoft Visio, Project Expert .

Пример 8.1. ООО "Инкомет"

Организационный план.

Описание команды Директор предприятия и руководитель всего комплекса работ по созданию ИП-4., закончил МИФИ в 1960 г., кандидат физико-математических наук, участвовал в разработке множества физических экспериментальных методик, автор 80 статей и 2 изобретений. Имеет опыт сопряжения ИП-4 с действующим оборудованием прокатного стана и взаимодействия с соответствующими службами крупных прокатных производств.

Главный инженер и один из основных участников разработки ИП-4 закончил Куйбышевский авиационный институт им. Королёва, по специальности "Конструирование и разработка радиоаппаратуры". Участвовал в разработке и эксплуатации систем компьютерной автоматизации крупных физических установок, автор нескольких статей и двух изобретений. Программист, разработчик программного обеспечения ИП-4 закончил С.-Петербургский технический университет в 1993 г. Участвовал в разработке множества физических экспериментальных методик, автор крупного программного пакета обработки экспериментальной информации, автор 20 публикаций. Один из основных участников разработки ИП-4.

Направления развития и календарный план работ Работы, выполненные в течение первого года работы программы "Старт" в 2004 – 2005 гг. подтвердили правильность выбранных научно–технических решений и перспективность внедрения измерителя плоскостности ИП-4 в прокатное производство. Намечены дальнейшие работы по трем основным направлениям:

  1. Продолжение испытаний ИП-4 с целью демонстрации возможностей прибора и его преимуществ перед конкурентными технологиями на следующих металлургических предприятиях:
    • Кольчугинский завод цветных металлов;
    • Гайский завод цветных металлов;
    • Щёлковский алюминиевый завод;
    • Саяногорский завод алюминиевой фольги;
    • Самарский металлургический завод;
    • Новолипецкий металлургический комбинат;
    • Белоколитвинский металлургический комбинат. Возможно, в зависимости от конкретной ситуации испытания будут проводиться и на других заводах.
  2. Работы по расширению зон применения ИП-4:
    • участие в разработке системы автоматического регулирования плоскостности на базе ИП-4 для станов холодной прокатки ОАО "НМЛК";
    • участие в разработке системы автоматического регулирования плоскостности на базе ИП-4 для 5-клетьевого стана непрерывной прокатки (ОАО "Северсталь") совместно с АСК;
    • участие в разработке линии контроля плоскостности сертификации листов из титановых сплавов на стане "2000 Прогладочный" ВСМПО-АВИСМА;
    • участие в разработке системы измерения плоскостности на базе ИП-4 для стана горячей прокатки полосы из титановых сплавов.
  3. Работы по усовершенствованию аппаратно-программного комплекса ИП-4:
    • разработка модификации ИП-4 на базе современных цифровых сигнальных процессоров;
    • разработка соответствующего программного обеспечения для модифицированного аппаратного комплекса;
    • создание системы измерения и учета температуры прокатываемой полосы и интеграции ее в систему регулирования плоскостности и ИП-4;
    • переход к использованию в приборе ИП-4 цифровой камеры нового качества.

Более подробный план реализации инвестиционного проекта на 2006 г. приводится в Табл. 8.3 .

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

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

Повышение квалификации по инженерно-техническому направлению – за период с 2006 по 2007 г. планируется обучить от 4 до 8 сотрудников; при общем количестве сотрудников не менее 14 человек пройдет обучение 57%. Планируемый срок обучения - не менее одного сотрудника в 6 месяцев.

Направления повышения квалификации:

  • обучение новым разработкам на базе цифровых сигнальных процессоров фирмы Texas Instrument;
  • цифровая обработка сигналов;

Список специальностей для повышения квалификации:

  • генеральный директор;
  • главный инженер;
  • инженер – наладчик;
  • инженер – программист;
  • инженер – электроник.

В 2006 году в предприятии будет работать 12 человек. В 2007 г. планируется привлечение 2 специалистов.

Поиск и найм дополнительных работников планируется осуществлять для выполнения конкретных задач.

Основной механизм подбора кадров – определение требований к кандидату и объявление конкурса на замещение вакансии.