Обеспечение проектной деятельности. 6358.03.01_РУ.01_1_БИОР. Оглавлени естр
 Скачать 0.78 Mb.
|
|
1.2 Процедура адаптации модели ЖЦ ИС При адаптации модели ЖЦ ИТ в интересах организации или проекта в соответствии с применяемыми политикой и процедурами должны выполняться следующие действия. 1. Руководителем проекта (РП) определяются и документируются обстоятельства, воздействующие на адаптацию. Эти воздействия включают: – стабильность и разнообразие среды функционирования; – коммерческие или эксплуатационные риски, касающиеся заинтересованных сторон; – новизну, размеры и сложность; – дату начала и продолжительность применения; – вопросы целостности, такие как безопасность, защищенность, секретность, удобство применения; – доступность; – вновь возникающие технологические возможности; – бюджетный профиль и доступные организационные ресурсы; – готовность предоставления услуг обеспечивающими системами. 2. При наличии свойств, критичных по отношению к системе, руководитель проекта должен учесть структуры ЖЦ, которые рекомендованы или установлены в качестве обязательных стандартами, соответствующими области критичности. 3. Далее руководитель проекта собирает входные данные от следующих заинтересованных сторон проекта: 11 – правообладатели системы; – заинтересованные стороны соглашения, заключенного организацией; – стороны, вносящие вклад в организационные функции. 4. Руководитель проекта определяет новую (модифицированную) модель жизненного цикла системы в терминах стадий, их назначения, целей и результатов, которые достигаются вследствие применения процессов жизненного цикла в пределах каждой стадии. 5. Проектный офис принимает решение об адаптации базовой модели. 6. Модификация ЖЦ ИС приобретает локальный (для одного проекта и для одной подсистемы) или общекорпоративный характер по решению проектного офиса, по результатам апробации предложенной РП модификации. 1.3 Разработка технико-экономического обоснования Основной целью подготовки ТЭО (технико-экономического обоснования –документа, в котором представлена информация, из которой выводится целесообразность или нецелесообразность создания продукта или услуги) ИТ-проекта является получение финансирования на реализацию соответствующей инициативы. Кроме того, корректно составленное ТЭО может решать следующие задачи: – приоритизация проектов в условиях ограниченных финансовых, человеческих и прочих ресурсов; – определение совокупности организационно-технологических мероприятий по обеспечению заявленных бизнес-выгод от реализации проекта; – обеспечение заинтересованности руководителей бизнес-подразделений в проекте; – формирование основы для оценки соответствия результатов проекта и первоначальных планов. Согласно исследованиям 75 % компаний ставит именно такие цели при подготовке ТЭО, в то же время всего лишь 40 % из них считают, что используемые ими методы позволяют получить корректную оценку эффективности внедряемого ИТ-решения. Помимо обозначенных задач ТЭО может обеспечивать входную информацию для устава проекта как ключевого документа интегрированного управления проектом. Для того чтобы ТЭО обеспечивал качественную информацию, рекомендуется структурировать идентифицированные бизнес-выгоды ИТ-проекта как это показано в таблице 1. Таблица 1. Матрица структурирования выгод ИТ-проекта В соответствии с предлагаемым подходом бизнес-выгоды можно классифицировать по двум факторам: характеру воздействия на бизнес и степени определенности. Таким образом, каждая 12 выгода по проекту размещается на пересечении соответствующих значений двух обозначенных факторов. Использование матрицы структурирования выгод начинается с определения характера воздействия на бизнес каждой из них. Определены три типа воздействия. 1. Создание новых возможностей: функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам. 2. Повышение эффективности операций: функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно. 3. Отказ от операций: информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес- процессов. После определения характера воздействия необходимо классифицировать каждую бизнес- выгоду по степени определенности от менее определенных к более определенным: наблюдаемые (качественные), измеримые, количественные, финансовые. Качественные бизнес-выгоды могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта. Измеримые бизнес-выгоды поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения. Количественные бизнес-выгоды аналогично измеримым характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но в отличие от измеримых значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности. Финансовые бизнес-выгоды – это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Выбор той или иной категории для конкретной бизнес-выгоды производится на основе доступной информации о ней до момента реализации инвестиций. Каждая бизнес-выгода на момент ее идентификации относится к наименее определенной категории – наблюдаемая. По ходу анализа необходимо максимальное количество бизнес-выгод перенести в финансовую категорию для построения экономической модели окупаемости проекта, кроме доходной части, в которой должна быть отражена и расходная. В качестве инструмента оценки стоимости проекта и системы авторы рекомендуют использовать модель совокупной стоимости владения системы – общей величины целевых затрат, которые вынужден нести владелец с момента начала реализации вступления в состояние владения до момента выхода из состояния владения и исполнения владельцем полного объёма обязательств, связанных с владением, рассмотрение которой будет произведено в разделе, посвященном управлению стоимостью проекта. 13 1.4 Формирование бизнес-цели проекта Бизнес-цель – это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес- цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится просто выдать продукт, а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной. Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста. Бизнес-цель должна быть достаточно веской, чтобы организация решилась перейти к разработке устава проекта, документа, в соответствии с лучшими практиками инициирующего выполнение проекта. В качестве инструмента, позволяющего определить необходимость реализации проекта, может быть использовано ТЭО, или бизнес-кейс, проекта. 1.5 Разработка устава проекта Устав проекта – это документ, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально- ориентированных и матричных организациях, т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта, должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за днем подписания устава. Процесс разработки устава проекта уже подразумевает, что компания заинтересована в достижении какой-то цели или решении имеющейся проблемы и готова выделять под это ресурсы. Следовательно, со стороны организации-заказчика есть мотив инвестировать средства и ресурсы в генерацию такой информации, которая позволит разработать корректный устав проекта. К информации, имеющей ключевое значение для составления устава, относятся: – стратегические и тактические цели организации-заказчика; 14 – формулировка требований организации-заказчика; – ТЭО; – контракт; – внутрикорпоративная методология управления проектами и соответствующие политики. Решение о выполнении проекта – итог процесса отбора проектов, основанного на информации, которая изложена в вышеуказанных документах. Таким образом, крайне важно давать прямую ссылку в соответствующих разделах устава на них с тем, чтобы придать уставу больший вес. Обязательные разделы устава проекта следующие: – название проекта. Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания; – бизнес-причина возникновения проекта. Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте; – бизнес-цель должна быть сформулирована заказчиком исходя из стратегических и тактических целей компании; – требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта. Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта; – расписание основных контрольных событий. На этапе формирования устава должно быть обязательно указано время начала и завершения проекта, при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика. Рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя- пятью. Принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий – это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств; – участники проекта. Перечисление заинтересованных сторон проекта, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него; – окружение проекта. Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации- заказчика – к использованию его результатов; – допущения относительно организации и окружения, а также внешние допущения. Набор условий, которые должны быть выполнены наряду с созданием продукта проекта для достижения 15 результата проекта. Допущения обусловливают риски проекта; во время проекта происходит их мониторинг. Пример допущений: • компетенции команды проекта достаточно для выполнения предпроектного обследования; • организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта. При составлении устава проекта допущения формулируются со стороны организации- заказчика об организации-исполнителе; – ограничения относительно организации и окружения, а также внешние ограничения. Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ. При составлении устава проекта ограничения формулируются со стороны организации- заказчика об организации-исполнителе и о проекте в целом; – объем денежных средств, выделенных на достижение бизнес-цели. На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины, и ошибка в оценке может составлять от –20 % до +100 %; – назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор. Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта – объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта. Роль спонсора проекта обычно берет на себя менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект. Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например: • утверждать бизнес-цели проекта, включая расписания и бюджет, и вносимые в них изменения; • назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения; • формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта; • вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов; • принимать решения о внесении изменений в базовую линию проекта. 16 Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта. Администратор (координатор) проекта – это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. Формировать всю команду и тем более сразу указывать имена всех ее членов не принято – функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта. После подготовки устава в соответствии с предложенным шаблоном рекомендуется произвести проверку его корректности. Автор устава, как правило, спонсор проекта, должен обязательно убедиться, что: • информация в уставе, а также сделанные в нем допущения соответствуют исходным данным, которые содержатся в стратегических и тактических целях организации-заказчика, задокументированных предварительных требованиях организации-заказчика, ТЭО, контракте и внутрикорпоративных политиках и методологиях; • все разделы предложенного формата устава проекта заполнены в соответствии с рекомендациями; • в самом документе отсутствуют противоречия; • список рассылки устава проекта включает все функциональные группы, сотрудники которых должны войти в проектную команду, а в идеале – и всех участников проекта внутри организации- заказчика. Устав проекта является установочным документом, описывающим связь проекта с операционной деятельностью компании. По этой причине внесение значительных изменений в текст данного документа не рекомендуется, а при возникновении такой обоснованной необходимости стоит разработать новый устав проекта, более полно отвечающий реалиям реализуемого проекта. |