3.3. Замена

3.3. Замена

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

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

Проблемы

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

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

Обучение новой системе потребует времени и ресурсов; они могут быть ограничены.

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

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

Разработанные по заказу приложения могут иметь неадекватные программы обработки даты. Изменение или обновление исходного кода может быть дорогостоящим и требующим много времени.

Пакеты программ должны быть заменены соответствующими 2000 году версиями (upgrades) или другими продуктами.

Во время преобразования данные могут быть потеряны из-за модификации полей.

Могут потребоваться новые инструментальные средства для штата программистов, включая:

- системы анализа влияния;

- инструментальные средства управления изменениями или контроля версий;

- утилиты быстрого изменения и замены;

- инструментальные средства тестирования.

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

Зависимость от интерфейсов создает сложности при интегрировании новой системы в существующую среду.

Рекомендуемый подход

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

Преимущества

Возможность заменять устаревшие пакеты и системы последними разработками.

Добавление долгосрочной гибкости.

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

Недостатки

Это рискованный метод, учитывая короткое время для реализации.

Новая система требует дополнительных ресурсов.

Не все новые покупные программы соответствуют 2000 году.

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

"ДЕЛАТЬ", если:

- изготовленные на заказ системы обеспечивают значительное стратегическое преимущество над покупными пакетными системами;

- пакетные системы плохо интегрируются в финансовые системы;

- пакетные системы не являются гибкими и / или сбалансированными для роста;

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

- времени достаточно, чтобы разработать и внедрить изготовленное на заказ приложение или систему;

- пакетные системы не отвечают всем требованиям пользователей.

"ПОКУПАТЬ", если:

- затраты на то, чтобы "сделать", больше затрат на то, чтобы "купить";

- требуются стандартные методы обработки, такие, как стандартные финансовые действия, стандартные подпрограммы закупки и т.д.;

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

- имеются достаточные ресурсы, чтобы купить новую систему, но не для того, чтобы сделать новую систему.

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

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

Проверьте все новые продукты и системы, а также существующие системы, на которые может повлиять замена.

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

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

Советы

Оцените затраты для обоих альтернативных вариантов метода замены. Обратите внимание на то, что затраты метода "делать" могут использоваться в обосновании замены пакета.

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

Используйте следующий контрольный список при выборе пакета прикладных программ:

- функциональные возможности - обеспечивает выполнение всех необходимых Функций;

- гибкость - легко модифицировать или настраивать;

- дружелюбие по отношению к пользователю - прост в использовании и обеспечивает управление;

- аппаратные и программные ресурсы - способен поддерживать существующие ресурсы;

- характеристики базы данных - поддерживает текущие требования обработки и поиска;

- установка - процесс не требует много усилий и времени;

- сопровождение - поставщик предоставляет продолжающееся сопровождение и поддержку;

- документация - ясная и полная;

- качество поставщика - приложение разработано опытными разработчиками;

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

- соответствие 2000 году - продукт уже соответствует 2000 году.

Так как аппаратные средства и их операционные системы заменяются регулярно, новые системы должны проверяться на соответствие 2000 году.

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