Проводники в джунглях системной сложности

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

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

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

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

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

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

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

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

• ИТ-директор обслуживает интересы бизнеса (а не вендоров, что, к сожалению, тоже бывает). В первую очередь важно, что ИТ-директор поддерживает (а не сдерживает!) необходимый темп изменения бизнес-процессов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прогрессоры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе:

Владимир Рахтеенко, генеральный директор компании «Заказные ИнформСистемы» (CustIS).