Техническое предложение на оказание услуг по Поставке, Установке и Настройке новой Биллинговой Системы для ОАО «Северэлектро» включая Обучение и Техническую Поддержку 1 РЕКВИЗИТЫ ДОКУМЕНТА Проект Поставка, Установка и Настройка новой Биллинговой Системы для ОАО «Северэлектро» включая Обучение и Техническую Поддержку Документ Техническое предложение Дата создания 16.01.2015 г. Дата изменения Редакция 1.0 Форма A4 КОНТАКТНАЯ ИНФОРМАЦИЯ Организация ООО «Сайнер» Фактический адрес: 308024, г. Белгород, пер. Харьковский, д. 36д тел. +7 (4722) 58-85-55 По организационным вопросам Директор по развитию бизнеса Ляпер Дмитрий Александрович [email protected] тел. сот. +7 (909) 945-89-47 По техническим вопросам Системный архитектор Маслов Александр Геннадьевич [email protected] тел. сот. +7 (961) 167-25-15 2 ОГЛАВЛЕНИЕ 1. ОБЩИЕ СВЕДЕНИЯ ................................................................................................... 6 1.1. Полное наименование Системы ............................................................... 6 1.2. Сведения о Заказчике ................................................................................... 6 1.3. Резюме Исполнителя .................................................................................... 6 1.4. Место оказания услуг .................................................................................... 7 1.5. Срок оказания услуг ...................................................................................... 7 1.6. Термины и определения .............................................................................. 7 2. НАЗНАЧЕНИЕ СОЗДАНИЯ СИСТЕМЫ ................................................................. 8 2.1. Назначение Системы..................................................................................... 8 3. ХАРАКТЕРИСТИКА ОБЪЕКТОВ АВТОМАТИЗАЦИИ ....................................... 9 3.1. Краткие сведения об объекте автоматизации ..................................... 9 3.2. Сведения об условиях эксплуатации Системы ................................ 11 3.3. Сведения о режимах эксплуатации Биллинговой системы ......... 11 4. ОПИСАНИЕ СИСТЕМЫ ........................................................................................... 11 4.1. Система в целом ........................................................................................... 11 4.1.1. Структура и функционирование Системы ................................... 12 4.1.2. Функциональные возможности Биллинговой системы ......... 21 4.1.3. Показатели назначения ....................................................................... 36 4.1.4. Допустимые пределы модернизации и развития ..................... 37 4.1.5. Вероятностно-временные характеристики, при которых сохраняется целевое назначение Биллинговой системы .............................. 37 4.1.6. Масштабирование .................................................................................. 38 4.1.7. Надежность .............................................................................................. 38 4.1.8. Эргономика и техническая эстетика ............................................... 38 4.1.9. Стандартизация и унификация ......................................................... 39 4.1.10. Интеграция Системы .......................................................................... 40 4.2. Технические характеристики Системы ................................................ 41 4.2.1. Виды обеспечения ................................................................................ 41 4.2.2. Таблица требований нового биллинга/Системы коммерческого управления 44 3 ОРГАНИЗАЦИЯ ПРОЕКТА ...................................................................................... 80 5. 5.1. Методология реализации проекта ......................................................... 80 5.2. Инвентарная таблица системы, затраты на поставку и монтаж 80 5.3. Инвентарная таблица Системы, Периодические затраты ............ 82 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ .............................................. 82 6. 6.1. Проведение предварительных испытаний ........................................ 82 6.2. Требования к проведению опытной эксплуатации ......................... 83 6.3. Требования к проведению приемочных испытаний (передача в постоянную эксплуатацию) ............................................................................................ 83 7. ОБУЧЕНИЕ И ОБУЧАЮЩИЕ МАТЕРИАЛЫ ...................................................... 84 7.1. Инструкция пользователей ...................................................................... 86 7.2. Руководство администратора ................................................................. 86 8. ДОКУМЕНТАЦИЯ НА СИСТЕМУ ........................................................................... 87 8.1. Уточненное техническое задание ........................................................... 88 8.2. Концептуальный проект ............................................................................ 88 8.3. Концепция полномочий.............................................................................. 88 8.4. Программа и методика испытаний ........................................................ 89 8.5. Требования к Программе предварительных испытаний .............. 89 8.6. Требования к Программе опытной эксплуатации ............................ 90 8.7. Требования к Программе приемочных испытаний ......................... 90 8.8. Протоколы испытаний ............................................................................... 91 8.9. Функционально-техническая спецификация разработок ............. 91 9. 8.10. Описание настроек ................................................................................... 91 8.11. Инструкция пользователей ................................................................... 92 8.12. Руководство администратора .............................................................. 92 8.13. Способ кодирования проектной документации ............................ 93 ТЕХНИЧЕСКАЯ ПОДДЕРЖКА СИСТЕМЫ ......................................................... 94 9.1. Поддержка пользователей / горячая линия ....................................... 94 9.2. Гарантийная поддержка ............................................................................. 94 10. ДОПУЩЕНИЯ И ОГРАНИЧЕНИЯ ПРОЕКТА ...................................................... 94 10.1. Ограничения объема проекта .............................................................. 94 10.2. Процедурные ограничения ................................................................... 95 4 10.3. Предоставление данных ........................................................................ 96 10.4. Предоставление ресурсов .................................................................... 96 10.5. Ограничения и допущения по срокам проектных работ ............ 96 5 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Полное наименование Системы Новая Биллинговая Система для ОАО «Северэлектро» (в дальнейшем Система). 1.2. Сведения о Заказчике Заказчик – ОАО «Северэлектро» 1.3. Резюме Исполнителя ООО «Сайнер» (SCIENER) - консалтинговая компания, один из ведущих интеграторов России, входит в состав «Группы компаний Систематика». ООО «Сайнер» разрабатывает системы принятия решений и управления предприятиями, внедряет отраслевые решения для предприятий энергетической отрасли и жилищнокоммунального хозяйства на базе корпоративных информационных систем. Специалистами компании успешно реализовано более 100 проектов в крупнейших российских компаниях энергетики, ЖКХ и других отраслей. Основываясь на опыте лучших мировых практик успешного внедрения ERPсистем и собственных разработках, ООО «Сайнер» создает единое информационное пространство, открытое для интеграции. Предлагаемые компанией системы автоматизации являются лидерами в своем классе и признаны во всем мире, поэтому внедрение решений на базе этих программных продуктов и консультационная работа проходят по отлаженной методологии, что дает высокие прогнозируемые результаты. ООО «Сайнер» является партнером ведущих мировых вендоров: SAP AG, IDS Scheer. Являясь партнером SAP AG ООО «Сайнер» имеет следующие партнерские статусы: SAP Service Partner, SAP Partner Center of Expertise (PCoE), SAP Silver Partner. ООО «Сайнер» является стратегическим партнером SAP, что стало следствием многолетнего успешного опыта компании в области внедрения информационных технологий на предприятиях энергетической отрасли России, и плодотворного сотрудничества ИТ-интегратора с ведущим производителем отраслевых решений для энергетики. Имея многолетний опыт работы, и обладая значительной экспертизой в продуктовой линейке SAP, ООО «Сайнер» предлагает полный комплекс решений на базе продуктов вендора и Отраслевые решения для энергетических компаний, ЖКХ и энергосбытовых компаний. Функционал отраслевых решений позволяет автоматизировать Основную производственную деятельность электросетевых компаний: транспорт электроэнергии, формирование балансов электрической энергии и управление потерями, биллинг услуги по передаче электроэнергии, ТОРО и управление активами. Проекты компании отмечены международной наградой по качеству управления проектом IPMA Excellence Aword. В компании внедрена система менеджмента качества. НП «Национальная сертификационная палата» выдала «Сайнер» сертификат соответствия требованиям национального и международного стандартов ГОСТ Р ИСО 9001-2008 и MS ISO 9001:2008 в сфере: 6 Проектирования и внедрения информационных систем; Технологической и функциональной поддержки информационных систем; Системной интеграции; Проектирования, разработки и внедрения программного обеспечения; Продажи собственного программного обеспечения; Продажи программного обеспечения других производителей; Управленческого консалтинга. ООО «Сайнер» имеет статус «Инновационный партнер в BPM-консалтинге» компании IDS Scheer. С целью обеспечения надежной эксплуатации внедренных информационных решений, их развития и поддержки, а также накопление, систематизация и приумножения базы знаний, в ООО «Сайнер» создан Отраслевой Центр Компетенций. Благодаря тому, что компания выступает в качестве единого поставщика всего спектра ИТ-услуг, заказчики получают возможность существенно сократить свои затраты на создание и последующее сопровождение информационных систем, а также на консультационную поддержку используемых решений. Кадровый ресурс ООО «Сайнер» это более 150 высококвалифицированных сотрудников, из них более 80-ти сертифицированных SAP, более 80% руководителей проектов сертифицированы IPMA. Действующая сеть филиалов компании позволяет ООО «Сайнер» эффективно оказывать консалтинговые услуги клиентам, в независимости от их географического положения, и оперативно осуществлять техническую поддержку действующих проектов. С 2011 года компания входит в состав «Группы компаний Систематика». «Группа Систематика» - одна из ведущих российских IT-компаний, предоставляющая широкий спектр услуг в области информационных технологий. Общее количество сотрудников группы компаний превышает 1300 человек. 1.4. Место оказания услуг ОАО «Северэлектро». 1.5. Срок оказания услуг Плановый срок начала работ: с момента подписания Договора. Плановый срок окончания внедрения Системы: не более 18 месяцев с момента подписания Договора. Плановый срок гарантии поддержки: не более 36 месяцев с момента передачи системы в промышленную эксплуатацию. 1.6. Термины и определения Термины SAP ERP Определения Система управления ресурсами предприятия компании SAP AG 7 Термины Определения SAP for Utilities / Industrial Solution for Utilities (IS-U) Модуль системы SAP ERP, предназначенный для автоматизации процессов электроснабжения Исполнитель В рамках данного предложения – ООО «Сайнер» Заказчик ОАО «Северэлектро» Организационные рамки проекта Перечень подразделений Заказчика, охватываемых при внедрении Системы Функциональные рамки проекта Перечень стратегических задач автоматизации, которые предполагается решить в рамках внедрения Системы Бизнес-процесс Последовательность определенных операций (работ, заданий, процедур), совершаемых работниками для решения какойлибо задачи в рамках деятельности Заказчика НСИ Нормативно-справочная информация - справочники и классификаторы ведущиеся в Системе централизовано ПО Программное обеспечение СУБД Система управления базами данных ТОРО Техническое обслуживание и ремонты оборудования 2. НАЗНАЧЕНИЕ СОЗДАНИЯ СИСТЕМЫ 2.1. Назначение Системы Биллинговая система предназначена для автоматизации следующих макро коммерческих процессов ОАО «Северэлектро»: 1. Запрос на новые подключения. 2. Коммерческий цикл, включающий сбор данных, пре-биллинг, выставление счетов, раздачу счетов и урегулирование счетов. 3. Управление задолженностью абонента. 4. Обслуживание абонентов интернета и т.д.). 5. Управление потоком электроэнергии и нетехническими потерями. (индивидуальное, посредством телефона, Система будет поддерживать предоставление Услуг следующим группам Клиентов: не бытовые абоненты (юридические лица, учреждения, организации, предприятия); 8 бытовые абоненты (физические лица - население). Система также предназначена для автоматизации формирования и наглядного представления консолидированной информации о деятельности всех участвующих в биллинговых процессах подразделений. 3. ХАРАКТЕРИСТИКА ОБЪЕКТОВ АВТОМАТИЗАЦИИ 3.1. Краткие сведения об объекте автоматизации Организационная структура ОАО «Северэлектро»: В каждом из трех регионов Бишкек, Чуй и Талас имеются отдельные биллинговые центры. Каждый регион подразделяется на распределительные центры (РЭС-ы). Бишкек поделен на 4 РЭС-а, Чуй на 10 РЭС-ов и Талас на 5 РЭС-ов. В каждом из этих 19 РЭС-ов имеются отделы продаж, которые ответственны за учет, биллинг и сбор на соответствующей территории. Данные предоставляемые РЭС-ами учитываются биллинговыми центрами и собираются в Отделе Продаж. Текущий Биллинговый Процесс: Северэлектро группирует абонентов на 5 основных категорий: промышленные, коммерческие, правительственные учреждения (бюджетные организации), сельскохозяйственные и частный сектор. Тарифы на 3-х фазное соединение состоят из двух частей, учитывающие оплату за электроэнергию и мощность. Для частного сектора с электрическим отоплением имеется специальная оплата за мощность. Частный сектор с трех фазным подключением ежемесячно оплачивает за мощность (в зимние месяцы). Некоторые абоненты не замеряются. Биллинг потребления абонентов без счетчика производится на основе установленной мощности и обычного потребления установленного оборудования, которое проверяется контроллером. Существуют различные процедуры снятия показаний счетчика и биллинга для бытовых и не бытовых абонентов. Не бытовые абоненты снимают показания со своих счетчиков и ежемесячно сообщают данные в биллинговый центр. Отдел Продаж проверяет показания каждые два или три месяца. У бытовых абонентов данные ежемесячно считываются контроллером. Задачи контроллеров следующие: считывание данных разноска счетов сбор долгов и/или выдача напоминаний должникам. Также контроллеры ответственны за: Проверка наличия пломб Гарантия, что вращение диска кВтч находится в допустимых нормах Выявления незаконных подключений Отключение и подключение должников Обработка заявлений новых абонентов Расчет среднего потребления абонентов без счетчиков. 9 Контроллеры в Бишкеке посещают в среднем 125 абонентов в день в соответствии с ежедневным планом маршрута. Они посещают каждого абонента два раза в месяц, сначала снимают показания счетчика, а потом разносят счета. В принципе, показания снимаются каждый месяц, но часто - из-за загруженности контроллеров - показания снимаются раз в два месяца. Каждый РЭС имеет биллинговый отдел с отдельными биллинговыми системами для бытовых и не бытовых абонентов. Задачи биллинговых отделов следующие: Распечатка ежедневных списков для показаний / маршрутные листы Ввод данных на основе показаний Проверка достоверности данных Выставление счетов Контроль за платежами Реализованное Биллинговое Программное Обеспечение: Все РЭС-ы имеют отдельные компьютерные биллинговые системы для бытовых и не бытовых абонентов. Базы данных на основе VisualFoxPro и текущие приложения биллинга совместимы с операционными системами семьи Windows (WindowsXP, WindowsServer 2008, Windows 7). Бытовые биллинговые системы были установлены в 2010-м году, а биллинговые системы для не бытовых абонентов были разработаны приблизительно в 1990 году. Кроме возраста биллинговых приложений большим недостатком нынешнего биллинга являются отдельные базы данных для бытовых и не бытовых абонентов. В Аламединском РЭС-е (Чуйская область) было реализовано пилотное программное приложение, которое позволяет не бытовым абонентам сообщать свои биллинговые данные через SMS. Счета производятся на основе переданных данных, а причитающаяся сумма также доводится до сведения абонента через SMS. Абоненты могут оплачивать свои счета либо в биллинговых центрах Северэлектро, в банках или через платежные терминалы. Квитанция об оплате печатается на счете и когда счет оплачивается, корешок отправляется в отдел продаж. Крупные промышленные абоненты и правительственные учреждения проводят авансовые платежи, основанные на сумме счета предыдущего месяца, а в следующем месяце этот авансовый платеж компенсируется за счёт потребления в расчетном периоде. В общем ОАО «Северэлектро» питает электроэнергией 500 000 бытовых абонентов и 21 000 не бытовых абонентов. Существующее биллинговое приложение имеет примерно 100 пользователей в Бишкеке, 100 в Чуйской области, 50 в Таласе и 60 пользователей в головном офисе ОАО «Северэлектро». Вопросы, подлежащие рассмотрению: широкий спектр приложений, вместе с низким уровнем интеграции приводит к серии ограничений: Непоследовательность данных; Отсутствие или трудность внутреннего контроля; Высокая стоимость поддержки; и 10 Отсутствие своевременной информации. ОАО Северэлектро выявило необходимость смягчения этих ограничений таким образом, что согласовывается с постоянной реорганизацией. Было выбрано разработать IS/IT-Генеральный План со структурированным обновлением прикладных решений и технологической инфраструктуры, которая поддерживает их деятельность. IS/IT-Генеральный План складывается при помощи различных инициатив ОАО «Северэлектро» интегрировать компьютерные решения, которые включают не только реализацию надежной структуры связи, но и установку, и использование компьютерных приложений для поддержки большинства операций компании. Чтобы установить четкие правила для технологического усовершенствования, были определены приложения и технологическое видение, а также программы проектов/инициатив по реализации концепции, которые должны быть достигнуты в среднесрочной перспективе. Анализ стратегических целей ОАО Северэлектро и процессов компании, определяющих основные ограничения и приоритеты, позволило определить приоритеты различных областей деятельности. Каждый связан с этапами развития панорамы приложений в соответствие с ее бизнес приоритетами. ОАО Северэлектро выявило необходимость смягчения этих ограничений, и для этого решило, что лучше интегрировать свою систему управления бизнесом. Поэтому новая биллинговая система должна быть интегрирована в настоящую и будущую бизнес-среду ОАО Северэлектро. 3.2. Сведения об условиях эксплуатации Системы Работа пользователей с Системой будет возможной: 3.3. в корпоративной сети ОАО «Северэлектро» с удаленных рабочих мест в подразделениях, к которым возможно подключение VPN-каналов связи; с удаленных рабочих мест в подразделениях, к которым возможно подключение Интернет-каналов связи общего назначения, с использованием технологий «тонкий клиент»; Сведения о режимах эксплуатации Биллинговой системы Будет обеспечена возможность работы пользователей с Биллинговой системой в режиме 24 х 7. Будет обеспечено функционирование Системы в следующих режимах: Штатный режим (непрерывная круглосуточная работа); Сервисный режим (для проведения обслуживания, реконфигурации и пополнения новыми компонентами); 4. ОПИСАНИЕ СИСТЕМЫ 4.1. Система в целом Система существенным особенностями: образом будет характеризоваться 11 следующими Модульность: Система первоначально будет покрывать диапазон модулей бизнес-процессов, но она также будет позволять добавление дополнительных модулей или пользователей в любой модуль, и в случае необходимости позволит интегрироваться в основную систему. Гибкость: Система будет поддерживать настройку по бизнес требованиям и будет адаптирована к практикам изменения Заказчика. В случае если возникнет необходимость настроить под конкретные потребности Заказчика, то же самое будет сделано в виде дополнений и процедур, которые могут быть подключены/отключены от базового продукта, при возникновении ситуации. Открытая Архитектура: Система будет открытой, чтобы позволить совместимость с программным обеспечением общего назначения и иметь средство для экспорта/импорта файлов данных из других приложений. Интеграция: Система будет полностью интегрирована по подразделениям и функциональным районам, а также по географическому расположению. Она будет иметь возможность назначать проверку по конкретному объекту на основе записей в эталонном файле проверки данных. Она будет полностью совместима для обмена данными с унаследованными системами и другими системами. Подход к интеграции рабочего процесса: Система будет поддерживать рабочий процесс автоматически выдавая предупреждения, обмен сообщений и т.д. по функциональным районам/модулям. Возможности Internet и Intranet: Система будет в состоянии продемонстрировать свою способность подключения internet, intranet и web. Это также может показать возможность Электронной Коммерции, что при необходимости позволит в будущем связать ее с системой абонентов и поставщиков. Ввод данных в Одной Точке: Система позволит вводить данные в компьютерную систему один раз, чтобы обеспечить целостность данных, и нет никаких удалений из данных. Масштабируемость: Система будет масштабируемой для обработки любого количества пользователей и объема загруженных данных без ущерба для времени ответа или эффективности операций. 4.1.1. Структура и функционирование Системы Биллинговая система будет реализована с использованием стандартных возможностей решений: SAP for Utilities / Industrial Solution for Utilities (IS-U), SAP Multichannel Foundation for Utilities (MFU), SAP Business Objects и SAP NetWeaver Process Integration. Биллинговая система будет состоять из следующих связанных и взаимодействующих между собой компонентов, которые будут представлены в виде логической совокупности бизнес-функций или в виде отдельных модулей: Управление Запросами на новое подключение; Управление Коммерческим циклом (включающим сбор данных, пребиллинг, выставление счетов, раздачу счетов и урегулирование счетов); 12 Управление Задолженностью абонентов; Управление Обслуживанием абонентов; Управление Потоками электроэнергии и нетехническими потерями; Управление Служебными распоряжениями Личный кабинет клиента; Управленческий контроль; Любая информация (кроме справочной), хранящаяся в системе, в случае ее влияния на результаты работы алгоритмов или данные отчетов, будет храниться с указанием даты начала и даты окончания актуальности. Изменение значений времязависимых параметров будет производиться проставлением нового значения с определенной даты, без возможности прямого изменения предыдущего значения. Система будет иметь возможность гибкой настройки подсистемы аудита действий пользователей, для возможности однозначного определения даты, времени и ФИО пользователя, выполнившего корректировку данных. В системе будет предусмотрена функция авторизации (присвоения статуса «утверждено»), выполняемая одним пользователем относительно действий, выполненных другими пользователями, с возможностью гибкой настройки применения на тех или иных объектах и данных. Биллинговая система будет построена по 3-х уровневой модели приложения (в этом контексте приложение понимается более широко, нежели рабочее место конечного пользователя, а именно как автоматизированная информационная система в целом). В соответствии с этой моделью, приложения будут состоять из трех уровней: представления, бизнес-логики и доступа к данным: Уровень представления (или Внешний уровень) будет определять представление данных для конечного пользователя и может быть представлен как экранные формы, отчеты и т.п.; Уровень бизнес-логики (или Внутренний уровень) будет определять логику работы приложения, т.е. операции над данными; Уровень доступа к данным (или Предметный уровень) будет определять модель данных и внутренние взаимосвязи между ними. Общие положения: Новая биллинговая система будет интегрально администрировать все процессы коммерческой деятельности компании. Система будет позволять каждому члену организации, участвующему в коммерческих процессах ежедневно управлять коммерческими процессами. Планы действий, которые необходимы для улучшения деятельности по обслуживанию клиентов, а также для выставления счетов, сбора и нетехническим потерям будут осуществляться более эффективно при помощи новой биллинговой системы. Система позволит в любое время легко проконсультировать относительного любого аспекта клиента компании. Кроме того будет условие, которое позволит доступ к информации на основе суточного, месячного, квартального, полугодового и годового характера, в соответствии с коммерческими потребностями. 13 Ниже приведено краткое поддерживаться Системой: 1. описание каждого компонента, которые будут Компонент «Управление Запросами на новое подключение» обеспечит автоматизацию процесса, который относится к управлению новыми подключениями, контрактным формальностям с абонентами и изменениям со стороны абонента, которые могут возникнуть во время исполнения контракта (например, смена имени абонента). Новый процесс подключения включает в себя различные этапы в зависимости от типа запроса (те, которые требуют или не требуют вмешательства распределительной бригады). Коммерческая система будет оценивать соответствие срока выполнения подключения, а также общее количество времени, затраченное на предоставление нового подключения. Следующие этапы по запросу новых подключений являются основными: Регистрация и осмотр: это начало запроса, оно влечет за собой географическое положение, осмотр и утверждение помещений абонента. Подготовка и уведомление о бюджете, если на участке необходимы работы. Это включает расчет цены, которую абонент должен будет заплатить. Сбор доходов: через коммерческие отделы или через внешние пункты (платежные терминалы), посредством различных форм оплат (наличная форма, банковский перевод, предоплата). В каждом конкретном случае будут выдаваться соответствующие правовые документы. Завершение мероприятия и закрытие запроса. Для того чтобы сохранять взаимосвязь между коммерческой деятельностью и Распределительным Центром обновленной, новая коммерческая система будет в состоянии поддерживать обновленной информацию о каждом этапе нового подключения. Кроме того, она будет обязательно иметь полную запись запросов абонента, выполнять наблюдение за периодом завершения, а также информировать о ходе выполнения каждого запроса. После того, как процесс расширения электросети завершен (если это было необходимо сделать) и подключение было выполнено, новое подключение будет зарегистрировано (определение географического местоположения), а контракт вступает в полную силу. Основные этапы, которые будут приняты во внимание в период заключения контракта: Регистрация контракта: это начало деловых отношений между абонентом и ОАО «Северэлектро». Вся информация будет доступна для проверки, в том числе вероятность имения задолженности абонента у других служб. Услуга будет автоматически включена в процесс считывания показаний, выставления счетов и сбора. 14 Обновление контракта: любые изменения в организации, которые ей относятся будут доступны, чтобы они могли быть проверены и обновлены. Расторжение контракта: оно включает в себя прекращение деловых отношений и выставление последнего счета, а также возможность использования последнего показания, предоставленного клиентом, чтобы сделать оценку с учетом предыдущего потребления или генерации порядка считывания. Каждая коммерческая сделка будет храниться в бухгалтерском учете. Компонент «Управление Коммерческим циклом» обеспечит автоматизацию процессов сбора данных, пре-биллинга, выставления счетов, раздачу счетов и урегулирование счетов. 2. Этапы со счетчиками оплаты по факту: считывание, выставление счетов, вместе с раздачей и сбором счетов: i. Считывание (снятие показание) Деятельность по снятию показаний связана с операциями по программированию разделов считывания, снятие показаний на различные средства и их обработка, для последующего выставления счетов и управления коммерческими потерями. Эта деятельность включает в себя проверку полученных показаний. Управление процессами снятия показаний будет разработано в децентрализованном порядке через центры снятия показаний, которые зависят от коммерческих агентств. С помощью новой системы будут осуществляться следующие задачи: • Оптимизация маршрута для деятельности по ручному снятию показаний. • Запись и удаление абонентов с маршрутов снятия показаний. • Планирование ежедневной работы. • Назначение задач сотрудникам в местах снятия показаний. • Проверка и корректировка полученных показаний. • Внутреннее административное управление нарушениями, о которых сообщили контроллеры. Ежедневное планирование деятельности по снятию показаний будет выполняться в соответствии с рамками деятельности выполняемой в течение всего месяца или года, которая установлена и назначена для каждого центра снятия показаний. Для того чтобы организовать маршрут снятия показаний, новая система будет учитывать некоторые факты, такие как: количество показаний, время, которое требуется для снятия показания с каждого счетчика и распространение счетов. Новая система также будет в состоянии обрабатывать информацию с показаниями, которая поступает с различных средств: портативный терминал данных, списки повседневных маршрутов, показания снятые 15 удаленно и показания предоставленные абонентом (по телефону или через Интернет). Процесс контроля снятия показаний будет позволять: • Выдачу жалоб от контроля по аномальным ситуациям. • Обработка и коррекция этих аномальных ситуаций. • Автоматическая выдача операций, которые возникают по причине жалоб: выпуск рабочих приказов, задач, которые еще не были завершены и выставление счетов. • Регистрация отклонений от того что было запланировано и что было сделано для контроля над деятельностью. • Контроль качества работы контролера. Определить когда абонент имеет дело с аномальной ситуацией, является ответственностью компании, которая будет параметрируема и указываться место, где она возникла. У промышленных абонентов и у абонентов частного сектора ОАО «Северэлектро» установлены ИНТЕЛЛЕКТУАЛЬНЫЕ приборы учета и показания поступают удаленно. Новая биллинговая система будет оборудована необходимыми интерфейсами для того чтобы автоматически импортировать данные о потреблении с разных головных систем от различных поставщиков, и для того чтобы электронным образом выполнять команды по отключению и переподключению. ii. Выставление счетов Процесс выставления счетов заключается в расчете стоимости, которая должна быть включена в счет, штрафы, надбавки и налоги, которая будет зависеть от характеристик поставок, информации, полученной со счетчиков, а также других значений и тарифов, включаемых в счет. В соответствии с параметрами удобно избегать ошибок при выставлении счетов, и для обеспечения возможности выявления возможного мошенничества, в новой биллинговой системе будет доступна система проверки счетов. Она также будет иметь возможность для решения этих аномалий, которые необходимо произвести в централизованном порядке в головном офисе ОАО «Северэлектро», где контролируется и администрируется Управление Коммерческим Циклом и децентрализовано в соответствующих РЭС-ах. Система будет поддерживать включение в счет клиента данных, которые, по мнению компании, имеют отношение, такие как детали взимаемой суммы, сумма, счета по кВтч и то, что требуется законами страны. Также будут включены уведомления, как например уведомления о задолженности. Кроме того, процесс выставления счетов будет учитывать изменения, которые необходимо произвести в связи с жалобами абонента в выставленных счетах. Новая коммерческая система будет выставлять счета потребления, полученные удаленно со счетчиков. Они, как правило, имеют 16 программное обеспечение, которое дает возможность снимать показания удаленно. Система будет иметь возможность подключаться с помощью программного обеспечения для того чтобы выставление счетов с этих удаленных счетчиков было таким же легким, как и с классических счетчиков. Бухгалтерский учет счетов-фактур будет показывать все счета, которые формируют каждую учетную запись. iii. Сбор Процесс сбора происходит после того, как счет выставлен и передан абоненту. Он включает в себя все виды деятельности, которые возникают при сборе денежных средств либо кассирами самой компании, банками, почтовыми отделениями или через платежные терминалы. Новая биллинговая система будет готова выполнять прием платежей во всех существующих формах: через автоматическое списывание, через розничные платежи посредством внешних посредников (банки, супермаркеты, аптеки, банкоматы). Сбор денежных средств, выполняемый самой компанией, будет проводиться кассирами в кассах. Кроме того, все проведенные операции будут записываться и контролироваться в конце каждого дня. Сбор денежных средств посредством внешних посредников и соответствующие депозитные счета, проведенные в ОАО «Северэлектро» будут обновляться и контролироваться. Кроме того, трансакции, которые являются частью определенного счета, будут различны. Компонент будет соответствовать следующим нефункциональным требованиям: 3. • Возможность быстрого поиска клиента, получения справочной информации о статусе клиента (начисления, открытые позиции и т.д.) и осуществления базовых транзакций из одного окна системы. • Разграничение прав пользователей на ввод, изменение, удаление и просмотр данных по клиентам, в соответствии с их функциональными обязанностями. • Разграничение прав пользователей на создание, изменение, удаление и просмотр отчетов по группе клиентов в соответствии с их функциональными обязанностями. Компонент «Управление Задолженностью абонентов» обеспечит автоматизацию процесса по управлению абонентами неплательщиками. Когда абонент не оплачивает счет в течение контрактных сроков, начинает работать процесс по управлению абонентами неплательщиками. Система будет запрограммирована для выполнения нескольких операций, которые связаны со сбором начисляемых сумм, таких как: уведомления о задолженности, отмена услуг, повторное подключение, если оплата осуществлена, наблюдение за отменой услуг, 17 если платеж не действителен. Эти процессы будут работать в соответствии с коммерческой политикой компании относительно управления абонентами неплательщиками. Эти политики определяют: как давно по истечении счета выдано уведомление об отключении, и сколько дней должно пройти с момента уведомления до отмены услуг. Управление задолженностью будет включать расчет штрафов и дополнительных финансовых расходов, которые возникают в связи с отсутствием оплаты в течение установленных сроков. Компания должна иметь специализируемые секторы по управлению задолженностью, чтобы они могли исполнить процесс после того, как автоматические мероприятия были завершены. Эти сектора будут в состоянии выполнить соответствующие операции в каждом случае, такие как отправка писем для абонентов или просьбу о юридической помощи в случае необходимости. Новая коммерческая система позволит финансировать и рефинансировать долги в акции с финансовым интересом. Коммерческая политика ОАО «Северэлектро» будет устанавливать определенные параметры для определения количества акций, их стоимость и процентную ставку. Также будет доступна возможность выполнять наблюдение за неоплаченной задолженностью. Это будет показываться на экранах системы вместе с соответствующей областью, типа абонента, его историей и задолженностью, которая соответствует РЭС-ам. Согласно политике компании, каждая коммерческая операция, которая включает в себя сбор задолженности с абонентов неплательщиков, процентов, штрафов и надбавок будут зарегистрированы в системе учета компании через интерфейсы, которые коммерческая система будет ежедневно проводить с указанной системой. 4. Компонент «Управление Обслуживанием абонентов» обеспечит автоматизацию процесса, включающего все виды деятельности, которые имеют отношение к взаимосвязи между абонентом и компанией, в том числе рассмотрения жалоб и, следовательно, уведомлений, которые должны быть сделаны. Новая коммерческая система позволит уделять внимание абонентам посредством всех имеющихся средств: РЭС-ы, головной офис и интернет. Система будет всегда иметь доступ к общей информации, касающейся абонентов, расходных материалов, технических данных, а также к информации о счетчиках и показаниях, начислениях и сборах, электрооборудовании, подробном описании предыдущего контакта абонента с компанией или наоборот и нарушениях. Это позволит улучшить сроки обслуживания абонентов. Индивидуальное обслуживание через РЭС-ы позволит каждому абоненту ОАО «Северэлектро» выполнять коммерческие процедуры в любом доступном учреждении. Кроме того, коммерческие представители будут совершать все эти действия, запрошенные абонентом в системе. 18 Обслуживание абонентов, проводимое по телефону, позволит обслуживать абонентов со всей территории деятельности. Звонки, полученные по коммерческим вопросам, будут дифференцироваться от тех, которые связаны с вопросами качества обслуживания, а также от звонков, связанных с качеством обслуживания. Обслуживание абонентов, осуществляемое через Интернет, позволит решить вопросы, касающиеся счетов и потребления, а также запросы копий квитанций, изменения данных контракта (имя или тариф), претензии по выставленным счетам и данные абонентов о показаниях. Кроме того, будет произведена запись всех возможных типов жалоб. Система позволит отслеживать выполнение жалоб, которые уже были решены сотрудниками головного офиса, РЭС-ами, по телефону или через Интернет. 5. Компонент «Управление Потоками электроэнергии и нетехническими потерями» обеспечит автоматизацию процесса эффективного контроля над потерями электроэнергии компании. По требованию компании, система предоставит информацию об энергетическом балансе, что будет сделано с учетом счетчиков размещённых в распределительной сети. Для того чтобы контролировать энергетические потери, компания должна принять решительные планы действий, осуществляемые сотрудниками компании или сотрудниками, нанятых для этих целей. Модуль по контролю над электроэнергией будет поддерживать тщательные последовательные меры по выполнению стратегических планов, реализуемых с целью снижения потерь и действиями, предпринятыми для выполнения этой цели. 6. Компонент «Управление Служебными распоряжениями» обеспечит возможность автоматически оформлять служебные распоряжения, что будет осуществляться в соответствующем РЭС-е или в головном офисе. Как следствие развития различных процессов, которые являются частью коммерческой деятельности, таких как, обслуживание абонентов, новые подключения, коммерческий цикл, управление абонентами неплательщиками и контроль над электроэнергией, будет реализовано автоматическое оформление служебных распоряжений. Выдача служебных распоряжений присутствует во всех коммерческих процессах. Это является очень важным для выполнения последующих действий и контроль за каждым из них, а также для загрузки в систему данных служебного распоряжения. Служебные распоряжения включают в себя следующие задачи: операции программирования, распределение задач между сотрудниками, которые могут быть сотрудниками компании или специально нанятые для этой работы, поставка необходимых материалов, полевые работы, регистрация выполненных мероприятий, и наконец, проверка и последующее обновление служебных распоряжений выданных при всех процессах. 19 В зависимости от задачи, которые должны быть выполнены, будут разные служебные распоряжения: соединение, прекращение подачи электроэнергии, переподключение, осмотр, замена оборудования и т.д. Служебное распоряжение проходит различные этапы: выдача, отмена, и решение. В каждом из них будут выполнены следующие процедуры: • Регистрация служебных распоряжений: даты, часы, пользователи, идентификация персонала выполняемого мероприятия, выполненные и не выполненные операции, использованные материалы, время, расходы и т.д. • запись времени, которое потребовалось для выполнения служебного распоряжения, которое может быть измерено с момента его выдачи до его последующего обновления, и разделения в зависимости от пользователя, ответственного за определенную территорию. Система будет автоматически выдавать каждое служебное распоряжение соответствующему коммерческому агентству. Для этого при выдаче система определит географическое местоположение поставки. 7. Компонент «Личный кабинет клиента» представляет собой webразработку и предназначен для организации самообслуживания клиентов. Компонент обеспечит доступ к собственной информации абонента, предоставление клиентам данных об объемах и стоимости оказываемых абоненту услуг и данных по показаниям приборов учета, предоставление показаний приборов учета абонентом, информирование клиентов компании. 8. Компонент «Управленческий контроль» обеспечит облегчение управления и наблюдения за различными видами деятельности, которые составляют коммерческие процессы. Будут приняты во внимание информация и показатели эффективности управления, их развитие и накопление (ежедневно, ежемесячно или ежегодно), которые можно увидеть в техническом или в денежном измерении, их группировку в соответствии с различными переменными, такими как географическое расположение, тип абонента, дата и тариф, которые будут подробно описаны графически или диаграммами. Консультационные данные могут относиться к текущему месяцу, обновляться в последний рабочий день. Будет возможность выбора периода по группе месяцев, в том числе за последние 24 месяца с возможностью накопления значений. В каждом случае будет возможность связать информацию через различные географические записи и коммерческие учреждения, которые компания имеет в наличии. Тот факт, что система позволяет делать запросы, подразумевает, что имеющиеся данные будут включать детали, касающиеся операций, которые еще не были выполнены, и аспекты относительно каждого процесса, коммерческого отдела, его 20 статистических параметров. данных и отклонения контроля соответствующих 4.1.2. Функциональные возможности Биллинговой системы 4.1.2.1. Компонент «Управление Запросами на новое подключение» Компонент будет содержать следующие функциональные возможности: Ведение электронной «картотеки» потенциальных клиентов (заявителей на новое подключение), с возможностью последующей трансформации в абонента. Система будет обеспечивать возможности ведения преддоговорной работы (деятельность до заключения договора поставки основных услуг) – подготовка и выдача условий на подключение (УП), заключение договора на подключение (ДНП) В системе регистрируется информация о выданных УП, а также заключенных ДНП, с указанием реквизитов заказчика и расположения точки подключения. В системе регистрируется статусы реализации мероприятий по подключению (выдано УП, заключен ДНП, выполнено техническое присоединение, заключен абонентский договор) и установлены нормативные сроки выполнения каждого из этапов. Система автоматически формирует отчет по заказчикам, по которым нормативные сроки истекли, но договор на поставку услуг не заключен В системе ведется регистрация сведений о выполнении выездной проверки факта подключения/пользования и ее результатах 4.1.2.2. Компонент «Управление Коммерческим циклом» Компонент будет содержать следующие функциональные возможности: Ведение электронной «картотеки» абонентов – физических и юридических лиц; регистрацию новых абонентов с указанием всех персональных реквизитов, необходимых для полной, однозначной идентификации абонентов в базе данных. Система будет поддерживать модель статусов «жизненного цикла клиента» от этапа подписания договора, начала обслуживания, и до завершения обслуживания с сохранением истории взаиморасчетов. Предусмотрена возможность регистрации в Системе события расторжения договора, с даты которого, системе перестает производить действия по расчетам и начислениям и блокирует возможность ввода поступающих оперативных данных (например, показаний ПУ). Наличие в составе объектов Системы «точки энергоснабжения», характеризующейся адресом и обслуживающим контролером. Регистрация в карточке абонента следующих данных для клиентов – физических лиц (включая, но не ограничиваясь): o ФИО клиента; 21 o дата рождения; o контактный телефон/е-mail; o удобное для абонента время обхода и/или обзвона; o паспортные данные (серия, номер, дата и место выдачи); o адрес проживания (по паспорту); o адрес доставки счетов; o способ доставки счетов; o метод оплаты, при безналичной оплате – банковские реквизиты; o данные о плательщике – ФИО, паспортные данные, адрес проживания, телефон, платежные реквизиты, социальный статус клиента (работает, пенсионер, студент, безработный); o название подразделения, к которому относится клиент. Регистрация в карточке абонента следующих данных для клиентов – юридических лиц (включая, но не ограничиваясь): o название организации; o ведомственная принадлежность; o принадлежность к бюджету; o ИНН; o КПП; o коды учета – налогового, аналитического, статистического; o почтовый адрес; o юридический адрес; o ФИО и телефон руководителя; o ФИО и телефон главного инженера; o ФИО и телефон главного бухгалтера; o адрес доставки счетов; o способ доставки счетов; o метод оплаты; o полные банковские реквизиты; o данные о плательщике – Название организации, ИНН, ФИО руководителя, ФИО главного бухгалтера, ИНН, КПП, платежные реквизиты; o наименование подразделения, к которому относится клиент. Регистрация договора с новым абонентом с указанием всех данных о клиенте, которые указаны в договоре, а также условий обслуживания клиента, включая следующие данные, для всех абонентов (включая, но не ограничиваясь): 22 o номер договора (подписанного на бумаге); o дата начала действия договора; o дата окончания действия договора; o дата выставления счета и срок оплаты счета; o название услуги; o дата подключения услуги; o адрес поставки услуги; o качество поставляемой услуги (если применимо); o норматив потребления (если применимо). Ведение истории договоров. Регистрация данных по потребителям и их приборам учета (ПУ), необходимые для корректного расчета потребления и начислений: o Серийный номер ПУ; o Модель ПУ; o Место установки (адрес) ПУ (внутри квартиры, на лестничной клетке, № этажа); o тип ПУ (индивидуальный, общий); o применяемый тариф (тарифная схема); o данные для расчета фактического потребления; o специфические для каждого вида потребления данные о ПУ, включая: значность; начальные (поверочные) сведения сведения о подразделении и контроллере, обслуживающем данный ПУ. o Данные объекта электроснабжения; o Ведение справочника типов неисправностей/нарушений в работе ПУ. Возможность загрузки типа нарушения с использованием интерфейсов обмена данными, с указанием показаний ПУ. o Поиск в базе данных абонентов по заданным признакам: Для всех абонентов: номер абонента в БД (уникальный код); номер лицевого счета; номер договора; адрес абонента; 23 номер телефона Для физических лиц: фамилия абонента; имя абонента; фамилия плательщика; Для юридических лиц: название организации; ИНН; фамилия руководителя; фамилия главного инженера; фамилия главного энергетика; фамилия главного бухгалтера. o Внесение изменений в персональные реквизиты, принадлежащие абоненту, а также учет и контроль изменений реквизитов абонента. o Внесение изменений в описание условий обслуживания абонента, включая изменение набора услуг, изменение тарифов, лимитов, скидок, сроков и условий оплаты счетов и т.п. o Внесение изменений в данные о потребителях и ПУ. o Контроль над соблюдением условий и сроками действия договоров с абонентами. o Формирование абонентам. справочной и статистической отчетности по Поддержка гибкой 3-уровневой структуры данных о клиентах и схеме подключения, позволяющей корректно обслуживать «сложных» клиентов (под «простым» клиентом подразумевается случай, когда абонент, плательщик и потребитель совпадают) включая следующие случаи: o случай, когда абонент, плательщик и потребитель являются разными лицами (физическими или юридическими); o потребитель, у которого есть несколько приборов учета; o случай, когда один прибор учета используется для нескольких клиентов, причем счета формируются пропорционально фактическому потреблению услуг каждым из клиентов; o клиент, имеющий субклиентов, получающий общий детализациею начислений отдельно по всем субклиентам; счет и o клиент, имеющий субклиентов с выставлением отдельных счетов клиенту и субклиентам; 24 o случай «общего плательщика», когда один плательщик оплачивает несколько счетов разных клиентов общим платежом. o Трансформация независимого клиента зарегистрированного ранее клиента. в субклиента другого, o Трансформация субклиента в независимого клиента компании. o Возможность централизованного учета данных о клиенте, который имеет несколько филиалов на территории разных территориальных подразделений. o Ведение истории взаимоотношений с абонентом («Досье клиента»), в котором сохраняются необходимые отметки о действиях, произведенных в отношении клиента в рамках процессов «Выставление и доставка счетов», «Управление дебиторской задолженностью», «Отключение/ Подключение». o Ведение электронной «картотеки» помещений – физических и юридических лиц; регистрацию новых помещений с указанием всех параметров, необходимых для полной, однозначной идентификации помещения в базе данных и проведения расчетов. Ведение приборов и показаний: o Поддержка различных типов приборов учета. o Возможность регистрации показаний на любой момент времени. o Автоматизированный ввод показаний для расчета потребления из файлов либо посредством обмена информационными сообщениями с внешними системами. Возможность сконфигурировать несколько форматов файлов из интерфейса пользователя. o Поддержка ручного ввода показаний приборов. Экранная форма будет обеспечивать удобство работы оператора и быстрого ввода данных по большому числу приборов учета. o Ведение ответственных за снятие показаний с приборов учета контролеров. o Ведение справочника контролеров. Возможность ручной корректировки справочника/перераспределение между Контролерами. Однозначная ответственность за снятие показаний с абонента. o Возможность формирования ежедневных заданий для контролеров: формирование задания на обход с возможностью ручной корректировки (добавления/удаления абонентов, добавления примечаний) o Использование данных об ответственных контролерах поддержки планирования контрольных обходов. для o Регистрация информации об источнике данных о показаниях приборов учета (дата снятия показаний, ведомость контрольного обхода с именем контролера, сообщение абонента и т.п.). 25 o Возможность корректировки данных по показаниям приборов учета до момента выставления счета. После выставления счета система должна предоставить возможность внести записи, корректирующие сумму начислений, и учесть корректировку сумм при следующем выставлении счета в открытом расчетном периоде. o Проверка корректности значений показаний при вводе. Например, автоматическое обнаружение ошибок типа другой порядок цифр, буква «о» вместо «0», отрицательное или нулевое потребление, переход через «0» и пр. o Ведение протокола ошибок с указанием причины (типа) ошибки. o Формирование сводных и детальных отчетов о вводе показаний ПУ за различные периоды, с возможностью фильтрации и группировки показаний по различным критериям: клиентам, контроллерам, операторам, адресам и группам адресов, подразделениям. Расчет потребления: o Регистрация результатов лабораторных анализов на предмет превышения значений предельно допустимых концентраций (ПДК) во взятых пробах, для последующего начисления сумм к оплате за превышение ПДК. o Поддержка сложных схем расчета с различными единицами измерения. o Приведение различных расчетных единиц потребления к основной тарифицируемой единице измерения. o Выполнение расчета на основании показаний приборов учета, а также с возможностью гибкого распределения на субсчета полученной величины по сложной масштабируемой многоступенчатой схеме потребления (балансовый метод). o Поддержка расчета потребления в случае ввода нескольких показаний в течение расчетного периода (например, в случае смены прибора учета в течение месяца, кражи прибора учета и расчета по нормативам и т.п.), с учетом приоритетов использования показаний. o Выполнение расчета на основании нормативов потребления, фиксированных договорных величин. o Выполнение расчета на основании расчетного расхода, рассчитанного из показаний ПУ за прошлые периоды или в случае снятия показаний ПУ в середине расчетного периода, с последующим перерасчетом и отражением результатов перерасчета в текущем (открытом) расчетном периоде; o Проведение различных видов (Например, для юридических лиц - по точке учета – субпотребителям, по договору в целом) перерасчетов по недопоставкам или поставкам услуг ненадлежащего качества, которые могут производиться в соответствии с заявлениями, поданными Клиентами. 26 o Возможность моделирования начисления/сторнирования последующим удалением результатов. с o Контроль рассчитанного значения на корректность (многократно превышающие среднемесячные значения, контроль нулевых значений и пр.) o Настройка типа активации расчета. o Автоматическое выполнение расчета и сохранение в базе данных полученного значения по событию при вводе показания прибора учета за расчетный период независимо от способа ввода o Ручная активация выполнения расчета и сохранения в базе данных полученного значения при вводе показания прибора учета за расчетный период независимо от способа ввода o Автоматическое выполнение расчета и сохранение в базе данных полученного значения по событию календаря с датами наступления расчета. o Ручное и автоматическое утверждение результатов расчета. o Единичное и групповое утверждение результатов расчета. o Невозможность бесследного удаления результатов расчета. o Отсутствие возможности ручного изменения рассчитанного значения пользователем. o Ручное и автоматическое выполнение перерасчета результатов расчета при изменении параметров, с изменением значения, сохраненного в базе данных, в случае незакрытого периода. o Получение протоколов расчетов. Начисления: o Выполнение начисления на основании договора на подключение (ДНП). o Выполнение начисления на основании расчета потребления. o Выполнение начисления/сторнирования регулярных либо разовых фиксированных сумм (штрафные санкции и пр.). o Выполнение авансовых авансового потребления. начислений на основании расчета o Автоматический контроль непротиворечивости начислений. Например, разный порядок сумм, по сравнению с прошлым периодом. o Настройка типа активации начисления. o Автоматическое выполнение начисления и сохранение в базе данных полученного значения по событию, при вводе результатов расчета потребления за расчетный период. 27 o Ручная активация выполнения начисления и сохранения в базе данных полученного значения при вводе результатов расчета за расчетный период. o Автоматическое выполнение начисления и сохранение в базе данных полученного значения по событию календаря o Ручное и автоматическое утверждение результатов начисления. o Единичное и групповое утверждение результатов начисления. o Невозможность бесследного удаления результатов начисления. o Ручное по запросу и автоматическое по расписанию выполнение разных видов перерасчета начисленных сумм при изменении параметров, с изменением значения, сохраненного в базе данных, в случае незакрытого периода. o Отсутствие возможности ручного изменения рассчитанного значения пользователем. o Возможность моделирования начисления/сторнирования последующим удалением результатов по одному клиенту. с o Возможность моделирования начисления/сторнирования последующим удалением результатов по группе клиентов. с o Получение протоколов начислений. Выставление счетов: o Возможность использования различных шаблонов документов для разных категорий клиентов. Гибкая настройка шаблонов. o Возможность формирования, просмотра на экране и печати счета к оплате (наличным или безналичным способом) для одного клиента. o Возможность массового формирования счетов к оплате (наличным или безналичным способом) для группы клиентов, выбранных по определенным критериям, в частности: тип клиента, наличие у клиента субклиентов, по подразделениям, в порядке возрастания адресов и т.д., с сохранением при необходимости, критериев выборки для последующего использования. o Возможность массовой печати счетов на печатающем устройстве. o Возможность печати счетов и передачи данных на конвертировочную машину для формирования писем клиентам, с возможностью сортировки писем по определяемым правилам для учета требований почтового отделения (сортировка по почтовым индексам, печать описей и т.п.). o Возможность формирования и печати авансовых счетов для юридических лиц. o Возможность формирования, печати и хранения в БД счетов-фактур – как для одного клиента, так и для группы клиентов. o Возможность гибкой схемы выставления счетов клиентам, имеющим сложную структуру; например, при наличии у клиента субклиентов – 28 формирование для них отдельных счетов или формирование общего счета, с детализацией начислений по всем субклиентам – в зависимости от условий договора. o Возможность формирования в процессе биллинга отдельного счетафактуры для каждого суб-абонента, как для отдельного клиента, в случае наличия у клиента одного или более суб-абонента. Выставление счету клиента производиться только после расчета всех его суб-абонентов. o Возможность выставлять отдельный счет за хищения. o Возможность указывать начисления за хищения в составе счета за услугу (с указанием объема хищения и суммы). o Формирование в процессе выставления счетов для каждого типа клиентов дополнительного набора документов (претензии, уведомления, письма и пр.). o Формирование и печать расшифровок по начислениям за любой период времени по любому абоненту или группе абонентов. o Регистрация и контроль результатов доставки счетов абонентам. o Сохранение в системе выставленных счетов в течение заданного времени с возможностью повторного просмотра и печати единичного счета в том виде, в котором он был сформирован и напечатан изначально. o Возможность при необходимости корректно «откатить» операцию массового формирования счетов (до того, как они были отправлены клиентам) и провести ее заново. Регистрация и контроль поступлений (оплат): o Выполнение погашения начисленной суммы. o Ручной ввод данных о поступлениях, сопоставление начисленной сумме, сохранение в базе данных. o Автоматическая загрузка данных о поступлениях через интерфейс систем «Клиент Банк», сопоставление начисленной сумме, сохранение в базе данных. o Возможность ввода наличных предопределенном формате. платежей из файлов в o Возможность ручного соотнесения платежа начисленной сумме. o Возможность автоматического соотнесения платежа начислению (части начисления, нескольким начислениям) в соответствии с предопределенными правилами. o Ручной и автоматической контроль количества обрабатываемых платежных документов и сумм оплаты на соответствие данным банковской выписке. o Контроль ошибок в данных на предмет неразнесенных платежей, слишком больших или слишком маленьких сумм и пр. 29 o Наличие режима возврата сумм ошибочных платежей. o Невозможность удаления результатов регистрации поступления и возврата оплаты. o Наличие режима корректной обработки поступлений оплаты в случае закрытого периода. Закрытие периода: o Ведение календаря закрытия периодов. o Контроль транзакционной завершенности: отсутствие нерассчитанных клиентов, незавершенных операций по всем модулям и т.д. o Проведение операции «Закрытие периода», которая определяет границу между двумя расчетными периодами, после которой введенные в систему показатели потребления, платежи, сформированные начисления и корректировки будут отнесены к следующему расчетному периоду и учтены в счетах к оплате и в отчетах за следующий расчетный период. o Контроль полноты выполнения и завершенности всех бизнеспроцессов, предшествующих закрытию периода (отсутствие незавершенных транзакций), формирование списка лицевых счетов с указанием причины, по которой для данного лицевого счета не может быть закрыт период. o Возможность проведения операции «Закрытие периода» по одному клиенту и по группе клиентов (по клиентам участка, отделения, филиала). o Невозможность изменения натуральных и финансовых показателей клиента после операции «Закрытие периода» по закрытому периоду. o Запрет на проведение перерасчетов в закрытом периоде. o Предоставление данных для формирования оперативной отчетности, отчетности для вышестоящей организации и государственных органов. 4.1.2.3. Компонент «Управление Задолженностью абонентов» Компонент будет содержать следующие функциональные возможности: Ведение для каждого клиента лицевого счета, который содержит всю необходимую для взаиморасчетов финансовую информацию, в том числе историю финансовых операций: начислений, платежей, финансовых корректировок. Возможность ведения для каждого клиента нескольких лицевых счетов – для раздельного учета разных услуг либо групп услуг, пеней и штрафов. Ведение и поддержка в актуальном состоянии баланса лицевого счета клиента, отражающего в каждый момент времени текущее состояние взаиморасчетов с ним, автоматическое вычисление и отображение значений задолженности, в разрезе предопределенных видов (просроченная, исковая и пр.) 30 Разделение клиентов на категории, определяющие сценарии работы с ними. Формирование и хранение в системе признаков клиентов, работа с которыми ведется по определенным правилам. Возможность задания различных сценариев работы с клиентами в зависимости от типа клиента. Расчет пеней за просрочку в оплате счета. Начисление пеней и штрафов за просроченный платеж. Формирование в автоматическом режиме выборки клиентов, не оплативших счета, по заданным критериям, включая: диапазон величины задолженности, тип клиента. Необходимо обеспечить возможность формирования на основе этой выборки отчета о должниках, его редактирования, сохранения и печати. Система будет хранить информацию о действиях по взысканию просроченной задолженности, нормативных сроках и результатах их выполнения. Система будет формировать автоматические уведомления для ответственных работников по фактам возникновения просроченной задолженности: невыполнения предусмотренных действий по взысканию задолженности в нормативные сроки, получения отрицательного результата от действия по взысканию дебиторской задолженности. Система будет формировать отчет в разрезе абонентов о статусах и результатах выполнения действий по взысканию дебиторской задолженности. Ведение для каждого клиента электронного «Досье клиента», в котором сохраняются записи обо всех действиях, произведенных в отношении клиента в рамках процесса «Управление дебиторской задолженностью», в частности: отправка предупреждений и уведомлений, подача исковых заявлений в суд и пр. Возможность формирование списка должников по разным критериям, в частности. o Дата отчета – Отчет, показывающий состояние дел на заданную дату (текущую или прошедшую), o Количество неоплаченных счетов у абонента - список абонентов, не оплативших счета за несколько периодов (1 месяц, 2 месяца, ...), o Размер задолженности Список абонентов, имеющих задолженность, равную начислениям за 1 месяц (2, 3 месяца), o Пороговая величина задолженности – список абонентов, у которых задолженность «меньше, чем», «больше чем», «в диапазоне...». Формирование оперативной отчетности, отчетности для вышестоящей организации и государственных органов. 31 4.1.2.4. Компонент «Управление Обслуживанием абонентов» Компонент будет содержать следующие функциональные возможности: Регистрация и ведение обращений клиентов (заочное - по каналам коммуникации, а так же очное обращение); Ведение следующих данных обращений: o Дата/Время; o Класс; o Операция; o Вид; o Исходящий/входящий; o Дополнительные Документы; o Приоритет o Информация от клиента Формирование базы данных по обращениям клиентов, включающую персональные, адресные и контактные данные обратившегося клиента, возможность поиска обращений по данным клиента; Ведение сроков обработки обращений; Управление файлами-вложениями (образами документов) в обращениях клиентов; Формирование оповещений сотрудников о сроках выполнения заданий; Формирование задач по информированию клиентов об увеличении сроков рассмотрения обращений (жалоб) с указанием причин. 4.1.2.5. Компонент «Управление нетехническими потерями» Потоками электроэнергии и Компонент будет содержать следующие функциональные возможности: Формирование и хранение структуры баланса Подстанции; Хранение и ведение данных, необходимых для расчета величины допустимого небаланса подстанции (количество часов работы силовых трансформаторов в месяц, потери мощности при коротком замыкании, номинальные мощности силовых трансформаторов и т.д.), согласно утвержденной методике расчета величины допустимого небаланса подстанции; Автоматический расчет величины допустимого небаланса подстанций согласно утвержденной методике величины допустимого небаланса подстанций; Расчет фактической величины допустимого небаланса подстанций; Формирование Актов о составлении баланса электрической энергии на подстанции; 32 Формирование баланса электрической энергии на подстанции в разрезе систем (секций) шин; Хранение результатов расчета величины электроэнергии на подстанции в Системе; Хранение любого изменения данных используемых для расчета допустимого небаланса подстанции, а также структуры баланса подстанции в журналах изменений; Формирование и хранения в системе структуры баланса линий 6-10кВ, на основании топологии электрической сети; Внесение в Систему данных о нормативно-технологических потерях в линиях 6-10кВ, в единичном (по линии) и массовом (из согласованных шаблонов) порядке; Расчет величины фактического небаланса линии 6-10кВ; Формирование отчетной формы баланса электрической энергии в линиях 6-10кВ; Хранение любого изменения структуры баланса линии 6-10кВ в журналах изменений; Формирование и хранение в системе структуры баланса линий 0,4кВ, на основании топологии электрической сети; Внесение в Систему данных о нормативно-технологических потерях в линиях 0,4кВ, в единичном (по линии) и массовом (из согласованных шаблонов) порядке; Расчет величины фактического небаланса линии 0,4кВ; Хранение любого изменения структуры баланса линии 0,4кВ в журналах изменений; Внесение и хранение плановых данных в структуру развернутого баланса по электрическим сетям; Расчет фактических значений развернутого баланса по структурным единица: ОАО «Северэлектро», Региональное отделение, РЭС; Хранение любого изменения структуры развернутого баланса по электрическим сетям, а также плановых данных в журналах изменений; Формирование отчетной формы развернутого баланса (Отчет позволяет сформировать данные по поступлению в сети, внутрисетевым перетокам (при наличии учета), полезному отпуску в разрезе уровней напряжения по форме развернутого баланса за заданный расчетный период по зоне ОАО «Северэлектро»). фактического небаланса 4.1.2.6. Компонент «Управление Служебными распоряжениями» Компонент будет содержать следующие функциональные возможности: Возможность автоматически оформлять служебные распоряжения в ходе процессов обслуживания абонентов, новые подключения, коммерческий 33 цикл, управление электроэнергией; абонентами неплательщиками и контроль над Различные виды и типы служебных распоряжений, в зависимости от задачи: соединение, прекращение подачи электроэнергии, переподключение, осмотр, замена оборудования и т.д.; Распределение задач между сотрудниками, которые могут сотрудниками компании или специально нанятые для этой работы; Учет необходимых материалов, работы выполняемые у клиента; Регистрация выполненных мероприятий; Проверка и последующее обновление служебных распоряжений выданных при всех процессах; Ведение различных этапов служебных распоряжений: выдача, отмена, и решение. Регистрация служебных распоряжений: даты, часы, пользователи, идентификация персонала выполняемого мероприятия, выполненные и не выполненные операции, использованные материалы, время, расходы и т.д. Запись времени, которое потребовалось для выполнения служебного распоряжения. быть 4.1.2.7. Компонент «Личный кабинет клиента» Компонент будет содержать следующие функциональные возможности: Доступ к собственной информации абонента o Просмотр и корректировка персональных данных абонента (ФИО, адресные данные); o Просмотр и корректировка данных о действующих договорах; o Просмотр и корректировка данных о лицевых счетах и оказываемых услугах. Предоставление клиентам данных об объемах и стоимости оказываемых абоненту услуг и данных по показаниям приборов учета o Просмотр истории показаний приборов учета; o Просмотр истории потребления услуг; o Просмотр истории и текущего состояния лицевых счетов абонента; o Просмотр оплаченных/неоплаченных счетов абонента; o Просмотр истории платежей абонента; o Формирование отчетных форм и печатных форм платежных документов. Предоставление показаний приборов учета абонентом o Внесение абонентом данных по показаниям собственных приборов учета. Информирование клиентов компании 34 o Предоставление абонентам подразделений ОАО «Северэлектро» информации о деятельности компании, тарифной политике, действующего законодательства, предоставляемых клиентам услугах. 4.1.2.8. Компонент «Управленческий контроль» Компонент будет содержать следующие функциональные возможности: Информационные панели и визуализация o Построение индивидуальных, информационных панелей. основанных на технологии flash, o Легкие в построении и использовании модели для проведения анализа "что если". o Интеграция в корпоративный портал. o Преднастроенные компоненты: графики, карты, спидометры, селекторы, переключатели. Обработка специальных запросов, отчетность и анализ o Простота использования и ориентированность на бизнес-пользователей. o Единый интерфейс для доступа ко всем источникам данных. o Использование привычных бизнес-терминов при построении аналитического запроса. o Возможность самостоятельного построения нестандартных аналитических запросов. Отчетность o Получение данных из любых источников. o Доступ и преобразование программирования. информации в отчетную форму без o Возможность построения иерархических отчетов. o Широкие возможности для подготовки печатных форм. o Предоставление информации через WEB. Поиск и оценка o Простота оценки и скорость поиска по сотням внутренних и внешних источников данных. o Простота в использовании. Расширенный анализ o Выполнение интерактивной аналитической обработки данных. o Широкий спектр функций для анализа разноплановых наборов данных. o Возможность проводить более совершенный и точный прогнозный анализ. Интеграция Business Objects c MS Office o Легкая интеграция аналитических данных в приложения Microsoft Office. 35 o Возможность обновления данных непосредственно из приложений Microsoft Office. o Возможность обмена документами со встроенными аналитическими отчетами. Удаленный доступ к аналитическим данным (Business Objects Mobile) o Доступ к аналитической информации с мобильного устройства. o Простая установка и настройка. o Безопасный доступ к данным. 4.1.3. Показатели назначения Общие возможности: Биллинговая система будет поддерживать работу находящихся на территориально разобщенных объектах. Будет обеспечиваться возможность перенастройки системы при изменении нормативно-правовой базы без изменения программного кода Биллинговой системы. Будет обеспечиваться возможность увеличения количества одновременно работающих пользователей. Будет обеспечиваться возможность тиражирования проектных решений системы на всех потенциальных объектах внедрения. Будет обеспечено поэтапное наращивание, как производительности, так и функционального состава системы. Будет обеспечена возможность интеграции Системы информационными системами и программными продуктами. Будет реализован принцип открытой архитектуры построения системы, обеспечивающий возможность встраивания и взаимодействия с любыми другими системами. Биллинговая система будет иметь открытые интерфейсы для развития и интеграции. пользователей, с другими Степень приспособляемости системы к изменению процессов и методов управления: Биллинговая система обеспечит настройку и адаптироваться к изменению параметров и методов управления без проведения перепрограммирования на уровне общего программного обеспечения (системного и прикладного программного обеспечения). Адаптация системы будет осуществляться путем проведения структурной и параметрической настройки соответствующих функциональных частей. Процесс настройки и адаптации будет проводиться экспертами в предметной области и прикладных программистов. Процесс настройки и адаптации будет проводиться с помощью соответствующего программного обеспечения автоматизирующего процесс: 36 настройки и адаптации; документирования полученных результатов; переноса настроек с одного экземпляра Системы на другой. на стадии анализа Проекта развертывания Системы уточняется вид и тип используемого программного обеспечения. Степень приспособляемости системы к отклонениям параметров объекта автоматизации: Биллинговая система обеспечит: Масштабируемость по количеству пользователей в пределах от 10 до 5000; период накопления архивных данных - до 20 лет; период накопления и оперативной обработки данных - до 5 лет; настройку и изменение конфигурации автоматизированных рабочих мест пользователей; независимость от изменений в организационной структуре подразделений ОАО «Северэлектро», при сохранении состава и содержания выполняемых функций; возможность передислокации пользователей в пределах корпоративной сети ОАО «Северэлектро», и территориально удаленных площадок. 4.1.4. Допустимые пределы модернизации и развития Биллинговая система обеспечит возможность модернизации и развития для повышения степени приспособляемости при увеличении пределов изменений параметров объекта автоматизации свыше указанных ранее, а также при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. Модернизация и развитие Системы будут проводиться экспертами в предметной области и прикладных программистов, с помощью соответствующего программного обеспечения автоматизирующего процесс модернизации и развития, а также документирующего полученные результаты. На стадии анализа Проекта развертывания Системы уточняется вид и тип используемого программного обеспечения. Минимально допустимый срок эксплуатации Биллинговой системы при этом будет не менее 20 лет. 4.1.5. Вероятностно-временные характеристики, при которых сохраняется целевое назначение Биллинговой системы Минимальный срок эксплуатации Биллинговой системы в целом - не менее 20 лет; Минимальный срок эксплуатации аппаратного комплекса Биллинговой системы не менее 6 лет (при проведении соответствующей технической модернизации и развития); Минимальный срок эксплуатации телекоммуникационной системы - не менее 6 лет (при проведении соответствующей технической модернизации и развития); 37 На стадии анализа Проекта развертывания Системы уточняются «Требования к жизненному циклу Биллинговой системы на стадиях промышленной эксплуатации и утилизации». 4.1.6. Масштабирование Биллинговая система будет обладать достаточной гибкостью с тем, чтобы обеспечить работу даже при крупномасштабных организационных изменениях в ОАО «Северэлектро», резком изменении количества обслуживаемых клиентов и пользователей. При этом необходимо учитывать, что с увеличением количества клиентов и пользователей Системы может потребоваться приобретение дополнительных лицензий на систему в соответствии с ценовой политикой устанавливаемой вендором: SAP AG. 4.1.7. Надежность При разработке Системы будет соблюдено требование по надежности автоматизированной системы, как комплексному свойству сохранять во времени в установленных пределах значения всех параметров, характеризующих способность Системы выполнять свои функции в заданных режимах и условиях эксплуатации. Надежность функционирования Системы характеризуется в первую очередь устойчивостью (способностью безотказного функционирования) и восстанавливаемостью работоспособного состояния после произошедших сбоев или отказов. Разрабатываемые решения не будут конфликтовать с текущим программным обеспечением на серверах/рабочих местах пользователей ОАО «Северэлектро». Надежность комплекса параметрами: программных средств характеризуется следующими Будет обеспечена возможность восстановления информации и работоспособности комплекса программных средств после сбоев в случае возникновении аварийных ситуаций; Надежность комплекса программных средств, при увеличении пользователей, будет обеспечена возможностями его масштабирования. числа Аварийными ситуациями для Системы являются: Отказы (сбои) в аппаратном обеспечении; Отказы (сбои) в системном программном обеспечении; Отказы (сбои) в обслуживающем программном обеспечении; Отказы (сбои) в прикладном программном обеспечении. Не допускается простой работы пользователей Системы, кроме случаев возникновении аварийных ситуаций, при этом время восстановления работы серверных средств системы (прикладное ПО, базы данных) не будет превышать 6 часов. 4.1.8. Эргономика и техническая эстетика Печатные формы (отчеты, справочные списки, бланки) будут единообразно распечатываться независимо от используемого принтера. Вид фиксированных печатных форм будет соответствовать установленным в ОАО «Северэлектро» формам бумажных документов. 38 Биллинговая система будет предоставлять удобные средства поиска, навигации, распространения по всем территориальным подразделениям, разграничения доступа. Конфигурация рабочих станций будет обеспечивать удобный пользователя интерфейс, отвечающий следующим требованиям: для o В части внешнего оформления: наличие графического многооконного режима; настраиваемость графических элементов интерфейса, в том числе цветового оформления, в пределах возможностей операционной системы и технических средств; o в части диалога с пользователем: будет обеспечен удобный и интуитивно понятный интерфейс для пользователя, который хорошо знает свою предметную область и не является специалистом в области информационных технологий. интерфейс будет оптимизирован для выполнения типовых и часто используемых стандартизованных прикладных операций; взаимодействие пользователей с Биллинговой системой будет осуществляться на русском языке, исключения могут составлять только системные сообщения, не подлежащие русификации; Система не будет отображать на экране элементы управления, которые выполняют действия, не определенные правами конкретной функциональной роли; Система не будет позволять пользователю выход за пределы назначенных ему ролевых функций; Экран пользователя будет содержать только информацию для выполнения текущей функции; необходимую при обнаружении Системой ошибок, связанных с действиями пользователя, будет выдаваться сообщение с пояснениями, достаточными для исправления ошибки; все элементы управления, выполняющие одинаковые функции, будут называться и размещаться одинаково; представление справочной информации будет иерархическим с возможностью выбора основания классификации пользователем; будет обеспечено предоставление контекстно-зависимой помощи; интерфейс пользователя вероятности совершения действий. будет способствовать уменьшению оператором случайных ошибочных 4.1.9. Стандартизация и унификация Использованию типовых рабочих мест, компонентов и комплексов: Составные части Биллинговой системы будут построены с использованием стандартных и унифицированных методов реализации функций 39 информационной системы, входящих в состав используемой системы проектирования (среда разработки Биллинговой системы). Реализация каждого из составной части Системы будет производится с использованием единой для данного комплекса системы проектирования. Используемое решение Системы будет обеспечивать функциональных задач, операций и интерфейсов. Автоматизированные рабочие места будут построены на основе типовых решений построения клиентских рабочих мест Биллинговой системы. Типовое решение будет обеспечивать тиражирование одного решения на все подразделения (компании) ОАО «Северэлектро», без дополнительного проектирования путем изменения настроек и состава. В качестве системы управления базами данных будет применена единая (типовая) СУБД для всех баз данных в рамках решения функциональных задач (учетный комплекс, хранилище данных и репозиторий документов) Системы. Применение СУБД типов, отличных от базового, допустимо в особо оговоренных случаях. В качестве операционных систем серверов Биллинговой системы будет применена единая (типовая) операционная система. унификацию Использование типовых классификаторов В составе Биллинговой системы будут применены типовые (унифицированные) в рамках Корпоративной информационной системы ОАО «Северэлектро» классификаторы и кодификаторы. Использование унифицированных форм предоставления печатных документов (отчеты, справочные списки, бланки) Печатные документы, формируемые Биллинговой системой, будут иметь унифицированное содержание и форму предоставления для каждого вида печатного документа. На стадии проектирования Проекта развертывания Биллинговой системы создаются «Перечень, формы представления, правила формирования, регламент печатных документов». Используемый принтер для рабочих мест, в общем случае, должен быть формата A4, черно-белая лазерная печать. Используемый принтер для рабочих мест, где формируются отчеты, справочные списки, должен быть формата A3, A4, черно-белая лазерная печать. 4.1.10. Интеграция Системы В качестве интегрированной информационной системы, решение будет поддерживать интеграцию с другими системами, чтобы уменьшить возможность ошибочных расчетов и неправильного обращения информации, сохраняя целостность данных и обновленную информацию нетронутой. Кроме того, система будет предназначена для размещения будущих интерфейсов и будущих усовершенствований. 40 Приложение будет способствовать развитию интерфейсов с IT-системами ОАО Северэлектро и с другими приложениями (SOA/на основе веб-сервиса). В частности, новая биллинговая система будет обеспечена интерфейсами для следующих подсистем: Финансовая и бухгалтерская система (ERP): для разработки доступа интерфейса к базе данных финансовой и бухгалтерской системы, будет представлена вся необходимая информация. Интерфейс будет реализован вместе с биллинговой системой. ООО «Сайнер» рекомендует Заказчику к внедрению SAP ERP систему, поскольку она имеет общую платформу приложения и базу данных с реализуемой в рамках данного проекта Биллинговой системой, что обеспечивает большое количество интеграционных точек без необходимости разработки интеграционных интерфейсов. 4.2. Система управления инцидентами: будет представлена вся информация, необходимая для разработки интерфейса с базой данных Системы Управления Инцидентами (IRMS) и реализован интерфейс. АИИСКУЭ (Автоматизированная Информационная Система Коммерческого Учета Электроэнергии) - Система дистанционного измерения или AMR: Для того, чтобы иметь возможность получать данные абонентов, подключенных к АИИС КУЭ или имеют собственные AMR счетчики, будет представлена вся информация, необходимая для разработки интерфейса, которая позволит обеспечить доступ АИИСКУЭ к базе данных Биллинговой системы и реализовать интерфейсы. MS Excel: Информация управления будет легко экспортироваться в Excel в формате, определенным пользователем. MS Word: Могут быть выгружены отчеты ранее определенные в формате Word. MS Access: Информация, полученная из базы данных Биллинговой системы, может быть выгружена в базу данных в формате Access. Технические характеристики Системы 4.2.1. Виды обеспечения 4.2.1.1. Программное обеспечение Биллинговой системы Система будет построена на базе следующего ПО: SAP ERP ECC 6.0 Ehp7 или выше; SAP BusinessObjects Business Intelligence platform 4.1 или выше; SAP Process Orchestration 7.4 или выше; SAP Multichannel Foundation for Utilities V1.2 или выше; SAP Solution Manager 7.1 или выше; под управлением ОС SUSE Linux Enterprise Server 11 SP1 или выше. 41 В качестве СУБД будет использоваться SAP HANA и Oracle Database 11 версии не ниже 11. Программное обеспечение Биллинговой системы будет функционировать на следующих платформах: серверные компоненты – на платформе UNIX; клиентские компоненты – на платформе Windows XP (и выше); Изменения, вносимые вендором программного обеспечения Биллинговой системы, в части ядра не будут приводить к изменениям в прикладной части, разработанной ранее программистами сопровождения Системы с использованием предыдущих версий ядра. Платформа SAP Solution Manager необходима для технического администрирования (загрузки обновлений, генерации ключей разработчика и получения лицензий) всего программного обеспечения SAP используемого для создания Биллинговой системы (а так же для будущих систем реализуемых на платформе ПО SAP). Так же SAP Solution Manager будет использован для организации технической поддержки Биллинговой системы на этапах опытной и постоянной эксплуатации системы. В качестве хранилища файлов первичной информации будет использоваться ПО SAP Content Server. Будет предусмотрена возможность неограниченного расширения дискового пространства. 4.2.1.2. Рекомендуемая архитектура решения Предлагаемое решение будет базироваться на трехуровневой архитектуре для каждого компонента Системы, требующего отдельной инсталляции. За счет построения трехсистемного ландшафта обеспечивается стабильность и эффективность функционирования. Схема системного ландшафта представлена на рисунке ниже. DEV TST PRD Система разработки Тестовая система Продуктивная система Server Server Server Рисунок 1. Системный ландшафт Трехсистемный ландшафт обеспечивает следующее: o возможность проводить изолированное тестирование программного кода до переноса их в продуктивную систему; настроек и o реализация дополнительных функций может проходить, не затрагивая продуктивную работу; 42 o производительность систем не изменяется с ростом нагрузки на других; o специфические требования систем к вычислительным ресурсам обеспечиваются выделенной вычислительной инфраструктурой. Настройки и разработки для продуктивной системы выполняются в системе разработки (DEV), затем транспортируются в тестовую систему (TST) для сборки и проверки и после успешного тестирования переносятся в продуктивную (PRD) систему (см. рисунок). 4.2.1.3. Информационное обеспечение Биллинговой системы Биллинговая системами через: система обеспечит информационный обмен со смежными DB-линки между СУБД (в исключительных случаях); автоматизированную выгрузку/загрузку ASCII-файлов через специальные интерфейсы; автоматизированную выгрузку/загрузку XML-файлов через специальные интерфейсы по (SOA/ на основе веб-сервисов). Структура процесса сбора, обработки, передачи данных и представлению данных между компонентами Биллинговой системы, в случае реализации ее в рамках нескольких АИС, будет стандартизована: для пакета функциональной документации; для пакета технической документации; для алгоритмов; для библиотек методов трансформации, манипуляции данных; для программного кода пакетов загрузки/извлечения данных, физического описания объектов базы данных, представления данных, процедур work flow (потока заданий). Нормативно-справочная информация, содержащаяся в Биллинговой системе, будет однозначно согласована с отраслевыми, уровня предприятия классификаторами и кодификаторами, утвержденными для использования в ОАО «Северэлектро». Для Биллинговой системы будет использоваться программное обеспечение СУБД (система управления базой данной), программное обеспечение сервера приложений, программное обеспечение системы копирования/восстановления баз данных и файловых систем, программное обеспечение системы корпоративной отчетности и BI – класса Enterprise Edition (для промышленного использования). 4.2.1.4. Лингвистическое обеспечение Биллинговой системы Вся документация, тексты онлайн помощи и пользовательские интерфейсы будут на русском языке (все экраны, меню и т.д. будут показывать правильные технические термины на русском языке). Все программное обеспечение будет правильно отображать, вычислять и передавать дату и время, применяемый формат будет: дд/мм/гггг и чч:мм:сс. 43 Прикладной программный код Биллинговой системы уровня представления (или Внешний уровень), уровня бизнес-логики (или Внутренний уровень), уровня доступа к данным (или Предметный уровень) будет открытым. Биллинговая система будет иметь однозначное и задокументированное разделение прикладного программного кода на программный код немодифицируемого ядра, все исправления в который вносит вендор, и на программный код доступный для модификации и дополнения программистами сопровождения Биллинговой системы; 4.2.1.5. Техническое обеспечение Биллинговой системы Требования к каналам доступа (минимальная пропускная полоса): o Для SAP GUI – не менее 9.6 КБит\с для клиентских рабочих мест; o Пропускная способность между серверами 1Гбит\с. Рекомендуемые минимальные требования к клиентским местам представлены ниже: Процессор Pentium IV– 1 ГГц, 512 Мбайт ОЗУ Жесткий диск не менее 20 Гбайт Операционная система Windows XP, Windows Vista, Windows 7 или выше Прочее оборудование Сетевая карта Ethernet/Fast Ethernet Принтер 4.2.2. Таблица требований управления нового биллинга/Системы коммерческого Общие требования ТРЕБОВАНИЕ Соответ ствует Не соответ ствует Замечания о соответствии 1 Коммерческая система должна быть транзакционной и данные должны быть охвачены онлайн там, где они возникли и чтобы пользователи могли с ними ознакомиться. Она также может использовать пакетную обработку при работе с массивной информацией. Соответ ствует Коммерческая система SAP будет транзакционной и данные будут охвачены онлайн там, где они возникли и чтобы пользователи могли с ними ознакомиться. Она также может использовать пакетную обработку при работе с массивной информацией. 2 Она должна быть параметрируемой, как на общем уровне, так и на модульном или функциональном уровне, где Соответ ствует Система SAP будет параметрируемой, как на общем уровне, так и на модульном или функциональном уровне, где 44 пользователи могут контролировать определенные функции. Функции, которые принадлежат менеджеру системы, также могут быть параметризованными. пользователи могут контролировать определенные функции. Функции, которые принадлежат менеджеру системы, также могут быть параметризованными. 3 Она позволяет выпускать и представлять отчеты, таблицы, показатели и статистические данные в целом на экране, на бумаге или экспортировать на магнитные носители или через офисные инструменты. Соответ ствует Система SAP позволяет выпускать и представлять отчеты, таблицы, показатели и статистические данные в целом на экране, на бумаге или экспортировать на магнитные носители или через офисные инструменты. 4 Соответ Реализация системы должна ствует включать бизнес процедуры и модель правил, что позволит поддерживать систему. Она также будет иметь один или больше уровней онлайн помощь для пользователей на русском/кыргызском языках (правильные технические термины на русском/кыргызском). Реализация системы будет включать бизнес процедуры и модель правил, что позволит поддерживать систему. Она также будет иметь один или больше уровней онлайн помощь для пользователей на русском языке (правильные технические термины на русском). 5 Дисплей должен быть на русском/кыргызском языках (экран, меню, и т.д. должны использовать правильные технические термины на русском/кыргызском). Соответ ствует Дисплей будет на русском языке (экран, меню, и т.д. будут использовать правильные технические термины на русском). 6 Она должна быть в состоянии выдержать обновленные версии, без нового проекта реализации системы. Она должна иметь эволюционное и внеплановое техническое обслуживание. Изменение версии не должно влиять на нормальное функционирование биллингового процесса. Соответ ствует Система SAP будет в состоянии выдержать обновленные версии, без нового проекта реализации системы. Она будет иметь эволюционное и внеплановое техническое обслуживание. Изменение версии не будет влиять на нормальное функционирование биллингового процесса. 45 7 Минимальная техническая документация, которую требуется передать, когда работа завершена, состоит из: Соответ ствует Минимальная техническая документация, которая будет передана, когда работа завершена, состоит из: a) Обновленное Руководство Пользователя; a) Обновленное Руководство Пользователя; b) Обновленная Модель Данных; b) Обновленная Модель Данных; c) Обновленный Словарь Данных; c) Обновленный Словарь Данных; d) Обновленный Функциональный Диапазон; d) Обновленный Функциональный Диапазон; e) Руководство по Эксплуатации Системы; e) Руководство по Эксплуатации Системы; f) Руководство для поддержки и технического обслуживания системы (конфигурация, анализ ошибок и т.д.); f) Руководство для поддержки и технического обслуживания системы (конфигурация, анализ ошибок и т.д.); g) Документы анализа и процесса реконструкции; g) Документы анализа и процесса реконструкции; h) Руководство анализа и концептуального дизайна системы; h) Руководство анализа и концептуального дизайна системы; i) Системный администратор пользователя; i) Системный администратор пользователя; j) Документы по методологии миграции данных; j) Документы по методологии миграции данных; k) План реализация тестовой системы и принятие. k) План реализация тестовой системы и принятие. 8 Она должна обеспечивать интеграцию с другими приложениями, внутренне и внешне, через Сервис Ориентированную Архитектуру (СОА), что позволяет экспозицию своей функциональности через службы или доступ к другим приложениям с помощью своих служб. Соответ ствует Система SAP будет обеспечивать интеграцию с другими приложениями, внутренне и внешне, через Сервис Ориентированную Архитектуру (СОА), что позволяет экспозицию своей функциональности через службы или доступ к другим приложениям с помощью своих служб. 9 Поставщик должен будет убедиться, что при изменении версии это не влияет на нормальное функционирование компании. Соответ ствует ООО «Сайнер» обеспечит выполнение требования, изменение версии не будет влиять на нормальное функционирование компании. 46 10 Она должна обеспечивать определение профилей безопасности простым и гибким образом, что позволяет назначение разрешений группе пользователей или отдельным пользователям. Соответ ствует Система SAP обеспечивает определение профилей безопасности простым и гибким образом, что позволяет назначать полномочия группе пользователей или отдельным пользователям. 11 Это должно позволить контролировать состояние пользователей (т.е. активный, заблокированный, истекший и т.д.). Соответ ствует Система SAP позволяет контролировать состояние пользователей (т.е. активный, заблокированный, истекший и т.д.). 12 Она должна обеспечивать ограничение доступа к приложениям, благодаря сочетанию следующих уровней авторизации: Соответ ствует Система SAP позволяет обеспечивать ограничение доступа к приложениям, благодаря сочетанию следующих уровней авторизации: - На уровне Модуля (например: выставление счетов) - На уровне Модуля (например: выставление счетов) - На уровне Приложения (например: коррекция выставления счетов/считывания) - На уровне Приложения (например: коррекция выставления счетов/считывания) 13 Системы должны безопасно обновляться и иметь доступ к базе данных. Соответ ствует Системы SAP безопасно обновляются и имеют доступ к базе данных. 14 Она должна обеспечивать программирование пользователей и срок действия паролей. Пароли должны быть зашифрованы. Соответ ствует Система SAP обеспечивает программирование пользователей и срок действия паролей. Пароли хранятся в зашифрованном виде. 15 Интерфейс пользователя должны иметь кнопки доступа к наиболее часто используемым функциям (Панель инструментов). Соответ ствует Интерфейс системы SAP предоставляет пользователю кнопки доступа к наиболее часто используемым функциям (Панель инструментов). 16 Она должна обеспечивать программирование закрытия неактивных сессий пользователя. Соответ ствует Система SAP позволяет запрограммировать автоматическое закрытие 47 неактивных сессий пользователей. 17 Система должна регистрировать пользователя, дату и время последнего обновления каждого регистра в базе данных. Соответ ствует Система SAP позволяет регистрировать пользователя, дату и время последнего обновления каждого регистра в базе данных. 18 Она должна позволять экспортировать отчеты в другие приложения (Word, Excel, flat файлы, PDF и т.д.). Соответ ствует Система SAP позволяет экспортировать отчеты в другие приложения (Word, Excel, flat файлы, PDF и т.д.). 19 Она должна иметь средства мониторинга для коммерческого календаря и для воздействий, которые происходят во время коммерческих процессов (ошибки чтения, выставление счетов, сбор). Соответ ствует Система SAP имеет средства мониторинга для коммерческого календаря и для воздействий, которые происходят во время коммерческих процессов (ошибки чтения, выставление счетов, сбор). 20 Если есть какие-либо виды задержки в коммерческом цикле, система соответственно должна уведомить лицо ответственное за деятельность, через текстовое сообщение (SMS или email). Соответ ствует Если есть какие-либо виды задержки в коммерческом цикле, система SAP будет уведомлять лицо ответственное за деятельность, через текстовое сообщение (SMS или email). Функциональные Клиентов Возможности ТРЕБОВАНИЕ 21 Возможность осуществлять ввод данных потребления потребителя, также легко как к любой другой релевантной (связанной по смыслу) информации, характерной для групп потребителей. Система должна поддерживать возможность ведения различных тарифов и Соответ ствует Соответ ствует Контрактного Не соответ ствует Процесса Новых Замечания о соответствии Система SAP позволяет осуществлять ввод данных потребления потребителя, также легко как к любой другой релевантной (связанной по смыслу) информации, характерной для групп потребителей. SAP IS-U поддерживает возможность 48 групп потребителей (здравоохранение, образование, министерство обороны и т.д.). 22 Способность администрировать сервисные заказы, связанную документацию и идентифицировать отложенные документы. ведения различных тарифов и групп потребителей (здравоохранение, образование, министерство обороны и т.д.). Соответ ствует Система должна гарантировать, что подписание договора является цифровым и что вышеизложенное заполнено в электронном виде. Система SAP позволяет администрировать сервисные заказы, связанную документацию и идентифицировать отложенные документы. Система SAP позволяет цифровое подписание договора и ведение информации по договору в электронном виде. 23 Возможность оформить важные замечания, касающиеся новых запросов на подключение и новых условий поставок. Соответ ствует Система SAP позволяет вводить важные замечания, касающиеся новых запросов на подключение и новых условий поставки. 24 Она должна быть настроена для того, чтобы позволить распечатать запрос на обслуживание, а также для отправки его с помощью электронных средств. Соответ ствует Система SAP позволяет настроить возможность печати запросов на обслуживание, а так же для отправки его с помощью электронных средств. 25 Должна быть предусмотрена возможность выставлять счета услуги по установке отдельно от услуг снабжения. Также должна быть возможность формирования комбинированных фактур для сервиса установки и услуги снабжения электроэнергией. Соответ ствует Система SAP предоставляет возможность выставлять счета за услуги по установке отдельно от услуги электроснабжения. Так же в SAP существует возможность формирования комбинированных фактур для сервиса установки и услуги снабжения электроэнергией. 26 Она должна обеспечивать печать вспомогательных документов. Соответ ствует Система SAP позволяет печать вспомогательные документы. 27 Порядковый номер должен генерироваться автоматически для каждого заказа на обслуживание. Соответ ствует Система SAP позволяет генерировать автоматически порядковый номер для любого объекта или документа. Порядковый номер каждого заказа 49 на обслуживание будет генерироваться автоматически. 28 Порядковый номер запроса на обслуживание должен быть уникальным. Соответ ствует Порядковый номер запроса на обслуживание будет уникальным 29 Пользователь должен иметь возможность осуществлять поиск по статусу заказа на обслуживание, дате изменения и типу. Соответ ствует Система SAP предоставляет гибкие возможности поиска объектов в системе. Таким образом пользователь будет иметь возможность осуществлять поиск по статусу заказа, дате изменения и типу. 30 Запись изменений состояния должны храниться с соответствующими датами запроса на обслуживание. Соответ ствует В системе SAP все изменения объектов, выполненные пользователем, фиксируются и хранятся с соответствующей информацией о дате и времени. 31 Запрос на обслуживание может быть отменен в любое желаемое время. Соответ ствует Система SAP позволяет отменить запрос на обслуживание в любое время. 32 Возможность пользовательского процесса с несколькими контрактами в одном местожительстве или в разных местах, или, чтобы они принадлежали к различным тарифным сеткам. Соответ ствует Структура данных модуля SAP ISU обеспечивает возможность ведения нескольких контрактов на одном местожительстве или в разных местах, а так же что бы они принадлежали к различным тарифным сеткам. 33 Она должна обеспечивать присвоение нескольких договоров на услуги одного клиента одному уникальному счету. Выбор может быть сделан клиентом в индивидуальном порядке в соответствии с его интересами или потребностями. Соответ ствует Структура данных модуля SAP ISU обеспечивает возможность присвоения нескольких договоров на услуги одного клиента одному уникальному счету, в зависимости от индивидуального выбора клиента. 50 34 Система должна выдавать рабочие заказы, необходимые для выполнения запроса на обслуживание. Эти задачи могут быть выполнены непосредственно обслуживающим персоналом. Соответ ствует Система SAP позволяет выдавать рабочие заказы, необходимые для выполнения запроса на обслуживание. Эти задачи могут быть выполнены непосредственно обслуживающим персоналом. 35 Она должна позволить выбор типов заказов на выполнение работ исключительно для запроса на обслуживание. Соответ ствует Система SAP позволяет определить типы заказов на выполнение работ, которые будут указываться исключительно для запросов на обслуживание. 36 Новый Модуль Контрактного Процесса должен взаимодействовать с другими системами (существующий или будущий IRMS), таким образом, что такая система будет обновляться, в соответствии с информацией клиента, подписок, отмен, изменения счетчика, изменения адреса и т.д. Соответ ствует Система SAP позволяет реализовать интеграционные интерфейсы с другими системами. В ходе реализации проекта будет реализована возможность интеграции с другими системами (существующий или будущий IRMS), таким образом, что такая система будет обновляться в соответствии с информацией клиента, подписок, отмен, изменения счетчика, изменения адреса и т.д. Функциональные возможности коммерческого цикла – Считывание ТРЕБОВАНИЕ Соответ ствует Не соответ ствует Замечания о соответствии 37 Она должна обеспечивать запись показаний счетчиков для того, чтобы получить потребление абонентов. Соответ ствует SAP IS-U обеспечивает запись показаний счетчиков для того, чтобы получить потребление абонентов. 38 Пользователь должен иметь возможность проверить статус измерений (ручное считывание или AMR) или обновить его (активное, отключено, неактивное) по отношению к бизнес-процессу Соответ ствует Пользователь будет иметь возможность проверить статус измерений (ручное считывание или AMR) или обновить его (активное, отключено, неактивное) по отношению к бизнес-процессу 51 (процесс оплаты и повторного подключения, например). (процесс оплаты и повторного подключения, например). 39 Она должна обеспечивать модификацию или ручной ввод показаний счетчика, до выставления счета, для того, чтобы исправить или урегулировать любую неконсистентность считывания. Все изменения должны быть сохранены в журнале вместе с датой пользовательской информации изменения, первоначального значения и т.д. Соответ ствует SAP IS-U обеспечивает модификацию или ручной ввод показаний счетчика, до выставления счета, для того, чтобы исправить или урегулировать любую неконсистентность считывания. Все изменения сохраняются в журнале вместе с датой пользовательской информации изменения, первоначального значения и т.д. 40 Она должна позволить обработку показаний счетчиков, предоставляемых клиентом. Соответ ствует SAP IS-U позволяет обработку показаний счетчиков, предоставляемых клиентом. 41 Соответ Она должна обеспечивать ствует мониторинг различных процессов сбора данных, с подробной информацией по выполненным, не выполненным, противоречивыми и отсутствующим показаниям. 42 Система должна вести учет, каким образом данные о потреблении были собраны: вручную, с помощью портативных терминалов, AMR или телеметрии, от клиента, и т.д. Соответ ствует Система SAP IS-U ведет учет, каким образом данные о потреблении были собраны: вручную, с помощью портативных терминалов, AMR или телеметрии, от клиента, и т.д. 43 Система должна проверить все данные перед выставлением счетов. Любые нарушения должны автоматически сообщаться. Соответ ствует Система SAP IS-U проверяет все данные перед выставлением счетов. Любые нарушения автоматически сообщаются. 44 Там должен быть интерфейс с портативными терминалами маршрутов считывания счетчиков, для того, чтобы выгружать и скачивать информацию по показаниям, а также с Соответ ствует Система SAP IS-U позволяет реализовать интерфейсы с портативными терминалами маршрутов считывания счетчиков, для того, чтобы выгружать и скачивать информацию по SAP IS-U обеспечивает мониторинг различных процессов сбора данных, с подробной информацией по выполненным, не выполненным, противоречивыми и отсутствующим показаниям. 52 существующими системами дистанционного считывания счетчиков. показаниям, а также с существующими системами дистанционного считывания счетчиков. 45 Проверки собранных данных должны быть выполнены путем сравнения с оцененными значениями. Оценочные показания должны генерироваться системой на основе исторических данных. Соответ ствует Система SAP IS-U позволяет реализовать проверки собранных данных путем сравнения с оцененными значениями. Оценочные показания будут генерироваться системой на основе исторических данных. 46 Наблюдения за процессом сбора данных должны быть визуализированы. Соответ ствует Система SAP IS-U позволяет визуализировать процессы сбора данных, для наблюдения. 47 Необходимые данные для установки счетчика должны быть сохранены. Это включает в себя, среди прочего: серийный номер счетчика, номер пломбы, дата последней сертификации, дата изготовления прибора, измерительные трансформаторы, если таковые имеются, и т.д. Соответ ствует Система SAP IS-U позволяет сохранять необходимые данные для установки счетчика. Это включает в себя, среди прочего: серийный номер счетчика, номер пломбы, дата последней сертификации, дата изготовления прибора, измерительные трансформаторы, если таковые имеются, и т.д. 48 Следует отслеживать историю счетчиков от первой установки до конечного демонтажа. Новая биллинговая система должна также управлять счетчиками, которые не относятся к клиенту. Соответ ствует Система SAP IS-U позволяет отслеживать историю счетчиков от первой установки до конечного демонтажа. Система SAP IS-U также позволяет управлять счетчиками, которые не относятся к клиенту. 49 Установка, замена, подключение и отключение счетчиков должны быть зарегистрированы, а также необходимые задачи обслуживания, например, калибровки (счетчиков, ТТ и ТН, установка и удаление пломб всего жизненного цикла). Соответ ствует Система SAP IS-U позволяет регистрировать установку, замену, подключение и отключение счетчиков, а также необходимые задачи обслуживания, например, калибровки (счетчиков, ТТ и ТН, установка и удаление пломб всего жизненного цикла). Процесс замены прибора в течение цикла оплаты 53 Процесс замены прибора в течение цикла оплаты должен поддерживаться системой. поддерживаться системой SAP ISU. 50 Должны быть отчеты о показаниях и расчете потребления. Соответ ствует Система SAP IS-U позволяет сформировать отчеты по показаниям и расчетам, что позволит проверить правдоподобность показаний или продемонстрировать любую интересующую информацию по накопленным данным. 51 Выбранная система должна быть в состоянии получить информацию из Системы Автоматического считывание счетчиков (AMR) и/или от Системы Расширенной инфраструктуры считывания (AMI) через интерфейсы, которые позволяют импорт и экспорт данных для соответствующих процессов. Что касается AMI, это относится к таким процессам, как повышение или уменьшение мощности, отключение и повторного подключения и т.д. (по мимо процессов дистанционного считывания). Соответ ствует Система SAP IS-U позволяет реализовать интерфейсы к системам AMR и/или AMI, которые позволяют импортировать и экспортировать данные для соответствующих процессов. Для AMI, в том числе, повышение и уменьшение мощности, отключение и повторное подключение и т.д. (по мимо процессов дистанционного считывания). 52 Это позволяет реализовать считывание маршрутов в соответствии с запрограммированными сроками и типами маршрутов. Соответ ствует Система SAP IS-U позволяет реализовать считывание маршрутов в соответствии с запрограммированными сроками и типами маршрутов. Функциональные возможности коммерческого цикла – Биллинг ТРЕБОВАНИЕ 53 Процесс расчета должен иметь максимальный уровень параметрирования, что позволит Соответ ствует Соответ ствует Не соответ ствует Замечания о соответствии Система SAP IS-U позволяет указывать управляющие параметры расчета, количество 54 пользователям менять режим расчета без изменения программного обеспечения. параметров максимально, что позволит пользователям менять режим расчета без изменения программного обеспечения. 54 Система должна иметь информацию в своей базе данных по каждому счету (смоделированный, реальный и отмененный) таким образом, что бы они могли быть визуализированы и напечатаны в любое время. Соответ ствует Система SAP IS-U хранит в базе данных информацию по каждому счету (смоделированные, реальные и отмененные) таким образом, что они могут быть визуализированы и напечатаны в любое время. 55 Расчеты должны быть проведены путем определения набора параметров, в соответствии со всеми существующими бытовыми и не бытовыми тарифами. Соответ ствует Система SAP IS-U позволяет проводить расчеты путем определения набора параметров, в соответствии со всеми существующими тарифами бытовых и не бытовых потребителей. Например, если данный клиент превышает порог, разрешенный для социального тарифа потребления энергии система должна поместить его/ее на следующий уровень тарифа, внутренний тариф. Система должна быть параметризована для удовлетворения этой процедуры. Например, система SAP IS-U позволяет выполнить расчет следующим образом: если клиент превышает порог, разрешенный для социального тарифа потребления энергии система должна поместить его/ее на следующий уровень тарифа, внутренний тариф. Система параметризована для удовлетворения этой процедуры. 56 Она должна позволить наблюдение за статусом выставления счетов от места его происхождения до текущего этапа. Соответ ствует Система SAP IS-U позволяет отследить статус выставления счетов с момента и места его выставления до текущего этапа. 57 Система должна позволять обработку счетов в предварительном печатном виде, через издаваемые формы, или одним или несколькими пакетами программного обеспечения, специализирующихся на печати. Соответ ствует Система SAP IS-U позволяет обработку счетов в предварительном печатном виде, через издаваемые формы, или одним или несколькими пакетами программного обеспечения, специализирующихся на печати. 55 58 Выбранный система должна вести учет каждой тарифной цены, для того, чтобы иметь возможность рассчитать или пересчитать выставленные счета в любое время. Соответ ствует Система SAP IS-U позволяет вести справочник тарифных цен в привязке к периоду действия цены, что позволит рассчитать или пересчитать выставленные счета в любое время. 59 Она должна регистрировать среднее потребление в соответствии с тарифами, для его дальнейшего использования при выставлении счетов, когда нет вообще никаких данных. Соответ ствует Система SAP IS-U регистрирует среднее потребление в соответствии с тарифами, для его дальнейшего использования при выставлении счетов, когда нет вообще никаких данных. 60 Она должна иметь возможность принимать оплату, которая была произведена заранее, чтобы включить ее в выставленные счета или в счета, которые были выставлены по договоренности с абонентами, проживающими в труднодоступных местах. После того, как только показания были получены, надо выполнить необходимые изменения при выставлении счетов. Соответ ствует Система SAP IS-U имеет возможность принимать оплату, которая была произведена заранее, чтобы включить ее в выставленные счета или в счета, которые были выставлены по договоренности с абонентами, проживающими в труднодоступных местах. После того, как только показания были получены, система выполнит необходимые изменения при выставлении счетов. 61 Она должна обеспечивать расчет счетов в соответствии с программами для считывания. Соответ ствует Система SAP IS-U обеспечивает расчет счетов в соответствии с программами для считывания. 62 Система должна иметь настраиваемое средство выставления счетов, что позволяет ей адаптироваться к любому другому тарифу - таким образом, что любое изменение записывается - и она выполняет правильное выставление счетов и обратные корректировки в случае необходимости, в том числе правильные позиции бухгалтерского учета. Соответ ствует Система SAP IS-U имеет настраиваемое средство выставления счетов, что позволяет ей адаптироваться к любому другому тарифу - таким образом, что любое изменение записывается - и она выполняет правильное выставление счетов и обратные корректировки в случае необходимости, в том числе правильные позиции бухгалтерского учета. 56 63 Централизованное выставленное счетов должно осуществляться в рамках обычной программы показаний счетчиков или по фиксированному или по прогнозному потреблению. Соответ ствует Система SAP IS-U позволяет осуществлять централизованное выставленное счетов в рамках обычной программы показаний счетчиков или по фиксированному или по прогнозному потреблению. 64 Система должна обеспечивать применение различных видов биллинга специфических поставок. Соответ ствует Система SAP IS-U обеспечивает применение различных видов биллинга специфических поставок 65 Биллинг должен выпускаться в печатном виде, на магнитном носителе или в любом другом адекватном формате для передачи посредством электронного обмена данными (например, в банки). Соответ ствует Система SAP IS-U результаты биллинга позволяет выводить в печатной форме или в электронном виде для передачи посредством электронного обмена данными (например, в банки). В том числе с возможностью сохранения на магнитных или любых других носителях информации. 66 Система должна быть в состоянии управлять текущим счетом абонента, которая позволит группировать случайное количество счетов, принадлежащих одному и тому же абоненту, таким образом, что их срок истекает в один и тот же день или имеют одинаковый адрес доставки. Соответ ствует Система SAP IS-U позволяет управлять текущими счетами абонентов, группируя любое количество счетов, принадлежащих одному и тому же абоненту, таким образом, что их срок истекает в один и тот же день или имеют одинаковый адрес доставки. 67 Он должна обеспечивать расчет счетов по расходам в конце срока действия контракта. Соответ ствует Система SAP IS-U позволяет рассчитывать счета по расходам в конце срока действия контракта. 68 Она должна позволить отмену счета, по которому был получен иск. Соответ ствует Система SAP IS-U позволяет отменить счет, по которому был получен иск. 69 Он должна обеспечивать повторное выставление счетов на основе оценочных данных или Соответ ствует Система SAP IS-U позволяет повторное выставление счетов на основе оценочных данных или 57 фиксированного потребления, реальных данных, и данных, предоставленных клиентом. фиксированного потребления, реальных данных, и данных, предоставленных клиентом. 70 Она должна позволять выставлять счета по причине мошенничества и штрафов в отношении нелегальных услуг. Соответ ствует Система SAP IS-U позволяет выставлять счета по причине мошенничества и штрафов в отношении нелегальных услуг. 71 Она должна учитывать расчет налога в соответствии с национальным законодательством. Соответ ствует Система SAP IS-U позволяет учитывать расчет налога в соответствии с национальным законодательством 72 Система должна позволять выдачу отчета о состоянии счета или заявления по каждому абоненту. Соответ ствует Система SAP IS-U позволяет выдачу отчета о состоянии счета или заявления по каждому абоненту. 73 Она должна позволить выставление счетов потребления за период, рассматривая его как неуплаченный долг, добавив его в другие возможные неуплаченные долги. Соответ ствует Система SAP IS-U позволяет выставление счетов потребления за период, рассматривая его как неуплаченный долг, добавив его в другие возможные неуплаченные долги. 74 Система должна быть в состоянии отображать записи абонента. Соответ ствует Система SAP IS-U позволяет отображать записи абонента. 75 Система должна быть в состоянии создавать отчеты, статистические данные, показатели считывания и биллинговые процессы на основе: времени, ошибок, аномалий и т.д. Соответ ствует Система SAP IS-U позволяет создавать отчеты, статистические данные, показатели считывания и биллинговые процессы на основе: времени, ошибок, аномалий и т.д. 76 Он должна контролировать и управлять корректировкой счетов. Соответ ствует Система SAP IS-U позволяет контролировать и управлять корректировкой счетов 58 77 Система должна обновлять онлайн и в режиме реального времени текущий счет каждого абонента, в соответствии с процессами биллинга. Соответ ствует Система SAP IS-U обновляет онлайн и в режиме реального времени текущий счет каждого абонента, в соответствии с процессами биллинга 78 Он должен обеспечивать массовую отмену счетов при возникновении любых ошибок или несоответствия. Соответ ствует Система SAP IS-U позволяет выполнить массовую отмену счетов при возникновении любых ошибок или несоответствия. 79 ВЫСТАВЛЕНИЕ СЧЕТОВ ЗА ОСВЕЩЕНИЕ УЛИЦ. Она должна поддерживать выставление счетов всех типов потребления точек общественного учета (уличные фонари, автобус и т.д.). Соответ ствует Система SAP IS-U позволяет выставлять счета за освещение улиц, а так же всех типов общественного учета (уличные фонари, автобус и т.д.) 80 Она должна обеспечивать выдачу счетов по точкам общественного учета и их оплату. Она также должна быть в состоянии управлять счетами по внутреннему потреблению ОАО «Северэлектро» и их оплату (офисы и другие помещения компании). Соответ ствует Система SAP IS-U позволяет выдачу счетов по точкам общественного учета и их оплату. Она также позволяет управлять счетами по внутреннему потреблению ОАО «Северэлектро» и их оплату (офисы и другие помещения компании). 81 Система должна генерировать массовые процессы для выставления счетов: сотни или тысячи счетов в едином процессе, которые должны обновлять онлайн и в режиме реального времени базу данных абонентов и их текущие счета. Соответ ствует Система SAP IS-U позволяет генерировать массовые процессы для выставления счетов: сотни или тысячи счетов в едином процессе. Массовые расчеты обновляют онлайн и в режиме реального времени базу данных абонентов и их текущие счета. 82 Система должна гарантировать, что финансовая информация (бухгалтерский учет, бюджет и расходы) постоянно обновляется в автоматическом и безопасный способ, или через интерфейсы, входящих данных из другой Соответ ствует Система SAP IS-U гарантирует, что финансовая информация (бухгалтерский учет, бюджет и расходы) постоянно обновляется в автоматическом режиме и безопасным способом, или через интерфейсы, входящих данных из другой системы (1-C, банков, 59 системы (1-C, банков, платежных терминалов систем и т.д.). 83 Некоторые счетчики должны быть подключены посредством головной части системы, или другим способом. Эти системы будут обеспечивать доставку и получение данных онлайн: платежных терминалов систем и т.д.). Соответ ствует Система SAP IS-U имеет интерфейсы, которые позволят реализовать интеграцию с системами, выполняющими сбор данных о потреблении со счетчиков и передачу на них команд об отключении или переподключении и т.д. - Данные о потреблении - Заказы на отключение - Заказы на переподключение - И т.д. 84 Отсутствующие данные потребления электроэнергии должны рассчитываться. Соответ ствует Система SAP IS-U позволяет рассчитать отсутствующие данные потребления электроэнергии. 85 Система должна выдавать выписки из счетов клиентов. И предоставлять краткие данные в ERP/1-C. Соответ ствует Система SAP IS-U позволяет выдавать выписки из счетов клиентов и предоставлять краткие данные в ERP/1-C. Функциональные возможности коммерческого цикла – Сбор ТРЕБОВАНИЕ Соответ ствует Не соответ ствует Замечания о соответствии 86 Все пользователи системы, которые являются кассирами или внешними посредниками должны быть зарегистрированы и идентифицированы. Соответ ствует Система поддерживает данную функцию. Все пользователи системы, которые являются кассирами или внешними посредниками будут зарегистрированы и идентифицированы. 88 Должна быть предоставлена онлайн оплата в офисах и во внешних центрах сбора. Соответ ствует Система поддерживает данную функцию. Будет предоставлена онлайн оплата в офисах и во внешних центрах сбора. 60 89 Должны быть доступны различные формы оплаты: наличные деньги, чеки, кредитные карты и дебетовые карты. Соответ ствует Система должна позволять проводить платежи посредством электронного перевода денежных средств (платежные терминалы и интернет). 90 Оплата может сочетаться в различных формах (наличные деньги и чеки, наличные деньги и кредитные карты и т.д.) с одной или с различных квитанций. Система поддерживает данную функцию. Доступны различные формы оплаты: наличные деньги, чеки, кредитные карты и дебетовые карты. Система позволяет проводить платежи посредством электронного перевода денежных средств (платежные терминалы и интернет). Соответ ствует Система также должна осуществлять платежи по финансовой компенсации. Система поддерживает данную функцию. Оплата может сочетаться в различных формах (наличные деньги и чеки, наличные деньги и кредитные карты и т.д.) с одной или с различных квитанций. Система позволяет осуществлять платежи по финансовой компенсации. 91 Платежи, которые сделаны в один день, могут быть отменены. Соответ ствует Система поддерживает данную функцию. Платежи, которые сделаны в один день, могут быть отменены. 92 Кассиры должны автоматически прекращать работу, когда офисы оплаты закрываются. Соответ ствует Система поддерживает данную функцию. Кассиры будут автоматически прекращать работу, когда офисы оплаты закрываются. По соображениям безопасности, система должна быть в состоянии ограничить количество собранных денежных средств кассой и осуществить временное закрытие, чтобы позволить депонировать сумму, которая была собрана к этому моменту. 93 Кассовый остаток может управляться при помощи агентств и платежных терминалов. По соображениям безопасности, система в состоянии ограничить количество собранных денежных средств кассой и осуществить временное закрытие, чтобы позволить депонировать сумму, которая была собрана к этому моменту. Соответ ствует Система поддерживает данную функцию. Кассовый остаток может управляться при помощи агентств и платежных терминалов 61 94 Она должна иметь возможность записывать полную статистическую информацию по сборам абонентов и посредников. Соответ ствует Система поддерживает данную функцию. Она имеет возможность записывать полную статистическую информацию по сборам абонентов и посредников. 95 Кассовый остаток должен контролироваться в конце дня или при пересмене. Соответ ствует Система поддерживает данную функцию. Кассовый остаток будет контролироваться в конце дня или при пересмене. 96 Внешние посредники должны прослеживать возвращенные чеки и незарегистрированные платежи. Соответ ствует Система поддерживает данную функцию. Внешние посредники смогут прослеживать возвращенные чеки и незарегистрированные платежи 97 Она должна обеспечивать интерфейс с банковскими системами для того, чтобы передавать и принимать записи, относящиеся абонентам, которые выбрали автоматический дебет для оплаты счетов. Соответ ствует Система поддерживает данную функцию. Она обеспечит интерфейс с банковскими системами для того, чтобы передавать и принимать записи, относящиеся абонентам, которые выбрали автоматический дебет для оплаты счетов. 98 Она должна обеспечивать интерфейс с кредитными системами для того, чтобы передавать и принимать записи, относящиеся к платежам посредством кредитных/дебетовых карт. Соответ ствует Система поддерживает данную функцию. Она обеспечит интерфейс с кредитными системами для того, чтобы передавать и принимать записи, относящиеся к платежам посредством кредитных/дебетовых карт. 99 Квитанции абонентов, которые выбрали автоматический дебет с их банковских счетов, должны быть отправлены им. 100 Система должна обеспечивать связь с внешними платежными посредниками как онлайн, так и Соответ ствует Соответ ствует Система поддерживает данную функцию. Квитанции абонентов, которые выбрали автоматический дебет с их банковских счетов, будут отправлены им. Система поддерживает данную функцию. Система обеспечит связь с внешними платежными посредниками как онлайн, так и 62 офлайн (через собственные системы посредством SOA). 101 102 офлайн (через собственные системы посредством SOA). Она должна обеспечивать онлайн корректировку и контроль неправильных платежей. Соответ ствует Система имеет специальные операции по управлению возвращенными чеками: Соответ ствует - Генерация расходов (с банка) - Состояние, полученное в результате оплаченных счетов посредством чека или генерации новых расходов соответствующих сумм (конфигурация на уровне принятия решения) Система поддерживает данную функцию. Она обеспечит онлайн корректировку и контроль неправильных платежей. Система поддерживает данную функцию. Система имеет специальные операции по управлению возвращенными чеками: - Генерация расходов (с банка) - Состояние, полученное в результате оплаченных счетов посредством чека или генерации новых расходов соответствующих сумм (конфигурация на уровне принятия решения) - Контроль абонентом (письма, сообщения и т.д.) - Контроль абонентом (письма, сообщения и т.д.) 103 104 Она должна обеспечивать поддержание графиков и общих параметров. Она должна управлять различными видами соглашений. Система должна быть в состоянии зарегистрировать или отправить обратно сумму, которая была выплачена абонентом при совместном участии в строительной деятельности электросети. 105 Она может обрабатывать атрибуты и официальные уровни авторизации. Соответ ствует Соответ ствует Система поддерживает данную функцию. Она обеспечит поддержание графиков и общих параметров. Система поддерживает данную функцию. Она позволит управлять различными видами соглашений. Система в состоянии зарегистрировать или отправить обратно сумму, которая была выплачена абонентом при совместном участии в строительной деятельности электросети. Соответ ствует Система поддерживает данную функцию. Она может обрабатывать атрибуты и официальные уровни авторизации. 63 106 Она обрабатывает и объединяет счетчики AMI при следующих процессах сбора: Система поддерживает данную функцию. Она обрабатывает и объединяет счетчики AMI при следующих процессах сбора: Соответ ствует - Переподключение отключенных абонентов - Переподключение отключенных абонентов - Обновление балансового счетчика (для счетчиков предоплаты) - Обновление балансового счетчика (для счетчиков предоплаты) - Обновление тарифа, обнаружение мошенничества - Обновление тарифа, обнаружение мошенничества - и т. д. - и т. д. 107 Система должна позволять частичные и полные платежи. Она должна иметь модуль управления, который позволит правильно управлять сборами, с точными последующими, своевременными отчетами. Система также должна иметь возможность влиять на выплаты определенных займов по соответствующим счетам. Система поддерживает данную функцию. Система позволяет частичные и полные платежи. Она имеет модуль управления, который позволит правильно управлять сборами, с точными последующими, своевременными отчетами. Система также имеет возможность влиять на выплаты определенных займов по соответствующим счетам. Соответ ствует Функциональные возможности Процесса по Абонентам Должникам ТРЕБОВАНИЕ 108 109 Соответ ствует Не соответ ствует Замечания о соответствии Полная информация о платежах, проведенных абонентами должны быть доступна для справки. Соответ ствует Система поддерживает данную функцию. Полная информация о платежах, проведенных абонентами доступна для справки. Должны быть возможны частичные или полные платежи по счету. Соответ ствует Система поддерживает данную функцию. Полная информация о платежах, проведенных абонентами доступна для справки. 64 110 111 112 113 114 115 Как только просроченные счета были оплачены, должно быть автоматически выдано распоряжение на переподключение. Согласно политике ОАО «Северэлектро», должны быть приняты частичные платежи и платежные соглашения. Если баланс на банковском счете или на кредитной карте не достаточен, чтобы покрыть сумму, которую необходимо оплатить, должно автоматически выдаваться уведомление об оплате. Должны автоматически выдаваться распоряжения по абонентам, которые не выплатили все долги (распоряжение об отмене услуг, визиты, звонки и письма). Для выдачи уведомления, касающиеся гарантийного истечения, как это установлено в компании, они должны быть параметризованы. Следуя установленным Организацией определенным критериям, она должна разрешать отменять распоряжения по отключению электричества и возобновлять услуги без взимания оплаты. Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. Как только просроченные счета были оплачены, будет автоматически выдано распоряжение на переподключение. Система поддерживает данную функцию. Согласно политике ОАО «Северэлектро», будут приняты частичные платежи и платежные соглашения. Система поддерживает данную функцию. Если баланс на банковском счете или на кредитной карте не достаточен, чтобы покрыть сумму, которую необходимо оплатить, будет автоматически выдаваться уведомление об оплате. Система поддерживает данную функцию. Будут автоматически выдаваться распоряжения по абонентам, которые не выплатили все долги (распоряжение об отмене услуг, визиты, звонки и письма). Система поддерживает данную функцию. Для выдачи уведомления, касающиеся гарантийного истечения, как это установлено в компании, они будут параметризованы. Система поддерживает данную функцию. Следуя установленным Организацией определенным критериям, Система будет разрешать отменять распоряжения по отключению электричества и возобновлять услуги без взимания оплаты. 65 116 117 118 119 Она должна быть в состоянии контролировать ряд мероприятий, которые должны проводиться с учетом оперативных возможностей (например: она должна ограничить количество выданных распоряжений по отказам в зависимости от мощности Технического Центра, а также параметризации замещающих действий, таких как программирование телефонных звонков, выдача писем и т.д.). Он должна иметь возможность получать информацию о задолженности по различным уровням, типам абонентов, районов. При управлении задолженностями, система должна быть в состоянии идентифицировать долги в соответствии с определенными абонентами (Правительство, больницы, Министерство обороны, компании по водоснабжению и т.д.). Она должна позволять выбирать всех абонентов, чья задолженность и количество счетов к оплате превышает определенную сумму (параметр). Она должна давать возможность для конфигурации и гибкого определения правил, которые должны быть установлены для определения операций, которые должны выполняться (например, учитывать записи по задолженности и тарифу, виды абонентов, сумму долга и т.д.). Система должна составлять отчеты по дебетовому остатку, Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. Она будет в состоянии контролировать ряд мероприятий, которые должны проводиться с учетом оперативных возможностей (например: ограничит количество выданных распоряжений по отказам в зависимости от мощности Технического Центра, а также параметризации замещающих действий, таких как программирование телефонных звонков, выдача писем и т.д.). Система поддерживает данную функцию. Система имеет возможность получать информацию о задолженности по различным уровням, типам абонентов, районов. При управлении задолженностями, Система в состоянии идентифицировать долги в соответствии с определенными абонентами (Правительство, больницы, Министерство обороны, компании по водоснабжению и т.д.). Система поддерживает данную функцию. Система позволяет выбирать всех абонентов, чья задолженность и количество счетов к оплате превышает определенную сумму (параметр). Система поддерживает данную функцию. Система предоставляет возможность для конфигурации и гибкого определения правил, которые должны быть установлены для определения операций, которые должны выполняться (например, учитывать записи по задолженности и тарифу, виды абонентов, сумму долга и т.д.). 66 принимая во внимание дату, категорию, характер деятельности (здравоохранение, образование и т.д.), вид абонента (частный или государственный) и состояние задолженности. 120 121 122 123 124 В случае если оплата произведена или имеется платежное соглашение, она должна автоматически выдать распоряжение на повторное подключение. Она должна обеспечивать выдачу и закачку распоряжений на последующую проверку отмены. Она должна подготовить статистические данные об отмене услуг и переподключении, которые должны быть сохранены в данных системы. Она должна быть способна выдавать индивидуальный запрос на отключение. Она должна быть способна выдавать несколько отчетов, такие как: сводка переподключений; сводка специальных отключений; временные отключения; абоненты, которые не были отключены; абоненты, которые были отключены; абоненты, которые не имеют счетчики; абоненты у которых нет электричества; надбавки в Система позволяет составлять отчеты по дебетовому остатку, принимая во внимание дату, категорию, характер деятельности (здравоохранение, образование и т.д.), вид абонента (частный или государственный) и состояние задолженности. Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. В случае если оплата произведена или имеется платежное соглашение, Система автоматически выдаст распоряжение на повторное подключение. Система поддерживает данную функцию. Система обеспечит выдачу и закачку распоряжений на последующую проверку отмены. Система поддерживает данную функцию. Система подготовит статистические данные об отмене услуг и переподключении, которые будут сохранены в данных системы. Система поддерживает данную функцию. Система способна выдавать индивидуальный запрос на отключение. Система поддерживает данную функцию. Система способна выдавать несколько отчетов, такие как: сводка переподключений; сводка специальных отключений; временные отключения; абоненты, которые не были отключены; абоненты, которые были отключены; абоненты, которые не имеют счетчики; абоненты у которых нет электричества; 67 результате отключений и переподключений. 125 126 Она должна быть способна выдавать оперативные отчеты о: сроках отключения и процессах переподключения, уведомления об ошибках, статистические данные о действиях работников и т.д. Система должна быть в состоянии производить консолидированные текущие счета, которые позволят управлять крупными клиентами (например, Правительство) через счета, которые составляют определенные услуги. надбавки в результате отключений и переподключений. Система поддерживает данную функцию. Система способна выдавать оперативные отчеты о: сроках отключения и процессах переподключения, уведомления об ошибках, статистические данные о действиях работников и т.д. Соответ ствует Система поддерживает данную функцию. Система в состоянии производить консолидированные текущие счета, которые позволят управлять крупными клиентами (например, Правительство) через счета, которые составляют определенные услуги. Соответ ствует Это позволит системе получать общий отчет о состоянии счетов. Кроме того, они позволят возможность оплаты по отдельности, либо на консолидированном уровне, чтобы облегчить эту задачу управления. Это позволит системе получать общий отчет о состоянии счетов. Кроме того, они позволят возможность оплаты по отдельности, либо на консолидированном уровне, чтобы облегчить эту задачу управления. Система должна выдавать абоненту отчет о состоянии счета со ссылкой на указанный период. 127 Коммерческая система должна включать в себя управление всеми счетами, которые еще не были оплачены абонентом, и эта информация должна быть передана в Финансовую Систему (ERP). Функциональные абонентов ТРЕБОВАНИЕ Система будет выдавать абоненту отчет о состоянии счета со ссылкой на указанный период. Система поддерживает данную функцию. Коммерческая система будет включать в себя управление всеми счетами, которые еще не были оплачены абонентом, и эта информация будет передаваться в Финансовую Систему (ERP). Соответ ствует возможности Соответ ствует Процесса Не соответ ствует по обслуживанию Замечания о соответствии 68 128 129 130 131 132 Если у абонента имеется множество услуг, она должна позволять различные способы оплаты или различные банковские счета. Должен быть закреплен эксклюзивный номер идентификации абонента и договора, что позволит легко определить возможные долги. Она должна быть в состоянии управлять различными видами идентификации абонента, которые являются частью договора: владелец контракта, получатель услуг, ответственный за оплату и т.д. Она должна быть в состоянии отображать информацию о: распоряжениях, которые еще не были осуществлены, жалобы, нарушения, вопросы, которые не были решены, а также наблюдения, показания, сделанные по телефону и с записи абонента. Она должна записывать жалобы абонентов, что позволит иметь типы жалоб, предусмотренные законом и в соответствии с текущими потребностями компании. Они должны быть классифицированы на основе критериев компании. Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. Если у абонента имеется множество услуг, она позволит различные способы оплаты или различные банковские счета. Система поддерживает данную функцию. Будет закреплен эксклюзивный номер идентификации абонента и договора, что позволит легко определить возможные долги. Система поддерживает данную функцию. Система в состоянии управлять различными видами идентификации абонента, которые являются частью договора: владелец контракта, получатель услуг, ответственный за оплату и т.д. Система поддерживает данную функцию. Система в состоянии отображать информацию о: распоряжениях, которые еще не были осуществлены, жалобы, нарушения, вопросы, которые не были решены, а также наблюдения, показания, сделанные по телефону и с записи абонента. Система поддерживает данную функцию. Система будет записывать жалобы абонентов, что позволит иметь типы жалоб, предусмотренные законом и в соответствии с текущими потребностями компании. Они будут классифицированы на основе критериев компании. 69 133 134 135 136 137 138 Система должна быть в состоянии выполнять точную и достоверную последовательность мер на разных этапах, которые должна пройти жалоба. Кроме того, все эти мероприятия должны быть должным образом зарегистрированы. Если возникнет необходимость, она должна автоматически выдавать распоряжения при выполнении действий, когда была представлена жалоба. Она должна быть в состоянии обновлять жалобы в зависимости от проведенной деятельности. Когда возникает жалоба относительно счета, она может быть изменена путем ее отмены и создания новой с адекватными изменениями. Она должна быть в состоянии отменить жалобы, когда нет законного основания, например, когда жалоба является бессмысленной. Она должна иметь возможность консультировать различные жалобы по отраслям таким образом, чтобы дать ответы на каждую отрасль. Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. Система в состоянии выполнять точную и достоверную последовательность мер на разных этапах, которые должна пройти жалоба. Кроме того, все эти мероприятия будут должным образом зарегистрированы. Система поддерживает данную функцию. Если возникнет необходимость, Система автоматически будет выдавать распоряжения при выполнении действий, когда была представлена жалоба. Система поддерживает данную функцию. Система в состоянии обновлять жалобы в зависимости от проведенной деятельности. Система поддерживает данную функцию. Когда возникает жалоба относительно счета, она может быть изменена путем ее отмены и создания новой с адекватными изменениями. Система поддерживает данную функцию. Система в состоянии отменить жалобы, когда нет законного основания, например, когда жалоба является бессмысленной. Система поддерживает данную функцию. Система будет иметь возможность консультировать различные жалобы по отраслям таким образом, чтобы дать ответы на каждую отрасль. 70 139 140 141 142 143 144 Она должна быть в состоянии выставить счет, выпустить, изменить, консультировать, рассчитать бюджетные расходы, которые не предусмотрены в счете-фактуре. Абонент может получить различные услуги на свое имя и может иметь тот же самый счет на эти услуги или по одному счету на каждый. Она должна позволять вносить изменения, когда это необходимо. Например, когда требуется: поменять тариф, поменять адрес, по которому квитанция должен быть направлен или поменять имя держателя контракта. Система должна иметь возможность отправлять информацию в обычном порядке или через другие IT системы. Что касается функционирования Интернета, портал Клиента должен быть подключен онлайн и в реальном времени к центральной базе данных системы. Если система не работает, таким образом, например, с копией базы данных, она не будет принята. Система должна быть в состоянии отображать информацию через Интернет: квитанции, предыдущее потребление, изменения данных Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. Система в состоянии выставить счет, выпустить, изменить, консультировать, рассчитать бюджетные расходы, которые не предусмотрены в счете-фактуре. Система поддерживает данную функцию. Абонент может получить различные услуги на свое имя и может иметь тот же самый счет на эти услуги или по одному счету на каждый. Система поддерживает данную функцию. Система позволит вносить изменения, когда это необходимо. Например, когда требуется: поменять тариф, поменять адрес, по которому квитанция должен быть направлен или поменять имя держателя контракта. Система поддерживает данную функцию. Система SAP имеет возможность отправлять информацию в обычном порядке или через другие IT системы. Система поддерживает данную функцию. Портал Клиента будет подключен онлайн и в реальном времени к центральной базе данных системы. Система поддерживает данную функцию. Система в состоянии отображать информацию через Интернет: квитанции, предыдущее потребление, изменения данных 71 абонента, регистрацию нового контракта или его отмену и т.д. 145 Интерфейс должен быть доступен с системами IRMS и ERP для обмена необходимыми данными. абонента, регистрацию нового контракта или его отмену и т.д. Система поддерживает данную функцию. Будет реализован интерфейс с системами IRMS и ERP для обмена необходимыми данными. Соответ ствует Операции по процессам контроля электроэнергии и управлению нетехнических потерь ТРЕБОВАНИЕ 146 147 148 Все замеры электроэнергии, полученные из пунктов доставки (производство, передача и распределение) должны быть записаны на комплексной основе, относительно их периодичность, чтобы иметь точный энергетический баланс. Она должна быть способной отображать данные и сравнивать различные замеры, полученные из пунктов доставки. Кроме того, с помощью этих данных, должна быть обеспечена возможность понять изменения, которые происходят на ежедневной диаграмме по нагрузке. Она должна быть в состоянии исправить ошибочные значения замеров, отображаемых после проведенного анализа. Соответ ствует Соответ ствует Соответ ствует Соответ ствует Не соответ ствует Замечания о соответствии Система поддерживает данную функцию. Все замеры электроэнергии, полученные из пунктов доставки (производство, передача и распределение) будут записаны на комплексной основе, относительно их периодичности, чтобы иметь точный энергетический баланс. Система поддерживает данную функцию. Система способна отображать данные и сравнивать различные замеры, полученные из пунктов доставки. Кроме того, с помощью этих данных, будет обеспечена возможность понять изменения, которые происходят на ежедневной диаграмме по нагрузке. Система поддерживает данную функцию. Система в состоянии исправить ошибочные значения замеров, отображаемых после проведенного анализа. 72 149 150 151 152 153 154 Она должна позволять загрузку замеров, которые соответствуют каждому пункту поставки и показаниям абонента через интерфейсы или файлы. При загрузке файлов необходимо чтобы выполнялись требуемые утверждения последовательности и формат данных, а также выдача журнала ошибок. Система должна обрабатывать все загруженные замеры, в целях обеспечения ежедневными отчетами о замерах и в дальнейшем составлять энергетические балансы. Система должна иметь возможность загружать прогнозы. Она должна быть в состоянии ежедневно контролировать поток электроэнергии в систему в различных пунктах поставки, дифференцируя уровень напряжения и сравнивая его с прогнозом о покупке электроэнергии. Могут быть проверены проявления общих потерь компании в соответствии с каждой географической областью. Она также должна иметь возможность выполнять контроль потери электроэнергии в зависимости от РЭС, фидеров среднего Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. Система позволяет загрузку замеров, которые соответствуют каждому пункту поставки и показаниям абонента через интерфейсы или файлы. Система поддерживает данную функцию. При загрузке файлов будут выполняться требуемые утверждения последовательности и формат данных, а также выдача журнала ошибок. Система поддерживает данную функцию. Система будет обрабатывать все загруженные замеры, в целях обеспечения ежедневными отчетами о замерах и в дальнейшем составлять энергетические балансы. Система поддерживает данную функцию. Система имеет возможность загружать прогнозы. Система поддерживает данную функцию. Система в состоянии ежедневно контролировать поток электроэнергии в систему в различных пунктах поставки, дифференцируя уровень напряжения и сравнивая его с прогнозом о покупке электроэнергии. Система поддерживает данную функцию. Могут быть проверены проявления общих потерь компании в соответствии с каждой географической областью. Она также имеет возможность выполнять контроль потери электроэнергии в зависимости от РЭС, фидеров 35/10/6кВ и 73 напряжения и подстанций среднего/низкого напряжения. 155 156 157 158 159 Она должна быть в состоянии видеть подробную информацию о различных видах абонентов, о бедных и дотационных областях, которые требуют специального наблюдения. Она должна быть в состоянии производить диаграммы о выставленных счетах за электроэнергию в сравнении с поступившей электроэнергией, а также графики изображающие поток электроэнергии через различные уровни компании. Она должна быть способной записывать все определенные планы, а также их назначение, действия, которые необходимо выполнить, оценку продолжительности. Для каждой операции, определенной в плане восстановления нетехнических потерь, должна быть возможность идентификации ответственных людей, как они измеряются и планируемые данные. Каждый месяц, система должна автоматически выдавать операции, которые должны осуществляться КоммерческоТехнической Службой или нанятой компанией, в соответствии с установленным планом действий. подстанций среднего/низкого напряжения. Соответ ствует Соответ ствует Соответ ствует Соответ ствует Соответ ствует Система поддерживает данную функцию. Система в состоянии видеть подробную информацию о различных видах абонентов, о бедных и дотационных областях, которые требуют специального наблюдения. Система поддерживает данную функцию. Система в состоянии производить диаграммы о выставленных счетах за электроэнергию в сравнении с поступившей электроэнергией, а также графики изображающие поток электроэнергии через различные уровни компании. Система поддерживает данную функцию. Система способна записывать все определенные планы, а также их назначение, действия, которые необходимо выполнить, оценку продолжительности. Система поддерживает данную функцию. Для каждой операции, определенной в плане восстановления нетехнических потерь, будет возможность идентификации ответственных людей, как они измеряются и планируемые данные Система поддерживает данную функцию. Каждый месяц, система будет автоматически выдавать операции, которые должны осуществляться КоммерческоТехнической Службой или нанятой компанией, в соответствии с установленным планом действий. 74 Функциональные возможности управления процессом обслуживания распоряжений ТРЕБОВАНИЕ 160 161 162 Она должна обеспечивать возможность для автоматического выпуска рабочих распоряжений, полученных из любой операций системы (обслуживание абонентов, показания, квитанции, сбор, наем и жалобы). Должна быть возможность определения географических районов, которые относятся Техническим Центрам для автоматического назначение работ в зависимости от местоположения службы, что позволяет интеграцию с Географической Информационной Системой (ГИС) для оптимизации распределения ресурсов. Система должна быть в состоянии передавать информацию о служебных распоряжениях в систему ERP для расчета затрат с помощью обычных средств или через интерфейсы. Соответ ствует Соответ ствует Соответ ствует Соответ ствует Не соответ ствует Замечания о соответствии Распоряжения в системе могут быть представлены различными видами заказов (сервисные, ТОРО, IS-U), которые будут автоматически создаваться при наступлении определенных событий (например, при поступлении жалобы в систему - с помощью инструментов WF). Заказы включают в себя набор операций (работ), материалов, которые будут использованы. При привлечении к работам внешних подрядчиков в заказы включаются услуги подрядной организации. Система SAP может быть интегрирована с различными ГИС системами. Сервисные заказы могут использовать географические координаты или адреса объектов в алгоритмах формирования заказа и определение организационных присвоений при назначения исполнителей. Операции заказов могут нести информацию о плановых и фактических затратах, также могут выступать объектом контировкии для других документов, отражающих хозяйственную деятельность. При необходимости заказы с операциями и материалами могут быть переданы во внешние системы. 75 163 164 165 166 167 168 Все выполненные мероприятия по исполнению распоряжений, а также их продолжительность и подробности операций должны быть зарегистрированы. Соответ ствует Операции сервисных заказов имеют количественные и временные параметры позволяющие отражать их выполнение, а именно подтверждать работы, списывать на них материалы, акцептовать услуги. Она должна зарегистрировать специалиста, который был назначен для исполнения распоряжения. Соответ ствует Система должна выполнять автоматическую проверку согласования до выдачи рабочих распоряжений. Соответ ствует Согласование заказов может быть реализовано с помощью статусных схем и операций WF Соответ ствует Заказы поддерживают функцию печати и позволяют регистрировать факт печати Необходимо распечатать распоряжение по которому должна быть проведена установка, а система должна зарегистрировать что была сделана распечатка. Она должна быть в состоянии решать в больших масштабах рабочие распоряжения относительно: отключений, переподключений, уведомлений об отключениях и все, что связано с управлением по абонентамнеплательщикам. Она должна быть в состоянии позволить программировать операции, которые будут осуществляться при установке с определенными характеристиками (географическая область, подстанции, тарифы абонентов, среднее потребление, неоплаченные задолженности). Соответ ствует Соответ ствует Операции заказа может быть присвоен исполнитель Система SAP в состоянии обрабатывать большие потоки информации. Заказы могут быть относиться к различным видам хозяйственной деятельности Заказы могут быть созданы автоматически, в том числе с привязкой к организационным единицам, исполнителям, в зависимости от различных заданных параметров. В заказы могут быть автоматически добавлены, необходимые операции, в зависимости от этих параметров. Правила автоматического создания заказов 76 и добавления операций могут корректироваться и зависеть от заданных параметров. 169 Следует предоставлять отчеты о сроке государственной поверки счетчиков, трансформаторов тока и трансформаторов напряжения по регионам, по дате и т.д. Система SAP позволит формировать отчеты о сроке государственной поверки счетчиков, трансформаторов тока и трансформаторов напряжения по регионам, по дате и т.д. А так же создавать автоматически сервисные заказы на поверку. Соответ ствует Функциональные возможности для Процесса Управления ТРЕБОВАНИЕ 170 171 Она должна быть способной выдавать различные записи по сбору, например, по тарифным группам и абонентам, и по коммерческим филиалам. Она должна обеспечивать выпуск ежедневных отчетов, относительно всего коммерческого цикла (показания, выставление счетов и сбор). Соответ ствует Соответ ствует Соответ ствует Не соответ ствует Замечания о соответствии Платформа бизнес-аналитики SAP позволяет осуществлять сбор, преобразование и хранение информации в любых аналитиках и с любой периодичностью. Платформа сочетает в себе возможности построения непредсказуемых (ad hoc) запросов к данным реляционных баз данных и OLAP-серверов, мощные функции анализа информации и построения профессионально оформленных отчетов, а также гибкие возможности детализации. Платформа бизнес-аналитики SAP позволяет осуществлять сбор, преобразование и хранение информации в любых аналитиках и с любой периодичностью. Платформа сочетает в себе возможности построения непредсказуемых (ad hoc) запросов к данным реляционных баз данных и OLAP-серверов, мощные функции анализа информации и построения профессионально оформленных 77 отчетов, а также гибкие возможности детализации. 172 173 Она должна показывать все показатели, установленные для проведения ежедневного, еженедельного, ежемесячного или ежегодного наблюдения. Система должна иметь инструмент для контроля управления, который взаимодействует с моделью базы данных, что позволяет получать необходимую информацию для управления. Соответ ствует Соответ ствует Платформа бизнес-аналитики SAP позволяет осуществлять сбор, преобразование и хранение информации в любых аналитиках и с любой периодичностью. Платформа сочетает в себе возможности построения непредсказуемых (ad hoc) запросов к данным реляционных баз данных и OLAP-серверов, мощные функции анализа информации и построения профессионально оформленных отчетов, а также гибкие возможности детализации. Платформа предоставляет надёжную архитектуру, поддерживающую семантические уровни, интеграцию данных и безопасность. Стандартизированная панель запроса упрощает получение доступа ко всем типам данных, включая многомерные источники. Анализ данных выполняется посредством создания отчетов, основанных на анализируемых данных, или путем открытия существующих документов. В отчетах можно анализировать различными способами, например можно выполнять фильтрацию, переход по иерархиям вниз, чтобы ознакомиться с подробностями, объединять данные из различных источников данных, отображать данные в диаграммах или добавлять формулы. Данные поступают из юниверсов, в которых данные реляционных баз данных или баз данных OLAP упорядочиваются в форме объектов или иерархий, из поставщиков персональных данных, например из файлов Microsoft Excel и CSV, из запросов 78 BEx, основанных на кубах SAP Info Cubes, из веб-служб или рабочих областей Advanced Analysis. 174 175 176 Помимо отчетов, что уже включены в систему, должна быть возможность добавления новых отчетов, которые компания может рассмотреть в будущем для удобного использования без изменения системы. Система должна представлять отчеты через интернет руководству компании. Система должна быть в состоянии обеспечить механизмы отчетности: a) срабатывает автоматически по определенной периодичности; b) запускается автоматически по возникновению событий; c) запускается вручную. Соответ ствует Соответ ствует Соответ ствует Платформа бизнес-аналитики позволяет пользователям без изменения системы создавать новые аналитические отчеты на основе различных источников данных и публиковать их в репозитории компании либо сохранять локально. Стартовая панель BI запускается в веб-браузере и представляет собой основной интерфейс для работы с объектами на платформе SAP Business Objects Business Intelligence. Стартовая панель BI позволяет просматривать различные типы объетов (отчеты, интерактивные панели и прочее). SAP Business Objects Business Intelligence позволяет осуществлять выполнение отчета или актуализацию данных в отчетах по запросу пользователя (вручную) а также осуществлять планирование выполнения отчета с заданной периодичностью либо по событию. Система позволяет создавать различные типы событий. 79 5. ОРГАНИЗАЦИЯ ПРОЕКТА 5.1. Методология реализации проекта ООО «Сайнер» будет использовать методологию внедрения ASAP, разработанною компанией SAP AG специально для внедрения SAP-решений. Данная методология предполагает деление жизненного цикла проекта на пять фаз: подготовка проекта; разработка концептуального решения; реализация; итоговая подготовка; запуск и поддержка. Подробный подход к организации проекта и методологии реализации проекта представлен в документе «Предварительный план проекта», который является неотъемлемой частью данного предложения. 5.2. No . Инвентарная таблица системы, затраты на поставку и монтаж Компонент 1 План Проекта 2 АО и ПО Системы Соответствующие Технические Характеристики Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ Дополнительная Информация о Месте Количество ГО и РЭС-ы в Бишкеке 1 ГО и РЭС-ы в Бишкеке 1 Лицензии ПО Биллинговой Системы Пункт B - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ ГО и РЭС-ы в Бишкеке 2.1 Лицензии 3-й стороны (OS, DB, Office, LAN и т.д.) Пункт B - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ ГО и РЭС-ы в Бишкеке 2.2 1 1 80 No . Компонент Соответствующие Технические Характеристики Дополнительная Информация о Месте Количество Оборудование АО Пункт B - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 3 Обучение Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ Согласовывает ся с Заказчиком 4 Настройка ПО Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 1 4.1 Настройка ПО Биллинговой Системы Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 1 4.4 Настройка CMS - IRMS интерфейса Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 1 4.5 Настройка CMS - ERP интерфейса Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 1 2.3 5 5.1 5.2 5.3 6 7 Монтаж Установка CMS ГО и РЭС-ы в Бишкеке Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ ГО и РЭС-ы в Бишкеке Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ ГО и РЭС-ы в Бишкеке 1 1 Установка CMS - IRMS интерфейса Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 1 Установка CMS - ERP интерфейса Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 1 Преобразование Данных Пункт 2.5 - РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ 1 Администрирование Системы -- 1 81 5.3. Инвентарная таблица Системы, Периодические затраты No . Компонент Y1 Y2 Y3 Y4 ... Yn 1 Лицензии ПО& Обновления Вкл. в Гарантию Вкл. в Гарантию Вкл. в Гарантию опция опция опция 1.1 ПО Системы и Общего Назначения Вкл. в Гарантию Вкл. в Гарантию Вкл. в Гарантию опция опция опция 1.2 АО и ПО Приложений, Стандартное и Пользовательское Вкл. в Гарантию Вкл. в Гарантию Вкл. в Гарантию опция опция опция 2 Технические Услуги 2.1 Старший Системный Аналитик 80 дней 40 дней 20 дней 10 дней 0 0 2.2 Старший Программист 20 дней 40 дней 60 дней 40 дней 0 0 2.3 Старший Специалист Сети 0 20 дней 20 дней 0 0 0 2.4 Старший Специалист БД 20 дней 40 дней 20 дней 10 дней 0 0 3 Расширенные Гарантийные Услуги - - - HQ HQ HQ 4 Пост-гарантийные услуги - - - HQ HQ HQ 6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ Испытания Системы проводятся на территории Заказчика. Испытания проводятся при участии ООО «Сайнер» и Заказчика. Участники приемки работ, сроки и место проведения приемки работ уточняются непосредственно перед проведением испытаний. 6.1. Проведение предварительных испытаний Предварительные испытания выполняются после проведения ООО «Сайнер» отладки и тестирования Системы и предоставления Заказчику соответствующих документов о ее готовности к испытаниям. Предварительные испытания проводят в соответствии с программой, составляемой ООО «Сайнер» и согласовываемой с Заказчиком, в которой указывают: 1) Перечень требований, которым должны соответствовать объекты Системы (со ссылкой на пункты ТЗ); 2) Описание проверяемых взаимосвязей объектов Системы; 3) Очередность испытаний частей Системы; 82 4) Средства для проведения испытаний; 5) Условия, порядок и методы проведения испытаний и обработки результатов; Программа предварительных испытаний будет согласована с Заказчиком. Результаты предварительных тестирования Системы фиксируются в протоколах испытаний. Протокол испытаний будет содержать заключение о возможности (невозможности) приемки Системы в опытную эксплуатацию, а также перечень необходимых доработок и рекомендуемые сроки их выполнения. После устранения недостатков Заказчик и ООО «Сайнер» проводят повторные испытания в необходимом объеме. Фактом завершения проведения предварительных испытаний является согласование и утверждение Заказчиком протоколов проведения испытаний и Акта приемки в опытную эксплуатацию. 6.2. Требования к проведению опытной эксплуатации Опытную эксплуатацию проводят в соответствии с программой, в которой указывают: 1) условия и порядок функционирования подсистем Системы в целом; 2) продолжительность опытной эксплуатации, достаточную для проверки правильности функционирования Системы при выполнении каждой функции Системы и готовности персонала к работе в условиях функционирования Системы; 3) порядок устранения эксплуатации. недостатков, выявленных в процессе опытной Во время опытной эксплуатации Системы ведут рабочий журнал, в который заносят сведения о продолжительности функционирования Системы, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Сведения фиксируют в журнале с указанием даты и ответственного лица. В журнал могут быть занесены замечания персонала по удобству эксплуатации Системы. По результатам опытной эксплуатации принимают решение о возможности (или невозможности) предъявления подсистем Системы и Системы в целом на приемочные испытания. Работа завершается оформлением акта о завершении опытной эксплуатации и допуске Системы к приемочным испытаниям. 6.3. Требования к проведению приемочных испытаний (передача в постоянную эксплуатацию) Приемочные испытания проводят для определения соответствия Системы ТЗ, оценки качества опытной эксплуатации и решения вопроса о возможности приемки Системы в постоянную эксплуатацию. Приемочные испытания проводят в соответствии с программой, составляемой ООО «Сайнер» и согласовываемой с Заказчиком, в которой указывают: 1) Перечень требований, которым должны соответствовать объекты Системы (со ссылкой на пункты ТЗ); 83 2) Критерии приемки Системы; 3) Условия и сроки проведения испытаний; 4) Средства для проведения испытаний; 5) Методику испытаний и обработки их результатов; 6) Перечень оформляемой документации. Программа приемочных испытаний будет согласована с Заказчиком. Для проведения приемочных испытаний Заказчику будет предъявлена ООО «Сайнер» следующая документация: 1) Техническое задание на создание Системы; 2) Все акты и протоколы предварительных испытаний 3) Акт приемки в опытную эксплуатацию Системы; 4) Рабочие журналы опытной эксплуатации Системы; 5) Акт завершения опытной эксплуатации и допуска системы к приемочным испытаниям; 6) Программа приемочных испытаний Системы; 7) Все документы подлежащие разработке - проектная и эксплуатационная документация, инструкции, положения, регламенты. Приемочные испытания следует проводить на территории Заказчика. Приемочные испытания в первую очередь должны включать проверку: 1) Полноты и качества реализации функций при штатных, предельных, критических значениях параметров объекта автоматизации и в других условиях функционирования Системы, указанных в ТЗ; 2) Выполнения каждого требования ТЗ, относящегося к интерфейсу Системы; 3) Работы персонала в диалоговом режиме; 4) Средств и методов восстановления работоспособности Системы после отказов; 5) Комплектности и качества эксплуатационной документации. Результаты испытаний объектов, предусмотренных программой испытаний, фиксируются в протоколе, содержащем выводы о результатах испытаний и соответствии созданной Системы определенному разделу требований ТЗ. Фактом завершения проведения испытаний является согласование и утверждения Заказчиком Протокола приемочных испытаний и Акта о завершении приемочных испытаний. 7. ОБУЧЕНИЕ И ОБУЧАЮЩИЕ МАТЕРИАЛЫ В ходе реализации проекта ООО «Сайнер» предоставит: Определение целей и области обучения Определение учебных материалов Определение логистики для подготовки 84 Проектирование обучаемых Проектирование учебного плана: учебных мероприятий для преподавателей a) Названия курсов; b) Предпосылки курса; c) Продолжительность курса; d) Целевая аудитория каждого курса (роль/ответственность); e) Ориентация курса (функциональная или техническая); f) Необходимый набор навыков; и Будет разработано расписание занятий и концепция оценки обучения. Будет проведено обучение следующих категорий пользователей: Категория 1 - Опытные Пользователи (Сотрудники, которые часто используют систему для обработки транзакций); Категория 2 - Обычные Пользователи (Пользователи, которые имеют доступ в систему для просмотра отчетов или делают запросы на нерегулярной основе); и Категория 3 Специализированные (функциональные и технические аналитики). пользователи системы ООО «Сайнер» проведет подготовку ключевых и конечных пользователей Системы в количестве, согласованном с Заказчиком. Под ключевыми пользователями понимаются члены рабочей группы проекта, специалисты подразделений филиалов и исполнительного аппарата Заказчика. До этапа перехода в промышленную эксплуатацию, ключевые пользователи будут являться главным связующим звеном между командой ООО «Сайнер» и Заказчиком, а потом центром компетенции по использованию Системы на предприятии. Таким образом, для ключевых пользователей необходима подготовка по следующим темам: o знание общей концепции Системы; o базовые знания работы с Системой; o знание функциональных возможностей компонентов Системы; Конечные пользователи – это специалисты, выполняющие работы непосредственно с отдельными функциональными блоками Системы. К ним относятся работники тех подразделений Заказчика, для которых будет обеспечена автоматизация деятельности в Системе. Для конечных пользователей можно выделить следующие направления подготовки: o базовые знания работы с Системой; o соответствующие функциональные компоненты. Обучение ключевых пользователей будет проходить централизованно очно, не более 15 человек в специально оборудованном классе. Обучение конечных пользователей будет проходить централизованно очно, не более 20 человек в группе в специально оборудованном классе или в режиме видео- 85 конференции в соответствии с концепцией обучения согласованной с Заказчиком. В обучении принимают участие ключевые пользователи. 7.1. Инструкция пользователей Документ предназначен для описания всех выполняемых функций, задач, комплексов задач, процедур. В руководстве пользователя Системы обязательно должны быть описаны: 1) Назначение системы (информацию о назначении системы, ее целях и задачах); 2) Условия применения Системы (требования к аппаратному обеспечению, требования к квалификации пользователя); 3) Подготовка Системы к работе (пошаговая инструкция для запуска Системы); 4) Описание операций (пошаговая инструкция с подробно расписанными действиями пользователя, каждое действие пользователя должно сопровождаться снимком экрана (скриншотом), в котором должны быть выделены все значимые для пользователя элементы (экранные кнопки, рабочие области, различные интерфейсы) и указаны их функции и назначение); Для каждой операции обработки данных в инструкции пользователей описывают: o наименование операции; o условия, при операции; соблюдении которых возможно выполнение o подготовительные действия; o основные действия в требуемой последовательности; o описание структуры экранов и меню, включая изображения экранных форм; o описание используемых функциональных клавиш; o заключительные действия. 5) Аварийные ситуации (пошаговые инструкции действий пользователя в случае отказа работы Системы). 7.2. Руководство администратора Документ содержит следующие основные разделы: 1) введение; 2) инсталляция Системы; 3) требования к ресурсам для функционирования Системы; 4) аварийные ситуации и ошибки; 5) обслуживание баз данных; 6) архивирование и восстановление данных. В зависимости от особенностей Системы допускается объединять или исключать, а также вводить дополнительные разделы. 86 Составление информационной части (аннотация и содержание) является обязательным. В разделе «Введение» указывают назначение руководства и приводят требования к квалификации системного администратора, необходимой для обслуживания системы. В разделе «Инсталляция Системы» приводят четкие пошаговые инструкции по установке Системы и (или) её компонентов на отдельный компьютер или локальную сеть. В разделе «Требования к ресурсам для функционирования Системы» указывают минимальные требования к ресурсам компьютера (-ов) и, при необходимости, ЛВС для нормального функционирования Системы в соответствии с требованиями ТЗ (требования к оперативной памяти, жестким дискам, периферийным устройствам и т.п.). В разделе «Аварийные ситуации и ошибки» приводят список сообщений об ошибках и описание способов выхода из аварийных ситуаций. Сообщения об ошибках должны быть разделены на следующие категории: критические (при которых дальнейшая работа невозможна), некритические, сообщения среды программирования или операционной системы, сообщения программы ведения реестра. В разделе «Обслуживание баз данных» приводят инструкции по обслуживанию баз данных (верификация, перестройка ключей, архивация и восстановление после сбоев). В разделе «Архивирование и восстановление данных» приводят разделы баз данных, каталоги файловой системы и прочие места хранения информации, необходимой для архивирования, а также описание способов архивирования и восстановления данных. 8. ДОКУМЕНТАЦИЯ НА СИСТЕМУ Вся проектная, техническая, эксплуатационная и пользовательская документация по Системе будет выполнена на русском языке. В ходе выполнения работ по внедрению Системы ООО «Сайнер» разработает и согласует с Заказчиком следующие документы: 1) Техническое задание; 2) Концептуальный проект; 3) Концепция полномочий; 4) Программа и методика испытаний; 5) Протоколы испытаний; 6) Функционально-техническая спецификация разработок; 7) Описание настроек; 8) Инструкции пользователей; 9) Руководство администратора; 10) Акты о переводе Системы в опытную и промышленную эксплуатацию. Оригиналы документации оформляются и утверждаются по одному экземпляру для каждой из Сторон. Требования к передаваемой документации: 87 Документы передаются на бумажном носителе и в электронном виде (на компактном диске); Вся документация предоставляется в двух видах: o бумажном (для подписания); o электронном. Электронные документы выполняются в следующих форматах: o текстовые документы – в формате совместимом с Microsoft Word и/или PDF; o схемы и описания бизнес-процессов – в формате ARIS. 8.1. Уточненное техническое задание Данный документ регламентирует назначение, общие и специальные требования к функциональности создаваемой Системы. Уточненное техническое задание формируется на этапе «Подготовка проекта» по результатам обследования Бизнес-процессов Заказчика. В нем уточняются и конкретизируются функциональные требования к Системе описанные в закупочной документации, а так же формируется Альбом требуемых выходных форм и отчетов в качестве приложения к Уточненному техническому заданию. 8.2. Концептуальный проект Документ определяет способы и механизмы реализации функциональных требований в ПО SAP. На основании данного документа производятся определяется перечень необходимых разработок. настройки Системы, Данный документ предназначен для специалистов Заказчика, обладающих знаниями о принципах работы с ПО SAP. Так же специалисты должны обладать хорошими знаниями о бизнесе компании, бизнес – процессах, в которых они задействованы, а так же о смежных бизнес – процессах. Как правило, это эксперты в различных бизнес – областях, прошедшие программу подготовки по функциональности внедряемой Системы. 8.3. Концепция полномочий Документ определяет, какие роли будут созданы в Системе, каким образом будут распределены полномочия между ролями для выполнения всех бизнес – процессов в соответствии с требованиями к информационному решению. Также в документе определено соответствие созданных в Системе ролей и должностей сотрудников объекта автоматизации. Документ описывает полномочия с использованием терминологии бизнеспроцессов, без использования терминологии SAP и технических деталей реализации полномочий. На основании данного документа проводится вся дальнейшая работа по настройке ролей в Системе, а так же определяются сценарии обучения для каждой роли. Данный документ предназначен для специалистов Заказчика, обладающих знаниями о принципах работы с ПО SAP. Так же специалисты должны обладать хорошими знаниями о бизнесе компании, бизнес – процессах, в которых они 88 задействованы, а так же о смежных бизнес – процессах. Как правило, это эксперты в различных бизнес – областях, прошедшие программу подготовки по функциональности внедряемой Системы. Данный документ также предназначен для специалистов, компетенциями в области информационной безопасности. 8.4. обладающих Программа и методика испытаний Программа и методика испытаний (ПМИ) предназначена для установления технических данных, подлежащих проверке при испытании Системы, а также порядок испытаний и методы их контроля, устанавливает сроки начала и окончания испытаний, и ответственных за выполнение работ. ПМИ должна устанавливать необходимый и достаточный объем испытаний, обеспечивающий заданную достоверность получаемых результатов. ПМИ могут разрабатываться как на Систему в целом, так и на части Системы. ПМИ утверждается каждой из сторон, участвующей во внедрении Системы. 8.5. Требования к Программе предварительных испытаний Программа предварительных согласовывается с Заказчиком. испытаний составляется ООО «Сайнер» и Программа предварительных испытаний включают в себя следующие блоки: 1) Автономные испытания; 2) Комплексные испытания. Автономные испытания Системы следует проводить в соответствии с программой и методикой автономных испытаний, разрабатываемых для каждой части Системы. В программе автономных испытаний указывают: 1) перечень функции, подлежащих испытаниям; 2) описание взаимосвязей объекта испытаний с другими частями Системы; 3) условия, порядок результатов; и методы проведения испытаний и обработки 4) критерии приемки частей по результатам испытаний. Подготовленные и согласованные тесты (контрольные примеры) на этапе автономных испытаний должны обеспечить: 1) полную проверку функций и процедур по перечню, согласованному с заказчиком; 2) необходимую задании; точность вычислений, установленную в Техническом 3) проверку надежности и устойчивости функционирования программных и технических средств. Комплексные испытания Системы проводят путем выполнения комплексных тестов. Результаты испытаний отражают в протоколе. Работу завершают оформлением акта приемки в опытную эксплуатацию. В программе комплексных испытаний Системы указывают: 89 1) перечень объектов испытания; 2) состав предъявляемой документации; 3) описание проверяемых взаимосвязей между объектами испытаний; 4) очередность испытаний подсистем Системы. При комплексных испытаниях допускается использовать в качестве исходной информацию, полученную на автономных испытаниях частей Системы. Комплексный тест должен: 1) быть логически увязанным; 2) обеспечивать проверку выполнения функций подсистем Системы во всех режимах функционирования, установленных в Техническом задании, в том числе всех связей между ними; 3) обеспечивать проверку реакции системы на некорректную информацию и аварийные ситуации. Протокол комплексных испытаний должен содержать заключение о возможности (невозможности) приемки Системы в опытную эксплуатацию, а также перечень необходимых доработок и рекомендуемые сроки их выполнения. После устранения недостатков проводят повторные комплексные испытания в необходимом объеме. 8.6. Требования к Программе опытной эксплуатации Программа опытной эксплуатации составляется согласовывается с Заказчиком. В программе указывают: ООО «Сайнер» и 1) Условия и порядок функционирования частей Системы и Системы в целом; 2) Продолжительность опытной эксплуатации, достаточную для проверки правильности функционирования Системы при выполнении каждой функции Системы и готовности персонала к работе в условиях функционирования Системы; 3) Порядок устранения недостатков, выявленных в процессе опытной эксплуатации. 8.7. Требования к Программе приемочных испытаний Программа приемочных испытаний составляется согласовывается с Заказчиком. В программе указывают: ООО «Сайнер» и 1) Перечень объектов, выделенных в Системе, для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ); 2) Критерии приемки Системы и ее частей; 3) Условия и сроки проведения испытаний; 4) Средства для проведения испытаний; 5) Фамилии лиц, ответственных за проведение испытаний; 6) Методику испытаний и обработки их результатов; 90 7) Перечень оформляемой документации. 8.8. Протоколы испытаний Документ содержит: 1) Дату проведения испытаний; 2) Список состава комиссии; 3) Описание целей проведения испытаний; 4) Перечень материалов представленных комиссии; 5) Результаты проведения испытаний; 6) Замечания, если имеются; 7) ФИО сотрудника (-ов) проводящего конкретный этап испытаний; 8) Выводы по результатам проведения испытаний. 8.9. Функционально-техническая спецификация разработок Документ предназначен для описания информации по функциональному описанию выбранного объекта проектирования. Такими объектами являются: Отчёты, Интерфейсы, Формы, Расширения стандартной функциональности, Программы конвертации данных. В документе представлена информация, которая позволяет получить полную картину о технических параметрах разработок. В данном документе собирается информация, которая потребуется программисту для проектирования объекта. Типичная информация касается того, как будет работать объект с точки зрения функциональности, какой тип данных будет использоваться, источник, из которого будут поступать такие данные, и т.д. Документ предназначен для фиксации технических параметров разработок, входящих в объем информационной системы, в том числе для технического описания программ конвертации данных. Данный документ предназначен для Специалистов, обладающих глубокими знаниями функциональности системы, со знаниями основных принципов программирования, так же для Программистов и Технических специалистов, обладающих компетенциями для реализации разработок в системе. 8.10. Описание настроек Документ предназначен для описания настроек системы, с целью обеспечения преемственности реализованных проектных решений средствами конфигурации на базе стандартных возможностей ПО SAP. Настоящий документ определяет настройки ключевых структур данных, общих для всего информационного решения, настройки для реализации бизнес - сценариев и бизнес-процессов. Данный документ предназначен для специалистов, обладающих глубокими знаниями функциональности Системы и имеющих соответствующие компетенции для реализации настроек, описанных в данном документе. 91 8.11. Инструкция пользователей Документ предназначен для описания всех выполняемых функций, задач, комплексов задач, процедур. В руководстве пользователя Системы обязательно должны быть описаны: 1) Назначение системы (информацию о назначении системы, ее целях и задачах); 2) Условия применения Системы (требования к аппаратному обеспечению, требования к квалификации пользователя); 3) Подготовка Системы к работе (пошаговая инструкция для запуска Системы); 4) Описание операций (пошаговая инструкция с подробно расписанными действиями пользователя, каждое действие пользователя должно сопровождаться снимком экрана (скриншотом), в котором должны быть выделены все значимые для пользователя элементы (экранные кнопки, рабочие области, различные интерфейсы) и указаны их функции и назначение); Для каждой операции обработки данных в инструкции пользователей описывают: o наименование операции; o условия, при операции; соблюдении которых возможно выполнение o подготовительные действия; o основные действия в требуемой последовательности; o описание структуры экранов и меню, включая изображения экранных форм; o описание используемых функциональных клавиш; o заключительные действия. 5) Аварийные ситуации (пошаговые инструкции действий пользователя в случае отказа работы Системы). 8.12. Руководство администратора Документ содержит следующие основные разделы: 1) введение; 2) инсталляция Системы; 3) требования к ресурсам для функционирования Системы; 4) аварийные ситуации и ошибки; 5) обслуживание баз данных; 6) архивирование и восстановление данных. В зависимости от особенностей Системы допускается объединять или исключать, а также вводить дополнительные разделы. Составление информационной части (аннотация и содержание) является обязательным. 92 В разделе «Введение» указывают назначение руководства и приводят требования к квалификации системного администратора, необходимой для обслуживания системы. В разделе «Инсталляция Системы» приводят четкие пошаговые инструкции по установке Системы и (или) её компонентов на отдельный компьютер или локальную сеть. В разделе «Требования к ресурсам для функционирования Системы» указывают минимальные требования к ресурсам компьютера (-ов) и, при необходимости, ЛВС для нормального функционирования Системы в соответствии с требованиями ТЗ (требования к оперативной памяти, жестким дискам, периферийным устройствам и т.п.). В разделе «Аварийные ситуации и ошибки» приводят список сообщений об ошибках и описание способов выхода из аварийных ситуаций. Сообщения об ошибках должны быть разделены на следующие категории: критические (при которых дальнейшая работа невозможна), некритические, сообщения среды программирования или операционной системы, сообщения программы ведения реестра. В разделе «Обслуживание баз данных» приводят инструкции по обслуживанию баз данных (верификация, перестройка ключей, архивация и восстановление после сбоев). В разделе «Архивирование и восстановление данных» приводят разделы баз данных, каталоги файловой системы и прочие места хранения информации, необходимой для архивирования, а также описание способов архивирования и восстановления данных. 8.13. Способ кодирования проектной документации Проектные документы именуются по следующему шаблону: <Дата><NN>_<Имя документа>_<Версия >_.<расширение>, где: <Дата> - дата версии документа в формате YYYY ММ DD. <NN> - двухбуквенный тип документа; <Имя документа> - краткое описание документа на русском языке; <Версия> - номер версии в формате V #.#; <расширение> - системное расширение, определяющее тип файла. Все компоненты имени отделяются друг от друга символом «_». Номер версии документа устанавливается в соответствии со следующими правилами: 1) номер версии документа изменяется ответственным выпускающим; 2) старший разряд номера версии изменяется после каждого цикла согласования между Заказчиком и ООО «Сайнер»; 3) младший разряд номера версии изменяется при фиксации промежуточного варианта документа, согласованного в рамках проектной группы ООО «Сайнер». 93 9. ТЕХНИЧЕСКАЯ ПОДДЕРЖКА СИСТЕМЫ 9.1. Поддержка пользователей / горячая линия В ходе выполнения проекта ООО «Сайнер» предоставит поддержку пользователей на этапе опытной эксплуатации Системы в соответствии с требованиями конкурсной документации. Будет использован SAP Solution Manager для организации технической поддержки Биллинговой системы. 9.2. Гарантийная поддержка Гарантийный срок 36 месяцев и начинается после завершения внедрения Системы, что подтверждается Актом передачи системы в промышленную эксплуатацию. 10. ДОПУЩЕНИЯ И ОГРАНИЧЕНИЯ ПРОЕКТА При оказании услуг по проекту действуют следующие допущения и ограничения. В случае изменения или невыполнения настоящих предположений, ООО «Сайнер» оставляет за собой право пересмотреть бюджетные, организационные и функциональные рамки проекта. 10.1. Ограничения объема проекта 1. Функциональные и организационные требования, описанные в данном документе, покрывают весь объем проекта. Любые существенные изменения стратегии реализации проекта или бизнес-операций, включенных в проект создания системы, повлияют на объем проекта, план проекта, оценку затрат и ресурсов, специфицированных в настоящем предложении. 2. Изменения в ходе проекта организационной структуры Заказчика, бизнеспроцессов, влекущих изменение технического задания, концептуального проекта или проектных решений, планом проекта не предусматриваются и могут быть приняты к исполнению как дополнительные услуги по проекту в рамках дополнительного соглашения к Договору. 3. В рамках проекта могут быть детализированы или уточнены требования к создаваемой Системе, которые принимаются к разработке в случае согласования их обеими сторонами – Заказчиком и Исполнителем. Уточненные требования описываются и согласовываются в отдельном проектном решении. 4. Внедрение, осуществляемое Исполнителем, проводится в соответствии с возможностями выбранной технологии SAP и ее версии, выбираемой в начале проекта, и основывается на стандартной функциональности продуктов, с минимальными модификациями. Предпочтительным является реализация функциональности стандартными средствами настройками продукта SAP. 5. Работы по каждой последующей задаче проекта могут быть начаты только после исполнения всех работ по предыдущей задаче проекта. 6. Системное администрирование систем SAP на весь период проведения работ по проекту осуществляет Исполнитель, за исключением срока гарантийной поддержки. 7. Замечания Заказчика по работе определенного элемента функциональности должны быть непротиворечивыми и корректно сформулированными. Количество итераций по устранению замечаний Заказчика к одному и тому же 94 элементу функциональности, при условии устранения их Исполнителем не может превышать двух. 8. Согласование Заказчиком отчетных материалов и документов при завершении работ по каждому этапу происходит в сроки, не превышающие 3(трех) рабочих дней с момента подачи их на согласование. В процессе согласования определенного отчетного материала, замечания к его содержанию и оформлению оформляются Заказчиком и направляются Исполнителю в виде протокола замечаний. Цикл согласования отчетного материала не должен превышать двух итераций. 9. Реализация и тестирование Системы осуществляется на основании утвержденного и подписанных Концептуального проекта и Проектных решений. Все иные требования и изменения могут быть реализованы после завершения тестирования Системы в рамках Дополнительного соглашения. 10. Предполагается быстрое принятие решений Заказчиком (большинство вопросов должны быть обработаны в течение двух рабочих дней или в соответствии с дополнительно оговоренным сроком). 11. В случае задержки выполнения Заказчиком своей части работ, календарный план проекта смещается на период просрочки путем заключения дополнительного соглашения и не влечет штрафных санкций по отношению к Исполнителю. 12. Результаты работ Исполнителя по проектированию, разработке, тестированию и сопровождению системы согласовываются не более чем с тремя представителями Заказчика. 13. В случае возникновения внештатной ситуации, а именно неполноценной работы стандартной функциональности SAP, решение которой влечет за собой обращение в глобальную службу поддержки SAP, устранение данной внештатной ситуации находится в сфере компетенции Заказчика. Специалисты ООО «Сайнер» окажут возможную помощь специалистам Заказчика в формировании обращения в глобальную службу поддержки SAP. 14. Исполнитель не отвечает за качество и надежность функционирования аппаратного, системного и прочего программного обеспечения, используемого в составе реализуемой информационной системы или смежных с ней. 10.2. Процедурные ограничения 1. Руководство Заказчика обеспечивает выполнение обязательств относительно целей проекта, его объема и процедур управления проектом. 2. Заказчик устанавливает эффективную процедуру принятия решений, с целью избегания длительных дискуссий и «тупиковых ситуаций» в развитии проекта. Заказчик отвечает за назначение ответственных лиц со стороны Заказчика за согласование и утверждение проектных документов, а так же своевременное согласование документов, предоставляемых подрядчиком. 3. Организация проведения совещаний, организационных митингов рабочих групп Заказчика и Исполнителя в рамках реализации проекта, входит в зону ответственности Заказчика 95 4. Работы по каждому последующему этапу проекта могут быть начаты только после исполнения всех работ по предыдущему этапу проекта и принятия Заказчиком результатов выполнения работ Исполнителем. 10.3. Предоставление данных 1. За достоверность данных, предоставляемых реализации проекта, отвечает Заказчик. проектной команде при 2. Заказчик обязуется предоставлять в заранее согласованные сроки алгоритмы и методики, касающиеся реализуемых в системе бизнес–процессов. 10.4. Предоставление ресурсов 1. Руководитель проекта со стороны ИТ-команды Заказчика и руководитель проекта со стороны функционального Заказчика должны быть выделены Заказчиком своевременно и уполномочены принимать решения по проекту. 2. Каждый из специалистов команды со стороны Заказчика должен обладать необходимой компетенцией для решения задач проекта. В случае если сотрудник не является компетентным в вопросах проекта, руководство Заказчика предоставляет другого сотрудника. 3. Со стороны Заказчика осуществляется своевременное выделение квалифицированных и ответственных сотрудников для участия в проекте. 4. Заказчик должен обеспечить присутствие работников, входящих в состав проектных групп на проводимых Исполнителем семинарах и совещаниях в соответствии с согласованными планами; 5. Заказчик несет ответственность за выделение работников, необходимых для проведения интеграционного (приемочного) тестирования. 10.5. Ограничения и допущения по срокам проектных работ 1. Вне зависимости от фактической даты начала проектных работ, в процессе выполнения проекта, проектная команда ООО «Сайнер» предпримет все возможные меры для соблюдения плана работ в соответствии с указанным в настоящем документе сроками без ущерба для качества выполнения работ по проекту. 96