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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прогрессоры

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

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

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

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

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

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

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

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

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

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

«Дай‑ка, дай‑ка мне ответ, ты прогрессор или нет?». Как отыскать нужного человека? Надо найти человека, который в условиях высокой динамики требований вел результативный проект, похожий на тот, который предстоит выполнить вам:
1) схожего масштаба с нужной вам тематикой (отлично);
2) схожего масштаба с другой тематикой (хорошо);
3) меньшего масштаба (удовлетворительно).

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

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

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

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

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

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

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

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

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

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

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

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

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