Управляемая ликвидация

Статья переехала, новый адрес: «Управляемая ликвидация» на lib.custis.ru

Михаил Заборов, руководитель направления Торговые сети компании CustIS (Заказные ИнформСистемы)

Журнал Директор информационной службы (CIO.RU), №12, 20 декабря 2008, стр. 22-25. http://www.osp.ru/cio/2008/12/5693440/

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

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

Почему организации расстаются с унаследованным программное обеспечение? Причины могут быть разные:

• неудовлетворительные темпы изменений ИТ в ответ на новые требования бизнеса
• бедная функциональность старого ПО
• низкая производительность унаследованного ПО
• устаревшая технологическая платформа
• потеря управляемости ИТ-системой из-за потери ключевых разработчиков
• слишком высокая совокупная стоимость владения устаревшей системой

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

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

Сценарий поэтапной замены

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

Рассмотрим информационную систему предприятия, состоящую из нескольких компонентов (см. рис. 1). Унаследованная ИТ-система, подлежащая замене, выделена красным цветом.

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

Как правило, подобные системы активно взаимодействуют со своим ИТ–окружением, происходит оперативный обмен документами и данными (в т.ч. мастер-данными) с другими транзакционными или справочными приложениями (системы 1 и 2 на рис.1). С системой работают бизнес-пользователи, данные из нее выгружаются в различные BI-приложения и системы учета «постфактум». Например, выгрузка документов для целей бухгалтерского учета или периодическая выгрузка операций в систему формирования корпоративной отчетности. Такие выгрузки на рисунке обозначены пунктирными линиями к системам 3-5 на рис.1.

Рисунок 1. Заменяемая ИТ-система в окружении других ИС предприятия.

Этап 1. Анализ ситуации и выбор функционала для замены

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

Готовых рецептов выделения участков для первоочередной замены не существует. Это скорее искусство, чем известная формальная процедура. Основная цель на этом этапе: получить наибольший эффект от новой системы путем снятия самых острых проблем.

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

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

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

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

Рисунок 2. Часть пользователей переключаются на работу в новой системе.

Этап 2. Включение новой системы в работу

По окончании первого шага можно перевести часть пользователей на работу в новой системе (см. рис. 2), которая связана со старой, и обе функционируют одновременно. По мере замены функционал новой системы нарастает, а старой — постепенно отмирает. Поскольку старая система еще поддерживает некоторые ключевые операционные процессы, в неё продолжают вноситься соответствующие изменения. Эти изменения должны также поддерживаться и в новой системе

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

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

Рисунок 3. Прежняя система лишается самостоятельности.

Этап 3. Лишение самостоятельности

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

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

Параллельно могут быть установлены связи и непосредственный обмен данными новой системы с прочими компонентами информационной системы предприятия (синие стрелки на рис.3).

Рисунок 4. Переключение всех входящих информационных потоков со старой системы на новую.

Этап 4. Переключение информационных потоков

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

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

Рисунок 5. Прежняя система практически выводится из IT-ландшафта.

Этап 5. Переключение оперативного информационного обмена и ликвидация

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

По мере выявления информационных потоков, они переносятся или переключаются на новую систему. Именно на этом этапе в какой-то момент принимается волевое решение об остановке старой системы (рис.6).

Рисунок 6. Ликвидация — остановка и удаление старой системы.

Дополнительные комментарии

Мы рассмотрели случай замены «один на один». Возможны различные варианты: новая система заменяет собою несколько старых или одна унаследованная система заменяется на несколько новых. В любом случае, можно провести замену, следуя приведенным выше этапам бережного внедрения.

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

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

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

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

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

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

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

Статья переехала, новый адрес: «Проводники в джунглях системной сложности» на lib.custis.ru

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

Владимир Рахтеенко, Генеральный директор 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 «инженер»).

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

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

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

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

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

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