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

ЗМІСТ
Стор.
Терміни, визначення та скорочення
1. ПРИЗНАЧЕННЯ СИСТЕМИ
1.1 Вид діяльності, для автоматизації якої призначена система
1.2 Повне найменування послуги та умовне позначення
1.3 Найменування організацій Замовника і Виконавця, їх реквізити
1.4 Перелік документів, на підставі яких модернізується ЄІАС "CRM-1551", ким і коли затверджені ці документи
1.5 Призначення Системи
1.6 Мета і завдання модернізації Системи
1.7 Перелік об'єктів автоматизації, з якими інтегрується Система
1.8 Перелік функцій, реалізованих Системою
1.9 Нормативні посилання
2 ОПИС СИСТЕМИ
2.1 Загальний опис архітектури та основних функцій системи
2.2 Відомості про налаштування Системи, необхідні для забезпечення її експлуатації
2.3 Загальний опис бізнес-процесів Системи
2.3.1 Основний бізнес-процес прийняття та обробки звернення від громадянина
2.3.2 Загальний бізнес-процес прийому та обробки дзвінка Оператором
2.3.3 Бізнес-процес реєстрації питання за дзвінком
2.3.4 Бізнес-процес реєстрації консультації за дзвінком (тип консультації "Консультація за системою "Городок")
2.3.5 Бізнес-процес реєстрації консультації за дзвінком (тип консультації "Консультація за Заходом")
2.3.6 Бізнес-процес реєстрації консультації за дзвінком (тип консультації "Консультація за Базою Знань (БЗ)"
2.3.7 Бізнес-процес реєстрації консультації за дзвінком (тип консультації "Консультація за питанням")
2.3.8 Бізнес-процес реєстрації питання за консультацією
2.3.9 Бізнес-процес реєстрації закриття питання за запитом заявника
2.3.10 Загальний бізнес-процес роботи з дорученнями Керівника виконавців
2.3.11 Загальний бізнес-процес розгляду доручень Виконавцем
2.3.12 Загальний бізнес-процес роботи Координатора-контролера
2.3.13 Загальний бізнес-процес роботи Менеджера району
2.3.14 Загальний бізнес-процес роботи Власника
2.4 Опис функціонування підсистем ЄІАС "CRM-1551"
2.4.1 Підсистема "Реєстрація та опрацювання звернень громадян"
2.4.2 Підсистема "Пошук інформації"
2.4.3 Підсистема "Проведення опитувань"
2.4.4 Підсистема "Перегляд інформації про аварійні та планові роботи"
2.4.5 Підсистема "Адміністрування баз даних і системи"
2.4.6 Підсистема "Інтеграція з системою телефонії"
2.4.7 Підсистема "Аудіоінформування"
2.4.8 Підсистема "Захист інформації"
2.5 Отримання даних по API
2.5.1 Отримання авторизаційного токену для підключення до Системи
2.5.2 Прийом даних по API з сайту 1551 та мобільних додатків
2.5.3 Прийом даних по API з системи ЕОСЖКГ
2.6 Структура таблиць даних ЄІАС "CRM-1551"
2.7 Склад інтерфейсу системи в залежності від ролі Користувача
2.8 Довідники
2.9 Режими функціонування ЄІАС "CRM-1551"
3 Вимоги до умов розгортання та обслуговування модернізованої системи ЄІАС "CRM-1551"
3.1 Загальні вимоги
3.2 Чисельність та кваліфікація персоналу ЄІАС "CRM-1551" та режим його роботи
3.3 Загальні вимоги до організаційної структури для розгортання та експлуатації ЄІАС "CRM-1551"
3.3.1 Рекомендації до підрозділів з експлуатації, адміністрування та ведення ЦБД ЄІАС "CRM-1551"
3.4 Склад комплексу технічних засобів
3.4.1 Основні компоненти комплексу технічних засобів
3.4.2 Технічні засоби сервера Системи
3.4.3 Базовий набір технічних засобів робочих станцій
4 ОПИС ВЗАЄМОЗВ'ЯЗКІВ СИСТЕМИ З ІНШИМИ СИСТЕМАМИ
4.1 Загальні вимоги
4.2 Інтеграція даних
4.3 Способи і засоби зв'язку для інформаційного обміну між компонентами та підсистемами
5 ЗАХОДИ по ПІДГОТОВці ОБ'ЄКТА АВТОМАТИЗАЦІЇ ДО ВВЕДЕННЯ СИСТЕМИ В ДІЮ
5.1 Заходи по підготовці інформаційної бази
5.2 Заходи по підготовці персоналу
5.3 Заходи по організації необхідних підрозділів та робочих місць
5.4 Заходи щодо підготовки об'єкту автоматизації
СПИСОК ТАБЛИЦЬ
СПИСОК РИСУНКІВ
ЛИСТ РЕЄСТРАЦІЇ ЗМІН

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

Найменування послуги:
Модернізація та функціональне розширення програмно-технічного комплексу інформаційно-довідкової служби Call-центр, супроводження програмно-апаратного комплексу інформаційно-довідкової служби Call-центр, забезпечення безперервного доступу структурних підрозділів виконавчого органу Київської міської ради (Київської міської державної адміністрації), районних в м. Києві державних адміністрацій та комунальних підприємств до інформаційно-довідкової служби Call-центр.
Умовне позначення: ЄІАС “CRM-1551” або Система.

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

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

• Рішення Київської міської ради від 2 липня 2015 року № 654/1518 “Про затвердження Комплексної міської цільової програми “Електронна столиця” на 2015-2018 роки”;
• Рішення Київської міської ради від 28 липня 2016 року N 862/862 “Про внесення змін до Комплексної міської цільової програми “Електронна столиця” на 2015-2018 роки”, затвердженої рішенням Київської міської ради від 02 липня 2015 року № 654/1518;
• Договір від 27 серпня 2018 року №4440 про надання послуг.

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

• впроваджено модуль на базі CallWay CRM;
• автоматизовано основні бізнес-процеси на основі використання “оперативного” CRM-підходу.

Мета даного проекту − підвищення швидкості та якості прийому, реєстрації та обробки звернень. Для досягнення вказаної мети у даному проекті реалізовано модернізовану програмну платформу ЄІАС “CRM-1551”, яка дозволяє щонайменше, ніж на 20% підвищити швидкість та ефективність прийому й обробки звернень від громадян, які телефонують до комунальної бюджетної установи “Контактний центр міста Києва”.
Завданнями модернізації програмної платформи ЄІАС “CRM-1551” є: <HTML><ul></HTML> <HTML><li></HTML>збільшення кількості викликів, що обробляються одночасно (до 2500 задіяних користувачів);<HTML></li></HTML> <HTML><li></HTML>автоматизація основних бізнес-процесів системи для підвищення ефективності роботи;<HTML></li></HTML> <HTML><li></HTML>забезпечення користувачів системи всією необхідною, а також додатковою інформацією;<HTML></li></HTML> <HTML><li></HTML>надання аналітичних даних щодо роботи об'єктів господарювання;<HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>забезпечення можливості майбутнього масштабування системи, її модернізації та подальшого вдосконалення.<HTML></p></HTML>

<HTML><p></HTML>ЄІАС “CRM-1551” інтегрується з такими системами та підсистемами:<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML>єдиний веб-портал Контактного центру міста Києва 15-51;<HTML></li></HTML> <HTML><li></HTML>підсистема “Адміністрування баз даних і системи”;<HTML></li></HTML> <HTML><li></HTML>підсистема “Аудіоінформування”;<HTML></li></HTML> <HTML><li></HTML>підсистема “Захист інформації”;<HTML></li></HTML> <HTML><li></HTML>підсистема “Інтеграція з системою телефонії”;<HTML></li></HTML> <HTML><li></HTML>підсистема “Перегляд інформації про аварійні та планові роботи”;<HTML></li></HTML> <HTML><li></HTML>підсистема “Проведення опитувань”;<HTML></li></HTML> <HTML><li></HTML>підсистема “Пошук інформації”;<HTML></li></HTML> <HTML><li></HTML>підсистема “Реєстрація та опрацювання звернень громадян”;<HTML></li></HTML> <HTML><li></HTML>система електронних поштових сервісів;<HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>єдине сховище даних та супровідної інформації.<HTML></p></HTML>

<HTML><p></HTML>Модернізована ЄІАС “CRM-1551” на базі “CallWay CRM” реалізує такі функції:<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML>забезпечення роботи зі створеною віртуальною структурою підрозділів Київради та комунальних підприємств;<HTML></li></HTML> <HTML><li></HTML>забезпечення автоматизації бізнес-процесів у системі;<HTML></li></HTML> <HTML><li></HTML>інтеграція з допоміжними системами та підсистемами, зокрема з «Єдиним веб-порталом Контактного центру міста Києва»;<HTML></li></HTML> <HTML><li></HTML>створення єдиного сховища даних та супровідної інформації;<HTML></li></HTML> <HTML><li></HTML>розмежування доступу до функцій системи для різних ролей користувачів;<HTML></li></HTML> <HTML><li></HTML>забезпечення зручного та швидкого пошуку інформації у базі даних;<HTML></li></HTML> <HTML><li></HTML>забезпечення інструменту створення маршрутизації заявок;<HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>надання звітної інформації в зручній формі.<HTML></p></HTML>

<HTML><p></HTML>Даний проект модернізації ЄІАС “CRM-1551” реалізований із дотриманням вимог нормативно-правових актів:
Закону України “Про інформацію”;
Закону України “Про звернення громадян”;
Закону України “Про електронні документи та електронний документообіг”;
Закону України “Про доступ до публічної інформації”;
Закону України “Про захист інформації в інформаційно-телекомунікаційних системах”;
Закону України “Про захист персональних даних”;
Постанови Кабінету Міністрів України від 18 січня 2012 року № 21 “Про затвердження Положення про Національну систему опрацювання звернень до органів виконавчої влади та Типового положення про контактний центр Автономної Республіки Крим, області, міст Києва і Севастополя”;
Положення про Національну систему опрацювання звернень до органів виконавчої влади;
Положення про комунальну бюджетну установу “Контактний центр міста Києва”;
Типове положення про контактний центр Автономної Республіки Крим, області, міст Києва і Севастополя; 
Рішення Київської міської ради від 16 лютого 2012 року № 93/7430  Про утворення комунальної бюджетної установи “Контактний центр міста Києва”;
Розпорядження від 5 квітня 2012 року № 555 Про організаційно-правові заходи щодо утворення комунальної бюджетної установи “Контактний центр міста Києва”;
Указу Президента України № 109/2008 “Про першочергові заходи щодо забезпечення реалізації та гарантування конституційного права на звернення до органів державної влади та органів місцевого самоврядування”;
Постанови Кабінету Міністрів України “Про організацію особистого прийому громадян у Кабінеті Міністрів України”;
Постанови Кабінету Міністрів України “Про затвердження Інструкції з діловодства за зверненнями громадян в органах державної влади і місцевого самоврядування”;
Постанови Кабінету Міністрів України “Про затвердження Методики оцінювання рівня організації роботи із зверненнями громадян в органах виконавчої влади”;
Постанови Кабінету Міністрів України “Про затвердження Класифікатора звернень громадян”;
Постанови Кабінету Міністрів України від 04.02.1998 № 121 “Про затвердження переліку обов'язкових етапів робіт під час проектування, впровадження та експлуатації засобів інформатизації”;
Постанови Кабінету Міністрів України від 12.04.2002 №522 “Про затвердження Порядку підключення до глобальних мереж передачі даних”;
Постанови Кабінету Міністрів України від 10.09.2003 № 1433 “Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади”;
Постанови Кабінету Міністрів України від 29.03.2006 №373 “Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах”;
Рішення Київської міської ради від 2 липня 2015 року № 654/1518 “Про затвердження Комплексної міської цільової програми “Електронна столиця” на 2015 - 2018 роки”;
НД ТЗІ 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.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. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення;
ДК 010-98. “Державний класифікатор управлінської документації”;
ДСТУ ISO/IEC 12207:2016 (ISO/IEC 12207:2008, IDT). “Інженерія систем і програмного забезпечення. Процеси життєвого циклу програмного забезпечення”.<HTML></p></HTML>

<HTML><p></HTML>Модернізована система ЄІАС “CRM-1551”, яка розгортається у рамках даного проекту, побудована на базі “CallWay CRM”. Така побудова надає можливість централізованого доступу до інформації, яка перебуває у базі даних та єдиному сховищі даних.
На Рисунок 1 наведено загальну схему архітектури ЄІАС “CRM-1551”.

Рисунок 1. Загальна схема побудови архітектури ЄІАС “CRM-1551”
Кінцевими користувачами ЄІАС “CRM-1551” залежно від наданої ролі є: оператор, координатор-контролер, менеджер району, власник, керівник виконавців, виконавець. Назви автоматизованих робочих місць співпадають з ролями, наданими користувачам системи: Автоматизоване Робоче Місце оператора, Автоматизоване Робоче Місце координатора-контролера, Автоматизоване Робоче Місце менеджера району, Автоматизоване Робоче Місце керівника виконавців, Автоматизоване Робоче Місце виконавця, Автоматизоване Робоче Місце власника.
Реалізація ЄІАС “CRM-1551” заснована на використанні сервісно-орієнтованої клієнт-серверної архітектури, яка складається з трьох рівнів (див. Рисунок 2):<HTML></p></HTML><HTML></li></HTML><HTML></ul></HTML>

1. Сховище даних (будується з використанням реляційних систем управління БД з шифруванням даних; для кожного користувача встановлюється свій рівень доступу до інформації) на основі Mirosoft SQLServer 2012.
2. Рівень серверів застосунків (складається з компонента сервісів загальносистемних засобів та компонента сервісів інформаційної взаємодії з іншими компонентами).
3. Рівень представлення (реалізує функціональні можливості системи за допомогою веб-технології SPA (Single-Page Applications: односторінкове веб-застосунку); включає інтерфейс авторизації, алгоритми шифрування, перевірку форматів даних, сортування, операції з даними тощо).

Рисунок 2. Схема трирівневої архітектури ЄІАС “CRM-1551”
Клієнтський рівень (перший) являє собою інтерфейсний (графічний) компонент, реалізований з використанням SPA підходу побудови веб-застосунків, та бібліотеки Angular 6 для реалізації вказаного SPA. Перший рівень має такі функціональні особливості:

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

Сервер застосунків (другий рівень) являє собою ASP.NET WebApi додаток, побудований на базі .Net Framework 4.7.1 або вище, та реалізує більшу частину бізнес-логіки, окрім фрагментів, які експортуються на термінали, а також розміщених на третьому рівні збережених процедур і тригерів. Компоненти другого рівня забезпечують:

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

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

• введення і редагування записів у ручному режимі;
• адміністрування користувачів системи;
• обмеження доступу до сайту по IP з використанням відповідного модуля.

Сервер бази даних (третій рівень) забезпечує зберігання даних (включно із збереженими процедурами, тригерами і схемою, яка описує застосунок у термінах реляційної моделі). Третій рівень реалізовано як промислову систему управління базами даних (Microsoft SQL Server 2012 з використанням технологій FailoverClustering та AlwaysOnAvailabilityGroups. AlwaysOn). На рисунку 3 наведено загальну схему із набором зв'язків між компонентами та модулями ЄІАС “CRM-1551”.


CallWay
Рисунок 3. Компоненти та модулі ЄІАС “CRM-1551”
ЄІАС “CRM-1551” складається з таких технологічних компонентів:

• HTTP-сервер;
• Сервер БД;
• Сервер застосувань;
• Засоби адміністрування і розробки: Microsoft Management Studio, призначених для адміністрування системи ETL, баз даних, сервера

застосувань (Microsoft Internet Information Services Manager) і розробки звітності (Microsoft Analysis and Reporting Services);

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

Система ЄІАС “CRM-1551” забезпечує виконання таких основних функцій:

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

Схему функціональних можливостей системи ЄІАС “CRM-1551” див. Рисунок 4.

Рисунок 4. Схема функціональних можливостей ЄІАС “CRM-1551”

У рамках виконання даного проекту модернізована система ЄІАС “CRM-1551” була налаштована згідно з потребами Замовника, викладеними у Технічному завданні.
У результаті модернізації Системи реалізовано:

• налаштування автоматизованих бізнес-процесів у системі, а саме:
• бізнес-процес роботи операторів під час прийому звернень громадян за допомогою голосового телефонного зв'язку (дзвінки з будь-яких телефонних номерів у межах України), а також через форму зворотного зв'язку на веб-сайті;
• бізнес-процес роботи виконавців з прийняття, перерозподілу та обробки отриманих звернень;
• бізнес-процес роботи координаторів по відслідковуванню якості та вчасності обробки звернень виконавцями;
• бізнес-процес роботи власників (балансоутримувачів або підрядників з обслуговування об'єктів) по відслідковуванню статусу обробки звернень по їх об'єктах;
• бізнес-процес роботи менеджерів районів по редагуванню довідників Системи;
• бізнес-процес роботи менеджерів району та власників з контролю об'єктів та заявок;
• наповнено довідники Системи під потреби користувачів:
• Класифікатор звернень громадян;
• Можливі відповіді;
• Параметри об'єкту;
• Категорії заявників;
• Соціальні стани;
• Типи об'єктів;
• Типи проблем;
• Стани;
• Види звернень;
• Ознаки надходження;
• Джерела надходження;
• Типи зв'язків;
• Типи операцій;
• Типи резолюцій;
• Типи скарг.
• налаштовано реєстри для виконання поточних бізнес-процесів:
• Звернення;
• Заявники;
• Організації;
• Користувачі;
• Скарги;
• Аварійні та планові роботи;
• Хід виконання;
• Аварійні будинки;
• Об'єкти;
• Працівники.

Система має можливість інтеграції із допоміжними підсистемами:

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

Система також має можливість інтеграції із зовнішніми системами:

• Системою телефонії;
• Системою центральної диспетчерської служби м. Києва з питань ЖКГ;
• Інформаційно-аналітичною системою “Управління майновим комплексом територіальної громади міста Києва”.

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

http://crm1551.callway.com.ua:8076/sections/CreateAppeal/add?phone=(044)2356767&type_id=1

Рисунок 5. Реєстрація нового звернення
Створюється нове звернення, якому присвоюється номер та тип “Дзвінок в 1551”, фіксується номер телефону, за яким приймається звернення та дата і час початку розмови.

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

• реєстрація консультації за системою ЕОСЖКГ;
• реєстрація консультації за заходом;

реєстрація консультації за базою знань;

• реєстрація консультації за питанням.

Реалізація консультацій більш детально розглянута в пп.2.3.4 – 2.3.7.

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

Реалізація закриття питання за запитом заявника розглянута в п.2.3.9.

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

Реалізація реєстрації питань заявника та Доручень по них розглянута в п.2.3.2, 2.3.3.

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

Основний інтерфейс керівника виконавців:
http://crm1551.callway.com.ua:8076/dashboard/page/Kerivnuk_vukonavec?id=0

Рисунок 6. Основний інтерфейс керівника виконавців
Протягом трьох діб він може позначити доручення “не в компетенції” та передати його на повторний розподіл до відділу координаторів. Якщо доручення є в компетенції організації виконавця або його підпорядкованих організацій, керівник виконавців призначає доручення підпорядкованій організації-виконавцю. Але тоді дата передачі доручення змінюється на поточну, стан доручення - “У роботі”.
Більш докладно бізнес-процес описаний у п.2.3.10.

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

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

• не може бути виконаним – у Дорученні зазначається відповідна резолюція;
• потребує роз'яснення – Доручення роз'яснюється.

Докладний процес обробки Доручення виконавцем зазначений у п.2.3.11.

1. Після обробки Виконавцем Доручення потрапляє до Координатора. Координатор знаходить доручення, що потребують обробки, та обирає одне з них. Якщо доручення не в компетенції виконавця, то координатор може змінити Керівника виконавців та відправити Доручення на обробку. Якщо Доручення було роз'яснене, перевіряється коректність роз'яснення. Якщо роз'яснення коректне , то Доручення закривається як “Роз'яснене”. Якщо роз'яснення некоректне і таких спроб роз'яснити менше трьох , то Доручення повертається виконавцю для надання більш точного формулювання. Якщо спроб роз'яснити більше трьох, то Доручення закривається як невиконане.

Більш детально цей процес описаний у п.2.3.12.

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

http://crm1551.callway.com.ua:8076/sections/CreateAppeal/add?phone=(044)2356767&type_id=1


Рисунок 7. Реєстрація нового звернення

1. Після прийняття виклику Система реєструє звернення.

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

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

Рисунок 8. Ідентифікація заявника

1. Після реєстрації заявника Оператор має визначити причину звернення.
2. Якщо звернення має причиною консультацію мешканця, Оператор повинен ініціювати реєстрацію консультації за такими типами:

• Консультація щодо заявок з системи ЕОСЖКГ;
• Консультація щодо Заходу;
• Консультація по Базі Знань (БЗ);
• Консультація щодо раніше зареєстрованого питання заявника (у тому числі запит на закриття питання);
• Питання, що потребує реєстрації.

Більш детально це питання викладено в пп. 2.3.3 – 2.3.9.

1. Якщо звернення має причиною консультацію мешканця щодо заявки з системи ЕОСЖКГ, Система виконує пошук інформації про таку заявку в системі «Городок» за адресою заявника.

Рисунок 9. Питання та заявки, пов'язані з адресою заявника
Якщо інформація знайдена, Система відображає цю інформацію, зберігаючи ідентифікатор знайденого об'єкта. Оператор надає мешканцю консультацію та реєструє її записом операції “Реєстрація консультації типу консультація за системою “Городок”, вказавши Ідентифікатор знайденої сутності у зверненні (детальніше -п.2.3.4). Якщо інформації щодо заявки не знайдено, Оператор повідомляє мешканця про відсутність інформації. Якщо у мешканця більше немає питань, Оператор повинен завершити дзвінок та завершити реєстрацію звернення. Якщо у мешканця є питання, Оператор продовжує реєстрацію нових питань (детальніше п.2.3.3).

1. Якщо звернення має причиною консультацію мешканця щодо Заходу, Оператор відкриває заходи, що відбуваються за адресою мешканця. Якщо інформація знайдена, Система відображає цю інформацію, після чого оператор надає мешканцю консультацію та реєструє консультацію записом операції “Реєстрація консультації типу реєстрація консультації за Заходом”, вказавши Ідентифікатор знайденої сутності у зверненні (детальніше п.2.3.5.). Якщо інформації щодо Заходу не знайдено, Оператор повідомляє мешканця про відсутність інформації. Якщо у мешканця більше немає питань, Оператор повинен завершити дзвінок та завершити реєстрацію звернення. Якщо у мешканця є питання, Оператор продовжує реєстрацію нових питань, починаючи з їх реєстрації.
2. Якщо звернення має причиною консультацію мешканця по Базі Знань (БЗ), Оператор обирає перехід до бази знань. Якщо є можливість надати відповідь без пошуку в БЗ, Оператор консультує мешканця та реєструє консультацію належним чином. Якщо відповідь без пошуку неможлива, Оператор проводить пошук інформації в БЗ. Система реєструє надання мешканцю консультації та реєструє консультацію записом операції “Реєстрація консультації типу консультація по БЗ” (детальніше п.2.3.6.). Якщо інформації в БЗ не знайдено, Оператор повідомляє мешканця про відсутність інформації. Якщо у мешканця більше немає питань, Оператор повинен завершити дзвінок та завершити реєстрацію звернення. Якщо у мешканця є питання, Оператор продовжує реєстрацію нових питань, починаючи з їх реєстрації.
3. Якщо звернення має причиною консультацію мешканця щодо раніше зареєстрованого питання Заявника (у тому числі запит на закриття питання), Оператор повинен визначити заявника як “поточного”, для чого необхідно визначити або запитати атрибути пошуку: номер телефону, інші атрибути тощо. Після цього Оператор має знайти раніше зареєстроване питання, користуючись наданими або наявними атрибутами пошуку.

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

1. Якщо причиною звернення є питання, що потребує реєстрації, Оператор повинен ініціювати реєстрацію питання.

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

1. У результаті прийняття дзвінка Оператор може ініціювати виконання операції “Реєстрація питання”.
2. У системі під час реєстрації питання фіксується дата та час початку виконання операції.
3. Після цього відображаються атрибути заявника та атрибути питання для заповнення. Якщо заявник є в системі, Оператор має знайти його за атрибутами, якщо заявника немає в системі, Оператор повинен зареєструвати заявника. Після цього заявник визначається як “поточний”.
4. Оператор повинен визначити, стосується питання місця та/або організації. Якщо питання стосується місця, Оператор вказує місце. Якщо питання стосується організації – вказує організацію.
5. Оператор має описати зміст питання та визначити тип питання за класифікатором.

Рисунок 12. Реєстрація питання

1. Після цього Оператор повинен заповнити атрибут “Тип питання”.
2. Якщо тип питання пов'язаний з передачею питання виконавцям, Система створює Доручення на відповідальні організації, встановлює дату та час контролю питання: “Поточна дата та час” + “Кількість днів на виконання”, встановлює cтрок виконання доручень: “Поточна дата та час” + “Кількість днів на виконання”.
3. Якщо тип питання не пов'язаний з передачею питання виконавцям, але питання потребує відповіді, то Оператор заповнює атрибути надання відповіді. Якщо ні, Оператор має ініціювати відмову та повернутися до звернення.
4. Після надання відповіді та ініціювання збереження питання Система зберігає “Дату та час реєстрації питання” та внесені дані, призначає питанню та дорученням унікальні номери, призначає Питанню стан “Передано”, призначає Дорученням стан “Надійшло”, відображає операцію “Реєстрація Питання” та номер питання у Зверненні.

<HTML><ol></HTML> <HTML><li></HTML><HTML><ol></HTML> <HTML><li></HTML>Після отримання дзвінка Оператор може ініціювати виконання операції “Реєстрація консультації”.<HTML></li></HTML> <HTML><li></HTML>Система автоматично фіксує дату та час початку виконання операції.<HTML></li></HTML> <HTML><li></HTML>Оператор повинен визначити “поточного” заявника, якщо він визначений і є в системі, Оператор повинен знайти його, вибрати як “поточного” та відобразити атрибути “Поточного заявника” і атрибути консультації для заповнення.<HTML></li></HTML> <HTML><li></HTML>Якщо заявник не визначений, Система відображає атрибути заявника та атрибути консультації для заповнення.<HTML></li></HTML> <HTML><li></HTML>Якщо заявника немає у системі, Оператор повинен запросити реєстраційні дані у заявника та зареєструвати заявника в системі.<HTML></li></HTML> <HTML><li></HTML>Якщо заявник не бажає ідентифікуватись, то консультація буде анонімна.<HTML></li></HTML> <HTML><li></HTML>Після того, як заявника визначено, Оператору відображаються можливі питання на консультації, він обирає “За системою ЕОСЖКГ”.<HTML></li></HTML> <HTML><li></HTML>Якщо заявник визначений, то Система автоматично “підтягує” будинок заявника, і відбувається пошук заявки в системі ЕОСЖКГ. Якщо не визначений, то Оператор задає атрибути пошуку в адресі заявника. Оператор повинен перевірити пошукові дані, визначені автоматично, зробити в них необхідні зміни та ініціювати пошук у системі ЕОСЖКГ.<HTML></li></HTML> <HTML><li></HTML>Система отримує результат пошуку та відображає знайдену інформацію.<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ol></HTML>
Рисунок 13. Заявка з системи ЕОСЖКГ <HTML><ol></HTML> <HTML><li></HTML><HTML><ol></HTML> <HTML><li></HTML>Оператор отримує перелік заявок з системи ЕОСЖКГ та може переглядати їх з наданням консультації мешканцю за знайденою інформацією.<HTML></li></HTML> <HTML><li></HTML>За необхідності, Оператор змінює пошукові дані та повторює пошук.<HTML></li></HTML> <HTML><li></HTML>Оператор реєструє питання по консультації та ініціює збереження консультації з реєстрацією питання по консультації.<HTML></li></HTML> <HTML><li></HTML>Оператор або заявник можуть відмовитись від виконання операції. У такому разі Оператор ініціює відмову та повинен перервати виконання операції та повернутись до Звернення.<HTML></li></HTML> <HTML><li></HTML>Після надання консультації Оператор повинен ініціювати збереження консультації, зафіксувати дату та час завершення операції, зберегти номер об'єкта з системи “Городок” у консультації, зберегти дані консультації, дату та час виконання операції.<HTML></li></HTML> <HTML><li></HTML>Якщо ініційовано реєстрацію питання по консультації, Оператор має перейти до “Реєстрація питання по консультації” (докладніше п.2.3.8). Якщо не ініційовано, то відобразити операцію “Реєстрація Консультації за “Городок” у Зверненні.<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ol></HTML>

1. Після отримання дзвінка Оператор ініціює виконання операції “Реєстрація консультації”.
2. Система автоматично фіксує дату та час початку виконання операції.
3. Оператор повинен визначити “поточного” заявника. Якщо він визначений і є в системі, Оператор повинен знайти його, вибрати як “поточного” та відобразити атрибути “Поточного заявника” і атрибути консультації для заповнення.
4. Якщо заявник не визначений, Система повинна відобразити атрибути заявника та атрибути консультації для заповнення.
5. Якщо заявника немає у системі, Оператор повинен запросити реєстраційні дані у заявника та зареєструвати заявника в системі.
6. Якщо заявник не бажає ідентифікуватись, то консультація буде анонімна.
7. Після цього Система автоматично підтягує активні Заходи по будинку Заявника та дає можливість змінити атрибути пошуку Заходів. Оператор повинен перевірити пошукові дані, визначені автоматично, заповнити пошукові дані та ініціювати пошук Заходів у Системі.
8. Система отримує результат пошуку та відображає знайдену інформацію.
9. Оператор надає консультацію мешканцю за знайденою інформацією.
10. Якщо інформації не знайдено, Система повинна відобразити повідомлення про відсутність даних та надати інформацію про відсутність даних заявнику.
11. За необхідності, Оператор змінює пошукові дані та повторює пошук.
12. Оператор реєструє питання по консультації та ініціює збереження консультації з реєстрацією питання по консультації.
13. Оператор або заявник можуть відмовитись від виконання операції. У такому разі Оператор повинен ініціювати відмову, перервати виконання операції та повернутись до Звернення.
14. Після надання консультації Оператор повинен ініціювати збереження консультації, зафіксувати дату та час завершення операції, зберегти номер заходу в консультації, зберегти дані консультації, дату та час виконання операції.
15. Система повинна відобразити операцію “Реєстрація Консультації” за типом “За Заходом” у Зверненні.

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

1. Після отримання дзвінка Оператор ініціює виконання операції “Реєстрація консультації”.
2. Система автоматично фіксує дату та час початку виконання операції.
3. Оператор повинен визначити “поточного” заявника, якщо він визначений і є в системі, Оператор повинен знайти його, вибрати як “поточного” та відобразити атрибути “Поточного заявника” і атрибути консультації для заповнення.
4. Якщо заявник не визначений, Система повинна відобразити атрибути заявника та атрибути консультації для заповнення.
5. Якщо заявника немає у системі, Оператор повинен запросити реєстраційні дані у заявника та зареєструвати заявника в системі.
6. Якщо заявник не бажає ідентифікуватись, то консультація буде анонімна.
7. Система відображає питання заявника, а оператор обирає необхідне питання.

Рисунок 14. Обираємо питання заявника

1. Оператор надає консультацію мешканцю за знайденою інформацією та виконує необхідні дії за питанням.
2. Якщо інформації не знайдено, Система повинна відобразити повідомлення про відсутність даних та надати інформацію про відсутність даних заявнику.
3. За необхідності, Оператор змінює пошукові дані та повторює пошук.
4. Оператор реєструє питання по консультації та ініціює збереження консультації з реєстрацією питання по консультації.
5. Оператор або заявник можуть відмовитись від виконання операції. У такому разі Оператор ініціює відмову та повинен перервати виконання операції та повернутись до Звернення.
6. Після надання консультації Оператор повинен ініціювати збереження консультації, зафіксувати дату та час завершення операції, зберегти дані консультації, дату та час виконання операції.
7. Система повинна відобразити операцію “Реєстрація Консультації за типом “За питанням” у Зверненні.

1. Після отримання дзвінка Оператор ініціює виконання операції “Реєстрація питання”.
2. Система повинна зв'язати консультацію з питанням, що створюється, до питання підтягнути дані по консультації (ідентифікатор облікової системи з ЕОСЖКГ; Питання за класифікатором).
3. Система повинна визначити “поточного” заявника, якщо він визначений і є в системі, Система повинна знайти його, вибрати як “поточного” та відобразити атрибути “Поточного заявника” й атрибути питання для заповнення.
4. Якщо Заявник не визначений, Оператор повинен відобразити атрибути заявника та атрибути питання для заповнення.
5. Якщо заявника немає у системі, Оператор повинен запросити реєстраційні дані у заявника та зареєструвати заявника в системі.
6. Після того, як заявника визначено, Оператор вказує місце та/або організацію, яких стосується питання.
7. Після цього Оператор описує зміст питання та обирає “Тип питання” за класифікатором.
8. Система заповнює атрибути “Індекс” та “Тип питання”.
9. Якщо тип питання пов'язаний з виконавцями, Система повинна створити “Доручення” на відповідальні організації, встановити дату та час контролю питання: “Поточна дата та час” + “Кількість днів на виконання”, встановити строк виконання доручень: “Поточна дата та час” + “Кількість днів на виконання”.
10. Якщо тип питання не пов'язаний з виконавцями, Оператор з'ясовує, чи необхідно надати відповідь. Якщо так, то він заповнює атрибути відповіді. Якщо у відповіді немає потреби, Оператор ініціює збереження питання.
11. Оператор або заявник можуть відмовитись від виконання операції. У такому разі Оператор повинен ініціювати відмову, перервати виконання операції та повернутись до Звернення.
12. Після ініціювання збереження питання Система повинна зафіксувати дату та час реєстрації питання, зберегти внесені дані, призначити питанню та дорученням унікальні номери.
13. Після збереження питання Система повинна призначити Питанню стан “Передано”, призначити Дорученням стан “Надійшло”.
14. Система повинна відобразити операцію “Реєстрація Питання” та номер питання у Зверненні “Реєстрація Консультації” за типом “За питанням” у Зверненні.

<HTML><ol></HTML> <HTML><li></HTML><HTML><ol></HTML> <HTML><li></HTML>У разі, якщо виконано передачу атрибутів дзвінка з CallWay до CRM-1551, Система відобразить Форму звернення.<HTML></li></HTML> <HTML><li></HTML>Оператор повинен ініціювати операцію “Реєстрація консультації”, Тип консультації “За питанням”. Під час цього Система відобразить реєстр питань (фільтр за номером телефону).<HTML></li></HTML> <HTML><li></HTML>Оператор повинен отримати від Заявника атрибути пошуку питання та ініціювати пошук питання за атрибутами, що надає Заявник.<HTML></li></HTML> <HTML><li></HTML>Якщо питання не знайдено, Оператор має запросити додаткову інформацію у заявника. Якщо Заявник не надав додаткову інформацію, Оператор повинен надати заявнику інформацію про неможливість закриття питання або відмовити у закритті питання та ініціювати реєстрацію консультації за питанням, або перейти до нового пошуку питання, заповнивши необхідні атрибути.<HTML></li></HTML> <HTML><li></HTML>Якщо питання знайдено, Система має відобразити результати пошуку. Оператор обирає питання з переліку результатів пошуку.<HTML></li></HTML> <HTML><li></HTML>Оператор має відкрити необхідне питання та зачитати зміст питання заявнику.<HTML></li></HTML> <HTML><li></HTML>Якщо вибір зроблено правильно та Заявник дзвонить з того самого номера телефону, з якого реєструвалось питання, Оператор закриває питання.<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ol></HTML>
Рисунок 15. Оцінка результату виконання робіт <HTML><ol></HTML> <HTML><li></HTML><HTML><ol></HTML> <HTML><li></HTML>Якщо Заявник дзвонить з іншого номера телефону, Оператор запитує номер телефону, з якого подавалось Звернення. Якщо номер телефону неправильний, Оператор повинен відмовити у закритті питання. Якщо Заявник назвав правильний номер телефону, то Оператор закриває питання.<HTML></li></HTML> <HTML><li></HTML>Система має зберегти внесені зміни та ініціювати реєстрацію консультації за питанням.<HTML></li></HTML> <HTML><li></HTML>Система має зберегти консультацію та відобразити операцію у зверненні “Консультація за питанням”.<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ol></HTML>

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

• Прострочені пріоритетні доручення;
• Повторні пріоритетні доручення;
• Пріоритетні доручення;
• Непріоритетні доручення тощо.

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

Рисунок 16. Обробка доручень Керівником виконавців

1. Керівник виконавців приймає рішення щодо доручення:

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

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

1. Виконавець здійснює первинний пошук доручень на підставі конфігурації первинних пошуків, що повинні бути закладені в Систему та згідно з Пріоритетами розгляду.
2. За необхідності реєстрації Заходу, Виконавець заповнює картку Заходу та прив'язує, за необхідності, відповідні доручення до даного Заходу.
3. Якщо є Заходи, які потребують закриття, Виконавець здійснює закриття Заходу. Якщо наявні доручення щодо даного Заходу, Виконавець закриває Доручення, пов'язані з даним Заходом.
4. Виконавець приймає доручення (групу доручень) в роботу згідно з пріоритетом обробки у такій послідовності:

• прострочені пріоритетні доручення;
• повторні пріоритетні доручення з поточною датою контролю;
• пріоритетні доручення з поточною датою контролю;
• непріоритетні доручення тощо.

1. Виконавець обирає доручення зі списку для обробки.
2. Виконавець приймає рішення щодо доручення:

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

1. 3

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

• Доручення, що насправді не в компетенції Виконавця, надсилаються за належністю іншій Організації-виконавцю. Під час цього попереднє доручення приймає стан “Закрито” та знімається з контролю. Створюється нове доручення на нову організацію. Нове доручення приймає стан “Зареєстровано”, Дата та час передачі = Поточна дата та час, Дата контролю для нового доручення не змінюється (дорівнює Даті контролю Питання).
• Доручення, що в компетенції Виконавця, повертаються Виконавцю на виконання.
  1. Потім Координатор-контролер звіряє доручення з результатом “Роз'яснено” з поточною датою контролю, а потім інші доручення, що оброблені Виконавцями:
• Доручення, що пройшли перевірку, “закриваються” (Стан = “Закрито”, Результат = “Виконано”, Резолюція = “Роз'яснено”).
• Доручення, що не пройшли перевірку, повертаються Виконавцю на доопрацювання.
  1. Потім Координатор-контролер перевіряє доручення, які не можна виконати в поточний час (Стан = “На перевірці”, Результат = “Не виконано”, Резолюція = “План програма”, “Потребує додаткового фінансування” тощо).
  2. Також Координатор-контролер може змінювати Тип питання у питаннях за офіційним листом. У такому випадку - за рішенням координатора-контролера:
• Доручення та їх стан можуть залишатись без змін.
• Можуть змінюватись перелік доручень та строки виконання.

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

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

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

• Реєстрація всіх видів звернень громадян (через телефон, Єдиний Веб-портал (веб-інтерфейс розділу Єдиного веб-порталу КМДА 1551.gov.ua та програмних модулів для відправки запитів з мобільних пристроїв і планшетів під керівництвом Windows Phone OS, iOS та Apple OS, Android OS, Android Tablet, Windows XP/7/Vista/8 та інші), електронну пошту тощо).
• Здійснення автоматизованого заповнення контрольно-реєстраційної картки відповідними графами під час реєстрації та обробки звернень:
• реквізитів заявника;
• назви кореспондента, звідки переадресовані звернення;
• переліку категорій заявника;
• переліку виконавців;
• стандартних текстів резолюцій.
• Автоматизований контроль виконання звернень (відстеження строків виконання).
• Формування переліку “Контрольні терміни” − реквізитів, що характеризують зміни контрольних термінів виконання документа.
• Аналіз стану та результатів розгляду звернень.
• Підтримка довідника текстів типових резолюцій.
• Ведення історії відправлення документів на виконання та їх прийняття до виконання.
• Єдиний контроль входу і зберігання всіх звернень для отримання повної історії звернень громадянина в будь-яку з інстанцій, охоплених системою.
• Закриття документів виконавцями.
• Ведення зв'язаної історії опрацювання документа та його контролю.
• Ведення журналу комунікацій з абонентом з можливістю їх розширеного пошуку, в залежності від наявних параметрів.
• Підготовка звітів.
• Можливість оцінки виконання робіт : кожен з етапів виконання робіт має можливість бути оціненим. Оцінка − це бали від 1 до 5 з можливістю залишити коментар.
• Стани питань:
• Зареєстровано – питання ще не прийнято до роботи виконавцем.
• У роботі – питання перебуває на виконанні.
• На перевірці – питання на перевірці у координатора-контролера.
• Не виконано – питання не виконано.
• Закрито – питання закрито.
• Стани доручень:
• Зареєстровано – доручення ще не прийнято до роботи виконавцем.
• У роботі – доручення перебуває на виконанні.
• На перевірці – доручення на перевірці у координатора-контролера.
• Не виконано – доручення не виконано.
• Закрито – доручення закрито.
• Увага – доручення на виконанні, проте термін виконання робіт незабаром спливає.
• Прострочена − доручення прострочене. Необхідно актуалізувати строки виконання робіт.
• Можливість масової передачі доручень у роботу: під час одночасного прийому великої кількості звернень у роботу розроблено функцію масової передачі звернень у роботу. Під час активації даної функції всі звернення, що перебувають у стані «нова», переводяться на виконання відповідному працівнику.
• Наявність “Картки місця”: можливість виводу картки будь-якого місця в системі (будинку, ліфта, квартири, інфраструктурного об'єкта: бойлера, трансформаторної підстанції тощо). У картці місця надано можливість виводу та редагування параметрів місця. З картки місця забезпечено перегляд усіх звернень, що були оформлені на дане місце.
• Наявність Картки підприємства: забезпечено можливість перегляду всіх звернень, що перебувають у роботі даного підприємства / відділу підприємства.
• Підбір виконавця по зверненню: забезпечено підбір виконавця звернення по відповідному напрямку звернень та відповідному місцю, на яке звернення зареєстровано.

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

В ЄІАС “CRM-1551” організовано можливість пошуку інформації по будь-якому з елементів звернення, а також можливість вибору значень з елементів довідників.
Пошук організований за кількома критеріями:

• за місцем, до якого прив'язана проблема, або на яке впливає проблема;

Підсистема забезпечує отримання інформації (думок, настрою, відгуків) про роботу громадського транспорту, соціальних служб, медичних закладів тощо шляхом проведення опитувань.
Передбачена можливість проведення опитувань під час взаємодії з громадянином засобами телефонного зв'язку. Під час спілкування з мешканцем передбачена можливість проведення опитувань з приводу виконання якості та швидкості виконання звернень, що подавались мешканцем.
У рамках налаштувань підсистеми “Проведення опитувань” налаштована можливість фіксації оцінки якості виконання робіт від 1 до 5 та коментаря до результату виконання.

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

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

• Розмежування прав доступу відповідно до встановленої керівництвом Замовника політики інформаційної безпеки та доступу.
• Ідентифікацію користувачів ЄІАС “CRM-1551” за паролем.
• Створення максимально спрощеної системи підключення внутрішніх користувачів до системи (доменні логін, пароль).
• Надання прав згідно з ролями доступу:

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

Забезпечено інтеграційні можливості з системою телефонії:

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

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

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

Функціонування підсистеми “Захист інформації” забезпечує:

• наявність функцій адміністратора ЄІАС «CRM-1551» для встановлення прав доступу користувачів;
• захист інформації від несанкціонованого доступу та порушень, цілісності;
• аудит операцій;
• аудит змін значень реквізитів;
• аудит дій користувача щодо внесення ним змін до ресурсів системи;
• аудит входу користувача до ЄІАС “CRM-1551”;
• аудит поточної та архівної інформації адміністратором безпеки;
• можливість організації користувачів у групи та багаторівневі підгрупи;
• неможливість внесення змін до інформації щодо прав доступу користувача до ресурсів та їх дій у ЄІАС “CRM-1551”;
• перегляд інформації про доступ до ресурсів за певним користувачем;
• перегляд інформації щодо внесених змін до ресурсів;
• блокування облікового запису;
• адміністрування прав доступу до окремих реквізитів;
• адміністрування прав доступу до операцій.

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

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

Для забезпечення обчислення значення електронного цифрового підпису, що використовується в системі, конфіденційності та цілісності даних, що передаються через АPI, передбачено можливість застосування програмного засобу криптографічного захисту інформації, що має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації України.
Для забезпечення безпеки передачі даних між АРМ та серверним програмним комплексом у ЄІАС “CRM-1551” передбачено можливість використання програмних засобів криптографічних перетворень, який має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України.

Формуємо POST запит на адресу сервісу API: /oauth/token.
Параметри запиту:
Таблиця 1. Параметри запиту для отримання токену

Елементи пакету, що отримується:
Таблиця 2. Елементи пакету, що отримується в результаті виконання запиту

Формуємо POST запит на адресу для передачі даних: /api/section/AppealsFromSite.
Параметри запиту:
Таблиця 3. Параметри запиту для передачі даних з сайту 1551 та мобільних додатків

Вхідні дані для реєстрації звернень з сайту 1551 та мобільних додатків.
Таблиця 4. Пакет даних по реєстрації звернень з сайту 1551 та мобільних додатків

Формуємо POST запит на адресу для передачі даних: /api/section/GorodokClaims.
Параметри запиту:
Таблиця 5. Параметри запиту для передачі даних з системи ЕОСЖКГ

Вхідні дані для реєстрації заявок з системи ЕОСЖКГ
Таблиця 6. Пакет даних по реєстрації звернень з системи ЕОСЖКГ

Загальний перелік таблиць даних ЄІАС “CRM-1551” див. таблиця 1.
Склад даних наведено у таблицях 2 - 50.
Таблиця 7. Загальний перелік таблиць даних ЄІАС “CRM-1551”

Таблиця 8. Довідники

Таблиця 9. Звернення

<HTML><ul></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів <HTML><ul></HTML> <HTML><li></HTML>− у форматі ГГ:ХХ ДД.ММ.РРРР
Таблиця 10. Заявники

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число
Таблиця 11. Організації

<HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 12. Користувачі

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число
Таблиця 13. Ролі

<HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 14. Ролі. Вміст довідника

Таблиця 15. Скарги

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів <HTML><ul></HTML> <HTML><li></HTML>− у форматі ГГ:ХХ ДД.ММ.РРРР
Таблиця 16. Аварійні та планові роботи

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів <HTML><ul></HTML> <HTML><li></HTML>− у форматі ГГ:ХХ ДД.ММ.РРРР <HTML><ul></HTML> <HTML><li></HTML>− у форматі ДД.ММ.РРРР <HTML><ul></HTML> <HTML><li></HTML>− у форматі mp3 розміром не більше 10 Мб.
Таблиця 17. Класифікатор звернень громадян

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 18. Хід виконання

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів <HTML><ul></HTML> <HTML><li></HTML>− у форматі ГГ:ХХ ДД.ММ.РРРР
Таблиця 19. Опитування

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів <HTML><ul></HTML> <HTML><li></HTML>− у форматі ГГ:ХХДД.ММ.РРРР
Таблиця 20. Питання

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів

Таблиця 21. Можливі відповіді

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів

Таблиця 22. Результат опитування

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML><HTML><ul></HTML> <HTML><li></HTML>− у форматі ГГ:ХХ ДД.ММ.РРРР
Таблиця 23. Аварійні будинки

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 24. Об'єкти

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 25. Параметри об'єкта

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 26. Значення параметрів

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 27. Адреси

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число
Таблиця 28. Адреси проживання

<HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 29. Зв'язки об'єктів

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число
Таблиця 30. Категорії заявників

<HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 31. Категорії заявників №2

Таблиця 32. Соціальні стани

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 33. Соціальні стани №2

Таблиця 34. Типи об'єктів

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 35. Ролі користувача

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число
Таблиця 36. Працівники

<HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 37. Типи проблем

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів

Таблиця 38. Стани

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів

Таблиця 39. Стани №2

Таблиця 40. Види звернень

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 41. Види звернень №2

Таблиця 42. Ознаки надходження

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 43. Ознаки надходження №2

Таблиця 44. Джерела надходження

<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML> <HTML><li></HTML>− ціле додатне число <HTML><ul></HTML> <HTML><li></HTML>− максимально 255 символів
Таблиця 45. Джерела надходження №2