ЗараменскихУЖЦИСмонография-148-272. Управление жизненным циклом информационных систем
 Скачать 3.15 Mb.
|
|
Итого 2 250 000 500 000 1 404 583 Как можно видеть из вышеприведенных вычислений, несмотря на то, что де- нежные поступления при реализации проекта будут превышать инвестиции на 1,75 млн., чистая приведенная стоимость будет меньше, порядка 1,4 млн. с учетом текущей ставки дисконтирования, применяемой для каждого периода. В MS Excel для расчета NPV используется функция: =ЧПС(). В англий- ской версии: =NPV() Синтаксис: =NPV(rate;value1;[value2]...) rate – ставка дисконтирования, выраженная в единицах за период. Так, если представлены годовые потоки денежных средств, то ставка должна быть годовая. value1;[value2]... – представленные потоки денежных средств по перио- дам фиксированной длины, которые могут быть представлены как диапазо- ны, конкретные значения через точку запятой или несколько диапазонов. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 179 Возврат инвестиций (ROI) Возврат инвестиций (Return On Investment, ROI) – отношение полученных (сэко- номленных) денег от реализации проекта к вложенным в него средствам. ROI = 180 % означает, что на каждый вложенный рубль вернулась (или была сэкономлена) сум- ма в 1 рубль 80 копеек. Смысл показателя ROI в определении чистой прибыли от инвестиций, которая необходима для получения прибыли. Он также может говорить о том, насколько эффективно используются активы. В MS Excel для расчета IRR используется функция: =ВСД(). В англий- ской версии: =IRR() Синтаксис: =IRR(values;[guess]) values – диапазон с потоками денежных средств. guess – необязательное поле, используемое для определения ставки ме- тодом подбора. Предположение, о том, какая будет величина ставки, необ- ходимо для начала отсчета именно от этого значения. ПРИМЕР Для приведенного ранее примера расчета NPV и значений денежного потока сумма CF по всем периодам составит 1,75 млн, а значит при исходном значении инвестиций в 500 тыс. коэффициент возврата инвестиций будет равен 250 %. Чистый денежный поток (CF t ) -500 000 +1 000 000 750 000 500 000 Период окупаемости инвестиций (Payback Period) Период окупаемости инвестиций (Payback Period, PP) – Продолжительность вре- мени, в течение которого обеспечивается возврат первоначальных инвестиций. Как правило, инвесторы склонны более благоприятно относиться к про- ектам с более быстрым оборотом средств, нежели преследовать долгосроч- ные выгоды, которые ассоциированы с большими рисками. Для определения, в какой момент проект достигнет точки окупаемости, необходимо последовательно рассчитывать показатель NPV для каждого периода проекта, пока значение NPV Этот показатель определяется последовательным расчетом NPV для ка- ждого периода проекта, точка, в которой NPV станет положительным, будет являться точкой окупаемости. ГЛАВА 3. Особенности управления проектами по внедрению КИС 180 ПРИМЕР Год (t) NPV 0 -500 000 1 909 091 2 619 835 3 375 657 Итого 1 404 583 Так, для рассмотренного при расчете NPV примера точка окупаемости будет достигнута уже к первому году, кода NPV станет больше 0. 3.4.2.4. Управление коммуникациями Управление реализацией проекта и решение спорных вопросов / проблем Правильное и непрерывное управление проектом является залогом его успешного осуществления и завершения. Появление промежуточных ре- зультатов в ходе реализации проекта позволяет начать их использование еще до завершения проекта в целом. Например, завершение этапа по авто- матизации учета основных средств предприятия позволяет, не дожидаясь окончания проекта, осуществлять расчет амортизации. Для решения возникающих в ходе проекта спорных вопросов и проблем применяется процедура управления решением спорных вопросов, призван- ная обеспечить качественное выполнение задач проекта в срок и снизить степень влияния связанных с этими вопросами факторов риска. Решение каждого вопроса (проблемы) проходит четыре стадии: ‒ идентификация проблемы; ‒ принятие к дальнейшему рассмотрению либо отказ от такового; ‒ одобрение предложенного решения; ‒ закрытие проблемы. Проблема может быть идентифицирована членами команды внедрения, пользователями или управленческим персоналом. В момент регистрации каждый спорный вопрос должен быть задокументирован с помощью Фор- мы регистрации проблем или аналогичного документа. Для принятия реше- ния о целесообразности документирования проблемы используется один из приведенных ниже критериев: ‒ На сколько существенно повлияет отказ от решения этой проблемы на проект (например, вызвать задержку, изменение курса проекта, снижение качества или увеличение стоимости проекта)? ‒ Выходит ли проблема за рамки одной задачи или требует внимания более чем одного консультанта? ‒ Требует ли проблема решения со стороны куратора или руководи- теля проекта? УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 181 Проблемы должны оцениваться по степени своего влияния на проект по следующим категориям важности: 1. Высокая (такие проблемы должны быть рассмотрены руководителем проекта и утверждены Координационным советом). ПРИМЕР Изменение порядка лимитирования накладных расходов относительно порядка, описанного в проектном решении. 2. Средняя (должны быть рассмотрены и решены руководителем про- екта совместно с кем-либо из заместителей директоров предприятия заказ- чика. Обо всех принятых таким образом решениях руководитель проекта отчитывается на очередном заседании Координационного совета). ПРИМЕР Необходимость перераспределения должностных обязанностей между двумя или несколькими подразделениями, работающими в системе. 3. Низкая (рассмотрение и решение таких проблем осуществляются руководителем проекта самостоятельно. Обычно проблемы такого рода не имеют альтернативных решений. Суть такой проблемы обычно заключается в необходимости принять конкретное заранее известное решение). ПРИМЕР Необходимо организовать своевременность ввода первичных документов на складе N. Каждая проблема должна быть рассмотрена руководителем проекта со стороны исполнителя, в результате чего ей должен быть назначен один из следующих статусов: ‒ Отклонена – проблема отклоняется, если она не препятствует нор- мальному ходу выполнения проекта и не влияет на его конечный ре- зультат. Перед тем как отклонить проблему, необходимо обсудить это решение с лицом, идентифицировавшим эту проблему. Это по- зволит инициировавшему лицу еще раз сформулировать суть про- блемы, и, возможно, более удачно передать ее важные аспекты. ‒ Отложена – проблема откладывается, если решение по этой про- блеме не может быть принято в момент рассмотрения. В этом слу- чае обязательно должна быть указана дата, до которой откладыва- ется решение проблемы. ‒ Объединена – проблемы, связанные тесно между собой, должны быть объединены. При объединении одна из проблем должна быть закрыта, а описание другой проблемы должно быть изменено с уче- том произошедшего объединения. ‒ Принята – для принятых проблем производится рассмотрение и оценка вариантов решения, выбор варианта и назначение исполни- теля для его реализации. ГЛАВА 3. Особенности управления проектами по внедрению КИС 182 Как только по какой-либо проблеме принято решение, оно должно быть преобразовано в последовательность шагов по его реализации, в числе ко- торых должно быть определено: ‒ Какие задачи должны быть выполнены. ‒ Какие документы, отчеты или другие рабочие продукты должны быть подготовлены. ‒ Кто будет отвечать за выполнение задач и за техническую подготовку. ‒ Критерии качества и завершения. Как правило, списком проблем управления проектом занимается про- ектный менеджер и затем последовательно передается на рассмотрение ку- ратору и Координационному совету (с занесением записей в проектную до- кументацию – как правило, Протокол выполненных работ и Журнал регист- рации проблем). Способы предотвращения конфликтных ситуаций Можно представить множество причин возникновения конфликтных ситуаций в процессе развития проекта. В данном разделе выделены основ- ные источники и причины возникновения таких проблем, а также возмож- ные пути их предотвращения. 1. Цель проекта в контексте решения критических вопросов предпри- ятия должна быть поставлена перед группой внедрения достаточно четко. Высшее руководство предприятия должно заявить о полной поддержке лю- дей, задействованных в проекте. В противном случае это приведет к сниже- нию мотивации и личной заинтересованности и, в конечном итоге, сущест- венно снизит вероятность успешного и эффективного завершения проекта. 2. Представители проектной команды должны регулярно встречаться друг с другом и с членами Координационного совета с целью обсуждения те- кущих вопросов, анализа состояния проекта и обмена мнениями. В против- ном случае может возникнуть ситуация, когда проект не будет расцениваться как самая приоритетная задача, а цели и задачи станут несколько размытыми. Созыв Координационного совета также позволяет решать спорные вопросы и подводить промежуточные итоги по выполненному объему работ. Обсуждение способов решения конфликтных ситуаций должно прово- диться в максимально полном составе проектной команды. Каждый ее пред- ставитель представляет отдельное подразделение и, следовательно, имеет свое видение проблем и методов их решения. Различия в подходах должны быть учтены и, как следствие, должны быть выработаны единые порядок и нормы взаимодействия. 3. Другой потенциальный источник конфликтных ситуаций – это при- оритеты управления и оценка производительности. Типичная ситуация, когда член проектной команды напрямую отчитывается перед своим непо- УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 183 средственным руководителем и косвенно – перед руководителем команды внедрения. Требования, высказанные обоими руководителями, вступают в противоречие, и рядовой член команды внедрения находится в состоянии растерянности. Ситуация, когда человек задействован на двух работах, по- тенциально может вылиться в две проблемы: ‒ члены проектной команды не поощряются в материальном плане за совмещение двух работ, и ‒ их вклад в общее дело остается недооцененным. 4. Исторически сложилось, что оценка действий сотрудника в основ- ном зависит от того, насколько успешно он работает на своем непосредст- венном рабочем месте. Построение системы учета вклада каждого члена проектной команды в проект гарантирует, что он будет лучше осознавать собственную значимость, а так же предоставит ему дополнительные стиму- лы к повышению эффективности выполняемых работ. Моральное и материальное поощрение членов проектной команды по результатам выполненных работ следует рассматривать, с одной стороны, как возможный источник мотивации, а с другой стороны – как источник конфликтных ситуаций, как в пределах группы внедрения, так и при взаи- модействии с другими подразделениями предприятия. Существует множе- ство систем поощрений, которые можно использовать в целях повышения мотивации. Любая из них должна быть тщательно взвешена с позиции ее влияния на работу команды. 3.4.2.5. Управление качеством На сегодняшний день существует бесчисленное множество определений понятия «качество», в частности, для различных отраслей бизнеса / про- мышленности. Одно из самых употребляемых определений было сформу- лировано в 1994 в Международном стандарте ISO 8402:94 «Управление ка- чеством и обеспечение качества». «Качество – совокупность характеристик объекта, относящихся к его способности удовлетворять установленные и предполагаемые потребности». Управление качеством системы является комплексной задачей, для ус- пешной реализации которой возможно, во-первых, фокусироваться на про- изводстве качественного продукта изначально, а во-вторых, проводить свое- временную оценку и корректировку уровня качества. В первом случае, мероприятия направлены на обеспечение соответст- вия проекта и ИС как таковой ранее определенным требованиям. ‒ Использование стандартов (управления проектами, разработ- кой программного обеспечения, управления ЖЦ и т.п.). ГЛАВА 3. Особенности управления проектами по внедрению КИС 184 Разумеется, опыт аналогичных проектов многих компаний и «лучшие мировые практики» дают общие руководства по управлению качеством и предлагают различные методики и инструменты, использование которых разумно и целесообразно. Однако необходимо понимать, что для их эффек- тивного применения необходимо обладать соответствующим опытом и гра- мотно комбинировать разные стандарты во избежание их конфликтов между собой и несовместимости со спецификой предприятия или проекта. ‒ Обучение, повышение квалификации персонала, использова- ние внешних консультантов. Повышение уровня компетенций проектной команды является широко применяемым и даже обязательным условием получения качественных ре- зультатов. ‒ Четкие критерии качества и стабильная внешняя среда проекта. Вероятность повышения качественного продукта повышается, если кри- терии оценки информационной системы заранее четко сформулированы и прозрачны, а рамки проекта остаются неизменными, без уменьшения сро- ков или стоимости. В случае же оценки и корректировки качества, очень важны: ‒ Прототипирование и тестирование с пользователями. Уже рассмотренное ранее в разделе ЖЦ ИС, прототипирование сущест- венно снижает риски получения некачественного или несоответствующего требованиям продукта и своевременная проверка функциональности с поль- зователями при тестировании также способствует выявлению неверных ар- хитектурных / функциональных / интерфейсных решений и их последую- щей корректировке. Постоянное улучшение системы менеджмента качества Потребители и другие заинтересованные стороны Потребители и другие заинтересованные стороны Основные положения для введения системы менеджмента качества: ISO 9000, ISO 9001, ISO 9004 Ответственность руководства Управление ресурсами Измерения, анализ и улучшение Выпуск продукта ПЛАНИРУЙ ДЕЙСТВУЙ ДЕЛАЙ КОНТРОЛИРУЙ ISO 10015 Требования Удовлетво- ренность ISO 10001 ISO 19011 ISO 10005 ISO 10006 ISO 10007 ISO 10013 ISO 10014 УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 185 ‒ Регулярный контроль и анализ. Контрольные карты, диаграмма Ишикавы для причинно-следственного анализа, план / факт анализ, планы совершенствования качества и процес- сов и другие методы управления проектами в зависимости от ситуации ока- зываются достаточно полезными в целях мониторинга качества. Среди прочих стандартов, содержащих рекомендации по управлению качеством систем: ‒ ISO 9000:2005 «Системы менеджмента качества. Основные поло- жения и словарь». ‒ ISO 9001:2008 «Системы менеджмента качества. Требования». ‒ ISO 9004:2009 «Менеджмент с целью достижения устойчивого ус- пеха организации. Подход с позиции менеджмента качества». ‒ ISO 10001:2007 «Менеджмент качества. Удовлетворенность потреби- теля. Руководящие указания по кодексу поведения для организаций». ‒ ISO 10005:2005 «Системы менеджмента качества. Руководящие ука- зания по планам качества». ‒ ISO 10006:2005 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов». ‒ ISO 10007:2003 «Системы менеджмента качества. Руководящие указания по менеджменту конфигурации». ‒ ISO/TR 10013:2001 «Рекомендации по документированию систем менеджмента качества». ‒ ISO/TR 10014:2006 «Менеджмент качества. Руководящие указания по реализации финансовых и экономических выгод». ‒ ISO 10015:1999 «Управление качеством. Руководящие указания по обучению». ‒ ISO 19011:2011 «Руководящие указания по аудиту систем менедж- мента». ISO 10006:2003 (ГОСТ Р ИСО 10006-2005) Международный стандарт: ISO 10006:2003 «Управление качеством. Руководящие указания по менеджменту качества проектов». Российский аналог: ГОСТ Р ИСО 10006-2005 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании». Стандарт акцентирует внимание своей аудитории на двух основных ас- пектах качества в управлении проектами: качестве процессов проекта и ка- честве продукции, так как недостаточное внимание / реализация требований хотя бы к одному из них может оказать негативное воздействие на ход про- екта, его результаты, саму организацию. Помимо собственных определений многим проектным терминам, ISO 10006:2003 описывает организационный аспект управления качества в час- ти ответственности руководства, затем переходя к управлению ресурсами, ГЛАВА 3. Особенности управления проектами по внедрению КИС 186 изготовлением продукта, и непосредственно к качеству (измерениям, анали- зу и улучшениям). Еще один раздел стандарта (глава «Системы менеджмен- та качества при проектировании», со ссылкой на ISO 9000), приводит во- семь основных принципов: ориентацию на потребителя, лидерство руково- дителя, вовлечение работников, процессный подход, системный подход к менеджменту, постоянное улучшение, принятие решений на основании фак- тов и взаимовыгодные отношения с поставщиками [57, с. 8]. Рассмотрим основные выделяемые стандартом процессы подробнее: Раздел Процессы Комментарии Ответственность руководства ‒ Стратегический процесс управления Обзор этапов и принципов менеджмента качества Управление ре- сурсами ‒ Процессы, связанные с ресурсами Принципы планирования ресурсов и их контроля (срав- нение план / факт, примеры корректирующих мер) ‒ Процессы, связанные с персоналом Установление организационной структуры проекта, вы- бор персонала с необходимыми компетенциями и его по- следующее развитие Изготовление продукции ‒ Взаимозависимые про- цессы Работа с требованиями стейкхолдеров проекта, управле- ние взаимодействием и получением обратной связи ‒ Процессы, связанные с областью применения Определение концепции и результатов применения раз- рабатываемого продукта (системы), документирование и последующий контроль необходимых для достижения целей проекта действий ‒ Процессы, связанные со временем Определение зависимостей между проектными актив- ностями и ограничений задач типа «Start no later than», «Must finish on», оценка их продолжительности и на ос- нове полученных данных формирование графика проек- та с контролем выполнения ‒ Процессы, связанные со стоимостью Оценка стоимости проекта с составлением, согласовани- ем и контролем бюджета ‒ Процессы, связанные с обменом информацией Формирование системы информирования по проекту его участников ‒ Процессы, связанные с риском Идентификация потенциальных рисков, оценка возможных последствий, разработка планов реагирования и контроль ‒ Процессы, связанные с закупкой Составление плана закупаемой продукции, технических требований, формирование критериев выбора поставщи- ков, а также процессы контрактной работы Измерение, ана- лиз и улучшение ‒ Процессы, связанные с улучшением Определение «слабых мест» в части управления проек- том и принятие корректирующих мер ‒ Измерение и анализ Сбор и оценка корректности данных ‒ Постоянное улучшение Распределение ответственности заказчика и подрядчика в части совершенствования процессов проекта Непосредственно же текст стандарта содержит основные моменты, ко- торым следует уделять внимание для успешной реализации проектов. |