Приложение 2. Компьютерный кризис 2000 года: Руководство по оцениванию GAO/AIMD-10.1.14

Приложение 2

Сентябрь 1997 года

Главное бюджетно-контрольное управление США

Компьютерный кризис 2000 года:
Руководство по оцениванию GAO/AIMD-10.1.14

Модель преобразования 2000 года:
структурный подход и жесткое управление программой могут уменьшить риски

Преобразование даты 2000 года представляет собой глобальный вызов индустрии информационных технологий. Каждая организация, федеральная или частная, должна обеспечить полное соответствие 2000 году своих информационных систем задолго до 31 декабря 1999 года. Хотя проблема 2000 года не является интересной в техническом отношении, она объемна и сложна. Для многих ведомств программа преобразования 2000 года будет крупнейшим проектом, когда-либо реализованным их организациями управления информационными ресурсами.

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

Руководство описывает пять этапов осуществления программы или проекта с представлением для каждого этапа основного действия или сегмента программы 2000 года.

1.0. Осведомленность

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

Основные процессы

1.1. Определить проблему 2000 года и ее потенциальное влияние на организацию.

1.2. Провести кампанию осведомления о проблеме 2000 года.

1.3. Оценить возможности организации по управлению программой.

1.4. Разработать и задокументировать стратегию 2000 года.

1.5. Получить поддержку руководства.

1.6. Учредить совет исполнительных руководителей.

1.7. Назначить руководителя программы 2000 года и учредить офис программы 2000 года.

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

1.1. Определить проблему 2000 года и ее потенциальное влияние на организацию.

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

1.2. Провести кампанию осведомления о проблеме 2000 года.

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

1.3. Оценить возможности организации по управлению программой, включая:

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

- уровни кадрового обеспечения и требования к квалификации кадров.

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

1.4. Разработать и задокументировать стратегию 2000 года.

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

1.5. Получить поддержку руководства и придать ей официальный статус путем выпуска:

- программного заявления по 2000 году;

- концепции программы 2000 года.

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

1.6. Учредить совет исполнительных руководителей.

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

1.7. Назначить руководителя программы 2000 года и учредить офис программы 2000 года.

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

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

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

2.0. Оценивание

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

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

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

Основные процессы

2.1 . Определить соответствие 2000 году.

2.2. Сконцентрироваться на основных деловых областях и процессах и разработать документ оценивания 2000 года.

2.3. Оценить серьезность влияния отказов, связанных с 2000 годом.

2.4. Провести в масштабе организации инвентаризацию информационных систем для каждой деловой области.

2.5. Разработать всеобъемлющий портфель автоматизированных систем.

2.6. Проанализировать портфель систем.

2.7. Установить приоритеты систем и компонентов для преобразования или замены.

2.8. Учредить проектные группы 2000 года для деловых областей и основных систем.

2.9. Разработать план программы 2000 года.

2.10. Определить необходимые ресурсы, установить их приоритеты и мобилизовать их.

2.11. Разработать стратегии проверки, планы тестирования и сценарии.

2.12. Определить требования к стенду (facility) тестирования 2000 года.

2.13. Определить и приобрести инструментальные средства 2000 года.

2.14. Рассмотреть вопросы графика внедрения.

2.15. Рассмотреть вопросы интерфейсов и обмена данными.

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

2.17. Определить подверженные 2000 году системы и процессы, функционирующие вне сферы управления информационными ресурсами.

2.1. Определить соответствие 2000 году.

2.2. Сконцентрироваться на основных деловых областях и процессах и разработать документ оценивания 2000 года.

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

2.3. Оценить серьезность влияния отказов, связанных с 2000 годом.

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

2.4. Провести в масштабе организации инвентаризацию информационных систем для каждой деловой области.

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

2.5. Разработать всеобъемлющий портфель автоматизированных систем и определить для каждой системы:

- связи с основными деловыми областями или процессами;

- платформы, языки и системы управления базами данных;

- программное обеспечение операционных систем и утилиты;

- телекоммуникации;

- внутренние и внешние интерфейсы;

- владельцев;

- доступность и адекватность исходного кода и соответствующей документации.

2.6. Проанализировать портфель систем и определить для каждой системы:

- невосстанавливаемые элементы (отсутствие исходного кода или документации);

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

2.7. Установить приоритеты систем и компонентов для преобразования или замены.

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

2.8. Учредить проектные группы 2000 года для деловых областей и основных систем.

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

2.9. Разработать план программы 2000 года, включая:

- графики для всех задач и этапов программы 2000 года;

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

- оценивание и выбор вариантов передачи третьей стороне;

- назначение проектов преобразования или замены проектным группам 2000 года;

- оценивание рисков;

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

2.10. Определить необходимые ресурсы, установить их приоритеты и мобилизовать их.

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

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

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

Этап I - автономное тестирование. Ориентировано на тестирование функциональности и соответствия одного приложения или программного модуля.

Этап II - интеграционное тестирование. Тестирует объединение связанных программных модулей и приложений.

Этап III - системное тестирование. Тестирует все объединенные компоненты информационной системы.

Этап IV - приемо-сдаточное тестирование. Тестирует информационную систему с "живыми" операционными данными.

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

2.12. Определить требования к стенду (facility) тестирования 2000 года.

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

2.13. Определить и приобрести инструментальные средства 2000 года.

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

2.14. Рассмотреть вопросы графика внедрения, включая:

- определение и выбор средств преобразования;

- время, необходимое для ввода преобразованных систем в производство;

- преобразование резервных и архивных данных.

2.15. Рассмотреть вопросы интерфейсов и обмена данными, включая:

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

- уведомление всех внешних объектов обмена данными;

- потребность в мостах и фильтрах данных;

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

- процесс проверки для исходящих внешних данных;

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

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

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

2.17. Определить подверженные 2000 году системы и процессы, функционирующие вне сферы управления информационными ресурсами.

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

3.0. Обновление

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

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

Основные процессы

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

3.2. Разработать мосты и фильтры данных.

3.3. Заменить выбранные приложения и соответствующие системные компоненты.

3.4. Задокументировать изменения в программном коде и системах.

3.5. Спланировать автономное, интеграционное и системное тестирование.

3.6. Списать выбранные приложения и соответствующие системные компоненты.

3.7. Сообщить об изменениях в информационных системах внутренним и внешним пользователям.

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

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

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

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

3.2. Разработать мосты и фильтры данных.

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

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

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

3.4. Задокументировать изменения в программном коде и системах.

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

3.5. Спланировать автономное, интеграционное и системное тестирование.

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

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

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

3.7. Сообщить об изменениях в информационных системах внутренним и внешним пользователям.

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

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

Следить за проектами преобразования и замены, регистрировать и использовать характеристики (метрики) проектов для управления затратами и сроками.

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

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

4.0. Проверка

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

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

Основные процессы

4.1. Разработать и задокументировать планы и графики тестирования и соответствия.

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

4.3. Реализовать стенд тестирования 2000 года.

4.4. Внедрять автоматизированные инструментальные средства тестирования и сценарии тестирования.

4.5. Выполнить автономное, интеграционное и системное тестирование.

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

4.7. Начать приемо-сдаточное тестирование.

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

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

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

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

4.3. Реализовать стенд тестирования 2000 года.

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

4.4. Внедрять автоматизированные инструментальные средства тестирования и сценарии тестирования.

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

4.5. Выполнить автономное, интеграционное и системное тестирование.

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

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

4.7. Начать приемо-сдаточное тестирование.

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

5.0. Внедрение

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

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

Основные процессы

5.1 . Определить среду и процедуры перехода.

5.2. Разработать график внедрения.

5.3. Разрешить вопросы обмена данными и межведомственные проблемы.

5.4. Выполнить преобразование баз данных и архива.

5.5. Завершить приемо-сдаточное тестирование.

5.6. Реализовать планы чрезвычайных обстоятельств.

5.7. Обновить или разработать планы восстановления после катастроф.

5.8. Внедрить преобразованные или замененные системы.

5.1. Определить среду и процедуры перехода.

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

5.2. Разработать график внедрения.

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

5.3. Разрешить вопросы обмена данными и межведомственные проблемы, включая обеспечение того, что:

- все внешние объекты обмена данными уведомлены;

- мосты и фильтры данных готовы для обработки не соответствующих 2000 году данных;

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

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

- процесс проверки готов для входящих внешних данных.

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

5.4. Выполнить преобразование баз данных и архива.

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

5.5. Завершить приемо-сдаточное тестирование.

Обычно формальное тестирование обнаруживает 80-90% программных ошибок, а остальные 10-20% ошибок раскрываются во время эксплуатации. Приемо-сдаточное тестирование должно быть завершено не позднее осени 1999 года, чтобы оставить достаточно времени для исправления программных ошибок, обнаруженных после внедрения.

5.6. Реализовать планы чрезвычайных обстоятельств.

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

5.7. Обновить или разработать планы восстановления после катастроф.

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

5.8. Внедрить преобразованные или замененные системы.

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

Управление программой и проектом

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

Основные процессы

А. Создать структуру управления программой 2000 года.

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

С. Внедрить процессы и инструментальные средства управления программой.

А. Создать структуру управления программой 2000 года:

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

- определить технических и управленческих представителей от каждой основной деловой области.

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

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

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

- управление конфигурацией,

- обеспечение качества,

- управление рисками,

- планирование проекта и слежение,

- измерение характеристик,

- финансирование.

С. Внедрить процессы и инструментальные средства управления программой.

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

Вопрос. В соответствии с инструкцией ЦБ РФ N 62а от 30.06.97 ссуда может быть отнесена к более высокой группе риска только в случае ее переоформления либо с изменением условий договора, либо без изменений условий договора. Инструкция не предусматривает других видов переоформления ссуды, которые могут являться основанием для отнесения ссуды к более высокой группе риска.

Однако если банк внес изменение в условия кредитного договора, но это условие не считается переоформлением ссуды с изменением или без изменения условий договора, то является ли такое изменение основанием для отнесения задолженности к более высокой группе риска в соответствии с требованием Инструкции ЦБ РФ N 62а?

Ответ. Внесение банком изменений в кредитный договор, связанных с изменением техники начисления процентов за пользование кредитом в связи с указаниями Банком России об изменении требований по данному вопросу, а также связанных с изменением процентной ставки в связи с изменением ставки рефинансирования Банка России, если в первоначальном кредитном договоре предусмотрено положение о такой возможности пересмотра процентной ставки, можно не расценивать как переоформление ссуды для целей Инструкции Банка России от 30.06.97 N 62а.

Изменение условий первоначального договора путем включения условия о предоставлении заемщиком справок о своих расчетных и иных счетах, открытых в других банках, или изменения банком даты уплаты заемщиками процентов за пользование кредитом в течение одного календарного месяца для всех клиентов одновременно для целей Инструкции Банка России от 30.06.97 N 62а также можно не расценивать как переоформление ссуды. Другие изменения каких-либо условий первоначального договора для целей Инструкции Банка России от 30.06.97 N 62а расцениваются как переоформление ссуды.

Одновременно считаем необходимым обратить внимание на то, что в соответствии с Указанием Банка России от 5.03.99 N 507-У "О внесении изменений и дополнений в Инструкцию Банка России "О порядке формирования и использования резерва на возможные потери по ссудам" от 30.06.97 N 62а" при классификации ссудной задолженности переоформленные ссуды с разным качеством обеспечения могут независимо от количества переоформлений быть отнесены в зависимости от реальной величины кредитного риска по оценке банка к более низкой группе риска, чем это вытекает из формализованных критериев, определенных п.2.8.5 Инструкции для классификации обеспеченных ссуд.

Вопрос. В связи с вступлением в действие Налогового кодекса изменяются ли требования к оформлению инкассовых поручений на принудительное (бесспорное) взыскание в соответствии с действующим законодательством налоговых платежей во внебюджетные фонды по сравнению с требованиями, изложенными в главе Х Инструкции Госбанка СССР N 2 и Указаниях ЦБ РФ N 51-У от 3 декабря 1997 года?

Изменяются ли при этом контрольные функции банков при приеме инкассовых поручений к исполнению? Будут ли Указания Банка России по этому вопросу?

Ответ. Статьями 46 и 48 части первой Налогового кодекса Российской Федерации определен порядок взыскания налога за счет денежных средств, находящихся на счетах налогоплательщика в банке, в случае неуплаты или неполной уплаты налога в установленный срок.

Федеральным законом Российской Федерации "О Центральном банке Российской Федерации (Банке России)" (ст. 80) определено, что Банк России устанавливает правила, формы, сроки и стандарты осуществления безналичных расчетов в Российской Федерации.

Порядок представления инкассовых поручений на взыскание средств со счета плательщика без его распоряжения в случаях, предусмотренных законодательством, определен Правилами безналичных расчетов в народном хозяйстве N 2 от 30.09.87 г., действующими в части безакцептного и бесспорного списания средств со счетов плательщиков (телеграмма Банка России от 2.10.92 г. N 218-92).

Порядок составления и оформления инкассовых поручений установлен Указанием Банка России "О введении новых форматов расчетных документов" от 3.12.97 г. N 51-У с учетом внесенных изменений и дополнений Указанием Банка России "О внесении изменений и дополнений в Указание Банка России от 3.12.97 N 51-У "О введении новых форматов расчетных документов" от 22.02.99 г. N 502-У".

Согласно пункту 1.7.6 раздела 1 части III "Организация работы по ведению бухгалтерского учета" Правил ведения бухгалтерского учета в кредитных организациях, расположенных на территории Российской Федерации от 18.06.97 N 61, при приеме денежно-расчетных документов ответственный исполнитель банка обязан проверить, соответствует ли документ установленной форме бланка, заполнены ли все предусмотренные бланком реквизиты, правильность указания банковских реквизитов. Платежные (расчетные) документы, принятые кредитной организацией к исполнению, должны оформляться подписью бухгалтерского работника, осуществившего их прием и проверку, с указанием даты приема.

Аналитические материалы, опубликованные в "Вестнике Банка России"
в 1 квартале 1999 года

Название	"Вестник"
	номер	дата
Особенности движения наличной иностранной валюты через уполномоченные банки в ноябре 1998 года	N 3 (347)	21.01.99
О результатах проведения деноминации российского рубля	N 7 (351)	4.02.99
Платежный баланс России за январь-сентябрь 1998 года	N 8 (352)	8.02.99
Состояние внутреннего валютного рынка и динамика обменного курса рубля в январе 1999 г.	N 9 (353)	10.02.99
Обзор конъюнктуры рынка ГКО-ОФЗ-ОБР за январь 1999 года	N 9 (353)	10.02.99
Состояние внутреннего валютного рынка в феврале 1999 г.	N 16(360)	17.03.99
Основные тенденции движения наличной иностранной валюты через уполномоченные банки в 1998 году	N 17(361)	24.03.99
Обзор конъюнктуры рынка ГКО-ОФЗ-ОБР за февраль	N 17(361)	24.03.99