Лот №1 Технические и ... · Стр. 1 Приложение №2 к...

Стр. 1

Приложение №2

к документации о запросе предложений

от 21.02.2013 № 08-04-0353

на поставку товара и оказание услуг

по адресу: г. Липецк, пр.Победы, 87 а

Лот №1

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

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

электроэнергии и расчетов с потребителями для нужд

ОАО «Липецкая энергосбытовая компания»

РАЗДЕЛ I. ОБЩИЕ ПОЛОЖЕНИЯ ............................................................... 4

1. Введение ........................................................................................................... 4

2. Общие сведения .............................................................................................. 4

2.1. Полное наименование работ и их условное обозначение ............ 4

2.2. Сокращения и обозначения ............................................................. 4

2.3. Границы применимости документа ................................................ 5

РАЗДЕЛ II. НАЗНАЧЕНИЕ И ЦЕЛИ ПРОВЕДЕНИЯ РАБОТ .................. 6

1. Основная цель Проекта ................................................................................ 6

2. Основное назначение Системы ................................................................... 6

3. Основные функции Системы ....................................................................... 6

РАЗДЕЛ III. КОМПЛЕКТНОСТЬ ПОСТАВКИ И СОСТАВ РАБОТ ........ 8

1. Состав работ .................................................................................................. 8

2. Необходимая функциональность ................................................................ 9

3. Состав комплекта поставки ....................................................................... 9

РАЗДЕЛ IV. ОБЩИЕ СВЕДЕНИЯ ОБ ОБЪЕКТЕ ....................................... 10

1. Организационная структура общества .................................................. 10

2. Основные виды деятельности ................................................................... 10

3. Дополнительные виды деятельности ..................................................... 10

РАЗДЕЛ V. ТРЕБОВАНИЯ К СИСТЕМЕ .................................................... 11

1. Общие требования к Системе ................................................................... 11

2. Требования к составу решаемых задач .................................................... 12

Стр. 2

3. Требования к автоматизации ведения взаимоотношений с

абонентами .................................................................................................. 12

4. Требования к личному кабинету (ЛКК) .................................................... 14

5. Требования к автоматизации сбора данных о фактическом

потреблении ................................................................................................. 18

6. Требования к автоматизации интегрального и интервального

биллинга ........................................................................................................ 19

7. Требования к автоматизации выставления финансовых

документов ................................................................................................... 22

8. Требования к автоматизации учета поступивших оплат .................. 23

9. Требования к автоматизации управлению дебиторской

задолженностью ......................................................................................... 24

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

компании (КПЭ)........................................................................................... 25

11. Требования к составу выходных форм и отчетов ................................ 26

РАЗДЕЛ VI. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО

РАЗРАБОТКЕ И ВНЕДРЕНИЮ СИСТЕМЫ ................................................ 29

1. Организация контроля хода выполнения работ .................................... 29

2. Требования к ИАС ........................................................................................ 29

3. Требования к нормативно-справочной информации (НСИ) ................ 29

4. Требования к интеграции с другими системами .................................... 30

5. Требования к проведению приемки работ ............................................... 30

6. Рекомендации по срокам выполнения работ .......................................... 30

РАЗДЕЛ VII. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО

МИГРАЦИИ ДАННЫХ ...................................................................................... 31

РАЗДЕЛ VIII. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ И ЗАЩИТЕ

ИНФОРМАЦИИ ................................................................................................... 32

1. Требования по безопасности ...................................................................... 32

2. Требования к защите информации от несанкционированного

доступа. ........................................................................................................ 32

РАЗДЕЛ IX. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ ПОДГОТОВКИ

ПОЛЬЗОВАТЕЛЕЙ К ЭКСПЛУАТАЦИИ СИСТЕМЫ .............................. 34

1. Категории пользователей .......................................................................... 34

2. Направления подготовки администратора приложений .................... 34

3. Направления подготовки разработчика приложений .......................... 34

4. Направления подготовки конечных пользователей .............................. 34

5. Направления подготовки бизнес - аналитиков ...................................... 34

Стр. 3

6. Аттестация пользователей ...................................................................... 35

РАЗДЕЛ X. ТРЕБОВАНИЯ К ОКАЗАНИЮ ТЕХНИЧЕСКОЙ

ПОДДЕРЖКИ ....................................................................................................... 36

РАЗДЕЛ XI. ТРЕБОВАНИЯ К СОПРОВОЖДЕНИЮ СИСТЕМЫ .......... 37

РАЗДЕЛ XII. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

РЕЗУЛЬТАТОВ РАБОТЫ .................................................................................. 38

РАЗДЕЛ XIII. ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ ......................... 39

1. Требования к информационному обеспечению ....................................... 39

1.1. Требования к составу, структуре и способам организации

данных в системе ............................................................................ 39

1.2. Требования по использованию систем управления базами

данными (СУБД)............................................................................. 39

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

3. Требования к программному обеспечению ............................................... 40

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

3.4. Требования к масштабируемости: ................................................ 40

3.5. Требования к системному программному обеспечению ............ 41

3.6. Требования к каналам связи .......................................................... 41

3.7. Требования к обновлению версий лицензионного

программного обеспечения ........................................................... 41

3.8. Требования к рабочим станциям и серверам ............................... 41

Стр. 4

РАЗДЕЛ I. ОБЩИЕ ПОЛОЖЕНИЯ

1. Введение

1.1. Целью настоящего Технического задания является определение требований к работам по

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

расчетами с потребителями ОАО «ЛЭСК» на базе программного обеспечения Oracle

CC&B, физическими и юридическими лицами, а также необходимых стадий и этапов ра-

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

присылаемых на открытый запрос предложений.

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

2.1. Полное наименование работ и их условное обозначение

Создание и внедрение автоматизированной системы управления сбытом электроэнергии и

расчетами с потребителями ОАО «ЛЭСК» (далее – АСУ СЭРП или Система) на базе программно-

го обеспечения Oracle Utilities Customer Care and Billing (далее - Платформа).

2.2. Сокращения и обозначения

Ниже приводятся термины и акронимы (аббревиатуры), используемые в настоящем доку-

менте.

Компания, Заказчик – ОАО «ЛЭСК»

Исполнитель – Участник открытого запроса предложений, предложивший в своей заявке

наилучшие условия выполнения договора;

Платформа - программное обеспечение Oracle Utilities Customer Care and Billing

Нормативный документ – принятый в установленном порядке документ, устанавливающий

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

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

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

иные документы;

НСИ – нормативно-справочная информация;

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

тельностью и расчетами с потребителями ОАО «ЛЭСК»

АСУ СЭРП, Система – автоматизированной системы управления сбытовой деятельностью и

расчетами с потребителями ОАО «ЛЭСК»;

ОС – операционная система;

ИАС – информационно-аналитическая система;

СУБД – система управления базами данных;

ТРП – технический рабочий проект;

ТЗ – техническое задание;

НИОКР – научно-исследовательские и опытно-конструкторские разработки;

ЦОД – центр обработки данных;

ЦОК – центр обслуживания клиентов;

АРМ – автоматизированное рабочее место;

КИС – корпоративная информационная система;

ПК – программный комплекс;

АСКУЭ – автоматизированная система коммерческого учета электроэнергии;

ЭСО – энергосбытовая организация;

Стр. 5

2.3. Границы применимости документа

Настоящий документ описывает требования к работам по разработке и внедрению АСУ

СЭРП. Технические требования являются основным документом в комплекте тендерной доку-

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

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

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

Основанием данных Технических требований являются требования, сформулированные в

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

Стр. 6

РАЗДЕЛ II. НАЗНАЧЕНИЕ И ЦЕЛИ ПРОВЕДЕНИЯ РАБОТ

1. Основная цель Проекта

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

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

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

комплексную и интегрированную поддержку деятельности подразделений Компании и обеспечи-

вают прозрачность деятельности ОАО «ЛЭСК» для руководства, инвесторов и для общества в це-

лом, за счет:

• Создания современной и эффективной системы управления энергосбытовой дея-

тельностью ОАО «ЛЭСК»;

• Централизации информационных потоков и оптимизация процессов формирования

отчетности;

• Сокращения операционных издержек и повышения производительности труда;

• Снижения дебиторской задолженности;

• Повышения конкурентоспособности за счет гибких условий обслуживания потреби-

телей;

• Автоматизации работы с контрагентами;

• Повышения финансовой прозрачности;

• Повышения инвестиционной привлекательности компании.

• Улучшение бизнес-процессов Компании с учетом передовых стандартов бизнес-

процессов.

2. Основное назначение Системы

Основное назначение Системы – автоматизация бизнес-процессов ОАО «ЛЭСК», включая:

• Автоматизацию бизнес-процессов подразделений ОАО «ЛЭСК»;

• Автоматизацию взаимодействия с потребителями физическими и юридическими ли-

цами;

• Автоматизацию взаимодействия со сторонними системами и организациями.

3. Основные функции Системы

Основные функции Системы – автоматизация бизнес-процессов ОАО «ЛЭСК», включая:

• Ведение истории взаимоотношений с потребителями физическими и юридическими

лицами;

• Сбор данных о фактическом потреблении;

• Интегральный и интервальный биллинг;

• Формирование финансовых документов;

• Прием и учет платежей;

• Управление дебиторской задолженностью;

• Формирование консолидированной отчетности о деятельности предприятия;

• Расчеты с сетевыми организациями;

• Расчеты по дополнительным видам услуг.

2. Объектами автоматизации Системы являются следующие подразделения Компании:

• Аппарат управления ОАО «ЛЭСК»

• ЦОК ОАО «ЛЭСК»

Липецкий участок сбыта электроэнергии

Елецкий участок сбыта электроэнергии

Стр. 7

Лебедянский участок сбыта электроэнергии

Грязинский участок сбыта электроэнергии

Добровский участок сбыта электроэнергии

Добринский участок сбыта электроэнергии

Усманский участок сбыта электроэнергии

Долгоруковский участок сбыта электроэнергии

Воловский участок сбыта электроэнергии

Измалковский участок сбыта электроэнергии

Задонский участок сбыта электроэнергии

Тербунский участок сбыта электроэнергии

Становлянский участок сбыта электроэнергии

Хлевенский участок сбыта электроэнергии

Данковский участок сбыта электроэнергии

Краснинский участок сбыта электроэнергии

Лев-Толстовский участок сбыта электроэнергии

Чаплыгинский участок сбыта электроэнергии

Стр. 8

РАЗДЕЛ III. КОМПЛЕКТНОСТЬ ПОСТАВКИ И СОСТАВ РАБОТ

Участник открытого запроса предложений должен предоставить технико-коммерческое

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

и внедряемой Системы на базе программного обеспечения Oracle CC&B, календарный план вы-

полнения работ по созданию и внедрению Системы -, пример регламента сопровождения. При

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

сроков до отдельных этапов.

1. Состав работ

Для создания и внедрения АСУ СЭРП необходимо выполнить следующие работы 1. Анализ существующих функций и бизнес-процессов;

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

тиками и стандартами обслуживания;

3. Согласование новой модели деятельности компании;

4. Формирование и первоначальное наполнение НСИ;

5. Разработка документации по ведению и сопровождению НСИ;

6. Настройка согласованной новой модели деятельности в программном обеспечении Oracle

CC&B;

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

гласованной модели и текущему законодательству (доработка интерфейсов, процедур расчетов

и начислений и т.д.);

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

боток;

9. Миграция данных из ранее действующих Систем автоматизации деятельности по работе с

абонентами. Работа должна быть выполнена в полном объеме самостоятельно Исполнителем,

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

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

интерфейс для доступа к этим данным из новой Системы автоматизации, после вывода из экс-

плуатации существующих систем;

10. Интеграция АСУ СЭРП со смежными системами автоматизации ОАО «ЛЭСК» (Call-центр,

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

тема управления электронной очередью). Интеграция должна быть выполнена в полном объе-

ме самостоятельно Исполнителем, без привлечения к данным работам специалистов Заказчи-

ка;

11. Интеграция АСУ СЭРП с системой автоматизации бухгалтерии на базе ПО 1С 8.2 УПП (толь-

ко со стороны Oracle CC&B);

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

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

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

интерфейса и процедур расчетов и начислений);

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

утвержденной новой модели работы компании;

14. Проведение групповых обучений ключевых специалистов и представителей участков по ис-

пользованию новой Системы;

15. Техническая поддержка Системы до момента передачи в промышленную эксплуатацию.

Стр. 9

2. В системе должна быть реализована следующая функциональность:

1. Ведение истории взаимоотношений с потребителями физическими и юридическими лицами;

2. Сбор данных о фактическом потреблении в ручном и автоматическом режиме;

3. Учет и разнесение платежей (в ручном и автоматическом режимах);

4. Управление дебиторской задолженностью (в том числе автоматизированный контроль и гене-

рация событий);

5. Исковая деятельность (по задолженностям абонентов)

6. Интегральный и интервальный биллинг;

7. Расчеты по дополнительным видам услуг;

8. Формирование финансовых документов (книга покупок и продаж, счета, счета-фактуры);

9. Личный кабинет клиента ( с интеграцией с платежными online системами);

10. Централизации информационных потоков и оптимизация процессов формирования отчетности

в целом по компании;

11. Управление консолидированной отчетностью о деятельности компании в целом;

12. Сверки и взаиморасчеты со смежными организациями – поставщиками услуг (, ОРЭ, сетевые

компании, ИКУ и т.д.);

13. Бизнес-аналитика, показатели деятельности компании и информационные панели руководите-

лей;

3. Состав комплекта поставки

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

2. документация по ведению НСИ;

3. разработанная и внедренная ИАС;

4. интеграция АСУ СЭРП с СЭД «Директум»;

5. услуги по разработке документации, формированию, первоначальному наполнению, ведению

и сопровождению НСИ;

6. услуги по разработке и внедрению ИАС;

7. услуги по интеграции АСУ СЭРП с другими системами;

8. миграция данных из ранее действующей Системы.

9. услуги по подготовке специалистов Компании по использованию АСУ СЭРП;

10. услуги по организации семинаров и проведению обучения по использованию программного

обеспечения;

11. подготовка специалистов Компании по использованию АСУ СЭРП;

Стр. 10

РАЗДЕЛ IV. ОБЩИЕ СВЕДЕНИЯ ОБ ОБЪЕКТЕ

1. Организационная структура общества

В состав ОАО «ЛЭСК» входят подразделения: аппарат управления,

18 участков сбыта, 1 центр обслуживания клиентов.

2. Основные виды деятельности

Основными видами деятельности компании являются:

поставка (продажа) электрической энергии по установленным тарифам в соответствии

с диспетчерскими графиками электрических нагрузок;

получение (покупка) электрической энергии с оптового рынка электрической энергии;

оказание услуг энергоснабжающим организациям по реализации электроэнергии;

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

ским лицам;

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

занные коммунальные услуги;


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

3. Дополнительные виды деятельности

Дополнительными видами деятельности компании являются:

продажа, установка и ремонт электросчетчиков любой классификации;

Стр. 11

РАЗДЕЛ V. ТРЕБОВАНИЯ К СИСТЕМЕ

1. Общие требования к Системе

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

ческим лицам в единой информационной Системе;

1.2. Система должна обеспечивать соответствие форм документов, отчетов, бизнес-процессов

текущим требованиям законодательства и внутренних Регламентов в рамках согласованно-

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

жении Проекта.

1.3. Обеспечение повышения эффективности деятельности ОАО «ЛЭСК» за счет применения

лучшей практики интеграции бизнес-процессов и современных информационно-

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

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

сти ОАО «ЛЭСК» для руководства, инвесторов и для общества в целом;

1.4. Повышение надежности и обеспечение единства хранения и ввода информации;

1.5. Использования информационного массива для принятия решений в производственных

процессах Компании;

1.6. Доступный в любом подразделении инструмент для ввода информации по объектам учета;

1.7. Интерфейс вывода данных, который позволит пользователю получить информацию, кон-

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

быточно (по принципу «разумной достаточности»);

1.8. Отсутствие дублирования ввода одинаковой информации в рамках единого информацион-

ного пространства;

1.9. Централизованное ведение НСИ в рамках единого информационного пространства компа-

нии в соответствии с едиными принципами целостности и непротиворечивости данных;

1.10. Разграничение зоны ответственности пользователей и подразделений компании;

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

открытости ее архитектуры;

1.12. Система должна обеспечивать работу следующих категорий пользователей:

бизнес-аналитик;

конечный пользователь;

администратор приложений;

разработчик приложений;

1.13. Система должна обеспечивать разграничение доступа к информации и защиту информа-

ции от несанкционированного доступа на основе механизмов назначения прав;

1.14. В комплекте с Системой должна поставляться документация, описывающая средства и ме-

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

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

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

ваться на использовании системных (ОС, СУБД) средствах защиты от аварий и отдельных

сбоев;

1.15. Система должна обеспечивать ведение протокола выполнения операций по вводу и моди-

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

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

время выполнения операции;

1.16. Система должна допускать возможность ввода данных и команд множеством разных спо-

собов (клавиатура, мышь) и многовариантность доступа к еѐ функциям (например, спомо-

Стр. 12

щью текстовых и графических ссылок, «горячих клавиш», элементов меню). Кроме того, в

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

режиму.

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

ципов (в рамках отдельных подсистем):

единство базовых текстовых, цветовых и графических обозначений;

однотипный интерфейс навигации по экранным формам;

обеспечение многооконного режима.

2. Требования к составу решаемых задач

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

следующих задач в рамках основной деятельности ОАО «ЛЭСК»:

Ведения истории взаимоотношений с потребителями физ. и юридическими лицами;

Сбор данных о фактическом потреблении;

Интегральный и интервальный биллинг:

Расчеты по дополнительным видам услуг;

Формирование финансовых документов;

Учет и разнесение платежей;

Управление дебиторской задолженностью;

Формирование отчетности:

формирование управленческой отчетности в разрезе структурных подразделений

компании;

формирование управленческой отчетности по контролируемым потребителям;

формирование оперативной отчетности в рамках подразделений, определенных в

организационном объеме проекта;

формирование отчетов, определенных регламентом вышестоящего руководства,

определенного формата и содержания;

формирование отчетов, требования к которым меняются, в зависимости от потреб-

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

2.2. Конфигурация Системы должна позволять постепенное наращивание функциональности

системы.

3. Требования к автоматизации ведения взаимоотношений с абонентами

3.1. Ведение договорной работы, управление договорами (основной договор, дополнительное

соглашение и др.)

Инициирование и подготовка проекта договора

Ведение единой базы договоров с отражением в ней видов, типов, параметров и других

классификаций заключаемых договоров

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

3.3. Учет и ведение данных по абонентам и условиям их обслуживания с ведением всей ин-

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

3.4. Наличие информационного портала лицевого счета абонента с отображением информации

для работы с потребителем;

3.5. Управление взаимоотношениями с потребителями в течение жизненного цикла работы с

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

Стр. 13

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

договора;

3.6. Ведение и хранение истории лицевого счета и взаиморасчетов с потребителями;

3.7. Регистрация договоров об обслуживании с ведением соответствующих разделов договоров

об обслуживании (РДО);

3.8. Функциональность контакт-центра по обслуживанию потребителей:

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

3.10. Обеспечение доступа к необходимой информации для быстрого получения данных лице-

вого счета и договора об обслуживании;

3.11. Выдача предупреждений по состоянию лицевого счета, графиков выписки счетов, финан-

совых балансов и деталей лицевого счета;

3.12. Регистрация всех типов контактов с потребителями (телефон, лично, эл.почта, интернет) и

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

3.13. Автоматическая генерация необходимости контакта с потребителем (письма, напомина-

ния) при достижении необходимых условий, заданных для данного потребителя;

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

обслуживать потребителей со сложной структурой взаимосвязей субъектов, при которой або-

нент, плательщик и потребитель не совпадают:

3.14.1. Абонент, плательщик и потребитель являются разными лицами;

3.14.2. Потребитель с несколькими приборами учета;

3.14.3. Один прибор учета используется несколькими потребителями;

3.14.4. Потребитель, имеющий суб-абонентов, получающий общий счет и детализацию на-

числений отдельно по всем суб-абонентами.

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

суб-абонентам.

3.14.6. Потребитель, получающий общий счет за разные услуги.

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

жом.

3.14.8. Перевод независимого потребителя в суб-абоненты другого, зарегистрированного ра-

нее потребителя.

3.14.9. Перевод суб-абонента в независимого потребителя.

3.15. Предоставление потребителю защищенного удаленного доступа к текущей и исторической

информации по лицевому счету;

3.15.1. Баланс лицевого счета;

3.15.2. Наличие задолженности;

3.15.3. Параметры договора;

3.15.4. Тарифный план;

3.15.5. Выставленные счета;

3.15.6. Произведенная оплата;

3.16. Выполнение действий по данному лицевому счету;

3.16.1. Коррекция данных по лицевому счету и договору;

3.16.2. Ввод показаний приборов учета;

3.16.3. Оплата услуг;

3.16.4. Интеграция с платежными системами;

3.17. Обеспечение размещения web-приложения на сайте ОАО «ЛЭСК», в части, ориентирован-

ной на обслуживание потребителей.

Стр. 14

4. Требования к личному кабинету (ЛКК)

4.1. Назначение ЛКК

Основное предназначение ЛКК – предоставление клиентам розничного рынка интерактивного

доступа к информационным сервисам Компании.

В связи с потребностью постоянной адаптации данного канала обслуживания под потребно-

сти целевых групп клиентов особенно актуальны требования «одного окна», компактности, гибко-

сти, быстрого поиска информации, указанные в п. 4.2 «Интерфейс пользователя».

4.2. Сервисы ЛКК

4.2.1. Организация процедуры доступа клиента к ЛКК

Доступ клиентов к ЛКК производится через Web-доступ с использованием ссылки доступа с

главной страницы сайта Компании. Весь трафик, передаваемый между клиентом и ЛКК должен

шифроваться с использованием SSL сертификатов по протоколу TLS. При доступе в ЛКК клиент

должен видеть визуальное подтверждение защищенности сессии клиента при соединении с ЛКК

(подсветка адресной строки цветом, символ «замка» и пр.).

Идентификация (процедура распознавания абонента по его идентификатору) пользова-

теля в ЛКК производится с использованием предназначенного Идентификатора пользо-

вателя. В качестве Идентификатора пользователя для ФЛ используется номер лицевого

счета, для ЮЛ – номер договора. Идентификатор пользователя хранится в ЛКК в за-

шифрованном виде.

В ЛКК должна быть реализована процедура взаимной аутентификации (проверки под-

линности). Проверка подлинности Компании проводится путем вывода информации о

владельце SSL сертификата с возможностью проверки данных сертификата на сайте

выдавшей его организации. Аутентификация пользователя в ЛКК производится путем

ввода Пароля, который хранится в ЛКК в зашифрованном виде.

Механизм авторизации (получения прав пользователя в системе) в ЛКК должен ограни-

чивать доступ каждого пользователя ЛКК исключительно к «собственным» данным

(персональные данные абонента, его договор, лицевой счет, данные начислений и оплат

и пр.) и принципиально исключать возможность любого доступа пользователя ЛКК к

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

администраторов ЛКК, которые не должны иметь возможности доступа и изменения

данных других пользователей. После успешной авторизации пользователя в ЛКК про-

исходит поиск и подбор данных клиента в соответствии с введенным идентификатором.

Пользователи ЛКК должны иметь возможность самостоятельного изменения пароля

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

пользователь обязательно должен еще раз указать свой текущий пароль, в ходе проце-

дуры восстановления – пользователь получает по e-mail/SMS персональную ссылку на

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

пользователь должен ввести новый пароль, подтвердить его (в поле подтверждения ну-

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

«символы с картинки» (CAPTCHA). При желании пользователь ЛКК может также от-

править новый пароль на свои контактный e-mail и/или мобильный телефон (SMS).

Механизм назначения пароля новым пользователям должен предусматривать как воз-

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

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

ром ЛКК требованиям к безопасности паролей. Пример таких требований: «время жиз-

Стр. 15

ни» пароля, максимальная частота смены пароля, минимальная и максимальная длина

пароля, минимальные требования к безопасности пароля – использование букв / цифр /

специальных символов / неповторяемость последних N паролей, автоблокирование

учетной записи пользователя в ЛКК на заданный временной период при нарушении

правил ввода пароля с уведомлением администратора ЛКК.

Учетная запись пользователя в ЛКК должна автоматически создаваться при регистра-

ции в CRM данных договора/лицевого счета. Пароль нового пользователя ЛКК должен

автоматически генерироваться и пересылаться на зарегистрированные в CRM контакт-

ные e-mail и/или мобильные телефоны (SMS).

Администратор ЛКК должен иметь возможность задавать период времени, после кото-

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

4.2.2. Доступ к персональной информации

Просмотр данных абонентского учета, и договоров в частности:

информация по объекту обслуживания и абоненту (адрес объекта обслуживания,

наименование абонента, для ЮЛ дополнительно регистрационные данные и

банковские реквизиты, контактная информация (телефон, e-mail, факс), специ-

альные параметры – кол-во льготников, газовая/электроплита и пр.);

данные лицевого счета / договора (№, дата заключения), также желательно хра-

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

нений в условиях договора;

справочная информация по ТУ и ПУ абонента;

информация по действующим льготам и истории изменения льгот (пример - вид

льготы, период действия льготы, ФИО льготника, %/сумма льготы);

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

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

данных для поставки ЭЭ - вид услуги, название тарифа, период действия, кате-

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

измерения, величина тарифа).

Изменение контактной информации абонента (e-mail, факс, телефоны).

Прочая информация по абоненту должна изменяться через систему CRM сотрудниками

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

4.2.3. Работа с показаниями ПУ

Просмотр истории показаний (наименование ТУ, номер ПУ, дата регистрации показа-

ний, зона, показание, источник показаний: абонент, Компания, наименование сетевой

организации или компании-партнера - при получении показаний ПУ через третьи сто-

роны). Показания и источник должны выводиться на основании результатов процедуры

утверждения показаний для проведения.

Ввод текущих показаний ПУ. Автоматический контроль даты ввода, допустимых зна-

чений (текущие показания ПУ меньше предыдущих или очень отличаются на порядок)

и передача в CRM через механизм интеграции (с указанием источника «Введена або-

нентом»).

4.2.4. Просмотр информации о взаиморасчетах

Стр. 16

Просмотр данных (вид услуги/начисления, дата, сумма) о поступивших платежах за вы-

бранный период. (Платежи, временно не распределенные по видам услуг/начислениям,

также должны быть доступны для просмотра.)

Просмотр данных о фактических / плановых начислениях (вид услуги/начисления, пе-

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

Должна быть возможность просмотра дополнительной детализации по начислениям,

как пример, для услуг поставки ЭЭ: наименование ТУ, номер ПУ, тариф, показания ПУ

на конец периода (если есть), вид алгоритма расчета начислений (по ПУ, нормативам и

пр.), расход к начислению, ставка тарифа, учет льгот.

Просмотр существенных параметров дополнительных начислений (штрафы, пени и

пр.), как пример: период, ставка%, сумма начисления.

Текущий баланс – величина дебиторской/кредиторской задолженности на текущую да-

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

полненных на основании других данных из ЛКК (Текущий баланс = Баланс на начало

периода – Начисления за период + Оплаты за период).

4.2.5. Выставление документов начисления / оплаты

Печать заранее сформированных документов начисления (акты, счета-фактуры) и опла-

ты (счета, квитанции) на основании данных из БС (см. п.Ошибка! Источник ссылки

не найден. «Ошибка! Источник ссылки не найден.»), полученных через механизмы

интеграции.

Формирование новых документов оплаты на основании выбранного метода расчета: по-

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

ных извещений (плановые начисления). При выборе расчета по показаниям ПУ у поль-

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

формирования документов оплаты.

Указанные документы формируются исключительно в БС, передаются обратно в ЛКК

через механизмы интеграции. В системе БС должен быть реализован отдельный меха-

низм, сопоставляющий данные запроса пользователя ЛКК на формирование документов

оплат с уже подготовленными документами и автоматически аннулирующий «лишние»

документы по заданным правилам.

Возможность отправки документов оплаты на контактный e-mail с использованием ме-

ханизмов рассылки CRM (через механизмы интеграции).

4.2.6. Оплата on-line

On-line оплата платежной банковской картой или через подключенные системы элек-

тронных платежей (QIWI-кошелек, Yandex-деньги, Web-money и пр.).

4.2.7. Регистрация и отслеживание истории заявок и обращений

Основные функции:

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

речня услуг. Каждый вид услуги должен поддерживать ведение набора общих и специ-

фических параметров, определяющих ее характеристики. Пример видов услуг: продажа

ПУ ЭЭ, установка ПУ ЭЭ, замена ПУ ЭЭ, установка ПУ расхода воды, энергосервис,

энергоаудит, продажа страховок, продажа кондиционеров, изменение персональных

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

контактный e-mail информационное письмо с описанием содержания сформированной

Стр. 17

заявки и сопутствующей информацией (ответственный со стороны компании, плановые

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

Отслеживание изменения статусов обработки заявок и результатов работ по заявкам не-

посредственно в ЛКК.

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

кам с последующим получением уведомлений на контактный адрес e-mail и/или теле-

фон (SMS).

4.2.8. Обратная связь

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

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

работы подразделений Компании, предложения по расширению функционала ИС Ком-

пании (ЛКК, Контакт-центр) и пр. По окончании процедуры регистрации обращения

клиент получает на свой контактный e-mail информационное письмо с текстом сделан-

ного обращения и сопутствующей информацией (ответственный со стороны компании,

плановые сроки ответа на обращения, рекомендуемые действия и пр.).

Возможность отслеживания обращений и ответов на них непосредственно в ЛКК.

Подписка на получение информации о результатах рассмотрения обращения на кон-

тактный адрес e-mail и/или телефон (SMS).

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

– см. Ошибка! Источник ссылки не найден. «Ошибка! Источник ссылки не най-

ден.».

4.2.9. Информационный обмен

Общие новости Компании (изменения в перечне предоставляемых услуг и их парамет-

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

разделений и пр.).

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

Справочно-нормативная информация по тематике.

Регламенты и процедуры: заключение договоров, предоставление показаний ПУ, про-

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

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

Подписка новостные и информационные рассылки Компании согласно структуриро-

ванному рубрикатору с периодическим получением на контактный e-mail краткого опи-

сания и ссылок на тематические статьи.

Стр. 18

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

5.1. Фиксация данных о каждом месте обслуживания или адресе, обслуживаемом энергосбы-

товой компанией как “объекте обслуживания”;

5.2. Ведение электронной «картотеки» помещений юридических лиц-объектов обслуживания

ОАО «ЛЭСК» с ведением необходимых данных по зданию или помещению;

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

однозначной идентификации помещения в базе данных и проведения расчетов по на-

числениям;

5.3.1. Узлы (станции, подстанции, КТП, ТП и т.д.)

5.3.2. Секции шин

5.3.3. Присоединения

5.3.4. Измерительные комплексы

5.3.5. Устройства сбора и передачи данных (УСПД)

5.4. Ведение географических данных;

5.5. Ведение для специальных и социальных объектов обслуживания требований обеспечения

жизнедеятельности;

5.6. Обеспечение ведения неограниченного числа точек учета для одного объекта обслужива-

ния, в которых непосредственно предоставляется услуга;

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

ных потребителей и суб-абонентов;

5.8. Конфигурирование связи точки учета с несколькими договорами об обслуживании для

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

лицевые счета;

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

живания потребителя;

5.10. Обработка всех запросов потребителей, обеспечение организации и контроля выполне-

ния заказов на проведение работ;

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

объектах обслуживания потребителей;

5.11.1. Установка прибора учета;

5.11.2. Снятие прибора учета;

5.11.3. Поверка прибора учета;

5.11.4. Замена прибора учета;

5.11.5. Подключение и отключение услуги;

5.11.6. Проведение инструментальных обследований;

5.12. Создание запросов массовых подключений и обновления данных по объектам обслужи-

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

тры);

5.13. Проверка статусов лицевых счетов всех нежилых помещений здания;

5.14. Поддержка различных типов приборов учета электроэнергии (одно-, двух-тарифные и

прочие типы приборов учета электроэнергии);

5.15. Регистрация и ведение данных по приборам учета;

5.15.1. Место установки прибора учета;

5.15.2. Тип прибора учета и его характеристики;

5.15.3. Применяемый тариф;

5.15.4. Данные для расчета фактического потребления;

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

Стр. 19

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

5.17. Автоматизированный ввод показаний потребления из файлов;

5.18. Автоматическая выгрузка показаний потребления в файл;

5.19. Поддержка ручного ввода показаний приборов. Портал ввода показаний приборов учета

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

ров учета в соответствии с маршрутным листом;

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

карманных персональных компьютеров;

5.21. Управление ответственными контролерами за снятие показаний с приборов учета и

планирование контрольных обходов;

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

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

5.23. Регистрация информации об источнике данных о показаниях приборов учета (дата сня-

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

АИИСКУЭ, комментарии потребителей и т.п.);

5.24. Уточнение данных показаний приборов учета до выставления счета;

5.25. Внесение записей, корректирующих сумму начислений, и учет корректировки сумм при

следующем выставлении счета в период, когда счет уже выставлен;

5.26. Проверку корректности значений показаний при вводе на непротиворечивость и макси-

мальное и минимальные значения;

5.27. Автоматическое обнаружение ошибок по заданному в алгоритме проверки параметру

(проверка мин-макс, отрицательное или нулевое потребление, переход через «0», срав-

нение с профилем и т.д.) с ведением протокола ошибок и фиксацией типа ошибки;

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

6. Требования к автоматизации интегрального и интервального биллинга

6.1. Всесторонняя обработка данных потребления, работа с различными коэффициентами

преобразования (факторами биллинга) и единицами измерений, с приведением различ-

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

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

ряемым потреблением;

6.3. Расчет начислений по однократным начислениям и сборам, (например, оплата услуг за

подключение, повторное подключение, штрафы, пени);

6.4. Расчет начислений для сложных планов расчета и многокомпонентных тарифов;

6.5. Поддержка сложных расчетных планов с комбинацией фиксированных платежей, плате-

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

чений потребления, налогов, скидок и т.д.;

6.6. Расчет общих начислений, начислений на основе тарифов за единицу измерения величи-

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

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

6.7. Расчет начислений по внутренним тарифам, внешним данным потребления и с использо-

ванием внешних тарифов для обеспечения сквозного и многостороннего биллинга;

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

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

гих действий, включая корректировки и отмены;

6.9. Выполнение расчетов объемов потребления на основании показаний приборов учета;

Стр. 20

6.10. Выполнение расчетов объемов потребления балансовым методом с возможностью гиб-

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

той схеме потребления;

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

типов показаний в течение расчетного периода в зависимости от причины наличия

множественных показаний (замена прибора учета в течение месяца, кража прибора уче-

та, расчета по нормативам и т.п.);

6.12. Выполнение расчета на основании нормативов потребления, договорных величин;

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

ний приборов учета в расчетный период (на основании среднесуточного расхода, по ус-

тановленной мощности, по максимальной нагрузке и т.д.);

6.14. Формирование авансовых начислений на основании нормативов потребления и факти-

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

цента авансовых платежей;

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

ства;

6.16. Предварительный расчет начислений/сторнирования с возможностью последующего

удалением результатов расчетов;

6.17. Автоматический запуск расчет и хранение значений величины начислений по событию

ввода показания прибора учета за расчетный период при внесении показаний приборов

учета как оператором в ручном режиме, так и при использовании интерфейса управле-

ния энергоданными;

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

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

(оператором в диалоговом режиме или через автоматизированный интерфейс с систе-

мой АИИСКУЭ);

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

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

потребления;

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

при использовании нормативов потребления при наступлении даты расчета;

6.21. Ручное и автоматическое утверждение результатов расчетов, как в единичном, так и

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

6.22. Ведение истории результатов расчета;

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

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

базу данных только разницы между уже рассчитанным значением и результатом пере-

расчета, в случае закрытого периода;

6.24. Ведение групп тарифов и планов расчетов для разных групп потребителей и видов ус-

луг;

6.25. Ведение истории изменения тарифов и обеспечение формирования расчетов начислений

за периоды действия этого предыдущего значения при отсутствии ограничений на ко-

личество хранимых значений в истории тарифа;

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

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

личными объемными величинами в рамках одной услуги для различных алгоритмов

расчетов в рамках одного плана расчета;

Стр. 21

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

оказания услуги;

6.28. Поддержка расчетов начислений в зависимости от параметров предоставляемой услуги;

6.29. Классификация / сортировка тарифов и планов расчета по критериям применимости по

отношению к услуге, группе потребителей, принадлежности к территориальной или ор-

ганизационной единицы и т.д.;

6.29.1. Уровень напряжения

6.29.2. Регулируемый, нерегулируемый, составляющие регулируемого тарифа

6.29.3. Дифференциация по числу часов использования мощности

6.29.4. Дифференциация по величине максимальной мощности

6.29.5. Мощность, электроэнергия, электроэнергия приобретаемая в целях компенсации

потерь.

6.29.6. Тарифы за ограничение (отключение) подачи электроэнергии

6.29.7. Прочие.

6.30. Создание и ведение групп тарифов и планов расчета;

6.31. В части расчетов за электроснабжение - функция расчетов потребления и формирования

начислений;

6.31.1. «Расход по прибору учета (ПУ)»: значение вычисляется по показаниям прибора

коммерческого учета;

6.31.2. «Постоянный расход»: значение вычисляется по постоянной величине;

6.31.3. «Алгоритм расчета»: значение вычисляется из значений других параметров, по

введенной формуле;

6.31.4. «Долевой расход»: значение вычисляется как часть значения другого параметра

в соответствии с введенной процентной величиной.

6.32. В части расчетов за дополнительные услуги функция ведения тарифов и расчетов на-

числений;

6.33. Расчет начислений для различных типов услуг (по способу расчета начислений);

6.33.1. Услуг с фиксированной ценой за определенный период времени (день, месяц,

год);

6.33.2. Услуг, стоимость которых зависит от объема потребления, с фиксированной це-

ной за единицу потребления;

6.33.3. Услуг с фиксированной ценой за оказание услуги – разовых услуг;

6.33.4. Услуги купли-продажи с фиксированной ценой за единицу товара;

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

6.35. Ведение пополняемого справочника тарифов;

6.36. Расчет начислений и формирование счета за отпущенную энергию сверх лимита (расчет

по повышенному тарифу);

6.37. Начисление/сторнирование фиксированной суммы (штрафные санкции, перераспреде-

ление общих потерь системы на потребителей без приборов учета);

6.38. Начисление суммы за хищения по регистрации факта хищения с указанием объема хи-

щения электроэнергии. Начисление штрафа за факт хищения по регистрации факта хи-

щения в зависимости от объема хищения;

6.39. Выполнение авансовых начислений на основании расчета авансового потребления;

6.40. Автоматическая проверка начислений на непротиворечивость;

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

чения по событию при вводе результатов расчета потребления за расчетный период;

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

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

Стр. 22

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

чения по событию календаря с датами наступления начисления;

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

значения при использовании нормативов потребления после наступления даты расчета;

6.45. Ручное и автоматическое утверждение результатов начисления с единичным и группо-

вым способом утверждения начислений;

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

чета начисленных сумм при изменении результатов расчета потребления, тарифов, c

учетом авансовых начислений и с сохранением истории перерасчетов;

6.47. Возможность формирования предварительных (пробных) начислений/сторнирования с

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

6.48. Формирование потока операций и кейсов для обработки случаев хищения: регистрация

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

похищенный объем энергоресурса и штрафа за хищение. Возможность выставлять от-

дельный счет за хищения, а также указывать начисления за хищения в составе счета за

услугу по предоставлению похищенного энергоресурса;

6.49. Расчеты с сетевыми организациями по различным схемам (с «держателем котла», с ка-

ждой сетевой организацией в отдельности) за услуги и по оплате потерь.

7. Требования к автоматизации выставления финансовых документов

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

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

7.2. Выставление счетов и платежных требований по однократным начислениям и сборам,

(например, оплата услуг за подключение, повторное подключение, штрафы, пени);

7.3. Включение в счет расчетов сторонних организаций для выставления единого консоли-

дированного счета;

7.4. Формирование и просмотр на экране счета и платежного требования к оплате для одно-

го потребителя;

7.5. Формирование счетов и передача данных на конвертировочную машину для формиро-

вания писем потребителям с сортировкой корреспонденции по определенным правилам

(сортировка по почтовым индексам и т.п.);

7.6. Формирование авансовых счетов и платежных требований для юридических лиц;

7.7. Формирование, печати и хранения истории счетов-фактур, счетов, платежных требова-

ний;

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

ру (суб-абоненты);

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

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

а так же единого счета абонента;

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

по группам услуг;

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

(потребление электроэнергии, газа, воды, другие услуги);

7.12. Формирование в процессе выставления счетов для каждого типа потребителей соответ-

ствующего, регламентированного набора документов;

7.13. Формирование сводной ведомости по выставленным счетам;

7.14. Формирование и печать расшифровок (комментариев) по начислениям за любой период

времени по любому абоненту или группе абонентов;

Стр. 23

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

7.16. Возможность проставить штриховой код при формировании бумажного счета (квитан-

ции);

7.17. Сохранение в системе выставленных счетов в течение заданного времени с возможно-

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

но;

7.18. Автоматизированная рассылка копий счетов потребителям посредством электронной

почты;

8. Требования к автоматизации учета поступивших оплат

8.1. Управление финансовыми поступлениями всех типов;

8.2. Работа с авансовыми платежами и планами авансовых платежей;

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

счета (включая электронный перевод средств (ЭПС), прямое дебетовое списание и пла-

тежи с помощью кредитных карт);

8.4. Обеспечение ведения бухгалтерского учета для целей формирования Книги поку-

пок/продаж, оборотно-сальдовых ведомостей;

8.5. Создание и предоставление для дальнейшего использования в учетной системе энерго-

сбытовой организации (ЭСО) бухгалтерских проводок с отражением на соответствую-

щих бухгалтерских счетах;

8.6. Выполнение погашения начисленной суммы;

8.7. Ручной ввод данных о поступлениях, сопоставление начисленной сумме, сохранение в

базе данных;

8.8. Автоматическая загрузка данных о поступлениях через интерфейс «Клиент Банк», со-

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

8.9. Возможность ввода данных о наличных платежах из файла в предопределенном форма-

те;

8.10. Ручное и автоматическое соотнесение платежа начисленной сумме (части начисления,

нескольким начислениям) в соответствии с определенными правилами;

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

и сумм оплаты на соответствие данным банковской выписке (Тендер-контроль);

8.12. Поддержка проведения «сверки» платежей со списком платежей, в частности, поиск

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

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

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

сканирования штрих-кодов);

8.14. Индоссирование и распечатка чеков;

8.15. Наличие режима возврата сумм ошибочных платежей;

8.16. Невозможность удаления результатов регистрации поступления и возврата оплаты;

8.17. Наличие режима корректной обработки поступлений оплаты в случае закрытого учет-

ного периода;

8.18. Формирование платежных требований на основании договора о безакцептном / акцепт-

ном списании для оплаты итоговых и авансовых начислений;

8.19. Контроль транзакционной завершенности: отсутствие не рассчитанных потребителей,

незавершенных операций по всем модулям и т.д.;

8.20. Проведение операции «Закрытие периода», которая определяет границу между двумя

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

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

Стр. 24

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

период, с корректировкой счетов-фактур в предыдущем периоде;

8.21. Контроль полноты выполнения и завершенности всех бизнес-процессов, предшествую-

щих закрытию периода (отсутствие незавершенных транзакций);

8.22. Проведение операции «Закрытие периода» по одному клиенту и по группе потребите-

лей (по потребителям участка, отделения). Защита от изменения натуральных и финан-

совых показателей потребителя после операции «Закрытие периода» по закрытому пе-

риоду. Обеспечение запрета на проведение перерасчетов в закрытом учетном периоде.

8.23. Списание кредиторской задолженности.

9. Требования к автоматизации управлению дебиторской задолженностью

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

ражающего в каждый момент времени текущее состояние взаиморасчетов с ним;

9.2. Расширенная функциональность по работе с задолженностями, взысканиями и сборами;

9.3. Инструменты контроля долга и стимулирования оплаты потребителя;

9.3.1. Напоминания

9.3.2. Предупреждения

9.3.3. Ограничения предоставления услуг

9.3.4. Отключения

9.3.5. Расторжение отношений

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

вержденными бизнес-правилами компании.

9.4. Фоновый мониторинг и контроль по запросу просроченных задолженностей с настрой-

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

ваниями и требованиями законодательства;

9.5. Отмена процессов взыскания дебиторской задолженности по полной или частичной оп-

лате, в зависимости от того, как это определено компанией;

9.6. Расчет и начисление штрафов, пеней, гос. пошлины за задержку платежа с автоматиче-

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

ми для каждой услуги на конкретном лицевом счету;

9.7. Оценка кредитоспособности по каждому лицевому счету, настроенная на основе финан-

сового события;

9.8. Оценка кредитоспособности на основании задержек платежей или недостатка средств

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

риода;

9.9. Разделение потребителей на категории, определяющие сценарии работы с дебиторской

задолженностью, при помощи атрибута «категория дебитора»;

9.10. Формирование и хранение в системе списка потребителей («Список №1»), работа с ко-

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

9.10.1. Потребители, которые находятся на контроле руководства;

9.10.2. Сгруппированные потребители (VIP-клиенты, одноставочние, двухставочные,

приравненные к населению, группировка по максимальной мощности, прочие).

9.11. Возможность задания различных сценариев работы с потребителями в зависимости от

типа потребителя и «категории дебитора»;

9.12. Автоматическое формирование и печать предупреждения о задолженности в предопре-

деленном формате для списка потребителей (в массовом порядке) и для одного потре-

бителя;

Стр. 25

9.13. Формирование, редактирование и удаление документов «Предупреждение о задолжен-

ности» для сформированного списка потребителей (в пакетном режиме) и для одного

потребителя (в ручном режиме);

9.14. Учет и ведение истории сформированных и отправленных предупреждений о задол-

женности;

9.15. Формирование, редактирование и печать документа «Уведомление об ограничении» для

сформированного списка потребителей (в пакетном режиме) и для одного потребителя

(в ручном режиме) с учетом сформированных уведомлений и ведением истории их вы-

ставления;

9.16. Формирование, редактирование и печать документа «Уведомление об ограниче-

нии/отключении» для потребителя. Возможность автоматизированной рассылки копий

«Уведомление об ограничении/отключении» отдельным потребителям посредством

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

нии/отключении;

9.17. Формирование документов «Заявка на отключение/ограничение абонентов» для экс-

плуатирующей сетевой организации;

9.18. Автоматическая отмена процессов взыскания задолженности по полной или частичной

оплате, в зависимости от того, как это определено правилами работы на РРЭ и регла-

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

9.19. Формирование на основе документа «Заявка на включение абонентов» с возможностью

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

9.20. Ведение для каждого потребителя «Истории контактов с потребителем», в котором со-

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

ках процесса «Управление дебиторской задолженностью», в частности:

• отправка предупреждения о задолженности (с отметкой о получении);

• отправка уведомления об отключении / ограничении (с отметкой о получении);

• включение потребителя в распоряжение на отключение (с указанием номера и даты

распоряжения).

9.21. Списание дебиторской задолженности.

9.22. Ведение исполнительных листов.

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

Ключевые показатели деятельности должны быть разработаны в ходе выполнения ра-

бот (Раздел III, пп.1, 2, 3) и согласованы с Заказчиком.

Минимальный набор результатов:

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

чиком.

Описание процесса, зафиксированное системой автоматизации методом настроек и ми-

нимального программирования.

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

Направления, по которым должны измеряться КПЭ с помощью автоматизированной системы:

10.1. Биллинг

Стр. 26

• Контроль расчѐтов, перерасчѐтов, выставления счетов (например, доля клиентов, по

которым сделан расчет в течение суток после появления исходных данных для расчѐта)

10.2. CRM

• Работа с обращениями и жалобами клиентами (например, количество обращений без

ответа более Х часов/дней);

• Работа колл-центра (например, количество клиентов, ожидающих ответ оператора,

более Х минут);

• Работа личного кабинета (например, доля обращений клиентов через личный каби-

нет от общего кол-ва обращений клиентов);

• Работа ЦОКов - электронная очередь (например, количество человек в очереди)

10.3. Процессная модель

• Договорная работа (например, количество запросов по заключению (изменению) до-

говоров, обрабатываемых более Х часов/дней);

• Взыскание ДЗ (например, количество клиентов, не оплативших ДЗ после обзвона

должников);

• Контроль взаиморасчѐтов с сетевыми организациями (например, количество клиен-

тов, по которым не введены в систему необходимые первичные документы (акты съѐма

показаний и пр.));

• Контроль взаиморасчѐтов с поставщиками дополнительных услуг (например, коли-

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

10.4. Ситуационная модель

• Исковая деятельность (например, количество должников, по которым не сформиро-

ван (или подан) иск в течение Х дней после обзвона должников);

• Ограничения (например, количество должников, по которым не сформировано (или

не направлено) уведомление на ограничение в течение Х дней после обзвона должни-

ков)

10.5. Централизация

Набор КПЭ будет формироваться Заказчиком в ходе осуществления автоматизации процессов

Компании.

11. Требования к составу выходных форм и отчетов

11.1. Формирование оперативной отчетности:

11.1.1. Счет

11.1.2. Счет-фактура

11.1.3. Ведомость электропотребления

11.1.4. Платежное требование

11.1.5. Отчет о поступивших платежах в разрезе источников (в режиме on-line)

11.1.6. Приходный кассовый ордер

11.1.7. Расходный кассовый ордер

11.1.8. Акт приема-передачи электроэнергии и мощности

11.1.9. Реестр поступивших оплат по неопознанным абонентам

11.1.10. Справка о задолженности

11.1.11. Приглашение на сверку

11.1.12. Акт о расходе электроэнергии


11.1.14. Акт выверки взаиморасчетов

Стр. 27

11.1.15. Договор Энергоснабжения (купли-продажи) с приложениями

11.1.16. Наряд на работу

11.1.17. Сведения о потреблении и оплате абонента

11.1.18. Лист обхода

11.1.19. Карточка потребителя

11.1.20. Квитанция для оплаты

11.1.21. Финансово-лицевой счет

11.1.22. Форма оперативного контроля (ЕНН-2)

11.2. Формирование статистической отчетности:

11.2.1. 46 форма по эл.энергии в разрезе юридических лиц

11.2.2. Структура полезного отпуска электроэнергии

11.2.3. Отчет о поступивших платежах в разрезе источников

11.2.4. Потребление электрической энергии от источника в разрезе потребителей

11.2.5. Начисление по методам расчета

11.2.6. Структура дебиторской задолженности

11.2.7. Реестр неоплаченных платежных документов

11.2.8. Реестр неоплаченных счетов-фактур

11.2.9. Книга продаж и дополнительные листы

11.2.10. Книга покупок и дополнительные листы

11.2.11. Журнал регистрации счетов-фактур

11.2.12. Журнал регистрации счетов

11.2.13. Журнал учета списаний и доначислений

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

11.2.15. Кассовая книга

11.2.16. Кассовый отчет

11.2.17. Оборотная ведомость по договору

11.2.18. Оборотная ведомость по группе договоров (по техникам)

11.2.19. Оборотная ведомость по отделению

11.2.20. Оборотная ведомость общая

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

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

11.2.22. Оборотная ведомость по компенсации расходов в связи с изменением до-

говорной величины потребления

11.2.23. Оборотная ведомость по пени

11.2.24. Оборотная ведомость по 395 ст.

11.2.25. Оборотная ведомость по гос.пошлине

11.2.26. Реализация энергии по договорам

11.2.27. Ведомость по перерасчетам

11.2.28. Ведомость о полезном отпуске и реализации электрической энергии – 8

ГП

11.2.29. Отчет по форме 9-ПС

11.2.30. Расчет пени

11.2.31. Расшифровка кредитовой задолженности

11.2.32. Справка по перерасчетам предыдущих периодов

11.2.33. Справка по закрытию задолженности предыдущих периодов

11.2.34. Журнал выставленных платежных требований

11.2.35. Реестр переданных платежных документов на инкассо.

Стр. 28

11.2.36. Ведомость поступлений денежных средств на расчетные счета ОАО

«ЛЭСК»

11.2.37. Ведомость поступления сумм сальдо с субсчетов отделений на расчетные

счета ОАО «ЛЭСК»

11.2.38. Объем поставки электроэнергии по группам потребителей в разрезе сете-

вых организаций

11.2.39. Журнал регистрации приходно-кассовых ордеров и расходно-кссовых ор-

деров

11.2.40. Справка по кредиторской задолженности

11.2.41. Справка по дебиторской задолженности


11.2.43. Расчет процентов по ст.395 ГК РФ

11.2.44. Справка о поступлении на расчетный счет

11.2.45. Справка по нерасшифрованным суммам

11.2.46. Отчет по сберкассам

11.2.47. Итоговые данные по банкам

11.2.48. Отчет по квартирным группам

11.2.49. Список задолженности по бюджетным организациям

11.2.50. Ведомость потребления для предоставления в сетевую организацию

11.2.51. Отчет по КТП и Фидерам

11.2.52. Отчет по трехфазным счетчикам

11.2.53. Акт об оплате электроэнергии населением

11.2.54. Инвентаризационная опись

11.2.55. 26 форма ЖКХ

11.2.56. Список нарядов

11.2.57. Отчет по штрафникам

11.2.58. Список отключенных абонентов

11.2.59. Отчет по выверки и контролю срока поверки

11.2.60. План-отчет по контролерам

Стр. 29

РАЗДЕЛ VI. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО РАЗРАБОТКЕ И

ВНЕДРЕНИЮ СИСТЕМЫ

1. Организация контроля хода выполнения работ

Работы по разработке и внедрению Системы должны быть организованы поэтапно. Этапы

могут осуществляться последовательно или одновременно. Со стороны Участника открытого за-

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

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

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

проекта и т.д.

Перевод Системы в промышленную эксплуатацию должен сопровождаться этапом мето-

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

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

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

щие формализованные методологии ведения Проекта разработки и внедрения Системы.

2. Требования к ИАС

2.1. Требования к техническому решению построения информационно-аналитической системы

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

2.1.2. Аутентификация – идентификация пользователя с помощью идентификатора и

пароля.

2.1.3. Технология однократной регистрации в системе – однократный ввод идентифи-

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

ская аутентификация.

2.1.4. Авторизация – предоставление полномочий пользователю для работы с содержа-

нием портала.

2.1.5. Интегрированное управление пользователями – обеспечение централизованного

администрирования пользователей.

2.1.6. Возможность расширения функциональности системы.

2.2. Требования к функциональности информационно-аналитической системы.

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

приятия по группам процессов, входящих в объем Проекта.

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

вателями посредством стандартного интерфейса.

2.2.3. Обеспечение возможности проведения всестороннего анализа большого объема

данных и формирование отчетности на их основе;

2.2.4. Возможность накопления, хранения и преобразования данных;

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

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

Систему;

3. Требования к нормативно-справочной информации (НСИ)

3.1. Создание и унификация НСИ для предприятия включает в себя:

разработку единой для всех подразделений структуры справочников для АСУ СЭРП;

унификацию (приведение существующих справочников в соответствие с разработан-

ной структурой);

Стр. 30

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

вочников

заполнение справочников и классификаторов данными;

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

выверка данных в справочниках, проверка на непротиворечивость.

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

структурой платформы.

4. Требования к интеграции с другими системами

4.1. Обеспечить интеграцию со следующими информационными системами:

4.1.1. 1С 8.2 УПП;

4.1.2. Система электронного документооборота «Директум».

4.1.3. Система управления электронной очередью

4.1.4. Call-центр

4.2. При разработке интеграционных решений должны применяться только стандартные от-

крытые средства интеграции ПО;

4.3. Требования к интеграции с другими системами должны быть уточнены на этапе разработ-

ки Технического задания.

5. Требования к проведению приемки работ

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

испытаний на территории и оборудовании ОАО «ЛЭСК».

Методика проведения испытаний должна быть представлена Исполнителем и согласована

с Заказчиком.

6. Рекомендации по срокам выполнения работ

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

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

Стр. 31

РАЗДЕЛ VII. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО МИГРАЦИИ

ДАННЫХ

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

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

деятельности.

Проведение миграции данных включает в себя:

анализ исходных данных;

разработка системы форматов данных;

извлечение, проверка и очистка данных;

трансформация данных;

загрузка данных в систему.

Стр. 32

РАЗДЕЛ VIII. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ И ЗАЩИТЕ ИНФОРМАЦИИ

1. Требования по безопасности

Требования к Системе включают:

Система должна обеспечивать обработку конфиденциальной информации.

Применяемые в Системе средства и технологии защиты, объединяемые в

Систему защиты информации (СЗИ) Системы, должны обеспечивать открытость архи-

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

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

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

ки и строиться на основе ограниченного числа типов и версий приобретаемого про-

граммного обеспечения, а также типов и конфигураций аппаратно-программных

средств защиты, уточняемых на стадии проектирования Системы.

Развернутые и уточненные требования к структуре, функциям и средствам СЗИ долж-

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

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

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

анализа возможных моделей нарушителей.

СЗИ должна предполагать независимость функционирования каждой из

входящих в ее состав структурных Систем защиты. Нарушение функционирования

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

Систем защиты.

Средства защиты, входящие в состав СЗИ, должны иметь развитые средства регистра-

ции критических системных событий в электронных журналах и средства оперативно-

го оповещения об этих событиях администраторов безопасности.

2. Требования к защите информации от несанкционированного доступа.

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

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

темным ПО;

стандартными средствами используемой СУБД;

средствами ИВК (идентификация пользователей и разграничение прав

доступа).

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

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

ми;

многоуровневую систему защиты: защита на уровне подсистемы, уровне

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

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

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

пространства, сетевой нагрузки и т.п.);

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

ведение журнала изменений коммерческих данных, инициированных

оператором.

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

группам операций.

Стр. 33

Стр. 34


ПОЛЬЗОВАТЕЛЕЙ К ЭКСПЛУАТАЦИИ СИСТЕМЫ

1. Категории пользователей

Разработка и ввод в промышленную эксплуатацию Системы предусматривает подготовку

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

категорий пользователей:

администратор;



бизнес-аналитик.

2. Направления подготовки администратора приложений

Администратор Системы должен получить знания и навыки по:

генерации Системы;

конфигурированию технических характеристик Системы;

контролю доступа;

резервному копированию и восстановлению;

конфигурированию меню;

связям с другими программными продуктами и системами;

передаче данных из/в приложения;

переносу на другие платформы;

другие (будет уточнено на этапе доработки Рабочего проекта)

3. Направления подготовки разработчика приложений

Разработчик должен получить знания и навыки по:

модификации и создании серверных компонентов Системы;

модификации и создании клиентских компонентов Системы;

модификации программного кода лицензионного программного обеспечения и созда-

нию новых программ при помощи встроенного языка программирования Системы;

другие (будет уточнено на этапе доработки Рабочего проекта).

4. Направления подготовки конечных пользователей

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

направлениям:

базовые знания работы с Системой;

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

другие (будет уточнено на этапе доработки Рабочего проекта);

5. Направления подготовки бизнес - аналитиков

Должна быть произведена подготовка бизнес - аналитиков по следующим направлениям:


расширенные знания возможностей компонентов Системой;

возможности Системы в области формирования гибких аналитических отчетов;


Стр. 35

6. Аттестация пользователей

По окончанию проведения подготовки специалистов должна быть произведена проверка

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

конечных пользователей Системы.

Стр. 36

РАЗДЕЛ X. ТРЕБОВАНИЯ К ОКАЗАНИЮ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ

В Проект должно быть включено обеспечение технической поддержкой.

Программный продукт, результатом конфигурирования которого является создание Сис-

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

стандартным уровнем технической поддержки со стороны компании-производителя ПО (вендора).

Предоставить описание требуемого уровня технической поддержки со стороны компании-

производителя ПО на этапе внедрения и дальнейшего развития Системы.

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

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

Стр. 37

РАЗДЕЛ XI. ТРЕБОВАНИЯ К СОПРОВОЖДЕНИЮ СИСТЕМЫ

В рамках Проекта разработки и ввода в промышленную эксплуатацию АСУ СЭРП Испол-

нитель должен обеспечить начальное сопровождение Системы, ИАС после ввода в эксплуатацию

сроком не менее 3 месяцев.

Стр. 38

РАЗДЕЛ XII. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ РЕЗУЛЬТАТОВ

РАБОТЫ

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

Руководство администратора;

Руководство пользователя;

Руководство бизнес-аналитика;

Руководство разработчика;

Разработать программу и методику испытаний Системы, предоставить результаты проведе-

ния испытаний.

Стр. 39

РАЗДЕЛ XIII. ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ

1. Требования к информационному обеспечению

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

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

функциональных требований к системе и потребности обмена с внешними системами.

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

мое СУБД, поддерживающей такое представление данных;

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

информационных кубов на основе OLAP-решения.

1.2. Требования по использованию систем управления базами данными (СУБД)

1.2.1. В качестве Системы Управления Базой Данных должна использоваться высокопроиз-

водительная современная СУБД ORACLE, бесшовная интеграция которой с исполь-

зуемым лицензированным ПО, на основе которого разрабатывается Система, должна

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

1.2.2. Общие требования к используемой СУБД:

1.2.2.1. Поддержка реляционной модели базы данных;

1.2.2.2. Поддержка технологии клиент-сервер;

1.2.2.3. Поддержка многопроцессорной архитектуры;

1.2.2.4. Наличие средств создания индексов и кластеров данных;

1.2.2.5. Автоматическое восстановление базы данных;

1.2.2.6. Наличие механизма блокировки транзакций;

1.2.2.7. Реализация SQL, совместимого со стандартом ANSI 1992 г.

1.2.2.8. Поддержка стандартов ODBC и OLE DB;

1.2.2.9. Поддержка работы с XML;

1.2.2.10. Наличие встроенных средств контроля целостности баз данных;

1.2.2.11. Наличие встроенных средств резервного копирования базы данных;

1.2.2.12. Импорт и экспорт данных;

1.2.2.13. Возможность работы в распределенном режиме, наличие механизмов реплика-

ции данных;

1.2.2.14. Совместимость с различными операционными системами;

1.2.2.15. Поддержка высокоскоростных сетевых протоколов;

1.2.2.16. Наличие графических средств администрирования;

1.2.2.17. Возможность контроля доступа к данным;

1.2.2.18. Централизованное управление пользователями;

1.2.2.19. Оптимизация запросов;

1.2.2.20. Наличие механизма встроенных процедур баз данных;

1.2.2.21. Наличие утилит для переноса данных из унаследованных систем;

1.2.3. Обеспечение безопасности данных на уровне сервера баз данных.

1.2.4. СУБД должна обеспечивать обмен и хранение информации неограниченного объѐма.

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

Обязательным языком интерфейса Системы, а также всей документации по Проекту явля-

ется русский язык.

Стр. 40

3. Требования к программному обеспечению

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

Прикладное программное обеспечение Системы должно представлять собой совокупность

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

нение следующих требований:

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

рекцию, удаление и поиск данных, в том числе справочников Системы;

реализацию общих требований к Системе;

возможность конфигурирования и настроек Системы;

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

ния с помощью штатного средства разработки;

автоматизированное создание выходных документов Системы с помощью средств раз-

работки запросов и отчетов.

3.2. Требования к показателям назначения Системы

3.2.1. Автоматизированная система предназначена для работы в непрерывном (кругло-

суточном) режиме.

3.2.2. Система должна поддерживать работу пользователей, находящихся на

территориально разобщенных объектах.

3.2.3. Система должна формировать единое информационное пространство, в

котором взаимодействие процессов и пользователей обеспечивается за

счет общих информационных объектов.

3.2.4. Должна обеспечиваться возможность увеличения количества одновременно рабо-

тающих пользователей.

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

на всех потенциальных объектах внедрения.

3.2.6. Должен быть реализован принцип открытой архитектуры построения

системы, обеспечивающий возможность встраивания и взаимодействия с

любыми другими системами.

3.2.7. Непротиворечивость данных. Система должна автоматически контролировать дуб-

лирование данных и проверять информацию для устранения противоречивости. При

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

смотрены механизмы разрешения конфликтов.

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

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

в пределах корпоративной сети Заказчика.

3.3. Требования к надежности

Уровень надежности Системы должен обеспечивать выполнение утвержденного графика

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

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

3.4. Требования к масштабируемости:

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

рументальных средств для автоматизации процессов внедрения системы, а также эксплуатации,

поддержки и дальнейшей модернизации:

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

Стр. 41

Инструменты миграции;

Инструменты архивирования;

Инструменты интеграции приложений;

Управление потоками операций и уведомления;

Формализованные плоские отчеты;

Управление проектами конфигурации;

Инструментарий разработчика.

3.5. Требования к системному программному обеспечению

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

функционирование модулей Системы, в том числе в многопользовательском и много-

процессорном режиме;

генерацию и сопровождение базы данных Системы;

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

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

защиту от несанкционированного доступа.

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

с СУБД ORACLE.

В качестве клиентских ОС должны быть использованы ОС семейства Microsoft Windows

2003 / XP, имеющиеся в наличии и предоставляемые Компанией.

3.6. Требования к каналам связи

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

ченной пропускной способностью (512 кБит/сек)

3.7. Требования к обновлению версий лицензионного программного обеспечения

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

строек и изменений в новые версии лицензионного ПО с момента их получения Исполнителем, но

не позднее даты окончания поддержки предшествующей версии. Исполнитель должен произво-

дить установку обновлений Лицензионного ПО по согласованию с Заказчиком.

3.8. Требования к рабочим станциям и серверам

В предложениях Участники должны указать минимальные характеристики рабочих стан-

ций и серверов, необходимые для работоспособности Системы.

Стр. 42

Лот №2

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

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

электроэнергии и расчетов с потребителями для нужд

ООО «Городская энергосбытовая компания»

РАЗДЕЛ I. ОБЩИЕ ПОЛОЖЕНИЯ ............................................................... 4

1. Введение ........................................................................................................... 4

2. Общие сведения .............................................................................................. 4

2.1. Полное наименование работ и их условное обозначение ............ 4

2.2. Сокращения и обозначения ............................................................. 4

2.3. Границы применимости документа ................................................ 5

РАЗДЕЛ II. НАЗНАЧЕНИЕ И ЦЕЛИ ПРОВЕДЕНИЯ РАБОТ .................. 6

1. Основная цель Проекта ................................................................................ 6

2. Основное назначение Системы ................................................................... 6

3. Основные функции Системы ....................................................................... 6

РАЗДЕЛ III. КОМПЛЕКТНОСТЬ ПОСТАВКИ И СОСТАВ РАБОТ ........ 8

1. Состав работ .................................................................................................. 8

2. Необходимая функциональность ................................................................ 9

3. Состав комплекта поставки ....................................................................... 9

РАЗДЕЛ IV. ОБЩИЕ СВЕДЕНИЯ ОБ ОБЪЕКТЕ ....................................... 10

1. Организационная структура общества .................................................. 10

2. Основные виды деятельности ................................................................... 10

3. Дополнительные виды деятельности ..................................................... 10

РАЗДЕЛ V. ТРЕБОВАНИЯ К СИСТЕМЕ .................................................... 11

1. Общие требования к Системе ................................................................... 11

2. Требования к составу решаемых задач .................................................... 12

3. Требования к автоматизации ведения взаимоотношений с

абонентами .................................................................................................. 12

4. Требования к личному кабинету (ЛКК) .................................................... 14

5. Требования к автоматизации сбора данных о фактическом

потреблении ................................................................................................. 18

6. Требования к автоматизации интегрального и интервального

биллинга ........................................................................................................ 19

Стр. 43

7. Требования к автоматизации выставления финансовых

документов ................................................................................................... 22

8. Требования к автоматизации учета поступивших оплат .................. 23

9. Требования к автоматизации управлению дебиторской

задолженностью ......................................................................................... 24

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

компании (КПЭ)........................................................................................... 25

11. Требования к составу выходных форм и отчетов ................................ 26

РАЗДЕЛ VI. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО

РАЗРАБОТКЕ И ВНЕДРЕНИЮ СИСТЕМЫ ................................................ 29

1. Организация контроля хода выполнения работ .................................... 29

2. Требования к ИАС ........................................................................................ 29

3. Требования к нормативно-справочной информации (НСИ) ................ 29

4. Требования к интеграции с другими системами .................................... 30

5. Требования к проведению приемки работ ............................................... 30

6. Рекомендации по срокам выполнения работ .......................................... 30

РАЗДЕЛ VII. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО

МИГРАЦИИ ДАННЫХ ...................................................................................... 31

РАЗДЕЛ VIII. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ И ЗАЩИТЕ

ИНФОРМАЦИИ ................................................................................................... 32

1. Требования по безопасности ...................................................................... 32

2. Требования к защите информации от несанкционированного

доступа. ........................................................................................................ 32


ПОЛЬЗОВАТЕЛЕЙ К ЭКСПЛУАТАЦИИ СИСТЕМЫ .............................. 34

1. Категории пользователей .......................................................................... 34

2. Направления подготовки администратора приложений .................... 34

3. Направления подготовки разработчика приложений .......................... 34

4. Направления подготовки конечных пользователей .............................. 34

5. Направления подготовки бизнес - аналитиков ...................................... 34

6. Аттестация пользователей ...................................................................... 35

РАЗДЕЛ X. ТРЕБОВАНИЯ К ОКАЗАНИЮ ТЕХНИЧЕСКОЙ

ПОДДЕРЖКИ ....................................................................................................... 36

РАЗДЕЛ XI. ТРЕБОВАНИЯ К СОПРОВОЖДЕНИЮ СИСТЕМЫ .......... 37

РАЗДЕЛ XII. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

РЕЗУЛЬТАТОВ РАБОТЫ .................................................................................. 38

Стр. 44

РАЗДЕЛ XIII. ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ ......................... 39

1. Требования к информационному обеспечению ....................................... 39

1.1. Требования к составу, структуре и способам организации

данных в системе ............................................................................ 39

1.2. Требования по использованию систем управления базами

данными (СУБД)............................................................................. 39

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

3. Требования к программному обеспечению ............................................... 40

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

3.4. Требования к масштабируемости: ................................................ 40

3.5. Требования к системному программному обеспечению ............ 41

3.6. Требования к каналам связи .......................................................... 41

3.7. Требования к обновлению версий лицензионного

программного обеспечения ........................................................... 41

3.8. Требования к рабочим станциям и серверам ............................... 41

Стр. 45

РАЗДЕЛ XIV. ОБЩИЕ ПОЛОЖЕНИЯ

3. Введение

3.1. Целью настоящего Технического задания является определение требований к работам по

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

расчетами с потребителями ООО «ГЭСК» на базе программного обеспечения Oracle

CC&B, физическими и юридическими лицами, а также необходимых стадий и этапов ра-

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

присылаемых на открытый запрос предложений.

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

4.1. Полное наименование работ и их условное обозначение

Создание и внедрение автоматизированной системы управления сбытом электроэнергии и

расчетами с потребителями ООО «ГЭСК» (далее – АСУ СЭРП или Система) на базе программно-

го обеспечения Oracle Utilities Customer Care and Billing (далее - Платформа).

4.2. Сокращения и обозначения

Ниже приводятся термины и акронимы (аббревиатуры), используемые в настоящем доку-

менте.

Компания, Заказчик –ООО «ГЭСК»;

Исполнитель – Участник открытого запроса предложений, предложивший в своей заявке

наилучшие условия выполнения договора;

Платформа - программное обеспечение Oracle Utilities Customer Care and Billing

Нормативный документ – принятый в установленном порядке документ, устанавливающий

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

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

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

иные документы;

НСИ – нормативно-справочная информация;

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

тельностью и расчетами с потребителями ООО «ГЭСК»;

АСУ СЭРП, Система – автоматизированной системы управления сбытовой деятельностью и

расчетами с потребителями ООО «ГЭСК»;

ОС – операционная система;

ИАС – информационно-аналитическая система;

СУБД – система управления базами данных;

ТРП – технический рабочий проект;

ТЗ – техническое задание;

НИОКР – научно-исследовательские и опытно-конструкторские разработки;

ЦОД – центр обработки данных;

ЦОК – центр обслуживания клиентов;

АРМ – автоматизированное рабочее место;

КИС – корпоративная информационная система;

ПК – программный комплекс;

АСКУЭ – автоматизированная система коммерческого учета электроэнергии;

ЭСО – энергосбытовая организация;

Стр. 46

4.3. Границы применимости документа

Настоящий документ описывает требования к работам по разработке и внедрению АСУ

СЭРП. Технические требования являются основным документом в комплекте тендерной доку-

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

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

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

Основанием данных Технических требований являются требования, сформулированные в

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

Стр. 47

РАЗДЕЛ XV. НАЗНАЧЕНИЕ И ЦЕЛИ ПРОВЕДЕНИЯ РАБОТ

4. Основная цель Проекта

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

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

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

комплексную и интегрированную поддержку деятельности подразделений Компании и обеспечи-

вают прозрачность деятельности ООО «ГЭСК» для руководства, инвесторов и для общества в це-

лом, за счет:

• Создания современной и эффективной системы управления энергосбытовой дея-

тельностью ООО «ГЭСК»;

• Централизации информационных потоков и оптимизация процессов формирования

отчетности;

• Сокращения операционных издержек и повышения производительности труда;

• Снижения дебиторской задолженности;

• Повышения конкурентоспособности за счет гибких условий обслуживания потреби-

телей;

• Автоматизации работы с контрагентами;

• Повышения финансовой прозрачности;

• Повышения инвестиционной привлекательности компании.

• Улучшение бизнес-процессов Компании с учетом передовых стандартов бизнес-

процессов.

5. Основное назначение Системы

Основное назначение Системы – автоматизация бизнес-процессов ООО «ГЭСК», включая:

• Автоматизацию бизнес-процессов подразделений ООО «ГЭСК»;

• Автоматизацию взаимодействия с потребителями физическими и юридическими ли-

цами;

• Автоматизацию взаимодействия со сторонними системами и организациями.

6. Основные функции Системы

Основные функции Системы – автоматизация бизнес-процессов ООО «ГЭСК», включая:

• Ведение истории взаимоотношений с потребителями физическими и юридическими

лицами;

• Сбор данных о фактическом потреблении;

• Интегральный и интервальный биллинг;

• Формирование финансовых документов;

• Прием и учет платежей;

• Управление дебиторской задолженностью;

• Формирование консолидированной отчетности о деятельности предприятия;

• Расчеты с сетевыми организациями;

• Расчеты по дополнительным видам услуг.

3. Объектами автоматизации Системы являются следующие подразделения Компании:

• Аппарат управления ООО «ГЭСК»

• ЦОК ООО «ГЭСК»

Стр. 48

Стр. 49

РАЗДЕЛ XVI. КОМПЛЕКТНОСТЬ ПОСТАВКИ И СОСТАВ РАБОТ

Участник открытого запроса предложений должен предоставить технико-коммерческое

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

и внедряемой Системы на базе программного обеспечения Oracle CC&B, календарный план вы-

полнения работ по созданию и внедрению Системы -, пример регламента сопровождения. При

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

сроков до отдельных этапов.

4. Состав работ

Для создания и внедрения АСУ СЭРП необходимо выполнить следующие работы 16. Анализ существующих функций и бизнес-процессов;

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

тиками и стандартами обслуживания;

18. Согласование новой модели деятельности компании;

19. Формирование и первоначальное наполнение НСИ;

20. Разработка документации по ведению и сопровождению НСИ;

21. Настройка согласованной новой модели деятельности в программном обеспечении Oracle

CC&B;

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

гласованной модели и текущему законодательству (доработка интерфейсов, процедур расчетов

и начислений и т.д.);

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

боток;

24. Миграция данных из ранее действующих Систем автоматизации деятельности по работе с

абонентами. Работа должна быть выполнена в полном объеме самостоятельно Исполнителем,

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

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

интерфейс для доступа к этим данным из новой Системы автоматизации, после вывода из экс-

плуатации существующих систем;

25. Интеграция АСУ СЭРП со смежными системами автоматизации ООО «ГЭСК» (Call-центр,

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

тема управления электронной очередью). Интеграция должна быть выполнена в полном объе-

ме самостоятельно Исполнителем, без привлечения к данным работам специалистов Заказчи-

ка;

26. Интеграция АСУ СЭРП с системой автоматизации бухгалтерии на базе ПО 1С 8.2 УПП (толь-

ко со стороны Oracle CC&B);

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

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

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

интерфейса и процедур расчетов и начислений);

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

утвержденной новой модели работы компании;

29. Проведение групповых обучений ключевых специалистов и представителей участков по ис-

пользованию новой Системы;

30. Техническая поддержка Системы до момента передачи в промышленную эксплуатацию.

Стр. 50

5. В системе должна быть реализована следующая функциональность:

14. Ведение истории взаимоотношений с потребителями физическими и юридическими лицами;

15. Сбор данных о фактическом потреблении в ручном и автоматическом режиме;

16. Учет и разнесение платежей (в ручном и автоматическом режимах);

17. Управление дебиторской задолженностью (в том числе автоматизированный контроль и гене-

рация событий);

18. Исковая деятельность (по задолженностям абонентов)

19. Интегральный и интервальный биллинг;

20. Расчеты по дополнительным видам услуг;

21. Формирование финансовых документов (книга покупок и продаж, счета, счета-фактуры);

22. Личный кабинет клиента ( с интеграцией с платежными online системами);

23. Централизации информационных потоков и оптимизация процессов формирования отчетности

в целом по компании;

24. Управление консолидированной отчетностью о деятельности компании в целом;

25. Сверки и взаиморасчеты со смежными организациями – поставщиками услуг (, ОРЭ, сетевые

компании, ИКУ и т.д.);

26. Бизнес-аналитика, показатели деятельности компании и информационные панели руководите-

лей;

6. Состав комплекта поставки

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

13. документация по ведению НСИ;

14. разработанная и внедренная ИАС;

15. интеграция АСУ СЭРП с СЭД «Директум»;

16. услуги по разработке документации, формированию, первоначальному наполнению, ведению

и сопровождению НСИ;

17. услуги по разработке и внедрению ИАС;

18. услуги по интеграции АСУ СЭРП с другими системами;

19. миграция данных из ранее действующей Системы.

20. услуги по подготовке специалистов Компании по использованию АСУ СЭРП;

21. услуги по организации семинаров и проведению обучения по использованию программного

обеспечения;

22. подготовка специалистов Компании по использованию АСУ СЭРП;

Стр. 51

РАЗДЕЛ XVII. ОБЩИЕ СВЕДЕНИЯ ОБ ОБЪЕКТЕ

4. Организационная структура общества

В состав ООО «ГЭСК» входят подразделения: аппарат управления,

3 центра обслуживания клиентов.

5. Основные виды деятельности

Основными видами деятельности компании являются:

поставка (продажа) электрической энергии по установленным тарифам в соответствии

с диспетчерскими графиками электрических нагрузок;

получение (покупка) электрической энергии с оптового рынка электрической энергии;

оказание услуг энергоснабжающим организациям по реализации электроэнергии;

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

ским лицам;


занные коммунальные услуги;


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

6. Дополнительные виды деятельности

Дополнительными видами деятельности компании являются:

продажа, установка и ремонт электросчетчиков любой классификации;

Стр. 52

РАЗДЕЛ XVIII. ТРЕБОВАНИЯ К СИСТЕМЕ

12. Общие требования к Системе

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

ческим лицам в единой информационной Системе;

12.2. Система должна обеспечивать соответствие форм документов, отчетов, бизнес-процессов

текущим требованиям законодательства и внутренних Регламентов в рамках согласованно-

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

жении Проекта.

12.3. Обеспечение повышения эффективности деятельности ООО «ГЭСК» за счет применения

лучшей практики интеграции бизнес-процессов и современных информационно-

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

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

сти ООО «ГЭСК» для руководства, инвесторов и для общества в целом;

12.4. Повышение надежности и обеспечение единства хранения и ввода информации;

12.5. Использования информационного массива для принятия решений в производственных

процессах Компании;

12.6. Доступный в любом подразделении инструмент для ввода информации по объектам учета;

12.7. Интерфейс вывода данных, который позволит пользователю получить информацию, кон-

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

быточно (по принципу «разумной достаточности»);

12.8. Отсутствие дублирования ввода одинаковой информации в рамках единого информацион-

ного пространства;

12.9. Централизованное ведение НСИ в рамках единого информационного пространства компа-

нии в соответствии с едиными принципами целостности и непротиворечивости данных;

12.10. Разграничение зоны ответственности пользователей и подразделений компании;

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

открытости ее архитектуры;

12.12. Система должна обеспечивать работу следующих категорий пользователей:

бизнес-аналитик;


администратор приложений;


12.13. Система должна обеспечивать разграничение доступа к информации и защиту информа-

ции от несанкционированного доступа на основе механизмов назначения прав;

12.14. В комплекте с Системой должна поставляться документация, описывающая средства и ме-

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

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

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

ваться на использовании системных (ОС, СУБД) средствах защиты от аварий и отдельных

сбоев;

12.15. Система должна обеспечивать ведение протокола выполнения операций по вводу и моди-

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

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

время выполнения операции;

12.16. Система должна допускать возможность ввода данных и команд множеством разных спо-

собов (клавиатура, мышь) и многовариантность доступа к еѐ функциям (например, спомо-

Стр. 53

щью текстовых и графических ссылок, «горячих клавиш», элементов меню). Кроме того, в

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

режиму.

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

ципов (в рамках отдельных подсистем):

единство базовых текстовых, цветовых и графических обозначений;

однотипный интерфейс навигации по экранным формам;

обеспечение многооконного режима.

13. Требования к составу решаемых задач

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

следующих задач в рамках основной деятельности ООО «ГЭСК»:

Ведения истории взаимоотношений с потребителями физ. и юридическими лицами;

Сбор данных о фактическом потреблении;

Интегральный и интервальный биллинг:

Расчеты по дополнительным видам услуг;

Формирование финансовых документов;

Учет и разнесение платежей;

Управление дебиторской задолженностью;

Формирование отчетности:

формирование управленческой отчетности в разрезе структурных подразделений

компании;

формирование управленческой отчетности по контролируемым потребителям;

формирование оперативной отчетности в рамках подразделений, определенных в

организационном объеме проекта;

формирование отчетов, определенных регламентом вышестоящего руководства,

определенного формата и содержания;

формирование отчетов, требования к которым меняются, в зависимости от потреб-

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

13.2. Конфигурация Системы должна позволять постепенное наращивание функциональности

системы.

14. Требования к автоматизации ведения взаимоотношений с абонентами

14.1. Ведение договорной работы, управление договорами (основной договор, дополнительное

соглашение и др.)

Инициирование и подготовка проекта договора

Ведение единой базы договоров с отражением в ней видов, типов, параметров и других

классификаций заключаемых договоров

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

14.3. Учет и ведение данных по абонентам и условиям их обслуживания с ведением всей ин-

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

14.4. Наличие информационного портала лицевого счета абонента с отображением информации

для работы с потребителем;

14.5. Управление взаимоотношениями с потребителями в течение жизненного цикла работы с

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

Стр. 54

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

договора;

14.6. Ведение и хранение истории лицевого счета и взаиморасчетов с потребителями;

14.7. Регистрация договоров об обслуживании с ведением соответствующих разделов договоров

об обслуживании (РДО);

14.8. Функциональность контакт-центра по обслуживанию потребителей:

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

14.10. Обеспечение доступа к необходимой информации для быстрого получения данных лице-

вого счета и договора об обслуживании;

14.11. Выдача предупреждений по состоянию лицевого счета, графиков выписки счетов, финан-

совых балансов и деталей лицевого счета;

14.12. Регистрация всех типов контактов с потребителями (телефон, лично, эл.почта, интернет) и

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

14.13. Автоматическая генерация необходимости контакта с потребителем (письма, напомина-

ния) при достижении необходимых условий, заданных для данного потребителя;

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

обслуживать потребителей со сложной структурой взаимосвязей субъектов, при которой або-

нент, плательщик и потребитель не совпадают:

14.14.1. Абонент, плательщик и потребитель являются разными лицами;

14.14.2. Потребитель с несколькими приборами учета;

14.14.3. Один прибор учета используется несколькими потребителями;

14.14.4. Потребитель, имеющий суб-абонентов, получающий общий счет и детализацию на-

числений отдельно по всем суб-абонентами.

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

суб-абонентам.

14.14.6. Потребитель, получающий общий счет за разные услуги.

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

жом.

14.14.8. Перевод независимого потребителя в суб-абоненты другого, зарегистрированного ра-

нее потребителя.

14.14.9. Перевод суб-абонента в независимого потребителя.

14.15. Предоставление потребителю защищенного удаленного доступа к текущей и исторической

информации по лицевому счету;

14.15.1. Баланс лицевого счета;

14.15.2. Наличие задолженности;

14.15.3. Параметры договора;

14.15.4. Тарифный план;

14.15.5. Выставленные счета;

14.15.6. Произведенная оплата;

14.16. Выполнение действий по данному лицевому счету;

14.16.1. Коррекция данных по лицевому счету и договору;

14.16.2. Ввод показаний приборов учета;

14.16.3. Оплата услуг;

14.16.4. Интеграция с платежными системами;

14.17. Обеспечение размещения web-приложения на сайте ООО «ГЭСК», в части, ориентирован-

ной на обслуживание потребителей.

Стр. 55

15. Требования к личному кабинету (ЛКК)

15.1. Назначение ЛКК

Основное предназначение ЛКК – предоставление клиентам розничного рынка интерактивного

доступа к информационным сервисам Компании.

В связи с потребностью постоянной адаптации данного канала обслуживания под потребно-

сти целевых групп клиентов особенно актуальны требования «одного окна», компактности, гибко-

сти, быстрого поиска информации, указанные в п. 4.2 «Интерфейс пользователя».

15.2. Сервисы ЛКК

15.2.1. Организация процедуры доступа клиента к ЛКК

Доступ клиентов к ЛКК производится через Web-доступ с использованием ссылки доступа с

главной страницы сайта Компании. Весь трафик, передаваемый между клиентом и ЛКК должен

шифроваться с использованием SSL сертификатов по протоколу TLS. При доступе в ЛКК клиент

должен видеть визуальное подтверждение защищенности сессии клиента при соединении с ЛКК

(подсветка адресной строки цветом, символ «замка» и пр.).

Идентификация (процедура распознавания абонента по его идентификатору) пользова-

теля в ЛКК производится с использованием предназначенного Идентификатора пользо-

вателя. В качестве Идентификатора пользователя для ФЛ используется номер лицевого

счета, для ЮЛ – номер договора. Идентификатор пользователя хранится в ЛКК в за-

шифрованном виде.

В ЛКК должна быть реализована процедура взаимной аутентификации (проверки под-

линности). Проверка подлинности Компании проводится путем вывода информации о

владельце SSL сертификата с возможностью проверки данных сертификата на сайте

выдавшей его организации. Аутентификация пользователя в ЛКК производится путем

ввода Пароля, который хранится в ЛКК в зашифрованном виде.

Механизм авторизации (получения прав пользователя в системе) в ЛКК должен ограни-

чивать доступ каждого пользователя ЛКК исключительно к «собственным» данным

(персональные данные абонента, его договор, лицевой счет, данные начислений и оплат

и пр.) и принципиально исключать возможность любого доступа пользователя ЛКК к

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

администраторов ЛКК, которые не должны иметь возможности доступа и изменения

данных других пользователей. После успешной авторизации пользователя в ЛКК про-

исходит поиск и подбор данных клиента в соответствии с введенным идентификатором.

Пользователи ЛКК должны иметь возможность самостоятельного изменения пароля

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

пользователь обязательно должен еще раз указать свой текущий пароль, в ходе проце-

дуры восстановления – пользователь получает по e-mail/SMS персональную ссылку на

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

пользователь должен ввести новый пароль, подтвердить его (в поле подтверждения ну-

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

«символы с картинки» (CAPTCHA). При желании пользователь ЛКК может также от-

править новый пароль на свои контактный e-mail и/или мобильный телефон (SMS).

Механизм назначения пароля новым пользователям должен предусматривать как воз-

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

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

ром ЛКК требованиям к безопасности паролей. Пример таких требований: «время жиз-

Стр. 56

ни» пароля, максимальная частота смены пароля, минимальная и максимальная длина

пароля, минимальные требования к безопасности пароля – использование букв / цифр /

специальных символов / неповторяемость последних N паролей, автоблокирование

учетной записи пользователя в ЛКК на заданный временной период при нарушении

правил ввода пароля с уведомлением администратора ЛКК.

Учетная запись пользователя в ЛКК должна автоматически создаваться при регистра-

ции в CRM данных договора/лицевого счета. Пароль нового пользователя ЛКК должен

автоматически генерироваться и пересылаться на зарегистрированные в CRM контакт-

ные e-mail и/или мобильные телефоны (SMS).

Администратор ЛКК должен иметь возможность задавать период времени, после кото-

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

15.2.2. Доступ к персональной информации

Просмотр данных абонентского учета, и договоров в частности:

информация по объекту обслуживания и абоненту (адрес объекта обслуживания,

наименование абонента, для ЮЛ дополнительно регистрационные данные и

банковские реквизиты, контактная информация (телефон, e-mail, факс), специ-

альные параметры – кол-во льготников, газовая/электроплита и пр.);

данные лицевого счета / договора (№, дата заключения), также желательно хра-

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

нений в условиях договора;

справочная информация по ТУ и ПУ абонента;

информация по действующим льготам и истории изменения льгот (пример - вид

льготы, период действия льготы, ФИО льготника, %/сумма льготы);

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

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

данных для поставки ЭЭ - вид услуги, название тарифа, период действия, кате-

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

измерения, величина тарифа).

Изменение контактной информации абонента (e-mail, факс, телефоны).

Прочая информация по абоненту должна изменяться через систему CRM сотрудниками

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

15.2.3. Работа с показаниями ПУ

Просмотр истории показаний (наименование ТУ, номер ПУ, дата регистрации показа-

ний, зона, показание, источник показаний: абонент, Компания, наименование сетевой

организации или компании-партнера - при получении показаний ПУ через третьи сто-

роны). Показания и источник должны выводиться на основании результатов процедуры

утверждения показаний для проведения.

Ввод текущих показаний ПУ. Автоматический контроль даты ввода, допустимых зна-

чений (текущие показания ПУ меньше предыдущих или очень отличаются на порядок)

и передача в CRM через механизм интеграции (с указанием источника «Введена або-

нентом»).

15.2.4. Просмотр информации о взаиморасчетах

Стр. 57

Просмотр данных (вид услуги/начисления, дата, сумма) о поступивших платежах за вы-

бранный период. (Платежи, временно не распределенные по видам услуг/начислениям,

также должны быть доступны для просмотра.)

Просмотр данных о фактических / плановых начислениях (вид услуги/начисления, пе-

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

Должна быть возможность просмотра дополнительной детализации по начислениям,

как пример, для услуг поставки ЭЭ: наименование ТУ, номер ПУ, тариф, показания ПУ

на конец периода (если есть), вид алгоритма расчета начислений (по ПУ, нормативам и

пр.), расход к начислению, ставка тарифа, учет льгот.

Просмотр существенных параметров дополнительных начислений (штрафы, пени и

пр.), как пример: период, ставка%, сумма начисления.

Текущий баланс – величина дебиторской/кредиторской задолженности на текущую да-

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

полненных на основании других данных из ЛКК (Текущий баланс = Баланс на начало

периода – Начисления за период + Оплаты за период).

15.2.5. Выставление документов начисления / оплаты

Печать заранее сформированных документов начисления (акты, счета-фактуры) и опла-

ты (счета, квитанции) на основании данных из БС (см. п.Ошибка! Источник ссылки

не найден. «Ошибка! Источник ссылки не найден.»), полученных через механизмы

интеграции.

Формирование новых документов оплаты на основании выбранного метода расчета: по-

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

ных извещений (плановые начисления). При выборе расчета по показаниям ПУ у поль-

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

формирования документов оплаты.

Указанные документы формируются исключительно в БС, передаются обратно в ЛКК

через механизмы интеграции. В системе БС должен быть реализован отдельный меха-

низм, сопоставляющий данные запроса пользователя ЛКК на формирование документов

оплат с уже подготовленными документами и автоматически аннулирующий «лишние»

документы по заданным правилам.

Возможность отправки документов оплаты на контактный e-mail с использованием ме-

ханизмов рассылки CRM (через механизмы интеграции).

15.2.6. Оплата on-line

On-line оплата платежной банковской картой или через подключенные системы элек-

тронных платежей (QIWI-кошелек, Yandex-деньги, Web-money и пр.).

15.2.7. Регистрация и отслеживание истории заявок и обращений

Основные функции:

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

речня услуг. Каждый вид услуги должен поддерживать ведение набора общих и специ-

фических параметров, определяющих ее характеристики. Пример видов услуг: продажа

ПУ ЭЭ, установка ПУ ЭЭ, замена ПУ ЭЭ, установка ПУ расхода воды, энергосервис,

энергоаудит, продажа страховок, продажа кондиционеров, изменение персональных

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

контактный e-mail информационное письмо с описанием содержания сформированной

Стр. 58

заявки и сопутствующей информацией (ответственный со стороны компании, плановые

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

Отслеживание изменения статусов обработки заявок и результатов работ по заявкам не-

посредственно в ЛКК.

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

кам с последующим получением уведомлений на контактный адрес e-mail и/или теле-

фон (SMS).

15.2.8. Обратная связь

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

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

работы подразделений Компании, предложения по расширению функционала ИС Ком-

пании (ЛКК, Контакт-центр) и пр. По окончании процедуры регистрации обращения

клиент получает на свой контактный e-mail информационное письмо с текстом сделан-

ного обращения и сопутствующей информацией (ответственный со стороны компании,

плановые сроки ответа на обращения, рекомендуемые действия и пр.).

Возможность отслеживания обращений и ответов на них непосредственно в ЛКК.

Подписка на получение информации о результатах рассмотрения обращения на кон-

тактный адрес e-mail и/или телефон (SMS).

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

– см. Ошибка! Источник ссылки не найден. «Ошибка! Источник ссылки не най-

ден.».

15.2.9. Информационный обмен

Общие новости Компании (изменения в перечне предоставляемых услуг и их парамет-

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

разделений и пр.).

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

Справочно-нормативная информация по тематике.

Регламенты и процедуры: заключение договоров, предоставление показаний ПУ, про-

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

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

Подписка новостные и информационные рассылки Компании согласно структуриро-

ванному рубрикатору с периодическим получением на контактный e-mail краткого опи-

сания и ссылок на тематические статьи.

Стр. 59

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

16.1. Фиксация данных о каждом месте обслуживания или адресе, обслуживаемом энергосбыто-

вой компанией как “объекте обслуживания”;

16.2. Ведение электронной «картотеки» помещений юридических лиц-объектов обслуживания

ООО «ГЭСК» с ведением необходимых данных по зданию или помещению;

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

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

ниям;

16.3.1. Узлы (станции, подстанции, КТП, ТП и т.д.)

16.3.2. Секции шин

16.3.3. Присоединения

16.3.4. Измерительные комплексы

16.3.5. Устройства сбора и передачи данных (УСПД)

16.4. Ведение географических данных;

16.5. Ведение для специальных и социальных объектов обслуживания требований обеспечения

жизнедеятельности;

16.6. Обеспечение ведения неограниченного числа точек учета для одного объекта обслужива-

ния, в которых непосредственно предоставляется услуга;

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

ных потребителей и суб-абонентов;

16.8. Конфигурирование связи точки учета с несколькими договорами об обслуживании для

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

цевые счета;

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

вания потребителя;

16.10. Обработка всех запросов потребителей, обеспечение организации и контроля выполнения

заказов на проведение работ;

16.11. Диспетчирование организации работ и выдачи наряд-заказов для проведения работ на объ-

ектах обслуживания потребителей;

16.11.1. Установка прибора учета;

16.11.2. Снятие прибора учета;

16.11.3. Поверка прибора учета;

16.11.4. Замена прибора учета;

16.11.5. Подключение и отключение услуги;

16.11.6. Проведение инструментальных обследований;

16.12. Создание запросов массовых подключений и обновления данных по объектам обслужива-

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

16.13. Проверка статусов лицевых счетов всех нежилых помещений здания;

16.14. Поддержка различных типов приборов учета электроэнергии (одно-, двух-тарифные и про-

чие типы приборов учета электроэнергии);

16.15. Регистрация и ведение данных по приборам учета;

16.15.1. Место установки прибора учета;

16.15.2. Тип прибора учета и его характеристики;

16.15.3. Применяемый тариф;

16.15.4. Данные для расчета фактического потребления;

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

учета.

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

16.17. Автоматизированный ввод показаний потребления из файлов;

Стр. 60

16.18. Автоматическая выгрузка показаний потребления в файл;

16.19. Поддержка ручного ввода показаний приборов. Портал ввода показаний приборов учета

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

учета в соответствии с маршрутным листом;

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

манных персональных компьютеров;

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

рование контрольных обходов;

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

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

16.23. Регистрация информации об источнике данных о показаниях приборов учета (дата снятия

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

АИИСКУЭ, комментарии потребителей и т.п.);

16.24. Уточнение данных показаний приборов учета до выставления счета;

16.25. Внесение записей, корректирующих сумму начислений, и учет корректировки сумм при

следующем выставлении счета в период, когда счет уже выставлен;

16.26. Проверку корректности значений показаний при вводе на непротиворечивость и макси-

мальное и минимальные значения;

16.27. Автоматическое обнаружение ошибок по заданному в алгоритме проверки параметру

(проверка мин-макс, отрицательное или нулевое потребление, переход через «0», сравне-

ние с профилем и т.д.) с ведением протокола ошибок и фиксацией типа ошибки;

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

17. Требования к автоматизации интегрального и интервального биллинга

17.1. Всесторонняя обработка данных потребления, работа с различными коэффициентами пре-

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

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

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

ряемым потреблением;

17.3. Расчет начислений по однократным начислениям и сборам, (например, оплата услуг за

подключение, повторное подключение, штрафы, пени);

17.4. Расчет начислений для сложных планов расчета и многокомпонентных тарифов;

17.5. Поддержка сложных расчетных планов с комбинацией фиксированных платежей, плате-

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

ний потребления, налогов, скидок и т.д.;

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

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

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

17.7. Расчет начислений по внутренним тарифам, внешним данным потребления и с использо-

ванием внешних тарифов для обеспечения сквозного и многостороннего биллинга;

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

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

действий, включая корректировки и отмены;

17.9. Выполнение расчетов объемов потребления на основании показаний приборов учета;

Стр. 61

17.10. Выполнение расчетов объемов потребления балансовым методом с возможностью гибкого

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

потребления;

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

показаний в течение расчетного периода в зависимости от причины наличия множествен-

ных показаний (замена прибора учета в течение месяца, кража прибора учета, расчета по

нормативам и т.п.);

17.12. Выполнение расчета на основании нормативов потребления, договорных величин;

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

приборов учета в расчетный период (на основании среднесуточного расхода, по установ-

ленной мощности, по максимальной нагрузке и т.д.);

17.14. Формирование авансовых начислений на основании нормативов потребления и фактиче-

ского потребления за предыдущие периоды с учетом утвержденного в договоре процента

авансовых платежей;

17.15. Проведение перерасчетов по недопоставкам или поставкам услуг ненадлежащего качества;

17.16. Предварительный расчет начислений/сторнирования с возможностью последующего уда-

лением результатов расчетов;

17.17. Автоматический запуск расчет и хранение значений величины начислений по событию

ввода показания прибора учета за расчетный период при внесении показаний приборов

учета как оператором в ручном режиме, так и при использовании интерфейса управления

энергоданными;

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

вводе показания прибора учета за расчетный период независимо от способа ввода (опера-

тором в диалоговом режиме или через автоматизированный интерфейс с системой

АИИСКУЭ);

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

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

ления;

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

использовании нормативов потребления при наступлении даты расчета;

17.21. Ручное и автоматическое утверждение результатов расчетов, как в единичном, так и груп-

повом утверждение результатов расчетов;

17.22. Ведение истории результатов расчета;

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

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

данных только разницы между уже рассчитанным значением и результатом перерасчета, в

случае закрытого периода;

17.24. Ведение групп тарифов и планов расчетов для разных групп потребителей и видов услуг;

17.25. Ведение истории изменения тарифов и обеспечение формирования расчетов начислений за

периоды действия этого предыдущего значения при отсутствии ограничений на количест-

во хранимых значений в истории тарифа;

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

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

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

ках одного плана расчета;

Стр. 62

17.27. Поддержка расчета начислений по разовым услугам с фиксированной ценой за факт оказа-

ния услуги;

17.28. Поддержка расчетов начислений в зависимости от параметров предоставляемой услуги;

17.29. Классификация / сортировка тарифов и планов расчета по критериям применимости по от-

ношению к услуге, группе потребителей, принадлежности к территориальной или органи-

зационной единицы и т.д.;

17.29.1. Уровень напряжения

17.29.2. Регулируемый, нерегулируемый, составляющие регулируемого тарифа

17.29.3. Дифференциация по числу часов использования мощности

17.29.4. Дифференциация по величине максимальной мощности

17.29.5. Мощность, электроэнергия, электроэнергия приобретаемая в целях компен-

сации потерь.

17.29.6. Тарифы за ограничение (отключение) подачи электроэнергии

17.29.7. Прочие.

17.30. Создание и ведение групп тарифов и планов расчета;

17.31. В части расчетов за электроснабжение - функция расчетов потребления и формирования

начислений;

17.31.1. «Расход по прибору учета (ПУ)»: значение вычисляется по показаниям при-

бора коммерческого учета;

17.31.2. «Постоянный расход»: значение вычисляется по постоянной величине;

17.31.3. «Алгоритм расчета»: значение вычисляется из значений других параметров,

по введенной формуле;

17.31.4. «Долевой расход»: значение вычисляется как часть значения другого пара-

метра в соответствии с введенной процентной величиной.

17.32. В части расчетов за дополнительные услуги функция ведения тарифов и расчетов начисле-

ний;

17.33. Расчет начислений для различных типов услуг (по способу расчета начислений);

17.33.1. Услуг с фиксированной ценой за определенный период времени (день, месяц,

год);

17.33.2. Услуг, стоимость которых зависит от объема потребления, с фиксированной

ценой за единицу потребления;

17.33.3. Услуг с фиксированной ценой за оказание услуги – разовых услуг;

17.33.4. Услуги купли-продажи с фиксированной ценой за единицу товара;

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

17.35. Ведение пополняемого справочника тарифов;

17.36. Расчет начислений и формирование счета за отпущенную энергию сверх лимита (расчет по

повышенному тарифу);

17.37. Начисление/сторнирование фиксированной суммы (штрафные санкции, перераспределе-

ние общих потерь системы на потребителей без приборов учета);

17.38. Начисление суммы за хищения по регистрации факта хищения с указанием объема хище-

ния электроэнергии. Начисление штрафа за факт хищения по регистрации факта хищения в

зависимости от объема хищения;

17.39. Выполнение авансовых начислений на основании расчета авансового потребления;

17.40. Автоматическая проверка начислений на непротиворечивость;

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

ния по событию при вводе результатов расчета потребления за расчетный период;

Стр. 63

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

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

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

ния по событию календаря с датами наступления начисления;

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

ния при использовании нормативов потребления после наступления даты расчета;

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

способом утверждения начислений;

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

начисленных сумм при изменении результатов расчета потребления, тарифов, c учетом

авансовых начислений и с сохранением истории перерасчетов;

17.47. Возможность формирования предварительных (пробных) начислений/сторнирования с по-

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

17.48. Формирование потока операций и кейсов для обработки случаев хищения: регистрация

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

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

ный счет за хищения, а также указывать начисления за хищения в составе счета за услугу

по предоставлению похищенного энергоресурса;

17.49. Расчеты с сетевыми организациями по различным схемам (с «держателем котла», с каждой

сетевой организацией в отдельности) за услуги и по оплате потерь.

18. Требования к автоматизации выставления финансовых документов

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

с измеряемым и не измеряемым потреблением;

18.2. Выставление счетов и платежных требований по однократным начислениям и сборам, (на-

пример, оплата услуг за подключение, повторное подключение, штрафы, пени);

18.3. Включение в счет расчетов сторонних организаций для выставления единого консолиди-

рованного счета;

18.4. Формирование и просмотр на экране счета и платежного требования к оплате для одного

потребителя;

18.5. Формирование счетов и передача данных на конвертировочную машину для формирования

писем потребителям с сортировкой корреспонденции по определенным правилам (сорти-

ровка по почтовым индексам и т.п.);

18.6. Формирование авансовых счетов и платежных требований для юридических лиц;

18.7. Формирование, печати и хранения истории счетов-фактур, счетов, платежных требований;

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

(суб-абоненты);

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

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

так же единого счета абонента;

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

группам услуг;

18.11. Возможность выставления потребителю единого счета за все потребляемые им услуги (по-

требление электроэнергии, газа, воды, другие услуги);

18.12. Формирование в процессе выставления счетов для каждого типа потребителей соответст-

вующего, регламентированного набора документов;

Стр. 64

18.13. Формирование сводной ведомости по выставленным счетам;

18.14. Формирование и печать расшифровок (комментариев) по начислениям за любой период

времени по любому абоненту или группе абонентов;

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

18.16. Возможность проставить штриховой код при формировании бумажного счета (квитанции);

18.17. Сохранение в системе выставленных счетов в течение заданного времени с возможностью

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

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

ты;

19. Требования к автоматизации учета поступивших оплат

19.1. Управление финансовыми поступлениями всех типов;

19.2. Работа с авансовыми платежами и планами авансовых платежей;

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

счета (включая электронный перевод средств (ЭПС), прямое дебетовое списание и платежи

с помощью кредитных карт);

19.4. Обеспечение ведения бухгалтерского учета для целей формирования Книги поку-

пок/продаж, оборотно-сальдовых ведомостей;

19.5. Создание и предоставление для дальнейшего использования в учетной системе энергосбы-

товой организации (ЭСО) бухгалтерских проводок с отражением на соответствующих бух-

галтерских счетах;

19.6. Выполнение погашения начисленной суммы;

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

данных;

19.8. Автоматическая загрузка данных о поступлениях через интерфейс «Клиент Банк», сопос-

тавление начисленной сумме, сохранение в базе данных;

19.9. Возможность ввода данных о наличных платежах из файла в предопределенном формате;

19.10. Ручное и автоматическое соотнесение платежа начисленной сумме (части начисления, не-

скольким начислениям) в соответствии с определенными правилами;

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

сумм оплаты на соответствие данным банковской выписке (Тендер-контроль);

19.12. Поддержка проведения «сверки» платежей со списком платежей, в частности, поиск пла-

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

лям участка, отделения), группировка платежей;

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

сканирования штрих-кодов);

19.14. Индоссирование и распечатка чеков;

19.15. Наличие режима возврата сумм ошибочных платежей;

19.16. Невозможность удаления результатов регистрации поступления и возврата оплаты;

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

периода;

19.18. Формирование платежных требований на основании договора о безакцептном / акцептном

списании для оплаты итоговых и авансовых начислений;

19.19. Контроль транзакционной завершенности: отсутствие не рассчитанных потребителей, не-

завершенных операций по всем модулям и т.д.;

Стр. 65

19.20. Проведение операции «Закрытие периода», которая определяет границу между двумя рас-

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

жи, сформированные начисления и корректировки будут отнесены к следующему расчет-

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

корректировкой счетов-фактур в предыдущем периоде;

19.21. Контроль полноты выполнения и завершенности всех бизнес-процессов, предшествующих

закрытию периода (отсутствие незавершенных транзакций);

19.22. Проведение операции «Закрытие периода» по одному клиенту и по группе потребителей

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

показателей потребителя после операции «Закрытие периода» по закрытому периоду.

Обеспечение запрета на проведение перерасчетов в закрытом учетном периоде.

19.23. Списание кредиторской задолженности.

20. Требования к автоматизации управлению дебиторской задолженностью

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

жающего в каждый момент времени текущее состояние взаиморасчетов с ним;

20.2. Расширенная функциональность по работе с задолженностями, взысканиями и сборами;

20.3. Инструменты контроля долга и стимулирования оплаты потребителя;

20.3.1. Напоминания

20.3.2. Предупреждения

20.3.3. Ограничения предоставления услуг

20.3.4. Отключения

20.3.5. Расторжение отношений

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

жденными бизнес-правилами компании.

20.4. Фоновый мониторинг и контроль по запросу просроченных задолженностей с настройкой

автоматизированных процессов взыскания в соответствии с нормативными требованиями

и требованиями законодательства;

20.5. Отмена процессов взыскания дебиторской задолженности по полной или частичной опла-

те, в зависимости от того, как это определено компанией;

20.6. Расчет и начисление штрафов, пеней, гос. пошлины за задержку платежа с автоматической

генерацией и влиянием на сальдо счета в соответствии с правилами, определенными для

каждой услуги на конкретном лицевом счету;

20.7. Оценка кредитоспособности по каждому лицевому счету, настроенная на основе финансо-

вого события;

20.8. Оценка кредитоспособности на основании задержек платежей или недостатка средств на

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

20.9. Разделение потребителей на категории, определяющие сценарии работы с дебиторской за-

долженностью, при помощи атрибута «категория дебитора»;

20.10. Формирование и хранение в системе списка потребителей («Список №1»), работа с кото-

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

20.10.1. Потребители, которые находятся на контроле руководства;

20.10.2. Сгруппированные потребители (VIP-клиенты, одноставочние, двухставоч-

ные, приравненные к населению, группировка по максимальной мощности, прочие).

20.11. Возможность задания различных сценариев работы с потребителями в зависимости от типа

потребителя и «категории дебитора»;

Стр. 66

20.12. Автоматическое формирование и печать предупреждения о задолженности в предопреде-

ленном формате для списка потребителей (в массовом порядке) и для одного потребителя;

20.13. Формирование, редактирование и удаление документов «Предупреждение о задолженно-

сти» для сформированного списка потребителей (в пакетном режиме) и для одного потре-

бителя (в ручном режиме);

20.14. Учет и ведение истории сформированных и отправленных предупреждений о задолженно-

сти;

20.15. Формирование, редактирование и печать документа «Уведомление об ограничении» для

сформированного списка потребителей (в пакетном режиме) и для одного потребителя (в

ручном режиме) с учетом сформированных уведомлений и ведением истории их выставле-

ния;

20.16. Формирование, редактирование и печать документа «Уведомление об ограниче-

нии/отключении» для потребителя. Возможность автоматизированной рассылки копий

«Уведомление об ограничении/отключении» отдельным потребителям посредством элек-

тронной почты. Учет сформированных и доставленных уведомлений об ограниче-

нии/отключении;

20.17. Формирование документов «Заявка на отключение/ограничение абонентов» для эксплуа-

тирующей сетевой организации;

20.18. Автоматическая отмена процессов взыскания задолженности по полной или частичной оп-

лате, в зависимости от того, как это определено правилами работы на РРЭ и регламентом

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

20.19. Формирование на основе документа «Заявка на включение абонентов» с возможностью

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

20.20. Ведение для каждого потребителя «Истории контактов с потребителем», в котором сохра-

няются записи обо всех действиях, произведенных в отношении потребителя в рамках

процесса «Управление дебиторской задолженностью», в частности:

• отправка предупреждения о задолженности (с отметкой о получении);

• отправка уведомления об отключении / ограничении (с отметкой о получении);

• включение потребителя в распоряжение на отключение (с указанием номера и даты рас-

поряжения).

20.21. Списание дебиторской задолженности.

20.22. Ведение исполнительных листов.

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

Ключевые показатели деятельности должны быть разработаны в ходе выполнения работ

(Раздел III, пп.1, 2, 3) и согласованы с Заказчиком.

Минимальный набор результатов:

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

ком.

Описание процесса, зафиксированное системой автоматизации методом настроек и мини-

мального программирования.

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

Стр. 67

Направления, по которым должны измеряться КПЭ с помощью автоматизированной системы:

21.1. Биллинг

• Контроль расчѐтов, перерасчѐтов, выставления счетов (например, доля клиентов, по ко-

торым сделан расчет в течение суток после появления исходных данных для расчѐта)

21.2. CRM

• Работа с обращениями и жалобами клиентами (например, количество обращений без

ответа более Х часов/дней);

• Работа колл-центра (например, количество клиентов, ожидающих ответ оператора, бо-

лее Х минут);

• Работа личного кабинета (например, доля обращений клиентов через личный кабинет от

общего кол-ва обращений клиентов);

• Работа ЦОКов - электронная очередь (например, количество человек в очереди)

21.3. Процессная модель

• Договорная работа (например, количество запросов по заключению (изменению) дого-

воров, обрабатываемых более Х часов/дней);

• Взыскание ДЗ (например, количество клиентов, не оплативших ДЗ после обзвона долж-

ников);

• Контроль взаиморасчѐтов с сетевыми организациями (например, количество клиентов,

по которым не введены в систему необходимые первичные документы (акты съѐма показа-

ний и пр.));

• Контроль взаиморасчѐтов с поставщиками дополнительных услуг (например, количест-

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

21.4. Ситуационная модель

• Исковая деятельность (например, количество должников, по которым не сформирован

(или подан) иск в течение Х дней после обзвона должников);

• Ограничения (например, количество должников, по которым не сформировано (или не

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

21.5. Централизация

Набор КПЭ будет формироваться Заказчиком в ходе осуществления автоматизации процессов

Компании.

22. Требования к составу выходных форм и отчетов

22.1. Формирование оперативной отчетности:

22.1.1. Счет

22.1.2. Счет-фактура

22.1.3. Ведомость электропотребления


22.1.5. Отчет о поступивших платежах в разрезе источников (в режиме on-line)

22.1.6. Приходный кассовый ордер

22.1.7. Расходный кассовый ордер

22.1.8. Акт приема-передачи электроэнергии и мощности

22.1.9. Реестр поступивших оплат по неопознанным абонентам

22.1.10. Справка о задолженности

22.1.11. Приглашение на сверку

Стр. 68

22.1.12. Акт о расходе электроэнергии


22.1.14. Акт выверки взаиморасчетов

22.1.15. Договор Энергоснабжения (купли-продажи) с приложениями

22.1.16. Наряд на работу

22.1.17. Сведения о потреблении и оплате абонента

22.1.18. Лист обхода

22.1.19. Карточка потребителя

22.1.20. Квитанция для оплаты

22.1.21. Финансово-лицевой счет

22.1.22. Форма оперативного контроля (ЕНН-2)

22.2. Формирование статистической отчетности:

22.2.1. 46 форма по эл.энергии в разрезе юридических лиц

22.2.2. Структура полезного отпуска электроэнергии

22.2.3. Отчет о поступивших платежах в разрезе источников

22.2.4. Потребление электрической энергии от источника в разрезе потребителей

22.2.5. Начисление по методам расчета


22.2.7. Реестр неоплаченных платежных документов

22.2.8. Реестр неоплаченных счетов-фактур

22.2.9. Книга продаж и дополнительные листы

22.2.10. Книга покупок и дополнительные листы

22.2.11. Журнал регистрации счетов-фактур

22.2.12. Журнал регистрации счетов

22.2.13. Журнал учета списаний и доначислений

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

22.2.15. Кассовая книга

22.2.16. Кассовый отчет

22.2.17. Оборотная ведомость по договору

22.2.18. Оборотная ведомость по группе договоров (по техникам)

22.2.19. Оборотная ведомость по отделению

22.2.20. Оборотная ведомость общая

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

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

22.2.22. Оборотная ведомость по компенсации расходов в связи с изменением дого-

ворной величины потребления

22.2.23. Оборотная ведомость по пени

22.2.24. Оборотная ведомость по 395 ст.

22.2.25. Оборотная ведомость по гос.пошлине

22.2.26. Реализация энергии по договорам

22.2.27. Ведомость по перерасчетам

22.2.28. Ведомость о полезном отпуске и реализации электрической энергии – 8 ГП

22.2.29. Отчет по форме 9-ПС

22.2.30. Расчет пени

22.2.31. Расшифровка кредитовой задолженности

22.2.32. Справка по перерасчетам предыдущих периодов

Стр. 69

22.2.33. Справка по закрытию задолженности предыдущих периодов

22.2.34. Журнал выставленных платежных требований

22.2.35. Реестр переданных платежных документов на инкассо.

22.2.36. Ведомость поступлений денежных средств на расчетные счета ООО «ГЭСК»

22.2.37. Ведомость поступления сумм сальдо с субсчетов отделений на расчетные

счета ООО «ГЭСК»

22.2.38. Объем поставки электроэнергии по группам потребителей в разрезе сетевых

организаций

22.2.39. Журнал регистрации приходно-кассовых ордеров и расходно-кссовых орде-

ров

22.2.40. Справка по кредиторской задолженности

22.2.41. Справка по дебиторской задолженности


22.2.43. Расчет процентов по ст.395 ГК РФ

22.2.44. Справка о поступлении на расчетный счет

22.2.45. Справка по нерасшифрованным суммам

22.2.46. Отчет по сберкассам

22.2.47. Итоговые данные по банкам

22.2.48. Отчет по квартирным группам

22.2.49. Список задолженности по бюджетным организациям

22.2.50. Ведомость потребления для предоставления в сетевую организацию

22.2.51. Отчет по КТП и Фидерам

22.2.52. Отчет по трехфазным счетчикам

22.2.53. Акт об оплате электроэнергии населением

22.2.54. Инвентаризационная опись

22.2.55. 26 форма ЖКХ

22.2.56. Список нарядов

22.2.57. Отчет по штрафникам

22.2.58. Список отключенных абонентов

22.2.59. Отчет по выверки и контролю срока поверки

22.2.60. План-отчет по контролерам

Стр. 70

РАЗДЕЛ XIX. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО РАЗРАБОТКЕ И

ВНЕДРЕНИЮ СИСТЕМЫ

7. Организация контроля хода выполнения работ

Работы по разработке и внедрению Системы должны быть организованы поэтапно. Этапы мо-

гут осуществляться последовательно или одновременно. Со стороны Участника открытого запроса

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

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

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

Перевод Системы в промышленную эксплуатацию должен сопровождаться этапом методоло-

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

плана дальнейшего развития системы.

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

формализованные методологии ведения Проекта разработки и внедрения Системы.

8. Требования к ИАС

8.1. Требования к техническому решению построения информационно-аналитической системы

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

8.1.2. Аутентификация – идентификация пользователя с помощью идентификатора и па-

роля.

8.1.3. Технология однократной регистрации в системе – однократный ввод идентификаци-

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

тентификация.

8.1.4. Авторизация – предоставление полномочий пользователю для работы с содержани-

ем портала.

8.1.5. Интегрированное управление пользователями – обеспечение централизованного ад-

министрирования пользователей.

8.1.6. Возможность расширения функциональности системы.

8.2. Требования к функциональности информационно-аналитической системы.

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

ятия по группам процессов, входящих в объем Проекта.

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

лями посредством стандартного интерфейса.

8.2.3. Обеспечение возможности проведения всестороннего анализа большого объема

данных и формирование отчетности на их основе;

8.2.4. Возможность накопления, хранения и преобразования данных;

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

Окончательный список отчетов будет определен в техническом задании на Систему;

9. Требования к нормативно-справочной информации (НСИ)

9.1. Создание и унификация НСИ для предприятия включает в себя:

разработку единой для всех подразделений структуры справочников для АСУ СЭРП;

унификацию (приведение существующих справочников в соответствие с разработанной

структурой);

Стр. 71

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

вочников

заполнение справочников и классификаторов данными;

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

выверка данных в справочниках, проверка на непротиворечивость.

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

структурой платформы.

10. Требования к интеграции с другими системами

10.1. Обеспечить интеграцию со следующими информационными системами:

10.1.1. 1С 8.2 УПП;

10.1.2. Система электронного документооборота «Директум».

10.1.3. Система управления электронной очередью

10.1.4. Call-центр

10.2. При разработке интеграционных решений должны применяться только стандартные откры-

тые средства интеграции ПО;

10.3. Требования к интеграции с другими системами должны быть уточнены на этапе разработки

Технического задания.

11. Требования к проведению приемки работ

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

пытаний на территории и оборудовании ООО «ГЭСК».

Методика проведения испытаний должна быть представлена Исполнителем и согласована с

Заказчиком.

12. Рекомендации по срокам выполнения работ

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

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

Стр. 72

РАЗДЕЛ XX. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РАБОТ ПО МИГРАЦИИ ДАННЫХ

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

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

ности.

Проведение миграции данных включает в себя:

анализ исходных данных;

разработка системы форматов данных;

извлечение, проверка и очистка данных;

трансформация данных;

загрузка данных в систему.

Стр. 73

РАЗДЕЛ XXI. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ И ЗАЩИТЕ ИНФОРМАЦИИ

1. Требования по безопасности

Требования к Системе включают:

Система должна обеспечивать обработку конфиденциальной информации.

Применяемые в Системе средства и технологии защиты, объединяемые в

Систему защиты информации (СЗИ) Системы, должны обеспечивать открытость архитек-

туры и обладать свойствами модульности, масштабируемости и возможности адаптации

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

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

строиться на основе ограниченного числа типов и версий приобретаемого программного

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

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

Развернутые и уточненные требования к структуре, функциям и средствам СЗИ должны

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

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

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

возможных моделей нарушителей.

СЗИ должна предполагать независимость функционирования каждой из

входящих в ее состав структурных Систем защиты. Нарушение функционирования любой

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

защиты.

Средства защиты, входящие в состав СЗИ, должны иметь развитые средства регистрации

критических системных событий в электронных журналах и средства оперативного опо-

вещения об этих событиях администраторов безопасности.

3. Требования к защите информации от несанкционированного доступа.

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

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

ным ПО;

стандартными средствами используемой СУБД;

средствами ИВК (идентификация пользователей и разграничение прав

доступа).

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

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

ми;

многоуровневую систему защиты: защита на уровне подсистемы, уровне

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

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

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

пространства, сетевой нагрузки и т.п.);

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

ведение журнала изменений коммерческих данных, инициированных

оператором.

Стр. 74

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

группам операций.

Стр. 75

РАЗДЕЛ XXII. ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ ПОДГОТОВКИ ПОЛЬЗОВАТЕЛЕЙ

К ЭКСПЛУАТАЦИИ СИСТЕМЫ

7. Категории пользователей

Разработка и ввод в промышленную эксплуатацию Системы предусматривает подготовку

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

категорий пользователей:

администратор;



бизнес-аналитик.

8. Направления подготовки администратора приложений

Администратор Системы должен получить знания и навыки по:

генерации Системы;

конфигурированию технических характеристик Системы;

контролю доступа;

резервному копированию и восстановлению;

конфигурированию меню;

связям с другими программными продуктами и системами;

передаче данных из/в приложения;

переносу на другие платформы;

другие (будет уточнено на этапе доработки Рабочего проекта)

9. Направления подготовки разработчика приложений

Разработчик должен получить знания и навыки по:

модификации и создании серверных компонентов Системы;

модификации и создании клиентских компонентов Системы;

модификации программного кода лицензионного программного обеспечения и созданию

новых программ при помощи встроенного языка программирования Системы;


10. Направления подготовки конечных пользователей

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

правлениям:


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

другие (будет уточнено на этапе доработки Рабочего проекта);

11. Направления подготовки бизнес - аналитиков

Должна быть произведена подготовка бизнес - аналитиков по следующим направлениям:


расширенные знания возможностей компонентов Системой;

возможности Системы в области формирования гибких аналитических отчетов;


Стр. 76

12. Аттестация пользователей

По окончанию проведения подготовки специалистов должна быть произведена проверка зна-

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

ных пользователей Системы.

Стр. 77

РАЗДЕЛ XXIII. ТРЕБОВАНИЯ К ОКАЗАНИЮ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ

В Проект должно быть включено обеспечение технической поддержкой.

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

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

ным уровнем технической поддержки со стороны компании-производителя ПО (вендора).

Предоставить описание требуемого уровня технической поддержки со стороны компании-

производителя ПО на этапе внедрения и дальнейшего развития Системы.

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

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

Стр. 78

РАЗДЕЛ XXIV. ТРЕБОВАНИЯ К СОПРОВОЖДЕНИЮ СИСТЕМЫ

В рамках Проекта разработки и ввода в промышленную эксплуатацию АСУ СЭРП Исполни-

тель должен обеспечить начальное сопровождение Системы, ИАС после ввода в эксплуатацию сро-

ком не менее 3 месяцев.

Стр. 79

РАЗДЕЛ XXV. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ РЕЗУЛЬТАТОВ РАБОТЫ

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

Руководство администратора;

Руководство пользователя;

Руководство бизнес-аналитика;

Руководство разработчика;

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

испытаний.

Стр. 80

РАЗДЕЛ XXVI. ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ

4. Требования к информационному обеспечению

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

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

циональных требований к системе и потребности обмена с внешними системами.

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

СУБД, поддерживающей такое представление данных;

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

информационных кубов на основе OLAP-решения.

4.2. Требования по использованию систем управления базами данными (СУБД)

4.2.1. В качестве Системы Управления Базой Данных должна использоваться высокопроизво-

дительная современная СУБД ORACLE, бесшовная интеграция которой с используемым

лицензированным ПО, на основе которого разрабатывается Система, должна быть под-

тверждена сертификатом производителя ПО.

4.2.2. Общие требования к используемой СУБД:

4.2.2.1. Поддержка реляционной модели базы данных;

4.2.2.2. Поддержка технологии клиент-сервер;

4.2.2.3. Поддержка многопроцессорной архитектуры;

4.2.2.4. Наличие средств создания индексов и кластеров данных;

4.2.2.5. Автоматическое восстановление базы данных;

4.2.2.6. Наличие механизма блокировки транзакций;

4.2.2.7. Реализация SQL, совместимого со стандартом ANSI 1992 г.

4.2.2.8. Поддержка стандартов ODBC и OLE DB;

4.2.2.9. Поддержка работы с XML;

4.2.2.10. Наличие встроенных средств контроля целостности баз данных;

4.2.2.11. Наличие встроенных средств резервного копирования базы данных;

4.2.2.12. Импорт и экспорт данных;

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

данных;

4.2.2.14. Совместимость с различными операционными системами;

4.2.2.15. Поддержка высокоскоростных сетевых протоколов;

4.2.2.16. Наличие графических средств администрирования;

4.2.2.17. Возможность контроля доступа к данным;

4.2.2.18. Централизованное управление пользователями;

4.2.2.19. Оптимизация запросов;

4.2.2.20. Наличие механизма встроенных процедур баз данных;

4.2.2.21. Наличие утилит для переноса данных из унаследованных систем;

4.2.3. Обеспечение безопасности данных на уровне сервера баз данных.

4.2.4. СУБД должна обеспечивать обмен и хранение информации неограниченного объѐма.

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

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

русский язык.

Стр. 81

6. Требования к программному обеспечению

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

Прикладное программное обеспечение Системы должно представлять собой совокупность

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

ние следующих требований:

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

цию, удаление и поиск данных, в том числе справочников Системы;

реализацию общих требований к Системе;

возможность конфигурирования и настроек Системы;

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

помощью штатного средства разработки;

автоматизированное создание выходных документов Системы с помощью средств разра-

ботки запросов и отчетов.

6.2. Требования к показателям назначения Системы

6.2.1. Автоматизированная система предназначена для работы в непрерывном (кругло-

суточном) режиме.

6.2.2. Система должна поддерживать работу пользователей, находящихся на

территориально разобщенных объектах.

6.2.3. Система должна формировать единое информационное пространство, в

котором взаимодействие процессов и пользователей обеспечивается за

счет общих информационных объектов.

6.2.4. Должна обеспечиваться возможность увеличения количества одновременно работаю-

щих пользователей.

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

всех потенциальных объектах внедрения.

6.2.6. Должен быть реализован принцип открытой архитектуры построения

системы, обеспечивающий возможность встраивания и взаимодействия с

любыми другими системами.

6.2.7. Непротиворечивость данных. Система должна автоматически контролировать дублиро-

вание данных и проверять информацию для устранения противоречивости. При одно-

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

механизмы разрешения конфликтов.

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

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

пределах корпоративной сети Заказчика.

6.3. Требования к надежности

Уровень надежности Системы должен обеспечивать выполнение утвержденного графика вы-

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

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

6.4. Требования к масштабируемости:

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

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

держки и дальнейшей модернизации:

Стр. 82

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

Инструменты миграции;

Инструменты архивирования;

Инструменты интеграции приложений;

Управление потоками операций и уведомления;

Формализованные плоские отчеты;

Управление проектами конфигурации;

Инструментарий разработчика.

6.5. Требования к системному программному обеспечению

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

функционирование модулей Системы, в том числе в многопользовательском и многопро-

цессорном режиме;

генерацию и сопровождение базы данных Системы;

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

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

защиту от несанкционированного доступа.

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

СУБД ORACLE.

В качестве клиентских ОС должны быть использованы ОС семейства Microsoft Windows 2003

/ XP, имеющиеся в наличии и предоставляемые Компанией.

6.6. Требования к каналам связи

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

ной пропускной способностью (512 кБит/сек)

6.7. Требования к обновлению версий лицензионного программного обеспечения

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

строек и изменений в новые версии лицензионного ПО с момента их получения Исполнителем, но не

позднее даты окончания поддержки предшествующей версии. Исполнитель должен производить ус-

тановку обновлений Лицензионного ПО по согласованию с Заказчиком.

6.8. Требования к рабочим станциям и серверам

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

серверов, необходимые для работоспособности Системы.

Лот №1 Технические и ... · Стр. 1 Приложение №2 к...

Documents