Обеспечение проектной деятельности. 6358.03.01_РУ.01_1_БИОР. Оглавлени естр
 Скачать 0.78 Mb.
|
|
2.4 Критические факторы успеха Проект, будучи инициативой с весьма ограниченными ресурсами, всегда направлен на оптимальное их использование. По этой причине в реализации необходимо уделять внимание обеспечению того или иного критического фактора успеха только в тот момент времени, когда это действительно важно для проекта, и снижать интенсивность привлечения ресурсов в прочие моменты времени, когда эти ресурсы могут быть задействованы на обеспечении решения прочих задач. На рисунке 4 отражена модель, описывающая значимость каждого из критических факторов успеха на различных этапах ЖЦ ИС. 26 Рисунок 4. Модель критических факторов успеха в динамике этапов жизненного цикла информационной системы Указанные баллы отражают нормированные по десятибалльной шкале оценки значимости критических факторов на соответствующих стадиях. Наличие спонсора из числа высшего руководства компании. Наличие спонсора у проекта зачастую предопределяет результат проекта. Данный фактор имеет особенно большое значение в начале проекта, когда необходимо обеспечить политическую поддержку проекта и необходимые ресурсы; не меньшее значение он имеет в конце проекта, когда необходимо обеспечить принятие и переход к продуктивной эксплуатации системы в полном объеме в запланированный срок. Компетентный состав команды. В составе команды проекта должны быть специалисты, обладающие необходимым опытом внедрения ERP-систем. Типична ситуация, когда данная группа представлена консультантами системного интегратора и техническими специалистами вендора (поставщик (зачастую, производитель) товаров и услуг под своей торговой маркой). В то же время в проекте необходимо наличие сотрудников самой фирмы, с одной стороны – как основных носителей знаний о бизнес-процессах компании, с другой – для получения знаний о системе и формирования и развития соответствующих компетенций внутри компании. Межфункциональная координация. Интеграционный, т.е. комплексный, характер решения накладывает серьезные требования на межфункциональную координацию как среди членов проектной команды, так и владельцев бизнес-процессов. Данный фактор имеет высокое значение в начале проекта, когда все участники из различных подразделений формируют общие цели проекта, и в конце, когда необходимо проанализировать достижения соответствующих целей и, убедившись, что не возникло межфункциональных противоречий, завершить проект. Обеспечение «умного» реинжиниринга бизнес-процессов. Реинжиниринга бизнес-процессов – фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимального эффекта производственно-хозяйственной и финансово-экономической деятельности, оформленное соответствующими организационно-распорядительными и нормативными документами. Построение системы вокруг неоптимизированных процессов не имеет смысла. Владельцы бизнес-процессов должны иметь представление о том, как и какие 27 процессы будут автоматизированы. Во многих методологиях внедрения предполагается, что процессы в компании будут по большей части перестроены в соответствии с логикой, реализованной в системе, в связи с чем данный фактор приобретает еще большую значимость. Данный фактор имеет большое значение на фазе концептуального проектирования, когда производится анализ существующих бизнес-процессов и проектирование новых бизнес-процессов в системе. Привлечение конечных пользователей. С самого начала проекта конечные пользователи должны быть активно вовлечены в проект. Они должны осознавать важность внедрения системы, а их разумные требования не должны быть проигнорированы. Очевидно, что их участие особенно важно на стадии формирования требований к системе, а также при миграции данных и интеграционном тестировании. Принятие системы сотрудниками. Принятие системы пользователями позволяет в короткие сроки получить запланированный эффект от её внедрения и, следовательно, сократить время окупаемости проекта. Принятие во многом основано на том, понимают ли сотрудники концепцию, реализованную в системе; таким образом, аналогично реинжинирингу бизнес-процессов данный фактор имеет наибольшую значимость на этапе концептуального проектирования. Мотивация сотрудников и членов проектной команды. Сотрудники должны быть заинтересованы в достижении целей проекта, это снизит возможное сопротивление и повысит лояльность к системе. Также надо иметь в виду, что конфликтующие цели должны быть устранены из системы мотивации сотрудников. Наибольшую значимость данный фактор приобретает на последнем этапе проекта, когда от членов проектной команды требуется наибольшее усилие для обеспечения работоспособности системы и устранения выявленных недостатков. Продуманная стратегия коммуникаций. Коммуникации как внутри проектной группы, так и за её пределами (с будущими пользователями) являются важным аспектом, обеспечивающим успех проекта внедрения. О целях, задачах и объеме проекта должно быть известно всем участникам проекта; кроме того, участники должны быть в кратчайшие сроки информированы обо всех происходящих изменениях как внутри проекта, так и в деятельности организации. Для решения задачи регулярной информированности должен быть выстроен план и стратегия коммуникации. Особую важность данный параметр имеет на первых двух стадиях проекта, когда в тесном сотрудничестве с менеджментом компании определяются цели и план проекта; также его значимость повторно возрастает на финальной стадии, ибо на этом этапе проектная команда должна провести большое количество информационных семинаров перед выводом системы в продуктив. Обеспечение обучения и тренингов. Стратегия и план обучения должны быть сформированы на начальных этапах проекта, а не после его завершения, причем в них должна учитываться необходимость развития компетенции как технических специалистов, администраторов системы, так и конечных пользователей. Кроме того, надо иметь в виду, что при обучении сотрудники должны не только приобретать технические навыки (тренинги) работы в системе, но и получать понимание концепций, реализованных в ERP-системе. Обучение работе в системе должно быть включено отделом управления человеческим капиталом в план развития релевантных сотрудников, а также должна быть предусмотрена возможность обучения новых сотрудников и тех, кому требуется повторное обучение. 28 2.4 Формирование списка работ (операций) проекта Определение списка работ предполагает определение и документирование работ, запланированных для выполнения. Инструментальным средством для определения списка работ, а также для оценки их взаимосвязи и длительности служит иерархическая структура работ (ИСР). Перед началом определения списка работ рекомендуется еще раз проанализировать описание содержания проекта, ограничения и допущения с точки зрения полноты списка операций – этот список будет основой для составления смет, планирования сроков выполнения и контроля проектных работ. Процесс определения состава операций начинается с определения степени детализации операций. Количество операций должно быть достаточным для того, чтобы ответственный за пакет работ мог отслеживать ход исполнения и осуществлять координацию работ. Число операций не должно быть слишком большим, затрудняющим оценку общего состояния проекта с помощью системы отчетности о ходе выполнения проекта. Далее, например, методом мозгового штурма выполняется разбиение пакетов работ на операции. На этом этапе важно проследить, чтобы были определены все операции, необходимые для реализации проекта, при этом длительность (степень детализации) не рассматривается. На следующем этапе выполняется учет степени детализации. Если количество выделенных операций мало, их разбивают на более мелкие, если велико – родственные операции группируют. Степень детализации зависит от цели детализации. Детализация операций для разработки иерархического расписания крупного проекта будет существенно отличаться от степени детализации при разработке расписания выполнения малого проекта. Степень детализации также зависит от количества контрольных событий, которые планируется отразить в расписании проекта. Состав операций может определяться последовательно, методом набегающей волны. Этот метод применяется в крупных или долгосрочных проектах, когда имеется неопределенность относительно выполнения некоторых работ. При использовании метода набегающей волны пакеты работ, расположенные в отдаленном будущем, планируются только на высоком уровне, в то время как пакеты работ, расположенные ближе по оси времени, планируются детально. Этот метод рекомендуется применять при создании детальных планов на стадии разработки и производства. 3 РАЗРАБОТКА РАСПИСАНИЯ ПРОЕКТА 3.1 Исходные данные для разработки расписания Исходной информацией для процесса разработки расписания является описание содержания проекта. Оно включает допущения (документированные факторы, относящиеся к расписанию, которые при разработке расписания считаются достоверными) и ограничения (факторы, ограничивающие свободу выбора команды управления проектом при проведении анализа сети расписания и влияющие на составление расписания проекта). При разработке расписания учитываются два основных типа ограничений по времени: 29 – требуемые даты для начала или завершения операции, которые можно использовать для ограничения начала или завершения операции; – контрольные события, вследствие чего получение определенных результатов работ привязывается к определенным датам, изменить которые можно только посредством одобренных изменений. Для разработки расписания рекомендуется использовать следующие инструменты и методы. Диаграмма Гантта (рисунок 5) – диаграмма, которая использует горизонтальные полосы для представления операций проекта, показывает даты начала и завершения каждой операции и проекта относительно горизонтальной шкалы времени. Рисунок 5. Диаграмма Гантта проекта Диаграмма, построенная по методу критического пути (метод планирования расписания и управления сроками проекта, в основе которого лежит определение наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи) – методу анализа сети расписания, проводимого при помощи модели расписания. Критический путь представляет группу операций, которые не могут быть задержаны без изменения, отсрочки даты завершения всего проекта. При использовании метода критического пути рассчитываются теоретические даты раннего старта и раннего финиша и позднего старта и позднего финиша для всех плановых операций без учета ограничений по ресурсам. Этот расчет производится путем проведения анализа прямого и обратного проходов по путям сети расписания проекта. Полученные даты раннего и позднего старта и финиша показывают периоды времени, в пределах которых следует планировать данную операцию, исходя из ее длительности, логических взаимосвязей, опережений, задержек и прочих ограничений. 30 Диаграмма контрольных событий – инструмент для разработки расписания проекта, построение которого включает следующие действия: – сбор исходной информации для построения диаграммы; – построение сетевой диаграммы, отражающей взаимосвязь операций; – определение уровня детализации контрольных событий – количества контрольных событий, отражаемых на диаграмме; – выбор контрольных событий – событий, которые являются главными для продвижения проекта; – упорядочивание контрольных событий – изучение взаимосвязей и определение последовательности их выполнения; – нанесение контрольных событий на детальное расписание проекта; – проверка равномерности распределения контрольных событий по расписанию проекта. Результатами процесса разработки расписания являются: – расписание проекта. Расписание проекта может быть разработано детально или укрупненно как расписание контрольных событий. Расписание может быть представлено в табличном виде или иметь графическое представление в виде сетевых диаграмм, столбиковых горизонтальных диаграмм или диаграмм контрольных событий; – данные для модели расписания. Обязательные данные для расписания проекта включают в себя контрольные события расписания, плановые операции, параметры операции и документацию всех имеющихся допущений и ограничений, а дополнительные – требования к ресурсам по периодам времени, альтернативные расписания, резервы на непредвиденные обстоятельства; – базовый план расписания – особый вариант расписания проекта, разрабатываемый посредством анализа сети расписания модели расписания, принимается и утверждается командой управления проектом в качестве первоначального (базового) плана расписания с указанными базовым стартом и базовым финишем. Базовый план расписания используют для выявления отклонений фактических сроков выполнения операций от плановых; – требования к ресурсам (обновления); – параметры операции (обновления); – календарь проекта (обновления); – запрошенные изменения. В процессе разработки расписания могут появиться запрошенные изменения, которые обрабатываются в процессе общего управления изменениями; – план управления проектом (обновления). План управления проектом обновляется с отражением всех одобренных изменений в способах управления расписанием проекта. Технология разработки расписания. При разработке расписания рекомендуется соблюдать следующую последовательность работ: – определить перечень операций, которые должны быть включены в расписание; – определить взаимосвязь операций; – определить длительность каждой операции; – рассчитать с помощью прямого прохода раннее расписание для каждой операции; – рассчитать с помощью обратного прохода позднее расписание для каждой операции; – вычислить временной резерв для каждой операции; – определить критический путь; – сравнить дату предполагаемого завершения проекта с датой завершения проекта по обязательству; 31 – подкорректировать расписание или дату завершения проекта по обязательству, если завершение проекта по расписанию предполагается раньше этой даты; – определить ограничения на ресурсы; – откорректировать расписание в соответствии с ограничениями на ресурсы; – проверить, не планируется ли завершение проекта по откорректированному расписанию раньше даты обязательства; – согласовать расписание. 3.2 Разработка расписания проекта методом критического пути Рассмотрим алгоритм разработки расписания проекта с использованием метода критического пути. 1. Создать перечень операций, которые должны быть включены в расписание. Используется ИСР, перечень идентичен нижнему уровню иерархической структуры работ. 2. Определить длительность каждой операции. Длительность каждой операции определяется в рамках процессов оценки трудоемкости и определения длительности операций. 3. Определить предшествующую операцию для каждой операции. Предшествующая операция каждой операции определяется в течение заключительных этапов составления иерархической структуры работ. 4. Рассчитать с помощью прямого прохода (forward pass) раннее расписание (early schedule): ранний старт (ES) и ранний финиш (EF) для каждой операции. При расчете раннего расписания для операций требуется придерживаться нескольких правил составления расписаний (scheduling conventions). В расписании старт первой операции всегда назначается на дату старта проекта. Эта дата является входом плана проекта. Первая дата старта является стартом проекта. Дата раннего финиша – это дата раннего старта плюс длительность операции. При этом применяется следующее правило. Считается, что каждая операция начинается в момент начала того периода, в который она стартует, и оканчивается в момент завершения периода, в который она завершается. Это означает, что если длительность операции составляет один день и если она начинается первого января, то заканчивается данная операция также первого января. В соответствии с данным правилом ранний финиш любой операции равен раннему старту плюс длительность минус один. Таким образом (пример в таблице 2), операция 1 начинается в день 1 и заканчивается в день 15. Следующая операция должна начаться в следующий доступный временной период: поскольку операция 1 заканчивается в день 15, операция 2 должна начаться в день 16, а закончиться в день 20. Операции 3 и 4 представляют следующую проблему. Эти операции зависят от операции 2, т.е. операция 2 должна окончиться перед их стартом. Датой раннего старта обеих операций будет день 21. Расчет раннего финиша: EF= ES + Длительность – 1. 5. Рассчитать с помощью обратного прохода (backward pass) позднее расписание (late schedule) для каждой операции. Для выполнения обратного прохода необходимо начинать с последней операции, которая была выполнена в раннем расписании. Логическим обоснованием этого является следующее: если раннее расписание определяет самую раннюю дату завершения проекта, то в обратном проходе мы ищем для всех операций самые поздние даты их выполнения, при которых проект мог бы быть 32 полностью выполнен. Мы начинаем с наиболее поздней из дат раннего финиша, соответствующей завершению последней операции. Это время позднего финиша (LF). Для получения времени позднего старта (LS) из времени позднего финиша вычитается длительность. Даты позднего расписания (поздний старт и поздний финиш) для операции 11 будут, соответственно, днями 90 и 94. Поскольку дата позднего старта операции 11 – день 90, операции 10 и 3 должны быть окончены не позднее дня 89. Это будет датой позднего финиша для обеих операций. Таков самый поздний срок завершения данных операций для того, чтобы обеспечить завершение проекта в день 94 и дату позднего старта операции 11. Для получения дат позднего старта для каждой операции вычитаются их длительность. При рассмотрении операции 2 надо быть очень внимательными в выборе даты позднего финиша, которая также согласуется с датами позднего старта операций 3, 4 и 6. Поскольку датами позднего старта операций 3, 4 и 6 являются дни 86, 53 и 21, соответственно, датой позднего финиша операции 2 является день 20. Расчет позднего финиша: LS = LF – Длительность + 1. Таблица 2. Операции проекта 6. Вычислить временной резерв (float) для каждой операции. При расчете дат раннего и позднего расписания проекта обнаруживается, что иногда даты раннего и позднего расписания совпадают, а для некоторых операций они различны. В данных операциях было отличие между датой раннего старта и позднего старта. Разница между этими датами называется временным резервом (float или slack). |