Повне найменування системи: Інформаційно-телекомунікаційна система “Інформаційно-аналітична звітність для органів влади, громадян та бізнесу”. Умовне позначення: ІТС “Звітність”, далі – Система. Дане Технічне Завдання стосується побудови третьої черги ІТС “Звітність”, що виражається в побудові нового модулю “Аналітичні показники діяльності державних адміністрацій”. Вимоги до побудови наступних черг визначаються додатково.

Договір № 4097 від 13.10.2017р.

Замовник: Комунальне підприємство “Головний інформаційно-обчислювальний центр” Місцезнаходження вул. Космічна, 12а, м. Київ, 02192 п/р 35446132091290 ГУ ДКСУ в м. Києві Код банку 820019 ЄДРПОУ 04013755 Свідоцтво пл. ПДВ №100093243 ІПН 040137526538 Розробник: Товариство з обмеженою відповідальністю “УКРАЇНСЬКІ БІЗНЕС КОМУНІКАЦІЇ” Місцезнаходження: 01033, м. Київ, вул. Жилянська, 47Д код ЄДРПОУ 38910488 р/р 26008052753904 в ПАТ “КБ ПриватБанк”, Печерська філія у м. Києві код банку 300711 свідоцтво пл. ПДВ № 200145237 ІПН 389104826537

Розробка виконуєть­ся згідно договору № 4097 від 13.10.2017р. Результат проведення закупівлі: код за ДК 021:2015: 72210000-0 Послуги з розробки пакетів програмного забезпечення (Створення інформаційно-телекомунікаційної системи “Інформаційно-аналітична звітність для органів влади, громади та бізнесу”, 3-я черга)

Початок робіт: 13.10.2017 р. Закінчення робіт: 25.12.2017 р.

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

ІТС “Звітність” є інструментом аналізу діяльності структурних підрозділів секретаріату Київської міської ради, виконавчого органу Київської міської ради (Київської міської державної адміністрації), районних в місті Києві державних адміністрацій, підприємств, установ та організацій, що належать до комунальної власності територіальної громади міста Києва (далі – Установи), що забезпечить оперативною, прозорою, достовірною інформацією в доступній формі всі зацікавлені сторони – як органи влади різних рівнів, так і громадян та представників бізнесу. ІТС “Звітність” призначена для консолідації інформації та процесів з розрізнених інформаційних систем підприємств, організацій, установ, що належать до комунальної власності територіальної громади міста Києва, а також господарських товариств, у яких є частка майна комунальної власності територіальної громади міста Києва в розмірі не менше як 30% в єдиній базі даних, що дозволить вдосконалити і поліпшити господарську діяльність. В рамках реалізації ІТС “Звітність” створюється програмно-технологічний комплекс (програмна платформа ІТС “Звітність”), яка функціонально збудована як єдине інформаційне середовище, в якому функціонально та інформаційно взаємодіють інформаційні системи та/або комплекси. ІТС “Звітність” будується почергово, за модульним принципом. Третя черга ІТС “Звітність” призначена для консолідації інформації та процесів з окремих інформаційних систем: Комунальна бюджетна установа «Контактний центр м. Києва 1551», Центральна диспетчерська м. Києва з питань ЖКГ 1557, Автоматична система обліку транспорту КП “Київпастранс” для представлення їх в наглядному вигляді для керівників районних адміністрацій міста та інших представників районних адміністрацій, що дозволить підвищити інформованість керівників району та покращити роботу відповідальних підрозділів, що в свою чергу призведе до більш якісного надання послуг населенню району. Кінцеве рішення третьої черги ІТС “Звітність” є інструментом моніторингу показників роботи підрозділів районних державних адміністрацій, керуючих компаній по обслуговуванню житлового фонду, що знаходяться в комунальній власності, організацій, що займаються тепло- та водопостачанням, підрядних організацій, які виконують роботи по обслуговуванню інфраструктури житлових будинків, а також структурних підрозділів КП “Київпастранс”, що безпосередньо займаються виконанням транспортної роботи (перевезенням пасажирів) та забезпечують виїзд транспортних одиниць на маршрути громадського транспорту.

В результаті виконання робіт із створення інформаційно-телекомунікаційної системи “Інформаційно-аналітична звітність для органів влади, громадян та бізнесу” буде впроваджено в експлуатацію третю чергу системи ІТС “Звітність” у вигляді підсистеми “Аналітичні показники діяльності державних районних адміністрацій”. Метою виконання робіт по розробці третьої черги ІТС “Звітність” є створення підсистеми інформаційно-аналітичної звітності для забезпечення автоматизації процесів збору та консолідації аналітичної інформації підрозділів, що працюють зі зверненнями громадян міста Києва, проведення аналізу надання комунальних та транспортних послуг населенню. Підсистема забезпечить державні районні адміністрації міста Києва актуальною інформацією для оперативного контролю, супроводження та підтримки прийняття управлінських рішень керівниками органів державного управління. Впровадження третьої черги ІТС “Звітність” дозволить якісно покращити контроль над сферою житлово-комунального господарства.

Роботи, що направлені на розробку третьої черги ІТС “Звітність”, передбачають розв’язання наступних задач:

• Здійснення оперативного контролю над ситуацією, відсутність системи моніторингу над поточною діяльністю виконавців звернень, а також відсутність інструментів контролю співробітників дозволяє зловживати становищем і не виконувати власних зобов’язань. У зв'язку з відсутністю контролю – поширюється безкарність персоналу, формується негативне ставлення мешканців до керівного складу керуючої компанії, районної адміністрації та місцевої влади цілому.
• Здійснення комплексної роботи з покращення ситуації за рахунок попередньої оцінки ризиків.
• Покращення керованості процесів обробки звернень, що надходять на виконання від диспетчерських служб та контактного центру м. Києва. Підвищення ефективності процесів за рахунок агрегації звернень від різних організацій.
• Здійснення планування робіт з урахуванням попередньої оцінки вірогідності подій.

В Підсистемі будуть реалізовані відповідні наведеним задачам бізнес-процеси. Підсистема, що створюється, будується за наступними принципами:

• застосуванні сучасних інформаційних технологій;
• застосуванні правила накопичення, зберігання та обробки інформації для формування довідників;
• забезпеченні надійного захисту інформації від порушення її цілісності, витоку та блокування згідно з порядком, встановленим нормативно-правовими державними актами і нормативними документами в галузі захисту інформації;
• забезпеченні резервування компонентів технічного забезпечення системи;
• використанні сучасних засобів програмної інженерії при розробці програмного прикладного забезпечення.

Створення Системи відбувається з урахуванням вимог наступних нормативно-правових документів: -       Закону України «Про інформацію»; -       Закону України «Про електронні документи та електронний документообіг»; -       Закону України «Про доступ до публічної інформації»; -       Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»; -       Закону України «Про електронний цифровий підпис»; -       Закону України «Про захист персональних даних»; -       Постанови Кабінету Міністрів України від 04.02.1998 № 121 «Про затвердження переліку обов’язкових етапів робіт під час проектування, впровадження та експлуатації систем і засобів інформатизації»; -       Постанови Кабінету Міністрів України від 12.04.2002 №522 «Про затвердження Порядку підключення до глобальних мереж передачі даних»; -       Постанови Кабінету Міністрів України від 10.09.2003 № 1433 «Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади»; -       Постанови Кабінету Міністрів України від 28.10.2004 № 1452 «Про затвердження Порядку застосування електронного цифрового підпису органами державної влади, органами місцевого самоврядування, підприємствами, установами та організаціями державної форми власності»; -       Постанови Кабінету Міністрів України від 29.03.2006 №373 «Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах»; -       Рішення Київської міської ради від 2 липня 2015 року № 654/1518 «Про затвердження Комплексної міської цільової програми «Електронна столиця» на 2015 - 2018 роки»; -       ДСТУ 2394 - 94 «Інформація та документація. Терміни та визначення»; -       НД ТЗІ 1.1-003-99. Термінологія в галузі захисту інформації у комп’ютерних системах від несанкціонованого доступу; -       НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі; -       НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації у комп’ютерних системах від несанкціонованого доступу; -       НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу; -       НД ТЗІ 3.6-001-2000. Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу; -       НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі; -       НД ТЗІ 3.7-003-05. Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі; -       ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення; -       ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення; -       ДСТУ 2873-94 Системи оброблення інформації. Програмування. Терміни та визначення; -       ДСТУ 2941-94 Системи оброблення інформації. Розроблення систем. Терміни та визначення; -       ДСТУ ISO/IEC 2382-4:2005 Інформаційні технології. Словник термінів. Частина 4. Організація даних; -       ДСТУ ISO/IEC 2382-17:2005 Інформаційні технології. Словник термінів. Частина 17. Бази даних; -       ДСТУ ISO/IEC 2382-9:2005 Інформаційні технології. Словник термінів. Частина 9: Обмін даними; -       ДСТУ 4302:2004 Інформаційні технології. Настанови щодо документування комп`ютерних програм (ISO/IEC 6592:2000, MOD); -       ДСТУ 4145:2002 Інформаційні технології. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих; -       ГОСТ 19.001-77. Єдина система програмної документації. Загальні положення; -       ГОСТ 19.101-77 (СТ СЗВ 1626-79). Єдина система програмної документації. Види програм і програмних документів; -       ГОСТ 19.102-77. Єдина система програмної документації. Стадії розробки; -       ГОСТ 19.103-77. Єдина система програмної документації. Позначення програм програмних документів; -       ГОСТ 19.104-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Основні написи; -       ГОСТ 19.105-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Загальні вимоги до текстових програмних документів; -       ГОСТ 19.201-78 (СТ СЗВ 1627-79). Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення; -       ГОСТ 19.202-78 (СТ СЗВ 2090-80). Єдина система програмної документації. Специфікація. Вимоги до змісту та оформлення; -       ГОСТ 19.301-79 (СТ СЗВ 3747-82). Єдина система програмної документації. Програма та методика випробувань. Вимоги до змісту та оформлення; -       ГОСТ 19.507-79 (СТ СЗВ 2091-80). Єдина система програмної документації. Відомість експлуатаційних документів; -       ГОСТ 19.701-90 (ИСО 5807-85). Єдина система програмної документації. Схеми алгоритмів, програм, даних та систем; -       ГОСТ 19781-90 Програмне забезпечення систем обробки інформації. Терміни та визначення; -       ГОСТ 34.003-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення; -       ГОСТ 34.201-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем; -       ГОСТ 34.601-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення; -       ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи; -       ГОСТ 34.603-92. Інформаційна технологія. Види випробувань автоматизованих систем; -       РД 50-34.698-90. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів; -       РД 50-682-89. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення. -       ДСТУ 3396.0-96 «Захист інформації»; -       ДК 010-98 «Державний класифікатор управлінської документації»; -       ДСТУ ISO/IEC 12207:2014 “Інженерія систем і програмного забезпечення. Процеси життєвого циклу програмного забезпечення”. Даний перелік не є вичерпним та може бути уточнений в процесі розробки Системи.

ІТС “Звітність” – це інтегрована предметно-орієнтована інформаційно-телекомунікаційна система, що будується на основі централізованої програмно-технологічної платформи з уніфікацією програмно-технічних засобів розробки прикладної функціональності з використанням сучасних сервісно-орієнтованих технологій. В рамках створення третьої черги Системи розроблятиметься модуль “Аналітичні показники діяльності державних районних адміністрацій” з метою відображення інформації в зручному вигляді на веб-порталі. Модуль буде включений в єдине інформаційне середовище (програмну платформу) ІТС “Звітність” із здійсненням інтеграції з загальною архітектурою Системи. Основною аудиторією користувачів третьої черги Системи є керівництво і фахівці структурних підрозділів державних районних адміністрацій м. Києва, а також керівники комунальних керуючих компаній міста, що будуть використовувати Систему для забезпечення підтримки прийняття управлінських рішень. При створенні третьої черги Системи використовуватимуться сучасні загальнопоширені засоби розробки програмних продуктів із дотриманням законодавства з питань правової охорони інтелектуальної власності, зокрема правомірного використання комп’ютерних програм. Система матиме вбудовані механізми захисту інформації від несанкціонованого доступу, механізми забезпечення ідентифікації та автентифікації користувачів, механізми збереження цілісності даних, реєстрації дій користувачів, управління доступом користувачів до інформації та окремих функцій. Програмно-технічні засоби, що розробляються, будуть підтримувати прийом-передачу даних за протоколом HTTPS. Фізичний сервер, на якому розміщуються програмні модулі Системи, повинен мати постійне підключення до Інтернету по протоколам TCP/IP. Система забезпечуватиме уніфікований для всіх видів автоматизованих робочих місць комфортний, максимально простий та інтуїтивно зрозумілий інтерфейс користувача. Система, що створюється, забезпечить інформаційно-аналітичною звітністю відповідних користувачів в повному обсязі. Рішення щодо побудови інформаційної системи базуються на: -       застосуванні сучасних інформаційних технологій; -       реалізації концепції створення єдиного інформаційного простору для головних напрямків фінансово-господарської діяльності в м. Києві; -       застосуванні правила централізованого накопичення, зберігання та обробки інформації; -       підтримці актуальності, повноти, несуперечності, цілісності та доступності інформації; -       забезпеченні надійного захисту інформації від порушення її цілісності, витоку та блокування згідно з порядком, встановленим нормативно-правовими державними актами і нормативними документами в галузі захисту інформації; -       забезпеченні надійності, резервування компонентів технічного забезпечення системи; -       забезпеченні централізованого управління, безперервного контролю функціонування та централізованого налаштування системи та її компонентів; -       забезпеченні можливості реалізації централізованого оновлення рішень за результатами модернізації/доопрацювання та налаштувань системи в автоматизованому режимі без перерв застосування системи та її компонентів за призначенням; -       використанні сучасних засобів програмної інженерії при розробці програмного прикладного забезпечення. В основу інформаційного забезпечення Системи буде покладений принцип однократного введення і єдиного місця збереження інформації та багаторазового її використання для рішення задач Системи.

Впровадження третьої черги ІТС “Звітність’ передбачає створення загальних компонентів системи (які включають у себе відповідні вітрини даних), що інтегровані з програмною платформою ІТС “Звітність”, та реалізації засобів інформаційної взаємодії з інформаційними системами, в яких відбувається первинне накопичення та актуалізація певного набору даних. Загальна схема архітектури інфраструктури Системи приведена на рис. 1.  
Рис. 1. Верхньорівнева загальна схема побудови архітектури Системи Третя черга створюється з урахуванням програмної платформи ІТС “Звітність”, та буде реалізовуватись на основі трирівневої сервісно-орієнтованої клієнт-серверної архітектури у складі наступних рівнів/слоїв: -     Сховище даних. Будуватиметься на основі використання сучасних реляційних систем керування базами даних, що передбачають шифрування даних. -     Рівень серверів застосувань. Буде складатись із наступних взаємопов’язаних компонентів:

• сервіси загальносистемних засобів та реалізації бізнес-логіки прикладної функціональності;
• сервіси інформаційної взаємодії з іншими компонентами та інформаційними системами.

-     Рівень представлення. Буде забезпечувати реалізацію прикладної функціональності клієнтських робочих місць із застосуванням сучасних веб-технологій. Рівень представлення не буде мати прямих зв’язків з базою даних (за вимогами безпеки), не буде навантаженим основною бізнес-логікою (за вимогами масштабованості) і буде зберігати стан програми (за вимогами надійності). На рівень представлення виноситься найпростіша бізнес-логіка: інтерфейс авторизації, алгоритми шифрування, перевірка значень, що вводяться, на допустимість і відповідність формату, нескладні операції (сортування, групування, підрахунок значень) з даними, вже завантаженими на термінал. Для реалізації клієнтської частини використовуватиметься SPA (Single-Page Applications: односторінкове веб-застосування) підхід побудови веб-застосувань. На рівні сховища даних буде використовуватись сучасна реляційна СКБД. Сховище даних складатиметься із наступних основних розділів: -     дані каталогу облікових об’єктів, прикладні атрибутивні та інші дані; -     службові дані (нормативно-довідникові дані та класифікатори, користувачі системи, журнали аудиту, тощо). Компоненти серверу застосувань реалізації бізнес-логіки прикладної функціональності призначені для створення серверних служб доступу до об’єктів та бізнес-логіки прикладної функціональності у відповідності до функціональних задач. Компоненти серверу застосувань сервісів загальносистемних засобів призначені для створення серверних служб реалізації загальносистемних функцій засобів ідентифікації та автентифікації користувачів, перевірки прав доступу, аудиту дій, уніфікованих механізмів формування функціональності клієнтських робочих місць тощо. Модуль третьої черги буде функціонувати інтегровано з програмною платформою ІТС “Звітність” з використанням єдиного сховища даних для користувачів Системи, при цьому для кожного користувача встановлюється свій рівень доступу до інформації. Централізація інформаційних ресурсів досягається шляхом реалізації засобів інформаційної взаємодії з програмною платформою ІТС “Звітність”, в якій відбувається централізована обробка певного набору даних. Застосовані рішення з побудови Системи та її Модулів забезпечуватимуть можливості: -         автоматизованої адаптації системи при зміні вимог до аналітики; -         інтеграції модуля системи у програмну платформу ІТС “Звітність”; -         інтеграції систем, що розробляються, з іншими інформаційними системами та програмними продуктами. Склад програмних засобів, які будуть використовуватися при побудові сховища даних, відповідає наявному складу, який використовувався при розробці першої та другої черг ІТС “Звітність”:

• Microsoft Windows Server 2012 R2;
• Microsoft SQL Server 2014 Standard Edition with Data Tools Business Intelligence для служб Analysis Services, Integration Services и Reporting Services;
• Oracle Express 12g.

Схема розміщення компонентів на серверному обладнанні приведена в розділі 6.3. До складу системи, що розробляється, включаються наступні технологічні компоненти:

• HTTP-сервер, зворотний проксі-сервер та TCP проксі-сервер загального призначення з підтримкою SSL Termination – Nginx для балансування навантаження на Систему.
• ETL-додаток – це комплексне рішення SQL Server Integration Services, за допомогою якого реалізуються процеси вилучення, перевірки, перетворення і завантаження даних з джерел.
• Сервер БД являє собою промислову систему управління базами даних. На даному сервері зберігаються НДІ, область тимчасового і постійного зберігання даних, агрегати даних. Реалізована система розмежувань прав доступу на рівні об'єктів і записів в таблицях. Як сервер БД буде використовуватися Microsoft SQL Server 2012 та Oracle Express Edition 12g;
• Сервер застосувань – продукт, що забезпечує підтримку промислової інфраструктури бізнес-застосувань. Включає в себе наступний ряд додатків забезпечують:
  • Стандартні підходи до організації служб каталогів, централізовані методи організації;
    • Розгортання сервісів розробки додаткових застосувань;
    • Розгортання сервісів аналізу і звітності.
    • Засоби адміністрування і розробки – Microsoft Management Studio, призначений для адміністрування системи ETL, баз даних, сервера застосувань (Microsoft Internet Information Services Manager) і розробки звітності (Microsoft Analysis and Reporting Services).
    • Клієнтські місця користувачів, що представляють собою автоматизовані робочі місця у вигляді веб-інтерфейсу в межах тонкого клієнту (Інтернет-оглядачі останніх та передостанніх версій Edge, Internet Explorer, Google Chrome, Mozilla Firefox або Safari).

Ліцензії на програмне забезпечення надаються Замовником разом з технічним майданчиком для розгортання системи.
Трирівнева архітектура будується з 3-х частин:

Клієнт – це інтерфейсний (зазвичай графічний) компонент, який представляє перший рівень, власне застосунок для кінцевого користувача. Перший рівень не має прямого зв’язку із базою даних (за вимогами безпеки), не є навантаженим основною бізнес-логікою (за вимогами масштабованості) і зберігає стан програми (за вимогами надійності). На перший рівень виноситься найпростіша бізнес-логіка: інтерфейс авторизації, алгоритми шифрування, перевірка значень, що вводяться, на допустимість і відповідність формату, нескладні операції (сортування, групування, підрахунок значень) із даними, що вже завантажені на термінал. Для реалізації клієнтської частини використовуватиметься SPA підхід побудови веб-застосунків, а для реалізації SPA – бібліотека Angular 2.

• Сервер застосунків – розташовується на другому рівні. Складається із наступних взаємопов’язаних компонентів: сервіси загальносистемних засобів та реалізації бізнес-логіки прикладної функціональності та сервіси інформаційної взаємодії з іншими компонентами та інформаційними системами. На другому рівні зосереджена більша частина бізнес-логіки. Поза ним залишаються фрагменти, що експортуються на термінали, а також розміщені в третьому рівні збережені процедури і тригери. Компоненти серверу застосунків сервісів загальносистемних засобів призначені для створення серверних служб реалізації загальносистемних функцій засобів ідентифікації та автентифікації користувачів, перевірки прав доступу, аудиту дій, уніфікованих механізмів формування функціональності клієнтських робочих місць тощо.

Сервер застосунків представляє ASP.NET WebApi додаток, побудований на базі .Net Framework 4.6.1 або вище. Це набір сервісів (веб-методів), які віддають інформацію в JSON вигляді на клієнт і забезпечують автентифікацію і авторизацію користувачів. Сервер передбачає наявність адміністративної частини для ручного введення і редагування записів та адміністрування користувачів системи. Для обмеження доступу до сайту по IP реалізується відповідний модуль. Списком дозволених IP – адресів можна буде управляти через панель адміністрування.

• Сервер бази даних забезпечує зберігання даних і виноситься на третій рівень. Таким чином, третій рівень являє собою базу даних разом із збереженими процедурами, тригерами і схемою, яка описує застосунок в термінах реляційної моделі. Сервер БД являє собою промислову систему управління базами даних - Microsoft SQL Server 2012 з технологіями FailoverClustering та AlwaysOnAvailabilityGroups. AlwaysOn - це рішення високої доступності та аварійного відновлення, що є альтернативою дзеркальному відображенню баз даних на рівні підприємства. Технологія AlwaysOn дозволяє максимально збільшити доступність користувацьких баз даних. Група доступності підтримує набір первинних баз даних читання і запису і від одного до чотирьох наборів відповідних вторинних баз даних. Крім того, бази даних-одержувачі можна зробити доступними тільки для читання або для деяких операцій резервного копіювання.

Застосовані рішення з побудови інформаційної системи забезпечуватимуть можливості:

• адаптації системи при зміні вимог до аналітики (додаткових розрізів, кількості елементів у кожному розрізі, деталізація або агрегація періодів аналізу);
• поетапного нарощування як продуктивності, так і функціонального складу системи;
• інтеграції системи, що розробляється, з іншими інформаційними системами та програмними продуктами.

В рамках реалізації ІТС “Звітність” створюється програмно-технологічний комплекс (програмна платформа ІТС “Звітність”), яка функціонально збудована як єдине інформаційне середовище, в якому функціонально та інформаційно взаємодіють інформаційні системи та/або комплекси. ІТС “Звітність” будується почергово, за модульним принципом. Третя черга ІТС “Звітність” розширює можливості Системи та призначена для консолідації інформації та процесів з розрізнених інформаційних систем: Комунальна бюджетна установа “Контактний центр м. Києва 1551”, Центральна диспетчерська м. Києва з питань ЖКГ 1557, Автоматична система обліку транспорту КП “Київпастранс” – для представлення їх в наглядному вигляді для керівників районних адміністрацій міста та інших представників районних адміністрацій. Кінцеве рішення третьої черги ІТС “Звітність” є інструментом моніторингу показників роботи підрозділів районних державних адміністрацій, керуючих компаній по обслуговуванню житлового фонду, що знаходяться в комунальній власності, організацій, що займаються тепло- та водопостачанням, підрядних організацій, які виконують роботи по обслуговуванню інфраструктури житлових будинків, а також структурних підрозділів КП “Київпастранс”, що безпосередньо займаються виконанням транспортної роботи (перевезенням пасажирів) та забезпечують виїзд транспортних одиниць на маршрути громадського транспорту. Загальна схема розширення Системи в рамках третьої черги представлена на рисунку 2. В рамках третьої черги з’являються нові джерела даних, для яких будуть сформовані та налаштовані нові: - модулі прийому та обробки даних; - модулі підготовки звітів; - модулі обробки звітів; - програмні інтерфейси для внесення даних та відображення даних.  
Рис. 3. Загальна схема розширення Системи в рамках третьої черги

            Система будується за модульним принципом. При реалізації кожного модулю Система розширює набір даних, якими вона оперує. Додаються нові блоки даних, якими оперує Система (див. Рис. 3).             При реалізації третьої черги системи додаються блоки даних по зверненнях мешканцях, що приймаються та оброблюються в міських контактних центрах 1551 та центральній диспетчерській міста 1557. Відслідковуються результати районів в загальноміських рейтингах, що укладаються даними службами. А також збирається та накопичується інформація про випуск транспорту на маршрути КП “Київпастранс”. В рамках реалізації третьої черги системи відбувається розробка наступних блоків даних:

• Робота зі зверненнями до Комунальної бюджетної установи “Контактний центр м. Києва 1551”;
• Рейтинги районів за даними Комунальної бюджетної установи “Контактний центр м. Києва 1551”
• Робота з заявками Центральної диспетчерської служби м. Києва з питань ЖКГ 1557;
• Рейтинги ЖЕДів за районами м. Києва;
• Рейтинг роботи ліфтового обладнання по місту та по районах;
• Стан подачі комунальних послуг в будинки з відображенням на інтерактивній карті;
• Актуальний стан роботи ліфтового обладнання з відображенням на інтерактивній карті;
• Інформація відносно запуску опалювального сезону;
• Контроль виїзду транспорту на маршрути КП “Київпастранс”.

Схема розширення підсистеми збереження даних приведена на Рис. 4.   Рис. 4.  Розширення підсистеми збереження даних

При розширенні Системи додаються нові вітрини даних, що розширюють функціональний склад Системи при реалізації третьої черги системи (див. Рис. 5). Рис. 5. Загальна схема розширення підсистеми Вітрин даних

Система збору та обробки статистичної звітності з інформаційних систем КБУ “Контактний центр м. Києва 1551”, Центральної диспетчерської служби з питань ЖКГ м. Києва 1557 КП “Київжитлоспецексплуатація”, Автоматизованої системи обліку транспортної роботи КП “Київпастранс” призначена для збирання статистичних даних з вищевказаних систем до єдиної бази даних. Система розробляється для виконання наступних функцій: збір, обробка, зберігання, передача даних, формування поточної статистичної звітності. Система вирішуватиме наступні задачі:

• Імпортування статистичних даних з систем КБУ “Контактний центр м. Києва 1551”, Центральної диспетчерської служби з питань ЖКГ м. Києва 1557 КП “Київжитлоспецексплуатація» та Автоматизованої системи обліку транспортної роботи КП «Київпастранс» шляхом відправлення запитів до баз даних вказаних систем, а також використання уніфікованих API (Aapplication Pprogramming iInterface) та мови розмітки XML (Extensible Markup Language) з одночасним забезпеченням цілісності та достовірності даних, що надходять з цих систем.
• Контролювання надходження поточної статистичної звітності. Задача включає формування звітності щодо контролю надходження даних з інформаційних систем, а також функціональні можливості, які дозволяють вчасно інформувати про ці надходження користувачів (нагадування).
• Формування звітності за поточними статистичними даними, які надійшли від інформаційних систем.

Модуль, що розробляється, задовольнятиме наступним вимогам:

• забезпечує формування інформаційно-аналітичної звітність звітності за допомогою   інтуїтивно зрозумілого користувачеві інтерфейсу;
• підтримує протокол доступу SOAP (Simple Object Access Protocol) за допомогою технології Web Services;
• забезпечує збереження отриманих даних в оперативній пам’яті, а також їх обробку в штатному режимі, що допомагає прискорити доступ до них;
• підтримує роботу з базами даних, заснованих на реляційній моделі даних; 
• підтримує роботу з  багатопроцесорною архітектурою баз даних;
• реалізує SQL (Structured Query Language), який є сумісним зі стандартом ANSI 1992;
• підтримує стандарт Open DataBase Connectivity для баз даних;
• підтримує роботу з базами даних, що мають вбудовані засобами контролю цілісності отриманих даних;
• підтримує роботу з базами даних, що мають вбудовані засобі резервного копіювання отриманих даних;
• забезпечує ефективне функціонування з транзакційними та з аналітичними додатками одночасно;
• будується виключно на основі високопродуктивної системи управління базами даних,  яка має високий рівень масштабування для ефективної одночасної роботи великої кількості користувачів з великими об’ємами даних;
• забезпечує захист отриманих даних у процесі їх збереження, а також в процесі передачі інформації;
• підтримує роботу з базою даних, що має вбудовані можливості дворівневого збереження даних та їх розділенням  на «гарячі» та «холодні» дані в оперативній пам’яті та на дисковому просторі відповідно;
• надає інтегровані дані, які використовуються для крос-функціонального аналізу;
• виключає наявність надлишкових або несумісних даних, а також помилок;
• забезпечує швидкий та ефективний доступ до достовірних даних;
• забезпечує надійний та якісний інструмент, за допомогою якого інтегруються корпоративні;
• забезпечує можливість масштабованості;
• відповідає найвищим вимогам до продуктивності.

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

Вимоги із забезпечення захисту інформації реалізуватимуться за рахунок створення комплексу засобів захисту, який складається із програмних засобів криптографічного захисту інформації, засобів підсистеми «Адміністрування» та засобів захисту операційних систем. У складі комплексу засобів захисту будуть застосовані програмні засоби криптографічного захисту інформації, які мають діючий позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України. У Системі буде реалізований захищений доступ до системи на рівні логінів/паролів підключення до Системи, які шифруватимуться за алгоритмом хешування MD5. Також буде шифруватися доступ до ядра системи та всіх окремих елементів (локальні мережі контакт-центрів, автоматизоване робоче місце (АРМ), підключені мережеві пристрої, пристрої модуляції сигналів тощо). Зв’язок між елементами системи будуватиметься на технології шифрованих тунелів, які разом об’єднуються у загальну внутрішню мережу. Для забезпечення конфіденційності та цілісності даних, що передаються між сервером програмних застосувань та АРМ користувачів, а також двохфакторної автентифікації користувачів АРМ, буде використовуватися програмний засіб криптографічного захисту інформації, який відповідає наступним загальним вимогам:

• Має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації України.
• Функціонує як невід’ємна частина Системи з визначеним переліком функцій.
• Має можливість бути використаним у складі будь-якої інформаційної системи (автоматизованої системи), яка реалізована у якості портального рішення.
• Реалізує наступні механізми:
  • контроль цілісності програмного забезпечення;
  • тестування на правильність функціонування та блокування роботи в разі виявлення порушень;
  • захист від порушення конфіденційності інформації внаслідок помилкових дій користувача або в разі некоректної роботи складових елементів;
  • захист ключових даних на їх носіях від несанкціонованого зчитування;
  • захист засобу від здійснення порушником навмисного зовнішнього впливу;
  • захист від порушення конфіденційності та цілісності ключових даних в ключових документах.
  • Реалізує алгоритм шифрування даних відповідно до ДСТУ ГОСТ 28147:2009 у режимі гамування із зворотнім зв’язком;
  • Реалізує наступні формати, структури, протоколи, алгоритми:
    • позначки часу відповідно до вимог RFC 3161 «Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)» та вимог до протоколу фіксування часу, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1402/21714;
    • інтерактивного визначення статусу сертифіката відповідно до вимог RFC 2560 «Internet X.509 Public Key Infrastructure Online Certificate Status Protocol – OCSP» та вимог до протоколу визначення статусу сертифіката, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1403/21715;
    • списку відкликаних сертифікатів відповідно до вимог RFC 5280 «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» та вимог до формату списку відкликаних сертифікатів, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1400/21712;
    • об’єктні ідентифікатори для криптоалгоритмів, що є державними стандартами відповідно до вимог до структури об’єктних ідентифікаторів для криптоалгоритмів, що є державними стандартами, затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 № 1399/21711;
    • запиту на формування сертифіката відкритого ключа, що створюються та обробляються об’єктом експертизи, відповідають вимогам (PKCS#10) Certification Request Syntax Specification;
    • посиленого сертифіката відкритого ключа, що відповідає вимогам до формату посиленого сертифіката відкритого ключа, що затверджені наказом Мін’юсту та Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1398/21710.

Для забезпечення конфіденційності та цілісності даних при введенні даних з клієнтських АРМ, захищеного збереження інформації про дії користувачів та адміністраторів системи, буде застосований програмний засіб криптографічного захисту інформації, що відповідає наступним загальним вимогам:

• Має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації Україні;
• Призначений для забезпечення конфіденційності та цілісності інформації шляхом здійснення її криптографічного перетворення (виконання функцій шифрування та дешифрування) та здійснює розмежування доступу до такої інформації, що зберігається на носіях інформації (жорсткий диск комп’ютера, переносний жорсткий диск, флеш-накопичувач) відповідно до ключових даних та сертифікатів відкритих ключів та забезпечує:
  • створення та використання шифрованих файлових контейнерів (шифрованих віртуальних дисків);
  • створення шифрованих контейнерів без файлової системи або з файловою системою NTFS чи FAT;
  • можливість створення динамічних шифрованих файлових контейнерів;
  • створення шифрованого носія на основі переносного жорсткого диску, флеш-накопичувача;
  • можливість шифрування логічних дисків (томів) жорсткого диску комп’ютера, переносного жорсткого диску, флеш-накопичувача;
  • Реалізований у вигляді набору програмних модулів, готових до використання, та мати можливість бути використаним у якості її окремої та незалежної частини (складової) з визначеним переліком функцій;
  • Реалізує алгоритм шифрування даних відповідно до ДСТУ 28147:2009 у режимі гамування із зворотнім зв’язком;
  • Реалізація криптографічних алгоритмів буде здійснюватися бібліотекою функцій криптографічних перетворень, що має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації.

Для забезпечення захисту інформації, що передається між основним та резервним центром обробки даних, що розміщуються на територіально-рознесених майданчиках, буде застосовуватися програмний засіб криптографічного захисту інформації, що відповідає наступним вимогам:

• Має дійсний експертний висновок Державної служби спеціального зв'язку та захисту інформації України щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації;
• Реалізує наступні функції:
  • захист трафіку на рівні автентифікації/шифрування мережевих пакетів по протоколах IPsec AH та/або IPsec ESP;
  • пакетну фільтрацію трафіку з використанням інформації в полях заголовків мережевого і транспортного рівнів;
  • контекстну фільтрацію для протоколів TCP і FTP;
  • класифікацію та маркування трафіку;
  • реалізацію заданого протоколу взаємодії (автентифікацію та/або захист трафіку) для кожного захищеного з'єднання, доступ в заданому захищеному режимі тільки для зареєстрованих партнерів по взаємодії;
  • регульовану стійкість захисту трафіку;
  • підтримку NAT Traversal Encapsulation;
  • маскування топології сегмента мережі, що захищається (тунелювання трафіку);
  • підтримку списку відкликаних сертифікатів (CRL – Certificate Revocation List);
  • реєстрацію подій;
  • надання статистики із використанням протоколів SNMP v.1, v.2c;
  • дистанційне та локальне налаштування (за допомогою командної строки або із використанням графічного інтерфейсу);
  • підтримку сервісів QoS.
  • Використовує алгоритм шифрування ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотнім зв’язком;
  • Забезпечує пропускну здатність у режимі шифрування для пакетів UDP та ТСР – не менш 1600 Мбіт/сек.

Захист компонентів від несанкціонованого доступу буде виконуватися за рахунок реалізації таких заходів: -         Сеанс клієнт-сервер, під час роботи з проектом через Інтернет, виконується тільки по https протоколу (захист за допомогою SSL сертифікату); -         Для розгортання компонентів проекту, а також для доступу користувачів до серверів застосовується SSH протокол з використанням логіну та паролю доступу та RDP протокол з використанням логіну та паролю; -         SSH протокол працює по нестандартному порту (port:2002); -         RDP протокол працює по нестандартному порту (port:2003); -         Всі процеси запускаються від імені непривілейованих користувачів; -         Доступ до баз даних виконується за допомогою спеціалізованих облікових записів та паролів, які відповідають єдиним заданим політикам безпеки (строк дії пароля, кількість літер, чисел та символів). Для забезпечення обчислення значення електронного цифрового підпису від даних, що записуються до бази даних ІТС “Звітність” третьої черги, конфіденційності та цілісності даних, що передаються між сервером застосувань та АРМ користувачів з правами адміністратора, двохфакторної автентифікації таких користувачів АРМ буде застосовуватися програмний засіб криптографічного захисту інформації, який вже використовує Система, а саме:

• для забезпечення конфіденційності та цілісності даних, що передаються між сервером застосувань та АРМ користувачів, буде застосовуватися програмний засіб криптографічного захисту інформації – “Крипто Автограф” (експертний висновок №05-02-02/819 від 29.02.2016 р.);
• для забезпечення конфіденційності та цілісності даних при введенні даних з клієнтських АРМ, а також захищеного збереження інформації про дії користувачів та адміністраторів системи “Криптософт Storage” (експертний висновок №05-02-02/2246 від 23.06.2014 р.).

Розробка та впровадження комплексної системи захисту інформації не є предметом даного договору, її може бути реалізовано в подальшому в рамках окремих робіт.

При проектування системи ІТС “Звітність” були реалізовані базові заходи безпеки інформації. При реалізації третьої черги використовуються вже започатковані заходи безпеки, а саме:

• організаційно-адміністративні;
• апаратно-програмні;
• інженерно-технічні.

Вимоги щодо КСЗІ визначатимуться в окремому Технічному завданні, яке буде розроблятись Виконавцем, якого буде визначено за результатами проведення окремої конкурсної процедури. Для забезпечення обчислення значення електронного цифрового підпису, що використовується в системі, конфіденційності та цілісності даних, що передаються через АPI слід передбачити можливість застосувати програмний засіб криптографічного захисту інформації, що має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації України. Для забезпечення безпеки передачі даних між робочим місцем Чиновника та серверним програмним комплексом у ІТС “Звітність” слід передбачити можливість використання програмних засобів криптографічних перетворень, який має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України.

Система буде підтримувати наступні режими функціонування:

• Основний режим. Передбачає штатне безперервне функціонування всіх компонентів за їх призначенням. При цьому для серверних програмно-технічних засоби та частини програмного забезпечення обслуговування клієнтів передбачено цілодобове функціонування. Періоди регламентного обслуговування Системи визначаються заздалегідь. 
• Режим адміністрування. Даний режим передбачає здійснення налагоджування та оновлення компонентів системи в автоматичному централізованому режимі. При цьому підтримується одночасна робота користувачів Системі в основному режимі, або в режимі Регламентного технічного обслуговування.
• Режим регламентного обслуговування. Даний режим передбачає проведення заздалегідь визначених періодів регламентного технічного обслуговування для профілактики або відновлення працездатності компонентів Системи.

Функціонування вищевказаних режимів буде підтримуватись одночасно.

В Системі буде передбачено наявність програмних засобів для діагностики, а також розроблено вбудовані механізми документування аварійних подій або помилок. При цьому помилка або аварійна подія, що виникла, реєструватиметься у відповідному електронному журналі з одночасним інформуванням про подію користувача та/або адміністратора Системи за допомогою відповідного повідомлення. Для адміністраторів Системи буде передбачена можливість отримання технічної довідкової інформації-допомоги з різним рівнем деталізації щодо ліквідації аварійних подій або виправлення помилки. Повідомлення про аварійні події або помилки буде містити: - час виникнення тої або іншої аварійної події або помилки; - назву компонента Системи, в якому виникла аварійна подія або помилка; - назву файлу вихідних текстів; - номер рядка в файлі; - причину аварійної події або помилки.  Додатково таке повідомлення може містити назву функції, яка викликала аварійну подію або помилку, а також перелік викликів.

Розвиток та модернізація Системи передбачає поступову інтеграцію інформаційних систем міста, які наразі існують відокремлено одна від одної, у єдину програмно-технічну платформу. Така інтеграція буде здійснюватися відповідно меті та призначення створення даної Системи. Система передбачає відкритість до модернізації її компонентів, при цьому її безперервне функціонування за призначенням буде забезпечуватись в повній мірі. Додатково буде забезпечено можливість розширення функціонального складу Системи відповідно зростаючим потребам та можливостям сучасного технічного обладнання.

Виконавець в ході розробки Системи робіт сформулює пропозицію рішення щодо чисельності та кваліфікації персоналу для обслуговування Системи. Таке рішення передбачає:

• Безперервне забезпечення технічного супроводження Системи в процесі її експлуатації на всіх стадіях життєвого циклу;
• Забезпечення цілодобового безперервного режиму роботи Системи та її компонентів за призначенням та в повному обсязі;
• Організацію та впровадження централізованого контролю працездатності Системи;
• Забезпечення швидкого реагування на виникнення аварійних ситуацій або помилок, а також оперативного усунення відмов роботи Системи або її компонентів;
• Організацію та впровадження адміністрування Системи, яке передбачає оперативне налагодження роботи Системи під час експлуатації;
• Своєчасне оновлення програмного забезпечення в централізованому режимі. 

Рішення щодо чисельності та кваліфікації персоналу Системи, запропоновані Виконавцем під час розробки Системи, обґрунтовуються необхідними вимогами до її обслуговуваннями та мінімізуються за витратами при їх впровадженні. При цьому чисельність задіяного для обслуговування Системи персоналу ніколи не перевищує наявну чисельність персоналу, який задіяний у поточних автоматизованих процесах. Технічне обслуговування Системи передбачає роботу персоналу на договірних умовах аутсорсингу. Рішення щодо вибору типу експлуатації на умовах аутсорсингу або штатною чисельністю персоналу економічно обґрунтовується та забезпечує мінімальні витрати ресурсів під час експлуатації Системи. Технічна підтримка програмного забезпечення Системи може здійснюватися спеціалізованими організаціями, підприємствами чи установами на основі окремих договорів.

Система забезпечуватиме:

• Можливість зберігання історичних даних протягом не менш ніж 5 років;
• Обслуговування одночасної роботи до 1000 користувачів;
• Швидкість базових операцій роботи з довідниками, картками та базами даних 3-5 секунд;
• Швидкість формування регламентованих звітних форм – до 20 секунд.

Надійність системи буде забезпечена за наступними напрямками:

• Забезпечення працездатності компонентів програмно-технічної платформи;
• Збереження даних.

При відмові одного або декількох компонентів Системи, збереження її працездатності буде забезпечуватися за рахунок автоматичного резервування (збереження) даних. При цьому з боку адміністратора вимагається мінімальна увага щодо реакції на усунення наслідків відмов компонентів. Збереження даних у системі буде забезпечене програмно-апаратними засобами. Резервування даних буде забезпечувати збереження цілісності даних при програмно-апаратних збоях, відмовах, помилках тощо. Резервування даних буде реалізовано шляхом використання відповідних програмно-апаратних засобів та рішень, резервного копіювання, транзакційності при змінах даних. Резервування даних забезпечуватиметься у наступних випадках:

• Перебої в подачі або вимкнення живлення технічних засобів;
• Аварійні ситуації, відмови технічних засобів обробки даних;
• Помилки програмного забезпечення, програмні збої або руйнування Системи;
• Тимчасові відмови або перебої в роботі ліній зв’язку.

Надійність та безперервність функціонування Системи буде забезпечуватися за рахунок:

• Використання сучасних технологій при розробці прикладного програмного забезпечення;
• Забезпечення якісного тестування прикладного програмного забезпечення;
• Забезпечення резервування основних компонентів та елементів Системи;
  • Організації та впровадження регламенту резервного копіювання, а також архівного збереження інформації в Системі;
  • Забезпечення виконання регламенту технічного супроводження експлуатації Системи на всіх етапах;
  • Вчасного реагування на аварійні ситуації та оперативної заміни в разі необхідності програмно-технічних засобів, які вийшли з ладу;
  • Забезпечення Сумісності технічних засобів та програмного забезпечення, що використовуються.

Для гарантування безперервної роботи серверної частини Системи буде реалізована одна з наступних стратегій забезпечення надійності:

• Гаряче резервування. При цьому дублюючі компоненти знаходяться у режимі “гарячого” резерву. У разі, якщо відклик основного компонента є відсутнім, здійснюється перехід на застосування резервного компонента в автоматичному режимі;
• Циклічне переключення компонентів. При цьому кожен виклик передається компонентам по циклу. У разі, якщо немає відклику від певного компонента,  здійснюється автоматичний перехід на використання іншого компоненту.

Рішення щодо ергономіки модулю відповідатимуть основним вимогам технічної естетики та інженерної психології, що забезпечить гармонійний зв'язок між параметрами технічних засобів та психофізичними можливостями людини. Рішення щодо ергономіки Системи забезпечуватимуть:

• Використання простих та інтуїтивно зрозумілих інтерфейсів робочих місць користувачів, які не потребують спеціальних знань або тривалого навчання для ефективної роботи з ними;
• Використання функціонально орієнтованих на вирішення конкретних задач форми відображення інформації для користувачів;
• Мінімальну кількість дій користувача при виконанні завдань в Системі, відсутність в екранних формах функціональних можливостей, що не потрібні для виконання завдання, яке поставлене перед користувачем;
• Вбудовані механізми валідації значень, що визначаються для окремих полів, комбінацій полів (контекстно-залежний контроль), контроль значень полів за довідниками/класифікаторами, а також на відповідність вже введеним даним (базі даних);
• Вбудовані механізми допомоги внесення та отримання інформації, контекстні підказки.

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

Стандартизація та уніфікація реалізації функцій компонентів Системи буде забезпечуватися за рахунок використання сучасних інструментальних програмних засобів, які підтримують єдину технологію проектування та розробки функціонального, інформаційного та програмного забезпечень систем. Розробка технічного та загального програмного забезпечень компонентів системи передбачає вибір сумісних, найбільш інтегрованих програмних та технічних засобів, які відповідають вимогам сучасних міжнародних стандартів «відкритих систем». Будуть розроблені вимоги до розробки прикладного програмного забезпечення, які уніфікують інтерфейс користувача, процедури обробки інформації, ідентифікацію програмних компонентів та баз даних, типізують окремі програмні модулі відповідно до свого призначення в різних функціональних підсистемах. Компоненти системи відповідають ДСТУ ISO/IEC 17025:2006, ТУ У 27.1-35679599-001:2012, а також мають підтвердження якості з висновками від наступних служб:

• Державної інспекції технологічної безпеки України;
• Державної санітарно-епідеміологічної служби.
• Застосування сучасних інформаційних технологій;
• Застосування правила централізованого накопичення, зберігання та обробки інформації;
• Підтримка актуальності, повноти, несуперечності, цілісності та доступності інформації;
• Забезпечення надійного захисту інформації від порушення її цілісності, витоку та блокування згідно з порядком, встановленим нормативно-правовими державними актами і нормативними документами в галузі захисту інформації;
• Розподіл рівня доступу до даних Системи за різними рівнями та можливість гнучкого налаштування та адміністрування;
• Забезпечення надійності, резервування компонентів технічного забезпечення Системи;
• Забезпечення централізованого управління, безперервного контролю функціонування та централізованого налаштування Системи та її компонентів;
• Забезпечення можливості реалізації централізованого оновлення рішень за результатами модернізації/доопрацювання та налаштувань Системи в автоматизованому режимі.

Інформаційне забезпечення розробляється достатнім для найбільш ефективного використання всіх функцій Системи. Інформаційне забезпечення  буде надавати можливості:

• Багаторазового використання даних у різних ділових процесах;
• Забезпечення фізичної та логічної цілісності даних;
• Мінімізації надмірності даних, що зберігаються;
• Стандартизації представлення даних;
• Достовірності та актуальності даних.
• Розмежування доступу до даних;
• Запобігання несанкціонованого доступу до даних.

Інформаційне забезпечення буде відповідати основним вимогам:

• Забезпечувати копіювання і зберігання масивів інформації;
• Забезпечувати мінімізацію обсягу даних, що вводяться вручну;
• Забезпечувати можливість розширення масивів інформації з урахуванням перспектив розвитку Системи.

Інформаційне забезпечення Системи буде включати:

• Систему класифікації і кодування;
• Програмні модулі забезпечення інформаційного обміну між компонентами системи та між внутрішніми та зовнішніми інформаційними системами, з якими повинний бути організований обмін.

Система класифікації і кодування  буде підтримувати процес накопичення і зберігання інформації, а також вирішення функціональних задач з мінімальними витратами пам’яті і максимальною швидкодією за рахунок використання класифікаторів таких рівнів:

• Локальних в межах системи;
• Відомчих;
• Загальнодержавних;

Розробка системи класифікації і кодування системи передбачить:

• Використання загальносистемних класифікаторів;
• Централізоване ведення системних класифікаторів;
• Забезпечення можливості аналізу інформації, формування статистичних звітів по усьому спектру класифікованих даних;
• Забезпечення мінімальних витрат пам‘яті у процесі накопичення та зберігання інформації;
• Забезпечення максимальної швидкодії при вирішенні функціональних задач.

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

• Можливість підключення та безпечність доступу локальних ресурсів Системи до зовнішніх інформаційних систем та ресурсів;
• Можливість централізованого адміністрування та керування доступністю локальних ресурсів Системи.

Лінгвістичне забезпечення Системи буде включати розвинуті мовні засоби програмування для розробки програмного забезпечення та інтерфейсу користувача. Мовні засоби програмування будуть обрані Виконавцем відповідно до рішень з програмного забезпечення Системи на етапі технічного проектування. Інтерфейс користувача буде розроблений українською мовою та забезпечуватиме:

• Очевидність кожної дії на робочих місцях користувачів та введення-виведення інформації на професійно-орієнтованій мові, яка використовує поняття конкретної предметної області ділових процесів;
• Наявність ефективної допомоги при можливих діях користувача;
• Максимальне використання при введенні інформації довідників можливих значень даних;
• Попередження помилкових ситуацій.

Програмне забезпечення (ПЗ) системи складатиметься із:

• загальносистемного програмного забезпечення (ЗПЗ);
• прикладного програмного забезпечення (ППЗ).

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

• підтримку загально прийнятих сучасних міжнародних стандартів до відкритих систем;
• сумісність та інтегрованість;
• підтримку функціонування в різнорідному апаратному і програмному середовищах;
• вмонтованість механізму захисту від помилок і підтримки цілісності;
• мінімальні витрати на їх закупівлю та експлуатацію.

До загальносистемного програмного забезпечення відносяться:

• операційні системи;
• система керування базами даних (СКБД);
• офісні застосування;
• тощо.

До прикладного програмного забезпечення відноситься програмне забезпечення, що розробляється та налаштовується під час створення системи. Розробка прикладного програмного забезпечення буде проводитись за допомогою сучасних інструментальних засобів програмної інженерії проектування і генерації розподілених баз даних (CASE-засобів). При розробці ППЗ будуть використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей системи за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів.

Модуль буде містити наступні автоматизовані робочі місця (АРМ):
-       АРМ користувача. -       АРМ адміністратора.
Користувач у своєму АРМ буде мати доступ до окремих вітрин даних (звітів) з обмеженням по набору доступних даних. Так, для керівника або спеціаліста району міста Києва необхідно обмежувати доступ районом, в якому він працює. Адміністратор в своєму АРМ буде мати змогу надавати доступ користувачам до звітів та управляти доступом до наборів даних. Доступ до даних визначається на основі засобів Системи, що була розроблена в попередніх чергах. Доступ до вітрин даних надається для груп користувачів та організацій. В рамках наборів даних існує можливість обмеження доступу на рівні довідників Системи. Для задач третьої черги Системи необхідно налаштувати обмеження доступу до даних з використанням довідника “Район”. Користувачі Системи відповідного району будуть мати доступ до:

• загальноміських даних
• детальних даних виключно по своєму району.

Налаштування рівнів доступу буде в АРМ Адміністратора. Специфікація обчислювальної техніки та апаратних засобів мережевої взаємодії забезпечить поетапну реалізацію функціональних задач Системи і врахує:

• Наявність існуючих технічних засобів у Замовника;
• Тенденції розвитку обчислювальної техніки та апаратних засобів зв'язку;
• Можливість фізичного поєднання різнотипної техніки у єдиний програмно-технічний комплекс;
• Необхідність взаємодії з зовнішніми автоматизованими системами;
• Високу пропускну здатність, надійність і безпечність передачі даних.

Автоматизовані робочі місця користувачів Системи будуть розгорнуті на базі сучасних комп’ютерів, технічні характеристики яких враховують функціональне використання автоматизованого робочого місця за призначенням в повному обсязі відповідно до вимог щодо якості функціонування Системи. Рольова модель системи адміністрування буде мати 2 рівня. В адмініструванні та інформаційному наповненні беруть участь такі ролі:

• Адміністратор;
• Користувач.

Різні користувачі будуть використовувати різну функціональність в залежності від рольової моделі згідно своїх функціональних обов’язків. В рамках кожної ролі користувачі можуть мати різні повноваження (наприклад, різні користувачі можуть мати доступ до перегляду різних вітрин даних). Система повноважень передбачить можливість призначення користувачам (або групам користувачів) прав (повноважень) для виконання операцій (перегляд, внесення змін, запис нової інформації, видалення) над різними об’єктами (сутностями системи). Ці повноваження можна буде призначати за допомогою інтерфейсу адміністрування, даючи повноваження групі і додаючи користувача до відповідної групи. При цьому перевірки, над якими саме об’єктами можна виконувати дану операцію, будуть здійснюватися виключно за рахунок технічної реалізації. Користувачі також будуть мати можливість входити в групи (об’єднання користувачів з однаковими правами доступу). В такому випадку, при наданні прав повноважень до групи користувачів, вони розповсюджуються на всіх користувачів, що входять до цієї групи (наслідування прав). Групи створюються в рамках ролі. Адміністратор при роботі з Системою буде мати технічну можливість виконувати такі дії (операції): -         вирішення поточних питань технічного супроводу програмного та апаратного забезпечення Системи; -         створення, редагування, видалення користувачів, керування правами та доступом до розділів (вітрин даних) кожного користувача та групи користувачів; -         здійснення регулярного резервного копіювання програмного забезпечення та інформаційного наповнення Системи. -         здійснення:

• управління розділами;
• управління категоріями розділів;
• управління статичними сторінками у випадку їх наявності (редагування, видалення, публікація, надання назв статичним сторінкам);
• управління поштовою розсилкою, розсилкою зареєстрованим користувачам;
• управління розподілом прав користувачів (користувач, редактор, адміністратор) та розподілом прав груп;
• управління профілями користувачів (перегляд, редагування, видалення, блокування);
• управління статистикою (перегляд детальної статистики, формування статистичних звітів за обраний період часу);
• управління довідниками системи.

Іноді адміністратору необхідно перевірити працездатність системи із роллю звичайного користувача. В такому випадку Адміністратор буде мати можливість скористатися так званою функцією імперсонації, тобто вибрати користувача та імітувати вхід в систему. При цьому він потрапить в інтерфейс тієї ролі, яка призначена користувачеві і модифікована таким чином, щоб дати можливість повернутися до інтерфейсу адміністратора. Вимоги до функціонального складу АРМ.

• Налагодження роботи з базою даних. Забезпечення можливості зазначення авторизаційної інформації, потрібної для доступу до бази даних, з якою працює сайт, та її налаштувань.
• Функція реєстрація користувачів.

Базовий набір прав: ­  перегляд списку зареєстрованих користувачів системи; ­  редагування особових даних акаунту користувача; ­  зміна та відновлення паролю користувача. Форма реєстрації нового користувача містить такі поля: ­        ім’я користувача (нік-нейм); ­        пароль (4-12 латинських літер, цифр або символів); ­        підтвердження паролю (4-12 латинських літер цифр або символів); ­        електронна адреса користувача; ­        роль користувача ­        права доступу конкретного користувача (в рамках ролі) або належність до групи користувачів. Відновлення пароля у разі його втрати. У разі втрати пароля, користувач має змогу відновити його, натиснувши кнопку «відновити пароль», що знаходиться в панелі авторизації. Відновлення пароля відбувається у такі етапи: ­    відправлення користувачем запиту на зміну пароля (користувач вказує свій нік-нейм та номер телефону); ­    відправлення користувачу листа на e-mail, що містить посилання для підтвердження бажання зміни паролю; ­    надання користувачу форми для зміни паролю; ­    відправлення користувачу електронного листа, який містить новий пароль. Форма зміни паролю містить: ­    новий пароль (4-12 латинських літер чи цифр або символів); ­    підтвердження нового паролю (4-12 латинських літер чи цифр або символів); ­    капчу. У модулі буде реалізовано можливість представлення списку користувачів за такими параметрами: ­    нік-нейм користувача; ­    дата реєстрації; ­    e-mail користувача. Додатково буде реалізована можливість пошуку за вказаними вище параметрами. Адміністратор буде мати можливість блокування користувачів за такими параметрами: ­    IP-адреса користувача або ­    нік-нейм або ­    e-mail користувача. Зареєстрований користувач може замінювати свій пароль для доступу до Системи виключно через HTTPS з’єднання.

• Функція управління користувачами

Буде надавати наступні можливості: ­  додавання облікового запису користувача; ­  редагування облікового запису користувача; ­  видалення облікового запису користувача; ­  активування/деактивування облікового запису користувача; ­  занесення користувача до відповідних його правам груп; ­  захист від багаторазового підбору пароля шляхом блокуванням доступу до системи авторизації для відповідного IP на деякий час (не менше 30 хвилин) та надсилання адміністратору попередження поштою; У системі обліковий запис користувача має наступні поля: ­  логін – унікальне поле, яке може складатись виключно з букв англійського алфавіту; використовується для авторизації та символічного позначення користувача, редактора у системі; ­  пароль – поле, яке може складатись виключно з цифр, букв та символів англійського алфавіту; використовується для авторизації у системі разом з полем логін; ­  е-mail; ­  ПІБ; ­  телефонний номер – поле з маскою, притаманною для телефонних номерів у міжнародному форматі; ­  посада – поле у довільному форматі; ­  опис – службове поле, яке надає можливість текстового опису користувача, редактора, приміток тощо. Особливості зберігання пароля: ­  зберігання хешу пароля (система не знає пароля користувача; при спробі авторизації порівнюється введений пароль з хешом; особливості – неможливо відтворити старий пароль користувача, тому, коли формується новий, старе значення хешу зберігається до моменту або підтвердження нового пароля, або при вході в систему зі старим паролем новий пароль деактивується). За умовчанням у системі зберігається як мінімум один активний обліковий запис з правами групи “Адміністратори”. Буде передбачено можливість налаштування доступу групам користувачів або конкретним користувачам по дозволеній IP–адресі. Для реалізації такого функціоналу буде передбачено у модулі можливість: -       переглядати список IP-адрес, яким надано відповідний доступ для роботи із системою; -       додавати, коригувати, видаляти IP-адреси, яким може бути наданий доступ до роботи із системою.

• Функція управління групами користувачів

Даний функціонал надає адміністратору наступні можливості: ­  додавання групи; ­  редагування групи; ­  видалення групи; ­  встановлення прав для окремої групи. Опис групи користувачів/редакторів має наступні обов’язкові поля: ­  назва групи; ­  статус групи (активна, неактивна); ­  набір прав (повноважень) для групи, а саме – перелік блоків (вітрин даних), доступних для перегляду учасниками групи або їх редагування (наповнення, видалення). За умовчанням, у системі є одна група з назвою “Адміністратори”, яка має повні права на усі модулі; цю групу неможливо видалити.

• Функція роботи з довідниками.

Надає можливість адміністраторам системи здійснювати редагування інформації, що містяться в довідниках, які використовуються Системою. А саме: редагування та видалення вмісту інформації, що міститься у таблицях довідників. При цьому Система забезпечить цілісність та зв'язок даних для уникнення помилок у роботі. Для операцій з масового введення інформації буде передбачена мінімізація кількості натискань на клавіатуру для виконання стандартних дій завдяки інтерфейсу системи та підтримці комбінацій клавіш. Кількість записів у довідниках обмежена виключно можливостями бази даних щодо зберігання. Будуть передбачені інструменти для перевірки коректності введеної інформації на відповідність типу кожного поля, для запобігання виникнення помилок у роботі системи.

Впровадження Системи підвищить ефективність виконання функціональних обов’язків керівників районних державних адміністрацій, керівників підрозділів, що займаються обробкою звернень від населення. Організаційне забезпечення, що створюється у межах Системи, буде включати документи, які відображають автоматизований технологічний процес обробки інформації у Системі та регламентують діяльність її користувачів. У ході розробки Системи Виконавець може розглянути можливість забезпечення експлуатації Системи на умовах аутсорсингу.

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

Створення ІТС “Звітність” третьої черги передбачає створення та впровадження нових компонентів звітності, а саме:

1. Оперативна інформація про стан виконання звернень до Комунальної бюджетної установи “Контактний центр міста Києва 1551”.
2. Результати району у загальноміському рейтингу по обробці звернень до КБУ “Контактний центр міста Києва 1551”.
3. Оперативний стан ситуації у сфері житлово-комунального господарства району за даними центральної диспетчерської служби м. Києва 1557 (КП “Київжитлоспецексплуатація”).
4. Результати району у загальноміському рейтингу у сфері житлово-комунального господарства, що створюється за даними Центральної диспетчерської служби 1557, КП “Київжитлоспецексплуатація”.
5. Рейтингові показники роботи ліфтового обладнання.
6. Інформація про актуальний стан подачі комунальних послуг в районі.
7. Інформація про актуальний стан роботи ліфтового обладнання.
8. Інформація про актуальний стан запуску опалювального сезону.
9. Інформація про випуск транспорту на маршрути КП “Київпастранс”.

Перелік послуг зі створення ІТС “Звітність” третьої черги включає:

• Розробку Технічного завдання на створення третьої черги ІТС “Звітність”:
  • Детальний аналіз бізнес-процесів Замовника (див. розділ 5.2);
  • Аналіз наявної проектно-конструкторської документації та функціональності існуючих інформаційних систем Установ, структур баз даних, процесів первинного наповнення та актуалізації даних;
  • Класифікація переліку облікових об’єктів системи, визначення їх атрибутивного складу, процесів первинного наповнення та актуалізації даних, технологічних процесів роботи;
  • Деталізація вимог до функціонального складу комплексу службових програмних модулів та прикладних програмних модулів.
  • Розробку програмного забезпечення третьої черги ІТС «Звітність»:
    • Розробка програмного забезпечення комплексу підсистем службових програмних модулів, прикладних програмних модулів, експлуатаційної документації;
    • Первинне наповнення довідників, класифікаторів та іншої первинної інформації в базі даних Системи;
    • Підготовчі роботи до розгортання Системи на базі програмно-апаратного комплексу Замовника. Підготовчі роботи передбачають:
      • Підготовку комплексних інструкцій з монтажу і запуску Системи;
      • Налаштування програмно-апаратного комплексу Замовника;
      • Розгортання Системи на комплексі технічних засобів Замовника;
      • Проведення випробувань. Система проходить випробування за наступними етапами:

1. Попередні випробування. Склад, обсяг і методи попередніх випробувань Системи визначаються документом «Програма і методика випробувань» та розробляються на етапі створення робочої документації. 2. Дослідна експлуатація. Склад, обсяг і методи дослідної експлуатації Системи визначаються документом «Програма дослідної експлуатації» та розробляються на етапі впровадження Системи в експлуатацію. Випробування Системи включають перевірку функціонування кожного з компонентів у наступних режимах:

• Основний режим.
• Режим адміністрування.
• Режим регламентного обслуговування.

Алгоритм проведення випробувань Системи включає наступні елементи, які визначаються за кожним етапом та погоджуються сторонами:

• Стадія випробувань;
• Учасники випробувань;
• Місце і строк проведення випробувань;
• Порядок узгодження документації;
• Статус приймальної комісії.
• Проведення попередніх випробувань включає:
  • Фіксування виявлених неполадок в Протоколі випробувань.
  • Усунення виявлених неполадок.
  • Перевірка усунення виявлених неполадок.
  • Ухвалення рішення про можливість передачі Системи в дослідну експлуатацію.
  • Складання та підписання Акту приймання Системи в дослідну експлуатацію експертною групою.
  • Проведення дослідної експлуатації. Впровадження програмного забезпечення третьої черги ІТС “Звітність” в дослідну експлуатацію передбачає:
    • Проведення навчання відповідальних технічних фахівців встановленню та адмініструванню Системи;
    • Проведення навчання користувачів;
    • Організацію процесу збору та накопичення зауважень та коментарів до роботи Системи.
    • Фіксування виявлених неполадок в Протоколі випробувань.
    • Усунення виявлених неполадок.
    • Перевірка усунення виявлених неполадок.
    • Складання та підписання Акту про завершення дослідної експлуатації експертною групою.

Після проведення всіх етапів випробувань Виконавець надає наступну оновлену у відповідності з результатами проведення випробувань та рекомендаціями щодо вдосконалення документацію:

• Дослідний зразок програмного забезпечення.
• Загальна інструкція з розгортання та налаштування програмного забезпечення.
• Програма та методика приймальних випробувань.
• Протокол приймальних випробувань.
• Програма та методика переведення в дослідну експлуатацію.
• Протокол переведення.
• Керівництво адміністратора.
  • Керівництво користувача.

У складі додаткових послуг зі ІТС “Звітність” третьої черги передбачені наступні:

• Технічне обслуговування;
• Модернізація апаратно-програмного комплексу;
• Усунення аварійних ситуацій.

При цьому загальний час проведення профілактичних робіт не повинний перевищувати 3% від загального часу роботи системи в основному режимі функціонування. Буде передбачена можливість ведення журналів інцидентів в електронній формі, а також графіків і журналів проведення профілактичних робіт. Для всіх технічних компонентів буде забезпечено регулярний і постійний контроль стану Системи і технічне обслуговування без зупинки її функціонування. Технічне обслуговування Системи забезпечуватиме:

• безперервне забезпечення супроводження експлуатації системи на всіх стадіях життєвого циклу;
• цілодобовий режим роботи системи та її компонентів за призначенням в повному обсязі;
• централізований контроль працездатності системи;
• усунення відмов роботи системи та її компонентів;
• адміністрування (оперативне налагодження під час експлуатації) роботи системи;
• своєчасне централізоване застосування оновлень програмного забезпечення.

Додаткові послуги надаються за окремими договорами на умовах аутсорсингу або штатного обслуговування за погодженням. Для якісного та своєчасного проведення робіт з розгортання та випробувань Системи є необхідним забезпечення наступних умов:

• Здійснена підготовка приміщень, в яких розташований апаратний комплекс для розгортання Системи відповідно до вимог, наведених в цьому технічному завданні;
• Здійснено закупівлю та встановлення необхідного ПЗ;
• Забезпечена організація необхідної мережевої комунікації для швидкої взаємодії;
• Створені умови функціонування Системи, при яких гарантується відповідність створюваної системи вимогам, що містяться в даному технічному завданні;
• Вирішено організаційні питання щодо взаємодії з системами-джерелами даних;
• Створено необхідні умови для безперервного функціонування системи підрозділів і служб;
• Організовано доступ до баз даних джерел;
• Визначено регламент інформування про зміни структур джерел даних;
• Виділено відповідальних фахівців з боку Замовника для взаємодії з проектною командою
• Забезпечено можливість ефективної роботи Системи та умов функціонування, при яких гарантується відповідність створюваної Системи вимогам, що містяться в цьому технічному завданні.

Вся документація оформлюється українською мовою в двох екземплярах та затверджується в друкованому вигляді з наданням копій в електронному вигляді. Технічна документація розроблюється у відповідності до чинних державних стандартів та з використанням термінології згідно галузевих і корпоративних стандартів. До складу документації на Систему входять:

• Технічне завдання.
• Загальний опис рішення
• Програма та методика попередніх випробувань.
• Протокол попередніх випробувань.
• Протокол впровадження в дослідну експлуатацію.
• Протокол дослідної експлуатації.
• Інструкція з формування та ведення бази даних.
• Загальна інструкція по налагодженню рішення.
• Керівництво Користувача.
• Керівництво Адміністратора.

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

Третя черга ІТС “Звітність” забезпечить впровадження компонентів інформування керівників державних районних адміністрацій про показники роботи служб району по обслуговуванню звернень населення та надання населенню комунальних та транспортних послуг. Буде забезпечено розробку службової частини системи для забезпечення управлінням доступу до розділів системи. Також буде організовано можливість безпосереднього вводу даних, що не представлені в цифровому вигляді у інформаційних системах, з якими буде організована інтеграція ІТС “Звітність”. Система забезпечить:

• Можливість поділу повноважень для доступу до інформації:
  • Рівень 0 – рівень формування комплексу показників для керівництва КМДА. Відображаються показники по всьому місту.
  • Рівень 1 – рівень формування комплексу показників для керівників районних служб міста.

• Поділ формування звітності на наступні компоненти:

1. Оперативна інформація про стан виконання звернень до Комунальної бюджетної установи “Контактний центр міста Києва 1551”.
2. Результати району у загальноміському рейтингу по обробці звернень до КБУ “Контактний центр міста Києва 1551”.
3. Оперативний стан ситуації у сфері житлово-комунального господарства району за даними центральної диспетчерської служби м. Києва 1557 (КП “Київжитлоспецексплуатація”).
4. Результати району у загальноміському рейтингу у сфері житлово-комунального господарства, що створюється за даними Центральної диспетчерської служби 1557, КП “Київжитлоспецексплуатація”.
5. Рейтингові показники роботи ліфтового обладнання.
6. Інформація про актуальний стан подачі комунальних послуг в районі.
7. Інформація про актуальний стан роботи ліфтового обладнання.
8. Інформація про актуальний стан запуску опалювального сезону.
9. Інформація про випуск транспорту на маршрути КП “Київпастранс”.

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

• Ідентифікацію та автентифікацію Користувача. Повинна здійснюватися ідентифікація і перевірка справжності користувачів при вході в Систему за логіном і паролем, або за допомогою двохфакторної ідентифікації.
• Розмежування доступу користувачів на рівні функціоналу та інформаційних масивів.
• Збереження цілісності даних.
• Реєстрація дій користувачів.

У Системі передбачена взаємодія з користувачами зовнішніх систем, які мають наступні ролі: Система КБУ “Контактний центр 1551”:

• Оператор;
• Модератор/оператор;
• Виконавець 1551;
• Куратор (координатор);
• Оператор (відділ зворотного зв’язку);
• Спеціаліст ОКК.

Система Центральної диспетчерської міста з питань ЖКГ 1557:

• Диспетчер диспетчерської служби керування;
• Координатор;
• Виконавець 1557.

Система організації випуску транспорту на маршрут КП “Київпастранс”:

• Диспетчер.

Функції та дії користувачів відповідно рольовій моделі описано в розділі 5.3.

Зовнішня роль: Оператор. Приймає виклик:

• Отримує дзвінок через програму телефонії;
• Відповідає на вхідний дзвінок протягом 3 секунд;
• Починає розмову з абонентом згідно основних, тематичних скриптів розмови та правил телефонного етикету.

Рис. 6. Загальна схема бізнес-процесу прийому та реєстрації звернень, що надійшли по дзвінку
Уточняє інформацію:

• Уважно вислуховує абонента та орієнтується у суті звернення;
• У випадку, якщо суть звернення не зрозуміла оператору, то він задає уточнюючі запитання для отримання повної картини про проблему.

Переглядає інформацію:

• Переглядає інформацію по необхідній темі в «Базі знань», АРМ або ОС «Городок».
• У випадку, якщо для перегляду інформації потрібно більше часу, ставить абонента на «Hold», використовуючи основні скрипти розмови.

Надає інформацію та проставляє відмітку в БЗ:

• При наявності в системах необхідної інформації, надає відповідь абоненту.
• При наданні інформації з Бази знань, оператор на сторінці, з якої була отримана інформація, оператор проставляє відмітку «Надано інформацію» згідно інструкції.

При відсутності в Базі знань необхідної інформації, оператор оформлює запит на внесення, доповнення або зміну інформації.
Реєструє звернення:

• При необхідності оператор оформлює звернення в АРМ згідно тематичних скриптів;
• Надає абоненту номер зареєстрованого звернення.

Завершує виклик, зберігає запис розмови.

Зовнішня роль: Модератор/оператор.
Отримує звернення у вигляді реєстраційної картки з особистими даними та змістом питання.
Перевіряє звернення на дотримання всіх вимог та правил реєстрації звернення на сайті 1551 в мобільному додатку. Реєструє або відхиляє звернення:

• Реєструє звернення в АРМ згідно класифікатора питань.
• В разі порушення правил реєстрації користувачем сайту 1551 мобільного додатку, відхиляє звернення з відповідною причиною відмови, яку відображено в особистому кабінеті користувача або у вигляді листа на його електронній пошті, через яку користувач проходив реєстрацію на сайті 1551.

Рис. 8. Загальний бізнес-процес опрацювання звернення виконавцем
 
Рис. 9. Загальний бізнес-процес опрацювання звернення виконавцем (продовження) Зовнішня роль: Виконавець Отримує звернення: Виконує пошук звернень в програмно-апаратному комплексі АРМ “CallCenter” згідно інструкції:

• Пошук поточних звернень, тобто тих, які знаходяться в стані виконання (надійшли на опрацювання за певний проміжок часу) з урахуванням звернень, які було перенаправлено від інших структурних підрозділів КМДА, РДА тощо.
• Пошук звернень, які є невиконаними та контроль яких припадає на поточний день.

Приступає до опрацювання звернення:

• Починає роботу над зверненням.
• У випадку, якщо звернення не відноситься до компетенції організації яка отримала його на виконання, виконавець встановлює значення «Не належить до компетенції» та залишає коментар, з якої причини.
• Якщо звернення необхідно розписати на підпорядковану організацію (наприклад, КП, ЖЕД, відділ благоустрою тощо), то обирає структуру з дерева організацій, на яку слід розписати дане звернення.

Завершує опрацювання звернення:

• У випадку, якщо звернення виконано в повному обсязі, встановлює статус «Виконано». Під статусом «Виконано» в повному обсязі, розуміється: Відновлено ГВП, ХВП, опалення, тощо, благоустрій після розриття – відновлено; покладено асфальтне покриття; зрізано аварійне дерево.
• У випадку, якщо виконання звернення не передбачає вчинення будь-яких дій, а відповідь несе в собі інформацію консультативного характеру по суті питання, ставить відмітку «Роз’яснено».

Зовнішня роль: Куратор (координатор) Виконує пошук звернень з відміткою «Роз’яснено» згідно інструкції по роботі зі зверненнями громадян за допомогою «Переліку звернень». Перевіряє наявність та відповідність до суті порушеної проблеми листа-відповіді. Повертає звернення виконавцю або підтверджує виконання:

• Присвоює статус «Не виконано» з відповідним підстатусом:
  • «Безглузда відповідь» - відповідь не по суті порушеного питання;
  •  «Фінансування» - відсутнє фінансування для вирішення проблеми, що порушується у зверненні;
  • «План/програма» - вирішення проблеми, що порушується у зверненні запланована на майбутні періоди (включена до програми ремонту);
  • «Чекати відповідь» - відповідь є проміжною;
  • «На доопрацюванні» - звернення відправлено на доопрацювання, у зв’язку з наявними неточностями або невідповідностями до шаблону відповіді;
  • «Фактично» - проблема, порушена у зверненні, не вирішена.

 
Рис. 10. Загальний бізнес-процес контролю надання відповіді виконавцем

• Підтверджує виконання звернення виконавцем шляхом присвоєння йому статусу «Виконано» з відповідним підстатусом:
  • «Роз’яснено» - роз’яснено по суті порушеної проблеми;
  •  «Самостійно» - звернення було вирішено без участі виконавця, а власними силами заявника;
  •  «Частково» - звернення було вирішено не в повному обсязі;
  •  «Відмовлено у задоволенні» - заявнику було відмовлено у вирішенні проблеми, що порушується у зверненні (наприклад, облаштувати дитячий майданчик на ділянці, де розміщенні тепломережі тощо).
  •  «Фактично» - звернення вирішено у повному обсязі.

Зовнішня роль: Оператор (відділ зворотного зв’язку) Здійснює пошук звернень, у “Переліку звернень CallCenter” обирає звернення, які було встановлено на прозвон, зі статусом “Виконано”. Виконує вихідний прозвон для підтвердження виконання звернення заявником згідно інструкції та скриптів. В разі неможливості здійснення продзвону визначає:

• Період повторного продзвону,
• Час очікування на лінії відповіді заявника,
• Кількість здійснених спроб,
• Статус «неможливо здійснити зворотний зв’язок».

Підтверджує виконання або повертає звернення виконавцю:

• Визначає статус «Виконано» - «Фактично», «Самостійно» та підтверджує виконання підписом;
• Визначає статус «Не виконано» - «Фактично» та повертає звернення виконавцю.

Рис. 11. Загальний бізнес-процес надання зворотного зв’язку

Роль: Спеціаліст ОКК Переглядає та аналізує всі заявки, що надійшли до ЦДС 1551. Формує та подає щотижневу звітність:

• ТОП – 10 найпроблемніших питань,
• Статистика надходження звернень громадян,
• Щотижневий дайджест 1551.

Формує та подає щомісячну звітність:

• Проведення щомісячної оцінки діяльності районних в місті Києві державних адміністрацій за окремими показниками,
• Рейтинг ЖЕДів,
• Статистика надходження звернень громадян.

Формує та подає щоквартальну звітність «Про результати виконання Програми «Безпечна столиця» на 2016-2018 роки».

Роль: Диспетчер диспетчерської служби керування. Слідкує за викликами що надходять в диспетчерську службу:

• у випадку надходження телефонного дзвінка надає мешканцю або іншій особі всі необхідні роз’яснення;
• у випадку надходження сигналу від пасажира в ліфту або через домовий переговорний пристрій вмикає двосторонній переговорний зв'язок.

Приймає та розподіляє вхідні телефонні дзвінки. Приймає виклики через переговорні пристрої з під’їздів та кабін ліфтів. Реєструє в установленому порядку в програмному забезпеченні компанії звернення від мешканців або третіх осіб, отримані особисто за допомогою дзвінків або викликів, через переговорні пристрої в під’їздах та кабінах ліфтів. Надає консультації мешканцям по скаргам та претензіям щодо якості надання послуг Диспетчерської служби керування. У випадку звернення співробітника ЖЕД або зовнішньої служби переводить дзвінок на панелі оператора на чергу Виконавці відповідного району. Інформує особисто, за телефоном або через переговорний пристрій мешканців або третіх осіб про орієнтовні терміни проведення ремонтних і налагоджувальних робіт інженерного будинкового обладнання, про причини та орієнтовні терміни усунення несправності ліфтового обладнання. Вживає заходів щодо усунення несправності ліфта та визволення громадян. Надає рекомендації щодо порядку виконання робіт для усунення порушень в роботі будинкового інженерного обладнання. Створює заявки на проведення відповідних робіт та призначає їх Виконавцям. Перевіряє наявність звернень щодо поточного питання та об’єднує їх у відповідній заявці. Доповідає Начальнику Зміни Диспетчерської служби керування про виявлені недоліки в роботі Диспетчерської служби Керування, щодо якості обслуговування мешканців, надає пропозиції щодо їх усунення.

Рис. 13. Загальний бізнес-процес прийому і реєстрації звернень


 Рис. 14. Загальний бізнес-процес прийому і реєстрації звернень  (продовження)

Пожежа, мінування, труп людини Роль: Диспетчер диспетчерської служби керування.

• не оформлює заявку,
• уточнює у мешканця повну адресу,
• рекомендує звернутись до пожежної частини за телефоном 101 або до поліції,
• передає інформацію начальнику зміни через систему телефонії,
• начальник зміни передає інформацію через систему телефонії у відділ Координаторів (Координатору відповідного району).

Роль: Координатор

• передає інформацію аканту, начальнику ЖЕД, МНС в у телефонному режимі у будь-який час доби,
• інформує про те, що пожежну службу та поліцію ДСК не викликає.

 Впали люди в шахту ліфта, затиснуло частину тіла у дверях ліфту Роль: Диспетчер диспетчерської служби керування.

• оформляє заявку з видом робіт “Застрягли люди”, тип “Аварійна”,
• прописує в змісті заявки інформацію - впали люди в шахту ліфта або затиснута частина тіла,
• ліфт при цьому категорично не перезапускається,
• передає інформацію начальнику зміни через систему телефонії,
• начальник зміни передає інформацію через систему телефонії до відділу Координаторів (Координатору відповідного району).

Роль: Координатор

• передає інформацію в ліфтову організацію, аканту, начальнику ЖЕД, МНС в у телефонному режимі у будь-який час доби,
• кожні 15 хвилин за допомогою автонагадування зв’язується із людиною в ліфті для контролю її психофізичного стану.

Посилилася аварійна ситуація, заявка є, або житель обіцяє скаржитися у 1551 Роль: Диспетчер диспетчерської служби керування.

• повідомляє координатору через систему телефонії інформацію про посилення аварійної ситуації.

Роль: Координатор

• перевіряє інформацію по жителю (чи не є він проблемним), консультує диспетчера щодо подальших дій.

Роль: Виконавець. Отримує звернення в обліковій системі. Приймає до виконання шляхом:

• зміни статусу задачі «Прийняти в роботу»;
• телефонним дзвінком від Координатора району.

Приступає до виконання робіт. У випадку необхідності зв’язується с Координатором для внесення коригувань у завдання. Якщо завдання не входить до компетенції Виконавця – виставляє статус «Відхилено». Якщо завдання виконано – виставляє статус завдання:

• «Виконано» – якщо заявка виконана частково, і після його робіт необхідні дії іншого Виконавця;
• «Закрито» – якщо заявка виконана повністю і може бути відправлена в архів;
• «Помилковий виклик» – якщо виклик виявився помилковим.

 
Рис. 16. Загальний бізнес-процес опрацювання звернень виконавцем

Роль: Координатор. Слідкує за появою нових заявок в Системі. Оброблює заявки згідно з класами обслуговування:

• Глобальні – Заявки на інфраструктурних об’єктах від будинку і більше;
• Аварійні – завдання що потребують невідкладної реакції виконавця.
• Термінові – завдання що мають підвищений пріоритет виконання.
• Звичайні – завдання, що мають строк виконання від 1 доби і більше.

Контролює появу нових заявок в Системі та передає заявки в роботу. Контролює строки виконання заявок в Системі та при досягненні планової дати – зв’язується з Виконавцем для уточнення процесу виконання заявки, корегування планових строків її виконання. Кожна з заявок має регламентний строк її виконання згідно з яким оцінюється роботи Виконавця.  
Рис. 17. Загальний бізнес-процес передачі завдань в роботу та контролю їх виконання

Роль: Диспетчер. Створює Добові наряди з маршрутами. Створює План роботи з заповненням даних про маршрути, рухомі одиниці, водіям.

Роль: Диспетчер. Якщо рухома одиниця не може вийти на лінію з будь-якої причини диспетчер вносить інформацію про причину та час затримки.

Система забезпечує обробку даних, які поступають з суміжних систем, а саме:

• Система АРМ “Call-центр” Комунальної бюджетної установи «Контактний центр м. Києва 1551»,
• Система реєстрації та контролю виконання заявок “Городок”, що використовується в центральній диспетчерській м. Києва з питань ЖКГ 1557,
• Автоматична система обліку транспортної роботи КП “Київпастранс”.

Інформаційний обмін з суміжними системами буде реалізований на основі налаштованих програмних каналів обміну даними через резервний шлюзовий сервер. Шлюз інформаційного обміну передбачатиме: -     можливість підключення та безпечність доступу локальних ресурсів Системи до зовнішніх інформаційних систем та ресурсів; -     можливість централізованого адміністрування та керування доступністю локальних ресурсів системи. Кожна з вищеперелічених установ надає дані для формування відповідної частини звітності.
Комунальна бюджетна установа “Контактний центр м. Києва 1551” надає дані для формування наступних компонентів:

• Оперативна інформація про стан виконання звернень до Комунальної бюджетної установи “Контактний центр міста Києва 1551”.
• Результати району у загальноміському рейтингу по обробці звернень до КБУ «Контактний центр міста Києва 1551».

            Дані від Комунальної бюджетної установи “Контактний центр міста Києва 1551” надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються), а саме:

• Рейтинг РДА

            Вибірка містить наступні елементи:
Таблиця 1. Структура даних по рейтингу РДА

Таблиця 2. Структура даних по зверненням жителів в КБУ “Комунальна бюджетна установа 1551” Звернення жителів

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

• Період оновлення оперативних даних про роботу контактного центру не рідше раз на 15 хвилин;
• Період оновлення оперативних даних про інші показники отримання та обробки звернень не рідше раз на день.
• Рейтингові показники роботи РДА не рідше раз на день.

Імпорт даних

Центральна диспетчерська м. Києва з питань ЖКГ 1557 надає дані для формування наступних компонентів:

• Оперативний стан ситуації у сфері житлово-комунального господарства району за даними центральної диспетчерської служби м. Києва 1557 (КП “Київжитлоспецексплуатація”).
• Результати району у загальноміському рейтингу у сфері житлово-комунального господарства, що створюється за даними Центральної диспетчерської служби 1557, КП “Київжитлоспецексплуатація”.
• Рейтингові показники роботи ліфтового обладнання.
• Інформація про актуальний стан подачі комунальних послуг в районі.
• Інформація про актуальний стан роботи ліфтового обладнання.
• Інформація про актуальний стан запуску опалювального сезону.

            Дані від Центральної диспетчерської м. Києва з питань ЖКГ 1557 надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються). Вибірка містить наступні елементи: Таблиця 3. Структура Звернення Центральної диспетчерської 1557 Звернення (appeals)

Таблиця 4. Структура таблиці Заявки Центральної диспетчерської 1557 Заявки (claims)

Таблиця 5. Структура таблиці Об’єкти в заявці Центральної диспетчерської 1557 Об’єкти в заявці (claims_places)

Таблиця 6. Структура таблиці Зупинки ліфтів Центральної диспетчерської міста 1557 Зупинки ліфтів (elelvator_stop)

Таблиця 7. Структура таблиці Задачі Центральної диспетчерської міста 1557 Задачі (tasks)

Таблиця 8. Структура таблиці Виконавці задачі Центральної диспетчерської міста 1557 Виконавці по Задачі (job_tasks)

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

• Період оновлення оперативних даних про роботу контактного центру не рідше раз на 15 хвилини;
• Період оновлення оперативних даних про інші показники отримання та обробки звернень не рідше раз на годину;
• Період оновлення оперативних даних про роботу ліфтового обладнання та подачі комунальних послуг в будинки не рідше раз на годину;
• Рейтингові показники ЖЕДів та ліфтового обладнання раз на місяць.

Імпорт даних

КП “Київпастранс” надає дані для формування компоненту інформації про випуск транспорту на маршрути.             Дані від КП «Київпастранс» надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються) та обробляються з використанням механізму обміну даними JavaScript Object Notation. Вибірка містить наступні елементи: Таблиця 9. Структура даних по Випуску транспорту на маршрут КП “Київпастранс”

Імпорт даних

Періодичність оновлення даних 2 рази на добу.             За отриманими даними формуються графічні звіти, що відображаються на інформаційних панелях застосування. При відсутності або ненаданні доступу до будь-якої частини даних Виконавець може реалізувати форми для ручного внесення показників у Систему.

Компонент забезпечить: -       Розробку інформаційної панелі для інформування керівника районної адміністрації м. Києва про кількість звернень, що надходять до контактного центру 1551 та забезпечити його інструментом для відслідковування динаміки зміни даного показника; -       Шляхом порівняння показників роботи району з іншими районами міста необхідно забезпечити надання та відображення інформації про роботу структурних підрозділів районних державних адміністрацій по обробці звернень громадян; -       Взаємне порівняння показників роботи структурних підрозділів району для визначення підрозділів з найкращими та найгіршими результатами по виконанню звернень громадян. -       Можливість експорту друкованої версії звітів у форматі PDF.
Компонент включатиме: -       Оперативну інформацію про динаміку кількості звернень, що надходять до контактного центру 1551 за останні 7 днів; -       Рівень виконання звернень районом (порівняння з іншими районами) та в розбивці по підрозділам, що обробляють звернення в районі. -       Рейтинг найбільш актуальних питань, що набирають актуальність та, навпаки, втрачають актуальність за останні 7 днів. -       Кількість та доля звернень, що були прострочені виконавцями.
Джерела даних: Див. п.5.5. Отримані дані структуруються, компонуються та індексуються програмними засобами Системи для забезпечення швидкого доступу та спрощення обчислень.

Вітрини даних

Дані представляються у такому вигляді: Перелік звітів:

1. Звіт за результатами моніторингу кількості звернень до служби 1551 за останній тиждень. Відслідковування динаміки зміни кількості звернень в залежності від рівня доступу користувача:

• значення по місту;
• по обраному району;
• по організаціям та підрозділам району, що є виконавцями даних звернень.

          Звіт відобразити відобразить динаміку отримання звернень по району з можливістю порівняння тенденції з середніми показниками по місту. Керівник буде мати змогу бачити зміну активності отримання звернень громадян, що звертаються до контактного центру.
Графічне представлення звіту:

• Заголовок: Моніторинг звернень 1551.
• Динамічний підзаголовок: Назва району м. Києва. До підзаголовку додається уточнення (за тиждень).
• Візуалізація даних: графіки залежності кількості звернень від конкретного дня тижня; горизонтальна вісь графіку відображає дні тижня (позначення та порядок: сб, нд, пн, вт, ср, чт, пт), вертикальна вісь – кількість звернень (підпис осі – кількість звернень).
• Дані відображаються за двома масивами та позначаються кольорами та маркерами:

а) фактична кількість звернень; б) планова кількість звернень.

1. Звіт із результатами аналізу кількісних показників виконання звернень до служби 1551. Формування переліку організацій та підрозділів з найбільшою кількістю роз’яснень. Відслідковування показників долі виконання звернень:

• загалом по місту;
• по обраному району;
• по організаціям та підрозділам району, що є виконавцями даних звернень.

          Такий звіт відобразить долю закритих заявок, що реально опрацьовані виконавцями. Аналіз даних показників відобразить «вузькі» місця в обробці звернень, та сприяти пошуку шляхів виконання звернень замість видачі роз’яснень. Аналіз по виконавцям дозволить звернути увагу на підрозділи, що занижують даний показник району.
            Графічне представлення звіту:

• Заголовок: Співвідношення виконання та роз'яснення звернень.
• Візуалізація даних: по середньому рівню виконання звернень по місту та по району
• Таблиця з представленням підрозділів, що надали найбільше роз'яснень при обробці звернень мешканців міста.

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

1. Звіт за результатами моніторингу звернень, що були прострочені. Формування переліку організацій та підрозділів району з найбільшою кількістю прострочених звернень до служби 1551.

Звіт забезпечить керівника району інформацією про підрозділи, що затримують виконання звернень та прострочують їх виконання. Покращення даних показників підрозділів району підвищить результати району в загальноміському рейтингу. Графічне представлення звіту:

• Заголовки:

1. ТОП 3 організацій по простроченим зверненням.
2. ТОП 3 департаментів по простроченим зверненням.

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

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

1. Звіт з відображенням динаміки зростання та спаду актуальності питань у розрізі часу (за звітний період). Формування реєстру питань, що турбують громадян та організацій, які звертаються до контактного центру. Відслідковування актуальних тенденцій (як зростання так і зниження).

Звіт відобразить питання, що набирають популярність у громадян району та, можливо, потребують втручання/роз’яснення/втручання від голови району або його підлеглих.             Графічне представлення звіту:

• Заголовки:

1. Зростання актуальності за тиждень.
2. Cпад актуальності за тиждень.

• Візуалізація даних: наведені наступні дані за трьома питаннями з найвищими (для зростання) та найменшими (для спаду) показниками актуальності за звітний період (тиждень) у порядку зменшення:

-         показник зростання/спаду актуальності питання у відсотковому вираженні; -         показник зростання/спаду актуальності питання у числовому вираженні; -         тематика питання.

1. Звіт з загальними показниками ефективності роботи служби 1551.

Звіт забезпечить керівника району наступною загальною інформацією: -           кількість звернень, які знаходяться в обробці, -           кількість прострочених звернень (у процентному та числовому вираженні), -           середній показник часу з’єднання з оператором контактного центра, -           кількість дзвінків за поточну добу.
            Графічне представлення звіту:

• Заголовки:

1. Звернень в роботі.
2. Звернень прострочено.
3. Час до з'єднання.
4. Дзвінків за добу.

• Візуалізація даних: наведені актуальні дані за відповідними пунктами. Для забезпечення зручності використання дані можуть виділятися кольорами або шрифтами.

Компонент забезпечить інформування керівників районів про результат, отриманий районом в загальноміському рейтингу по обробці звернень, що складається контактним центром 1551. Компонент надасть необхідну інформацією про те, які показники впливають на оцінку роботи району в загальноміському рейтингу та результати району по ним. Також буде забезпечено можливість формування друкованої версії звітів у форматі PDF.
Компонент включатиме: -         Рейтингові показники району по сферах:

• Житлово-комунальне господарство,
• Благоустрій,
• Споживчий ринок.

- Результати району по елементам, з яких складається значення рейтингових показників по виконанню та закриттю звернень до КБУ “Контактний центр міста Києва 1551” та по сферах. - Середні результати по місту та результати роботи по визначеному району, а також результати у розрізі відповідальних виконавців.

Вітрини даних             Дані представляються у такому вигляді: Рис. 23. Прототип сторінки Результати району у загальноміському рейтингу по обробці звернень до КБУ “Контактний центр міста Києва
1551”
Перелік звітів:

1. Звіт за результатами розрахунку рейтингових показників з елементами:

• кількість отриманих звернень;
• вчасність закриття виконавцями;
• виконання звернень виконавцями;
• кількість звернень, що знаходяться в роботі;
• показники достовірності виконання робіт;
• розрахунок:
  • індексу швидкості виконання;
  • індексу фактичного виконання;
  • підсумкового рівня виконання звернень.

Звіт відобразить загальні рейтингові показники району в цілому та в розбивці по окремих підрозділах району. Керівник отримає можливість бачити складові рейтингу, що негативно впливають на результати роботи району. Керівник буде мати можливість бачити деталізацію даних показників по підрозділах району, які займаються обробкою та виконанням звернень.
Графічне представлення звіту. Звіт подається у вигляді таблиць показників за трьома секціями:

1. Житлове господарство.
2. Благоустрій.
3. Споживчий ринок.

            За кожною секцією створюється окрема таблиця за наступними правилами:

• Загальний заголовок: Містить назву секції (Житлове господарство, Благоустрій, Споживчий ринок) та уточнення (рівень виконання звернень громадян).
• Заголовки стовпців:

-                Назва установи. -                Кількість звернень. -       Закриття виконавцем. Стовпець має підрозбивку на три показники:

• вчасно;
• не вчасно;
• не розглянуто.

-       Виконання звернень. Стовпець має підрозбивку на три показники:

• виконано;
• не виконано;
• на перевірці.

-                В роботі -                % вчасно закритих. -       % виконання без урахування продзвону. Підвищення або спад показника відмічається кольором шрифту та спеціальним маркером. -       % достовірності. Підвищення або спад показника відмічається кольором шрифту та спеціальним маркером. -       Індекс швидкості виконання. Підвищення або спад показника відмічається кольором шрифту та спеціальним маркером. -       Індекс фактичного виконання. Підвищення або спад показника відмічається кольором шрифту та спеціальним маркером. -                Рівень виконання. Виділяється жирним шрифтом.

• Заголовки рядків таблиці відображають назву відповідної установи (Районної державної адміністрації або підрозділи районів, що займаються обробкою звернень). Підвищення або спад показника загального рейтингу району відмічається спеціальним маркером.
• Останній рядок таблиці містить сумарний показник за кожним стовпцем. Заголовок: «Всього:».
• Окремо подається графічне представлення рейтингів районів по кожній секції у вигляді графіку динаміки рейтингу по дням тижня.

-           Заголовок: Динаміка РДА по місцях. -           Вертикальна вісь графіку відображає номер місця району у загальному рейтингу (назва осі: Місце), горизонтальна вісь відображає конкретну дату в рамках звітного періоду у форматі рррр-мм-дд. -           Кожен графік динаміки рейтингу для окремої установи. виділяється кольором та маркером. Необхідно передбачити наявність спливаючих підказок при наведенні на елемент у форматі: дата (рррр-мм-дд), назва установи: місце в рейтингу. -           Передбачена можливість друку графіку або його збереження у кількох форматах у пам’яті комп’ютера.

• Окремо подається графічне представлення статистичної інформації по поточній кількості звернень в роботі за установами у вигляді кругової діаграми з відображенням часток та кількості відповідних звернень.

-           Заголовок: Частка по кількості звернень в роботі. -           Інтерактивна легенда діаграми. Відображає назви відповідних установ. При наведенні на елемент на діаграмі виділяється відповідна частка. При натисненні на елемент він включається або виключається з переліку та діаграми. -           Частки на діаграмі та назви установ у легенді маркуються однаковими кольорами. -           При наведенні на частку на діаграмі з’являється спливаюча підказка у форматі: Назва установи. Заявок в роботі: (кількість заявок у роботі). -           Передбачена можливість друку графіку або його збереження у кількох форматах у пам’яті комп’ютера.

1. Звіти по більш детальному рівню представлення показників, що вплинули на виконання звернень за результатами розрахунку рейтингових показників з елементами в розрізі:

• виконавців звернень;
• типів питань.

Звіт допоможе керівнику звернути увагу на підрозділи та типи питань, вирішення яких призвели до погіршення рейтингу району. Звіт надає інформацію про:

• показник вчасності виконання звернень;
• показник виконання звернень;
• показник достовірності виконання звернень;
• місце в рейтингу районів по виконанню питань відповідного типу по:

-           швидкості виконання; -           показнику фактичного виконання звернень.
Графічне представлення звіту. Звіт подається у вигляді таблиць показників по кожній установі за секціями:

1. Житлово-комунальне господарство;
2. Благоустрій;
3. Споживчий ринок.

          За кожною секцією створюється окремий комплекс таблиць за наступними правилами:

• Загальний заголовок: Показники, що вплинули на рівень виконання звернень громадян (назва установи) з питань (назва секції: ЖКГ або благоустрою) за період з (дата: дд.мм.рррр) по (дата: дд.мм.рррр).
• Таблиця 1.
  • Заголовок: Показник вчасності закриття звернень.
  • Заголовки стовпців:
    • ТОП найгірших виконавців. Стовпець має підрозбивку на наступні показники:
    • Виконавець. Назва установи або підрозділу.
    • Надійшло. Загальна кількість звернень.
    • Невчасно закриті. Кількість звернень, що не були вчасно закриті.
    • % вчасності.
    • ТОП проблемних питань. Стовпець має підрозбивку на наступні показники:
    • Питання. Назва питання.
    • Надійшло. Загальна кількість звернень.
    • Невчасно закриті. Кількість звернень, що не були вчасно закриті.
    • % вчасності.

• Таблиця 2.
  • Заголовок: Показник виконання звернень.
  • Заголовки стовпців:
    • ТОП-3 найгірших виконавців. Стовпець має підрозбивку на наступні показники:
    • Виконавець. Назва установи або підрозділу.
    • Надійшло. Загальна кількість звернень.
    • Не виконано. Кількість звернень, що не були виконані.
    • % виконання.
    • ТОП-3 проблемних питань. Стовпець має підрозбивку на наступні показники:
    • Питання. Назва питання.
    • Надійшло. Загальна кількість звернень.
    • Не виконано. Кількість звернень, що не були виконані.
    • % виконання.

• Таблиця 3.
  • Заголовок: Показник достовірності виконання звернень.
  • Заголовки стовпців:
    • ТОП-3 найгірших виконавців. Стовпець має підрозбивку на наступні показники:
    • Виконавець. Назва установи або підрозділу.
    • Перевірено. Загальна кількість перевірених звернень.
    • Не виконано. Кількість звернень, що не були виконані.
    • Не виконано > 1.
    • % достовірності.
    • ТОП-3 проблемних питань. Стовпець має підрозбивку на наступні показники:
    • Питання. Назва питання.
    • Перевірено. Загальна кількість перевірених звернень.
    • Не виконано. Кількість звернень, що не були виконані.
    • Не виконано > 1.
    • % достовірності.

• Таблиця 4.
  • Заголовок: Показник швидкості виконання.
  • Заголовки стовпців:
    • Місце. Відображає місце установи в загальному рейтингу.
    • Кількість питань. Відображає кількість питань за звітний період.

• Таблиця 5.
  • Заголовок: Показник фактичного виконання.
  • Заголовки стовпців:
    • Місце. Відображає місце установи в загальному рейтингу.
    • Кількість питань. Відображає кількість фактично вирішених питань за звітний період.

          Макет сторінки Розшифрування рейтингових показників Рейтингу 1551 приведено на Рис. 24.

Компонент забезпечить інформування керівника районної адміністрації у м. Києві про кількість звернень, що надходять до центральної диспетчерської служби міста 1557 та забезпечить його інструментом для відслідковування динаміки змін даного показника. Буде реалізовано порівняння показників роботи обраного району з іншими районами міста для оцінки роботи житлово-експлуатаційних дільниць керуючої компанії району. Увагу керівника буде звернено на підрозділи з найкращими та найгіршими результатами по виконанню заявок. Буде забезпечено можливість формування друкованої версії звітів у форматі PDF. Компонент включатиме: -       заплановану і фактичну кількість звернень з питань житлово-комунального господарства за останні 7 днів; -       стан роботи ліфтового господарства, а також ліфти, які зупинялися найбільшу кількість раз за останні 7 днів; -       зведену інформація по будинках, за якими було подано максимальну кількість звернень за останні 7 днів; -       статистику за зверненнями на поточний час, а також кількість звернень, які були прострочені виконавцями в розрізі підрозділів керуючої компанії району; -       статистику за часом з'єднання на гарячу лінію 1557 і кількість дзвінків за сьогоднішній день; -       кількість аварій в районі, а також динаміку станом за тиждень, з розбивкою за типами аварій; -       статистику відключень на поточний час по кожній з послуг постачальників; -       порівняння ЖЕДів керуючої компанії по показникам вчасності виконання заявок; -       кількість звернень по питанням за останній тиждень, а також динаміку показників; -       швидкість реакції аварійної служби району на виклики, що були отримані у черговий час.
            Вітрини даних

            Дані представляються у такому вигляді:           Перелік звітів:

1. Звіт порівняння план/факт по кількості звернень за останній тиждень:

• загалом по місту;
• по обраному району;
• по організаціям та підрозділам району, що є виконавцями даних звернень.

Звіт повинен відобразить динаміку отримання звернень по району. Керівник буде мати змогу бачити зміну тенденції в активності мешканців, що звертаються до центральної диспетчерської служби району.
            Графічне представлення звіту по місту та по району:

• Заголовок: Моніторинг звернень 1557.
• Підзаголовок: Загально по Києву (за тиждень) та по окремому району.
• Візуалізація даних:

1)     графіки динаміки кількості звернень по м. Києва до диспетчерської 1557 за звітний період; горизонтальна вісь графіку відображає дні останнього тижня (7 днів). 2)     діаграми динаміки кількості звернень по м. Києву за звітний період; горизонтальна вісь діаграми відображає дні за останній тиждень, а вертикальна вісь відображає кількість звернень.

• Дані відображаються за двома масивами та позначаються кольорами та маркерами:

а) фактична кількість звернень; б) планова кількість звернень..
            Графічне представлення звіту по району:

• Заголовок: Динаміка звернень з питань ЖКГ відповідного району м. Києва.
• Динамічний підзаголовок: Назва району м. Києва. До підзаголовку додається уточнення (за тиждень).
• Візуалізація даних: графіки залежності кількості звернень від конкретного дня тижня; горизонтальна вісь графіку відображає дні тижня, вертикальна вісь – кількість звернень (підпис осі – Кількість звернень).
• Дані відображаються за двома масивами та позначаються кольорами та маркерами:

а) фактична кількість звернень; б) планова кількість звернень.

• Легенда графіку: розшифрування даних, показує, яким кольором та маркерами позначені графіки а) та б).

1. Звіт про стан роботи ліфтового обладнання, ліфти, що зупинялись найбільшу кількість разів за останні 7 днів:

• Вибірка трьох ліфтів, що зупинялись за останні 7 днів найбільшу кількість разів.
• Відомість по всім ліфтам що зупинялись за період.

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

• Заголовок: ТОП 3 проблемних ліфтів (за тиждень). Заголовок виділяється шрифтом, кольором та відповідною іконкою.
• Звіт відображає у вигляді переліку три ліфти, які найчастіше зупинялися за звітний тиждень в порядку зменшення кількості відмов. Формат переліку:
• перший рядок: Адреса ліфту (вулиця, номер будинку, тип ліфта);
• другий рядок: назва керуючої установи, кількість зупинок.

1. 3.  Звіт по будинках, за якими було подано найбільше звернень до диспетчерської служби за останні 7 днів:

• Вибірка трьох будинків за найбільшою кількістю звернень;
• Відомість по всім будинкам, по яких були прийняті звернення за період.

          Звіт відобразить найбільш проблемні будинки району. Звіт дозволить керівнику відслідковувати потенційні проблемні ситуації в районі.
          Графічне представлення звіту:

• Заголовок: ТОП 3 проблемних будинків (за тиждень). Заголовок виділяється шрифтом, кольором та відповідною іконкою.
• Звіт відображає у вигляді переліку три будинки, за якими отримано найбільшу кількість заявок щодо відмов обладнання та проблемних ситуацій за звітний тиждень в порядку зменшення кількості таких заявок. Формат переліку:
• перший рядок: Адреса будинку (вулиця, номер будинку);
• другий рядок: назва керуючого підрозділу, кількість звернень.

1. Звіт по статистиці обробки дзвінків, що поступили на гарячу лінію 1557 з фіксацією середнього часу з’єднання та кількість оброблених дзвінків за поточну добу.

Звіт надасть поточну картину завантаженості лінії диспетчерської служби району за поточну добу. Моніторинг показнику середнього часу з’єднання відобразить час очікування мешканця на лінії диспетчерської служби, а кількість оброблених дзвінків – інтенсивність звернень мешканців за поточну добу. Звіт забезпечить керівника району наступною загальною інформацією: -           середній показник часу з’єднання з оператором контактного центра (в секундах), -           кількість дзвінків за поточну добу.             Графічне представлення звіту:

• Заголовки:
  • Час до з'єднання.
  • Дзвінків за добу.
  • Візуалізація даних: наведені актуальні дані за відповідними пунктами. Для забезпечення зручності використання дані можуть виділятися кольорами або шрифтами.

1. Звіт по статистиці заявок, що знаходяться в роботі та строкам їх виконання на поточний момент.

Звіт надасть інформацію про кількість заявок в роботі та відобразить керівнику району кількість прострочених заявок, регламентний строк виконання яких вийшов. Даний показник впливає на рейтинг району, що ведеться центральною диспетчерською службою 1557.             Звіт повинен забезпечить керівника району наступною загальною інформацією: -           кількість звернень, які знаходяться в обробці, -           кількість прострочених звернень (у процентному та числовому вираженні).
Графічне представлення звіту:

• Заголовки:
  • Звернень в роботі.
  • Звернень прострочено.
  • Візуалізація даних: наведені актуальні дані за відповідними пунктами. Для забезпечення зручності використання дані можуть виділятися кольорами або шрифтами.

1. Звіт по кількості відключених будинків по кожній з комунальних послуг (гаряче та холодне водопостачання, центральне опалення, електропостачання):

• Деталізація по району та по кожній з територій житлово-експлуатаційних дільниць (ЖЕДів).

          Звіт відобразить кількість будинків на території району, що знаходяться без надання комунальних послуг. Динаміка зміни цього показника (відносно даних за вчора) відобразить покращення або погіршення ситуації.           Графічне представлення звіту:

• Заголовок: Кількість будинків без послуг.
• Динамічний підзаголовок: доба представлення (на сьогодні або за вчора).
• Звіт візуалізовано як таблицю з наступними заголовками стовпців:
  • Район / Територія ЖЕДу. по якому наводяться дані.

Заголовки є посиланнями. При натисканні на назву району відкривається деталізований звіт за відповідним районом. При цьому доступ до деталізованої інформації за всіма районами надається користувачам, які мають рівень доступу 0, а користувачі з рівнем доступу 1 або 2 мають доступ до інформації тільки за відповідним підзвітним районом.

• ГВП. Кількість будинків з відключеним гарячим водопостачанням. Заголовок є посиланням на карту ГВП.
• ХВП. Кількість будинків з відключеним холодним водопостачанням.
• ЦО. Кількість будинків з відключеним центральним опаленням. Заголовок є посиланням на карту ЦО.
• Ел. Кількість будинків з відключеним електропостачанням.
• Сумарна кількість відключених будинків за кожною послугою відображається в останньому рядку таблиці. Заголовок: Сумарно.

Останній рядок виділяється шрифтом та має динамічне представлення: -           сумарна кількість відключених будинків (цифрою); -           показник зміни кількості відключених будинків за звітний період (формат: іконка підвищення/спаду кількості (приріст кількості будинків))

1. При кліку на елемент Динаміка відкривається Звіт по кількості аварій по послугах в районі та динаміці зміни їх кількості за тиждень:

• Інформація по кількості аварійних ситуацій в районі по послугах гарячого водопостачання (ГВП), холодного водопостачання (ХВП), центрального опалення (ЦО) та електропостачання.
• Інформація про вчасність виконання даних заявок.

Рис. 26. Прототип елементу динаміки подачі комунальної послуги за останній тиждень


Звіт надасть інформацію про кількість аварійних ситуацій в районі та вчасність їх виконання. Керівник району буде бачити динаміку зміни даного показника за останні 7 днів.
Графічне представлення звіту:

• Заголовок: Аварійні ситуації в місті.
• Візуалізація даних: наведені актуальні дані за кількістю аварійних ситуацій за поточну добу. Формат представлення: (кількість аварійних ситуацій) у відповідний день.
• Динаміка зміни кількості аварій представлена показником зростання/спаду за останні 7 днів.

1. При кліку на елемент, що відображає прострочені заявки, що знаходяться в роботі перейти відбувається перехід до детального звіту по простроченим заявкам. Звіт по статистиці заявок, що знаходяться в роботі в керуючій компанії району та були прострочені виконавцями в тому числі в розрізі виконавців робіт:

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

Рис. 27. Прототип елементу відображення прострочених завдань підрозділів, що відповідають за виконання завдань           Звіт надасть інформацію про вчасність виконання заявок підрозділами керуючої компанії. Звіт відобразить найбільш проблемні житлово-експлуатаційні дільниці, що виконують задачі в позарегламентний строк.
            Графічне представлення звіту:

• Заголовок: Прострочені завдання по підрозділам.
• У вигляді переліку наведені підрозділи з найбільшою кількістю прострочених завдань у порядку зменшення долі таких завдань.

1. Звіт по тематиці питань, що цікавить мешканців за останній тиждень та динаміку зміни цих показників:

• Відобразити тематики питань з найбільшою кількістю звернень з вказуванням динаміки зміни інтересів мешканців до них;
• Відобразити деталізацію по всіх типах питань.

          Звіт надасть інформацію про проблемні питання, що турбують населення району, та показати зміну настроїв населення (які питання їх турбують більше або менше).
            Графічне представлення звіту:

• Заголовок: ТОП тематик звернень з питань ЖКГ.
• У вигляді переліку наведені найбільш популярні тематики звернень у порядку зменшення популярності.
• Повинна бути можливість переходу до більш детального звіту з цих питань, що повинен бути представлений у вигляді реєстру по типах питань.

1. Звіт по швидкості реакції аварійної служби району на виклики, що були отримані в черговий час.

• Інформація про оперативність реакції на аварійні ситуації, що виникли у неробочий час.
• Деталізація по типах звернень та оперативності їх виконання.

          Звіт надасть можливість керівництву моніторити роботу аварійної служби району в розрізі швидкості реакції на аварійні випадки з деталізацією по типах заявок (відсутність холодного водопостачання, відсутність електропостачання в квартирі повністю, порив труби та інші).
Графічне представлення звіту:

• Середній час реакції на аварійні ситуації в залежності від типу.
• Візуалізація моментів отримання заявок та їх виконання на основі тайм-лайну (схематичного відображення періоду часу роботи аварійної служби інтервалами по 30 хвилин). При наявності активної заявки ці періоди необхідно виділити відповідним кольором.
• Загальний перелік заявок, що були в роботі аварійної служби району з деталізацією про тип заявки, час отримання та виконання.

Рис. 29. Звіт по вчасності виконання заявок за минулу добу аварійною службою району

Компонент забезпечить інформування керівника району про результат, отриманий районом в загальноміському рейтингу, що створюється за даними центральної диспетчерської служби 1557. Забезпечить керівника району інформацією з деталізацією по елементах, на основі яких ведеться розрахунок рейтингу та в розрізі підрозділів керуючої компанії району.
          Рейтингові показники та коефіцієнти району по виконанню заявок представити будуть представлені по напрямках: -       Ліквідація аварійних ситуацій в будинку; -       Освітлення місць загального користування; -       Прибирання прибудинкової території; -       Прибирання сходових клітин.
          Перелік додаткових показників та коефіцієнтів, що будуть відображені при відображенні розшифрування отриманого результату ЖЕДу: -       Доля заявок від кількості особових рахунків, що обслуговується ЖЕДом; -       Доля повторних заявок, що надходили після виконання основної заявки; -       Доля виконання заявок в регламентний строк; -       Доля заявок, що залишились на кінець звітного періоду по яких минув регламентний строк виконання.
Рейтингові показники та коефіцієнти відображаються:
-       В середньому по місту; -       По обраному району та місце району в загальноміському рейтингу районів; -       По підрозділам обраного району та місце ЖЕДу в загальноміському рейтингу ЖЕДів.
Графічне представлення звіту. Рис. 30. Прототип сторінки Результати в загальноміському рейтингу ЖЕДів Звіт буде представлений у вигляді таблиць з результатами ЖЕДів в загальноміському рейтингу. Для відображення загального результату рейтингу ЖЕДів необхідно дотримуватися наступного формату таблиці в загальному представленні:
Стовпець 1: Місце ЖЕДу в загальноміському рейтингу та динаміка зміни даного показника з минулого періоду (кількість місць на які змінились показники ) Стовпець 2: Назва району до якого відноситься підрозділ керуючої компанії району. Стовпець 3: Назва ЖЕДу. Назва підрозділу керуючої компанії району. Стовпець 4: Кількість балів, що отримано підрозділом за звітний період. Кількість балів розраховується як сума місць які отримали ЖЕДи по показникам, які оцінюються.
Для порівняння загальних результаті рейтингу ЖЕДів по районах необхідно дотримуватися наступного формату таблиці в загальному представленні: Стовпець 1: Місце Району в загальноміському рейтингу та динаміка зміни даного показника з минулого періоду (кількість місць на які змінились показники ) Стовпець 2: Назва району. Стовпець 3: Середня кількість балів, що отримано підрозділами району за звітний період. Кількість балів розраховується як сума місць які отримали ЖЕДи в результуючому рейтингу поділена на кількість підрозділів, що приймають участь у рейтингуванні. Додаткові розшифрування результатів ЖЕДів по окремих показниках:             Представляється у табличному вигляді з вказуванням: Стовпець 1: Місце ЖЕДу в загальноміському рейтингу та динаміка зміни даного показника з минулого періоду (кількість місць на які змінились показники ) Стовпець 2: Назва району до якого відноситься підрозділ керуючої компанії району. Стовпець 3: Назва ЖЕДу. Назва підрозділу керуючої компанії району. Стовпець 4: Кількість особових рахунків, що обслуговується даним підрозділом. Стовпець 5-7: Розрахункові коефіцієнти згідно з методикою обраховування рейтингу для відображення прибирання сходових клітин:

• Загальна кількість отриманих звернень щодо прибирання сходових клітин в розрахунку на кількість особових рахунків (умовне позначення – К1);
• Кількість невиконаних звернень щодо прибирання сходових клітин в розрахунку на кількість особових рахунків (умовне позначення – К2);
• Кількість звернень з прибирання сходових клітин (неякісне або відсутність) в розрахунку на кількість особових рахунків.

(Умовне позначення: К3 – сума показників К1 та К2). Стовпець 5-7: Розрахункові коефіцієнти згідно з методикою обраховування рейтингу для відображення прибирання прибудинкової території:

• Загальна кількість отриманих звернень щодо прибирання прибудинкової території в розрахунку на кількість особових рахунків (умовне позначення – К4);
• Кількість невиконаних звернень щодо прибирання прибудинкової території в розрахунку на кількість особових рахунків (умовне позначення – К5);
• Кількість звернень з прибирання прибудинкової території (неякісне або відсутність) в розрахунку на кількість особових рахунків.

(Умовне позначення: К6 – сума показників К4 та К5). Стовпець 5-7: Розрахункові коефіцієнти згідно з методикою обраховування рейтингу для відображення усунення аварійних ситуацій:

• Загальна кількість отриманих звернень щодо усунення аварійних ситуацій (умовне позначення – К7);
• Кількість (у відсотках) виконаних в регламентні строки звернень щодо усунення аварійних ситуацій (умовне позначення – К8);
• Відношення кількості звернень з аварійних ситуацій в робочій час до відсотку їх усунення в регламентні терміни.

(умовне позначення: К9 – відношення показників К7 та К8). Стовпець 5-7: Розрахункові коефіцієнти згідно з методикою обраховування рейтингу для відображення освітлення місць загального користування:

• Загальна кількість отриманих звернень щодо освітлення місць загального користування в розрахунку на кількість особових рахунків (умовне позначення – К10);
• Кількість невиконаних звернень щодо освітлення місць загального користування в розрахунку на кількість особових рахунків (умовне позначення – К11);
• Кількість звернень щодо освітлення місць загального користування (неякісне або відсутність) в розрахунку на кількість особових рахунків.

(Умовне позначення: К12 – сума показників К10 та К11). Розрахункові коефіцієнти, що впливають на кінцеві показники рейтингу керуючих компаній та житлово-експлуатаційних дільниць, будуть доступні керівнику району для визначення проблемних зон в обслуговуванні населення.
При переході на більш детальний рівень представлення інформації до рівня показників та коефіцієнтів, що формують рейтингові значення, виводиться реєстр заявок, за яким розраховується результуючий показник рейтингу. Також додатково забезпечується можливість формування друкованої версії звітів у форматі PDF.

            Компонент надасть можливість керівнику району бачити результати роботи компанії, що обслуговує ліфтове обладнання в комунальних будинках району, в загальноміському рейтингу показників роботи ліфтового обладнання. Це дозволить відслідковувати проблемні питання в роботі ліфтового обладнання та приймати рішення для покращення його обслуговування. Перелік показників: -         Простій ліфтового обладнання за звітний період та динаміка його зміни; -         Середній час запуску ліфтів, що зупинились та динаміка його зміни; -         Кількість зупинок ліфтового обладнання на 1 ліфт в обслуговуванні; -         Кількість ліфтів в простої більше доби та динаміка зміни показника.
Показники простою ліфтового обладнання та середнього часу запуску ліфтів дозволяє опосередковано бачити якість та вчасність проведення технічного обслуговування ліфтового обладнання. Показник кількості зупинок – покаже якість обслуговування ліфтового обладнання. Показник кількості ліфтів, що стоять більше доби, відобразить оперативність проведення ремонтів ліфтового обладнання.
Рейтингові показники відображаються: -         В середньому по місту; -         По обраному району та місце району в загальноміському рейтингу районів; -         По територіям ЖЕДів в загальноміському рейтингу ЖЕДів.
При переході на більш детальний рівень представлення інформації виводиться розшифрування елементів з яких формується результуючий показник. Рис. 31. Макет сторінки по Рейтинговим показникам роботи ліфтового обладнання Перелік звітів: 1. Для порівняння загальних результатів рейтингу районів необхідно дотримуватися наступного формату таблиці в загальному представленні: Стовпець 1: Місце Району в загальноміському рейтингу та динаміка зміни даного показника з минулого періоду (кількість місць на які змінились показники ) Стовпець 2: Назва району. Стовпець 3: Кількість ліфтів в обслуговуванні. Стовпець 4: Кількість балів, що отримано районами за звітний період. Кількість балів розраховується за критеріями оцінки. Стовпець 5: Відхилення значення від середнього по місту.
2. Детальний звіт із показниками роботи ліфтового обладнання. Відображає актуальні значення показників по районам. Графічне представлення.       Звіт реалізовано у вигляді таблиці з наступними стовпцями:       Стовпець 1. Назва: Району Містить назву відповідного району м. Києва або житлово-експлуатаційної дільниці.       Стовпець 2. Кількість ліфтів в обслуговуванні.       Стовпець 3.Часовий ресурс, діб на місяць.       Стовпець 4. Простій ліфтового обладнання, діб на місяць.       Стовпець 5. Доля простою ліфтового обладнання.       Стовпець 6. Відхилення від середнього значення по місту.       Стовпець 7. Середній час запуску ліфта (годин).       Стовпець 8. Відхилення від стандартного значення по місту.       Стовпець 9. Кількість зупинок ліфтів за період.       Стовпець 10. Кількість зупинок на один ліфт в обслуговуванні.       Стовпець 11. Відхилення від середнього значення по місту.             Стовпець 12. Кількість ліфтів в простої більше 1 доби.             Стовпець 13. Доля ліфтів в простої від загальної кількості в обслуговуванні.           Сумарні показники відображаються в останньому рядку таблиці.           Заголовок: Разом.           Останній рядок виділяється шрифтом.

1. 3.  Реєстр заявок. Містить інформацію по простою ліфтів, що зафіксований за даними центральної диспетчерської служби м. Києва 1557. Доступ до інформації у реєстрі заявок надається згідно присвоєного користувачу рівня доступу та обраного напрямку.

Графічне представлення. Реєстр заявок реалізовано у вигляді таблиці з наступними стовпцями: Стовпець 1. Назва: Району Стовпець 2. Назва: Балансоутримувач. Містить назву житлово-експлуатаційної дільниці, що відповідає за дане ліфтове обладнання. Стовпець 3. Назва: Місце. Містить назву ліфту. Стовпець 4. Назва: Виконавець. Містить найменування виконавця. Стовпець 5. Назва: Номер заявки. Містить реєстраційний номер відповідної заявки. Стовпець 6. Назва: Статус заявки. Містить поточний статус виконання робіт по заявці. Стовпець 7. Назва: Тип заявки. Містить назву відповідного типу заявки або короткий опис ситуації. Стовпець 8. Назва: Дата початку робіт. Містить фактичну дату початку робіт по заявці. Формат: рррр-мм-дд гг:хх:сс. Стовпець 9. Назва: Планова дата виконання. Містить планову дату виконання робіт по заявці. Формат: рррр-мм-дд гг:хх:сс. Стовпець 10. Назва: Коментар по заявці. Містить короткий коментар по заявці у довільному форматі. Стовпець 11. Назва: Резолюція. Містить коротку резолюцію по заявці у довільному форматі.

            Компонент відображає проблематику подачі комунальних послуг в багатоквартирні будинки району, застосовуючи інтеграцію з картографічним ресурсом ІАС “МАЙНО”. Будинки, у яких відсутня подача послуг, або які мають проблеми з наданням послуг, виділяються особливим чином в залежності від тривалості проблемної ситуації та характеру проблеми. Статистичні показники, що представляються у різних зрізах, розкривають деталі проблемних ситуацій та дозволяють керівнику бути проінформованим про процес їх вирішення.   Компонент включатиме: -       Відображення належної подачі комунальних послуг до будинків району. При наявності в поточний момент проблеми з подачею послуги до будинку, він позначається відповідною позначкою. При наведенні на позначку у вікні, що виринає, відображається інформацію про тривалість та причину події, планову дату її вирішення, а також відповідальну організацію.
Представляються послуги:

• гарячого водопостачання:

-         Відсутність послуги; -         Недостатня якість постачання послуги.

• холодного водопостачання:

-         Відсутність послуги; -         Недостатня якість постачання послуги.

• центрального опалення:

-         Включення послуги (на початку опалювального сезону); -         Відсутність послуги; -         Недостатня якість постачання послуги.

• електропостачання – відсутність послуги.

Інформація подається в розрізі тривалості існування проблеми з вказуванням при кліку на позначку:

• тривалості аварійної ситуації;
• місця виникнення проблеми;
• планових термінів її вирішення;
• організації, що займається вирішенням даної проблеми.

-       Статистику по будинках, в яких наявні проблеми в подачі комунальних послуг; -       Статистику по будинках, в яких комунальні послуги подаються недостатньої якості (занижений тиск, недостатня температура, тощо); -       Статистику по тривалості виконання робіт; -       Динаміку зміни кількості будинків без послуги або з недостатньою якістю послуги; -       Статистику по відсутності послуги в розрізі виконавців робіт.
         Графічне представлення звіту. Рис. 32. Макет представлення даних по подачі комунальних послуг до будинків району

1. Звіт що відображає подачу послуг до будинків міста.

Графічне представлення звіту. Звіт візуалізовано як таблицю з наступними заголовками стовпців:

• Район / Територія ЖЕДу. по якому наводяться дані.
• Заголовки є посиланнями. При натисканні на назву району відкривається деталізований звіт за відповідним районом. При цьому доступ до деталізованої інформації за всіма районами надається користувачам, які мають рівень доступу 0, а користувачі з рівнем доступу 1 або 2 мають доступ до інформації тільки за відповідним підзвітним районом.
• ГВП. Кількість будинків з відключеним гарячим водопостачанням. Заголовок є посиланням на карту ГВП.
• ХВП. Кількість будинків з відключеним холодним водопостачанням.
• ЦО. Кількість будинків з відключеним центральним опаленням. Заголовок є посиланням на карту ЦО.
• Ел. Кількість будинків з відключеним електропостачанням.
• Сумарна кількість відключених будинків за кожною послугою відображається в останньому рядку таблиці. Заголовок: Сумарно.
• Останній рядок виділяється шрифтом та має динамічне представлення:
  • сумарна кількість відключених будинків (цифрою);
  • показник зміни кількості відключених будинків за звітний період (формат: іконка підвищення/спаду кількості (приріст кількості будинків).

1. Позначення аварійно відключених та планово відключених будинків на інтерактивній карті м. Києва. Якщо в будинку наявні проблеми в подачі комунальних послуг, він маркується на карті спеціальною позначкою відповідного кольору:

• червоний – для аварійно відключених будинків;
• жовтий – для планово відключених будинків.

Рис. 33. Макет повідомлення, що з’являється при натисненні на маркер на інтерактивній карті При наведенні на маркер з’являється спливаюче вікно з коротким повідомленням про поточний стан будинку (Повідомлення: «відключено аварійно» або «відключено планово»). При натисненні на маркер (одне натискання кнопкою миші) з’являється спливаюче вікно з розвернутим повідомленням про поточний стан будинку. Формат повідомлення:

• Будинок (поточний стан будинку: «Аварія» або «Планові»).
• Адреса: (адреса будинку у форматі: вул., номер будинку).
• Номер заявки: (номер заявки на відключення будинку).
• Аварійних будинків по даній заявці: (кількість будинків, відключених по поточній заявці).
• Тип заявки: (назва послуги (опис поточної ситуації) – опис причини, що призвела до відключення).
• Місце аварії: (Назва аварійного обладнання, серійний номер (адреса місцезнаходження об’єкта).
• Діапазон дат в рамках яких діє поточна подія в форматі Дата 1 – Дата 2.
• Кількість годин або днів, що залишилась до закінчення заявки.
• Виконавець: (офіційна назва компанії, що виконує роботи по заявці).

1. Інформаційна панель, яка відображає загальну кількість по місту:

• будинків без проблем;
• аварійно відключених будинків;
• планово відключених будинків.

                     Інформація подається у такому вигляді:

• Будинки без проблем. Вказується кількість будинків без поточних проблем, виділена зеленим кольором.
• Відключено планово. Вказується кількість планово відключених будинків, виділена жовтим кольором. Представляється розподілення даного показника по строкам проблеми.
• Відключено аварійно. Вказується кількість аварійно відключених будинків, виділена червоним кольором. Представляється розподілення даного показника по строкам проблеми.

1. Діаграма динаміки подачі комунальних послуг до будинків (по районах).

          Візуалізація даних: лінійна діаграма кількості будинків з проблемами постачання комунальної послуги за обраним районом (по горизонтальній осі – періоди часу за три останні доби, по вертикальній – кількість будинків без послуги).

1. Звіт із інформацією про поточну кількість аварійних будинків в розрізі організацій-виконавців робіт.

          Звіт візуалізовано у вигляді таблиці з наступними стовпцями:

• Організація. Назви організацій, що надають відповідні комунальні послуги. При натисканні на заголовок відбувається сортування даних за назвою організації.
• Кількість аварій. Кількість на поточний час аварійних ситуацій, що відносяться до відповідної організації. При натисканні на заголовок відбувається сортування даних за значенням.
• Кількість будинків. Поточна кількість будинків з відключеною послугою. При натисканні на заголовок відбувається сортування даних за значенням.

Компонент відобразить проблематику в роботі ліфтового обладнання в режимі реального часу, застосовуючи інтеграцію з картографічним ресурсом ІАС “МАЙНО”. Будинки, у яких ліфти знаходяться у неробочому стані, в залежності від тривалості зупинки та виду проблеми позначені позначками відповідного кольору. Статистичні показники, що представляються у різних зрізах, розкривають деталі проблемних ситуацій та дозволяють керівнику бути проінформованим про процес їх вирішення.
Компонент включає: -       Візуальне відображення для моніторингу роботи ліфтового обладнання в районі. При наявності в поточний момент проблеми з роботою ліфту, необхідно він позначається відповідною позначкою. При наведенні на позначку у вікні, що виринає, відображається інформація про тривалість та причину події, планову дату її вирішення, а також відповідальну організацію. Відображення інформації про простій ліфтового обладнання  реалізується в розрізі тривалості простою з вказуванням:

• Тривалості простою;
• Причини простою;
• Відповідальної організації.

-       Статистику по тривалості простою ліфтового обладнання на поточний момент; -       Статистику про кількість парадних, де не працює жодний з ліфтів; -       Статистику по частоті зупинок ліфтового обладнання за останні 7 днів; -       Статистику по проблематиці розкрадання ліфтового обладнання – кількість ліфтів, що простоює з відповідною причиною розкрадання обладнання. Графічне представлення звіту. Аналогічне постачанню комунальних послуг до будинків.

1. Позначення будинків з проблемними ліфтами на інтерактивній карті м. Києва. Якщо в будинку наявні проблеми щодо роботи ліфтового обладнання, він маркується на карті спеціальною позначкою відповідного кольору:

-         червоний – для аварійних ситуацій; -         жовтий – для планових робіт. При наведенні на маркер з’являється спливаюче вікно з коротким повідомленням про поточний стан ліфтового обладнання (Повідомлення: «зупинка аварійна» або «зупинка планова»). При натисненні на маркер (одне натискання кнопкою миші) з’являється спливаюче вікно з розвернутим повідомленням про поточний стан ліфтового обладнання в будинку.          Формат повідомлення: -    Ліфтове обладнання (поточний стан ліфтового обладнання: «відключено аварійно» або «відключено планово»). -    Адреса: (адреса будинку у форматі: вул., номер будинку). -    Балансоутримувач: (назва житлово-експлуатаційної контори). -    Номер заявки: (номер заявки на проведення робіт). -    Тип заявки: (опис поточної ситуації). -    Годин простою: (кількість годин, протягом яких не працює ліфтове обладнання, з точністю до другого знаку після коми). -    Планова дата закриття заявки: (дата у форматі рррр-мм-дд гг-хх-сс). -    Виконавець: (офіційна назва компанії, що виконує роботи по заявці).

1. Інформаційна панель, яка відображає загальну по місту або району:

-    тривалість простою ліфтового обладнання на поточний момент; -    кількість парадних, де не працює жодний з ліфтів; -    частоту зупинок ліфтового обладнання за останні 7 днів; Інформація подається у вигляді таблиці. Заголовки таблиці:

• Простій ліфтового обладнання. Вказується загальна годин простою ліфтового обладнання по місту, виділена відповідним кольором.
• Кількість парадних, де не працюють ліфти. Вказується кількість парадних, де не працює жодний з ліфтів, виділена відповідним кольором.
• Частота зупинок ліфтового обладнання (за тиждень). Вказується загальна кількість зупинок ліфтового обладнання по місту за останні 7 днів, виділена відповідним кольором.

1. Діаграма поточного стану ліфтового обладнання.

Заголовок: Робота ліфтового обладнання. Динамічний підзаголовок: Назва району м. Києва.             Візуалізація даних: стовпчаста діаграма кількості непрацюючих ліфтів за кожним районом (підпис осі – кількість звернень). Кожен стовпець представляє кількість по району: -         будинків з працюючими ліфтами (зелений стовпець, назва: Будинки без проблем); -         будинків, в яких проводиться планове обслуговування ліфтів (жовтий стовпець, назва: Відключено планово); -         будинків, в яких не працюють ліфти внаслідок аварії (червоний стовпець, назва: Відключено аварійно).             При наведенні на стовпець з’являється спливаюче вікно з повідомленням про поточний стан ліфтового обладнання (Повідомлення: стан ліфтового обладнання: (поточна кількість непрацюючих ліфтів).

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

Звіт візуалізовано у вигляді таблиці з наступними стовпцями:

• Заголовок: Організація.

Назви організацій, що відповідають за ліфтове обладнання. При натисканні на заголовок відбувається сортування даних за назвою організації.

• Кількість аварій.

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

• Кількість ліфтів, що простоює через розкрадання обладнання.       

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

Компонент супроводжує процес запуску опалювального сезону та візуально відображає позначками різного кольору готовність будинків району до опалювального сезону, процес підключення будинків до централізованого опалення та відслідковування аварійних ситуацій на інфраструктурних об’єктах та локальних проблемних ситуацій, пов’язаних з заповітреністю внутрішньобудинкових систем опалення. Для відображення використовується інтеграція з картографічним ресурсом ІАС “МАЙНО”. Динаміка зміни цих показників дозволить керівнику району бачити прогрес даних робіт.
Компонент включатиме:
-       Візуальне відображення будинків для моніторингу підключення будинків району до системи централізованого опалення.

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

-       Статистику по готовності будинків до старту опалювального сезону. З відображенням долі готовності будинків до опалювального сезону. -       Статистику по підключенню будинків до системи централізованого опалення під час запуску опалювального сезону. -       Інформацію про кількість скарг на відсутність та недостатню якість централізованого опалення. -       Статистику по будинках району, які мають скарги на недостатню температуру опалення. -       Статистику по будинках району, в яких опалення відсутнє у зв’язку з аварією.
Графічне представлення звіту
Аналогічне подачі комунальних послуг в будинки з додатковою інформацією у вигляді: Інформаційна панель відображає Кількість будинків та долю будинків від загальної кількості будинків:

• ЦО запущено;
• ЦО не запущено;
• Будинків, де немає проблем в подачі ЦО;
• З аварійними відключеннями на інфраструктурних об’єктах;
• З точковими проблемами в будинку.

Рис. 36. Макет блоку даних по відображенню актуального стану  запуску центрального опалення в будинки Динаміка зміни даних показників за останні 3 дні Перелік організацій з найбільшою кількістю аварійних випадків та кількість будинків, що відключені від послуги ЦО на даний момент.
Передбачена можливість перейти до більш детального звіту по запуску центрального опалення. 4 сегменти даних представлені в окремих таблицях. Кожна з них може супроводжуватись динамікою зміни показників:

• Запуск центрального опалення в будинки;
• Будинки без проблем з подачею центрального опалення;
• Будинки з аварійними відключеннями на інфраструктурних об’єктах;
• Будинки з точковими проблемами в будинку.

Кожний з елементів буде містити розшифрування значень показників, що сформували кінцеві значення. Рис. 37. Макет детального звіту актуального запуску опалювального сезону

1. Відображення будинків на інтерактивній карті м. Києва для моніторингу підключення будинків району до системи централізованого опалення.

Доступні 3 варіанти інтерактивної карти, які відображають стан системи центрального опалення за наступними періодами: -       Запуск системи центрального опалення; -       Відключення системи центрального опалення (в тому числі планове та аварійне); -       Поточний стан системи центрального опалення протягом року. Якщо в будинку наявні проблеми або аварійний стан системи центрального опалення (ЦО), він маркується на карті спеціальною позначкою відповідного кольору: -         червоний – для відключених будинків з причини аварії або планових робіт; -         жовтий – для будинків, де наявні точкові проблеми з заповітреністю стояків центрального опалення; При наведенні на маркер з’являється спливаюче вікно з коротким повідомленням про поточний стан системи ЦО будинку. При натисненні на маркер (одне натискання кнопкою миші) з’являється спливаюче вікно з розвернутим повідомленням про поточний стан системи ЦО будинку. Формат повідомлення: -    Будинок (поточний стан системи ЦО будинку: «аварійне» або «точкове»). -    Адреса: (адреса будинку у форматі: вул., номер будинку). -    Балансоутримувач: (назва житлово-експлуатаційної контори). -    Номер заявки: (номер заявки (заявок) на проведення робіт). -    Тип заявки: (назва послуги (опис поточної ситуації)). -    Місце аварії, якщо це відключення: (Назва аварійного обладнання, серійний номер (адреса місцезнаходження об’єкта). -    Днів на аварії: (кількість днів, протягом яких будинок відключений від послуги, з точністю до другого знаку після коми). -    Планова дата закриття заявки: (дата у форматі рррр-мм-дд гг-хх-сс). -    Виконавець: (офіційна назва компанії, що виконує роботи по заявці).

1. Інформаційна панель, яка відображає загальну кількість по місту та по районам:

-         підключених до ЦО будинків; -         будинків, що мають проблеми з системою ЦО; -         аварійно відключених від ЦО будинків.          Інформація подається у вигляді таблиці.          Заголовки таблиці:

• Підключені будинки. Вказується кількість підключених до ЦО будинків, виділена зеленим кольором.
• Будинки з проблемами. Вказується кількість будинків, що мають проблеми в системі ЦО, виділена жовтим кольором.
• Відключено аварійно. Вказується кількість аварійно відключених від ЦО будинків, виділена червоним кольором.

1. Звіт із інформацією про поточну кількість будинків з аварійною системою ЦО в розрізі організацій.

Звіт візуалізовано у вигляді таблиці з наступними стовпцями:

• Заголовок: Організація. Назви організацій, що надають ЦО. При натисканні на заголовок відбувається сортування даних за назвою організації.
• Кількість аварій. Кількість на поточний час аварійних ситуацій системи ЦО, що відносяться до відповідної організації. При натисканні на заголовок відбувається сортування даних за значенням.
• Кількість будинків. Поточна кількість будинків з відключеною послугою ЦО. При натисканні на заголовок відбувається сортування даних за значенням.

Компонент надасть керівнику району інформацію про реальний випуск транспортних засобів на маршрути в порівнянні з планом, що був запланований підприємством. Це дозволить розуміти поточну проблематику в перевезенні пасажирів громадським транспортом, що спричинена не виїздом на маршрути відповідних транспортних засобів.
-       Інформування про план/факт випуску громадського транспорту на маршрути. Для всіх маршрутів громадського транспорту, що переміщуються по території районів міста Києва. -       Статистика по виїзду на маршрути по типах громадського транспорту:

• автобусів;
• тролейбусів;
• трамваїв.

-       Групування інформації по:

• автобусних, тролейбусних та трамвайних депо;
• та по окремих маршрутах.

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

1. Інформаційна панель, яка відображає планову та фактичну кількість випуску транспорту на маршрути (загальна кількість автобусів, трамваїв та тролейбусів).

Заголовки:

• План. Вказується планова кількість транспорту, який повинний був виїхати на маршрути.
• Не виїхало. Вказується фактична кількість транспорту, який не виїхав на маршрути.

1. Інформаційна панель, яка відображає деталізацію планової та фактичної кількості випуску транспорту на маршрути за типами транспортних засобів: автобус, трамвай, тролейбус.

• іконка, яка позначає відповідний вид транспорту (автобус, трамвай, тролейбус) з буквеним уточненням (А, Т, Тр відповідно);
• планова кількість випуску на маршрути транспортних одиниць кожного типу;
• символ розділення інформації (слеш);
• кількість транспортних одиниць кожного типу, які не виїхали на маршрути (число червоного кольору).

При натисненні на відповідну іконку позначення транспортного засобу відбувається перехід на деталізацію за даним типом (див.п.6).

1. Графік динаміки випуску транспортних одиниць кожного типу за звітний період (28 днів).

Вертикальна вісь графіку відображає фактичну кількість транспортних одиниць кожного типу, які виїхали на маршрути (підпис осі: Кількість). Горизонтальна вісь графіку представляє дні звітного періоду (підпис осі: дата у форматі дд-мм-рррр). Легенда графіку: відображає, динаміку якого типу транспорту (А, Т, Тр) ілюструє графік.

1. Кругова діаграма, що відображає причини невиїзду транспорту на маршрути.

Інформація візуалізується у вигляді кругової діаграми, сектори якої відповідають кількості транспортних засобів, що не виїхали з певної причини, а саме:

• Експлуатаційні
• Технічні
• Розпорядження керівника
• Відсутність водія
• Вина водія
• Інші

Легенда діаграми відповідає переліку причин невиїзду. Кольори секторів діаграми та шрифтів легенди узгоджені.

1. Графік динаміки причин невиїзду транспортних одиниць.

Заголовок: Динаміка причин невиїзду. Вертикальна вісь графіку відображає фактичну загальну кількість транспортних одиниць, які не виїхали на маршрути з певних причин (підпис осі: Кількість). Горизонтальна вісь графіку представляє дні звітного періоду (підпис осі: дата у форматі дд-мм-рррр). Легенда графіку: відображає причини невиїзду, динаміку яких ілюструє графік.

1. Інформаційна панель, яка відображає планову та фактичну кількість випуску транспорту кожного відповідного типу на маршрути (кількість автобусів, трамваїв або тролейбусів).

Заголовок панелі: Випуск (відповідний тип транспорту: автобусів/трамваїв/тролейбусів). Звіт має аналогічну структуру, проте представлені дані по відповідному типу транспорту в розрізі парків або депо.

1.  Реєстр випуску на маршрути транспорту по кожному з АТП або депо.

Представлений у вигляді таблиці. Заголовок таблиці: Випуск (тип транспорту – автобусів, трамваїв, тролейбусів) на лінію по маршрутам (назва АТП або депо). Заголовки стовпців:

• Номер. Номер маршруту.
• План. Планова кількість певного типу транспортних засобів, що мав виїхати на даний маршрут.
• Факт. Фактична кількість певного типу транспортних засобів, що виїхав на даний маршрут.
• КВп %. Коефіцієнт випуску. Відношення планової кількості до фактичної кількості, вказується у відсотках.
• Причина невиїзду:

-       Експлуатаційна -       Технічна -       Розпорядження керівника -       Відсутність водія -       Вина водія -       Інша
Останній рядок підсумовує кількість за кожним стовпцем, назва рядку: Разом.

ПЗ стеку технологій: -         FrontEnd:

• Angular 2
• Bootstrap
• NodeJS
• Highcharts
• Google.Maps
• Програмний комплекс ІАС МАЙНО

-         BackEnd:

• Microsoft Internet Information Services 7.5
• .Net Framework 4.6.1
• ASP.Net

-         СКБД:

• Microsoft SQL Server 2012 Enterprise Edition

-         Операційні системи

• Microsoft Windows Server 2012 R2;

-         Http та Https проксі сервер

• Nginx

-         IDE для налаштування та підтримки

• Microsoft Internet Information Services 7.5 Manager
• Microsoft SQL Server Data Tools
• Microsoft SQL Management Studio

Розширення функціональності ІТС “Звітність” не вимагає додаткового збільшення обчислювальних потужностей і може функціонувати на наявних ресурсах, а саме:
-         Сервер додатків:

• CPU – 2 ядра
• RAM – 4 Gb

-         Сервер баз даних:

• CPU – 6 ядер
• RAM – 16 Gb
• HDD – 500 Gb

-         А ресурс для сервера обробки автентифікації ЕЦП:

• CPU – 4 ядра
• RAM – 8 Gb
• HDD – 100 Gb.

Відповідно до структури рішення, а також враховуючи наявність двох середовищ (основного та резервного), буде використовуватися існуюча схема розміщення компонентів Системи, без додавання нових компонентів: Рис. 39. Схема розміщення компонентів проекту на серверному обладнанні

В ході виконання проекту на об’єкті автоматизації вимагається виконати роботи з підготовлення до введення Системи в дію. З метою забезпечення підготовленості об’єкта автоматизації до введення Системи в дію потрібно провести: –        погодження з Замовником переліку вхідної та вихідної інформації, яка буде надходити в Систему і оброблятися з застосуванням ЕОМ; –        навчання персоналу Замовника, яке проводиться за графіком, що розробляється Виконавцем та погоджується Замовником; –        роботи із забезпечення обладнання всіх робочих приміщень, де планується встановлення обладнання Системи відповідно до вимог технічного завдання; –        забезпечити відповідність комп’ютерного обладнання, на якому має розгортатися Система, технічним вимогам, що гарантують працездатність програмного забезпечення, згідно з технічним завданням; –        заходи щодо розгортання системи захисту інформації в місцях встановлення обладнання ІТС “Звітність” .

Порядок контролю і приймання Системи повинен відповідати етапам, наведеним у таблиці вище.

Виконавець забезпечує гарантійну (технічну) підтримку створеного в результаті надання послуг програмного забезпечення протягом 12 місяців з дати підписання Акту приймання-передачі наданих послуг по останньому етапу згідно Календарного плану. Під гарантійною підтримкою розуміється зобов’язання Виконавця безоплатно підтримувати розроблене програмне забезпечення, виправляти виявлені помилки і адаптувати програмне забезпечення до нових версій СКБД.
rest_documentconversion_latest_conversion_thumbnail_32310127_1