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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Михаил Заборов — руководитель направления «Торговые сети» компании «Заказные ИнформСистемы» (CustIS); pressa@custis.ru