Текст книги "Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности"
Автор книги: Юрий Зеленков
Жанр:
Деловая литература
сообщить о нарушении
Текущая страница: 5 (всего у книги 8 страниц)
Отметим, что введение нормирующего множителя
в формулу делает метрику универсальной и позволяет использовать ее как для общей оценки зрелости исследуемого бизнес-процесса (чем ближе его метрика к 0, тем более предсказуемы его исходы), так и даже для сравнения эффективности различных процессов. Для лучшего понимания введенной метрики рассмотрим таблицу 5.1, в строках которой приведено количество исходов с результатом μi для различных опытов.
Для равномерно распределенной величины значение введенной метрики равно 1 независимо от количества испытаний (опыты 1 и 2). Из опытов 2–9 очевидно, что с уменьшением количества возможных вариантов, которые может принимать величина n, значение предложенной метрики также уменьшается, что соответствует сокращению неопределенности, связанной с возможными результатами процесса. Также отметим, что предложенная метрика одинакова для смещенных результатов (см. опыты 5 и 10). Это означает, что данная метрика не оценивает «качество» процесса с точки зрения соответствия его результатов некому целевому значению (в отличие от метода «шесть сигма»), а только его неопределенность.
Третье и четвертое свойства энтропии позволяют обобщить предложенную метрику на случай, когда ИС поддерживает одновременно несколько независимых или зависимых бизнес-процессов.
Пример использования энтропийного метода
В качестве примера использования предложенной метрики рассмотрим измерение эффективности бизнес-процесса (и соответствующей ИС) оплаты поставщикам, реализованного на НПО «Сатурн». Как следует из рис. 5.4, данный бизнес-процесс является одним из группы асинхронных процессов планирования и осуществления финансовых операций, взаимодействующих через план движения денежных средств. Информационная система в момент исследования поддерживала только те действия, которые на рисунке закрашены серым цветом.
При создании заявки на оплату заинтересованная служба указывает желаемую дату платежа δ, поэтому в качестве характерного параметра процесса логично выбрать отклонение от этой даты µ= ε– δ, измеряемое в днях, где ε – фактическая дата выполнения платежа. Метрика H(t) по данному параметру µ вычислялась ежемесячно. Полученные результаты представлены кривой 1 на рис. 5.5 (T – момент запуска системы, T+i, i=00…18 – месяц с момента запуска системы). Как следует из графика, степень непредсказуемости процесса в результате внедрения информационной системы за 9 месяцев снизилась более чем в 1,5 раза.
Для более ясного понимания причины снижения непредсказуемости на рис. 5.6 показаны распределения параметра µ в месяцы T+05 и T+09. Из этого рисунка видно, что с течением времени разброс отклонений от целевого значения сокращался, все большее количество процессов выполнялось с заданным результатом (в данном случае в заданный срок).
Из рисунка 5.5. видно, что через 8 месяцев после начала эксплуатации системы произошла некая стабилизация бизнес-процесса, и в рамках установившегося процесса значение H(t) совершает колебания с периодом равным кварталу. Дальнейший анализ показал, что минимальное значение всегда достигается во второй месяц квартала. Это связано с отсутствием в данном месяце регулярных платежей (налоги и т.п.), нарушение сроков выполнения которых приводит к обязательным штрафам.
Таким образом, предложенная метрика позволяет не только убедиться в общей эффективности ИС, но и позволяет определить направление дальнейшего совершенствования операций. В рассмотренном конкретном случае это совершенствование процедур управления финансами за счет автоматизации процесса планирования и учета поступлений.
Определение количества процессов с одинаковым результатом
Очень часто на практике возникает задача организовать выполнение бизнес-процессов таким образом, чтобы определенная их доля заканчивалась с заданным результатом. Например, для надежного функционирования метода планирования производства MRP необходимо, чтобы не менее 95% производственных заказов выполнялась точно в заданный срок[90].
Для определения значения H(t), соответствующего заданной доле процессов m, выполняемых с одинаковым результатом, можно воспользоваться подходом, известным как «формализм Джейнса»[91]. Он гласит: если нам ничего не известно о величине μ, кроме того, что она лежит в некотором ограниченном диапазоне, то разумнее всего принять, что вероятности p(μi ) распределены таким образом, что они обеспечивают максимум энтропии, которая может рассматриваться как мера нашего незнания.
Опуская несложные математические преобразования для тех, кто всерьез заинтересовался, приведем формулы, связывающие значения H(t) и m:
Эти соотношения позволяют на основании значения H(t) определить долю бизнес-процессов, заканчивающихся с одинаковым результатом. Для этого достаточно вычислить H(t) при различных значениях m. В качестве примера на рис. 5.5 представлены кривые 2, 3, 4, соответствующие значениям m = 0,3; m = 0,5 и m = 0,7.
Из представленных результатов следует, что на момент внедрения ИС менее 30% процессов завершались с одним и тем же результатом. После внедрения системы количество этих процессов увеличилось до 70% во второй месяц квартала и 50% в первый и третий месяцы квартала.
Обсуждение
В заключение заметим, что энтропийный метод оценки эффективности ИТ-систем не требует формулировки бизнес-стратегии или системы показателей работы компании, а значит, может применяться в условиях высокой неопределенности. Кроме того, его использование не требует высокого уровня управления компании в целом, как метрики, основанные на системе показателей. Безусловно, у энтропийного метода оценки эффективности ИТ-систем есть и недостатки:
фактическое сокращение неопределенности процесса, как правило, достигается сочетанием различных мер, лишь одной из которых является внедрение ИТ-системы, однако корректно отделить вклад ИТ в общее повышение эффективности не удается;
отсутствие связи между показателем эффективности (снижения неопределенности) процесса и результатами работы компании в целом;
не подходит для прогнозирования будущего эффекта от внедрения ИТ-системы, измеряет только фактические показатели.
Этот метод позволяет измерить только «степень непредсказуемости» результатов исследуемого бизнес-процесса, не оценивая их соответствие неким целевым значениям. В то же время, как уже было отмечено, в большинстве случаев на ранних стадиях проектов по организационному совершенствованию (включая и проекты по внедрению ИС) определение таких целевых значений вызывает значительные затруднения. Поэтому наиболее разумно использовать предложенный метод на начальных этапах проектов по изменениям для оценки уровня стабильности процесса, а также для определения целевых значений его параметров, которые затем могут контролироваться при помощи методики «шесть сигма».
6. Адаптивность
Рожать ежика – это дело такое: чем раньше начнешь, тем больше шансов.
Олег Дивов. Консультант по дурацким вопросам.
В этой главе мы обсудим, пожалуй, самый важный компонент паттерна стратегического поведения – как обеспечивать высокий уровень адаптивности информационной системы (рис. 6.1).
Адаптивная организация
Существование в изменчивой внешней среде требует способности к адаптации и от самой организации. Адаптивность (agility) чаще всего определяется, как способность организации обнаруживать изменения во внешней среде и эффективно реагировать на эти изменения[92]. Отметим, что устоявшегося русскоязычного термина, соответствующего английскому «agility», еще нет. Здесь и далее используется термин «адаптивность», предложенный в[93], хотя в отечественной литературе также встречается термин «гибкость» который, скорее, является переводом «flexibility». В зарубежной литературе между этими понятиями проводится четкая граница[94]: flexibility – это плановый ответ на изменившуюся ситуацию, agility – изменение фундаментальных принципов организации для обеспечения возможности изменяться в любом направлении.
Идея адаптивной организации вытекает из исследования роли случайности и непредвиденных обстоятельств в организационной теории. Результаты этих исследований[95] показали, что не существует единого универсального способа управления компанией, сам стиль этого управления зависит от ситуационных ограничений среды, в которой осуществляется деятельность. Таким образом, для поддержания эффективности организация должна все время адаптироваться к непредсказуемым изменениям.
Тема создания адаптивных организаций стала особенно популярной в последние годы, в настоящее время идет накопление идей и формирование общих подходов. Достаточно общий обзор литературы по этому вопросу представлен в статье[96]. Значительное внимание при этом уделяется поиску инвариантных элементов организации, которые позволяли бы быстро и эффективно строить новые операционные и бизнес-модели, осуществлять другие инновационные действия, формируя при этом неизменное ядро компании. В качестве таких постоянных компонент выделяются экстернализированные метамодели знаний, паттерны ведения бизнеса и люди, как носители знаний[97]. Действия по поддержанию адаптивности бизнеса должны быть проактивными[98], т.е. особую важность приобретают способность предсказывать изменения и повторно использовать существующие компоненты инфраструктуры. На практике очень часто существует противоречие между фактически взаимоисключающими требованиями – обеспечивать адаптивность с одной стороны и выполнять принятые планы с другой[99]. Поэтому необходимость следовать намеченным планам является дополнительным ограничением при обеспечении адаптивности.
Следует отметить, что на сегодняшний день значительный прогресс достигнут в исследованиях адаптивности производственных систем, рассматриваемой как способность регулировать без значительных затрат объемы производства и состав выпускаемой номенклатуры продуктов в соответствии с изменением спроса[100]. Наиболее общая модель адаптивной производственной системы предложена Х. Шарифи и Д. Джангом[101], где выделено четыре важнейших аспекта:
драйверы адаптивности (турбулентность и непредсказуемость внешней среды, в том числе изменения требований потребителей, политических и социальных факторов, технологические инновации, действия конкурентов и регуляторов рынка);
стратегия обеспечения адаптивности;
способности, которыми должна обладать адаптивная организация (быстрота реакции на изменения, гибкость, компетентность);
средства обеспечения адаптивности (организация, технологии, люди, инновации) и их реализация в виде практик, методов и инструментов.
Значительные достижения имеются также в области адаптивных (гибких) методов разработки программного обеспечения[102]. Адаптивность информационных систем обсуждается в книге под редакцией К. Десоузы[103], где, в частности, рассмотрены вопросы влияния новых информационных (прежде всего, коммуникационных) технологий – виртуальные офисы, видеоконференции, мобильные технологии, системы на базе агентов.
Адаптивная информационная система
Внедрение новых ИС, направленное на совершенствование операционных процессов, не должно препятствовать дальнейшему изменению этих процессов. Однако, на практике, с развитием системы повышается ее функциональность, сложность, ценность для бизнеса и снижается адаптивность (см. рис. 6.2). Поэтому очень важно иметь такие ИС, которые позволяют очень легко изменять процессы компании. В идеальном случае это должно происходить за счет переконфигурирования ИС, или, в крайнем случае, при помощи частичной замены некоторых старых модулей на новые. Необходимо избегать ситуации, когда потребуется полная замена ИС из-за ее несовместимости с новыми принципами работы, поскольку это ведет к значительным затратам. Таким образом, надо обеспечивать управляемую эволюцию системы, которая должна комбинировать непрерывное увеличение ее ценности для бизнеса с непрерывным увеличением адаптивности. Этому соответствует движение на рис. 6.2 из точки А в точку B, все модификации при этом должны происходить в рамках определенных границ.
Для решения этой задачи необходимо построить модель адаптивной информационной системы, понять, какие механизмы могут помочь поддерживать высокую адаптивность ИС, разработать метод измерения адаптивности.
До сих пор мы обсуждали вопрос, почему изменяются информационные системы. Ответ очевиден – потому что изменяются внешние условия, а следовательно, и требования, которым должна отвечать ИС. Теперь стоит остановиться на том, как происходят эти изменения. Профессор Лондонской школы экономики Клаудио Чиборра описал подход к развитию ИС[104], названный им bricolage[105] или импровизация – постепенное улучшение уже существующих систем, вовлечение работников операционного уровня в этот процесс, обучение через действие, метод проб и ошибок. В результате создаются уникальные операционные практики, которые не могут быть легко декодированы и воспроизведены конкурентами. Не правда ли, очень похоже на пресловутую «лоскутную автоматизацию»? Данный подход противоречит более традиционному представлению об инновациях, предполагающему радикальную замену существующих компетенций новыми на основе предварительного анализа, проекта и плана. На обширном фактическом материале Чиборра и его последователи показали, что даже, если проект внедрения ИС (например, ERP) планируется в соответствии со вторым способом, реализуется он всегда в соответствии с первым[106]. Т.е. «лоскутная автоматизация» это норма, а не отклонение от «лучших практик».
Этот вывод базируется на социотехнической теории, которая предписывает рассматривать взаимодействие двух аспектов организации – социального и технического. Поэтому невозможно оптимизировать только один аспект, социальный или технический. Известный французский социолог Бруно Латур предложил теорию[107], которая описывает создание альянсов различных действующих лиц (акторов), преследующих общие цели или решающих общую проблему. При этом действующими лицами являются не только люди или их объединения, но и технологии.
Действительно, при формировании в организации альянса, направленного, например, на повышение операционной эффективности, ИТ всегда будут его членом. Во-первых, существующая система может ограничивать «большой скачок» в светлое будущее, поскольку нужны будут значительные усилия и затраты на трансформацию ее в соответствии с новыми идеями. Во-вторых, технология, пусть неодушевленная и не имеющая собственных целей, но действующая через людей как через агентов, сама может стать инициатором изменений. За примерами далеко ходить не надо – ERP, облака, планшеты и т.д. Поэтому технологию надо признавать полноправным членом альянса, учитывать ее интересы или, выражаясь не так радикально, ограничения и возможности. Как заметил редактор журнала «Wired» Кевин Келли, «как мы изменяем технологии, так и они изменяют нас»[108].
Модель адаптивной информационной системы
Начнем с рассмотрения способов поддержания адаптивности ИС. Характеристики любой системы можно разбить на структурные и операционные[109]. Структурные свойства определяются архитектурой системы и используемыми технологиями, они закладываются на стадии проектирования, не зависят от внешних условий и их крайне сложно изменить. Примером таких свойств являются число и объем цилиндров для автомобильного двигателя. Операционные характеристики (например, скорость автомобиля и расход топлива) зависят не только от внутренних параметров, но и от внешних условий, они могут быть изменены за короткое время.
Для того чтобы исследовать структурные параметры ИС, необходимо рассмотреть процесс ее изменения. Воспользуемся моделью изменений ИС, предложенной Калле Лиитененом и Майклом Ньюманом[110], которая базируется на социотехнической теории. Согласно модели организационных изменений[111], созданной в рамках этой теории, любую социотехническую систему, в том числе и ИС, необходимо рассматривать как сочетание четырех взаимодействующих согласованных компонентов:
структура (нормативный и поведенческий аспекты системы – коммуникации, управление и бизнес-процессы),
акторы (члены организации и любые заинтересованные лица, которые могут на нее влиять),
технологии (инструменты, используемые при решении задач),
задачи (цели и способы, которыми они достигаются).
Следует отметить, что границы между компонентами размыты, но все они связаны друг с другом. Их взаимодействие складывается как из линейных связей типа «причина – следствие» (причем эти связи, как правило, проектируются заранее), так и из нелинейных, спонтанно возникающих, часто непредсказуемых отношений. Поэтому невозможно оптимизировать только один аспект системы – социальный или технический. На ИС непрерывно воздействуют внешние события, связанные с изменением окружающей среды (под окружающей средой понимаются как другие системы организации, так и внешние по отношению к организации системы), которые нарушают согласованность компонентов системы. К числу таких событий могут относиться появление новых технологий, оптимизация бизнес-процессов, изменение состава или количества пользователей и даже изменение команды разработчиков, например, приход на работу нового аналитика или архитектора и т.д. События вызывают рассогласование между компонентами системы (см. таблицу 6.1). При наличии такого рассогласования система предпринимает действия по его устранению. Отметим, что не все действия ведут к успеху, в общем случае возможны четыре исхода:
разрыв устраняется инкрементальными изменениями компонент;
разрыв не устраняется;
разрыв устраняется революционной трансформацией ИС в новую систему;
попытки устранения рассогласования между двумя компонентами приводят к его распространению на другие компоненты.
Таким образом, согласно модели Лиитинена и Ньюмана под воздействием потока внешних событий система большую часть времени развивается эволюционно, при этом инкрементально изменяются ее компоненты. Длительные периоды эволюционного развития прерываются революционными изменениями, когда система радикально изменяет за короткий промежуток времени свою структуру и правила связывания компонентов. В целом поведение системы является хаотическим. Основываясь на этой модели, мы можем уточнить определение адаптивной системы:
Адаптивная система должна компенсировать максимально возможное количество рассогласований между компонентами, вызываемых внешними событиями, путем инкрементальных изменений.
Это должно обеспечиваться ее структурными свойствами, которые определяются на стадии проектирования. Варианты такого дизайна будут рассмотрены в следующем разделе.
Стратегия обеспечения адаптивности должна быть частью общей ИТ-стратегии, независимо от того, в каком виде последняя институционализирована в организации – как план или как принцип поведения.
Операционные параметры адаптивной организации исследовал Р. Дав[112], к их числу относятся: время и затраты на проведение изменений, объем изменений, устойчивость процесса проведения изменений.
Таким образом, опираясь на результаты Шарифи и Джанга, Лиитинена и Ньюмена и Дава можно предложить модель адаптивной информационной системы, представленную на рис. 6.3.
Обеспечение адаптивности ИС
Общие закономерности создания систем различного рода выделены в методологии аксиоматического проектирования, разработанной профессором Массачусетского технологического института Су Нам-пио[113]. Этот подход выделяет несколько независимых доменов (домен потребителей, а также функциональный, физический и процессный домены, см. рис. 6.4), каждый из которых характеризуется вектором определенных параметров (соответственно атрибуты потребителя, функциональные требования, параметры проектирования и переменные процессов). Во время проектирования производится отображение параметров одного домена на параметры другого. Если связи между параметрами верхнего уровня недостаточно детализированы, проектировщик вынужден их декомпозировать, возвращаясь к предыдущему домену и обратно, используя движение зигзагом (рис. 6.5).
Аксиоматическое проектирование построено на двух аксиомах. Первая (аксиома независимости) требует поддерживать независимость функциональных требований. Собственно, проектирование продукта (системы) это отображение вектора функциональных требований [FR] на вектор параметров проектирования [DP]. В случае ИС проектными решениями могут быть декомпозиция ее на сервисы, программные модули, объекты и т.п. Обсуждаемое отображение может быть представлено в виде произведения [FR]=[A][DP], где [A] – матрица проектирования. Вид этой матрицы определяет качество проектирования. В идеальном случае она должна быть диагональной, т.е. каждому функциональному требованию должно соответствовать только одно проектное решение. В случае треугольной матрицы [A] каждое функциональное требование влияет на несколько проектных решений, но обратного влияния нет. Эти два случая удовлетворяют аксиоме независимости. Во всех прочих случаях одно проектное решение может быть реализацией нескольких функциональных требований, что приводит к взаимному влиянию функциональных требований друг на друга.
Аналогичные рассуждения можно повторить и для разработки технологий изготовления продукта, во время которой вектор параметров проектирования [DP] отображается на вектор параметров процессного домена [PV], но при обсуждении ИС это отображение обычно не рассматривается.
Вторая аксиома (информационная) требует минимизировать объем информации в процессе проектирования или, не вдаваясь в детали, увеличить вероятность удовлетворения функциональных требований. Информация в данном случае определяется как Ii=-log2 pi , где pi – вероятность удовлетворения функционального требования FRi. Когда необходимо удовлетворить n требований, лучшим проектом будет тот, который соответствует минимальному объему информации
Рассмотрение принципов проектирования адаптивных систем необходимо начать с обсуждения возможности распространить методы гибкой разработки ПО (XP, Scrum, RUP и др.) на создание и развитие корпоративной ИС системы в целом, поскольку эти методы достигли уже значительной степени зрелости. Однако при этом возникает ряд ограничений, связанных с масштабом проектов. Фактически, команды разработчиков, следующие гибким методам, используют свою способность чрезвычайно быстро создавать программный код для выяснения и уточнения требований пользователей. Отсюда вытекают особенности организации процесса разработки – небольшие команды, сосредоточенные в одном месте, интеграция заказчика в такую команду, отказ от утвержденных спецификаций до начала разработки и т.д. Все это позволяет разрабатывать относительно небольшие слабо интегрированные в корпоративную ИС приложения. Задача распространения гибких методов на корпоративную ИС исследована Д. Леффингвеллом[114], где отмечается, что в таком случае возникают вопросы координации отдельных распределенных команд, согласования релизов, предварительной разработки общей архитектуры системы и т.п. Решение всех этих вопросов в рамках исключительно модели гибкой разработки невозможно, появляется потребность в создании единого координирующего и планирующего органа. Вторым обязательным условием реализации гибких методов на корпоративном уровне является соблюдение требований первой аксиомы аксиоматического дизайна, только это позволит обеспечить относительную автономность команд разработчиков, отвечающих за реализацию различных функциональных требований. В противном случае решения групп будут влиять друг на друга, что радикально усложнит их взаимодействие.
Другой способ поддержания адаптивности ИС обеспечивается технологией – это концепция платформы, на базе которой создается семейство продуктов, причем и платформа, и продукты должны управляемо эволюционировать[115]. Процессы разработки и поддержки платформы и приложений на ее базе должны быть разделены. Под платформой здесь понимается не программная среда типа Java или .Net, а некий набор слабо связанных бизнес-объектов и средств интеграции и автоматизации бизнес-процессов, которые могут быть достаточно просто переконфигурированы в зависимости от текущих задач предприятия. Существующие индустриальные тренды (SOA, BPM, model business management – MBM, бизнес-правила, отделение реализации от интерфейса и т.д.)[116], кажется, позволяют создавать системы, которые могли бы в дальнейшем легко реконфигурироваться.
Такой платформой может стать и ERP система. Но при этом надо оценивать степень простоты и быстроты внесения изменений в текущую конфигурацию. Большинство предлагаемых сейчас на рынке ERP систем данному требованию не удовлетворяют. Эти системы имеют значительное количество перекрестных связей между модулями, внесение даже незначительных изменений связано с большими трудностями. Можно утверждать, что их дизайн не соответствует аксиоме независимости. Фактически эти системы жестко фиксируют существующую на момент их внедрения бизнес-практику, поэтому их изменение обходится слишком дорого.
Отметим также, что платформенный подход к созданию семейства продуктов получил широкое распространение не только в ИТ, но и, например, в машиностроении.
Третий способ обеспечения адаптивности, более социотехнический, это концентрация не на функциях ИС и даже не на поддержке бизнес-процессов, а на предоставлении сервисов. Сервис можно трактовать как бизнес-процесс с подписанным соглашением об уровне сервиса (SLA), где указаны поставщик и потребитель, ключевые параметры оказания услуги, включая стоимость, время восстановления и т.д. Разница в подходах, ориентирующихся на процесс и на сервис, исследована М. Урамом и Б. Стефенсоном[117] (см. таблицу 6.2).
В этом случае ИС становится лишь одним из инструментов, обеспечивающих сервис. В данном случае речь идет о дизайне в соответствии с аксиомой независимости не только технического компонента ИС, но и ее социальной части – людей и организационных структур. В целом такой подход следует социотехнической теории, которая в качестве реакции на непредсказуемость внешней среды рекомендует не повышать внутреннюю сложность организации, а уменьшать внутренний контроль и координацию (так называемая стратегия простой организации и сложных задач[118]). Следствием этого подхода является замена традиционной иерархии полуавтономными группами, которые полностью отвечают за все операции в рамках определенного сервиса.
В соответствии со сказанным можно предложить модель оценки зрелости организации ИТ – сервисов на основе их сопоставления с уровнями архитектуры предприятия (таблица 6.3).
Корпоративная информационная система как единое целое включает в себя все виды сервисов: инфраструктурные, поддержки бизнес-приложений и бизнес-процессов, между которыми формируются различные связи. Инфраструктурные сервисы (например, резервное копирование или электронная почта) могут обеспечивать выполнение некоторых функций бизнес-приложений и элементов бизнес-процессов. Точно так же в рамках одного бизнес-процесса могут использоваться различные бизнес-приложения.
Предложенный подход к выделению сервисов позволяет уточнить стратегическую модель повышения уровня адаптивности инфраструктурных сервисов, предложенную компанией Microsoft[119] и представленную на рисунке 2.4. На основании таблицы 6.3 в корпоративной ИС могут быть выделены не только инфраструктурные сервисы, но и сервисы поддержки бизнес-приложений и бизнес-процессов, для каждого из них может быть определен достигнутый и требуемый уровни зрелости. Это позволяет сформировать план действий по повышению зрелости ИС, пример такого плана приведен на рисунке 6.6.
Если выделенные сервисы удовлетворяют аксиоме независимости, полученный план позволяет сформировать институциональную основу стратегического управления адаптивностью корпоративной ИС (рисунок 6.7). Создание такого плана должно находиться в ведении органа, ответственного за координацию и планирование развития ИС. Независимость сервисов позволяет поручить их развитие различным группам, использующим методологию гибкой разработки (agile методы), которые обеспечивают быстрое изменение сервисов в соответствии с меняющимися требованиями. Отметим, однако, что методы гибкой разработки, безусловно, эффективны на фазе инкрементального развития сервисов. На фазе их революционного изменения (полная замена, создание новых), возможно, целесообразнее применять традиционные методы управления проектами, опирающиеся на предварительную спецификацию и график реализации. Два варианта процесса изменения системы будут рассмотрены в следующем разделе.
Наличие единой технологической платформы обеспечивает повторное использование объектов, созданных разными группами, а также их унифицированное представление в пользовательском интерфейсе прикладных систем, облегчает интеграцию данных различных приложений, процессов и бизнес-областей.
Отметим, однако, что модель, представленная на рисунке 6.7, в настоящий момент трудно реализуема на практике, особенно в крупных организациях. Это связано с тем, что сегодня на рынке отсутствуют программные продукты, которые могут претендовать на роль технологической информационной платформы, обеспечивающей простое создание сервисов, поддерживающих все виды деятельности многопрофильной корпорации. Поэтому в ближайшей перспективе предложенная модель поддержания адаптивности, скорее всего, будет реализовываться в подразделениях, отвечающих за тот или иной относительно обособленный функциональный сегмент бизнеса.
Процессы изменения
Как мы установили, с точки зрения социотехнической теории возможны два вида изменений информационной системы[120] – инкрементальные и революционные. Теперь мы рассмотрим возможные варианты реализации этих процессов. Предлагаемые модели не разработаны лично автором, они являются результатом весьма жарких, но очень продуктивных дискуссий, в которых принимали участие его коллеги по ИТ-дирекции НПО «Сатурн», а также обсуждений на конференциях с представителями других организаций. Более того, подобные процессы уже реализованы на некоторых предприятиях.
На рис. 6.8 представлен процесс, обеспечивающий постоянное инкрементальное изменение системы на фазе ее эволюционного развития. Инициаторами изменений становятся пользователи системы. При обнаружении ошибки или при необходимости незначительного эволюционного изменения функциональности системы они формируют заявки на доработку, которые поступают в общую очередь. Все заявки должны периодически (например, еженедельно) рассматриваться, для каждой из них в зависимости от ее важности должен быть установлен приоритет и срок реализации. Соглашение о приоритетах и сроках должно устанавливаться совместно представителями команды развития системы (специалисты ИТ) и ее пользователями. Поэтому на стороне заказчика желательно выделить одного ключевого пользователя (владельца приложения или владельца процесса), который может принять решение в случае спорной ситуации.
