Лекция 3. Управление ЖЦ ИС И ИТ в контексте проектной деятельности

**Первый учебный вопрос. Модели ЖЦИС и ИТ.** ***Каскадная модель*** Каскадная модель жизненного цикла, также называемая моделью «водопада» (waterfall), была разработана еще в 80-х годах, и на протяжении многих лет она считалась стандартом для разработки ПО. Данная модель характеризуется тем, что этапы строго последовательны и переход между ними невозвратный. Это означает, что в рамках каскадной модели переход к следующему этапу (например, от проектирования и сбора требований к разработке и развертыванию) может произойти только по завершении предыдущего этапа. Модель «водопада» была применена одной из первых и одно из ее основных достоинств в возможности планирования сроков и стоимости каждого этапа – однако, на практике разработка системы почти никогда не проходит строго в соответствии с жесткой заранее продуманной схемой. В частности, это касается сбора требований, так как реально при старте проекта требования бывают определены только частично и в дальнейшем уточняются, изменяются и дополняются. К тому же, если изначально требования были определены неточно, высока вероятность того, что система не будет удовлетворять потребностям заказчика.  ***Каскадная модель с промежуточным контролем*** В качестве одной из вариаций каскадной модели для того, чтобы предусмотреть возможность возвращения к предыдущим этапам для внесения определенных изменений и пересмотра отдельных вопросов, была создана каскадная модель с промежуточным контролем. Она предполагает увеличенное время, отведенное на разработку, за счет проведения промежуточных корректировок между фазами жизненного цикла. В свою очередь, это снижает риски получения некачественного продукта на выходе и повышает надежность системы в целом.  ***Спиральная модель*** Для нивелирования рисков, связанных с вышеописанной проблемой, была создана спиральная модель (также называемая итерационной). Фазы жизненного цикла непоследовательны, то есть допустимо начало работ над следующим этапом до завершения предыдущего. Таким образом, суть спиральной модели состоит в возможности прохождения всех этапов жизненного цикла системы в несколько итераций, каждый раз создавая новый прототип и проверяя актуальность требований, по которым он создавался, внося технические доработки в интерфейс и функциональность. Подобная гибкость позволяет использовать модель на предприятиях любого масштаба.  Прототип крайне важен в ситуациях, когда требуется разъяснить и уточнить требования, выбрать концептуальное решение или даже в целом определить целесообразность реализации проекта. При этом сам прототип может либо моделировать исключительно пользовательский интерфейс, либо архитектурную сторону системы (логика обработки и хранения данных). Это означает, что процесс создания системы и само управление проектом будет более гибким и управляемым, с совершенствованием системы на каждом «витке спирали», то есть при выпуске каждой версии. Уменьшаются риски (в том числе, финансовые) для заказчика и спонсора системы, которые могут отказаться от проекта еще на этапе показа первого прототипа в случае абсолютного его несоответствия ожиданиям и потребностям (либо в случае изменения рыночной ситуации). Как правило, подобная модель применяется при разработке нетиповых систем, предоставляя возможность оперативно создать прототип программного продукта для проверки его работоспособности с пользователями и соответственно, быстрого получения комментариев и замечаний к системе. ***Модель разработки через тестирование (V-модель).*** Приближенная по своей сути к практикам PRINCE2, V-модель разработки через тестирование была разработана еще в конце 1980-х годов ведомствами Германии и США, и до сих пор является стандартом немецких правительственных и оборонных проектов. Основной ее принцип состоит в постепенном возрастании степени детализации проекта с течением времени и одновременном проведении «горизонтальных» итераций. Таким образом, результаты каждой из фаз левой стороны буквы V влияют на тестирование и компоновку проекта с правой стороны буквы V: приемо-сдаточные испытания основываются на проведенном анализе требований, интеграционное тестирование – на высокоуровневом описании архитектуры, модульное тестирование – на архитектуре, интерфейсах, алгоритмах и прочих элементах детализированных требованиях к системе.  Важна гибкость данной модели, так как, по сути, она адаптируема под любой тип организации. Промежуточные результаты проверяются на ранних стадиях, и минимизация рисков достигается благодаря простому соотнесению фаз/итераций. V-модель не рассматривает непосредственно стадию обслуживания и утилизации, учитывая лишь активности по подготовке к ним. Рассмотрев основные особенности моделей жизненного цикла, перейдем к фазам проекта по созданию и внедрению интегрированной системы управления как совокупности этапов по созданию, настройке, доработке и внедрению отдельных функциональных модулей системы, выполнение которых необходимо и достаточно для создания системы управления, соответствующей заданным требованиям. **Второй учебный вопрос. Стандарты ЖЦИС и ИТ.** ***ГОСТ 34.601-90 Информационная технология.*** Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. Отличается высокой степенью формализации (как и ГОСТы 19-й серии) и по умолчанию, таким образом предполагает каскадный подход. На сегодняшний день ГОСТ многократно становился основой для доработок и частичного использования в других стандартах/методологиях и в целом в исходном виде не является исчерпывающим как единственный источник информации для выполнения проекта разработки/внедрения.  ***ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)*** Международный стандарт: ISO/IEC 12207:2008 Information technology – Software life cycle processes (Информационные технологии. Процессы жизненного цикла программного обеспечения). Российский аналог: ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств». Базируясь на процессном подходе, ISO 12207 определяет необходимость документирования основных результатов процесса, но не ограничивает их. Данный стандарт стал основой для дальнейшей детализации в некоторых методологиях разработки ПО (в частности, Rational Unified Process), однако сам по себе лишь устанавливает структуру основных, вспомогательных и организационных процессов ЖЦ программных средств, определяя необходимые в их рамках работы и задачи. Таким образом формируется единое понимание жизненного цикла (и единая терминология) между заказчиком, разработчиком / подрядчиком и другими стейкхолдерами. С другой стороны, ISO 12207:2008 рассматривает лишь программные средства и соответствующие организационные процессы, не рассматривая аппаратную составляющую.  В РФ был разработан и принят идентичный ISO 12207 стандарт ГОСТ Р ИСО/МЭК 12207-2010. Основной идеей разработчиков ГОСТ 12207 являлось создание единого общекорпоративного стандарта, которым было бы возможно воспользоваться при возникновении любой задачи из тех, которые описаны в документе (будь это обучение пользователей, поставка ПО или любая другая активность в рамках ЖЦ). ***ISO/IEC 15288 (ГОСТ Р ИСО/МЭК 15288-2005)*** Международный стандарт: ISO/IEC 15288:2005 Systems engineering. System life cycle processes (Системотехника. Процессы жизненного цикла системы). Российский аналог: ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем. Достаточно «молодой» стандарт системной инженерии (впервые представленный в 2002 году), ISO/IEC 15288 фокусируется на вопросах жизненного цикла системного уровня, в особенности тейлоринге (tailoring) – по сути, настройке и адаптации ЖЦ к конкретным требованиям и ограничениям. В отличие от рассмотренного ранее стандарта, ISO 15288 распространяется на системы в целом, охватывая такие их элементы, как: «технические средства, программные средства, люди, процессы (например, процесс оценки), процедуры (например, инструкции оператора), основные средства и природные ресурсы (например, вода, объекты живой природы, минералы)». Согласно данному стандарту, любой процесс ЖЦ может быть начат в любой момент, без ограничения порядка использования и последовательности (в том числе, параллельном выполнении нескольких процессов). Важно также отметить высокий уровень абстракции ISO 15288 в сравнении с ISO 12207, так как данный стандарт не приводит ролей, конечных результатов в виде списка выходных документов, либо же состава работ, лишь оставаясь на уровне концепции.  **Третий учебный вопрос. Фазы ЖЦИС и их специфика.** *Планирование проекта* Обследование проводится в обязательном порядке на самом первом этапе для сбора информации о целях и задачах компании в целом и внедряемой системы в частности, а также получению данных об основных бизнес- процессах и покрывающем их ландшафте информационных систем (для определения в нем места внедряемого решения). Важно верно определить: - организационный объем проекта (затрагиваемые реализацией проекта подразделения); - наличие зависимостей от других проектов; - планируемые финансовые, инфраструктурные и человеческие ресурсы, бюджет проекта (включая необходимые закупки – например, лицензии от поставщика ПО – и планируемые затраты при необходимости оплаты услуг подрядчика по сопровождению, по обслуживанию серверов и т.д.). Принято различать две категории обследования: - экспресс-обследование; - информационное обследование; Также по результатам информационного обследования со стороны заказчика должны быть приняты все организационные меры для обеспечения реализации проекта. В частности, это относится к внутренним приказам и документам предприятия заказчика (для назначения ответственных за предоставление информации и взаимодействие с проектной командой в рамках внедрения). *Анализ и постановка задачи* Существует определенный набор ключевых мероприятий, обязательное проведение которых может повысить вероятность успеха проекта. Уже на стадии постановки задачи должны быть определены цели этапов проекта и самого проекта, включая критерии их выполнения. При этом данные цели должны быть сформулированы предельно четко и ясно (по возможности, удовлетворяя критериям SMART: конкретность, измеримость, достижимость, актуальность, установка конкретного срока). Под интегрированной системой управления понимается система управления, использующая совокупность современных программно-аппаратных средств, информационных технологий и экономико-математических методов для регулярного решения задач управления производственно-экономической деятельностью предприятий и коммерческих организаций. Интегрированная система управления является сложной системой управления, включающей в свой состав отдельные модули (подсистемы). Модуль — часть системы, выделенная по определенному признаку, отвечающему конкретным целям и задачам управления. В рамках этих задач он может рассматриваться как самостоятельная система. *Проектирование* Проектирование включает в себя два основных аспекта: техническое и рабочее проектирование. В первом случае проводится описание технических деталей, а также моделирование ситуаций, в которых система будет использоваться – для дальнейшей разработки сценариев использования системы и ее тестирования на их основе. При рабочем же проектировании могут составляться блок-схемы и алгоритмы для программных модулей. В целом же техническое проектирование ИТ-системы предполагает детальную подготовку к этапу настройки/развертывания модулей системы, для чего необходимо решить несколько задач: - сформировать список модулей и функций системы, необходимых для поддержки определенных на этапе анализе автоматизируемых бизнес-процессов; - сформировать список справочников систем (будущей и если применимо, текущей) для дальнейшего переноса и обновления данных; - определить примерный сценарий работы системы по категориям пользователей для формирования необходимого набора диалогов и процедур проектируемой системы (включая реакции на все возможные и даже очень маловероятные действия со стороны пользователя); - определить элементы интерфейса пользователей (в случае гибкого или разрабатываемого «с нуля» решения) для достижения удобства работы с системой; - сформировать список отчетов/панелей мониторинга (включая их формы и обязательные для реализации элементы). Эти отчеты в дальнейшем будут использоваться как для учетных целей, так и для целей мониторинга системы ее администратором (в части формирования и сбора статистики по нагрузке на ее отдельные модули, свободных ресурсах, активности пользователей и т.п.); - определить перечень настроек функциональных компонентов системы в соответствии со выделенными на предыдущем этапе требованиями; - определить необходимость, возможности и пути интеграции с существующими и планируемыми к реализации системами на предприятии заказчика, чтобы своевременно предусмотреть технические средства для интеграции. На этапе детального проектирования важно крайне четко определить все функциональные возможности системы и определить ее место в общей программной архитектуре предприятия. *Разработка* Ко времени старта реализации системы, как уже было сказано, должна быть выбрана и подготовлена среда разработки, а также выбрана методология, в соответствии с которой будет осуществляться управление разработкой. От нее зависит очень многое: принцип взаимодействия команды разработки/внедрения (между собой и с основными стейкхолдерами проекта), следование одной из моделей жизненного цикла ИС (каскадной, итерационной и пр), длительность самого процесса разработки и тестирования и прочие важные аспекты процесса реализации системы. Подробнее различные методологии как управления проектами, так и непосредственно разработки будут рассмотрены в следующей главе. *Развертывание и внедрение* Этап развертывания системы является одним из наиболее важных с точки зрения распределения ответственности за работы между заказчиком и подрядчиком. Исполнитель выполняет основную задачу – инсталляцию модуля на рабочий сервер с перенесением на него итоговую конфигурацию с тестового сервера. Однако при верном последовательном обучении и вовлечении специалистов заказчика в процесс создания / внедрения системы остальные операции могут быть осуществлены ими: - предшествующее работам обеспечение охвата всех автоматизируемых рабочих мест пользователей функционирующей ЛВС; - настройка рабочего сервера; - определение перечня / количества рабочих мест, которые необходимо развернуть для ОПЭ; - развертывание рабочих мест пользователей с определением прав доступа. ‒ Подготовка наиболее актуальной информации по каждому модулю для ввода в систему (включая подготовку, дополнение и выверку справочников, которые могли потерять актуальность за время между тестовой эксплуатацией и развертыванием системы); - организация поддержания данных системы в актуальном состоянии (в том числе при интеграции с другими системами). Целью данного этапа является подготовка модуля системы к опытно-промышленной эксплуатации — подготовка конечных пользователей, ввод начальных данных, подготовка приказов по предприятию заказчика о передаче модуля системы в опытно-промышленную эксплуатацию. Среди основных работ этапа: - обеспечить безусловное выполнение условий готовности модулей системы к сдаче в опытно-промышленную эксплуатацию; - ввести и выверить начальные данные (например, начальные остатки) по каждому модулю для ввода информации в систему; - отработать на рабочих местах пользователей модуля системы практические действия пользователей в параллельном режиме с имеющимися приложениями; - разработать, согласовать с подрядчиком и утвердить регламент взаимодействия подразделений заказчика, участвующих в опытно-промышленной эксплуатации модуля системы; - осуществить интеграцию модуля с другими модулями или внешними системами, внедренными ранее; - подготовить и издать приказ по предприятию заказчика о передаче модуля системы в опытно-промышленную эксплуатацию, который должен содержать: - наименование модуля системы, проходящего опытно-промышленную эксплуатацию; - наименование компании-исполнителя; - сроки проведения опытно-промышленной эксплуатации; - список должностных лиц со стороны заказчика и исполнителя, ответственных за проведение опытно-промышленной эксплуатации модуля; - перечень подразделений предприятия заказчика, участвующих в проведении опытно-промышленной эксплуатации; - порядок и сроки перевода персонала заказчика на работу в условиях функционирования модуля системы. К моменту ОПЭ уже должны быть проведены следующие работы: - модули системы успешно перенесены и функционируют на рабочем сервере и автоматизированных рабочих местах пользователей (с разделением прав доступа); - подготовлены, дополнены и введены недостающие справочники по каждому модулю системы, проведена выверка введенных в систему недостающих справочников; - заказчиком утверждены итоговые документы. *Эксплуатация* Этап эксплуатации системы является наиболее ожидаемым для бизнес-заказчиков, которые только сейчас начинают получать ожидаемый возврат инвестиций и видеть реальный результат внедрения. Однако это и самый опасный этап, так как полученный результат может (и скорее всего, не будет) не соответствовать первоначальным ожиданиям и представлениям как о функциональности, так и даже о внешнем виде/интерфейсе системы. Технические специалисты и подрядчик фокусируются на решении задач бесперебойной работы, обслуживания баз данных, а в случае необходимости – на донастройке системы (что означает одновременное наступление стадии модернизации, продолжающееся параллельно с эксплуатацией). Но бизнесзаказчик и спонсор системы, как и все участники процесса сбора требований часто имеют собственное представление о целевом состоянии системы, именно поэтому критически важно с самого начала вовлекать в проект специалистов, переводящих пожелания бизнеса в плоскость разработчиков (данная роль в английской терминологии получила название IT/Business Relationship Manager). Стадия сопровождения, приводящая к изменениям к системе в процессе эксплуатации (по окончании приемки работ) охватывает несколько аспектов: - устранение замечаний, не затрагивающее изменение ТЗ; - обновления (по сути – новые версии системы), выпускаемые при накоплении критического объема доработок; - увеличение производительности системы. *Сопровождение эксплуатации* Данная фаза жизненного цикла разделяется на следующие этапы: 1. Авторский надзор. В условиях промышленной эксплуатации в течение определенного договором времени после сдачи модуля системы со стороны исполнителя и подрядчика проводится наблюдение за его функционированием и по мере необходимости оказание помощи специалистам заказчика по устранению замечаний. В свою очередь, уже обученные ответственные за систему сотрудники заказчика в тесном взаимодействии с ключевыми пользователями формируют перечень замечаний, осуществляют технологические обновления модуля/системы и ведут документирование эталонных версий модулей и их программной документации. При этом предприятие-подрядчик включается в работу только при необходимости значительных доработок либо если таковое определено заключенным контрактом на поддержку. Это объясняется тем, что ключевая необходимая для успешной и бесперебойной работы системы функциональность и программно-аппаратная база уже была сформирована на предыдущих этапах и специалисты заказчика уже в состоянии осуществлять стандартную техническую поддержку на своем предприятии самостоятельно. 2. Техническая поддержка. Техническая поддержка системы начинается после приема в промышленную эксплуатацию и может продолжаться до снятия с эксплуатации и утилизации системы. Как правило, варианты осуществляемой поддержки варьируются по процентам от стоимости приобретенного ПО, в зависимости от набора оказываемых услуг, а объем и периодичность выполнения работ на данном этапе определяются отдельным договором. 3. Постгарантийное сопровождение Постгарантийное сопровождение предполагает заказываемые у производителя работы, не предусмотренные изначальным контрактом на автоматизацию процессов/системную интеграцию. Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как «модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении». Функционирование программного продукта таким образом поддерживается на протяжении всего периода его эксплуатации. *Модернизация* В течение периода эксплуатации системы происходят неизбежные изменения как вне организации (в том числе, изменение рынка, контрагентов), так и внутри организации (к примеру, смещение бизнес-приоритетов в другую индустрию, на другой рынок и пр.). Растет объем обрабатываемой информации, объем файлов, снижается пропускная способность, оборудование выходит из строя и появляется новое — все эти факторы неизбежно влияют на актуальность самой системы и решаемых ей задач. В то время, когда системы уже не способны с должной степенью эффективности решать задачи бизнеса, говорят об «унаследованных» (legacy) системах. Legacy systems (унаследованные системы) — системы, более не соответствующие текущим потребностям бизнеса, но по-прежнему эксплуатирующиеся компаниями. Как правило, в их основе лежат устаревшие со временем технологии, платформы и не представляется возможным далее и совершенствовать и видоизменять для соответствия требованиям безопасности, новому аппаратному обеспечению, обновленным операционным системам. Виртуализация — предоставление вычислительных ресурсов, абстрагированное от аппаратной реализации и изолирующее вычислительные процессы конкретных физических ресурсов. Таким образом, при виртуализации создаются различные уровни абстракции. Сама концепция виртуализации появилась еще в 1970х годах, когда IBM виртуализировала интерфейсы своего оборудования. VMS запускается непосредственно на основном оборудовании, позволяющем создавать множество виртуальных машин (VM), каждая из которых может обладать своей собственной операционной системой. Другим вариантом виртуализации в то время была симуляция процессора (выполнение псевдокода на виртуальной машине вместо реального оборудования). Большая часть задач по модернизации решения могут проводиться параллельно с эксплуатацией (не дожидаясь ее прекращения), однако это будет требовать повышенного контроля ко всем параметрам и данным системы, вероятность ошибок в которых резко повышается. С другой стороны, успешное применение подобного способа позволяет избежать необходимости мигрировать данные после модернизации и искать «промежуточное» решение, на время модификации ИС заменяющее по функциональности и удобству основную систему. *Утилизация* Не существует системы, которая бы использовалась всегда — а значит, необходимо предусмотреть условия, при которых понадобится отказаться от системы и вывести ее из эксплуатации. Эта деятельность, в свою очередь, также является проектом, ключевая цель которого – снятие системы (или ее отдельных модулей) с эксплуатации, что чаще всего проводится уже после внедрения новой системы. **Четвертый учебный вопрос. Управление стейкхолдерами.** Конфликт интересов бизнеса и ИТ. Важным аспектом для внедрения и существования систем в частности — и деятельности организации в целом является согласованность действий ИТ-департамента с интересами бизнес-пользователей и конечно, руководства компании. Формирование бизнес-архитектуры, сбор требований, процесс внедрения – любые действия, относящиеся к ИТ, так или иначе затрагивают интересы других сторон. Ценность ИТ-проекта должна быть так или иначе «донесена» до каждой из них для понимания смысла сотрудничества и конечно, выделения необходимых инвестиций. Посвятившие значительно количество времени и ресурсов исследованию подходов и практик определения ценности ИТ для бизнеса, создатели проекта it-value.ru выделили в ходе работы несколько основных стейкхолдеров и основные вопросы, актуальные для них.  Организационные условия осуществления проекта Необходимые условия отражают потребности проекта, отсутствие которых непосредственно влияет на сроки, стоимость и даже принципиальную возможность достижения результата проекта. Этими условиями являются: - сильная поддержка проекта со стороны Генерального директора (и других топ-менеджеров) предприятия заказчика; - осознание руководством предприятия крайней необходимости внедрения системы; - готовность руководства предприятия к четкой организации проекта обследования предприятия и реализации системы; - готовность руководства предприятия к выделению квалифицированных сотрудников для осуществления совместной работы по проекту со специалистами подрядчика; - готовность предприятия и его руководства к внедрению и проведению неизбежных изменений в управленческих процессах, корпоративных стандартах учета и отчетности, созданию у сотрудников предприятия твердого убеждения неизбежности нововведений, поддержанию высокого статуса проекта и закреплению всех проектных распоряжений соответствующими приказами руководства; - формирование совместной группы внедрения со стороны заказчика и подрядчика; - создание органа корпоративного управления заказчика и проведение его заседаний по утвержденному регламенту, но не реже одного раза в месяц; - назначение куратора проекта в ранге не ниже заместителя генерального директора компании заказчика, а также ответственных лиц по подразделениям предприятия для участия в проекте; - создание для группы внедрения необходимых условий для работы на предприятии заказчика (помещение, компьютеры для каждого, сеть, связь, доступ к ксероксу и принтеру), в том числе для работы в условиях вахтенного метода, т.е. возможно без выходных дней и в нерабочее время (после окончания рабочего дня в организации заказчика). **Пятый учебный вопрос. Управление человеческими ресурсами.** При привлечении подрядчика к внедрению проектная команда будет состоять из специалистов с обеих сторон: как заказчика, так и исполнителя.  Куратор проекта — как правило, представитель топ-менеджмента компании, участвует в активностях по оформлению договора на выполнение проекта, осуществляет общее руководство проектом и определяет стратегические аспекты взаимодействия специалистов и компаний, занятых в нем. Руководитель проекта участвует во всех этапах проекта по внедрению, осуществляет руководство работами, определяет операционные аспекты взаимодействия специалистов компаний, занятых в нем. Как правило, занятость в проекте от 80 % до 100 % (неполная занятость и совмещение нескольких ролей и/или нескольких проектов одновременно существенно повышает риск неудачи проекта). Бизнес-аналитик выполняет работы по проведению обследования предприятия, формирует в случае необходимости рекомендации по оптимизации и реинжинирингу бизнес-процессов Заказчика и участвует в их исполнении, формирует рекомендации по информационному обеспечению бизнес-процессов и взаимодействию, а также принимает участие в формировании требований на создание системы (совместно с консультантом по постановке задач, если подобная роль отдельно выделяется). Консультант по функциональности выполняет работы по настройке и доработке функциональных возможностей системы с учетом специфики бизнес-процессов предприятия Заказчика (на основе данных, предоставленных бизнес-аналитиком), а также принимает участие в процессе внедрения системы. Технический консультант осуществляет техническую и технологическую поддержку проекта, совместно с программистом-консультантом, ответственным за программное обеспечение. Преподаватель курсов по функциональности осуществляет обучение специалистов со стороны заказчиков, в дальнейшем играющих роль пользователей, описывая им интерфейс системы, ее ключевые возможности и настройки. Другой группой обучаемых сотрудников являются ИТ-специалисты заказчика, после внедрения осуществляющих текущую техническую и консультационную поддержку пользователей. Со стороны заказчика Координатор проекта, будучи, как и куратор от исполнителя, представителем топ-менеджмента компании (в ранге не ниже заместителя генерального директора предприятия заказчика), участвует в активностях по принятию оперативных административных решений и контролю их выполнения. Руководитель проекта со стороны заказчика выполняет те же функции, что и руководитель проекта от исполнителя и фактически является его заместителем (во время отсутствия последнего на предприятии). Группа внедрения со стороны заказчика включает как ИТ-специалистов, так и сотрудников, задействованных во внедрении и работе с системой бизнес-подразделений. ИТ-специалисты заказчика являются сотрудниками отдела автоматизации / ИТ-департамента (чаще всего программистами) и принимают активное участие во всех работах по внедрению системы (особенно на этапах создания проектного решения, доводки модулей системы в ходе тестирования и опытно-промышленной эксплуатации, формирования системной документации). ICB IBMA – требования к компетенциям проектных команд Основные компетенции и рекомендации по формированию проектных команд описываются в Руководстве, опубликованном некоммерческой профессиональной ассоциацией по управлению проектами IPMA (International Project Management Association). Ключевым стандартом IPMA по управлению проектами является ICB – IPMA Competence Baseline – руководство, описывающее требования к компетенциям, необходимым менеджерам проектов и членам проектных команд для управления проектами / программами / портфелем проектов. Система оценки компетенций состоит из четырех уровней сертификации IPMA: - уровень А – Сертифицированный директор проектов; - уровень B – Сертифицированный старший менеджер проектов; - уровень С – Сертифицированный менеджер проектов; - уровень D – Сертифицированный специалист по управлению проектами. **Шестой учебный вопрос. Управление финансами.** ***Совокупная стоимость владения (Total Cost of Ownership, TCO)*** — суммарная величина прямых и косвенных затрат владельца системы на протяжении всего ее жизненного цикла. Идея TCO была предложена еще в 1987 году компанией Gartner Group, и с тех пор создано множество различных инструментов / методов определения значения стоимости владения системой. TCO учитывает три основных типа затрат: - прямые капитальные (CAPEX); - прямые операционные (OPEX); - косвенные затраты (потенциальные потери от различных плановых и внештатных ситуаций). Отметим, что, по сути, косвенные затраты отражают то, насколько эффективно осуществляется управление информационными системами. Так, чем более эффективно ИТ-служба обеспечивает управление ИТ-инфраструктурой и системами, тем меньше косвенные затраты от простоя систем, потери времени конечных пользователей на самостоятельный поиск решения и ожидание помощи. ***Чистая приведенная стоимость проекта (Net Present Value, NPV)*** — Текущая стоимость будущих денежных потоков инвестиционного проекта. Смысл данного показателя состоит в вычислении текущей стоимости потоков денежных средств по периодам с последующим суммированием результатов. Риски проекта учитываются при использовании различных ставок дисконтирования (чем выше риск, тем выше будет выбранная для него ставка дисконтирования, которая может учитывать также и инфляцию / прогнозную норму прибыли). Всего для вычисления NPV применяются три основных шага: 1. Определение текущей стоимости затрат (объема инвестиций), через суммирование различных типов затрат. 2. Расчет текущей стоимости денежных потоков (PV) к текущей дате:  где CF – денежный поток; r – ставка дисконтирования; It – инвестиции периода. Либо в случае осуществления инвестиций в несколько этапов применяется следующая формула:  где CF – денежный поток; r – ставка дисконтирования; It – инвестиции периода t; n – общее число периодов. 3. Сравнение текущей стоимости инвестиций в проект с текущей стоимостью доходов. Полученная разница и представляет собой значение чистого дисконтированного дохода.  NPV > 0 — Реализация предложенного проекта экономически эффективна, так как потенциально он принесет больше, чем требуемый процент возврата инвестиций. NPV = 0 — Проект выгоден, так как принесет прибыль, эквивалентную требуемому проценту возврата инвестиций. NPV < 0 — Реализация проекта экономически нецелесообразна. ***Возврат инвестиций (Return On Investment, ROI)*** — отношение полученных (сэкономленных) денег от реализации проекта к вложенным в него средствам. ROI = 180 % означает, что на каждый вложенный рубль вернулась (или была сэкономлена) сумма в 1 рубль 80 копеек. Смысл показателя ROI в определении чистой прибыли от инвестиций, которая необходима для получения прибыли. Он также может говорить о том, насколько эффективно используются активы. ***Период окупаемости инвестиций (Payback Period, PP) ***— Продолжительность времени, в течение которого обеспечивается возврат первоначальных инвестиций. Как правило, инвесторы склонны более благоприятно относиться к проектам с более быстрым оборотом средств, нежели преследовать долгосрочные выгоды, которые ассоциированы с большими рисками. Для определения, в какой момент проект достигнет точки окупаемости, необходимо последовательно рассчитывать показатель NPV для каждого периода проекта, пока значение NPV Этот показатель определяется последовательным расчетом NPV для каждого периода проекта, точка, в которой NPV станет положительным, будет являться точкой окупаемости. **Седьмой учебный вопрос. Управление коммуникациями.** Управление реализацией проекта и решение спорных вопросов / проблем Для решения возникающих в ходе проекта спорных вопросов и проблем применяется процедура управления решением спорных вопросов, призванная обеспечить качественное выполнение задач проекта в срок и снизить степень влияния связанных с этими вопросами факторов риска. Решение каждого вопроса (проблемы) проходит четыре стадии: - идентификация проблемы; - принятие к дальнейшему рассмотрению либо отказ от такового; - одобрение предложенного решения; - закрытие проблемы. Проблема может быть идентифицирована членами команды внедрения, пользователями или управленческим персоналом. В момент регистрации каждый спорный вопрос должен быть задокументирован с помощью Формы регистрации проблем или аналогичного документа. Для принятия решения о целесообразности документирования проблемы используется один из приведенных ниже критериев: - на сколько существенно повлияет отказ от решения этой проблемы на проект (например, вызвать задержку, изменение курса проекта, снижение качества или увеличение стоимости проекта); - выходит ли проблема за рамки одной задачи или требует внимания более чем одного консультанта; - требует ли проблема решения со стороны куратора или руководителя проекта. Проблемы должны оцениваться по степени своего влияния на проект по следующим категориям важности: 1. Высокая (такие проблемы должны быть рассмотрены руководителем проекта и утверждены Координационным советом). 2. Средняя (должны быть рассмотрены и решены руководителем проекта совместно с кем-либо из заместителей директоров предприятия заказчика. Обо всех принятых таким образом решениях руководитель проекта отчитывается на очередном заседании Координационного совета). 3. Низкая (рассмотрение и решение таких проблем осуществляются руководителем проекта самостоятельно. Обычно проблемы такого рода не имеют альтернативных решений. Суть такой проблемы обычно заключается в необходимости принять конкретное заранее известное решение). Каждая проблема должна быть рассмотрена руководителем проекта со стороны исполнителя, в результате чего ей должен быть назначен один из следующих статусов: - отклонена – проблема отклоняется, если она не препятствует нормальному ходу выполнения проекта и не влияет на его конечный результат; - отложена – проблема откладывается, если решение по этой проблеме не может быть принято в момент рассмотрения; - объединена – проблемы, связанные тесно между собой, должны быть объединены; - принята – для принятых проблем производится рассмотрение и оценка вариантов решения, выбор варианта и назначение исполнителя для его реализации. Как только по какой-либо проблеме принято решение, оно должно быть преобразовано в последовательность шагов по его реализации, в числе которых должно быть определено: - какие задачи должны быть выполнены; - какие документы, отчеты или другие рабочие продукты должны быть подготовлены; - кто будет отвечать за выполнение задач и за техническую подготовку; - критерии качества и завершения. Способы предотвращения конфликтных ситуаций. Можно представить множество причин возникновения конфликтных ситуаций в процессе развития проекта. В данном разделе выделены основные источники и причины возникновения таких проблем, а также возможные пути их предотвращения. 1. Цель проекта в контексте решения критических вопросов предприятия должна быть поставлена перед группой внедрения достаточно четко. Высшее руководство предприятия должно заявить о полной поддержке людей, задействованных в проекте. 2. Представители проектной команды должны регулярно встречаться друг с другом и с членами Координационного совета с целью обсуждения текущих вопросов, анализа состояния проекта и обмена мнениями. 3. Другой потенциальный источник конфликтных ситуаций – это приоритеты управления и оценка производительности. Типичная ситуация, когда член проектной команды напрямую отчитывается перед своим непосредственным руководителем и косвенно – перед руководителем команды внедрения. Требования, высказанные обоими руководителями, вступают в противоречие, и рядовой член команды внедрения находится в состоянии растерянности. 4. Исторически сложилось, что оценка действий сотрудника в основном зависит от того, насколько успешно он работает на своем непосредственном рабочем месте. **Восьмой учебный вопрос. Управление качеством.** «Качество — совокупность характеристик объекта, относящихся к его способности удовлетворять установленные и предполагаемые потребности». Управление качеством системы является комплексной задачей, для успешной реализации которой возможно, во-первых, фокусироваться на производстве качественного продукта изначально, а во-вторых, проводить своевременную оценку и корректировку уровня качества. В первом случае, мероприятия направлены на обеспечение соответствия проекта и ИС как таковой ранее определенным требованиям. - использование стандартов (управления проектами, разработкой программного обеспечения, управления ЖЦ и т.п.); Разумеется, опыт аналогичных проектов многих компаний и «лучшие мировые практики» дают общие руководства по управлению качеством и предлагают различные методики и инструменты, использование которых разумно и целесообразно. Однако необходимо понимать, что для их эффективного применения необходимо обладать соответствующим опытом и грамотно комбинировать разные стандарты во избежание их конфликтов между собой и несовместимости со спецификой предприятия или проекта. - обучение, повышение квалификации персонала, использование внешних консультантов; Повышение уровня компетенций проектной команды является широко применяемым и даже обязательным условием получения качественных результатов. - четкие критерии качества и стабильная внешняя среда проекта. Вероятность повышения качественного продукта повышается, если критерии оценки информационной системы заранее четко сформулированы и прозрачны, а рамки проекта остаются неизменными, без уменьшения сроков или стоимости. В случае же оценки и корректировки качества, очень важны: - прототипирование и тестирование с пользователями; - регулярный контроль и анализ. Контрольные карты, диаграмма Ишикавы для причинно-следственного анализа, план / факт анализ, планы совершенствования качества и процессов и другие методы управления проектами в зависимости от ситуации оказываются достаточно полезными в целях мониторинга качества. ***ISO 10006:2003 (ГОСТ Р ИСО 10006-2005)*** Международный стандарт: ISO 10006:2003 «Управление качеством. Руководящие указания по менеджменту качества проектов». Российский аналог: ГОСТ Р ИСО 10006-2005 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании». Стандарт акцентирует внимание своей аудитории на двух основных аспектах качества в управлении проектами: качестве процессов проекта и качестве продукции, так как недостаточное внимание / реализация требований хотя бы к одному из них может оказать негативное воздействие на ход проекта, его результаты, саму организацию. Помимо собственных определений многим проектным терминам, ISO 10006:2003 описывает организационный аспект управления качества в части ответственности руководства, затем переходя к управлению ресурсами. Еще один раздел стандарта (глава «Системы менеджмента качества при проектировании», со ссылкой на ISO 9000), приводит восемь основных принципов: ориентацию на потребителя, лидерство руководителя, вовлечение работников, процессный подход, системный подход к менеджменту, постоянное улучшение, принятие решений на основании фактов и взаимовыгодные отношения с поставщиками. ***ISO 15504/SPICE. Модели уровней зрелости CMM/CMMI*** Международный стандарт: ISO 15504:2004 «Information Techology. Process Assessment» / SPICE (Software Process Improvement and Capability Determination). Российский аналог: ГОСТ Р ИСО/МЭК 15504 «Информационные технологии. Оценка процессов». Стандарт, впервые представленный в 90-х годах, отличает фокус на модели улучшения процессов, а именно: эффективности работы и возможностей процесса. Под «эффективностью работы» понимаются продуктивность, учет потребностей пользователей / бизнес-заказчика, а «возможности процесса» определяются, как правило, организацией – поставщиком услуг по разработке и сопровождению системы для формулирования целевых потенциальных уровней совершенства этих процессов. Всего в стандарте детализируются и рассматриваются пять основных групп процессов: Процессы взаимодействия «потребитель-поставщик» (Suppliercustomer). - разработка (Engineering); - поддержка (Supporting); - управление проектом (Management); - организационные процессы (Organization). **Девятый учебный вопрос. Управление содержанием.** ***Проектная документация*** Важность документации очень просто недооценить, однако именно благодаря ей любой человек сможет уяснить как общую картину и суть проекта, так и узнать самые незначительные детали его реализации. Сквозное документирование проекта (включающее все результаты проведенных работ, замечаний, разногласий, предложений, проведенных встреч) должно осуществляться в обязательном порядке. Основным элементом управления проектом является регулярный отчет руководителя проекта о состоянии проекта, в котором отражаются результаты выполнения работ по внедрению на момент формирования отчета. На протяжении всего проекта в отчете отражаются работы, выполненные в настоящее время, находящиеся на стадии выполнения (с указанием степени завершенности) и предстоящие в ближайшем будущем. Появление промежуточных результатов в ходе реализации проекта позволяет начать их использование еще до завершения проекта в целом. Например, завершение этапа по автоматизации учета основных средств предприятия позволяет, не дожидаясь окончания проекта, осуществлять расчет амортизации. Для эффективного управления проектом важными являются все без исключения составляющие. К примеру, даже такая, незначительная на первый взгляд, информация, как сведения о плане отсутствия специалистов (отпуска, командировки и пр.) является необходимой для планирования конкретных работ проекта и соответствующего задействования специалистов. Именно из совокупности таких мелких элементов складывается качественное выполнение проекта внедрения и обеспечивается гарантия успеха проекта в целом. ***Системная документация*** Пристальное внимание следует уделить формированию системной документации. Для формирования документации можно использовать диаграммную технику представления управленческих процессов. Примером такой техники могут служить IDEF-диаграммы. При помощи функций описываются основные процессы, которые преобразуют входящую информацию и формируют выходную. Количественные функции (длительность, стоимость и т.п.) позволяют моделировать управленческие процессы и анализировать варианты их улучшения. Документация системы должна включать в себя следующие элементы: информационная архитектура, программная архитектура, программно-техническая реализация. Базисом документации по поддержке и дальнейшему развитию КИС должны стать технологические, организационные и методологические составляющие. Эти составляющие представляют собой, по сути, правила изменения системы и могут охватывать все стадии проекта. Документация должна обладать логической полнотой и удобством представления. Предприятия, включая АСУ-подразделения, нередко страдают отсутствием или невыполнением регламентов, слабой дисциплиной в области эксплуатации и замедленном восприятии изменений системы. Язык спецификаций – важная деталь, обеспечивающая возможность «говорить на одном языке» для заказчика и подрядчика. Создание любой составной части КИС должна сопровождаться созданием структурных схем и спецификаций, заранее согласованных с заказчиком. Логическая полнота спецификаций является обязательным условием, как и понимание их формулировок. **Десятый учебный вопрос. Управление рисками.** Выбор и реализация стратегии управления рисками Риск — неопределенное событие (условие), реализация которого влияет на ход проекта и достижение его целей. В любом ИТ-проекте необходимо учитывать несколько крайне важных категорий рисков, ассоциированных как со внедрением, так и с поддержкой, технологическим совершенствованием и в целом управлением системы: - организационные: ассоциированные с поддержкой руководства компании и корректностью проведенного на первом этапе обследования бизнес-архитектуры компании; - ресурсные: риски проектного управления в части «треугольника ограничений»: времени, ресурсов, качества; - проектные: остальные риски проектного управления (в части контроля показателей проекта, управления коммуникациями, мотивацией, интеграцией); - технологические: риски возникновения ошибок, вызванных недостаточно точным анализом и проектированием системы на уровне архитектуры приложений, данных и технологий. Инициирование При старте проекта крайне важна поддержка руководства компании и то, насколько высокий уровень приоритета проекта (в сравнении с другими реализуемыми в компании активностями) будет им определен. Именно здесь на первый план выходит возможный конфликт интересов Бизнеса и ИТ, в случае появления которого может быть выделено недостаточно ресурсов, что повышает потенциальные «шансы» срыва сроков и / или снижения качества проекта в дальнейшем. Также значительные риски предполагает этап обследования, на котором неверная постановка требований (в частности, из-за неэффективных коммуникаций) приведет к несоответствию итогового продукта ожиданиям / потребностям заказчика. Планирование На этапе планирования появляются также новые риски, в частности, нехватка необходимых компетенций у проектной команды для корректного проектирования системы и подготовки к ее реализации. Другой риск – неверная оценка сроков / объема проекта может привести к значительным задержкам проекта, к примеру, по причине опоздания в согласовании контракта на закупку лицензий. Никогда не следует забывать также об ассоциированных со всеми контрагентами: поставщиками, подрядчиками рисках, так как их банкротство, повышение тарифов, невыполнение договорных обязательств может существенно сказаться на ходе реализации проекта. Исполнение Уже во время реализации системы вероятно обнаружение невозможности реинжиниринга бизнес-процессов в текущих условиях, изменение которых потребует значительного увеличения сроков реализации либо бюджета проектов. Отсутствие мотивации у проектной команды, ошибки управления коммуникациями, рисками, интеграцией – все те риски, которые потенциального могут на этом этапе негативно сказаться на реализации проекта. Всегда существуют программные риски при приобретении ПО третьих фирм, однако еще более критичны здесь технологические риски. Ведь любые ошибки проектирования и настройки / реализации системы могут привести к потере данных, невыполнению контрактных обязательств, остановке системы (не говоря уже о последствиях ошибок для систем, выход из строя которых способен повлиять на безопасность жизни и здоровья человека). Мониторинг и управление На этапе мониторинга высокую степень важности имеет сравнение первоначальных целей / задач / содержания проекта и полученного результата для максимально оперативного выявления и устранения замечаний. Именно поэтому столь необходимо участие грамотных специалистов в тестировании системы – и обеспечение всех необходимых для процесса условий и ресурсов. Другим аспектом является вновь управление коммуникации, только уже при опытной эксплуатации и обучении пользователей, так как их участие и содействие крайне важно для последующего успеха проекта. Завершение проекта Основным риском по завершении проекта является изменение как внешних рыночных условий, так и внутренних процессов компании. А значит, решение, создаваемое в ходе проекта, может потерять актуальность, и даже более того — его изменение (в силу сложности и низкой гибкости архитектуры) может оказаться нерентабельным или просто невозможным. Перед началом проекта внедрения необходимо четко уяснить, что может помешать достижению результата, и разработать меры по предотвращению возможных негативных последствий. В первую очередь, проводится идентификация рисков. Их список может быть сформирован руководителем проекта с командой внедрения при дальнейшем согласовании результата с куратором проекта. Этот список может быть представлен в форме таблицы по этапам ЖЦ системы, по этапам управления проектом внедрения, по основным классам рисков и другим видам группировки. Следующим шагом проводится оценка рисков, которые возможно представить в виде таблицы/матрицы, с обязательным указанием описания риска, его возможных последствий в качественном и количественном выражении (либо денежный эквивалент ущерба от реализации, либо оценка по шкале от 1 до 5). Вычисление данного значения чаще всего проводится на основании предварительного анализа вероятных потерь (от временных и денежных ресурсов до ущерба репутации компании, потери рыночной доли и т.п.). На этой стадии возможно использование анализа чувствительности, сценарного анализа, имитационного моделирования Монте-Карло, «bowtie» анализа причин/событий/последствий реализации рисков и прочих специальных методов. Затем указывается вероятность реализации риска (в %), а также возможные меры по снижению этой вероятности либо уменьшению потенциального ущерба. В самом простейшем варианте для получения итоговой оценки для каждого риска необходимо умножить значение Ущерба от реализации на Вероятность осуществления риска (переведя % в значение от 0 до 1). После ранжирования результатов и выделения рисков с наиболее высоким приоритетом назначаются ответственные за управление данным риском и принятие необходимых мер. Определив самые критичные для проекта и бизнеса в целом угрозы, существует несколько стратегий их минимизации.  ***Обеспечение непрерывности бизнеса, планы DRP и BCP*** Для того, чтобы ИТ-инфраструктура не просто соответствовала потребностям бизнеса, но и обеспечивала непрерывность доступа к системе/ предоставляемым сервисам необходимо также предусмотреть концепцию / стратегию непрерывности. В этих целях возможно использовать серверные технологии в различных конфигурациях. В зависимости от ситуации технологические площадки: 1. Могут быть территориально распределены или локализированы. 2. Могут иметь полный или частичный резерв оборудования или не иметь его вообще. - в случае полного резерва при катастрофе на технологической площадке предоставление ИТ-услуги (приложения) обеспечивается за счет оборудования на второй площадке; - в случае частичного резерва основное вычислительное оборудование установлено на одной площадке; - если резервирование не осуществляется, то восстановление на новом оборудовании производится с резервных внешних носителей информации. 3. Могут иметь кластерную конфигурацию (распределение нагрузки между равнозначными активными серверами приложений). При выборе конкретной стратегии непрерывности и восстановления принимаются во внимание следующие аспекты: - уровень критичности приложения (системы), исходя из которого определяется допустимое время восстановления; - режим восстановления (ручной / автоматический); - стоимость реализации; - сложность / время реализации. Подход по реализации стратегии непрерывности бизнеса, как правило, закрепляется в плане обеспечения непрерывности (BCP). План обеспечения непрерывности бизнеса (Business continuity plan, BCP) — документ, предназначенный для выработки и соблюдения мер по минимизации рисков системных сбоев информационных систем компании и снижения возможных их последствий для бизнеса. BCP-план направлен на обеспечение поддержки бизнес-процессов компании во время и после чрезвычайной ситуации и может охватывать либо один отдельный процесс, либо совокупность нескольких. ИТ системы рассматриваются в BCP исключительно с точки зрения поддержки бизнес-процессов и может даже не рассматривать вопрос восстановления процессов, фокусируясь только на временных требованиях непрерывности бизнеса. Основная цель подобного документа – своевременное определение вариантов действий в различных критических ситуациях. В случае подобных происшествий снижается объем финансового ущерба, обеспечивает более быстрое восстановление, а также удовлетворяет требованиям всех заинтересованных сторон (клиентов, акционеров, регуляторов, руководителей) к непрерывности работы компании. Однако список задач по формированию плана обеспечения непрерывности бизнеса охватывает большее количество аспектов: Определение всех рисков для бизнеса с формированием плана работ по каждому из данных рисков (в т.ч. ответственные сотрудники, меры предотвращения реализации рисков и нивелированию их негативного воздействия). 1. Определение критических сервисов/приложений, параметров целевого времени восстановления (recovery time objective, RTO) и целевой точки восстановления (recovery point objective, RPO), стоимости каждого часа простоя. 2. Принципы переноса данных между основной и резервной площадками, выбор оптимального решения (в т.ч. с рассмотрением удаленности резервной площадки, пропускной способности каналов связи). 3. Формирование процесса/процедур восстановления сервиса в случае наступления критической ситуации – разработка плана. План аварийного восстановления (Disaster recovery plan, DRP) — план действий по восстановлению полной работоспособности информационной системы (в т.ч. на альтернативных площадках). План аварийного восстановления, как правило, фокусируется на тех ситуациях, когда доступ к информационным системам отсутствует/ограничен в течение длительного периода. В отличие от BCP, план DRP существует на более операционном уровне, описывая порядок действий (организации технических и организационных решений) по построению системы защиты инфраструктуры ИТ. Для планирования непрерывности бизнеса, как правило, проводятся следующие активности: Разработка политики непрерывности бизнеса – определение требований и основных принципов. Анализ влияния на бизнес BIA (business impact anaylsis) — определение критических ИТ-ресурсов, приоритетов восстановления. 1. Разработка/внедрение превентивных мер — внедрение и управление активностями 2. Определение стратегии восстановления. 3. Создание плана обеспечения непрерывности бизнеса BCP 4. Тестирование и обучение персонала. 5. Эксплуатация плана BCP – в т.ч. мониторинг реализации и обновление плана, взаимодействие с внешними контрагентами по вопросам непрерывности бизнеса. Обеспечение информационной безопасности на предприятии Цель информационной безопасности – обеспечить бесперебойную работу организации и свести к минимуму ущерб от событий, таящих угрозу безопасности, посредством их предотвращения и сведения последствий к минимуму. С точки зрения безопасности все виды информации, включая бумажную документацию, базы данных, информационные системы, съемные носители, разговоры и другие способы, используемые для передачи знаний и идей, требуют надлежащей защиты. Информация и поддерживающие еѐ информационные системы и сети являются ценными производственными ресурсами организации. Их доступность, целостность и конфиденциальность является приоритетными направлениями программы развития информационной безопасности. 1. Сетевая безопасность. На этом уровне реализуются задачи защиты внешнего периметра и локальной сети: - потоковое сканирование входящего трафика; - IPSEC/SSL VPN сервера, в т.ч. поддержка мобильных устройств, удаленного доступа, токенов, RSA-сертификатов; - выявление / блокирование атак, вирусов, вредоносного ПО; - предотвращение вторжений; - веб-фильтрация по предустановленным категориям трафика между объектами ЛВС и глобальной сетью. 2. Защита серверов и рабочих станций. Защита от несанкционированного доступа и воздействия вредоносного ПО на пользовательские и системные файлы Защита серверного оборудования, рабочих станций и мобильных устройств: - антивирусная защита; - межсетевое экранирование трафика на конечном устройстве; - контроль целостности файлов. 3. Контроль и управление доступом. Создание централизованной системы идентификации и управления доступом пользователей к корпоративным информационным ресурсам: - централизованное ведение учетных записей пользователей; - поддержка ролевой модели предоставления доступа пользователям; - поддержка механизмов согласования со средствами локального администрирования систем; - поддержка Single sign-on, многофакторной аутентификации и пр. 4. Обеспечение конфиденциальности данных. Обеспечение конфиденциальности данных, обрабатываемой и хранящейся в информационно-телекоммуникационных системах (в частности, в области коммерческой тайны и персональных данных сотрудников, клиентов, контрагентов): - использование меток данных; - шифрование данных; - управление сертификатами ЭЦП; - мониторинг доступа пользователей к данным; - контроль печати конфиденциальных документов и записи информации на внешние носители данных. 5. Защита от утечки данных. Функции контентной фильтрации трафика, URL фильтрации, e-mail фильтрации, а также контроль съемных носителей и печати конфиденциальных документов. 6. Построение централизованной системы управления и мониторинга средств информационной безопасности. Внедрение совокупности решений в централизованную систему мониторинга для обеспечения контроля событий ИБ и оценки защищенности инфраструктурных компонентов: - устройств сетевой безопасности; - конечных устройств; - системы централизованного управления доступом; - dlp компонент; - системы сканирования уязвимостей; - прочие средства безопасности. Проводятся также следующие активности: - инвентаризация информационных активов; - ведение/анализ журналов/логов сетевого оборудования, межсетевых экранов, операционных систем, СУБД, приложений; - аудит управления обновлениями; - тестирование на проникновение. При реализации инициатив необходимо не только провести интеграцию отдельных технических решений, но и принять ряд организационных мер: o разработать соответствующее методологическое обоснование (детальная политика безопасности, роли и матрица доступа пользователей всех приложений, классификация инцидентов информационной безопасности и т.д.); o подготовить организационно-распорядительные документы по управлению и взаимодействию в области информационной безопасности; o зафиксировать зоны ответственности подразделений. **Одиннадцатый учебный вопрос. Сбалансированная система показателей.** Концепция Сбалансированной системы показателей BSC впервые была представлена в работах Каплана и Нортона, определивших набор показателей, позволяющих руководителям компаний получить полную высокоуровневую картину состояния бизнеса и адекватно оценить степень реализации своего видения/стратегии, их внешние и внутренние перспективы. Представляя модель как инструмент стратегического управления, авторы предложили, исходя из видения развития компании определять цели, показатели эффективности (финансовые и нефинансовые), их целевые значения и инициативы по достижению. Всего в BSC выделяется четыре основные точки зрения / перспективы, по сути являющиеся основными направлениями развития любой компании, для которых и определяются в дальнейшем стратегические цели: - финансовая; Бизнес-выгоды от реализации проектов - клиентская; Повышение уровня обслуживания и удовлетворенности пользователей - процессная; Совершенствование процессов, обеспечение качества и внутренней эффективности. - обучение и развитие. Эффективность управления персоналом, мотивацией, знаниями. Управление инновациями. Для всех стратегических целей в соответствии с BSC определяются основные ключевые показатели эффективности (факторы, влияющие на достижение этих целей и оценивающие прогресс компании в этом направлении) и критические факторы (по сути – основные риски). Для определения КПЭ необходимо проведение следующих действий: 1. Документирование бизнес-процессов. 2. Определение целей бизнес-процессов. 3. Формирование индикаторов их достижения в количественных и качественных терминах. 4. Определение критических значений для созданного списка показателей эффективности (для дальнейшей оценки степени отклонения от эталонных значений).