Ÿрил.1-ФТТ.docx · Web view2020-02-12 · Опытная эксплуатация (далее – ОЭ) проводится в предпродуктивной среде

ФУНКЦИОНАЛЬНО-ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ ИТ-ПРОЕКТА IT-19-70 «ВНЕДРЕНИЕ ИНСТРУМЕНТА СВЕРКИ

ВНУТРИГРУППОВЫХ ОБОРОТОВ»

Москва2019г.

Функционально-технические требования ИТ-проекта «Внедрение инструмента сверки внутригрупповых оборотов» IT-19-70

УтвержденУтверждающий ФИО, должность Подпись Дата

Куратор ИТ-проекта, Председатель Управляющего комитета

Глазунова Е.И.. финансовый контролер АК АЛРОСА (ПАО)

СогласованСогласующий ФИО, должность Подпись Дата

Заказчик ИТ-проекта, член Управляющего совета

Мишарина А.А., начальник Управления подготовки отчетности по

МСФО АК АЛРОСА (ПАО)

Член Управляющего совета

Стасенко А.В., Главный бухгалтер – начальник Управления бухгалтерского

учета и отчетности АК АЛРОСА (ПАО)

Член Управляющего советаОсипенко Н.В., Директор по учету и отчетности ООО «АЛРОСА Бизнес-

сервис»

Член Управляющего советаСевергин К.И., Руководитель Центра Компетенций SAP ООО «АЛРОСА

ИТ»Бизнес-партнер ИТ по финансово-экономическому бизнес-направлению

Казакова Н.А., Руководитель портфеля проектов ООО «АЛРОСА ИТ»

Корпоративный ИТ-архитектор

Пачин О.И., руководитель портфеля проектов ООО «АЛРОСА ИТ»

Представитель Службы безопасности

Мануилов А.А., Начальник отдела информационной безопасности АК

АЛРОСА (ПАО)

История документаДата Версия Автор (Роль, ФИО) Комментарий

19.12.2019 1.0 Пахомова Е.Г., Руководитель портфеля проектов ООО «АЛРОСА ИТ»Пачин О.И., Корпоративный архитектор ООО «АЛРОСА ИТ»

Первоначальная версия

31.01.2020 2.0 Пахомова Е.Г., Руководитель портфеля проектов ООО «АЛРОСА ИТ»Пачин О.И., Корпоративный архитектор ООО «АЛРОСА ИТ»

Уточненная версия по результатам полученных

замечаний

05.02.2020 3.0 Пахомова Е.Г., Руководитель портфеля проектов ООО «АЛРОСА ИТ»

Уточненная версия в связи с пересмотром подхода к

ОЭ, ОПЭ.

Связанные документы (этот документ должен читаться вместе с):Название документа Номер версии/

Имя файлаДата

Карточка ИТ-проекта

2


Содержание1. Основные сокращения, термины и определения.......................................................................42. Цели и задачи................................................................................................................................53. Общие сведения............................................................................................................................7

3.1 Описание рамок проекта................................................................................................73.2 Описание текущей ситуации.........................................................................................7

3.2.1 Описание существующего бизнес-процесса.........................................................73.2.2 Описание недостатков существующего бизнес-процесса...................................83.2.3 Описание существующей информационной системы/инфраструктуры...........83.2.4 Описание недостатков существующей информационной системы/ инфраструктуры 8

3.3 Бизнес-требования..........................................................................................................94. Требования к продукту...............................................................................................................10

4.1 Общие требования к архитектуре...............................................................................104.2 Требования к доступности и производительности....................................................124.3 Требования по обеспечению отказоустойчивости системы и непрерывности бизнеса 124.4 Требования к безопасности..........................................................................................134.5 Требования к автоматизации.......................................................................................134.6 Требования к данным...................................................................................................14Периодичность........................................................................................................................15Проверка и очистка данных...................................................................................................15Справочники и классификаторы...........................................................................................15Требования к хранению данных............................................................................................164.7 Связь с существующим окружением..........................................................................174.8 Требования к переносу (миграции) данных...............................................................184.9 Требования к пользовательскому интерфейсу...........................................................184.10 Требования к наличию отчётов...................................................................................194.11 Требования к документации........................................................................................194.12 Требования к средствам обучения..............................................................................224.13 Требования к методологическому обеспечению проекта.........................................24

5. Требования к организации работ...............................................................................................256. Требования к Исполнителю.......................................................................................................26

6.1 Состав работ Исполнителя...........................................................................................266.2 Требования к плану работ............................................................................................366.3 Порядок контроля и приемки результатов.................................................................37

6.3.1 Внутреннее тестирование на этапе «Реализация»..............................................376.3.2 Опытная эксплуатация..........................................................................................386.3.3 Опытно-промышленная эксплуатация................................................................396.3.4 Критерии приемки результатов испытаний:.......................................................40

Приложение 1. Организационный объем проекта...........................................................................41Приложение 2. Процесс сверки ВГО «как есть».............................................................................42Приложение 3. Пример типовых расхождений...............................................................................43

3


Функционально-технические требования (далее – ФТТ) разработаны для проведения работ по реализации инструмента сверки внутригрупповых оборотов (далее – ВГО), включая как проработку и оптимизацию процесса сверки ВГО актуализацию выгрузки фактических данных для сверки ВГО (при необходимости), так и расширение существующей функциональности подсистемы «Консолидация» КИИСУ. По результатам технической реализации осуществляется актуализация Методологии формирования консолидированной финансовой отчетности Группы АЛРОСА в соответствии с МСФО со стороны Заказчика. Работы данного проекта выполняются в рамках Программы «Быстрое закрытие», направленной на сокращение сроков подготовки и выпуска отчетности по РСБУ и МСФО.

Выполнение организационных мероприятий с ДЗО АЛРОСА и обеспечение выгрузки фактических данных из прочих локальных информационных учетных систем ДЗО для сверки ВГО и формирования консолидированной финансовой отчетности находятся за границами данного проекта.

1. Основные сокращения, термины и определения

Таблица 1Сокращения, термины и определения

№ СОКРАЩЕНИЯ, ТЕРМИНЫ И

ОПРЕДЕЛЕНИЯ

ОПИСАНИЕ

1 2 31. SAP BPC SAP Business Planning and Consolidation2. SAP BI IP SAP Business Intelligence – Integrated Planning3. SAP BW SAP Business Warehouse4. БП Бухгалтерия предприятия на базе продуктов 1С5. Бухгалтерский счет счет РСБУ в ЛУИС ДЗО6. ВГО Внутригрупповые обороты7. ДЗ Дебиторская задолженность8. ДЗО АЛРОСА Дочерние и зависимые общества, входящие в Группу АЛРОСА9. ЕК Единица консолидации10. Заказчик АК АЛРОСА (ПАО)11. ИС Информационная система12. КИИСУ Комплексная интегрированная информационная система управления на базе SAP

ERP ECC 6.013. КЗ Кредиторская задолженность14. МСФО Международные стандарты финансовой отчетности15. МТО Материально-техническое обеспечение16. НМЦ Начальная максимальная цена17. НСИ Нормативно-справочная информация18. ОПЭ Опытно-промышленная эксплуатация19. ОЦО Общий центр обслуживания, ООО АЛРОСА Бизнес-сервис20. ОЭ Опытная эксплуатация21. Первичный документ Под первичным документом в рамках данного ФТТ следует понимать такие

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

22. ПО Программное обеспечение23. ПЭ Промышленная эксплуатация24. РСБУ Российские стандарты бухгалтерского учета25. СЭД Система электронного документооборота26. ТЗ Техническое задание27. ТОиР Техническое обслуживание и ремонт28. ФВД Формуляры ввода данных, рабочие книги Excel, настроенные с использованием

функциональности EPM29. ФТТ Функционально-технические требования30. ФЭБ Финансово-экономический блок

4


Таблица 2ИС, используемые в ФТТ

№ КРАТКОЕ НАИМЕНОВАНИЕ

ПОЛНОЕ НАИМЕНОВАНИЕ

ИС

ОСНОВНЫЕ ПРОЦЕССЫ,

ФУНКЦИИ ИС

ВЛАДЕЛЕЦ ИС КОММЕНТАРИЙ

1 2 3 4 5 6

1. 1С: Учет для ДЗО 1С: Учет для ДЗО

Автоматизируемые бизнес-процессы на базе 1С: Предприятие 8: учет и отчетность; финансы и

казначейство; бюджетная модель

Глазунова Е.И., финансовый контролер АК АЛРОСА (ПАО)

Находится на стадии реализации (закупка ИТ-работ). Плановый срок перевода в ПЭ – 01.07.2021

2. КИИСУ учетная подсистема

Комплексная интегрированная информационная система управления, учетная подсистема

Автоматизированные бизнес-процессы на базе SAP ECC 6.0: учет и отчетность; финансы и

казначейство; управление

недвижимостью; управление МТО; ТОиР; расчет и учет

налогов; управление

сбытом; учет капитального

строительства

Филипповский А.Н., Заместитель генерального директора

Введено в ПЭ 01.01.2013

3. КИИСУ подсистема «Консолидация»

Комплексная интегрированная информационная система управления, подсистема «Консолидация»

Автоматизированные бизнес-процессы на базе SAP BPC: Сбор данных РСБУ Трансформация

данных Консолидация

данных Отчетность


Промышленная эксплуатация

4. КИИСУ SAP BW (зеркало)

Комплексная интегрированная информационная система управления, SAP BW (уровень зеркала ERP)


Промышленная эксплуатация

5. ЛИУС ДЗО

Локальные информационные учетные системы ДЗО

Автоматизированы процессы бухгалтерского, налогового учета

Руководители ДЗО -

6. СЭДСистема электронного документооборота

Согласование документации Компании, в том числе проектной

в ПЭ

2. Цели и задачи

Целью проекта IT-19-70 «Внедрение инструмента сверки внутригрупповых оборотов» (далее – Внедрение СВГО) является:

автоматизация процесса сверки внутригрупповых оборотов для подготовки консолидированной финансовой отчетности Группы АЛРОСА по МСФО в

5


сокращенные сроки; автоматизация выгрузки фактических данных из КИИСУ для целей сверки ВГО и

консолидации финансовой отчетности.

Таблица 3

№ ЗАДАЧИ ПРОЕКТА ОПИСАНИЕ ПРЕДПОСЫЛОК И УСЛОВИЙ РЕШЕНИЯ ЗАДАЧ

1 2 3

1.

Актуализация под техническую реализацию Методологии формирования консолидированной финансовой отчетности Группы АЛРОСА в соответствии с МСФО в части процесса сверки ВГО, распространяющей свои требования на ДЗО АЛРОСА и направленной на оптимизацию данного процесса

Автоматизация сверки ВГО является одной из задач, которые необходимо решить в рамках Программы «Быстрое закрытие», направленной на: сокращение сроков и повышение качества

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

повышение уровня контроля неурегулированных расхождений.

2.

Анализ и оптимизация бизнес-процессов: Сбор данных для сверки ВГО и

формирования финансовой отчетности; Контрольные функции, коммуникации с

ДЗО по процессу сверки ВГО; Корректировка данных; Отчетность для сверки ВГО.

3. Разработка Регламента взаимодействия участников сверки ВГО

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

5.

Актуализация автоматизированной выгрузки фактических данных из КИИСУ для целей сверки ВГО и подготовки консолидированной финансовой отчетности

6.Актуализация Матрицы рисков и контрольных процедур в части процесса сверки ВГО

6


3. Общие сведения

3.1 Описание рамок проекта

Таблица 4

ОРГАНИЗАЦИОННЫЕ РАМКИ

В организационный объем проекта входят общества группы АК АЛРОСА (28 ДЗО с учетом АК АЛРОСА (ПАО))

согласно Приложению 1. следующие структурные подразделения Компании:

АК АЛРОСА (ПАО) Управление бухгалтерского учета и отчетности; Управление подготовки отчетности по МСФО.

• ООО «АЛРОСА Бизнес-сервис» - специалисты ОЦО для тестирования автоматизированных операций, отчетов;

• ООО «АЛРОСА ИТ» - специалисты ЦК SAP для осуществления поддержки проекта со стороны базиса и осуществления технической экспертизы решения

Проект реализуется для Финансово-экономического блока Компании.Плановое количество пользователей, выполняющих работу в создаваемом функционале «Сверка ВГО» – 65 человекДЗО, отраженные в Приложении 1 как «пилот», участвуют при анализе, оптимизации процессов сверки ВГО, консолидации, построение целевой архитектуры. При анализе текущего процесса выгрузки данных из КИИСУ участвуют все ДЗО, чей учет организован в данной системе.

ПЛАНИРУЕМЫЙ СРОК РЕАЛИЗАЦИИ Декабрь 2020г.

ПРОДУКТ ПРОЕКТА Модификация подсистемы «Консолидация» КИИСУ в части функционала Сверка внутригрупповых оборотов

3.2 Описание текущей ситуации

3.2.1 Описание существующего бизнес-процесса

В 2013 году в АК «АЛРОСА» (ПАО) в рамках проекта по внедрению Комплексной интегрированной информационной системы (далее – КИИСУ) осуществлено создание следующих подсистем на базе продуктов SAP:

учетная подсистема на базе SAP ECC 6.0; подсистема бюджетирования и консолидации на базе SAP BI IP; подсистема аналитической отчетности на базе SAP BW 7.3 on Oracle.

Внедрение КИИСУ АК «АЛРОСА» (ПАО) направлено на создание единого информационного пространства Компании на основе единой централизованной Системы — единого источника консолидированных и актуальных данных на основе лучших в своем классе решений компании ЅАР.

В 2018г. осуществлена модификация КИИСУ, а именно: миграция подсистем аналитической отчетности, бюджетирования и консолидации на платформу SAP BPC 10.1 (Standard и Embedded) in BW on HANA.

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

7


ДЗО. Пошаговое верхнеуровневое описание процесса «как есть» сверки ВГО представлено в Приложении 2 данного ФТТ.

В 2019г. в рамках Программы «Быстрое закрытие» осуществлен анализ наиболее затратных по времени процессов закрытия периода в учете и определены мероприятия, направленные на сокращение сроков выполнения данных процессов. Одним из таких мероприятий является оптимизация процесса сверки ВГО и внедрение соответствующего целевого инструмента.

3.2.2 Описание недостатков существующего бизнес-процесса

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

Процесс сверки ВГО подлежит оптимизации для обеспечения:

1. Сокращения сроков подготовки финансовой консолидированной отчетности по МСФО с 60 календарного дня, следующего за отчетным периодом, до 45 календарного дня.При этом за счет оптимизации и автоматизации процесса сверки ВГО сокращение сроков - на 3-4 дня.

2. Для повышения качества данных, представляемых со стороны ДЗО.

3.2.3 Описание существующей информационной системы/инфраструктуры

В настоящее время сверка остатков и оборотов по внутригрупповым операциям осуществляется в подсистеме бюджетирования и консолидации (SAP BPC 10.1 in BW on HANA) КИИСУ на основании учетных данных по РСБУ:

загруженных из учетной подсистемы КИИСУ (SAP ERP 6.0) и трансформированные в модель BPC через настроенные меппинги;

предоставленных ДЗО посредством ФВД в модели BPC.

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

3.2.4 Описание недостатков существующей информационной системы/ инфраструктуры

В ходе оценки существующего решения выявлены следующие недостатки:

Недостаточный уровень детализации информации, ее аналитичности, необходимой для целей выявления причин расхождения и их урегулирования в подсистеме «Консолидация» без обращения к учетным системам ДЗО, АК АЛРОСА (ПАО).

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

Недостаточный уровень автоматизации сбора данных в учетных системах ДЗО и их передачи в подсистему «Консолидация».

8


3.3 Бизнес-требования

Таблица 5. № ОПИСАНИЕ ТРЕБОВАНИЯ ВЛАДЕЛЕЦ

(ИНИЦИАТОР) ТРЕБОВАНИЯ

СВЯЗЬ С ЦЕЛЯМИ ПРОЕКТА

1. Сокращение сроков сверки внутригрупповых оборотов

Глазунова Е.И. финансовый контролер АК АЛРОСА (ПАО)

За счет оптимизации процесса и общих правил сборки сверки данных (в сторону расширения аналитики предоставления данных), на основании которых осуществляется автоматизация целевого инструмента

За счет автоматизации расширенной выгрузки данных из КИИСУ

За счет автоматизации расширенной выгрузки данных из учетных ИС ДЗО1

За счет автоматизации определения и учета выявленных причин расхождения (ввод пояснений, их изменение и хранение), на основании которых принимаются решения о возможных корректировках

2. Повышение качества данных


За счет автоматизированных контрольных процедур при сборе и сверке данных по ВГО

За счет дополнительного контроля своевременного отражения внутригрупповых расчетов (расхождения могут быть выявлены на более ранней стадии)

За счет выравнивания подхода, правил к процессу сбора данных со стороны ДЗО1, централизации НСИ, влияющих на процесс сверки ВГО1

3. Создание единого информационного пространства для АК АЛРОСА и ДЗО для проведения сверки ВГО


4. Актуализация выгрузки из КИИСУ под обновленный процесс сверки ВГО


За счет автоматизации расширенной выгрузки данных из КИИСУ

4. Требования к продукту

4.1 Общие требования к архитектуре

Внедрение инструмента сверки ВГО должно быть осуществлено с использованием текущей функциональности подсистемы «Консолидация» КИИСУ SAP BPC 10.1 in BW on HANA (далее - SAP BPC), SAP BW 7.4 on HANA 1.0 (далее - SAP BW). Данная функциональность применяется в настоящее время для целей процессов консолидации и формирования финансовой и иной отчетности компании. Архитектура подсистемы «Консолидация» КИИСУ трехкомпонентная: клиент - сервер приложений –сервер хранения. Целевой ландшафт систем четырехсистемный, состоящий из систем разработки (BID), тестирования (BIS), предпродуктива контроль качества (BIQ)и продуктива (BIP). Изменения в ландшафте системы запланированы в рамках технических

1 Работы по автоматизации сбора данных в учетных ИС ДЗО, определение подхода и правил сбора данных со стороны ДЗО, централизации НСИ, влияющих на процесс сверки ВГО находятся за границами данного ФТТ, выполняются в рамках программы «Быстрое закрытие».

9


мероприятий, направленных на апгрейд SAP BW 7.4 до SAP BW 7.5 при переводе HANA 1.0 на HANA 2.0.2

Для целей сверки ВГО в подсистеме «Консолидация» КИИСУ необходимо разработать отдельную модель BPC, либо осуществить расширение существующих моделей BPC «VGO CONS» или «Consolidation» в текущей подсистеме «Консолидации» КИИСУ, обеспечить ввод, изменение, хранение комментариев по причинам расхождений с учетом требований к детальности аналитик сверки.

Должна быть предусмотрена модификация:

потока данных от ДЗО, не ведущих учет в системе КИИСУ, включая изменения используемых ФВД с учетом требований к детальности аналитик сверки, либо создание новых ФВД, содержащих ограниченный объем учетных данных, требуемых для выполнения сверки ВГО в необходимых аналитических разрезах.

выгрузки данных из КИИСУ для функционала сверки ВГО и консолидации финансовой отчетности.

Область предполагаемой модификации подсистемы «Консолидация» КИИСУ приведена на схеме потоков данных модели Консолидации (Рисунок 1).

Рисунок 1. Схема потоков данных модели Консолидации

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

не модифицируют стандартную функциональность процессов в системе; используют специальные точки расширения существующей функциональности;

2 Плановые сроки завершения работ - июль 2020г. – август 2020г.10


не изменяют стандартные объекты, закрытые SAP к изменению сторонним разработчиком.

При оптимизации и автоматизации процесса сверки и урегулирования внутригрупповых расчетов между компаниями Группы в целях подготовки сводной (консолидированной) отчетности необходимо руководствоваться Методологией формирования консолидированной финансовой отчетности Группы в соответствии с МСФО, где установлены следующие основные принципы консолидации внутригрупповых оборотов:

Трансформация данных ДЗО осуществляется в разрезе каждой отдельной компании с формированием соответствующих проводок;

В процессе трансформации осуществляется выверка внутригрупповых остатков и оборотов, формирование корректировочных консолидационных поправок на основании комментариев, полученных от ДЗО и АК «АЛРОСА» (ПАО). ДЗО, имеющие доступ в систему SAP BPC, осуществляют выверку с контрагентами самостоятельно с использованием вспомогательных отчетов в системе:

o консолидация дебиторской и кредиторской задолженностей осуществляется следующими консолидационными проводками «Исключение внутригрупповой кредиторской и дебиторской задолженности», «Исключение внутригрупповых займов и кредитов», «Элиминация внутригрупповых процентов к получению и к уплате», «Корректировка элиминации ДЗ-КЗ»;

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

На этапе «Концептуальное проектирование» Исполнителем должны быть предложены технические решения по расширению детальности аналитик при необходимости.

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

В рамках выполнения работ со стороны Исполнителя также должен быть уточнен порядок выгрузки данных из КИИСУ в соответствии с целевым процессом сверки ВГО (по необходимости).

Все создаваемые объекты в BW/BPC должны быть размещены в отдельной инфо-области и иметь свой префикс, например, «ZVG*». Существующие объекты BW могут быть изменены по согласованию со специалистами Центра компетенции SAP. Создаваемые инфо-объекты, провайдеры, кубы, ДСО, переменные, расширения, классы, BADi и т.д. должны соответствовать текущему Регламенту ведения разработок в BW.

4.2 Требования к доступности и производительности

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

65 чел. - планируемое количество зарегистрированных пользователей;

11


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

Реализуемое решение не должно ухудшать текущие характеристики функциональной производительности подсистемы «Консолидация», учетной подсистемы КИИСУ для пользователя, в том числе в части открытия ФВД и обработки данных в ФВД, что должно быть подтверждено Исполнителем работ в рамках ОЭ, ОПЭ.

На этапе «Концептуальное проектирование» Исполнитель должен выполнить расчет сайзинга необходимой памяти SAP HANA после реализации решения и организационного роста на 5 лет, данные расчеты подлежат уточнению по результатам проведенного ОЭ, ОПЭ и фиксации их в Запросе на поддержке.

4.3 Требования по обеспечению отказоустойчивости системы и непрерывности бизнеса

Дополнительных требований в части изменения уровня доступности подсистемы «Консолидация» в процессе модификации не предъявляется и изменения в КИИСУ не требуются.

Предполагается осуществлять реализацию данного проекта на базе существующего ландшафта технических систем в составе эксплуатируемой информационной системы КИИСУ подсистемы «Консолидация» (SAP BW и SAP BPC). Ландшафт функционирует на базе облачной инфраструктуры HANA Enterprise Cloud.

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

4.4 Требования к безопасности

В информационной системе должна быть реализована ролевая модель разграничения доступа. Различным группам пользователей должны назначаться различные права доступа в информационной системе, в рамках их должностных обязанностей, в соответствии с Матрицей функциональных ролей, а также с соблюдением принципов «минимально необходимых привилегий» (least privilege) и «минимально необходимых знаний» (need to know).

Система должна обеспечивать логирование действий пользователей.

4.5 Требования к автоматизации

1. Реализация функционала сверки ВГО должна обеспечивать: 1.1. Сбор данных для сверки внутригрупповых оборотов и остатков, консолидации

финансовой отчетности посредством ФВД, файлов и бесшовной передачи из учетной подсистемы КИИСУ. Интеграция с информационными системами и подсистемами осуществляется в соответствии с разделом 4.7 ФТТ.

1.2. Сверку загруженных данных (оборотов и остатков) в соответствии с моделью данных подсистемы «Консолидация» КИИСУ в следующей детализации: Компания; Бухгалтерский счет (код счета 60,62,75, 76, 58, 66, 67) – наименование, код; Контрагент – код, наименование, ИНН, КПП; Структурное подразделение АК «АЛРОСА» ПАО – код, наименование; Договор – номер бумажного договора, дата; Первичный документ (бумажный номер счета фактуры/платежного

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

12


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

1.3. Ввод, изменение комментариев по результатам урегулирования расхождений ВГО с записью имени пользователя, даты и времени создания (до 1000 символов для поля комментария).

1.4. Создание и применение инструмента управления комментариями (автоархивация, удаление, т.д.) с точки зрения технической поддержки.

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

1.6. Автоматизацию формирования корректирующих проводок на основе типовых расхождений ВГО с учетом критерия материальности (параметр «Материальность для корректирующих проводок») и их согласования/утверждения при превышении установленного порога. Дополнительно необходимо предусмотреть возможность создания предварительных корректирующих проводок с возможностью изменения счетов.

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

1.8. Обеспечить сверку ВГО с применением параметра «Материальность для сверки ВГО» при его задании/изменении перед началом каждого периода сверки ВГО. При этом должна быть предусмотрена возможность обращения/использования к ранее внесенным значениям данного параметра, т.е. необходимо обеспечить зависимость значений от периода подготовки отчетности. Данный справочник должен являться пользовательским. Расчет параметра «Материальность для сверки ВГО» осуществляется вне системы. Вносимые изменения в подсистему «Консолидации» КИИСУ не должны нарушать текущий реализованный процесс трансформации и консолидации данных

2. Уточнение выгрузки данных из КИИСУ для функционала сверки ВГО и консолидации финансовой отчетности включает в себя:

2.1. Актуализацию инструмента меппинга данных учетной подсистемы КИИСУ в модель данных подсистемы «Консолидации» с учетом требований к изменению процесса сверки ВГО

2.2. Наполнение меппинга на основании данных, предоставленных Заказчиком.2.3. Актуализацию инструмента передачи данных из учетной подсистемы КИИСУ в

подсистему «Консолидация».3. Изменение настроек учетной подсистемы «Консолидация», создание новых справочников

осуществляется при согласовании с Заказчиком. Наполнение существующих справочников КИИСУ учетной подсистемы осуществляется в рамках текущей поддержки (при необходимости).

13


4.6 Требования к данным

Загрузка данных для сверки ВГО и консолидации финансовой отчетности должна осуществляться в формате нарастающим итогом (YearToDate). Необходимо обеспечить отдельный набор показателей модели данных функционала сверки ВГО, которая является подмоделью модели данных подсистемы «Консолидация» КИИСУ.

Загрузка данных осуществляется как непосредственно из КИИСУ учетной подсистемы, так с использованием ФВД. В рамках проектирования со стороны Исполнителя должен быть разработан/уточнен формат ФВД и закреплен в соответствующем проектном документе. На основании данных требований со стороны ДЗО осуществляется автоматизация выгрузки из учетных систем ДЗО.

Загрузка данных сотрудником ДЗО производится только по соответствующей ему ЕК, согласно имеющимся полномочиям. Загрузка данных куратором ЕК/сотрудником ОЦО производится только по соответствующей ему ЕК (ЕК может включать в себя группу ДЗО в соответствии с иерархией ЕК), согласно имеющимся полномочиям. Исполнителем в рамках этапа проектирования разрабатывается проектный документ, в котором закрепляются роли и полномочия, и согласовывается с Заказчиком.

Загруженные данные подлежат проверке на предмет соответствия BPC моделям VGO CONS и Consolidation, допустимость загружаемых значений признакам моделей BPC.

Данные, участвующие в сверке ВГО, и данные, используемые для консолидации, должны соответствовать и быть сопоставимы. При проработке, оптимизации процесса сверки ВГО необходимо предусмотреть технические и организационные мероприятия, направленные на соблюдение данного требования, что должно найти отражение в Матрице рисков и контрольных процедур. Технические мероприятия подлежат реализации, как в модели, используемой для сверки ВГО, так и в КИИСУ учетной подсистемы в части выгрузки для сверки ВГО.

Периодичность

Модифицированная подсистема «Консолидация» в части СВГО должна обеспечивать возможность загрузки данных и формирования отчетности по расхождениям сверки с учетом требуемой детализации не реже 1 раза в месяц.

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

Проверка и очистка данных

Модифицированная подсистема «Консолидация» в части СВГО обеспечивает проверку и очистку данных реализованными средствами, которые используются в настоящее время при сборе данных для формирования консолидированной финансовой отчетности.

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

Справочники и классификаторы

Функциональность сверки ВГО использует те же мастер-данные и справочники, что и подсистема «Консолидация» КИИСУ. При разработке решения необходимо опираться на текущие

14


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

Основные справочники следующие: Единица консолидации; Партнерская единица консолидации; Категория данных; Период; Версия данных; Виды валют; Корпоративный план счетов (КПС) / позиции консолидации; Контрагент / деловой партнер; Структурное подразделение / балансовая единица; Сегмент

В рамках проекта должны быть разработаны следующие дополнительные справочники (но не ограничиваясь ими, если в ходе анализа/оптимизации процесса и проектирования решения будут выявлены дополнительные):

типовые расхождения ВГО; типовые корректирующие проводки для подсистемы «Консолидация».

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

Состав справочников должен быть уточнен со стороны Исполнителя в ходе проекта по требованиям и потребностям Заказчика. Наполнение создаваемых справочников осуществляет Заказчик.

В рамках оптимизации процесса сверки ВГО необходимо определить потребность и объем пользовательских справочников и реализовать их на последующем этапе.

Требования к хранению данных

Функциональность сверки ВГО подсистемы «Консолидация» КИИСУ должна обеспечить выполнение следующих требований к хранению данных:

1. Возможность хранения в одном хранилище фактических данных.

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

3. Единство структурирования (показатели, аналитические разрезы и т.п.) между данными планирования, прогнозирования и фактическими данными.

4. Поддержка необходимого количества измерений для хранимых данных.

5. Возможность обновления справочников через импорт файлов и через WEB-интерфейс для модели консолидации SAP BPC.

6. Возможность экспорта справочников.

15


7. Анализ существующих и создаваемых справочников на предмет потребности и возможности их ведения в зависимости от времени (время зависимые справочники), реализовать время зависимость по необходимости, осуществлять поддержку времязависимых иерархий справочников, версионности, времязависимых текстовых описаний основных данных.

8. Поддержку произвольного количества иерархических представления значений справочников.

9. Обособленность модели данных функциональности сверки ВГО, которая должна являться подмоделью модели данных подсистемы «Консолидация» КИИСУ.

10. Создание, управление справочниками со стороны Исполнителя должно осуществляться в соответствии с требованиями текущей технической поддержки SAP BW, SAP BPC (Центр компетенций SAP), например,

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

справочники всех аналитик должны быть в одном файле формата MS Excel; все справочники атрибутов, тестов и иерархий должны быть в файле формата MS Excel

и вестись в нем; источник данных в BW (PSA) для текстов и атрибутов для одного признака должен быть

один. Нельзя создавать PSA для текстов и отдельную PSA для атрибутов для одного и того же признака.

Требования к ведению разработок в КИИСУ будут представлены Исполнителю перед началом работ этапа «Реализация».

4.7 Связь с существующим окружением

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

Таблица 6Связь с существующим/планируемым окружением и интеграция

№ ИНФОРМАЦИОННАЯ СИСТЕМА/ ПОДСИСТЕМА ОПИСАНИЕ РЕАЛИЗОВАННОЙ СВЯЗИ

1 3 2

1.

1С: Учет для ДЗО(планируется реализовать в рамках проекта 1С: Учет для ДЗО)

Инициатор взаимодействия - 1С: Учет для ДЗОПередаваемая информация – передача данных в КИИСУ подсистему «Консолидация»:

данные РСБУ, преобразованные с учетом мэппинга данных на счета КПС модели данных подсистемы «Консолидации».

Механизм передачи – бесшовная интеграция.Регламент взаимодействия – будет определен при проектировании ИС «1С: Учет для ДЗО».

2.КИИСУ учетная подсистема (SAP ECC 6.0)

Инициатор взаимодействия - КИИСУ учетная подсистемаПередаваемая информация – передача данных в КИИСУ SAP BW – зеркало:

данные РСБУ для формирования отчетности, проведения финансовой консолидации.

Механизм передачи –прямая интеграция RFC.Регламент взаимодействия – 1 раз в месяц по моменту наступления срока сбора данных для формирования консолидированной финансовой отчетности.

3. КИИСУ SAP BW (уровень зеркала ERP)

Инициатор взаимодействия - КИИСУ подсистема «Консолидация»Передаваемая информация – передача данных из КИИСУ SAP BW (зеркало):

данные РСБУ, преобразованные по правилам меппинга, в данные соответствующие модели подсистемы «Консолидация».

16


№ ИНФОРМАЦИОННАЯ СИСТЕМА/ ПОДСИСТЕМА ОПИСАНИЕ РЕАЛИЗОВАННОЙ СВЯЗИ

1 3 2Механизм передачи – Data Transfer Process (DTP) .Регламент взаимодействия – 1 раз в месяц по моменту наступления срока сбора данных для формирования консолидированной финансовой отчетности.

4. Учетные системы ДЗО

Инициатор взаимодействия - Учетные системы ДЗОПередаваемая информация – передача данных в КИИСУ подсистему «Консолидация»:

данные РСБУ трансформированные в модель подсистемы «Консолидации» в соответствии с требованиями данной подсистемы.

Механизм передачи – файловый обмен/ФВД.Регламент взаимодействия – 1 раз в месяц по моменту наступления срока сбора данных для формирования консолидированной финансовой отчетности.

4.8 Требования к переносу (миграции) данных

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

В рамках выполнения работ данного ФТТ со стороны Исполнителя должны быть обеспечены загрузка, обновление, актуализация справочных данных (в том числе выявленных новых справочных данных), в объеме, необходимом для старта реализованного функционала сверки ВГО на этапе тестирования и продуктивной эксплуатации.

Загрузка и преобразование исторических данных под новые требования не требуется.

4.9 Требования к пользовательскому интерфейсу

Основные требования к пользовательскому интерфейсу представлены в таблице:Таблица 7

Требования к пользовательскому интерфейсу

ЯЗЫК ИНТЕРФЕЙСА Русский языкВОЗМОЖНОСТЬ

УДАЛЕННОЙ РАБОТЫ ДаТРЕБОВАНИЯ К ВОЗМОЖНОСТИ

НАСТРОЙКИ ПРЕДСТАВЛЕНИЯ

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

ДРУГИЕ ТРЕБОВАНИЯ

Внешнее оформление: Наличие графического многооконного режима Интеграция с приложениями MS Office Наличие инструментов для формирования регламентированных отчетов

Диалог с пользователем: должен быть обеспечен удобный и интуитивно понятный интерфейс для

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

доступность и/или видимость отдельных элементов интерфейса должна определяться ролью/полномочиями пользователя;

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

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

При проектировании решения Исполнитель должен ориентироваться на наиболее актуальные наработки вендора в части пользовательского интерфейса.

Для выявленных бизнес-операций должен быть проведен анализ способов оптимизации стандартного пользовательского интерфейса:

17


использование инструментов персонализации стандартного интерфейса в зависимости от бизнес-сценария путем комбинирования вкладок и экранов, автозаполнения полей;

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

доработка стандартного интерфейса с помощью штатных средств программирования системы.

4.10 Требования к наличию отчётов

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

Таблица 8Перечень отчетов, подлежащих актуализации, реализации

№ НАЗВАНИЕ ОТЧЕТА АКТУАЛИЗАЦИЯ/ РЕАЛИЗАЦИЯ

РЕГУЛЯРНОСТЬ СОЗДАНИЯ

1 2 3 41. IC_DATA_DZO (для ДЗО) для отдельной ДЗО в разрезе счетов.

Необходимо предусмотреть возможность группировки данных в отчете

Актуализация По необходимости

2. IC_DATA_VGO (общий) матрица сверки «все против всех». Отчет должен быть представлен как детально так и агрегировано по аналитикам

Актуализация По необходимости

3. ВГО Протокол Актуализация По необходимости

4. IC_DATA_VGO Актуализация По необходимости

5. Отчет контроля статуса загрузки данных, статусов мероприятий (пересчет валют, корректировочные проводки, т.д.);

Реализация Ежемесячно / По необходимости

6. Отчет с расхождениями и комментариями к расхождениям Реализация Ежемесячно / По необходимости

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

8. Консолидационные проводки - отчет по расхождениям, сгруппированными по счетам КПС и с необходимой для проводки аналитики.

Реализация Ежемесячно / по необходимости

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

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

4.11 Требования к документации

Все документы проекта должны соответствовать локальным нормативным документам АК АЛРОСА (ПАО), в том числе Положению об управлении проектом АК АЛРОСА (ПАО). В случае отсутствия готовых шаблонов документов их формат предлагается Исполнителем и согласуется Заказчиком. Согласование всех проектных документов осуществляется разработчиком документов в соответствии с требованиями и правилами Заказчика. Ниже приведен перечень проектных документов, подлежащих разработке в рамках проекта.

18


Таблица 9Перечень проектных документов

№ НАЗВАНИЕ ДОКУМЕНТА ТРЕБОВАНИЯ К ДОКУМЕНТУ

1. Устав ИТ-проекта Язык: русскийФормат: MS Word, MS Excel

2.План работ ИТ-проекта Детальный план работ ИТ-проекта по этапам работ, задачам с указанием

результатов и ответственных, в том числе со стороны Заказчика.Формат: MS Project с перекладкой в формат MS Excel

3.

Предложение по участию представителей Заказчика в соответствии с планом работ

Предложение готовится на основании Плана работ ИТ-проекта, в котором должны быть представлены задачи, в которых участвует Заказчик с указанием периода, процента их занятости и результата его участия.Формат: MS Excel

4.

Статус выполнения работ отчеты о выполненных и планируемых работах

Язык: русскийФормат: MS Power Point, MS ExcelДанный отчет выпускается на еженедельной основе и подлежит представлению заинтересованным лицам, определенным в Уставе ИТ-проекта. Документ включает в себя:

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

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

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

снизить/нивелировать; детальная информация по согласованию проектной документации,

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

5.

Протоколы совещаний рабочих функциональных групп, коллегиальных органов управления ИТ-проектов

Язык: русскийФормат: MS Word, MS Excel

6.

План коммуникаций Язык: русскийФормат: MS Word, MS Excel Документ включающий планы по взаимодействию внутри проектной команды , в том числе с участием Заказчика, и по взаимодействию с ДЗО.

7.

Проектное решение по созданию инструмента сверки ВГО

Язык: русскийФормат: MS Word, MS ExcelДанный документ должен включать в себя в том числе архитектуру решения, техническое описание реализуемого инструмента сверки ВГО (КИИСУ подсистема «Консолидация», КИИСУ SAP BW (уровень зеркала ERP)), изменение ФВД, создание/изменение справочников/аналитик/ атрибутов, интеграцию со смежными информационными системами/подсистемами, альбом отчетных форм с приложением их образцов. Также данный документ должен содержать требования к учетным системам ДЗО в части обеспечения выгрузки данных для подготовки консолидированной финансовой отчетности (Функциональные требования к передаче данных из учётных систем ДЗО в подсистему «Консолидация» КИИСУ).

8.

Проектное решение по реализации выгрузки из КИИСУ для целей сверки ВГО и консолидации финансовой отчетности

Язык: русскийФормат: MS Word, MS ExcelДанный документ должен включать в себя в том числе описание изменений и/или создание инструмента выгрузки, преобразования данных из КИИСУ для целей сверки ВГО и консолидации финансовой отчетности, изменение инструмента мэппинга данных КИИСУ для передачи их к подсистему «Консолидация»

19



9.

Регламент взаимодействия участников сверки ВГО

Язык: русскийФормат: MS Word, MS ExcelДанный документ включает в себя (но не ограничиваясь) описание процесса сверки ВГО, которое подлежит автоматизации, с указанием входящих, исходящих событий, документов, подразделений/ ответственных лиц/ ролей, сроков. Требования к данному документу представлены в разделе 4.13 «Требования к методологическому обеспечению проекта»

10.

Функциональные требования к передаче данных из учётных систем ДЗО в сверку ВГО КИИСУ подсистемы «Консолидация»

Язык: русский Формат: MS Word, MS Excel

11.

Матрица доступа (Матрица функциональных ролей)

Язык: русскийФормат: MS Word, MS ExcelВ документе должны быть отражены создаваемые, изменяемые функциональные роли пользователей, специалистов технической поддержки с учетом вносимых изменений в функциональность в процесс.

12.Протокол выполненных настроек и разработок, спецификации, ТЗ на разработку

Язык: русскийФормат: MS Word, MS ExcelСправочники должны быть представлены в формате MS Excel

13.

Актуализированная Методология формирования консолидированной финансовой отчетности Группы АЛРОСА в соответствии с МСФО3

Язык: русскийФормат: MS Word, MS ExcelАктуализация осуществляется по результатам проведенного тестирования силами Заказчика.Методика должна учитывать имеющиеся алгоритмы, заложенные в автоматических проводках по консолидации внутригрупповых оборотов

14.Актуализированная Матрица рисков и контрольных процедур в части процесса сверки ВГО


15. Программа и методика проведения испытаний


16. Протокол тестирования Язык: русскийФормат: MS Word, MS Excel

17.

Протокол опытной эксплуатации (принятие решения о готовности к проведению ОПЭ)

Язык: русскийФормат: MS Word, MS ExcelДокумент включает в себя условия проведения ОЭ, описание протестированных процессов, реестр замечаний и предложений, выявленных во время ОЭ, результаты их устранения с подтверждением факта устранения замечания, предложения по развитию решения, достижение критериев успешности прохождения ОЭ, решение о переходе на этап ОПЭ.

18. Операционная инструкция Язык: русскийФормат: MS Word, MS Excel

19. Руководство администратора Язык: русскийФормат: MS Word, MS Excel

20.Руководства по обеспечению технической поддержки и сопровождению системы


21. Обучающие материалы Язык: русскийФормат: MS Word, MS Excel

22. Протоколы обучения пользователей


23.Протокол подключения и настройки прав доступа пользователей


3 В зоне ответственности Заказчика20



24. Протокол миграции данных Язык: русскийФормат: MS Word, MS Excel

25. Запрос на поддержку Язык: русскийФормат: MS Word, MS Excel

26. Протокол опытно-промышленной эксплуатации системы

Язык: русскийФормат: MS Word, MS ExcelДокумент включает в себя условия проведения ОПЭ, описание протестированных процессов, реестр замечаний и предложений, выявленных во время ОПЭ, результаты их устранения с подтверждением факта устранения замечания, предложения по развитию решения, достижение критериев успешности прохождения ОПЭ, решение о переводе решения в ПЭ и на техническую поддержку в ЦК SAP, выученные уроки.

27. Итоговый отчет Язык: русскийФормат: MS Word, MS Excel

Документы должны предоставляться в электронном виде. Документы, являющиеся результатом этапа, подлежат обязательному согласованию в СЭД членами органа управления проектом (Операционный совет/Управляющий совет), утверждением куратора проекта. Результирующие согласованные документы предоставляются в электронном и печатном виде (2 экземпляра). Сканированные копии завизированных результирующих документов прилагаются к их электронным версиям и размещаются на проектном портале.

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

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

4.12 Требования к средствам обучения

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

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

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

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

21


Таблица 10Категории пользователи для обучения

№ КАТЕГОРИЯ ПОЛЬЗОВАТЕЛЕЙ ТРЕБОВАНИЯ К СРЕДСТВАМ И МЕТОДАМ ОБУЧЕНИЯ

1. Ключевые пользователи - 10 человекКонечные пользователи (Пользователи ОЦО, ДЗО, Кураторы ДЗО) - 55 человек

Обучение включает в себя: методологическую часть (в части выполненных изменений); процессную часть с демонстрацией сквозного примера в системе с

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

пользователей.

Подробное обучение и выполнение упражнений проводится по процессу выгрузки данных из КИИСУ, сверки ВГО (процесс сбора, загрузки и проверки данных, завершая сверкой, выявлением расхождений, их причин, корректировкой (различные способы), в том числе формирование корректирующих проводок), повторной проверкой, формированием отчетности, влиянием на трансформацию и консолидацию данных, т.д.). Курсы обучения, учебные материалы должны быть разработаны в соответствии с матрицей функциональных ролей/организационных единиц/должностей.Концептуально должна быть представлена следующая информация:

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

Дополнительно в рамках проводимого обучения освещаются основные подходы к проведению ОЭ, ОПЭ.

2. Кураторы ДЗО - 1 человек

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

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

пользователей.

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

о процессе сборе данных, их корректировках об управлении и ведении НСИ; о подходе к техническому поддержанию и сопровождению решения.

3. Заказчики проекта - 2 человек

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

методологическую часть (в части выполненных изменений); процессную часть с демонстрацией сквозного примера в системе с

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

Перед началом обучения пользователи должны быть ознакомлены с изменениями в методике (ответственность Заказчика)

22


№ КАТЕГОРИЯ ПОЛЬЗОВАТЕЛЕЙ ТРЕБОВАНИЯ К СРЕДСТВАМ И МЕТОДАМ ОБУЧЕНИЯ

4. Специалисты технической группы поддержки - 5 человек

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

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

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

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

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

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

(обеспечивает Заказчик); учебные материалы по работе в реализуемом функционале (обеспечивает

Исполнитель); информационная среда с примерами/заданиями, используемыми в ходе обучения

(обеспечивает Исполнитель); инструкции по выполнению необходимых операций в системе в рамках бизнес-роли

пользователя (обеспечивает Исполнитель); материалы для дистанционного обучения: видеоролики, интерактивные обучающие

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

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

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

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

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

4.13 Требования к методологическому обеспечению проекта

Основной целью методологического обеспечения проекта является обеспечение подготовки и внедрения всех необходимых методологических документов в рамках функционального и организационного объема проекта с учетом последующей реализации процесса сверки ВГО в подсистеме «Консолидация» КИИСУ.

23


В методологический объем проекта со стороны Исполнителя входит анализ принятой в АК АЛРОСА (ПАО) методологии процесса подготовки данных и процесса сверки внутригрупповых остатков и оборотов для консолидации финансовой отчетности. Данный пакет документов при необходимости подлежит актуализации и адаптации по ходу выполнения технических работ проекта. При проведении закупочных процедур ранее разработанные документы, относящиеся к процессу сверки ВГО, могут быть частично предоставлены в объеме, необходимом и достаточном для проведения оценки трудоемкости и стоимости работ при условии подписания соглашения о неразглашении информации.

В настоящее время существуют следующие методологические документы, необходимые для реализации сверки ВГО:

Методология формирования консолидированной финансовой отчетности Группы АЛРОСА в соответствии с МСФО;

Матрица рисков и контрольных процедур.

Актуализацию Методологии формирования консолидированной финансовой отчетности Группы АЛРОСА в соответствии с МСФО осуществляет Заказчик, актуализацию Матрицу рисков и контрольных процедур осуществляет Исполнитель.В рамках выполнения работ проекта со стороны Исполнителя на этапе «Концептуальное проектирование», кроме технического описания процесса и его настройки, разработки (Проектное решение), должно быть представлено описание процесса (Регламент взаимодействия участников сверки ВГО), включающие в себя:

Описание процесса сверки ВГО «как будет» по шагам с указанием сроков, участников, ответственных, порядка их взаимодействия, а также контролей, осуществляемых участниками/ответственными/

Описание процедуры сверки: по каким операциям осуществляется сверка, по каким аналитическим признакам, какие правила при сверке используются, контроли, осуществляемые участниками/ответственными и т.д.

Описание НСИ, используемой в процессе сверки ВГО.

Данный раздел подлежит актуализации и адаптации во время технической реализации и проведения ОЭ, ОПЭ.

5. Требования к организации работ

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

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

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

3. По необходимости, должны проводится встречи проектных команд от Заказчика и Исполнителя для определения состояния ИТ-проекта и решения оперативных вопросов;

4. По каждой встрече с представителями Заказчика Руководителем проекта от Исполнителя должен составляться фиксирующий документ (протокол встречи);

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

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

24


в ее согласовании; 7. Руководитель проекта от Исполнителя должен документировать все изменения требований

к системе;8. Исполнитель обязуется выполнять корпоративные стандарты Компании, соблюдать

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

9. Место проведения работ – г. Москва, командировки не предполагаются.10. Со стороны Исполнителя не позднее чем за 2 рабочих дня до начала работы рабочей

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

6. Требования к Исполнителю

6.1 Состав работ Исполнителя

Исполнитель выполняет работы в соответствии с ФТТ и Положением об управлении проектами АК АЛРОСА (ПАО). Работы по проекту выполняются поэтапно. Состав этапов, перечень работ, описание основных работ, распределение ответственности представлены в Таблице 11.

25

Таблица 11. Состав работ

ЭТАП/ ФАЗА

ВЫПОЛНЯЕМЫЕ РАБОТЫОТВЕТСТВЕННОСТЬ

ИСПОЛНИТЕЛЯ, ОСУЩЕСТВЛЯЮЩЕГО РАЗРАБОТКУ

ОТВЕТСТВЕННОСТЬЗАКАЗЧИКА

ОТВЕТСТВЕННОСТЬ ВНУТРЕННЕГО ИТ-ИНТЕГРАТОРА

1 2 3 4 5

Стадия «Обоснование»

Этап 1 «Подготовительные мероприятия. Закупочные процедуры»

1.1 Подготовительные мероприятия. Закупочные процедуры

Не участвует Согласование материалов на ИК, Защита проекта на ИК.

Согласование закупочной документации, в том числе ТЗ, требований к Исполнителю работ.

План коммуникаций с ДЗО. Согласование шаблонов проектной

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

Создание рабочих функциональных групп от ФЭБ и ОЦО.

Разработка детального плана работ этапа 1 Подготовительные мероприятия.

Подготовка материалов на ИК. Разработка закупочной документации (ТЗ,

НМЦ, требования к Исполнителю работ), проведение закупочных процедур.

Разработка шаблонов проектной технической и эксплуатационной документации.

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

Технические работы по подготовке системного ландшафта (инсталляция, настройка, мониторинг и администрирование систем).

Стадия «Реализация»

Этап 2 «Концептуальное проектирование»

2.1. Анализ процессов выгрузки данных из КИИСУ, сверки ВГО, консолидации, построение целевой архитектуры

Разработка и согласование детального плана работ проекта.

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

Анализ и оптимизация процесса сверки ВГО для целей сокращения

Предоставление информации и документации по запросам.

Обеспечение вовлечение бизнес-экспертов для выполнения работ этапа.

Предоставление требований к реализуемой функциональности.

Определение и назначение владельцев НСИ. Определение и назначение владельцев

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

Исполнителя.

Организация процесса анализа текущей ситуации.


Экспертиза проектной технической документации.

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

Архитектурная и экспертная поддержка


ЭТАП/ ФАЗА





1 2 3 4 5

длительности по сравнению с текущим процессом.

Разработка и согласование Реестра предложений к методологической документации проекта.

Разработка и согласование Реестра отчетных форм, подлежащих реализации.

Разработка целевой архитектуры решения, в том числе по выгрузке данных из КИИСУ, и ее согласование.

Проектное управление, в том числе подготовка статус-отчетов.

Согласование иной проектной документации этапа.

Обеспечение коммуникаций с ДЗО.

проекта, в том числе: o консультирование по вопросам

технической архитектуры текущего решения и интеграции с ИС;

o ознакомление с требованиями ведения настроек, разработок в системах SAP, создания и ведения ролей и полномочий SAP, создания и переноса транспортных запросов;

o экспертиза проектной документации, в том числе ее нормоконтроль;

Актуализация Устава (при необходимости).

Подключение специалистов Исполнителя к ИС.

Администрирование систем, на которых размещен КИИСУ подсистема «Консолидация», КИИСУ BW - зеркало (базис): контроль, согласование и перенос транспортных запросов SAP, создание/изменение соединений между SAP системами, установка обновлений на серверное и клиентское программное обеспечение SAP, согласование и применение SAP нот, т.д.

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

2.2 Концептуальное проектирование

Разработка и согласование Проектных решений, Регламента взаимодействия участников сверки ВГО, Матрицы рисков и контрольных процедур и иной проектной документации в соответствии с разделом 4.11 Требования к документации», формирование запросов на предоставление информации.

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

Подготовка и согласование с заказчиком материалов принятия технических решений.

Расчет сайзинга необходимой памяти


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

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

Методологическая и процессная поддержка Исполнителя.

27


ЭТАП/ ФАЗА





1 2 3 4 5

SAP HANA и организационного роста на 5 лет.

продуктивной среде. Проектное управление. Коммуникационная поддержка проекта. Административная поддержка проекта:

o подготовка отчетов о статусе проекта (консолидация) для оперативного совета;

o организация и протоколирование рабочих встреч, заседаний, носящих постоянный характер в соответствии с Уставом.

Предоставление оборудования, лицензий, организация доступа.

Согласование протокола ландшафта разработки и тестирования (типы систем Dev, Test).

Этап 3 «Реализация. Опытная эксплуатация»

3.1 Разработка Настройка, разработка выгрузка данных из КИИСУ, инструмента сверки ВГО, в том числе разработка/модификация ФВД для сверки ВГО и консолидации финансовой отчетности.

Актуализация инструментов мэппингов и его наполнение на основании данных предоставленных Заказчиком.

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

Разработка и согласование актуализированной Матрицы рисков и контрольных процедур процесса сверки ВГО


Согласование проектных документов. . Методологическая и процессная поддержка

Исполнителя. Актуализация и адаптация методологии. Предоставление информации и тестовых

данных по ДЗО, участвующих в ОЭ, для формирования сценариев тестирования и проведения тестирования функционала.

Участие во внутреннем тестировании.


Экспертиза проектной технической, эксплуатационной документации

Архитектурная и экспертная поддержка проекта, в том числе:

o консультирование по вопросам технической архитектуры текущего решения и интеграции с ИС;

o экспертиза проектной документации, в том числе ее нормоконтроль.

Администрирование систем, на которых размещен КИИСУ подсистема

28


ЭТАП/ ФАЗА





1 2 3 4 5

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

Уточнение проектных документов, разработанных на фазе проектирования в соответствии с разделом 4.11 Требования к документации».

Разработка и согласование проектной документации в соответствии с разделом 4.11 Требования к документации».

Настройка ролей и полномочий. Настройка и разработка интеграции. Управление интеграционными

активностями на стороне ИС (ретракция данных).

Подготовка тестовых данных. Тестирование реализованного

функционала

«Консолидация», КИИСУ BW - зеркало (базис): контроль, согласование и перенос транспортных запросов SAP, создание/изменение соединений между SAP системами, установка обновлений на серверное и клиентское программное обеспечение SAP, согласование и применение SAP нот, т.д.

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

Проектное управление. Коммуникационная поддержка проекта. Административная поддержка проекта:


o организация и протоколирование рабочих встреч, заседаний, носящих постоянный характер в соответствии с Уставом.

3.2 Разработка эксплуатационной документации

Разработка эксплуатационной документации.

Согласование эксплуатационной документации.

3.3 Проведение тестирования функционала в предпродуктивной среде (функциональное, интеграционное, регрессионное, нагрузочное). Опытная эксплуатация.

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

Разработка и согласование с заказчиком проектных документов для проведения испытаний в соответствии с разделом 4.11 «Требования к документации».

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

Обучение проектной команды,

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

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

прохождения обучения, определение полномочий для обучения.

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

Прохождение обучения.

Предоставление инфраструктуры,

29


ЭТАП/ ФАЗА





1 2 3 4 5

ключевых пользователей работе в ИС. Техническая поддержка на этапах

тестирования на всех ее уровнях. Регистрация и устранение замечаний к

испытаниям, ведение реестра замечаний.

Настройка среды для проведения тестирования функционала в тестовой среде (Pre-Prod), перенос настроек и разработок. Проведение и поддержка тестирования

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

предложений, выявленных во время тестирования функционала в тестовой среде.

помещений для проведения испытаний. Выполнение тестирования функционала. Формирование замечаний к испытаниям;

. Методологическая и процессная поддержка

Исполнителя, пользователей, участвующих в тестировании.

Подготовка данных для проведения ОПЭ в соответствии с требованиями к их загрузке.

Этап 4. Опытно-промышленная эксплуатация

4.1 Подготовка данных для миграции

Формирование реестра потоков данных. Описание инструментов миграции

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

документации в соответствии с разделом 4.11 «Требования к документации».

Подготовка данных. Подготовка данных для мэппинга/

преобразования данных учетной подсистемы КИИСУ для их передачи в подсистему «Консолидация» КИИСУ.

Согласование проектных документов.

Предоставление оборудования и организация доступа Исполнителя работ и пользователей.


Экспертиза проектной технической, эксплуатационной документации

Архитектурная и экспертная поддержка проекта, в том числе:

o консультирование по вопросам технической архитектуры текущего решения и интеграции с ИС;

o экспертиза проектной документации, в том числе ее

4.2 Миграция данных Тестирование инструментов миграции данных, разработаны технические требования и форматы миграции данных.

Подготовка среды (Prod). Миграция данных в соответствии с

Согласование проектных документов. Определение владельцев данных. Подготовка и представление данных для

осуществления миграции данных. Проверка загруженных данных.

30


ЭТАП/ ФАЗА





1 2 3 4 5

требованиями и форматом миграции данных.

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

Разработка и согласование проектной документации в соответствии с разделом 4.11 «Требования к документации».

нормоконтроль. Обеспечение технической поддержки

пользователей во время тестирования – 1 линия и 2 линия технической поддержки.

Администрирование систем, на которых размещен КИИСУ подсистема «Консолидация», КИИСУ BW - зеркало (базис): контроль, согласование и перенос транспортных запросов SAP, создание/изменение соединений между SAP системами, установка обновлений на серверное и клиентское программное обеспечение SAP, согласование и применение SAP нот, т.д.

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

Проектное управление. Коммуникационная поддержка проекта. Административная поддержка проекта:


o организация и протоколирование рабочих встреч, заседаний, носящих постоянный характер в соответствии с Уставом

4.3 Обучение ключевых пользователей

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

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

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

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

Сбор анкет оценки обучения и предоставление сводных оценок.

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

Разработка и согласование проектной документации в соответствии с разделом 4.11 «Требования к документации».

Мобилизация ресурсов для проведения обучения.

Обучение ключевым методологическим основам.

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

Заполнение анкет для оценки результатов проведения обучения.


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

31


ЭТАП/ ФАЗА





1 2 3 4 5

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

обучения. Разработка план-графика обучения

конечных пользователей. Обучение конечных пользователей

методологическим основам ИС, работе в ИС.

Сбор анкет оценки обучения и предоставление сводных оценок.

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

Прохождение обучения. Заполнение анкет для оценки результатов

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

4.6 ОПЭ. Устранение выявленных ошибок, замечаний, реализация предложений

Сопровождение тестирования реализуемого функционала в рамках ОПЭ в продуктивной среде (3 –я линия технической поддержки).

Обработка обращений в соответствии с требованиями к ведению и обработке обращений в системе HelpDesk Заказчика.

Устранение замечаний к результатам работ этапа.

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

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

Разработка и согласование проектной

Обеспечение методологической и процессной поддержки пользователей при тестировании реализуемого функционала в ОПЭ.

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

Формулирование замечаний, предложений к реализованному функционалу, к проектной, эксплуатационной документации, фиксирование инцидентов при тестировании сверки ВГО в соответствии с требованиями к выставлению инцидентов, замечаний.

Анализ, согласование изменений проектной документации (при необходимости).

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

32


ЭТАП/ ФАЗА





1 2 3 4 5

документации в соответствии с разделом 4.11 «Требования к документации».

Выпуск необходимых методических и организационно-распорядительных документов, в том числе актуализация методики формирования консолидированной финансовой отчетности Группы АЛРОСА в соответствии с МСФО в части процесса сверки ВГО.


Стадия «Завершение»

Этап 5. «Закрытие проекта»

5.1 Передача в эксплуатацию Актуализация и согласование эксплуатационной документации (при необходимости).

Разработка и согласование Заявки на поддержку (с учетом актуализированного расчета сайзинга необходимой памяти SAP HANA и организационного роста на 5 лет) Итогового отчета.

Протокол опытно-промышленной эксплуатации системы.

Согласование актуализированной эксплуатационной документации (при необходимости).

Согласование Заявки на поддержку. Согласование Итогового отчета. Согласование Протокол опытно-

промышленной эксплуатации системы.

Экспертиза актуализированной эксплуатационной документации (при необходимости).

Экспертиза и согласование Заявки на поддержку, Итогового отчета.

Согласование Протокол опытно-промышленной эксплуатации системы.

По результатам перевода реализованного инструмента сверки ВГО в промышленную эксплуатацию со стороны Исполнителя предоставляется гарантийная поддержка в течение 1 года с момента подписания протокола опытно-промышленной эксплуатации системы

33

6.2 Требования к плану работ

Таблица 12Сроки реализации

ЭТАП РАБОТ СРОК РЕЗУЛЬТАТ

1 2 3

Стадия «Обоснование» Этап 1 «Подготовительные мероприятия. Закупочные процедуры»

Ноябрь 2019г. – Июнь 2020г.4

Материалы на ИК. Закупочная документация, в том числе ТЗ, требования

к Исполнителю работ, критерии отбора. Устав ИТ-проекта. План работ ИТ-проекта. Предложение по участию представителей Заказчика в

соответствии с планом работ.

Стадия «Реализация» Этап 2 «Концептуальное проектирование»

44 рабочих дня с даты подписания договора

Актуализация Устава ИТ-проекта. План работ ИТ-проекта. Предложение по участию представителей Заказчика в

соответствии с планом работ План коммуникаций. Проектные решения. Регламент взаимодействия участников сверки ВГО. Матрицы рисков и контрольных процедур. Функциональные требования к передаче данных из

учётных систем ДЗО в подсистему «Консолидация» КИИСУ.

Матрица доступа (Матрица функциональных ролей).

Стадия «Реализация» Этап 3 «Реализация. Опытная эксплуатация»

44 рабочих дня с даты завершения этапа 2

Техническая документация (Спецификация, описание настроек, ТЗ на разработку и т.д.).

Протокол выполненных настроек и разработок Актуализированная Методика. План и методика проведения испытаний. Протокол тестирования. Операционная инструкция. Руководство администратора. Руководства по обеспечению технической поддержки

и сопровождению системы. Протокол опытной эксплуатации (принятие решения о

готовности к проведению ОПЭ).

Стадия «Реализация» Этап 4 Опытно-промышленная эксплуатация

50 рабочих дней с даты завершения этапа 3

Обучающие материалы. Протоколы обучения пользователей. Протокол подключения и настройки прав доступа

пользователей. Протокол миграции данных. Адаптированная Методика. Протокол опытно-промышленной эксплуатации

системы.

Стадия «Завершение» Этап 5. «Закрытие проекта»

80 рабочих дней с даты завершения этапа 3

Запрос на поддержку. Итоговый отчет.

6.3 Порядок контроля и приемки результатов

6.3.1 Внутреннее тестирование на этапе «Реализация»

4 При условии защиты проекта на ИК и выделении финансирования в феврале 2020г.


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

выполняются следующие виды тестирования:

• функциональное тестирование;

• интеграционное тестирование;

• регрессионное тестирование.

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

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

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

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

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

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

Все выявленные ошибки при тестировании выгрузки из КИИСУ, инструмента сверки ВГО, также предложения по улучшению функционала (изначально не заявленного при обследовании и в проектных решениях) регистрируются со стороны Заказчика, пользователей в Реестре замечаний и предложений.

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

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

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

• группа 3: ошибки, которые не влияют на возможность выполнять процесс.

35


Исполнитель вносит изменения реализованный функционал и подтверждает их устранение со стороны тестировщиков

Устранение ошибок первой группы и подтверждение их устранения со стороны Заказчика, согласование с Заказчиком предложений по устранению замечаний групп 2 и 3 является условием перехода к ОЭ.

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

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

6.3.2 Опытная эксплуатация

Опытная эксплуатация (далее – ОЭ) проводится в предпродуктивной среде на продуктивных данных ДЗО (Приложение 1), готовых к моменту начала работ данного этапа (например, за 6 месяцев 2020г.). ОЭ проводится для проверки работоспособности созданной выгрузки данных из КИИСУ и инструмента сверки ВГО, определения соответствия согласованным проектным решениям, Регламенту взаимодействия участников сверки ВГО, Матрице рисков и внутренних контролей и принятия решения о его готовности к ОПЭ. Тестирование проводится проектной командой Исполнителя, пользователями со стороны Заказчика, включая специалистов со стороны ДЗО (Приложение 1) согласно Программе и методике испытаний. Опытная эксплуатация включает в себя процессы, модифицированные и реализованные в рамках данного ФТТ. ОЭ включает в себя функциональное, интеграционное, регрессионное, нагрузочное тестирование.

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

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

Все выявленные ошибки при тестировании выгрузки из КИИСУ, инструмента сверки ВГО, также предложения по улучшению функционала (изначально не заявленные при обследовании, в проектных решениях) регистрируются со стороны Заказчика, пользователей в Реестре замечаний и предложений. Исполнитель вносит изменения реализованный функционал и подтверждает их устранение со стороны тестировщиков.

Все ошибки и замечания классифицируются на три группы:

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

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

36


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

• группа 3: ошибки, которые не влияют на возможность выполнять процесс.

Устранение ошибок первой группы и подтверждение их устранения со стороны Заказчика, согласование с Заказчиком предложений по устранению замечаний групп 2 и 3 является условием перехода к ОПЭ.

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

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

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

6.3.3 Опытно-промышленная эксплуатация

ОПЭ проводится для определения готовности реализованных выгрузки данных из КИИСУ и инструмента сверки ВГО к промышленной эксплуатации, оценки и подтверждения достижения сокращения длительности сверки ВГО за счет автоматизации и оптимизации. ОПЭ проводится на фактических данных за 9 месяцев 2020г. по периметру ДЗО, представленного в Приложении 1, в продуктивной среде. В объем ОПЭ входит также поддержание продуктивной загрузки фактических данных и их сверки за январь 2021г.

В процессе ОПЭ определяется:

• соответствие системы функционально-техническим требованиям;

• соответствие проектной и эксплуатационной документации функционально-техническим требованиям;

• готовность пользователей к работе с реализованным инструментом сверки ВГО, выгрузки данных из КИИСУ для сверки ВГО и консолидации финансовой отчетности;

• готовность сопровождения системы Заказчиком.

ОПЭ проводится в соответствии с Программой и методикой испытаний на соответствие требованиям по функционалу, разрабатываемой Исполнителем. По результатам проведения ОПЭ комиссия в составе представителей Исполнителя и Заказчика составляет Протокол опытно-промышленной эксплуатации системы с решением приемочной комиссии о готовности реализованного инструмента сверки ВГО к промышленной эксплуатации. Протокол согласуется ответственными лицами и утверждается Куратором проекта.

6.3.4 Критерии приемки результатов испытаний:

Критериями успешного завершения каждого этапа испытаний являются:

• в рамках ОЭ:o отсутствие критичных замечаний, не позволяющих перейти к следующему этапу

испытаний или влияющих на начало ОПЭ;

37


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

• в рамках ОПЭ:o отсутствие критичных замечаний, не позволяющих перейти в постоянную

эксплуатацию;o Протокол опытно-промышленной эксплуатации системы, утвержденный Куратором

проекта.

38


Приложение 1. Организационный объем проекта

Таблица 13Организационный объем проекта

№ НАИМЕНОВАНИЕ ОБЩЕСТВА УЧЕТНАЯ СИСТЕМА ПИЛОТНОЕ ОБЩЕСТВО

1 2 3 4

1.АК АЛРОСА (ПАО) SAP КИИСУ да

2. Гидрошикапа

нет

3.АО Вилюйская ГЭС-35 БП 3.0 нет

4.АО Алроса Лена БП 3.0 нет

5.АО Авиакомпания Алроса БП 2.0 нет

6.ООО Бриллианты Алроса БП 3.0 нет

7.АО Алмазы Анабара УПП 1.3 + РИБ 9 участков нет

8.ПАО Севералмаз УПП 1.3 + УАТ +ТОИР да

9.ООО Алроса Торг БП 3.0 нет

10.ООО Алроса Газ БП 3.0 нет

11.ООО Алроса Спецбурение5 БП 3.0 нет

12.ООО Алроса Охрана БП 2.0 нет

13.KIMANG LDA Luanda

нет

14.АО ИЦ Буревестник

УПП 1.3 в интеграции с Infor ERP + БИТ Финанс УУ

нет

15.ООО Алмаздортранс SAP КИИСУ да

16.ООО Якутская генерирующая компания5 БП 3.0 нет

17.ООО Алмазный НТЦ БП 3.0 нет

18.ООО Алроса Бизнес Сервис5 SAP КИИСУ нет

19. Зарница БП 3.0 нет

20. ООО Якутская электросетевая компания5 БП 3.0 нет

5 Входит в организационный периметр проекта 1С: Учет ДЗО, в рамках которого запланирован в 2021г.перевод казначейства, бухгалтерского, налогового, управленческого учетов на корпоративную информационную систему на базе продуктов 1С.

39


21.ООО Аэропорт Мирный SAP КИИСУ нет

22.ООО ПТВС5 БП 3.0 (Лаборатория С) да

23. Прометей БП 3.0 нет

24.ООО «Ведомственная охрана АЛРОСА»

нет

25.ООО «АЛРОСА ИТ»5 SAP КИИСУ

нет

26.ПО КРИСТАЛЛ

нет

27. ООО "Ювелирная группа "Смоленские бриллианты"

нет

28.СГГК Терра SAP КИИСУ нет

40


Приложение 2. Процесс сверки ВГО «как есть»

41


Приложение 3. Пример типовых расхождений

Пример типовых расхождений

Доначисление расходов контрагентуВозврат денег на расчётный счет компанииДоначисление процентных расходовПередача основных средствСторнирование путевок ОК Прометей

42

Documents

Ÿрил.1-ФТТ.docx · Web view2020-02-12 · Опытная эксплуатация (далее – ОЭ) проводится в предпродуктивной среде