1. Уряд Open Source
Публічне API для виконавчої влади всіх рівнів
Автор ідеї: Василь Жук
www.facebook.com/vasyl.zhuk

2. В чому сила Open Source?
• Замість обмеженого продукту –
необмежена кількість ідей від спільноти
• Замість обмежених ресурсів – колективна
творчість тих, хто справді любить
створювати
Все, що необхідно, – створити умови для того,
щоб спільнота зробила свою справу!

3. Public API
• Система команд (запитів), доступна через
мережу, що дозволяє отримувати, вносити
та управляти даними на певному сервісі
• Існуючі Public API від Google, Yandex,
Facebook, Twitter та ін. ресурсів стали
основою для величезної кількості стартап-
проектів, зробивши доступними для аналізу
різноманітні дані – від геолокації до
соціальних графів

4. Єдина «шина»
• Єдиний формат захищеного публічного REST API
– Інтегрується в існуючі веб-проекти уряду як модуль або
додатковий легковісний сервер з доступом до бази
даних
– Є елементом «базового продукту» - задачника для
уряду
– Інтегрує розрізнені веб-системи забезпечення
адміністративних процесів у єдину розподілену систему
• Дозволяє перетворити проекти e-Government у
Smart Government*
*http://nc.gov.ua/news/index.php?ID=1319

5. Очікуваний ефект
• Синергія
– Прискорення і оптимізація адміністративних процедур
– Доступність і простота адміністративних процедур (мобільний доступ і
т.д.)
– Зменшення часових і ресурсних затрат на комунікацію, обробку запитів,
звітування
• Прозорість
– Громадський контроль за діяльністю уряду – безпосередній та
автоматичний
– Інтерфейс для порталів відкритих даних
• Фінансовий ефект
– Впровадження простого розподіленого продукту дешевше
централізованих рішень
– Такий інтерфейс потенційно становить цікавість для розробників ІТ систем
для бізнесу

6. Бюрократія як система
ІТ, прозорість, справедливість
Кроки реалізації проекту

7. Уряд як сервіс (1)
• Як працює урядова організація зараз
Обробка запиту у стилі
«Чорна скринька»:
процеси обробки запиту не
доступні зацікавленій стороні
- громадянину
Запит
Результат
Відповідь
Вимога
додаткових
дій від суб’єкта

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

9. Уряд як сервіс (3)
• Як наслідок:
Обмежене
коло осіб
може
аналізувати
доцільність і
ефективність
процедур
Немає жодної
мотивації для
підвищення
ефективності
роботи
органів
1. Сприятливи
й ґрунт для
розвитку
корупції
2. Падіння
ефективності

10. Уряд як сервіс (4)
В ідеалі діяльність уряду має реалізовувати
такі права громадян:
• Знати, як і ким розглядається питання
• Бачити загальну картину процесу
• Отримати адекватне пояснення
• Вимагати більш ефективного виконання
урядом своїх обов’язків
• Право контролювати на всіх стадіях

11. Характеристика уряду як системи
• Існує потік задач:
– Запити від громадян і організацій
– Запити від інших органів
• Кожна задача вимагає певних стадій обробки, що
характеризуються:
– Відповідальною стороною
– Необхідними ресурсами/передумовами/підзадачами
– Процедурою обробки
– Часовими рамками
– Очікуваним(и) результатом(ами) / наслідками
– Напрямком передачі в залежності від результату

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

13. Підсумок
• Громадяни не є клієнтами для апарату
влади
• Державний апарат не є конкурентоздатним
для задоволення законних потреб
громадян

14. ІТ, прозорість, справедливість
Бюрократія як система
Кроки реалізації проекту

15. «Задачник» для уряду
Потрібен «кістяк» - допоміжна система, яка б
формалізувала процедури і відповідальність
•Системи такого класу існують і ефективно використовуються в ІТ-
сфері – т.з. системи Bug Tracking, або ж «задачники»
•Кожен запит в системі подається як талон (ticket), що збирає і несе
в собі всю необхідну інформацію для виконання задачі
•Талони мають такі ознаки як: пріоритет, очікуваний/необхідний
час виконання, відповідальний виконавець, статус та ін.
•Талони можуть враховувати підзадачі, результати одне одного,
об’єднуватися в більш узагальнені задачі
•Задачники починають з успіхом проникати в інші сектори,
зокрема у фінансовий

16. Центри Надання
Адміністративних Послуг
• Мають веб-рішення для обробки запитів
громадян
• Частина впроваджень засновані на попередніх
позитивних досвідах Вінниці та Івано-Франківська
Але
• Веб-проекти різних ЦНАП ніяк не інтегровані між
собою
• Імовірно, координація надання адміністративних
послуг відбувається не через веб-систему, а в ній
лише фіксується кінцевий результат

17. ЦНАП: підсумок
• ЦНАП є «порталом» в бюрократичну систему, що
склалася
– ЦНАП – крок в на шляху до клієнт-орієнтованості
урядових сервісів
АЛЕ
• ЦНАП «маскують» часто неефективну і застарілу
систему адміністративних процесів
• Можуть бути лише першим кроком у бік
поліпшення ефективності і прозорості надання
урядових послуг

18. Public API для уряду
• Хоча «задачник» сам по собі дозволить більш
ефективно і прозоро обробляти запити, цього
недостатньо для ефективного публічного контролю
• Формалізована і захищена система API дозволить:
– Спростити комунікацію між однорідними «задачниками»,
що обслуговують різні органи влади
– Відкрити можливості для аналізу неконфіденційної
(неперсональної) інформації щодо виконання запитів
органами державної влади в усіх необхідних (затребуваних
громадою) формах і аспектах
– Інтегрувати наявні інформаційні ресурси для отримання
узгодженої якісної інформації як для адміністративних, так і
для аналітичних потреб

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

20. Кроки реалізації проекту
Бюрократія як система
ІТ, прозорість, справедливість

21. 1. Створення базового продукту
Створити базовий «задачник» для уряду як ядро і основну складову
системи
Необхідні риси кінцевого продукту:
– Наскільки можливо – використовувати готові напрацювання і продукти з
відкритим кодом
– Можливість гнучко задавати формалізацію адміністративних процесів
(послідовну низку фаз обробки задачі), щоб потім впроваджувати в
практику аналогічних установ
– Надійний захист конфіденційної інформації (персональні ключі,
шифрування), персоналізація дій (електронні підписи)
– Можливості горизонтальної (кластер) і вертикальної (ієрархія) інтеграції
окремих інстанцій (серверів з установленим ПЗ)
• Горизонтальна інтеграція забезпечить порівняно дешевий спосіб масштабувати
потужність системи в межах одного підрозділу
• Вертикальна інтеграція через однорідне API дозволить швидко і без зайвих затрат
інтегрувати додаткові інстанції, коли все нові і нові органи будуть переходити на
«задачник»

22. 2. Впровадження
1. Взаємодія із органами влади різних рівнів
(лобіювання, громадський тиск) щодо переходу на
клієнто-орієнтовану прозору систему роботи через
задачник
2. Аналіз адмін-процесів установ різних рівнів,
послідовна інтеграція впроваджених рішень через:
– Формалізації законних процедур обробки запитів
– Навчання співробітників установ (або виділення
відповідального)
3. Інформування громади щодо можливостей
застосування і контролю
4. Лобіювання законодавчої бази (щодо електронного
документообігу, доказовості фото- і відеозйомки тощо)

23. Запуск еволюції систем контролю
• Заохочення ІТ-спільноти до творчості на
основі аналізу отриманих даних
– Конкурси мобільних аплікацій
– Хакатони
– «Узаконення» висновків аналітичних програм
(як-то вплив рейтингу службовця в системі на
просування і оклад)

24. МОТИВАЦІЯ: погляд розробників
• Завдяки використанню типового рішення для
інтеграції відбувається:
– Скорочення ресурсів, затрачених на розробку
– Відтак затрати на кожне нове впровадження це:
– Аналіз і формалізація адмін-процесів
– Формування довідників та процедур
– Запуск сервера
– Навчання співробітників
– Простота інтеграції (при виході нових версій всі
інстанції оновлюються, і лишаються ідеально
сумісними)

25. МОТИВАЦІЯ: погляд працівників
держапарату
• Зменшення затрат часу на написання різного роду
звітів, зменшення їх кількості – адже вони самі
собою формуються в системі
• Спрощення організації робочого процесу – один
список завдань, сортований по пріоритетах, типові
рішення, нагадування
• Спрощення отримання інформації – завдяки
інтеграції з банками даних не доведеться робити
повторні запити і накопичувати «макулатуру», все
необхідне – під рукою
• Оптимізація потоку завдань – ідентичні чи подібні
завдання можна групувати і об’єднувати

26. МОТИВАЦІЯ: погляд громади
• Інформація про статус запитів доступна в
реальному часі
• Завдяки електронним банкам даних не
доводиться дублювати форми і бланки –
«заява в один клік»
• Інформація надходить у зручній формі
• Скорочення часу обробки запитів
• ВАЖЛИВО! Оскільки продукт не
пропрієтарний, не постає питання про
корупційну складову самого проекту

27. Контроль і аналіз
• Запуск Open-Source проектів із розробки
«оболонок» (чи утиліт)
– Аналіз критичних точок бізнес-процесів на
основі отриманих даних
– Лобіювання спрощення та поліпшення
процедур
– Рейтингування держслужбовців відповідно до
ефективності виконання ними завдань

28. Опції фінансування
• Бюджетні кошти
• Гранти міжнародних організацій, що опікуються
проблемами прозорості і боротьби з корупцією
• Пожертви громадян – кошти, ресурси, час і вмілі руки
• Інститути «краудфандінгу» - BigIdea, Kickstarter
• Впровадження продукту за кордоном (питання перекладу,
як правило, вирішується просто), що може здійснюватися
на платній основі
• Послуги з інтеграції продукту із системами класу ERP, CRM,
іншими системами управління підприємством

29. СИТУАЦІЇ ЗАСТОСУВАННЯ
Коли спілкування з урядом - ефективне

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

31. Анти-ДТП
• Проблема: На прямому відрізку дороги неподалік від дитячого
майданчика власники спорткарів люблять перевіряти «розгон
до 100»
– Підвищена небезпека в житловому районі
– Процедура контролю через ДАІ вимагає людських ресурсів,
встановлення штатного реєстратора швидкості – коштів з
місцевого бюджету
• Рішення: мешканці району використовують розроблене ПЗ
(прошивку) для пристрою на основі веб-камери (і/або інших
елементів), реєструють і встановлюють саморобний пристрій з
унікальним підписом неподалік від критичної точки
(наприклад, пішохідного переходу). Через Wi-Fi пристрій
реєструє перевищення швидкості (або інші порушення), і
надсилає скарги із фотодоказами в ДАІ