Просмотр исходного текста страницы Проводники в джунглях системной сложности. Автоматизация ключевых бизнес-процессов крупных предприятий

;[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]]: Генеральный директор CustIS (Заказные ИнформСистемы)

''Журнал Intelligent Enterprise (Корпоративные системы), № 18, 24 ноября 2008, стр. 48-51.'' [http://www.iemag.ru/analitics/detail.php?ID=18270&phrase_id=37452  http://www.iemag.ru/analitics/detail.php?ID=18270&phrase_id=37452]''

<blockquote> Ключевые бизнес-процессы крупных организаций — это непрерывно развивающаяся система, и её развитие порождает массу проблем, когда речь идёт об автоматизации. Решать эти проблемы призваны не столько ИТ-инструменты, сколько люди.
</blockquote>

Все гуру предпринимательства и менеджмента говорят: «Ищите отличия, усиливайте отличия, специализируйтесь, меняйтесь, развивайтесь», — а после внедрения от ИТ директоров мы слышим: «Ничего не трогайте и не меняйте, только тогда всё будет работать». Один мой знакомый управляющий в сердцах так описал чудовищный функциональный разрыв, который возникает в таких проектах: «Они (вендоры) берут свое маленькое квадратное ведро и одевают на нашу большую круглую голову!».

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

=== Системная сложность ===

Крупные организации — это организации, которым повезло: благодаря интуиции и везению их основателей, благодаря многолетней работе их менеджмента на перспективу, они добились лидирующего положения.

Но для сохранения своего преимущества организация должна постоянно обеспечивать следующее.

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

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

Это очень легко сказать, но очень трудно сделать. Основная причина в том, что большая организация является сложной открытой системой. И как любая сложная система, обладает собственной скрытой логикой развития. Управленческие воздействия на такие объекты далеко не всегда приводят к ожидаемым результатам. На моей памяти множество историй, когда попытки что-то улучшить приводили к кризису в организации, для разрешения которого приходилось вводить антикризисное управление в лице лучших из лучших специалистов. И дело вовсе не в том, что кто-то «плохо поразмыслил», запуская изменения в компании, а в том, что точный расчет поведения сложных систем до сих пор неподвластен человеческому интеллекту. ''«Если хочешь рассмешить Бога — расскажи ему о своих планах».''

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

=== Функциональный разрыв ===

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

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

Итак, мы стоим у начала проекта, который можно схематично представить следующим образом (Рис.1).


[[Image:ИТ-проект в многомерном пространстве требований.png|orig|framed|Рис.1. ИТ-проект в многомерном пространстве требований]]

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

Тут мы сталкиваемся с функциональным разрывом — разницей между «Целевым» функционалом, который нужен бизнесу, и функционалом «Прототипа», который реализован в модуле (разрыв иллюстрируется расстоянием между точками).

Отмечу три важных факта. Во-первых, функционал «Цели» размыт — это лишь текущее представление о проектируемом бизнес-процессе, и оно не может быть точным (на схеме точка «Цель» размыта). Во-вторых, функционал «Цели» меняется во времени за счет внешних воздействий. В-третьих, по мере погружения проектируемого бизнес-процесса в жизнь, нас ждут непредсказуемые заранее реакции предприятия на попытки его изменить. Как я уже говорил ранее, это объективная вещь, связанная с системной сложностью предприятия: невозможно точно предсказать, как поведет себя система при воздействии на ее части. В результате представление о функционале «Цели» будет существенно изменяться во времени (на рисунке это обозначено черной стрелкой).

Далее начинается длительный итеративный процесс ликвидации функционального разрыва. Это достаточно непросто даже в том случае, если «Цель» зафиксирована. И это очень сложный процесс, если понимание «Цели» изменяется во времени.

[[Image:Эволюция функционала при результативном и слабом внедрении.png|orig|framed|Рис.2. Эволюция функционала при результативном и слабом внедрении]]

В случае результативного внедрения функциональный разрыв сокращается до минимума (на рис.1 и 2 — «результативное внедрение»). Более того, возникает положительная обратная связь. Чем ближе функционал «Прототипа» к реальным бизнес-процессам, тем активнее эти бизнес-процессы развиваются. Что позволяет предприятию усиливать свою позицию быстрее конкурентов. Подробнее с результативным внедрением разберемся в следующем разделе.

В остальных случаях функциональный разрыв остается значительным и перекладывается на плечи бизнес-подразделений (на рис.1 и 2 — «слабое внедрение»). В лучшем случае это приведет к появлению «наколеночной» автоматизации внутри подразделений, которая будет этот разрыв сокращать: Excel, Access и похожие инструменты в умелых руках инициативных бизнес-пользователей. В худшем случае организация надолго утратит возможность изменения ключевого бизнес-процесса, что является серьезной угрозой для существования всей организации в целом. ''«Хорошо тому живется, у кого одна нога: и портяночка не рвется, и не надо сапога!».''

=== Результативное внедрение ===

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

* Куплены лицензии. На самом деле, это формальное внедрение.
* Модуль функционирует на тестовом стенде. Это еще один случай формального внедрения.
* Модуль числится в промышленной эксплуатации, но реально используется «старый» модуль. Я встречал забавные случаи, когда новая система «подымается» только на время приезда инспекции из материнской компании. И это формальное внедрение.
* Часть модуля находится в промышленной эксплуатации, однако «старый» модуль по-прежнему развивается для поддержания необходимой бизнесу функциональности, именно посредством «старого» модуля происходит уменьшение функционального разрыва. Это пример слабого внедрения.

Ну и так далее, со всеми остановками.

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

* модуль находится в промышленной эксплуатации — количество усилий, которые тратятся на исправление ошибок, многократно меньше количества усилий, которые тратятся на развитие;
* большая часть старых модулей (подсистем), которые реализовывали схожую функциональность до внедрения нового модуля, выведены из эксплуатации;
* подавляющий объем новых требований бизнеса реализуется вовремя путем развития функциональности нового модуля (вокруг нового модуля не образуется слой «наколеночных» решений), то есть не возникает существенного функционального разрыва.

ИТ-директорам, которым удается поддержать именно такой сценарий развития информационной системы предприятия, предлагаю, безо всякой иронии, ставить памятник при жизни. И этот памятник должен символизировать бессмертное изречение: «Надо очень быстро бежать вперед, чтобы оставаться на месте». А для того, чтобы чего-то достичь, нужно бежать ещё быстрей…

=== Прогрессоры ===

Итак, мы вплотную приблизились к ответу на вопрос: «Что надо сделать, чтобы внедрение было результативным?».

Для начала я отвечу так. Надо обуздать системную сложность, причем дважды: живой системы, то есть организации, и внедряемого прототипа, который сам по себе является сложной информационной системой. Совет в духе «хочешь быть здоровым — будь им».

А вот чтобы сделать это с высокой степенью гарантии, вам придется найти практикующих системных аналитиков с очень высоким уровнем компетенций, которых я далее буду именовать «прогрессорами» — как людей, способных к реализации мощных прорывных проектов.

Да, именно так, вам придется выбрать людей, а не инструменты или компанию-подрядчика. Только люди, наделенные, в отличие от инструментов, интеллектом, в состоянии справиться с системной сложностью.

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

Итак, кто же это такой «практикующий системный аналитик с очень высоким уровнем компетенций»? Что он умеет делать, чего не могут другие?

Это человек, который может построить адекватную, по возможности, простую модель автоматизируемого бизнес-процесса и добиться ее результативного внедрения — невзирая на высокую динамику требований. Это человек, который силой мысленного эксперимента способен в целом предсказать траекторию развития системы. Это человек, который сможет справиться с несоответствиями, неизбежно возникающими в процессе внедрения. Это человек, который ведет проект. А чтобы все это смочь, прогрессор должен объединить в одном лице максимально возможные уровни нескольких компетенций.

Во-первых, прогрессор должен обладать великолепным концептуальным (системным) мышлением. Он в состоянии распознавать внутреннее устройство системы и строить адекватные модели. Он умеет упрощать сложность — собирает идеи, вопросы, наблюдения в единое представление. Он умеет задавать «прорезающие» вопросы в сложной ситуации.

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

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

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

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

=== Поведенческие индикаторы прогрессора ===

==== 1. Концептуальное (системное) мышление: ====

* наблюдает несоответствия между текущей ситуацией и ситуацией в прошлом;
* применяет сложные концепции для анализа этих несоответствий;
* упрощает сложность — собирает идеи, вопросы, наблюдения в единое представление; определяет ключевой вопрос в сложной ситуации;
* создает новые концепции, в том числе по сложным системам;
* распознает внутреннее устройство системы и строит адекватные, по возможности простые, модели.

2. Забота о качестве:

* проявляет интерес к увеличению порядка в существующей системе (бизнес-процессе);
* выявляет слабые стороны и недостаточные данные и ищет информацию для поддержания порядка в системе (бизнес-процессе);
* разрабатывает и применяет комплексные системы для организации и отслеживания информации.

3.	Готовность к изменениям:

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

4. Ориентация на результат:

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

5. Коммуникабельность:

* заинтересован в результативности взаимодействия;
* умеет не вызывать раздражения у собеседников, представляя свою точку зрения;
* использует разнообразный репертуар коммуникативных средств;
* умеет слушать и точно воспринимать смысл сообщения;
* задает вопросы собеседнику в точном соответствии с темой разговора.

6. Ответственность:

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

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

=== Как выбрать прогрессора ===

«Дай-ка, дай-ка мне ответ, ты прогрессор или нет?». Как отыскать нужного человека?

Надо найти человека, который в условиях высокой динамики требований вел результативный проект, похожий на предстоящий вам:

# схожего масштаба с нужной вам тематикой (отлично)
# схожего масштаба с другой тематикой (хорошо)
# меньшего масштаба (удовлетворительно)

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

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

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

Спрашивайте все, что вам интересно, но обязательно убедитесь, что именно ваш кандидат создал модель бизнес-процесса, которая результативно внедрена, невзирая на высокую динамику требований в процессе внедрения (еще раз посмотрите на критерии результативного внедрения!). И на всякий случай проверьте, что он подходит под описанный мной «портрет компетенций». Если вы обнаружите сильное несоответствие, то велика вероятность, что вел проект кто-то другой. Попробуйте найти именно его…

И, наконец, получите весомые гарантии того, что выбранный вами кандидат (именно он!) и будет вести ваш проект до окончания внедрения.

=== После результативного внедрения ===

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

Во-первых, добейтесь, чтобы люди, которые будут отвечать за развитие проекта после внедрения, появились в проекте как можно раньше (на рис.2 «инженер»).

Как правило, прогрессор даст вам трезвую оценку, есть ли в проектной команде такие люди. Только продолжительная совместная работа с прогрессором на внедрении позволит «инженеру» в будущем отвечать за самостоятельное развитие модуля. Это единственный вариант трансляции знаний, который позволит осуществлять устойчивое развитие модуля, в соответствии с заложенными моделями, архитектурой и дизайном.

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

=== Один в поле не воин ===

За рамками статьи осталось много факторов, которые необходимы для результативного внедрения:

* объективная необходимость проекта для организации
* внятное управление проектом со стороны заказчика
* слаженная проектная команда, которая работает с прогрессором
* достойный уровень инструментального оснащения (то есть «Прототипа»)
* гибкие технологии проектного управления…

Но будьте уверены — если вы действительно нашли прогрессора, если он согласился работать вместе с вами над проектом, если через полгода совместной работы вы еще вместе, то вероятность успеха проекта — очень высока.

[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:2008 год (Статьи)]]
[[Категория:Intelligent Enterprise (Публикации)]]

{{replicate-from-custiswiki-to-lib}}