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

Ссылки сюда (3) →

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

Репликация: База Знаний «Заказных Информ Систем» → «Управляемая ликвидация»