Владимир Рахтеенко
Генеральный директор CustIS (Заказные ИнформСистемы)

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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


Рис.1. ИТ-проект в многомерном пространстве требований

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

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

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

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

Рис.2. Эволюция функционала при результативном и слабом внедрении

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

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

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

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

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

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

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

Прогрессоры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Проводники в джунглях системной сложности. Автоматизация ключевых бизнес-процессов крупных предприятий»