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

Третий способ обеспечения адаптивности, более социотехнический, это концентрация не на функциях ИС и даже не на поддержке бизнес-процессов, а на предоставлении сервисов. Сервис можно трактовать как бизнес-процесс с подписанным соглашением об уровне сервиса (SLA), где указаны поставщик и потребитель, ключевые параметры оказания услуги, включая стоимость, время восстановления и т.д. Разница в подходах, ориентирующихся на процесс и на сервис, исследована М. Урамом и Б. Стефенсоном[117] (см. таблицу 6.2).

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

В соответствии со сказанным можно предложить модель оценки зрелости организации ИТ – сервисов на основе их сопоставления с  уровнями архитектуры предприятия (таблица 6.3).

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

Предложенный подход к выделению сервисов позволяет уточнить стратегическую модель повышения уровня адаптивности инфраструктурных сервисов, предложенную компанией Microsoft[119] и представленную на рисунке 2.4. На основании таблицы 6.3 в корпоративной ИС могут быть выделены не только инфраструктурные сервисы, но и сервисы поддержки бизнес-приложений и бизнес-процессов, для каждого из них может быть определен достигнутый и требуемый уровни зрелости. Это позволяет сформировать план действий по повышению зрелости ИС, пример такого плана приведен на рисунке 6.6.

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

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

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

Процессы изменения

Как мы установили, с точки зрения социотехнической теории возможны два вида изменений информационной системы[120] – инкрементальные и революционные. Теперь мы рассмотрим возможные варианты реализации этих процессов. Предлагаемые модели не разработаны лично автором, они являются результатом весьма жарких, но очень продуктивных дискуссий, в которых принимали участие его коллеги по ИТ-дирекции НПО «Сатурн», а также обсуждений на конференциях с представителями других организаций. Более того, подобные процессы уже реализованы на некоторых предприятиях.

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

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

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

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