Сервисно-ориентированная модель ИТ-службы крупной организации

Современные условия ведения бизнеса характеризуются постоянным изменением внешней среды, непрерывным возрастанием ее неопределенности. Этот вопрос находится в центре внимания многих исследований в рамках теории организации. В частности, П. Друкер [1] считает, что поиск перемен и превращение их в новые возможности для компании – основная задача современного менеджмента. Нестабильность окружения накладывает ограничения и на стратегическое планирование бизнеса. Широкое признание получили принципы формирования корпоративной стратегии Г. Минцберга [2], который отметил, что выраженные вслух намерения (отношение организации к внешней среде – позиция и планы на ее основе) формируются на основе укоренившихся, формально не декларируемых способа восприятия внешнего мира внутри организации (перспективы) и устойчивых характеристик поведения (паттернов). Два принципа (стратегия как план и как принцип поведения) совершенно равноправны: организации разрабатывают планы на будущее и выводят принципы поведения из своего прошлого, которые постепенно изменяются вместе с новыми ситуациями.

Применительно к корпоративным информационным системам (ИС) ряд аналогичных концепций предложил К. Сиборра [3]. В частности, он выделил подход к развитию ИС, названный им bricolage или импровизация, – постепенное улучшение уже существующих систем, вовлечение работников операционного уровня в этот процесс, обучение через действие, метод проб и ошибок. В результате создаются уникальные операционные практики, которые не могут быть легко декодированы и воспроизведены конкурентами. Данный подход противоречит более традиционному представлению об инновациях за счет внедрения ИС, предполагающему радикальную замену существующих компетенций новыми на основе предварительного анализа, проекта и плана. На обширном фактическом материале Сиборра и его последователи показали, что даже если проект внедрения ИС планируется в соответствии со вторым способом, реализуется он в соответствии с первым [3, 4].

На основании этих соображений автором данной статьи в работе [5] был предложен подход к стратегическому управлению развитием корпоративных информационных технологий (далее ИТ-стратегия) на основе сочетания перспективы (разделяемой точки зрения внутри организации на роль ИТ в ее деятельности) и паттерна (шаблона стратегического поведения). Перспектива определяет направления развития, их приоритеты и ограничения. Паттерн определяет повторяющиеся действия, которые выполняются при возникновении новой инициативы, связанной с изменением существующих или внедрением новых информационных систем и технологий. Составными компонентами паттерна стратегического поведения являются:

• •    метод принятия решений о реализации возникающих инициатив [6];

• •    метод измерения эффекта от их реализации [7];

• •    методы поддержания высокой степени адаптивности информационной системы организации [8]. В этой группе методов выделены распространение методов гибкой (agile) разработки на корпоративный уровень, использование единой корпоративной технологической информационной платформы, организация ИС в виде сервисов.

Согласно определению ISO/ГОСТ [9], ИС – это система обработки информации, работающая совместно с организационными ресурсами, такими как люди, технические средства и финансовые ресурсы, которые обеспечивают и распределяют информацию. Аналогичные идеи развиваются в работе [10], которая базируется на социотехнической теории. Согласно модели организационных изменений [11], созданной в рамках этой теории, любую социотехническую систему, в том числе и ИС, необходимо рассматривать как сочетание четырех взаимодействующих согласованных компонентов:

• •    структура (нормативный и поведенческий аспекты системы – коммуникации, управление и бизнес-процессы);

• •    акторы (разработчики и пользователи ИС, любые другие заинтересованные лица, которые могут на нее влиять);

• •    технологии (инструменты, используемые при решении задач);

• •    задачи (цели и способы, которыми они достигаются).

На ИС непрерывно воздействуют внешние события, связанные с изменением окружающей ее среды, которые нарушают согласованность компонентов системы. Под воздействием потока внешних событий система большую часть времени развивается эволюционно, при этом инкрементально изменяются ее компоненты. Длительные периоды эволюционного развития прерываются революционными изменениями, когда система радикально изменяет за короткий промежуток времени свою структуру и правила связывания компонентов. В целом поведение системы является хаотическим [10].

В рамках социотехнической теории ИТ-служба рассматривается как часть корпоративной информационной системы. Поэтому вопросы ее оптимальной организации, построения эффективных процессов сопровождения и развития имеют не меньшее значение, чем, скажем, определение целей информатизации, выбор технологий и т. д. В данной статье рассматривается модель ИТ-службы, ориентированная на предоставление сервисов поддержки различных функциональных сфер деятельности крупной организации.

1.    Сервисная модель предоставления ИТ-услуг

Сервисная модель предполагает концентрацию не на функциях ИС и не на поддержке биз-нес-процессов, а на предоставлении сервисов. Сервис можно трактовать как бизнес-процесс с подписанным соглашением об уровне сервиса, где указаны поставщик и потребитель, ключевые параметры оказания услуги, включая стоимость, время восстановления и т. д. Разница в подходах, ориентирующихся на процесс и на сервис, исследована в работе [12] (табл. 1). В целом такой подход следует социотехнической теории, которая в качестве реакции на непредсказуемость внешней среды рекомендует не повышать внутреннюю сложность организации, а уменьшать внутренний контроль и координацию (так называемая стратегия простой организации и сложных задач [13]). Следствием этого подхода является замена традиционной иерархии полуавтономны-ми группами, которые полностью отвечают за все операции в рамках определенного сервиса.

Таблица 1

Сравнение процессного и сервисного подходов

	Процесс	Сервис
Результат	Выходные параметры процесса	Ценность для потребителя
Потребитель	Внутри или вне организации поставщика	Вне организации поставщика
Измерение	Не обязательно	Требуется
Стоимость	Не обязательно	Требуется
Учет	Внутренний, метрики поставщика	Внешний, метрики потребителя

В соответствии со сказанным автором настоящей статьи, в [8] предложена модель оценки зрелости организации ИТ-сервисов на основе их сопоставления с уровнями архитектуры предприятия (табл. 2).

Таблица 2

Уровни зрелости ИТ-сервисов

Уровень зрелости	Описание	Потребители сервиса	Кто контролирует
0	Обеспечивается общее функционирование ИТ-инфраструктуры и информационных систем без формального соглашения об уровне сервиса (SLA)	Явно не определены	Руководитель ИТ-подразделения
1	Предоставляются инфраструктурные сервисы (сервисы технической архитектуры – электронная почта, управление файлами и печатью и т. д.)	Сотрудники организации	Руководитель ИТподразделения
2	Предоставляются сервисы поддержки биз-нес-приложений	Сотрудники организации	Владельцы приложений
3	Предоставляются сервисы поддержки биз-нес-процессов для пользователей организации	Сотрудники организации	Владельцы процессов
4	Сервисы поддержки бизнес-процессов предоставляются не только внутри, но и вне организации, включаются партнеры, поставщики и клиенты	Сотрудники организации, ее партнеров, поставщиков, клиентов	Владельцы процессов

Корпоративная информационная система как единое целое включает в себя все виды сервисов: инфраструктурные, поддержки бизнес-приложений и бизнес-процессов, между которыми формируются различные связи. Инфраструктурные сервисы (например, резервное копирование или электронная почта) могут обеспечивать выполнение некоторых функций бизнес-приложений и элементов бизнес-процессов. Точно так же в рамках одного бизнес-процесса могут использоваться различные бизнес-приложения.

2.    ИТ-стратегия как план повышения адаптивности ИТ-сервисов

Предложенный подход к выделению сервисов позволяет рассматривать стратегию развития ИТ как план повышения уровня адаптивности. На основании табл. 2 в корпоративной ИС могут быть выделены не только инфраструктурные сервисы, но и сервисы поддержки бизнес-приложе-ний и бизнес-процессов, для каждого из них может быть определен достигнутый и требуемый уровни зрелости. Это позволяет сформировать план действий по повышению зрелости ИС в целом, пример такого плана приведен на рис. 1.

План повышения зрелости позволяет сформировать институциональную основу стратегического управления развитием корпоративной ИС (рис. 2). Создание такого плана должно находиться в ведении органа, ответственного за координацию и планирование развития ИС. Если обеспечена независимость сервисов (т. е. отсутствуют функциональные требования, общие для двух и более сервисов), их развитие можно поручить различным группам, использующим методологию гибкой разработки (agile методы), которые обеспечивают быстрое изменение сервисов в соответствии с меняющимися требованиями. Отметим, однако, что методы гибкой разработки, безусловно, эффективны на фазе инкрементального развития сервисов. На фазе их революционного изменения (полная замена, создание новых), возможно, целесообразнее применять традиционные методы управления проектами, опирающиеся на предварительную спецификацию и график реализации. Два варианта процесса изменения системы будут рассмотрены в следующем разделе.

ИСуправления логистикой

Процессы сервиса

Сервисы поддержки бизнес-процессов Гпроцесс закупок

Хранение файлов

Рис. 1. Пример плана повышения адаптивности ИТ-сервисов

	0		1		2		3		4
Инфраструктурные сервисы

Электронная почта

Сервисы поддержки бизнес-приложений кого учета

Рис. 2. Процесс стратегического развития корпоративной ИС

Нали чи е е д и н ой к орп ор ативной информационной платформы обеспечи вает п ов торн ое и спользование объектов, созд ан ны х разными группами, а также их унифициров а н н ое п ре д с та в л е н и е в п ользов а те ль с к ом и н те рфейсе прикладных систем, облегчает интеграци ю д а н ных ра зли ч н ы х п рил ож е н и й , процес сов и би з н е с -областей.

Отме ти м, од н а ко, что м о д ель, п р е д с т а в ле н н а я н а ри с . 2, в н астоящий момент труднореали зу е ма на п ра к ти ке , ос о б ен н о в к рупных организациях. Это связано с тем, чт о с е го д н я н а р ын ке о т сутст в у ю т п рограм мн ы е п род укты, которые могут претендовать на роль к орп ор а ти в н ой и н ф орм аци он н ой пла т форм ы , обе с п е чи в а ющ е й п р остое с оздание сервисов, поддерживающих все в и д ы д е ят е льн ос ти мн ого п рофи л ьной организации. Поэтому, в ближайшей пе рс п е к ти в е п ре дло ж е н н а я моде ль п о д д ерж ан и я а д аптивности, скорее всего, будет реализовыватьс я в п од ра зд ел е ни ях, отв е чаю щ их за тот и ли и н ой отн ос и те льн о об особленный функциональный сегмент бизнеса.

3.    Процессы изменения ИС

С точк и зре н и я с оц и оте х н ической теории возможны два вида изменени й и н форма ц и он н о й системы – ин к ременталь н ые и р еволюционные [10]. Рассмотрим возможные в а ри а н т ы ре али з ации этих процессов, к от орые о существляются в рамках групп по развитию с оотв е тс тв у ю щ их сервисов.

Рис. 3. Процесс инкрементального изменения системы

На рис. 3 представлен процесс, обеспечивающий постоянное инкрементальное изменение системы в фазе ее эволюционного развития. Инициаторами изменений становятся пользователи системы. При обнаружении ошибки или при необходимости незначительного эволюционного изменения функциональности системы они формируют заявки на доработку, которые поступают в общую очередь. Все заявки должны периодически (например, еженедельно) рассматриваться, для каждой из них в зависимости от ее важности должен быть установлен приоритет и срок реа- лизации. Соглашение о приоритетах и сроках должно устанавливаться совместно представителями команды развития системы (специалисты ИТ) и ее пользователями. Поэтому на стороне заказчика желательно выделить одного ключевого пользователя (владельца приложения или владельца процесса), который может принять решение в случае спорной ситуации.

Очере д ь за д а н и й с у с та н ов ле н н ы ми приоритетами является входным буфером для команды п одд е р жк и и ра зв и ти я си с те м ы (отметим, что это аналог backlog в мето д е гиб к ой раз работк и s c r um) . С и с те мн ый а рхи т е к тор при необходимости связывается с автором за яв к и , у точн яе т в озн и к шую п роб л е му и форми ру ет задание разработчику в терминах системы на «языке ИТ». Обн ов л е н ие, с озда н н ое ра зр а б отч иком, тестируется архитектором и, в случае у с п е ха , п оме щ ае тс я в х ра н ил и щ е готов ы х объ е к тов . Периодически (например, каждую ночь) си с те ма об нов ляе тс я . Пользователь, сформ и ро в а в ш и й заявку, получает уведомление о ее реал иза ц и и . Ес ли он п одтв е рж д ае т, что его п отреб н ос ти удовлетворены, процесс прекращается, в п роти в н ом с лу ча е о н соз да е т д оп олн е н ие к р а не е отк р ытой за яв к е .

Эт о оче н ь общ а я моде л ь п роц е с с а и н к р е ме н та л ьн о го ул учшения системы. В зависимости от у с л ов ий к он к ре тн ой орган и за ц ии она может быть дополнена различными эл е ме н та ми . На п ри м е р , мож но п ре д у с мотре ть еже д невные короткие собрания всей команды разв и т и я для об ме н а инф орм аци ей о тек у щ и х за да ча х, к ак э то п ре д п и сыв ае т scrum. Кроме того, предложенная модель не о т да е т яв н ое п р е д п очте ни е те м или иным механизмам мотивации сотрудник ов , э ти в оп рос ы та кж е должны реш а ть с я п ри в н е д ре н и и п роц ес с а в конк ре тн ой ор га н и за ц и и.

Р ас с мотри м теперь п роц ес с з н а чи те л ьн ог о изме н е ни я и н форма ц ионной системы при помощи выпуска релизов (рис. 4).

Рис. 4. Процесс обновления системы за счет выпуска релизов

Данный процесс строится вокруг той же приоритезированной очереди заявок на изменение или устранение дефектов, которая является входом для процесса инкрементальных изменений. Может сложиться такая ситуация, когда некое множество заявок целесообразно реализовывать одним пакетом, например, потому, что их взаимное влияние очень велико и независимая разработка невозможна. Подобная ситуация может сложиться также при обновлении технологической платформы, на которой построена система, при значительном добавлении новой функциональности и т.п. В этом случае представитель заказчика (напомним, что это владелец приложения или владелец процесса) и руководитель группы развития системы могут принять решение о выпуске новой версии (или релиза) системы. Они определяют границы релиза, т.е. множество заявок, которые он будет закрывать, и сроки его реализации.

Системные архитекторы в этом случае рассматривают релиз целиком и декомпозируют его на отдельные задания для разработчиков. По мере завершения разработки производится тестирование интеграции и функциональности вновь создаваемых модулей. Для этого целесообразно развернуть специальную тестовую среду, повторяющую окружение промышленной системы. К такому тестированию могут быть привлечены и ключевые пользователи. Когда внутреннее тестирование релиза завершается, он переносится в промышленную систему, о чем уведомляются пользователи, заявки которых реализованы в данном обновлении. Они также должны подтвердить удовлетворение их требований.

Отметим, что подготовка нового релиза выполняется параллельно с процессом инкрементальных изменений, причем одновременно в разработке может находиться несколько релизов, которые будут выпускаться последовательно.

Заключение

Таким образом, в общем случае организация ИТ-службы, ориентированной на предоставление сервисов, может включать следующие структурные единицы:

• •    Группы развития сервисов, реализующие процессы изменений, представленные на рис. 3 и 4. Отметим, что подобные группы могут создаваться для развития любых видов сервисов (инфраструктурные, поддержка приложений, поддержка бизнес-процессов) или даже их комбинаций. Конкретный способ выделения таких групп должен определяться общим уровнем зрелости ИС-организации.

• •    Группу развития корпоративной информационной платформы (или несколько таких групп, если не удается ограничиться использованием только одной платформы). Изменение платформы ведется также в соответствии с процессами, представленными на рис. 3 и 4, но источниками запросов на изменение при этом являются не конечные пользователи, а группы, отвечающие за развитие сервисов.

• •    Комитет по стратегическому развитию ИС и ИТ в организации (см. рис 2). Данный комитет должен включать руководителей всех упомянутых выше групп, руководство ИТ-службы, представителей пользователей ИС (владельцев бизнес-приложений и бизнес-процессов). В задачи данного комитета входит разработка, обновление и контроль выполнения плана, представленного на рис. 1.

Отметим, что предложенная модель обеспечивает более высокий уровень гибкости ИТ-службы. В частности, в предлагаемой модели передача части функций по развитию сервисов на аутсорсинг будет производиться гораздо легче, чем в функциональной или матричной структурах.