ЗараменскихУЖЦИСмонография-148-272. Управление жизненным циклом информационных систем
 Скачать 3.15 Mb.
|
|
Планирование На этапе планирования появляются также новые риски, в частности, нехватка необходимых компетенций у проектной команды для корректно- УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 195 го проектирования системы и подготовки к ее реализации. Другой риск – неверная оценка сроков / объема проекта может привести к значительным задержкам проекта, к примеру, по причине опоздания в согласовании кон- тракта на закупку лицензий. Никогда не следует забывать также об ассо- циированных со всеми контрагентами: поставщиками, подрядчиками рис- ках, так как их банкротство, повышение тарифов, невыполнение договор- ных обязательств может существенно сказаться на ходе реализации проекта. Исполнение Уже во время реализации системы вероятно обнаружение невозмож- ности реинжиниринга бизнес-процессов в текущих условиях, изменение которых потребует значительного увеличения сроков реализации либо бюд- жета проектов. Отсутствие мотивации у проектной команды, ошибки уп- равления коммуникациями, рисками, интеграцией – все те риски, которые потенциального могут на этом этапе негативно сказаться на реализации проекта. Всегда существуют программные риски при приобретении ПО третьих фирм, однако еще более критичны здесь технологические риски. Ведь любые ошибки проектирования и настройки / реализации системы мо- гут привести к потере данных, невыполнению контрактных обязательств, остановке системы (не говоря уже о последствиях ошибок для систем, вы- ход из строя которых способен повлиять на безопасность жизни и здо- ровья человека). Мониторинг и управление На этапе мониторинга высокую степень важности имеет сравнение пер- воначальных целей / задач / содержания проекта и полученного результата для максимально оперативного выявления и устранения замечаний. Именно поэтому столь необходимо участие грамотных специалистов в тестировании системы – и обеспечение всех необходимых для процесса условий и ресур- сов. Другим аспектом является вновь управление коммуникации, только уже при опытной эксплуатации и обучении пользователей, так как их участие и содействие крайне важно для последующего успеха проекта. Завершение проекта Основным риском по завершении проекта является изменение как внеш- них рыночных условий, так и внутренних процессов компании. А значит, решение, создаваемое в ходе проекта, может потерять актуальность, и даже более того – его изменение (в силу сложности и низкой гибкости архитекту- ры) может оказаться нерентабельным или просто невозможным. ГЛАВА 3. Особенности управления проектами по внедрению КИС 196 Перед началом проекта внедрения необходимо четко уяснить, что может помешать достижению результата, и разработать меры по предотвращению возможных негативных последствий. Например, риск заключается в сле- дующем: на предприятии идет подготовка к внедрению корпоративной сис- темы управления, однако многие сотрудники не обладают основами компь- ютерной грамотности, что может привести к существенному снижению эф- фективности процесса внедрения. В этом случае мерой по предотвращению риска является предварительное обучение сотрудников предприятия осно- вам работы с базовыми компьютерными программами и проведение после- дующей аттестации. Иногда в ходе анализа рисков выявляются десятки фак- торов, которые могут повлиять на процесс внедрения, однако суть остается прежней – выявление рисков, разработка и выполнение мероприятий по их устранению, контроль над исполнением. В первую очередь, проводится идентификация рисков. Их список мо- жет быть сформирован руководителем проекта с командой внедрения при дальнейшем согласовании результата с куратором проекта. Этот список мо- жет быть представлен в форме таблицы по этапам ЖЦ системы, по этапам управления проектом внедрения, по основным классам рисков и другим ви- дам группировки. Часто карта рисков составляется на основе проведенного бизнес-моделирования (карты бизнес-процессов). Следующим шагом проводится оценка рисков, которые возможно пред- ставить в виде таблицы / матрицы, с обязательным указанием описания рис- ка, его возможных последствий в качественном и количественном выраже- нии (либо денежный эквивалент ущерба от реализации, либо оценка по шка- ле от 1 до 5). Вычисление данного значения чаще всего проводится на осно- вании предварительного анализа вероятных потерь (от временных и денеж- ных ресурсов до ущерба репутации компании, потери рыночной доли и т.п.). На этой стадии возможно использование анализа чувствительности, сценарного анализа, имитационного моделирования Монте-Карло, «bow- tie» анализа причин / событий / последствий реализации рисков и прочих специальных методов. Затем указывается вероятность реализации риска (в %), а также воз- можные меры по снижению этой вероятности либо уменьшению потенци- ального ущерба. В самом простейшем варианте для получения итоговой оценки для каждого риска необходимо умножить значение Ущерба от реа- лизации на Вероятность осуществления риска (переведя % в значение от 0 до 1). После ранжирования результатов и выделения рисков с наиболее вы- соким приоритетом назначаются ответственные за управление данным рис- ком и принятие необходимых мер. Определив самые критичные для проекта и бизнеса в целом угрозы, существует несколько стратегий их минимизации. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 197 Сценарий действий Необходимые меры С ни ж ен ие р ис ка Уменьшение как вероятности его наступления, так и возможных негативных послед- ствий. ПРИМЕР Так, для снижения риска недостоверности предоставленных на этапе обследования данных возможно фиксировать каждый факт предоставления информации, в фор- мате аудио- / видеозаписей встреч, сохранения полученных / переданных сообщений, подписания протоколов совещаний со списком принятых решений, и пр. Еще в дан- ном случае возможно привлечение квалифицированных специалистов со значитель- ным и релевантным (!) опытом реализации подобных проектов (в предметной об- ласти либо индустрии), а также подготовка шаблонов заполнения / загрузки инфор- мации для минимизации вероятности ошибки. П ер ен ос р ис ка Перенос риска на другую сторону при заключении отдельных соглашений. ПРИМЕР Заключение договоров страхования, аутсорсинга и прочие связанные с третьими сторонами активности. Так, потери от срыва работ в рамках контракта с под- рядчиком / поставщиком могут быть (по крайней мере, частично) покрыты соот- ветствующим пунктом договора об ответственности за неисполнение его условий. Убытки от пожара в серверной (или какая-то их часть) могут быть покрыты стра- ховой компанией. Чаще всего исключением (риском, перенос которого почти невозможен) является ущерб деловой репутации компании и ее бренду). И зб еж ан ие р ис ка В определенной степени наиболее «практичный» сценарий, предусматривающий ре- ализацию необходимых проектных активностей (возможно, чуть в большем объеме или в более сжатые сроки) во избежание многих проектных / организационных / тех- нологических рисков. ПРИМЕР Ежедневная отчетность для риска слабой организованности участников проекта, фиксация числа итераций и составление графика согласования / утверждения реше- ний и результатов во избежание риска слишком длительного процесса оформления документов. П ри ня ти е ри ск а Занятие «позиции боевой готовности», если риск выявлен слишком поздно или уже реализован, определение способов покрытия ожидаемого ущерба и избежания подоб- ных ситуаций в будушем. ПРИМЕР Потеря данных при проблеме с дата-центром в качестве реализовавшегося (возмож- но, не идентифицированного своевременно) риска. В этом случае в качестве реактив- ных мир возможно активировать последние сделанные резервные копии, восстано- вить работоспособность системы, а в дальнейшем даже пересмотреть прежнюю политику компании в отношении достаточного уровня надежности используемого ЦОД, а также обновить (создать) стратегию обеспечения непрерывности бизнеса. И наконец, заканчивая разговор о рисках, упомянем столь важный аспект, как «положительные» риски. Часто сосредотачиваясь на негативной стороне наступления определенных возможных событий / условий, участники проекта забывают о другой его стороне. А ведь, к примеру, в то время как «обычным» риском будет являться уход из компании ключевых сотрудников, «позитив- ным» возможным риском будет участие в проекте признанного в своей пред- метной области эксперта, у которого неожиданно освободится время. Рассмот- рим ту же матрицу сценариев действий, только уже для позитивных рисков. ГЛАВА 3. Особенности управления проектами по внедрению КИС 198 Сценарий действий Необходимые меры У си ле ни е (v s сн иж ен ие ) ри ск а ПРИМЕР Новость о возможном (при совпадении графиков) участии в качестве консультанта известного эксперта является позитивным риском, однако для усиления вероятно- сти его реализации необходимо пересмотреть график проведения семинаров и встреч, чтобы поменять их расписание в соответствии со свободными временными слота- ми эксперта. П ер ен ос ри ска ПРИМЕР Если компания – системный интегратор, работающий в России с программными про- дуктами Microsoft, создаст на их базе отраслевое решение для определенного локаль- ного рынка, которое будет пользоваться популярностью, Microsoft может предло- жить дальнейшее сотрудничество на льготных условиях. И сп ол ьз ов ан ие (v s из бе ж ан ие ) ри ск а ПРИМЕР При наличии возможности получения скидки вендора при закупке определенного объ- ема лицензий (который ранее предполагалось приобрести двумя этапами), компания может принять меры для изменения первоначального плана закупок и согласования нового контракта на больший объем лицензий. П ри ня ти е ри ск а ПРИМЕР Положительным риском может быть расширение числа пользователей внедренной системы. Если изначально планировалось использовать автоматизированную сис- тему управления проектами только в головном офисе, но другие филиалы / дочерние компании, увидев все ее преимущества, могут также принять решение адаптиро- вать данный программный продукт для своих нужд. Таким образом, сама компания будет иметь возможность реализовывать проекты в совместной работе несколь- ких филиалов, а компания – системный интегратор (либо внутреннее ИТ-подразде- ление) получает новый проект для выполнения. Риск всегда является неотъемлемой частью любого сложного и ответст- венного процесса. Более того, совершение рискованных действий необхо- димо для прогресса, а ошибки, как известно, являются основой приобрете- ния опыта. Несмотря на то, что некоторые риски в ходе реализации проекта внедрения системы неизбежны, это не означает, что попытки определить их и управлять ими вредят творческой работе. Обеспечение непрерывности бизнеса, планы DRP и BCP Для того, чтобы ИТ-инфраструктура не просто соответствовала потреб- ностям бизнеса, но и обеспечивала непрерывность доступа к системе/ пре- доставляемым сервисам необходимо также предусмотреть концепцию / стра- тегию непрерывности. В этих целях возможно использовать серверные тех- нологии в различных конфигурациях. В зависимости от ситуации технологи- ческие площадки: ‒ Могут быть территориально распределены или локализированы. ‒ Могут иметь полный или частичный резерв оборудования или не иметь его вообще. В случае полного резерва при катастрофе на технологической площадке предоставление ИТ-услуги (приложения) обеспечива- ется за счет оборудования на второй площадке. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 199 В случае частичного резерва основное вычислительное оборудо- вание установлено на одной площадке. Если резервирование не осуществляется, то восстановление на новом оборудовании производится с резервных внешних носи- телей информации. ПРИМЕР Возможен и другой вариант: построение резервной площадки «в облаке» (осно- ванной на SRM). Таким образом, на основной площадке обеспечивается локаль- ная доступность, реализуются решения по защите данных, а на резервной площадке организуется аварийное восстановление. Платформа виртуализации ОСНОВНАЯ ПЛОЩАДКА Сервер - MS Exchange - MS Windows Server 2003 РЕЗЕРВНАЯ ПЛОЩАДКА Веб-Сервер - Apache PHP - Red Hat Enterprise Linux Java- Сервер - JVM - MS Windows Server 2003 Сервер БД - Oracle 10g - Red Hat Enterprise Linux File-Сервер - Red Hat Enterprise Linux … Платформа виртуализации Платформа виртуализации VM VM Платформа виртуализации VM Платформа виртуализации ГЛАВА 3. Особенности управления проектами по внедрению КИС 200 ‒ Могут иметь кластерную конфигурацию (распределение нагруз- ки между равнозначными активными серверами приложений). ПРИМЕР Территориально распределенная конфигурация с подготовкой вычислитель- ных ресурсов в виде «холодного» резерва. Данная концепция предполагает подготовку резервной серверной площадки, включая всю необходимую серверную инфраструктуру, а также предваритель- ную подготовку и размещение на ней набора оборудования, идентичного обору- дованию основного ЦОД. Работа основных и резервных вычислительных ресурсов в режиме взаимного резервирования, при котором часть оборудования на каждой из серверных площадок имеет запас вычислительной мощности. Резервные вычислительные мощности находятся в режиме простоя, либо используются для решения вто- ростепенных задач. Установка на резервной площадке дополнительных систем хранения данных и прочих технических средств резервного копирования данных, с сеансами репли- кации данных с основным ЦОД периодичностью 1 раз в сутки. При выборе конкретной стратегии непрерывности и восстановления принимаются во внимание следующие аспекты: ‒ Уровень критичности приложения (системы), исходя из которого определяется допустимое время восстановления. ‒ Режим восстановления (ручной / автоматический). ‒ Стоимость реализации. ‒ Сложность / время реализации. Подход по реализации стратегии непрерывности бизнеса, как правило, закрепляется в плане обеспечения непрерывности (BCP). План обеспечения непрерывности бизнеса (Business continuity plan, BCP) – до- кумент, предназначенный для выработки и соблюдения мер по минимизации рис- ков системных сбоев информационных систем компании и снижения возможных их последствий для бизнеса. BCP-план направлен на обеспечение поддержки бизнес-процессов ком- пании во время и после чрезвычайной ситуации и может охватывать либо один отдельный процесс, либо совокупность нескольких. ИТ системы рас- сматриваются в BCP исключительно с точки зрения поддержки бизнес-про- цессов и может даже не рассматривать вопрос восстановления процессов, фокусируясь только на временных требованиях непрерывности бизнеса. Основная цель подобного документа – своевременное определение вариан- тов действий в различных критических ситуациях. В случае подобных про- исшествий снижается объем финансового ущерба, обеспечивает более бы- строе восстановление, а также удовлетворяет требованиям всех заинтересо- ванных сторон (клиентов, акционеров, регуляторов, руководителей) к не- прерывности работы компании. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ 201 Однако список задач по формированию плана обеспечения непрерыв- ности бизнеса охватывает большее количество аспектов: 1. Определение всех рисков для бизнеса с формированием плана ра- бот по каждому из данных рисков (в т.ч. ответственные сотрудники, меры предотвращения реализации рисков и нивелированию их негативного воз- действия). Так как план учитывает множество бизнес-факторов (например, репу- тационные риски), то как сам список рисков, так и список вариантов их сни- жения должен постоянно актуализироваться. Любые изменения в бизнес- процессах и бизнес-сервисах после их реализации должны быть пересмот- рены в BCP-плане. 2. Определение критических сервисов / приложений, параметров це- левого времени восстановления (recovery time objective, RTO) и целевой точки восстановления (recovery point objective, RPO), стоимости каждого часа простоя. ПРИМЕР Как правило, подавляющее большинство приложений требуют значение RTO, не превышающее 4 часов, и значение RPO менее 2-х часов. 3. Принципы переноса данных между основной и резервной площад- ками, выбор оптимального решения (в т.ч. с рассмотрением удаленности ре- зервной площадки, пропускной способности каналов связи). 4. Формирование процесса / процедур восстановления сервиса в слу- чае наступления критической ситуации – разработка плана. План аварийного восстановления (Disaster recovery plan, DRP) – план действий по восстановлению полной работоспособности информационной системы (в т.ч. на альтернативных площадках) План аварийного восстановления, как правило, фокусируется на тех си- туациях, когда доступ к информационным системам отсутствует / ограничен в течение длительного периода. В отличие от BCP, план DRP существует на более операционном уровне, описывая порядок действий (организации тех- нических и организационных решений) по построению системы защиты инфраструктуры ИТ. Так, среди наиболее популярных решений по защите от чрезвычайных ситуаций – построение резервной площадки / ЦОД (disas- ter recovery site). В качестве основных методологических материалов разработки планов обеспечения непрерывности / аварийного восстановления используются следующие международные стандарты и руководства: ‒ ISO/IEC 27001:2005 (ISO/IEC 17799:2005). ‒ Сборник лучших практик BCI (The Business Continuity Institute). ‒ Руководство CobiT. ‒ Contingency Planning Guide for Information Technology Systems (NIST). |