Информационные технологии и архитектура предприятия

Оглавление Информационные технологии и архитектура предприятия 1 Процесс разработки архитектуры предприятия 7 Создание и модернизация IT-инфраструктуры 20 Разработка стратегии развития ИТ предприятия 23 ИТ-сервис 31 Информационные технологии и архитектура предприятия Зачем нужна архитектура предприятия? Вопрос о необходимости архитектуры предприятия и архитектуры информационных технологий возникает достаточно часто. Понятие «архитектура» изначально относилась к области градостроительства. Для того, чтобы построить дом или спроектировать город, необходимо иметь определенный план, чертеж, позволяющий оценить все сооружение, в целом, и посчитать затраты на его реализацию. План здания (города) должен четко соответствовать функциональным требованиям заказчика к сооружениям этого класса. Внедрение информационных технологий на предприятии, как и строительство, является сложным трудоемким процессом, но, при этом, многие крупные компании тратят колоссальные денежные средства на внедрение различных информационных систем без малейшего представления об общей концепции развития предприятия. Можно себе представить крупный город, в котором строительство отдельных зданий производится хаотично, без архитектурных планов и долгосрочной концепции развития? Построение комплексной информационной системы современного предприятия можно сравнить по сложности с проектированием города, где информационные системы соответствуют зданиям. Информационные системы, как и отдельные здания, требуют поддержки и правильной эксплуатации, ремонта и модернизации. Но жизненный цикл информационной системы существенно короче жизненного цикла здания. При построении комплексной информационной системы предприятия (как правило, включающей множество различных по функциональности информационных систем или подсистем) необходимо иметь документированную информацию о текущем состоянии и концепцию развития информационных технологий в будущем. Под архитектурой предприятия (Enterprise Architecture, EA), обычно понимается полное описание (модель) структуры предприятия, как системы, включающее описание ключевых элементов этой системы, связей между ними [Сизов, 2008]. Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое «предприятие реального времени») и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения потребностей организации, и способных к взаимодействию и интеграции там, где это необходимо. В основе архитектуры предприятия заложен «Архитектурный взгляд» на системы, определенный в стандарте ANSI/IEEE 1471, как «фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии». Архитектура предприятия описывает деятельность компании с двух основных позиций: • Бизнес-архитектура описывает предприятие с позиции логических терминов, таких, как взаимодействующие бизнес-процессы и бизнес правила, необходимая информация, структура и потоки информации. • Архитектура информационных технологий (системная архитектура) описывает предприятие с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, защита и безопасность. Документирование и оптимизация архитектуры информационных технологий обеспечивает уменьшение уровня сложности информационных систем и упрощает их интеграцию. Оптимизация бизнес-процессов компании и оптимизация функциональности информационных систем, использующихся для автоматизации бизнес-процессов, увеличивает приток инвестиций в информационные технологии. Архитектура предприятия в первую очередь объединяет архитектуру информационных технологий и бизнес - архитектуру в единое целое, обеспечивая комплексный взгляд на обе существующие области. Архитектура предприятия является важным критическим элементом, связывающим информационные технологии, бизнес потребности предприятия и объединяет процессы стратегического бизнес – планирования, прикладные информационные системы и процессы их сопровождения. При этом архитектура предприятия неразрывно связана с основными рабочими процессами: • разработка стратегии и планирование на уровне предприятия; • управление корпоративными проектами. Разработка стратегии современного предприятия (Strategy and Planning) и управление корпоративными проектами (Enterprise program management) включают в себя направление, связанное непосредственно с информационными технологиями. Современные тенденции рассматривают ИТ проекты и стратегические инициативы как определенный актив компании, которым можно управлять аналогично финансовым активам. Управление портфелем информационных технологий (Business and IT portfolio management) – это процесс управления инвестициями в области управления ИТ проектами. Под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов (финансы, люди, оборудование, материалы, энергия), при этом пул ресурсов и результаты всех проектов портфеля находятся в компетенции одного центра ответственности. Аналитики компании META Group считали, что это - область пересечения архитектуры предприятия, стратегии предприятия и управления корпоративными проектами. Стратегия и планирование при этом обеспечивают основу для выработки ИТ стратегии предприятия, в соответствии с которыми появляются проекты внедрения (модернизации) информационных систем. Управление проектами – можно рассматривать, в первую очередь, как механизм, обеспечивающий переход от текущего состояния к планируемому, или, другими словами, переход от текущей архитектуры предприятия к целевой архитектуре [Ермошкин, Тарасов, 2003]. Архитектура предприятия является одним из элементов управление ИТ портфелем и предоставляет необходимую информацию о бизнес-процессах и технологиях, необходимых для их автоматизации. Архитектура предприятия не только является основой для разработки портфеля активов, но также обеспечивает весь жизненный цикл многих ИТ - активов. Архитектура предприятия позволяет увидеть все предприятие целиком, создать цепочку, показывающую воздействие отдельных элементов стратегии развития предприятия на его бизнес-процессы, и их зависимость от информационных систем и технологических элементов. Архитектура предприятия является инструментом управления, обеспечивающим процесс принятия решений об инвестициях в информационные технологии, стирающие грань между бизнесом и ИТ - подразделением. Традиционно считается, что новые инициативы по внедрению информационных технологий должны проявляться в виде требований от бизнеса, и новые информационные системы должны отвечать именно этим требованиям. Но бизнес должен, в то же время, получать и учитывать «сигналы» от ИТ - подразделения, которое, соответственно, должно показывать новые возможности, появляющиеся у предприятия при внедрении новых ИС. Таким образом, архитектуру предприятия можно рассматривать как новый виток развития организационных принципов построения деятельности предприятия, обеспечивающий его эффективное функционирование. Любому предприятию требуется планомерное развитие его структуры, бизнес-процессов, информационных систем и их интеграция между собой. Архитектура предприятия собственно и является планом развития предприятия (целевая архитектура) и документированной схемой того, что происходит в компании в текущий момент времени (текущая архитектура). Текущая архитектура (Current architecture) - описывает существующее состояние архитектуры предприятия. Называется также архитектурой “как есть” или базовым состоянием существующей архитектуры. Текущая архитектура – это отображение объективной реальности, включающей в себя существующие компоненты (бизнес-процессы, информационные системы, технологические элементы) и их связи. Это набор моделей с неизбежными упрощениями, ограничениями и субъективными искажениями. Процесс разработки текущей архитектуры – это, в первую очередь, процесс документирования и поддержания информации о состоянии предприятия в актуальном виде, обеспечивающий регистрацию и контроль информации обо всех элементах архитектуры предприятия, включающий в себя ведение базы данных по архитектурным объектам, осуществление управленческого учета и учета состояния. Процесс разработки текущей архитектуры аналогичен процессу ITIL/ITSM (управление конфигурацией - Configuration Management). Для упрощения работы по разработке текущей архитектуры многие компании используют базу данных конфигурационных единиц (CMDB), дополнив ее необходимой информацией. Целевая архитектура (Target Architecture) - описывает желаемое будущее состояние предприятия или, «что должно быть сформировано». Другими словами, целевая архитектура является будущей моделью предприятия. Целевую архитектуру можно назвать идеальной моделью предприятия, в основу которой заложены: • стратегические требования к бизнес-процессам и информационным технологиям; • информация о выявленных «узких местах» и путях их устранения; • анализ технологических тенденций и среды бизнес деятельности предприятия. Целевая архитектура и текущая архитектура позволяют описать начальное и конечное состояние предприятия – до и после внесения изменений в его структуру, оставляя без внимания сам процесс изменений. Процесс перехода от текущей архитектуры предприятия к целевой переводит предприятие на новую спираль развития и, таким образом, мы можем говорить, что архитектура предприятия характеризуется определенным жизненным циклом, похожим на жизненный цикл информационных систем. Современные подходы к построению архитектуры предприятия традиционно разделяют ее на несколько слоев (предметных областей). Количество архитектурных слоев варьируется в различных методиках. Ниже мы рассмотрим слои, использующиеся в большинстве из существующих методик: • Стратегические цели и задачи предприятия. • Бизнес – архитектура предприятия. • Архитектура информационных технологий (ИТ - архитектура предприятия), в том числе: ◦ Информационная архитектура (Enterprise Information Architecture); ◦ Архитектура прикладных решений (Enterprise Solution Architecture); ◦ Технологическая архитектура (Enterprise Technical Architecture). Стратегические цели и задачи предприятия определяют основные направления развития и ставят долгосрочные задачи и цели. При разработке стратегических целей предприятия необходимо учитывать воздействие информационных технологий на формирование облика современного предприятия. В ходе разработки стратегических целей предприятия формируется (модернизируется) и стратегия развития информационных технологий. Бизнес стратегия – определяет направление развития бизнеса в соответствии со стратегическими целями и задачами, стоящими перед предприятием, и отвечает на вопрос, почему предприятие должно развиваться именно в этом направлении. Бизнес стратегия включает: • Цели и задачи стоящие перед предприятием; • Бизнес решения, необходимые для достижения поставленных целей и задач; • Изменения, которые нужно провести для достижения поставленных целей и задач. ИТ - стратегия определяет направление развития информационных технологий в соответствии с целями, задачами и бизнес стратегией предприятия, и определяет, как может быть реализована бизнес стратегия. ИТ - стратегия включает: • Проекты, которые можно запустить для выполнения бизнес стратегии; • Варианты решения текущих задач и проблем; • Технологии, которые можно использовать для достижения поставленных целей. Бизнес - архитектура предприятия (EBA - Enterprise Business Architecture) – это целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес - целями. В ходе построения бизнес - архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура. Под бизнес - архитектурой, как правило, понимается совокупность моделей бизнес-процессов, организационных, культурных и социальных областей деятельности предприятия. Она учитывает профиль предприятия, его цели, варианты реализации бизнес-процессов. Архитектура бизнес-процессов определяется основными функциями организации и может меняться под влиянием внешней среды. Бизнес - архитектура предприятия неразрывно связана с процессом его управления. Под управлением предприятием обычно понимается деятельность компании с учетом изменений в окружающей экономической и социальной среде. Управленческий персонал распределяет финансовые, трудовые и материальные ресурсы для максимально эффективного достижения стратегических целей и задач предприятия. В ходе разработки бизнес - архитектуры подробно рассматриваются различные модели построения предприятия, соответствующие стратегии его развития. Модели бизнес - архитектуры могут быть разделены на три класса: классические (эталонные), специализированные и специфические. ИТ - архитектура предприятия, или, другими словами, архитектура информационных технологий, представляет собой совокупность технических и технологических решений для обеспечения эффективного функционирования бизнес - процессов предприятия в соответствии с правилами и концепциями, определяемыми бизнес – архитектурой [Данилин, Слюсаренко, 2005]. Архитектура информационных технологий описывает основные информационные системы, их взаимосвязи и включает в себя их принципы развития, совершенствования и поддержки. Таким образом, мы можем говорить о том, что архитектура является самодостаточной и полной динамической моделью системы. Архитектура информационных технологий является неотъемлемым элементом архитектуры всего предприятия и зависит от его целей и задач, стратегии развития, сложившейся модели бизнес процессов. В настоящее время существует множество работ, посвященных исключительно архитектуре информационных систем. Следует отметить, что практически во всех существующих методиках - архитектура информационных технологий является производной (частным случаем) архитектуры предприятия в целом, и рассматривать ее отдельно от контекста предприятия не является целесообразным. Обобщенная ИТ - архитектура должна включать в себя как логические, так и технические компоненты. Логическая архитектура предоставляет высокоуровневое описание миссии предприятия, его функциональных и информационных требований, системных компонентов и информационных потоков между этими компонентами. Техническая архитектура определяет конкретные стандарты и правила, которые будут использоваться для реализации логической архитектуры. Традиционно ИТ - архитектуру предприятия представляют в виде трех взаимосвязанных компонентов: • Enterprise Information Architecture (EIA) – информационная архитектура; • Enterprise Solution Architecture (ESA) – архитектура прикладных решений; • Enterprise Technical Architecture (ETA) – техническая архитектура. В ходе разработки архитектуры предприятия создается модель, включающая информацию о его производственных процессах, информационных и материальных потоках, ресурсах и организационных единицах. При этом модель ИТ - архитектуры непосредственно зависит от роли, которую выполняют информационные системы на предприятии: стратегическая (ориентированная на выполнение сложившихся стратегий и операций), сдвигающая (инструмент для увеличения эффективности бизнеса), поддерживающая (ИС не играют особой роли в функционировании предприятия), заводская (ИС являются обязательным элементом, обеспечивающим функционирование бизнеса). Модель предприятия (соответствующая ее роли) позволяет не только давать лучшее представление о структуре предприятия, но и является эффективным инструментом для анализа экономических, организационных и многих других аспектов его функционирования. ИТ - архитектура предприятия определяет правила формирования всех компонентов ИТ, взаимосвязи между ними и бизнес - архитектурой предприятия. Это связано с тем, что документирование ИТ - архитектуры без ее увязки с бизнес - архитектурой предприятия быстро утрачивает практическую ценность. Информационная архитектура (Enterprise Information Architecture, EIA) или, другими словами, архитектура информации – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий: • Базы данных и хранилища данных. • Информационные потоки (как внутри организации, так и связи с внешним миром). Информационную архитектуру предприятия условно можно назвать уровнем потоков данных. Но при построении информационной архитектуры предприятия нет необходимости создавать модели всех видов данных, используемых на предприятии. Достаточно обеспечить выбор наиболее важных (критичных для предприятия) данных и моделировать их на высоком уровне абстракции. Архитектура прикладных решений (Enterprise Solution Architecture ESA) – или, другими словами, архитектура приложений, включает совокупность программных продуктов и интерфейсов между ними. Архитектуру прикладных решений разделяют на два направления: • Область разработки прикладных систем; • Портфель прикладных систем. Область разработки прикладных систем описывает технологическую часть архитектуры прикладных решений и включает: программные продукты; модели данных; интерфейсы; пользовательские интерфейсы. Область разработки прикладных систем является техническим описанием конкретных приложений. Соответственно, информацию о данных модулях проще всего представить в виде двух следующих схем: • Компоненты и структура системы – внутренняя структура системы, включающая информацию о программных модулях и базах данных; • Взаимодействие с другими системами (интерфейсы) – описывает взаимодействие приложения с внешними объектами (программными продуктами, пользователями). Архитектура прикладных решений описывает ситуацию, сложившуюся в ИТ - подразделении на текущий момент времени (т.е. это картина, демонстрирующая «технологическое обеспечение» бизнес - процессов, где каждой основной бизнес - функции соответствуют определенные приложения). На основе архитектуры прикладных решений строятся планы последующего развития информационных технологий в компании, разрабатываются планы мероприятий и проектов, необходимых для достижения стратегических целей. На данном уровне лучше всего отслеживается взаимодействие бизнес - архитектуры предприятия и ИТ - архитектуры, так как можно определить взаимосвязи между организационной структурой предприятия и используемыми приложениями. В этом случае для оптимизации управления приложениями их разделяют на определенные группы (домены) в соответствии с функциональными возможностями. Следует отметить, что подобное разделение позволяет проще идентифицировать владельца приложения, определять его соответствие бизнес - требованиям. Техническая архитектура предприятия (Enterprise Technical Architecture, ETA) – это совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Другими словами, под технической архитектурой мы будем понимать полное описание инфраструктуры предприятия, включающее: • Информацию об инфраструктуре предприятия; • Системное программное обеспечение (СУБД, системы интеграции); • Стандарты на программно-аппаратные средства; • Средства обеспечения безопасности (программно-аппаратные); • Системы управления инфраструктурой. Техническую архитектуру предприятия можно визуально представить в виде совокупности архитектурных схем приложений, используемых на предприятии. Визуально техническую архитектуру приложения, в свою очередь, можно представить в виде схемы, включающей информацию о серверах, компонентах системы, стандартах (использующихся в данном приложении) и взаимосвязях между ними. Процесс разработки архитектуры предприятия Описание процесса разработки архитектуры предприятия является одним из самых важных элементов наряду с принципами построения архитектуры предприятия. Как уже было сказано выше, разработка ИТ - архитектуры является лишь элементом общей архитектуры предприятия. Разработанная архитектура представляется лишь «застывшей картинкой», отображающей текущее состояние предприятия. В идеале, архитектура предприятия представляет логически связанный цельный план действий и скоординированных проектов, необходимых для преобразования сложившейся архитектуры организации в состояние, определяемое как долгосрочная цель. Аналитики выделяют следующие подходы процессу построения архитектуры предприятия [Schekkerman Jaap, 2003]: • Традиционный подход - требует существенных затрат времени и ресурсов для построения архитектуры предприятии. Первый этап построения архитектуры рассматривается как проект в ходе, которого собирается детализированная информация о состоянии предприятия (текущая архитектура) и на ее основе начинают разрабатываться планы развития (целевая архитектура). Основу данного подхода составляет процесс построения архитектуры предприятия; • Сегментный подход постепенно вводит понятие архитектуры предприятия в компанию. В основе такого подхода заложены принципы построения архитектуры предприятия, на основе которых внедряются новые технологии (информационные системы), стандарты, продукты и услуги. Такой подход позволяет сосредоточить работы на ключевых бизнес функциях предприятия и постепенно внедрять архитектурный процесс по мере появления ресурсов. Следует отметить существование третьего подхода к процессу построения архитектуры предприятия: подхода статус-кво. Суть данного подхода в том, чтобы не внедрять архитектурный процесс на предприятии, или, другими словами, оставить все как есть. Архитектура предприятия развивается циклично. В ходе разработки стратегии развития предприятия выявляются изменения в бизнес - архитектуре предприятия, позволяющие оптимизировать его бизнес - процессы, а изменение бизнес - процессов предприятия непосредственно влияет на изменение ИТ - архитектуры. Далее разрабатывается план миграции, в ходе выполнения которого происходит переход из текущего состояния в планируемое. При этом процесс миграции является лишь очередным шагом на пути преобразования предприятия и его окончание означает переход предприятия на новый виток развития, вновь начинающийся с разработки стратегии. Один из самых первых и наиболее удачных процессов разработки архитектуры предприятия был предложен Стивеном Спиваком (Steven Spewak) и назывался EAP (Enterprise Architecture Planning). Модель выделяет в архитектуре предприятия семь шагов, разделенных на четыре уровня, и обеспечивает высокоуровневый взгляд на предприятие с точки зрения бизнеса [Сизов, 2008]. Уровень 1. Это уровень начала работ и активации архитектурного процесса. На этапе инициирования процесса планирования разрабатываются и описываются основные концепции развития архитектуры предприятия. Разрабатываются принципы построения архитектуры. Уровень 2. Этот уровень описывает состояние предприятия в настоящий момент времени. Другими словами, это уровень разработки текущей архитектуры предприятия. Здесь происходит бизнес моделирование (разработка текущей бизнес архитектуры) и описание текущих систем и технологий (документирование текущей архитектуры информационных систем). Уровень 3. Это уровень описывает возможные варианты развития архитектуры данных, архитектуры приложений, технологической архитектуры в соответствии с требованиями бизнеса. Другими словами на этом уровне происходит разработка целевой архитектуры. Уровень 4. Это уровень, обеспечивающий разработку плана перехода из текущего состояния в будущее. На этом уровне разрабатывается план миграции. Процесс разработки архитектуры предприятия имеет циклическую структуру. Одной из основных составляющих проекта разработки архитектурного процесса является создание структур, обеспечивающих управление и контроль за всем процессом. Архитектура предприятия должна являться основополагающим правилом, законом, в соответствии с которым происходят изменения деятельности компании. Основу управления и контроля архитектурного процесса, как правило, составляет набор руководящих принципов. Многие аналитики выделяют следующий набор принципов: • Внедрение новых систем и модернизация существующих должны проходить оценку эффективности, целесообразности для компании и соответствовать ее стандартам. • Необходимо контролировать изменения бизнес - процессов и информационных систем в рамках их влияния на другие обеспечивающие (зависимые) бизнес процессы и информационные системы. • Архитектурные модели должны поддерживаться в актуальном состоянии. Необходимо обеспечивать контроль целостности моделей и связей между ними. • Должны быть разработаны и поддерживаться в актуальном состоянии стандарты, правила и политики. Все проекты должны контролироваться на соответствие стандартам. • Результаты работы архитектурного процесса должны готовиться в виде рекомендаций, подлежащих утверждению высшим руководством организации. Одним из инструментов, обеспечивающих управление и контроль за архитектурным процессом, является создание архитектурного комитета во главе с одним из топ менеджеров. Функции архитектурного комитета заключаются в отслеживании и одобрении проектов и инициатив, существующих в компании, и оценке целесообразности их проведения. Следует отметить, что вместе с созданием архитектурного комитета на предприятии создается еще один бюрократический уровень, позволяющий активировать и останавливать проекты. Недостатком архитектурного комитета может оказаться возможность задержек при рассмотрении вопросов в ситуации, когда требуется быстрое принятие решений. Разработка архитектуры - процесс, требующий привлечения большого числа участников и рациональной организации их работы. В связи с этим выбор методологии является необходимой и важной задачей, так как от правильного ее решения зависит успешность усилий, затрачиваемых на разработку и поддержание архитектуры. В настоящее время существует множество методик построения архитектуры предприятия. Данная лекция не ставит своей целью описать все множество существующих в настоящее время методик разработки архитектуры предприятия, поэтому ниже приведена информация о наиболее популярных в настоящий момент моделях. Следует отметить, что архитектурные методики претерпевают постоянные изменения вместе с новыми тенденциями в области управления предприятием и развитием информационных технологий. Первые версии многих современных методик были разработаны еще в 90-х г. прошлого века [Zachman J. A., 2002]. Многие из них постоянно модернизируются или становятся основой для других, более современных методологий: • Zachman framework – методика, опубликованная впервые в 1987 году Zachman Institute for Framework Advancement (ZIFA). Методика постоянно обновляется и поддерживается в актуальном состоянии. Лежит в основе многих программных продуктов для архитектурного моделирования (например, CASE Wise). • EAP (Enterprise Architecture Planning) – коммерческая методика, разработанная в 1992 г. Стивеном Спиваком (Steven Spewak) на основе двух верхних уровней Zachman framework: Scope (Planner) и Business Model (Owner). Методика представляет собой архитектурный процесс, обеспечивающий инициализацию и разработку архитектуры в рамках всего предприятия. • PERA (Purdue Enterprise Reference Architecture). Методика разрабатывалась в 1989 – 1992 гг. в Purdue Laboratory for Applied Industry Control (PLAIC). В основе методики заложена декомпозиция плана внедрения информационной системы на отдельные шаги и упрощения за счет этого ее внедрения и интеграции. В настоящее время эту методику не поддерживают в актуальном состоянии. • TOGAF (The Open Group Architecture Framework) была разработана в 1995 г. Методика позиционируется авторами как средство разработки информационных систем. Методика сфокусирована на эффективном функционировании приложений, критичных для бизнеса. • CIMOSA (Computer Integrated Manufacturing Open Sys), известная как CIM Open System Architecture, была разработана компанией AMICE Consortium в 1996 г. Методика являлась одной из инициатив в рамках программы European ESPRIT. В настоящее время можно говорить о том, что CIMOSA является европейским архитектурным стандартом для построения комплексных автоматизированных производств (CIM – Сomputer-Integrated Manufacturing), и поддерживает все этапы их жизненного цикла. ◦ IAF (Integrated Architecture Framework) разрабатывалась в 1996 г. В ее основу были заложены: Zachman Framework, EAP (Enterprise Architecture Planning). В настоящий момент эта методика разрабатывается и используется Cap Gemini и Ernst & Young consulting. ◦ FEAF (Federal Enterprise Architecture Framework) – была разработана в 1996г. в USA Chief Information Officers Council. Методика обеспечивает построение крупных комплексных систем для государственных организаций. Данная методика легла в основу многих современных концепций построения архитектуры предприятия (например, Treasury Enterprise Architecture Framework, TEAF). ◦ JTA (Joint Technical Architecture). Первая версия этой методики разрабатывалась для US Department of Defends и была опубликована 22 августа 1996 г. В настоящее время методика поддерживается в актуальном состоянии National Defiance Industrial Association (NDIA). ◦ E2AF (Extended Enterprise Architecture Framework) была разработана в Institute For Enterprise Architecture Development в 2002 г. Методика включает в себя элементы следующих методик: Zachman Framework, EAP (Enterprise Architecture Planning), IAF (Integrated Architecture Framework), Federal Enterprise Architecture Framework. Наиболее интересные методики построения архитектуры предприятия были предложены такими аналитическими компаниями как Meta Group (2002) и Gartner (2005). • META Group выпустила в 2002 г. документ Enterprise Architecture Desk Reference, описывающий подход этой аналитической компании к архитектуре предприятия. В основе методики заложено разделение архитектуры предприятия на четыре основных компонента: бизнес архитектуру, архитектуру приложений, архитектуру информации, архитектуру технологий. • Gartner в настоящий момент разработал архитектурную методику под названием Gartner Enterprise Architecture Framework (GEAF). Методика была опубликована в 2005 г. и существенно отличалась от моделей использующихся аналитиками компании ранее. В основу новой методики лег документ Enterprise Architecture Desk Reference компании Meta Group. Цели и задачи, общая схема Цели и задачи Разница между видением и галлюцинацией состоит в том, что видение предполагает наличие надежного плана миграции, за которым следует отличное исполнение. Клайтон Спранг [6.1] Не надо питать иллюзий насчет того, что работа архитектора заканчивается строительством видения великолепной архитектуры предприятия. Архитектура информационных технологий – это только на 10% видение, а на 90% – кропотливая работа по реализации. Реализация архитектуры предприятия не является проектом в строгом смысле этого слова. Дело в том, что за фазой разработки неизбежно должна последовать деятельность по поддержанию и постоянному развитию архитектуры предприятия, а это более удобно описывать в рамках процессной модели. Однако на практике часто встречаются следующие два случая, когда целесообразно организовать выполнение специального архитектурного проекта. Мы уже отмечали, что с учетом существующего реального состояния дел большинство организаций либо не имеют формализованной определенной архитектуры, либо эти определения неполны и недостаточно четко связаны с требованиями бизнеса. В таких случаях имеет смысл организовать работу в рамках специального проекта с определенными сроками и результатами, основной целью которого будет являться создание первоначального описания архитектуры организации и создание механизмов для ее последующего поддержания и развития. Первоочередными задачами такого проекта являются: • организация необходимых структур с привлечением руководства предприятия, бизнес-подразделений и планирование работ; • понимание стратегии развития бизнеса организации; • формирование общих для бизнеса и ИТ требований к целевой архитектуре; • разработка концептуальной архитектуры в виде согласованного и полного набора принципов, в соответствии с которыми будет проводиться разработка архитектуры отдельных доменов (предметных областей или частных архитектур). Для многих организаций отправной точкой в создании общей архитектуры предприятия может стать существующая ИТ-архитектура. Другим возможным вариантом выделения такой деятельности в отдельный проект может явиться потребность в проведении эволюционного скачка в архитектуре. Например, открытие нового бизнес-направления или внедрение новой ERP-системы потребует значительных изменений в вычислительной и сетевой инфраструктуре, реорганизации ИТ-службы и т.п. Возможностей существующей группы поддержки архитектурного процесса окажется недостаточно для решения таких задач, и потребуется привлечение дополнительных внутренних и внешних ресурсов, что опять-таки удобнее выполнять в рамках четко определенного проекта. Какую бы архитектурную методику вы ни выбрали, при всех расхождениях в деталях проект работы над созданием архитектуры обычно включает решение следующих задач [6.2], [6.3]: 1. Определение и обоснование цели – ответы на вопросы Почему? и Что? 2. Выполнение ряда шагов, связанных с инициацией процесса разработки архитектуры (см. ниже). 3. Определение существующего состояния архитектуры ( "as is") для каждой выбранной области (домена) – отправная точка ответа на вопрос Где? 4. Определение целевой архитектуры – конечная точка ответа на вопрос Где? 5. Анализ расхождений между текущим и желаемым состоянием. 6. Разработка плана перехода – ответы на вопросы Когда? и Как? 7. Подтверждение (проверка) достижимости – можно ли на самом деле достичь конечного состояния из данного начального состояния с учетом существующих ограничений? 8. Выполнение намеченного плана. Здесь стоит особенно отметить важность усилий для решения третьей задачи. С одной стороны, формирование целостного описания существующей архитектуры может потребовать проведения настоящих "археологических раскопок" в ранее существовавшей документации, изучения существующих преданий и посвящения в "тайные знания" о годами работающих системах. С другой стороны, здесь важно определить набор целевых метрик (надежность, стоимость эксплуатации и т.п.) и их начальных значений – иначе потом будет очень трудно объективно оценить, достигнуты ли цели проекта. Начальные действия по инициации самого проекта разработки архитектуры включают следующие шаги: • определение "устава" (основных правил) и границ проекта; • бизнес-обоснование реализации проекта разработки архитектуры предприятия; • получение поддержки высшего руководства; • определение состава рабочей группы (организационная структура и участники); • проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры; • создание рабочих групп, которые будут разрабатывать различные фокусные области или домены в рамках общего проекта (например, бизнес-архитектура, архитектура информации, прикладных систем, инфраструктуры). Высокоуровневые документы, которые должны быть результатом первоочередных шагов, являются ключевыми для дальнейшей, более детальной проработки архитектуры. Они создают некоторый культурный контекст всех усилий и обеспечивают связь работы по созданию архитектуры с бизнес-стратегиями и приоритетами предприятия. Список этих высокоуровневых документов может включать: • бизнес-факторы, влияющие на деятельность предприятия; • внутренние и внешние технологические факторы; • формулировку общего видения архитектуры предприятия; • высокоуровневые принципы. Важной составляющей всего проекта является создание структур управления и контроля архитектурного процесса (governance), который должен обеспечить то, что сообщество специалистов на практике использует результаты этих работ; вторая серьезная задача – обеспечение связей процесса разработки архитектуры с процессами бизнес-планирования и выработки ИТ-стратегии. Общая блок-схема процесса в итоге выглядит, как показано на рис. 10.1. В принципе, существуют три возможных подхода к организации процесса разработки архитектуры: • Традиционный обычный подход. Он требует существенных начальных затрат времени и ресурсов для достижения первых ощутимых результатов. В этом подходе в первую очередь разрабатывается регламент для будущего описания архитектуры. Затем должно быть определено текущее базовое состояние архитектуры и только после этого представлена целевая архитектура. Лишь когда все эти действия закончены, начинается детальное проектирование и разработка необходимой архитектуры предприятия. • Сегментный подход. Суть этого подхода состоит в постепенной поступательной разработке сегментов архитектуры в рамках общей структуры, описывающей принципы архитектуры ИТ. Этот подход сосредоточивается на главных бизнес-сферах и областях архитектуры и имеет больше шансов на успех, поскольку усилия ограничены пределами общих выполняемых функций, а также сфер специфической деятельности предприятия. • Подход статус-кво или "оставить все как есть". Но, как мы уже говорили, результатом этого будут провалы в попытках наладить информационный обмен, невозможность реакции на быстроменяющееся окружение. Этот подход также означает постоянную переделку бизнес-функций, снижение производительности, потерянные или упущенные возможности. Рис. 10.1. Основные элементы архитектурного процесса Традиционный, обычный подход при всей кажущейся его правильности связан с риском "паралича анализа", который особенно неконструктивен в российских условиях переходной экономики и процессов реформирования государства. Чтобы сократить возможные риски неудач, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта разработки архитектуры ИТ, рекомендуется второй, т.е. сегментный подход. Семь шагов архитектурного процесса в соответствии с методикой Спивака Один из признанных авторитетов в области корпоративной архитектуры Стивен Спивак (Steven Spewak) предложил удачную модель планирования архитектуры предприятия, которая называется EAP (Entrerprise Architecture Planning – Планирование архитектуры предприятия). Модель EAP соответствует описанному нами выше принципу сегментного подхода к разработке архитектуры и включает 7 шагов, определяющих эту архитектуру и соответствующий план ее реализации (миграции) [6.4]. Эти 7 компонент, условно изображенных на рис. 10.2 в виде "свадебного торта", обозначают смещение фокуса приложения сил на каждом из шагов. Рис. 10.2. Методика EAP планирования Архитектуры предприятия Подход Спивака уже помог очень многим компаниям и государственным ведомствам в организации процесса моделирования, стратегического бизнес-планирования, реорганизации деловых процессов, проектировании различных систем, выработки стандартов на данные, управления проектами. В частности, этой методикой пользовались такие организации, как Federal Express, Министерство энергетики США, Штаб Военно-воздушных сил США и другие. Например, в Министерстве энергетики США основная фаза процесса разработки архитектуры ("проект") заняла примерно 6 месяцев. Методика EAP обеспечивает высокоуровневый взгляд на предприятие с точки зрения его бизнес-функций и требований в области информации. Это инструмент планирования, а не детального проектирования архитектуры. Результаты планирования используются в качестве основы для интегрированной разработки прикладных систем и технологий, которые обеспечивают потребности бизнеса. Отличительными характеристиками этого подхода к планированию архитектуры являются следующие: • в основе – потребности бизнеса, а не технологические факторы; • основное внимание сосредоточено более на данных и потребностях в информации, чем на процессах; • ответственность за процесс в большей степени несут представители бизнес-подразделений, чем специалисты по ИТ. Если "наложить" методику EAP Спивака на модель архитектуры Захмана (см. "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF" ), то можно сказать, что методика EAP является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия, т.е. это перспективы, соответствующие представлениям об архитектуре бизнес-руководителей: "планировщика" и "владельца". Проектирование систем, которое начинается с третьей строки таблицы Захмана, остается за рамками методики Спивака. Это замечание ничуть не умаляет достоинств методики Спивака, но ниже мы рассмотрим более подробно и остальные элементы архитектурного процесса. Общая схема архитектурного процесса Модель процесса разработки и использования архитектуры Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является систематическое и рекурсивное применение таких принципов, как: • декомпозиция на различные представления архитектуры (предметные области): область прикладных систем, технологическая архитектура и т.д.; • различные уровни детализации и абстракции для описания каждой из этих областей. Схема процесса разработки в самом общем виде представлена на рис. 10.3. Обратим внимание на то, что фактически здесь идет речь о параллельных активностях по определению как целевой архитектуры, так и стратегии ее достижения. Рис. 10.3. Схема процесса разработки архитектуры и стратегии ИТ Эта схема состоит из следующих шагов: • Общим фоном для этого процесса является мониторинг существующих тенденций в области деятельности организации и тенденций в области развития информационных технологий. • Анализ на бизнес-уровне. На первом этапе проводится анализ движущих сил, которые влияют на необходимость использования ИТ с точки зрения основных функций и бизнеса организации. Определяются требования бизнеса и технологии на текущем этапе и на перспективу, которые задают требования к информационным системам. Учитываются тенденции в развитии информационных технологий и мировых аналогов с учетом перспектив развития бизнеса. • На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ. • Принимаются общие для организации стандарты и понятия о том, что такое Архитектура предприятия: принципы, общие методы описания архитектуры и ее разделы, стандарты, конкретные продукты и технологии. • Параллельно с этими процессами выполняется анализ на "системном уровне": аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внедрения технологий и приложений. • Результаты вышеперечисленных этапов являются основой для выполнения "Gap-анализа", т.е. выявления расхождений и различий между существующей ИТ-инфраструктурой и желаемой архитектурой предприятия. • Результаты Gap-анализа ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информационных технологий (перечень критических процессов, подлежащих автоматизации в первую очередь и т. д.), обсуждается план детального анализа. • После этого начинается фаза реализации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия. С практической точки зрения, реализация инициативы в области разработки архитектуры предприятия разделяется на несколько фаз или этапов. На каждом этапе готовится совершенно определенный набор документов и иных материалов, которые создают основу архитектуры и которые позволяют предъявлять видимые результаты деятельности рабочей группы, ответственной за всю инициативу разработки архитектуры в целом. Основой работы на этих этапах является эволюционный, итеративный процесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития (Gap-анализ), который обеспечит синхронизацию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях. Этот процесс условно показан на рис. 10.4. Рис. 10.4. Общая схема процесса разработки архитектуры Таким образом, мы можем сказать, что архитектура является одновременно как постоянным организационным процессом, так и результатом, который материализуется в форме моделей и документов, описывающих существующее и будущее состояние архитектуры. Разработка архитектуры является сложным процессом, который обеспечивает движение от описания общего положения с имеющимися информационными системами и инфраструктурой к практической реализации информационных систем, их эксплуатации и оценке результатов. Процесс носит нелинейный, циклический характер, и было бы ошибкой считать, что разработка архитектуры – это одноразовая кампания, которая обеспечивает простое перемещение информационных систем предприятия из состояния "А" в состояние "Б". Архитектура – это постоянный процесс, который нацелен на обеспечение постоянных улучшений в той области, которая связана с отдачей от использования информационных технологий для реализации бизнес-функций предприятия и его соответствующих подразделений. Процесс разработки и обновления архитектуры должен идти параллельно и одновременно с практической реализацией информационных систем предприятия. Это два взаимосвязанных процесса, которые, однако, имеют различные "скорости протекания". Архитектурный процесс по своей природе является концептуальным, имеет длительный временной горизонт, в то время как реализация систем ориентирована на внедрение конкретных решений и реализацию проектов с существенно более коротким временным горизонтом. Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разработки архитектуры. Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям META Group. Характерными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, даже в случае выбора какой-то другой методики, вам скорее всего придется создавать аналоги этих документов. Каждая итерация включает: • Этап 1: Описание или уточнение Общего видения (видение общих требований к архитектуре). • Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура информации, архитектура приложений, технологическая архитектура и пр. • Этап 3: Разработка или уточнение Плана реализации. При первой итерации этого процесса разрабатываются только те представления (view) архитектуры (предметные области, или домены, архитектуры), которые идентифицированы как наиболее приоритетные (2-3 области). Например, если будет принято решение, что наиболее острой проблемой является инвентаризация существующих на предприятии прикладных систем и составление плана изменения их портфеля (вывод из эксплуатации ряда прикладных систем, обновление или разработка новых), то такая область, как Архитектура прикладных систем, должна разрабатываться в приоритетном порядке. После завершения всех трех этапов первой итерации рабочая группа, отвечающая за разработку архитектуры, продолжает разработку архитектур остальных доменов (предметных областей), не проработанных ранее, с учетом накопленного опыта и информации на предыдущих итерациях. Этап 1: Разработка Общего видения архитектуры Общее видение обеспечивает единое понимание проблемы между функциональным (бизнес-) руководством и людьми, отвечающими за информационно-коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры. Основными элементами Общего видения являются: • описание технологических тенденций, важных для предприятия; • идентификация бизнес-требований и стратегий; • идентификация основных требований к информации и технологиям, которые важны с точки зрения реализации бизнес-стратегий; • идентификация требований к архитектуре предприятия в целом. Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей На этом этапе ведется параллельная разработка Концептуальной архитектуры, основанной на ранее определенных принципах и лучших практиках, а также более детальная проработка Архитектур отдельных предметных областей. Мы уже отмечали, что описание архитектуры как минимум включает модели таких областей, как Бизнес-архитектура, Архитектура информации, Архитектура прикладных систем и Технологическая архитектура. Необходимо определить те предметные области, архитектура которых предполагает первоочередную разработку на первой итерации процесса. Заметим, что основой разработки архитектур отдельных предметных областей (доменов) служит Концептуальная архитектура. Концептуальная архитектура обеспечивает общий анализ всех доменов архитектуры с точки зрения идентифицированных на этапе разработки общего видения принципов и факторов влияния. Целью Концептуальной архитектуры является перевод требований, сформулированных в Общем видении, в набор конкретных принципов, которые будут использоваться на этапе разработки архитектуры отдельных предметных областей. Этап 3: Разработка Плана реализации Этап 3 включает в себя следующие два шага: • Стратегия миграции и планирование реализации. Целью данного шага является определение альтернатив, взаимозависимостей и усилий, необходимых для того, чтобы обеспечить выполнение технологических требований, идентифицированных на предыдущих этапах. Результатом этого шага станет набор проектов, рекомендуемых к реализации с точки зрения достижения желаемого состояния Архитектуры предприятия и Архитектуры отдельных предметных областей. • Расстановка приоритетов в плане разработки и уточнения архитектур отдельных предметных областей. На этом шаге определяются стратегические потребности и необходимые усилия для проработки архитектур отдельных предметных областей, которые либо требуют уточнения, либо не были разработаны на предыдущих итерациях архитектурного процесса. Создание и модернизация IT-инфраструктуры В современном мире невозможно представить себе развитие бизнеса без использования информационных технологий (ИТ). Системы хранения и обмена данными, электронные системы ведения учета и управления, электронная почта, удаленный доступ и многое другое — существенно облегчают решение любых бизнес-задач и организацию бизнес-процессов. Уже сегодня ни одна бухгалтерия не обходится без специальных программ, растет спрос на автоматизированные системы, а бесперебойность работы вычислительного оборудования оказывается в высшей степени критичной для предприятий любого сектора экономики. Значимость информационных технологий признана и на государственном уровне. Государственные и муниципальные учреждения, стремясь к усовершенствованию своей деятельности, внедряют передовые ИТ-системы в рамках множества федеральных целевых программ.    Что же такое ИТ-инфраструктура предприятия и какие качественные характеристики у неё есть? ИТ-инфраструктура предприятия — это единый комплекс, программных, технических, коммуникационных, информационных и организационно-технологических средств обеспечения функционирования предприятия, а также средств управления ими. Вне зависимости от размера организации, качественная ИТ-инфраструктура должна соответствовать четырём ключевым критериям: 1. Доступность. С помощью существующей ИТ-инфраструктуры вы из любого места, в любой момент времени должны иметь доступ к необходимым вам информационным ресурсам, технологическим или программным сервисным службам (сетевой принтер, электронная почта, удаленный доступ к информационной системе и многое д.р.) и иметь возможность их использовать. 2. Надежность. Это более сложный критерий, чем кажется на первый взгляд. Ведь всё, что может сломаться — обязательно рано или поздно сломается. Другое дело, что в случае с надежной ИТ-инфраструктурой, это не станет катастрофой — данные не исчезнут (работает система резервного копирования), не выйдут из строя серверы и рабочие станции (работает система «бесперебойного питания»), выход из строя оборудования не парализует организацию (есть подменное оборудование, есть резервный канал связи, есть возможность работать в «корпоративной системе» в автономном режиме) и многое другое. 3. Безопасность. Данный параметр определяет возможность ИТ-инфраструктуры обеспечить надлежащий уровень разграничения доступа к программно-техническим ресурсам и информации. Информация, содержащая коммерческую тайну, скрыта от посторонних лиц и сотрудников, не имеющих соответствующего уровня доступа. Заблокированы «не нужные» сотрудникам технические ресурсы и существует система аутентификации (распознавания) пользователей и ограничения их прав в отношении ИТ-ресурсов (ограничение доступа к электронной почте и сети Интернет, ограничение возможности записи информации на носители, авторизация пользователей в сети и т.д.). 4. Адаптивность (гибкость и масштабируемость). В рыночных условиях бизнес меняется достаточно динамично. Изменения в ИТ-инфраструктуре, её адаптация к бизнес-потребностям должны происходить также быстро, а добавление или изменение функционала должны протекать плавно и безболезненно как для бизнеса, так и для людей в нем участвующих. 5. Эффективность. Информация — это жизненная энергия современного бизнеса, благодаря которой рождаются инновационные идеи и решения для их воплощения. Сегодня компании с небывалой скоростью создают и обрабатывают гигантские массивы информации. В мире ежедневно создаётся и пересылается свыше 100 миллиардов электронных писем. Уже сейчас, более четверти хранимых данных не используется или устарели. По статистике менеджеры тратят каждый день около двух часов на поиски необходимой информации, но половина найденной информации оказывается бесполезной и в результате огромное количество руководителей не получают необходимых для работы данных или не уверены в их точности. При этом ежегодно возрастает количество данных, хранение и использование которых жестко регулируется законодательством. Именно с указанными проблемами призваны справляться современные ИТ-решения. Компоненты, используемые для построения ИТ-инфраструктуры и максимально отвечающие целям бизнеса, параллельно минимизирующие и оптимизирующие капиталовложения в их приобретение и эксплуатацию, способны справляться с проблемами роста объемов информации и решать задачи, связанные с доступностью, безопасностью, долговременным хранением данных и выполнением требований законодательства.   Всю ИТ-инфраструктуру предприятия можно разделить на две части Базовая инфраструктура — удовлетворяет базовые потребности организации в сервисах, необходимых для работы, и является платформой для поддержки и развертывания служб и приложений, критичных для бизнеса компании. В связи с этим надежность инфраструктурного ядра должна находиться на высоком уровне. Базовая ИТ-инфраструктура состоит из следующих компонентов: – физическая сеть (пассивное и активное оборудование ЛВС); – основные сетевые службы и сервисы; – безопасный выход в сеть Интернет, антивирусная защита; – файловый сервер и файловые сервисы.   Дополнительная инфраструктура — предоставляет сервисы и службы, необходимые для решения конкретных бизнес-задач. Эти сервисы не являются обязательными и развертываются в зависимости от нужд самой организации. Функционирование этих служб напрямую зависит от качества работы ядра инфраструктуры. Дополнительная инфраструктура состоит из следующих компонентов: – службы сетевой печати; – служба корпоративной электронной почты и защиты от спама; – службы внутрикорпоративной связи; – служба совместной работы; – служба удаленного доступа к ИТ-ресурсам; – служба централизованного управления обновлениями; – служба резервного копирования и восстановления данных; – служба централизованного хранения и управления базами данных; – службы мониторинга и управления ИТ-инфраструктурой; – службы управления и настройки параметров безопасности с помощью групповых политик; – службы присвоения сетевых сертификатов и многое другое.   Что-же необходимо для того что бы создать качественную ИТ-инфраструктуру, оказывающую реальную помощь бизнесу и отвечающую его требованиям? Для того чтобы создать качественную ИТ-инфраструктуру, отвечающую всем вышеперечисленным критериям, при её построении или модернизации, вне зависимости от конкретных целей, будь то создание единой информационной среды, автоматизации отдельных торговых или производственных процессов, автоматизации бухгалтерского или налогового учёта, необходимо пройти через следующие этапы: Этап 1: Определение приоритетов вашего бизнеса На этом этапе вы самостоятельно, исходя из «личного» опыта, опыта конкурирующих компаний и компаний партнеров, определите приоритеты развития вашего бизнеса и предполагаемые сферы его информатизации. Этап 2: Определение спектра задач и целей по информатизации бизнеса На данном этапе исходя из определенных вами приоритетов развития бизнеса, совместными усилиями мы определим план действий, задачи и цели информатизации вашего бизнеса. В процессе консультаций наши специалисты ответят на все ваши вопросы и помогут подобрать оптимальные решения поставленных задач и целей. Этап 3: Анализ существующей ИТ-инфраструктуры и существующих бизнес-процессов В соответствии с областью задач мы проанализируем существующую у вас ИТ-инфраструктуру и текущие бизнес-процессы, выявим степень соответствия ИТ-инфраструктуры требованиям бизнеса, найдём «узкие» места и определим и опишем четкие бизнес-требования к выстраиваемой ИТ-инфраструктуре и/или интегрируемому решению. Этап 4: Разработка проекта и подготовка спецификаций На этом этапе, проанализировав бизнес-требования, определяется объём предполагаемых работ, рассчитывается объём необходимых ресурсов, времени и бюджета. Определяются функциональные требования проекта, план миграции данных и пользователей, необходимый уровень программно-технической поддержки. Разрабатываются спецификации; подготавливаются коммерческие предложения и документация, определяющая условия проведения работ, поставки материалов, оборудования и программного обеспечения, программно-технической поддержки. Этап 5: Взаимодействие с партнерами и поставщиками На этом этапе проводятся операции, связанные с поиском и налаживанием контактов с компаниями партнерами (поставщики услуг связи, хостинга, разработчики программного обеспечения и д.р.), закупкой программного обеспечения и оборудования. Этап 6: Развёртывание интегрируемого решения На этом этапе осуществляются работы, связанные с закупкой и поставкой программного обеспечения и оборудования. Ведутся монтажные и сборочные работы. Обучаются пользователи. В информационные системы вносятся рабочие данные. Осуществляется наладка и пуск программно-технических средств в тестовом режиме. Этап 7: Ввод в эксплуатацию и программно-техническая поддержка В своём роде это финальный этап интеграции решения или создания ИТ-инфраструктуры «под ключ». На этом этапе происходит «тонкая» настройка и отладка всего комплекса в целом, ввод интегрированного решения или всего ИТ-комплекса в промышленную эксплуатацию, подписываются документы, подтверждающие выполнение работ и ввод в эксплуатацию. В случае постановки «решения» или «комплекса» на обслуживание — специалисты приступают к осуществлению работ по программно-технической поддержке.   Разработка стратегии развития ИТ предприятия Внедрение ИТ системы может дать значительную эффективность по нескольким направлениям даже в одном бизнес процессе. Комплексная автоматизация учета добавит к эффектам задействованных бизнес-процессов эффект автоматизированной интеграции и консолидированной отчетности. Однако, основная проблема большинства ИТ проектов, заключается в нечеткости целей проекта и как следствие отсутсвии стратегии их достижения. Причиной является незнание всех потенциальных эффектов автоматизации предприятия и способа их достижения. Следствием является несоответствие вложенных ресурсов и полученного эффекта от внедрения новой технологии, а также невнимание к структурным проблемам ИТ предприятия. Документ «Стратегия развития Информационных технологий (ИТ стратегия) предприятия» служит прежде всего для четкого определения целей и эффектов развития ИТ на предприятии. Он позволяет донести до руководства суть возможных перспектив, последовательность, длительность и стоимость шагов для их достижения. Это способствует адекватной реакции руководства на необходимые потребности ИТ для движения к обозначенным целям. Невнятная, или неграмотная ИТ стратегия не достигает обозначенных целей и возвращает предприятию описанные проблемы. Опыт показывает, что методологически-правильная ИТ стратегия часто оказывается невыполнимой на данном предприятии. По этому, мы здесь дополняем методологию элементами позволяющими получить не только результат условно эффективного развития ИТ, но и стратегию, которая имеет реальные шансы быть реализованной в большом объеме. Статья разработана с точки зрения исполнителя проекта. Это значит, что результатом проекта является удовлетворенность Заказчика разработанными документами. Сверхзадачей проекта будет эффективная и органично реализуемая на предприятии ИТ стратегия. Для большинства предприятий Информационные Технологии - это сопутствующее направление занимающееся поддержкой и сервисом основных и других сопутствующих направлений. Данная статья содержит рекомендации по разработке ИТ стратегии именно для таких предприятий.  ЭТАП 1: ПОДГОТОВКА ПРОЕКТА Со стороны исполнителя этап выполняют менеджер и ведущий эксперт проекта. Они проводят встречи: • со спонсором проекта, • с собственниками компании, • с высшим руководством, • результирующая встреча со спонсором проекта. При интервьюирование руководства выясняются: • общее видение бизнеса руководством, • перспективы развития предприятия и ИТ, • корпоративная и бизнес стратегия, • текущие и ожидаемые проблемы предприятия, • приоритетные задачи развития компании, • ресурсы выделяемые на развитие ИТ, • принятая на предприятии политика безопасности информации, • потребность предприятия в средствах автоматизации. Следует также выяснить предпочтения лиц принимающих решения в вопросе внедрения новых информационных технологий: • с опережением конкурентов, • после апробирования новшеств конкурентами, • одновременно с конкурентами. Предварительный анализ полученной информации позволит выяснить: • Какие причины повлияли на решение о разработке ИТ стратегии - ◦ Неудовлетворенность текущим состоянием дел? ◦ Плановое действие в рамках развития предприятия? ◦ Поиском эффективности - все есть а результата нет? • Ключевые направлений бизнеса, подлежащие изучению; • Важные сопутствующие направления; • Требования к информационной безопасности; • Наличие союзников реструктуризации ИТ; • Наличие противников изменения принципов ИТ; • Наличие на предприятии структуры обсуждения стратегических документов; • Наличие в ИТ службе специалистов с высокой квалификацией; • Готовность руководства что то менять в своей работе; • Готовность руководства выделять время, силы и ресурсы; • Готовность делиться властью; • Стратегические потребности бизнеса; • Наличие ошибок прошлого и готовность выделять ресурсы на их исправление; • Единодушие руководства по ряду ИТ вопросов; • Что понимается под ИТ стратегией руководством Заказчика: ◦ система принципов на основе которых будут развиваться компоненты информационных систем компании? ◦ интегрированный подход к автоматизации всех контуров? ◦ описание целевого будущего состояния ИТ и плана движения к нему? ◦ совокупность правил функционирования ИТ? ◦ план помощи ИТ предприятию в более эффективном достижении его задач? ◦ долговременный план действий по информационному обеспечению? Результатом работы проектной команды на первом этапе будут три документа:  ЭТАП 2. СБОР ИНФОРМАЦИИ На втором этапе проектная команда со стороны исполнителя состоящая из менеджера проекта и экспертов по направлениям проводит интервьюирование в соответствии с планом (подготовленным на предыдущем этапе). Задачей встреч является получение следующей информации по каждому направлению бизнес-процессов предприятия: • анализ бизнес-процессов • приоритеты и проблемы развития направления • выявление точек очевидной эффективности, автоматизация которых необходима • модели данных (сложность модели), объемы используемых данных (количество транзакций в день) • диагностика текущего использования ИТ • текущее состояния ИТ сервиса • потребности в ИТ сервисе Ключевым направлением для изучения является департамент информационных технологий • потенциал ИТ сервиса в его текущем состоянии • состояния внешней ИТ среды по технической инфраструктуре (качество услуг) • возможности и качество местного аутсорсинга по программным проектам ◦ Разработка ПО ◦ ИТ консалтинг ◦ Обучение персонала • состояние кабельного и сетевого хозяйства • наличие квалифицированных кадров • состояние рабочих станции и телефонии Для того, чтобы выработать правильные требования к ИТ решениям следует учесть: • географию предприятия • состояние рынка труда ИТ специалистов • цены на услуги (в соответствии с географией) • состояние и динамику ИТ рынка в целом и в регионах предприятия  ЭТАП 3. РАЗРАБОТКА ИТ СТРАТЕГИИ ИТ стратегия компании должна быть нацелена, в первую очередь, на получение конкретных результатов, использования ИТ технологий, во вторую очередь на оптимизацию затрат на ИТ технологий. Ведущий эксперт и эксперты по направления должны обладать достаточным опытом, для того чтобы выявить и рассчитать реальные и возможные эффекты автоматизации бизнес-процессов Заказчика. Во внимание принимаются различные факторы: • используемые на предприятии в данный момент ИТ системы и решения, их эффективность и затраты на их эксплуатацию и развитие; • наличие ресурсов на закупку и эксплуатацию более совершенных систем и решений. Ресурсы которые требуются на развитие информационных технологий определяются не только деньгами. Внедрение системы серьезно затрагивает бизнес-процессы в которых внедряется ИТ решение. Готовность руководства менять эти бизнес-процессы является необходимым ресурсом. Есть и взаимозаменяемые ресурсы, например: ограниченные возможности тестирования системы в условиях близких к реальным заменяются временной остановкой бизнеса в момент внедрения системы и изменении бизнес-процессов. Как следствие важным ресурсом является готовность руководства стимулировать сотрудников предприятия на внедрение ИТ решений, затрагивающих их работу. Стратегия развития информационных технологий должна быть тесно связана со стратегией развития предприятия. В условиях ограниченности ресурсов стратегия развития компании определяет, очередность внедрения - какие ИТ системы и решения следует внедрять в первую очередь. В качестве примера рассмотрим ситуацию выбора системы и две стратегии развития предприятия. В первом случае предприятие планирует открывать филиалы с целью увеличить объемы продаж. Правильной ИТ стратегией будет первоочередное внедрение системы Адресного хранения товара на главном оптовом складе. Такая система позволит ускорить комплектацию и снизить ее ошибки. Как следствие компания сможет повысить отгрузки при тех же объемах склада. Во втором случае компания не имеет возможности интенсивного увеличения продаж и по этому озабочена снижением себестоимости операций. Правильной ИТ стратегией будет первоочередное внедрение системы учета себестоимости товара. При выборе ИТ стратегии следует учитывать не только эффект от внедрения ИТ решений но и снижение совокупной стоимости управления ИТ инфраструктурой. Оптимальная ИТ стратегия является определенным компромиссом между качеством ИТ решений и их стоимостью. На данный момент стоимость ИТ решений для крупных компаний позволяет в этом компромиссе иметь уклон в пользу качества, однако и об оптимизации затрат на ИТ забывать не стоит. Для больших предприятий существует множество способов снижать затраты незначительно теряя качество решений, а иногда даже повышая их. Большинство из них требуют реструктуризации подразделений ИТ, например: • организация централизованных ИТ сервисов; • централизация закупок оборудования и услуг; • стандартизация используемых ИТ технологий. Документ Стратегия развития информационных технологий на предприятии состоит из разделов: • КОНЦЕПЦИЯ, • МЕТОДОЛОГИЯ, • ПЛАН РАЗВИТИЯ.  КОНЦЕПЦИЯ В раздел КОНЦЕПЦИЯ описываются общие принципы и критерии успеха организации ИТ сервиса на предприятии. КОНЦЕПЦИЯ не требует немедленного выполнения а определяет вектор развития информационных технологий, а также цели и критерии успеха последовательно проводимых мероприятий. В качестве примеров приведем наиболее общие (не зависящие от отрасти предприятия) цели развития информационных технологий: • автоматизация основных бизнес-процессов; • повышение эффективности работы существующей технической инфраструктуры; • повышение эффективности работы существующей ИТ службы; • снижение стоимости поддержки технической инфраструктуры и ПО; • создание простого и удобного бизнесу порядка взаимодействия с ИТ подразделениями; • стандартизации технических и программных средств. Следует осторожно относится к выбору целей. Многие цели могут противоречить друг-другу (например снижение стоимости и повышение эффективности). Указанный здесь список есть список примеров целей. Целей проекта должно быть не более трех, причем у них должны быть разные приоритеты. Первая цель имеет наибольший приоритет и т.д. В дальнейшем по завершении определенного периода работы происходит переопределение ИТ стратегии, в рамках которого можно переопределить и цели (например достигнут большой уровень отдачи ИТ для бизнеса, можно сконцентрировать усилия на снижении затрат). Раздел КОНЦЕПЦИЯ описывает принципы: • информационной среды, • построения схемы взаимоотношений между ИТ пользователями ИТ службой, • кадровой политики ИТ подразделений, • структуры ИТ подразделений, • схемы управления ИТ, • финансирования ИТ, • создания единой технической инфраструктуры, • участия менеджеров ИТ в принятии ключевых бизнес-решений, • политики безопасности данных, включая: ◦ типы данных, ◦ единые информационные ресурсы предприятия, ◦ способы хранения данных, ◦ принципы дублирования данных и резервного копирования, ◦ политику разграничения доступа к данным, • принципы политики безопасности сетевой инфраструктуры, включая: ◦ структуру сети и серверов, ◦ рабочие станции подключаемые к сети (бывает, что к сети подключают не все рабочие станции), ◦ возможность работы в сети специалистов других организаций выполняющих работы на предприятии, ◦ принципы работы в Интернет.  МЕТОДОЛОГИЯ В разделе МЕТОДОЛОГИЯ описываются базовые решения и инструкции, а также способы достижения требуемых результатов. Подробно рассматриваются: • список наиболее критичных проблем бизнеса связанных с ИТ услугами; • список проблем ИТ; • список ИТ услуг, которые оказывают (должны оказывать) ИТ подразделения пользователям: ◦ технические средства, ◦ информационные системы и ПО, ◦ рабочие станции, ◦ телекоммуникации, ◦ стандартное, общекорпоративное и прикладное ПО, ◦ поддержка ИТ систем, ◦ хранение и восстановление данных, ◦ планирование и внедрение ИТ проектов; • политика безопасности данных - основывается на положениях концепции (принципы политики безопасности данных) и уточняет: ◦ технологии дублирования данных и резервного копирования, ◦ технологии ограничения доступа, ◦ процедуры получения доступа, ◦ процедуры восстановления утраченных данных; • политика безопасности сетевой инфраструктуры – основывается на положениях концепции и уточняет: ◦ сетевое программное обеспечение, ◦ процедуры подключения рабочих станций к сети, ◦ процедуры подключения к сети специалистов других организаций выполняющих работы на предприятии, ◦ политика доступа пользователей к сети Интернет. Политика доступа к Интернет описывает: • работы, требующие доступа к Интернет; • технические решения организации доступа к Интернет; • ограничения доступа к Интернет. В разделе МЕТОДОЛОГИЯ определяется разграничение задач для центральной ИТ службы и для местных. Обычно задачами центральной ИТ службы становятся: • координации работы ИТ служб; • разработка стандартов технические и программные средства, на новые виды ИТ услуг; • контроля и сертификации внутренних решений; • поддержки централизованных ИТ ресурсов и сервисов; • координация работ по разработке типового ПО; • разработка краткосрочной и долгосрочной ИТ стратегии. В зависимости от принятых решений передаются либо центральной либо местной службе задачи: • информационно-техническая поддержка своих организаций; • подбор рядового ИТ персонала; • анализ потребности местного бизнеса компании в ИТ услугах; • информационно-техническая поддержка аппарата управления; • организация, планирования и внедрения ИТ проектов; • разработка бюджета; • закупка оборудования; • обучение ИТ специалистов. Особое внимание следует уделить специальным услугам автоматизации для управляющего менеджмента предприятия. Основной такой услугой является консолидированная отчетность о деятельности предприятия, описание которой содержит: • список документов, • периодичность, • точность (минимально необходимая), • источники данных, • технологии получения отчетности.  ПЛАН РАЗВИТИЯ В разделе ПЛАН РАЗВИТИЯ описывается планы, способы реализации и бюджеты мероприятий предназначенных для решений задач развития информационных технологий поставленных перед предприятием и ИТ службой. Стратегия развития ИТ связана со стратегией развития предприятия. Ряд мероприятий плана развития ИТ будут частями мероприятий по развитию бизнеса. План может быть разбит на несколько мероприятий с точки зрения объектов и субъектов, например планы: • создания и развития технической инфраструктуры; • реструктуризации ИТ подразделений; • стандартизации ПО; • внедрения ERP системы. В плане создания и развития технической инфраструктуры должны быть подробно расписаны мероприятия развития необходимых и полезных бизнесу технологий: • телефония, • серверные решения, • кабельные системы, • почтовое корпоративное решение, • системы поддержки централизованных информационных ресурсов. План реструктуризации ИТ подразделений содержит последовательность мероприятий по изменению структуры и управления ИТ служб, услуг, кадровой политики и др., например: • создание центральной ИТ службы; • создание периодического совета по стратегии ИТ; • доработка советом по стратегии плана дальнейшей реструктуризации ИТ подразделений; • ликвидация ряда служб; • передача задач другим ИТ службам; • слияние и разделение ряда ИТ служб; • определения регламента взаимодействия перестроенных служб; • создание эффективной системы управления ИТ; • изменение схемы взаимодействия ИТ служб с бизнесом; • создание новых ИТ услуг; • передача части ИТ услуг на аусорсинг в другие организации; • передача части ИТ услуг внутренним ИТ службам из аусорсинга. Если у вас возникают сложности с написанием подробного плана ИТ мероприятий, можно начать с мета-плана – т.е. неподробного плана развития, в котором мероприятия объединены общими целями, например: • устранения наиболее критичных проблем; • стандартизации ПО; • внедрения ERP системы. Далее в мета-план уточняется до мероприятий, далее уточняются детали и ресурсы мероприятий и т.д. Наиболее правильный путь при создании плана развития – это последовательное планирование комплекса мероприятий по достижению требуемых целей. Например, если цель - повышение точности консолидированной отчетности, то последовательность мероприятий: • повышение использования ИТ решений в точках сбора информации; • повышение контроля собранной информации; • доработка отчетности исходя из увеличения подробности и точности входящей информации. Другим примером может быть последовательность мероприятий с целью значительного повышения экономической отдачи ИТ решений: • проведение исследований возможности автоматизации процессов напрямую влияющий на критические факторы успеха бизнеса; • выявления наиболее интересных проектов с точки зрения критерия эффективность/время внедрения и эффективность/стоимость внедрения; • запуск выбранных проектов автоматизации. Если поставлена задача повышения надежности используемых ИТ решений, то нам потребуются мероприятия: • выделение наиболее опасных точек отказа; • внедрение систем повышения надежности (обычно это системы дублирования оборудования критических узлов); • проведение испытаний (искусственное создание критических ситуаций и ситуаций отказа оборудования). При разработке плана развития ИТ большое внимание следует уделять циклам эффективной эксплуатации выбранных решений. Длительность циклов по любым ИТ проектам должна быть больше, чем сроки их окупаемости. ИТ-сервис Information Technology Infrastructure Library (ITIL) Библиотека Information Technology Infrastructure Library (ITIL) — библиотека инфраструктуры информационных технологий, созданная в конце 80-х годов на основе передового опыта ведущих производителей программно – аппаратного обеспечения. Библиотека передового опыта IT Infrastructure Library была разработана Центральным Компьютерным и Телекоммуникационным Агентством (CCTA - Central Communications and Telecom Agency) по указанию английского правительства в целях использования ИТ - службами [Потоцкий, 2003]. ITIL - строго регламентированная система требований и рекомендаций по организации деятельности по управлению предоставлением информационных сервисов (сервисов ИТ или услуг ИТ) в соответствии с определенным уровнем качества и затрат. ITIL - это не продукт, не программа, не система. ITIL - это методология, которая позволит пользователю обеспечить эффективное функционирование служб Информационных технологий, удовлетворение нужд бизнес - пользователей, стабильное и предсказуемое развитие информационной системы. Ключевое понятие в ITIL - управление сервисом ИТ (ИТ услугой). Сервис ИТ - это описанный набор средств, относящихся к ИТ или не относящихся к ИТ, которые поддерживаются поставщиком сервисов ИТ, удовлетворяют одну или более потребностей заказчика, обеспечивают достижение основных целей деятельности заказчика и воспринимаются им как единое целое. Основные идеи ITIL: • Информационная служба — партнер бизнеса. ИТ-отдел не должен быть вспомогательным элементом для основного бизнеса компании, ответственным только за работу отдельных серверов, сетей и приложений, где-то и как-то применяющихся в компании; • Основной продукт ИС — ИТ-услуга. ИТ-отдел становится полноправным участником бизнеса, выступая в роли поставщика определенных услуг (сервисов) для бизнес-подразделений, а отношения между ними формализуются как отношения поставщик услуг - потребитель услуг; • Услуги ИТ - это описанный набор средств, как относящихся к ИТ, так и не относящихся, которые поддерживаются поставщиком сервисов ИТ, удовлетворяют одну или более потребностей заказчика, обеспечивают достижение основных целей деятельности заказчика и воспринимаются им как единое целое; • Управление сервисом включает в себя множество процедур, позволяющих быстро и эффективно формулировать, изменять и контролировать определенные для каждого пользователя уровни сервиса по заранее заданным критериям и параметрам функционирования системы; • Качество услуги – это совокупность характеристик продукта или услуги, которые формируют способность продукта удовлетворять сформулированные и подразумеваемые потребности. В настоящее время существует уже 3 версии библиотеки ITIL. Книги, входящие в ITIL версий 1 и 2, изданные в 2000 – 2004 гг. [Потоцкий, 2003]: 1. Поддержка услуг (Service Support). 2. Предоставление услуг (Service Delivery). 3. Управление безопасностью (Security Management). 4. Управление инфраструктурой информационных и коммуникационных технологий (ICT Infrastructure Management). 5. Управление приложениями (Application Management). 6. Планирование внедрения ITSM (Planning to Implement ITSM). 7. Перспективы бизнеса (Business Perspective) – в разработке. В процессе изучения дисциплины «ИТ-инфраструктура» основное внимание уделяется двум основным книгам: поддержка услуг и предоставление услуг. Блок «Предоставление услуг (Service Delivery)» включает в себя набор бизнес процессов, обеспечивающих разработку качественных, экономически эффективных услуг, соответствующих требованиям бизнеса: ◦ Управление уровнем сервисов (Service Level Management); ◦ Управление возможностями (или мощностями) (Capacity Management); ◦ Управление непрерывностью (Continuity Management); ◦ Управление затратами (или финансами) (Cost Management); ◦ Управление доступностью (Availability Management). Блок «Поддержка услуг (Service Support)» включает в себя набор бизнес - процессов, обеспечивающих стабильность и гибкость функционирования существующих услуг. Бизнес - процессы этой группы ориентированы на обслуживание информационных систем и инфраструктурных компонентов, разрешение инцидентов и проблем, отслеживание изменений: ◦ Управление инцидентами (Incident Management); ◦ Управление проблемами (Problem Management); ◦ Управление конфигурациями (Configuration Management); ◦ Управление релизами (Release Management); ◦ Управление изменениями (Change Management). Описание каждого процесса включает цель, задачи, термины, виды деятельности, показатели эффективности. Управление уровнем сервисов (Service Level Management) – обеспечивает процесс согласования требований к предоставляемой услуге между заказчиком (бизнес подразделением) и исполнителем (ИТ подразделение). Целью данного процесс является достижение соглашения между заказчиком и исполнителем. При этом необходимо найти баланс между требованиями бизнеса и возможностями информационных технологий. Соглашение оформляется в виде документа – соглашение об уровне сервиса (Service Level Agreement, SLA), в котором прописываются все требования бизнес подразделения к предоставляемой услуге в нетехнических терминах. Управление возможностями (Capacity Management) или другими словами управление мощностями обеспечивает предоставление необходимых ресурсов для поддержки существующих услуг. Цель процесса - обеспечить своевременное, ориентированное на будущие потребности бизнеса и эффективное с точки зрения затрат предоставление необходимых мощностей ИТ-инфраструктуры. Управление непрерывностью (Continuity Management) обеспечивает подготовку к чрезвычайным ситуациям, планирование поведения сотрудников ИТ подразделения в случае возникновения проблем и инцидентов, оценивается степень уязвимости существующих информационных систем. Цель процесса - обеспечить восстановление технических средств, а также всей инфраструктуры поддержки услуг в случае бедствия, в соответствии с производственными (временными) планами. Управление затратами (Cost Management) обеспечивает возможность учета финансовых факторов при поддержке и разработке сервисов. Процесс управления затратами необходим для составления бюджета ИТ подразделения и выставления счетов за ИТ услуги бизнес подразделению. Цель процесса - обеспечивать эффективное с точки зрения затрат управление ИТ-активами, которые используются при оказании ИТ-услуг. Управление доступностью (Availability Management) процесс обеспечивающий, разработку, изменения, оптимизацию, сервисов для достижения оптимального, согласованного уровня доступности. В рамках данного процесса происходит проектирование систем для достижения требуемой способности восстановления, разрабатываются планы обслуживания и обеспечения безопасности. Цель процесса - оптимизировать возможности инфраструктуры, сервисов и ИТ-подразделения для предоставления эффективного с точки зрения затрат и постоянного уровня доступности, который позволит бизнесу достигать своих целей. Управление инцидентами (Incident Management) обеспечивает минимизацию отрицательного воздействия сбоев (нарушений работы программно – аппаратных средств) на предоставление услуг и обеспечивает максимально быстрое восстановление работоспособности. Цель процесса - восстановить нормальную работу ИТ-услуги как можно быстрее и минимизировать неблагоприятное воздействие сбоя на работу пользователей и отделов предприятия, таким образом, обеспечивая согласованный уровень качества услуги. Инцидент - любое событие, не являющееся частью нормальной работы услуги и ведущее или способное привести к остановке или потере уровня качества этой услуги. Управление проблемами (Problem Management) обеспечивает минимизацию негативного влияния инцидентов на существующие ИТ услуги и минимизацию количества инцидентов за счет предотвращения возможных причин. Проблема - это инцидент или группа инцидентов, имеющих общую неизвестную причину. Возникновение проблемы сигнализирует о неизвестной причине возникновения нескольких инцидентов и возможности их возникновения в ближайшем будущем. Цель процесса - способствовать обеспечению максимальной стабильности предоставляемых услуг путем определения и устранения ошибок в инфраструктуре, устанавливать корневую причину возникновения проблемы и, как следствие, предотвращать возникновение инцидентов. Управление конфигурациями (Configuration Management) обеспечивает логическое построение модели ИТ - инфраструктуры, включающее в себя описание существующих конфигурационных единиц (приложений, серверов, интерфейсов и пр.) и связей между ними. В процессе также собирается информация об открытых и закрытых инцидентах, проблемах, известных ошибках, изменениях, релизах. Собранная информация сохраняется в базе данных конфигурационных единиц (CMDB, Configuration Management Data Base) и используется различными ИТ подразделениями для планирования работ по оптимизации ИТ - инфраструктуры. Управление релизами (Release Management) обеспечивает разработку, тестирование, распространение и внедрение новых версий программно - аппаратного обеспечения. Процесс обеспечивает оптимизацию внесения всех изменений или обновлений, снижение рисков возникновения сбоев, позволяет правильно распределить существующие на предприятии ресурсы и оценить необходимые сроки для внесения изменений. Управление изменениями (Change Management) обеспечивает использование стандартных процедур и методов для минимизации вероятности возникновения инцидентов. Управление изменениями считается формальным процессом «принятия, записи, авторизации, планирования, тестирования, внедрения и проверки запросов на изменения (RfC)». Цель процесса - обеспечить использование стандартизированных методов и процедур для эффективного и своевременного проведения всех изменений в инфраструктуре и предотвращения связанных с этим инцидентов. ITIL версии 3 был опубликован в 2008 г. [Long, 2008]. В отличие от предыдущих версий в третьей версии ITIL основное внимание уделяется вопросам проектирования ИТ-услуг, управления портфелем ИТ-услуг. Взаимодействие ИТ-организации с бизнесом происходит через формирование стратегии оказания услуг в организации. ITIL версии 3 декларирует принципиальную непрерывность спектра услуг. На одном полюсе стоят услуги, которые бизнес предоставляет, используя только свои собственные ресурсы (бизнес-процессы, персонал, знания и т.п.). На другом – ИТ-услуги, связанные только с использованием ИТ-ресурсов (процессов управления ИТ, персонала, приложений и т.п.). Эти услуги ИТ-организация предоставляет бизнесу. Между этими крайностями расположены услуги, которые используют как те, так и другие ресурсы. Такие услуги планируются и реализуются совместно ИТ-организацией и бизнесом и именно они представляют основной интерес с точки зрения ITIL версии 3. Взаимодействие ИТ-организации с бизнесом происходит на языке услуг, причём потребителями услуг могут быть не только люди, но и бизнес-процессы, другие услуги и даже приложения. Определение услуги формируется совместно, исходя из требований бизнеса (а в конечном итоге его клиентов) и возможностей ИТ-организации (возможно привлечение и третьих сторон - аутсорсеров). Какие для этого необходимы ресурсы и как они должны быть устроены – это дело ИТ-организации. Связь услуг ИТ-организации со стратегией бизнеса обеспечивается через бизнес-процессы: услуги ИТ-организации в первую очередь реализуются для тех процессов, которые являются критичными с точки зрения стратегии бизнеса. Все решения, относящиеся к модернизации информационных ресурсов (процессов, приложений, персонала и т.п.) принимаются только в связи с услугами, которые ИТ-организация предоставляет с помощью этих ресурсов. Перечень услуг ИТ-организации согласован и утверждён бизнесом. Он является основой всех формальных соглашений и пересматривается только по взаимному согласию. Управление портфелем услуг, согласно ITIL версии 3 – это динамический метод управления инвестициями в управление услугами в масштабах всей организации с целью повышения их ценности. Портфель не сводится к перечню услуг, приложений, материальных активов или проектов. Портфель, по сути, это совокупность инвестиций, имеющих общие характеристики. Каталог услуг – это единственная часть Портфеля, которая ответственна за покрытие расходов и получение доходов провайдером. Портфель услуг, по существу, представляет собой стратегию провайдера услуг. Реализация этой стратегии подразумевает принятие целого ряда решений, в частности, о порядке и размерах инвестиций. Эти решения принимаются в процессе управления портфелем. Проектирование ИТ-услуг – часть глобального процесса изменения бизнеса. Книга «Проектирование услуг» охватывает пять аспектов деятельности по проектированию услуг: • новые или изменённые услуги; • системы и средства управления услугами, в особенности Портфель услуг; • технологическую архитектуру и системы управления; • процессы; • методы измерения и метрики. Преимущества ITIL для заказчиков: • Предоставление ИТ-услуг становится более ориентированным на потребности заказчика; • Соглашения о качестве услуг способствуют улучшению взаимоотношений; • Услуги описываются точнее, лучше, на языке заказчика и с требуемой степенью детализации; • Прозрачное качество и стоимость услуг; • Ясная схема взаимодействия с ИТ; • Выше качество ИТ – надежная поддержка бизнес-процессов. Преимущества ITIL для ИТ-подразделений: • Четко понятная структура ИТ-подразделения; • ИТ-подразделение становится более эффективной, рациональной и ориентированной на корпоративные цели; • Более целенаправленное руководство ИТ, облегчается управление изменениями; • Эффективная структура процессов создает основу для аутсорсинга услуг ИТ; • Следование передовому опыту ITIL способствует изменению корпоративной культуры в направлении осознания, что задачей ИТ является предоставление услуг; • Основа для улучшения качества ИТ и внедрения стандартов серии ISO-9000. Стратегическое преимущество ITIL для организации в целом - эффективное управление ИТ в масштабах организации.