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

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

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