Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности
Шрифт:
В этом случае ИС становится лишь одним из инструментов, обеспечивающих сервис. В данном случае речь идет о дизайне в соответствии с аксиомой независимости не только технического компонента ИС, но и ее социальной части – людей и организационных структур. В целом такой подход следует социотехнической теории, которая в качестве реакции на непредсказуемость внешней среды рекомендует не повышать внутреннюю сложность организации, а уменьшать внутренний контроль и координацию (так
В соответствии со сказанным можно предложить модель оценки зрелости организации ИТ – сервисов на основе их сопоставления с уровнями архитектуры предприятия (таблица 6.3).
Корпоративная информационная система как единое целое включает в себя все виды сервисов: инфраструктурные, поддержки бизнес-приложений и бизнес-процессов, между которыми формируются различные связи. Инфраструктурные сервисы (например, резервное копирование или электронная почта) могут обеспечивать выполнение некоторых функций бизнес-приложений и элементов бизнес-процессов. Точно так же в рамках одного бизнес-процесса могут использоваться различные бизнес-приложения.
Предложенный подход к выделению сервисов позволяет уточнить стратегическую модель повышения уровня адаптивности инфраструктурных сервисов, предложенную компанией Microsoft[119] и представленную на рисунке 2.4. На основании таблицы 6.3 в корпоративной ИС могут быть выделены не только инфраструктурные сервисы, но и сервисы поддержки бизнес-приложений и бизнес-процессов, для каждого из них может быть определен достигнутый и требуемый уровни зрелости. Это позволяет сформировать план действий по повышению зрелости ИС, пример такого плана приведен на рисунке 6.6.
Если выделенные сервисы удовлетворяют аксиоме независимости, полученный план позволяет сформировать институциональную основу стратегического управления адаптивностью корпоративной ИС (рисунок 6.7). Создание такого плана должно находиться в ведении органа, ответственного за координацию и планирование развития ИС. Независимость сервисов позволяет поручить их развитие различным группам, использующим методологию гибкой разработки (agile методы), которые обеспечивают быстрое изменение сервисов в соответствии с меняющимися требованиями. Отметим, однако, что методы гибкой разработки, безусловно, эффективны на фазе инкрементального развития сервисов. На фазе их революционного изменения (полная замена, создание новых), возможно, целесообразнее применять традиционные методы управления проектами, опирающиеся на предварительную спецификацию и график реализации. Два варианта процесса изменения системы будут рассмотрены в следующем разделе.
Наличие единой технологической платформы обеспечивает повторное использование объектов, созданных разными группами, а также их унифицированное представление в пользовательском интерфейсе прикладных систем, облегчает интеграцию данных различных приложений, процессов и бизнес-областей.
Отметим, однако, что модель, представленная на рисунке 6.7, в настоящий момент трудно реализуема на практике, особенно в крупных организациях. Это связано с тем, что сегодня на рынке отсутствуют программные продукты, которые могут претендовать на роль технологической информационной платформы, обеспечивающей простое создание сервисов, поддерживающих все виды деятельности многопрофильной корпорации. Поэтому в ближайшей перспективе предложенная модель поддержания адаптивности, скорее всего, будет
Процессы изменения
Как мы установили, с точки зрения социотехнической теории возможны два вида изменений информационной системы[120] – инкрементальные и революционные. Теперь мы рассмотрим возможные варианты реализации этих процессов. Предлагаемые модели не разработаны лично автором, они являются результатом весьма жарких, но очень продуктивных дискуссий, в которых принимали участие его коллеги по ИТ-дирекции НПО «Сатурн», а также обсуждений на конференциях с представителями других организаций. Более того, подобные процессы уже реализованы на некоторых предприятиях.
На рис. 6.8 представлен процесс, обеспечивающий постоянное инкрементальное изменение системы на фазе ее эволюционного развития. Инициаторами изменений становятся пользователи системы. При обнаружении ошибки или при необходимости незначительного эволюционного изменения функциональности системы они формируют заявки на доработку, которые поступают в общую очередь. Все заявки должны периодически (например, еженедельно) рассматриваться, для каждой из них в зависимости от ее важности должен быть установлен приоритет и срок реализации. Соглашение о приоритетах и сроках должно устанавливаться совместно представителями команды развития системы (специалисты ИТ) и ее пользователями. Поэтому на стороне заказчика желательно выделить одного ключевого пользователя (владельца приложения или владельца процесса), который может принять решение в случае спорной ситуации.
Очередь заданий с установленными приоритетами является входным буфером для команды поддержки и развития системы (отметим, что это аналог backlog в методе гибкой разработки scrum). Системный архитектор при необходимости связывается с автором заявки, уточняет возникшую проблему и формирует задание разработчику в терминах системы на «языке ИТ». Обновление, созданное разработчиком, тестируется архитектором и в случае успеха помещается в хранилище готовых объектов. Периодически (например, каждую ночь) система обновляется. Пользователь, сформировавший заявку, получает уведомление о ее реализации. Если он подтверждает, что его потребности удовлетворены, процесс прекращается, в противном случае он создает дополнение к ранее открытой заявке.
Это очень общая модель процесса инкрементального улучшения системы. В зависимости от условий конкретной организации она может быть дополнена различными элементами. Например, можно предусмотреть ежедневные короткие собрания всей команды развития для обмена информацией кто что делает, как это предписывает scrum. Также предложенная модель не отдает явное предпочтение тем или иным механизмам мотивации сотрудников, эти вопросы также должны решаться при внедрении процесса в конкретной организации.
Рассмотрим теперь процесс значительного изменения информационной системы при помощи выпуска релизов (рис. 6.9).
Данный процесс также строится вокруг приоретизированной очереди заявок на изменение или устранение дефектов, которая является входом для процесса инкрементальных изменений. Может сложиться такая ситуация, когда некое множество заявок целесообразно реализовывать одним пакетом, например, потому, что их взаимное влияние очень велико и независимая разработка невозможна. Подобная ситуация может сложиться также при обновлении технологической платформы, на которой построена система, при значительном добавлении новой функциональности и т.п. В этом случае представитель заказчика (напомним, что это владелец приложения или владелец процесса) и руководитель группы развития системы могут принять решение о выпуске новой версии (или релиза) системы. Они определяют границы релиза, т.е. множество заявок, которые он будет закрывать, и сроки его реализации. Отметим, что при планировании релиза крайне желательно оценить его потенциальный эффект и сложность реализации в соответствии с методом, предложенным в Главе 4.