ITSM. Основы и функции ITSM. Преимущества ITSM. ITIL. Service-oriented architecture

Лекция ITSM. Основы и функции ITSM. Преимущества ITSM. ITIL. Serviceoriented architecture Аннотация: Архитектура предприятия и ИТ-архитектура. Общие понятия и определения. Архитектурные модели и точки зрения. Роль CIO архитектор архитектуры предприятия. предприятия. Четыре традиционных Архитектура как уровня описания процесс. Процесс планирования архитектуры Стивена Спивака. Модель TOGAF. Стандарты архитектуры предприятия. Инструменты построения архитектурной модели. ИТ-архитектура — точка зрения бизнес-заказчика. Взгляд бизнеса и ИТ на архитектуру. Введение в ITSM. ITSM. Преимущества ITSM. ITIL. Управление ИТ-процессами и услугами. Основные компоненты системы управления IT-услугами. Архитектура предприятия и ИТ-архитектура Современным организациям необходима достоверная, надежная, безопасная и оперативная информация. Такая информация может быть предоставлена только в результате грамотного использования современных ИТ с учетом как потребностей организаций, так и их возможностей. Только системный подход к получению, обработке и предоставлению информации позволит справиться с этой задачей. «Кусочная» автоматизация отдельных частей предприятий без учета их связей и рассмотрения предприятия как единого целого принесет ему скорее вред, чем пользу, и может затормозить его развитие. Именно поэтому очень важно рассматривать предприятие целиком, для чего служит концепция «архитектуры предприятия». Как область знаний архитектура предприятия родилась в 80-х годах прошлого века в ответ на вопрос: почему такой полезный инструмент, как ИТ, несмотря на значительные усилия заинтересованных сторон, используется неэффективно и непроизводительно? Одна из причин неэффективности — 1 оторванность автоматизации от бизнес-процессов предприятия и несогласованность усилий по автоматизации отдельных подразделений. Общие понятия и определения Архитектура предприятия (Enterprise Architecture) — это область знаний об организации и развитии отдельных частей предприятия. Термин «архитектура предприятия» является сужением термина «архитектура системы», который в соответствии с IEEE определяется следующим образом: Архитектура — это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие ее проектирование и развитие. Предприятие является, несомненно, одной из самых сложных систем окружающего нас мира и для него полностью правомерно использование понятия «архитектура». И чем больше и сложнее предприятие, тем важнее для него архитектурный подход. ИТ-архитектура – это составная часть архитектуры предприятия. К сожалению, до этого термин «архитектура» относился, прежде всего, к программным системам и в основном решал вопрос, на каком оборудовании размещать компоненты приложений. Возможно, именно поэтому до сих пор существует иллюзия того, что архитектура предприятия относится только к ИТ, хотя подобный подход ведет к неэффективной работе как ИТ, так и всего предприятия. Определение из акта Клингера-Коэна четко перечисляет, какие области охватывает архитектура предприятия: Архитектура предприятия – это управленческая инженерная дисциплина, представляющая исчерпывающий обзор предприятия, включая стратегическое планирование, организационное планирование, управление взаимодействиями, улучшение бизнес - процессов, управление информацией и знаниями и операциями. Важно понимать, что вне зависимости от нашего желания архитектура объективно существует у каждого отдельного предприятия, а также 2 холдинга, объединяющего разные предприятия. Причем, как правило, во втором случае архитектура холдинга не является простым объединением архитектур входящих в него предприятий, т.к. существуют сквозные процессы, общие данные и корпоративные системы. Архитектурные модели и точки зрения Архитектура предприятия может быть представлена различными моделями, которые аналогичны проекциям и видам в архитектуре зданий. Каждая модель отражает архитектуру предприятия с определенной долей глубины и соответствия. Существует множество подходов к построению архитектурных моделей предприятия. Выбор модели определяет цель применения архитектурного подхода. Ниже мы подробно расскажем о нескольких самых распространенных моделях архитектуры предприятия – модели Захмана, Стивена Спивака и TOGAF. Кроме них существуют и другие важные архитектурные модели: FEA (Federal Enterprise Architecture, наиболее интересная ее часть – справочная модель производительности (Performance Reference Model, PRM), DoDAF (Departent of Defence Architecture Framework), GERAM (Generalised Enterprise Reference Architecture and Methodology) и MOF (Microsoft Operations Framework). Роль CIO - архитектор предприятия Для моделирования архитектуры предприятия появилась новая роль (должность) - архитектор предприятия. Он отвечает за создание, развитие, актуализацию корпоративных архитектурных моделей. На больших предприятиях в связи со сложностью архитектурных моделей существуют отдельные подразделения, объединяющие таких архитекторов. Архитектор предприятия должен обладать системным подходом, аналитическим мышлением, широкой эрудицией в области ИТ, корпоративного управления, бизнес-процессов и навыками моделирования. Архитектор предприятия должен уметь понимать проблемы и предметную область бизнеса и объяснять их техническим специалистам, а также владеть принципами современных технологий и объяснять их возможности 3 представителям бизнеса. Области компетенции архитектора предприятия показаны на рисунке 1. Рис. 1. Роль CIO - архитектор предприятия. Архитектурный процесс на предприятии должен осуществляться под руководством CIO. В уже упоминавшемся акте Клингера – Коэна, который регулирует политику в области ИТ для государственных организаций США, к инвестициям в ИТ предъявляются следующие требования: • инвестиции в ИТ должны поддерживать стратегию развития ИТ, согласованную со стратегией развитии организации и основываться на архитектуре предприятия; • в каждой государственной организации должен быть руководитель – CIO, показатели деятельности которого должны быть четко определены; • одна из основных функций CIO – развитие архитектуры предприятия. Таким образом, акт Клингера – Коэна провозгласил, что моделирование архитектуры предприятия является основой процесса планирования затрат и управления инвестициями правительства США в 4 области ИТ, и это область ответственности CIO. Хотя в России нет пока аналога акта Клингера – Коэна, нельзя забывать, что одно из самых зрелых с точки зрения ИТ государств считает этот процесс основной обязанностью CIO. Четыре традиционных уровня описания архитектуры предприятия Большинство моделей описания архитектуры предприятия в той или иной степени используют «перспективы», уровни взгляда на предприятие или слои. Как правило, в качестве основных уровней (слоев) архитектуры предприятия рассматриваются четыре архитектуры: 1. Архитектура бизнеса (бизнес-архитектура). 2. Архитектура данных. 3. Архитектура приложений. 4. Технологическая архитектура (инфраструктура). Именно такие уровни (слои) описания архитектуры использованы в моделях TOGAF, FEA, Стивена Спивака, MOF и других. Опишем подробнее, какие элементы включаются в описание каждой из архитектур. 1.Архитектура бизнеса описывает, как работает бизнес. Существует множество подходов к описанию того, как работает бизнес, и нет единого устоявшегося мнения о том, какие элементы следует включить в описание архитектуры бизнеса. Однако, принято считать, что наиболее значимыми элементами в этой области являются «процессы и информация», «организация» и «производительность». Каждый из этих элементов сам по себе очень важен и включает несколько предметных областей. 2. Архитектура данных описывает данные, используемые предприятием 2.1. Структура данных, в свою очередь, состоит из классификаторов и характеристик данных. Выделяются четыре типа данных: мас тер-данные, метаданные, транзакционные и исторические данные (рис. 3). Мастер-данные 5 – это ключевая информация для реализации бизнес-функций компании. Как правило, это данные о клиентах , продуктах , сотрудниках, поставщиках , материальных объектах компании и т.д. Мастер-данные обычно используются различными функциональными подразделениями компании. Рис. 3. Типы данных в описании архитектуры данных. Метаданные – это данные о данных, то есть форматы представления данных. Формат метаданных представляет собой стандарт, предназначенный для формального описания некоторой категории ресурсов (объектов, сущностей и т. п.). Транзакционные данные – это данные, непосредственно описывающие событие, операцию или транзакцию. Исторические данные – это накопленные данные о транзакциях за определенный промежуток времени. 2.2. Требования к переносу данных. При замене существующего приложения всегда возникает необходимость переноса данных в новое приложение. Требования для переноса данных должны определяться на уровне архитектуры данных. 2.3. Требования по управлению данными. Этот элемент описания архитектуры данных описывает ресурсы, которые есть на предприятии для проведения преобразований данных. 3. Архитектура приложений (прикладная архитектура), описывает основные классы приложений, с помощью которых осуществляется 6 автоматизация деятельности организации (бизнес-архитектура) и обработка потоков информации (архитектура данных). Как правило, прикладная архитектура содержит следующие элементы: • классификацию приложений или предоставляемых ими сервисов; • выделение и описание основных классов приложений или групп сервисов, используемых на предприятии; • привязку классов приложений к основным бизнес- процессам организации; • описание взаимодейс твия и взаимозависимос ти корпоративных прикладных программ; • определение функциональных требований к классам приложений или группам сервисов 4. Технологическая архитектура описывает физическое воплощение ИТ-инфраструктуры предприятия и опирается на требования, полученные в ходе описания архитектуры приложений. Существуют различные способы категоризации технологий. Согласно Gartner, технологическая архитектура состоит из шести элементов: • сервисы данных • прикладные сервисы • ПО промежуточному слою • вычислительная инфраструктура • сетевые сервисы • сервисы безопасности Архитектурный подход при внедрении бизнес-приложений — модель Захмана Самой популярной архитектурной моделью, которая активно используется при описании не только архитектуры предприятия, но и архитектуры других систем, является модель Захмана. Подробнее о модели Захмана в Приложении 1. 7 Архитектура как процесс У термина «архитектура» существуют две стороны. Одна – архитектура как описание и вторая – архитектура как процесс, набор руководств и правил, которые определяют построение новых подсистем сложной системы, а, следовательно, для ее развития. Здесь уместно вспомнить определение Gartner: «Архитектура – это глагол, а не существительное». Архитектура как процесс – это один из важнейших процессов предприятия. Архитектура предприятия находится в постоянном развитии от текущей архитектуры предприятия к целевой. Процесс планирования архитектуры Стивена Спивака. Спивак, как и Захман, работал в IBM, был озабочен теми же проблемами и обратился к архитектурным подходам лишь на год позже Захмана. Он соединил модель Захмана с методикой планирования и формирования целевой архитектуры. На практике процесс работы с архитектурой предприятия состоит из пяти шагов: 1. Определение общих контуров архитектуры — какой должна быть архитектура предприятия и зачем мы ее описываем 2. Построение модели архитектуры «как есть». 3. Построение модели архитектуры «как должно быть». 4. Определение шагов, которые позволят перейти от «как есть» к «как должно быть». 5. Формирование путей дальнейшего развития архитектурной модели, т.е. определение правил дальнейшей детализации и актуализации модели, Кроме того, необходимо сделать архитектурную модель общим инструментом бизнеса и ИТ, используя ее для подготовки как стратегических, так и оперативных решений. Это предполагает: 8 • ее доступность и информирование всех заинтересованных лиц о ее наличии; • ее понятность — важно уже на начальном этапе архитектурного процесса согласовать словарь и формулировать принципы создания модели предприятия, которые должны быть понятны всем топ- менеджерам компании; • ее адекватность ситуации на предприятии — поддержка ее актуального состояния. Модель TOGAF TOGAF является промышленным стандартом на описание архитектуры предприятия, который может бесплатно использоваться любой организацией, разрабатывающей собственную архитектуру. TOGAF постоянно развивается с середины 90-х годов, в настоящее время актуальна его 9-я версия. Основное отличие TOGAF от других архитектурных методологий заключается в том, что он фокусируется на процессе разработки архитектур, и его основу составляет подробно описанный пошаговый итеративный метод разработки архитектуры. Методика разработки архитектуры называется Architecture Development Method (ADM), и основные ее компоненты и этапы приведены на рисунке 6. 9 Рис. 6. Основные фазы TOGAF. Стандарты архитектуры предприятия Стандарты архитектуры предприятия определяют понятия, концепции, основные подходы, требования, применяемые для анализа и развития предприятия, как сложной системы, включающей социальные экономические и технологические элементы, которые объединены общим предназначением. Важнейшими стандартами, относящимися к архитектуре предприятия, являются стандарты ISO 14258:1998 (с изменениями от 2000 г.) и ISO 15704:2000. Подробнее о стандартах в Приложении 2. Общие принципы построения архитектурной модели Построение архитектурной модели — архитектурный процесс — подчиняется определенным принципам. Важнейшие из них: 1. Принцип постепенной детализации. Следует начинать с взгляда на предприятие с большой высоты (перспектива «хозяин» в модели Захмана или архитектура бизнеса в модели TOGAF и др.), а не с подробного описания одной или нескольких нижележащих элементов. 2. Принцип согласованности слоев. В случае, если за основу взято наиболее популярное представление архитектуры предприятия как «слоеного 10 пирога» (четыре уровня в модели TOGAF или «перспективы» в модели Захмана), необходимо добиваться согласованности слоев. Ведь цель построения архитектурной модели — получить единую и взаимосвязанную картину предприятия. 3. Принцип независимости слоев. Вместе с тем, слои (уровни, «перспективы») должны быть независимы. 4. Принцип полноты. Модель архитектуры предприятия должна описывать предприятие с требуемой полнотой. В то же время, не следует увлекаться большим количеством архитектур и уровней, так как это усложняет модель. 5. Принцип непротиворечивости. Элементы архитектурной модели не должны противоречить друг другу. 6. Принцип отсутствия дублирования. Элементы архитектурной модели не должны дублировать друг друга. 7. Принцип постоянной трансформации текущей архитектуры предприятия. Не следует забывать, что любое предприятие находится в постоянном развитии. С чего начать? Если CIO ограничен во времени и ресурсах, то не стоит сразу браться за полное описание архитектуры предприятия. В самом начале процесса надо выбрать те уровни взгляда на предприятие (слои), которые для вас наиболее важны. В этом случае вы сосредоточитесь на основных проблемных областях, где использование архитектурного подхода может принести наибольшую пользу, при этом не распыляя свои усилия. Как правило, наибольшее количество проблем организации выявляется на трех уровнях архитектуры: бизнес-архитектуре, архитектуре данных и приложений. С этих трех уровней мы и рекомендуем начинать описание архитектуры предприятия. Нередко у того, кто приступает к описанию архитектуры предприятия, возникает соблазн ограничиться только уровнем архитектуры приложений. 11 Однако, важно понимать, что описание только уровня архитектуры приложений приведет к неверным результатам. Кроме того, в дополнение к четырем традиционным уровням архитектуры мы рекомендуем выбрать уровни взгляда на предприятие (слои), которые важны для вашего предприятия. Если у компании есть филиалы, то в общем случае стоит задать руководству два вопроса, которые относятся к архитектуре бизнеса: 1. Степень централизации – насколько тесно связаны между собой подразделения филиалы организации. 2. Степень унификации – насколько одинаковы должны быть ИТсистемы, используемые для схожих бизнес-процессов. Это не такой простой вопрос, как кажется. Ведь если унификация позволяет сократить затраты на ИТ, то специализация позволяет получить конкурентные преимущества и повысить гибкость организации. Поэтому далеко не всегда цветовая однородность рисунка 8 – это цель, к которой должна стремиться компания. Инструменты построения архитектурной модели Существует относительно много языков моделирования архитектуры предприятия. Прежде всего – это семейство языков моделирования IDEF (Integrated Computer Automated Manufacturing De^nition), которое возникло в середине 70-х годов в ВВС США, как решение проблемы повышения производительности и эффективности информационных технологий. Часть стандартов этого семейства может быть использована при построении моделей архитектуры бизнеса, архитектуры данных и прикладной архитектуры. Подробнее о инструментах построения архитектурной модели в Приложении 3. Архитектурные стили — SOA и MDA Если у предприятия есть архитектура, то она может выглядеть тем или иным образом, использовать типовые модели и метамодели. Варианты архитектур по определенным признакам группируются в стили. Остановимся 12 на двух современных архитектурных стилях: сервисная архитектура и архитектура, управляемая моделями. Заметим, что к прикладным архитектурным стилям также часто также относят два противоположных подхода: все на базе «единой системы» или набор «лучших в своем классе» приложений. Подробнее о этих стилях в Приложении 4. ИТ-архитектура — точка зрения бизнес-заказчика Многим руководителям ИТ-служб знакома следующая ситуация: внедрили ERP-систему, а после года эксплуатации она «как мхом» обросла доработками, которые превратили ее во много маленьких «лоскуточков»... Создание устойчивой ИТ-архитектуры, которая выживает после нескольких лет эксплуатации, происходит далеко не во всех случаях. Очень часто отторжение ИТ- архитектуры начинается уже в проекте. И здесь проще всего показать пальцем на «кривые руки» разработчиков, консультантов и руководителей проектов или на «сырые» системы производителей. Однако существуют более фундаментальные причины отторжения ИТархитектур. Выживает не то, что заказывают и внедряют, а то, что реально используют. И дело даже не в том, чтобы точно угадать требования бизнеса к информационным системам, а в том, что эти требования могут меняться. Изменчивость бизнеса – вот фундаментальный фактор, определяющий устойчивость той или иной ИТ-архитектуры. И это не прихоти отдельных руководителей, это – объективная природа самих бизнесов, а отторжение или принятие бизнесом ИТ-архитектур – это их «естественный отбор». Каждый тип моделей соответствует определенному уровню развития программной системы: • исходной является так называемая «независимая модель вычислений» (Computational Independent Model, CIM), где аналитиком описывается бизнеслогика системы; 13 • далее она трансформируется в платформо-независимую модель (Platform-Independent Model, PIM), в которой систему описывают уже ИТархитекторы; • далее она трансформируется в платформо-специфичную модель (Platform-Specific Model, PSM), создаваемую разработчиком системы и уже использующей преимущества выбранной платформы и обходящей ее недостатки к программному коду; • платформо-специфичная модель автоматически или с минимальным участием программиста приводится к исполняемому коду и соответствующим структурам данных. Таким образом, мы получаем три подуровня прикладной архитектуры. Уровень CIM лежит ближе к архитектуре бизнеса, код – к инфраструктуре. Стандарт MDA содержит правила перехода от уровня CIM к PIM и от уровня PIM к PSM для некоторых платформ, в число которых входят CORBA, J2EE, .NET. Стиль ИТ-архитектуры При всем возможном разнообразии архитектур можно выделить лишь ограниченное количество устойчивых типов, обладающих своей внутренней логикой. Эксперты Gartner Group называют это стилем архитектуры и выделяют два таких стиля: «Сильная интеграция» и «Слабая интеграция»30. Помимо этих двух стилей широко распространен еще один, который хорошо знаком каждому ИТ-директору, многократно раскритикован, но абсолютно неистребим в реальной практике ИТ: «Лоскутное одеяло». Исторически первым возник стиль «Лоскутное одеяло», он же имеет и самое широкое распространение. За ним последовал стиль «Сильная интеграция», который сформировался в мире в 90-е годы на волне ERP-систем и технологий реляционных баз данных. «Слабая интеграция» – сравнительно молодой стиль, возникший в последнее десятилетие на волне Интернета, ECM-систем и сервисно-ориентированных технологий (SOA). Стиль ИТ-архитектуры – это взгляд на информационные системы не со стороны системного архитектора или разработчика, а со стороны бизнеса. 14 При решении своих задач бизнес видит рабочие места, их функциональность и данные. О том, на каких программных и технических средствах они могут быть построены, бизнес, может быть, и догадывается, но знать это не обязан. Для него ИТ-архитектура – это логика, связывающая ИТ-компоненты с его бизнес-процессами, формами организации и знаниями сотрудников. Стиль ИТ- архитектуры – это специфическая логика, связывающая все части архитектуры (бизнес-архитектура, архитектура данных, прикладная и техническая архитектуры) в одно целое. Логику стиля задает основной механизм интеграции данных. Именно он определяет возможности по адаптации информационных систем к изменениям в бизнесе. В информационных системах, поддерживающих системы управления бизнесом, данные – самая инертная компонента ИТархитектуры. Данные способны пережить не одно поколение бизнесприложений. Прикладная архитектура меняется, а данные наследуются. Бизнес-архитектура меняется еще быстрее: меняются стратегии и критерии эффективности, меняются бизнес-процессы, меняются и организационные структуры, а данные остаются. Инертность архитектуры данных – это основа непрерывности всей хозяйственной истории бизнеса. Эта история – его важнейший капитал. Описание каждого стиля представим в виде портрета, который отражает сквозную логику механизма интеграции данных через особенности решений в архитектуре данных, прикладной и бизнес-архитектурах. 1. Данные: характер интеграции данных. 2. Приложения: особенности бизнес-приложений. 3. Бизнес-процессы: особенности организации операционных бизнеспроцессов, поддерживаемых ИТ. 4. Квалификация: требования к квалификации рядовых бизнес пользователей и руководителей со стороны бизнеса и ИТ. 5. Организация: особенности организации управления бизнесом. 6. Устойчивость и ее границы: факторы и границы устойчивости. 15 Стили рассмотрим в порядке их возникновения. «Лоскутное одеяло» Наиболее распространенным стилем ИТ-архитектуры и первым по происхождению является «лоскутное одеяло». 1. Данные. Основной ее признак – это большая избыточность данных, их дублирование в различных системах. Фактически передача данных между отдельными приложениями («лоскутами») может сопровождаться вмешательством самих пользователей, подстраивающихся под текущую ситуацию в компании, поправляющих данные задним числом и т.п. 2. Приложения. Бизнес приложения – острова «лоскутного одеяла», к которым постоянно меняются бизнес требования. Приоритет имеет не полнота функциональности приложения, а его гибкость. Если чего нет, быстро допишем. 3. Бизнес-процессы. Бизнес-процессы неустойчивы и быстро меняются, исходя из текущей целесообразности, поэтому их формальное описание часто сильно агрегировано. Приоритет имеет операционная гибкость, а не производительность. 4. Квалификация. К квалификации рядовых операционистов и руководителей не предъявляется каких-либо серьезных требований. Сотрудники, как правило, работают по конкретным поручениям, которые при подобной ИТ- архитектуре очень сильно зависят от сложившейся ситуации. 5. Организация. Структуры управления бизнесом, адекватные этой ИТ-архитектуре, крайне просты и подвижны. Координация деятельности опирается на личные связи в первую очередь между самими исполнителями и прямой контроль их руководителей. 6. Устойчивость и ее границы. «лоскутное одеяло» очень устойчиво и выживает даже в условиях шоковых изменений. Именно межличностные связи и лояльность сотрудников своей компании являются в «лоскутное одеяло» механизмом интеграции данных. «Сильная интеграция» 16 Второй по распространенности и по происхождению является «сильная интеграция». 1. Данные. Можно сказать, что это противоположность «лоскутного одеяла», другая крайность, в которой данные структурированы очень строго и их дублирование сведено к минимуму. На уровне каждой транзакции поддерживается целостность данных. 2. Приложения. Типичным примером сильной интеграции может служить внедренная на предприятии ERP-система или же программа, разработанная самостоятельно, но также поддерживающая целостность транзакций на операционном уровне. 3. Бизнес-процессы. Сильная интеграция ориентирована на автоматизацию именно бизнес-процессов. Они там реально есть и должны быть очень устойчивыми. 4. Квалификация. Требования к квалификации исполнителей на операционном уровне не высоки, т.к. система, по сути, выстраивает «конвейер», к которому достаточно добавить инструкции и пользователей. Пользователь в идеале – мало квалифицированная «прослойка между инструкцией и экраном». 5. Организация. При сильной интеграции крайне важен высокий уровень централизации управления, связанный с наличием центров компетенции, сотрудники которых хорошо понимают: как все работает и на техническом уровне, и на уровне бизнеса. 6. Устойчивость и ее границы. Область устойчивости «сильной интеграции» не так велика, как у «лоскутного одеяла». Так, разработанная модель бизнес-процессов должна быть стабильна, потому что если при сильной интеграции начать менять бизнес-процессы, то это выльется в бесконечную перенастройку. «Слабая интеграция» И третий, сравнительно новый стиль ИТ-архитектуры – «слабая интеграция». Сейчас он только начинает выходить на сцену российского ИТ. 17 1. Данные. Информационное пространство формируют два слоя данных: • Первичные данные, в которые входят такие информационные ресурсы, как документы, почтовые сообщения и базы данных, мультимедиа, ссылки и любые другие источники. • Мастер-данные описания информационных ресурсов: каталоги, классификаторы и словари. В российской практике этот слой данных получил название Нормативно-Справочной-Информации (НСИ) . Работа в этой архитектуре очень похожа на то, как работают с обычными книжными библиотеками: начинают с классификатора информации, рубрикатора, а не сразу с источников-книг. 2. Приложения. При «слабой интеграции» появляется иной подход к бизнес-приложениям. При «сильной интеграции» пользователи работали с функциями приложения, которые они исполняли как операции на конвейере. Задержка в выполнении любой из функции приводила к остановке всего бизнес-процесса, а отказ от выполнения функции пользователю может присниться только в страшном сне. 3. Бизнес-процессы. В «слабой интеграции», как и в «лоскутном одеяле» бизнес-процессы очень подвижны. Но в отличие от «лоскутного одеяла» они предполагают регламентацию через бизнес-правила. Уже появились целые направления, которые описывают происходящее в компании не в терминах бизнес-процессов, а в виде системы бизнес- правил, которые отличаются от процессов тем, что описывают жизнь предприятия не по принципу «делать так и только так», а по принципу ограничения «разрешено все, что не запрещено». 4. Квалификация. За самостоятельность пользователя приходится платить свою цену. Квалификация пользователей на операционном уровне должна быть очень высокой. То же самое можно сказать и об уровне управления, который занимается разработкой и сопровождением НСИ. Слабая интеграция – это не «конвейер», это «среда обитания» 18 профессионалов, где они сами принимают решения о том: как им организовать свою работу. 5. Организация. «Слабая интеграция» требует формы организации бизнеса с очень глубокой децентрализацией и делегированием полномочий. Такая форма организации бизнеса требует наличия единого информационного и сервисного пространства. Если эта архитектура «загустеет» до неподвижных бизнес-процессов, «сдвинется» от сервисов в сторону функций с жесткими бизнес- процессами, - то квалификация профессионалов окажется невостребованной, и они быстро уйдут, не захотев работать простыми исполнителями. Профессионала в конвейер бизнеспроцесса загнать нельзя. 6. Устойчивость и ее границы. «Слабая интеграция» обладает большой степенью избыточности, и серьезным запасом устойчивости. Этим она отличается от «сильной интеграции», где без любого своего фрагмента система становится неустойчивой. Главным механизмом интеграции «слабой интеграции» являются НСИ, сервисное пространство и общие знания профессионалов, основанные на их высокой квалификации. ИТ-архитектура на практике У каждого стиля есть своя зона эффективности. «Сильная интеграция», например, полномасштабная выживает ERP-система, в условиях стабильности бизнеса и ориентирована на обеспечение его эффективности. Она хороша там, где бизнес организован как поток типовых операций, от которых требуется производительность, ритмичность и эффективность. Примером такого машиностроительное бизнеса может служить производство или крупносерийное массовое оказание телекоммуникационных услуг. «Слабая интеграция» выживает в условиях изменчивости и ориентирована на адаптивность. Применять ее стоит в том случае, когда в компании идут изменения и бизнес-процессы уже не являются стабильными. «Слабая интеграция» оказывается эффективной и тогда, когда бизнес делает 19 ставку на индивидуализацию долгосрочных отношений с клиентом. Характерные области применения такого типа ИТ-архитектуры: быстро растущие холдинги, НИОКР, капитальный ремонт, страхование жизни или банковское долгосрочное кредитование. «Лоскутное одеяло» - это единственная архитектура, выживающая в условиях очень высокой изменчивости и острого дефицита, т.е. в шоковых условиях. Она наиболее широко распространена и характерна для бизнесов с жесткой авторитарной властью, ориентированных на межличностные отношения, а не на зафиксированные правила. «Лоскутное одеяло» может быть построено и для крупных компаний, работающих по жестким правилам. В этом случае вся тяжесть жесткой координации «лоскутов этого одеяла» ложится на плечи ИТ-службы. Поскольку в крупных и средних компаниях всегда существуют зоны стабильности, развития и зоны выживания, то реальная их архитектура всегда оказывается комплексной, мозаикой пере численных выше стилей. Важнейшая задача долгосрочного планирования ИТ-архитектуры как раз и состоит в том, чтобы понять: где должны быть проведены границы стилей на едином корпоративном ИТ-ландшафте. Стратегическая ошибка в определении этих границ может очень дорого стоить компании в будущем. Особенно, если компания остановилась на строительстве «сильной интеграции» по всему бизнесу. Например, решили «подогнать» весь бизнес под одну крупную ERP-систему. Не случайно на реальных предприятиях они редко встречаются в чистом виде. Различные стили ИТ-архитектур сосуществуют, образуя, как правило, уникальный «симбиоз», отражая характерный архитектурный портрет каждой компании. Взгляд бизнеса и ИТ на архитектуру Взгляд на ИТ-архитектуру у бизнеса и ИТ может не совпадать. Многие ИТ директора крупных компаний уже столкнулись с аналогом «слабой интеграции» на уровне технической архитектуры. В условиях, когда идет параллельная модернизация бизнес-приложений, их устойчивое 20 взаимодействие превращается в серьезную проблему. А если еще учесть территориальное распределение и разность часовых поясов, то масштаб проблемы взаимодействия увеличивается в разы. Подробнее о взгляде бизнеса и ИТ на архитектуру в Приложении 5. Основы ITSM для успешной карьеры в сфере IT Введение в ITSM. Функции ITSM. Преимущества ITSM. ITIL. COBIT. S3M. ITSM (IT Service Management, управление ИТ-услугами) — подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Управление ИТ-услугами реализуется поставщиками ИТ-услуг путём использования оптимального сочетания людей, процессов и информационных технологий. Для содействия реализации подхода к управлению ИТ-услугами используется серия документов ITIL. В отличие от более традиционного технологического подхода, ITSM рекомендует сосредоточиться на клиенте и его потребностях, на услугах, предоставляемых пользователю информационными технологиями, а не на самих технологиях. При этом процессная организация предоставления услуг и наличие заранее оговоренных в соглашениях об уровне услуг параметров эффективности (KPI) позволяет ИТ-отделам предоставлять качественные услуги, измерять и улучшать их качество. Важным моментом при изложении принципов ITSM является системность. При (управление инцидентами, безопасностью взаимосвязь и изложении и т. д.) в каждого управление обязательном координация с составного элемента конфигурациями, порядке остальными управление прослеживается элементами ITSM его (службами, процессами) и при этом даются необходимые практические рекомендации. Подробнее о ITSM и его функциях в Приложении 6. Преимущества ITSM Выгоды от внедрения ITSM Для руководителей и владельцев: 21 • ИТ, ориентированные на решение задач бизнеса; • Быстрое реагирование ИТ на потребности бизнеса; • Качественный уровень ИТ-услуг для территориально распределённых подразделений; • Объективная оценка качества ИТ-услуг и работы службы ИТ по ключевым показателям эффективности; • Качественное снижение бизнес-рисков, связанных с ИТ; • Повышение продуктивности ИТ; • Ликвидация скрытых и незапланированных затрат на ИТ; • Оценка затрат на ИТ в зависимости от уровня ИТ-услуг. • Для пользователей: • Повышение качества обслуживания и удовлетворённости пользователей; • Уменьшение времени простоев, связанных с ИТ; • Обращение по любым запросам в централизованную службу поддержки; • Возможность проследить выполнение своих запросов; • Гарантированное выполнение запросов в соответствии с согласованным уровнем услуг. Для ИТ-служб: • Улучшение взаимопонимания между бизнесом и ИТ; • Определение чёткого перечня ИТ-услуг с согласованными параметрами качества их предоставления; • Легче обосновывать затраты на ИТ и планировать развитие ИТ в соответствии с развитием бизнеса; • Возможность оценить вклад службы ИТ в общий бизнес; • Повышение удовлетворённости пользователей деятельностью • Проще предоставлять необходимую отчётность; ИТ; 22 • Повышение управляемости ИТ-инфраструктуры; • Получение оперативной и точной информации о составе и состоянии ИТ-инфраструктуры; • Получение объективной информации о работе персонала ИТ- служб; • Чёткое разделение функций, обязанностей и ответственности между сотрудниками; • Возможность точнее оценить потребность во всех видах ресурсов; • Улучшение возможностей для мотивации ИТ-персонала; • Повышение производительности ИТ-службы; • Более эффективное использование полученных опыта и знаний. ITIL В настоящее время ИТ-служба предприятия становится полноправным участником бизнеса, выступая в роли поставщика определенных услуг для бизнес-подразделений, а отношения между ними формализуются как отношения "поставщик услуг – потребитель услуг". Бизнес-подразделение формулирует свои требования к необходимому спектру услуг и их качеству, руководство предприятия определяет объем финансирования для выполнения этих требований, а подразделения ИТ-службы поддерживают и развивают информационную инфраструктуру предприятия таким образом, чтобы она была в состоянии обеспечить запрошенную услугу с заданным качеством. Отражением трансформации роли и места ИТ-службы в структуре предприятий является концепция и модель управления качеством информационных услуг (Information Technology Service Management – ITSM, управление ИТ-услугами). Бизнес-процессы сегодня неразделимы с программными приложениями, техническими ресурсами и деятельностью персонала ИТ-служб, поэтому качество работы последних становится 23 важнейшим фактором, определяющим эффективность деятельности предприятия в целом. Подробнее о ITIL в Приложении 7. COBIT CobIT – подход к управлению информационными технологиями, созданный Ассоциацией контроля и аудита систем (Information Systems Audit and Control Association - ISACA) и Институтом руководства ИТ (IT Governance Institute - ITGI) в 1992 году. Стандарт Cobit ориентирован прежде всего на руководителей предприятий, ИТ менеджеров, и владельцев бизнес-процессов. Ключевые области управления ИТ: • Соответствие стратегии делает акцент на связи между планами бизнеса и ИТ; выявлении, поддержке и контроле за ценностным предложением ИТ; а также на соответствии ИТ и бизнес операций. • Полезность представляет собой реализацию ценностного предложения, контроль за тем, чтобы ИТ обеспечивали определенные стратегией преимущества, сосредоточение на оптимизации затрат и подтверждение подлинной ценности ИТ. • Управление ресурсами посвящено вопросам, связанным с управлением инвестиций критичными и должному ИТ ресурсами, руководству а именно, оптимизацией приложениями, информацией, инфраструктурой и персоналом. Ключевые вопросы касаются оптимизации знаний и инфраструктуры. • Управление рисками требует осведомленности высшего руководства в области рисков, четкого понимания корпоративного подхода в их отношении, соответствия требованиям прозрачности в отношении существенных рисков, включения функции или системы управления рисками в практику организации. • Оценка эффективности представляет собой контроль за реализацией стратегии, результатами проектов, использованием ресурсов, 24 эффективностью процессов и сервисным обслуживанием. Для этого применяются, в частности, системы сбалансированных показателей, которые преобразуют стратегию в последовательность действий, результаты которых измеряются иными, по сравнению с бухгалтерским учетом, методами. 25