1. Уряд Open Source
Публічне API для виконавчої влади всіх рівнів
Автор ідеї: Василь Жук
www.facebook.com/vasyl.zhuk
2. В чому сила Open Source?
• Замість обмеженого продукту –
необмежена кількість ідей від спільноти
• Замість обмежених ресурсів – колективна
творчість тих, хто справді любить
створювати
Все, що необхідно, – створити умови для того,
щоб спільнота зробила свою справу!
3. Public API
• Система команд (запитів), доступна через
мережу, що дозволяє отримувати, вносити
та управляти даними на певному сервісі
• Існуючі Public API від Google, Yandex,
Facebook, Twitter та ін. ресурсів стали
основою для величезної кількості стартап-
проектів, зробивши доступними для аналізу
різноманітні дані – від геолокації до
соціальних графів
5. Уряд як сервіс (1)
• Як працює урядова організація зараз
Обробка запиту у стилі
«Чорна скринька»:
процеси обробки запиту не
доступні зацікавленій стороні
- громадянину
Запит
Результат
Відповідь
Вимога
додаткових
дій від суб’єкта
6. Уряд як сервіс (2)
• Як наслідок:
Обмежене
коло осіб
може
аналізувати
доцільність і
ефективність
процедур
Немає жодної
мотивації для
підвищення
ефективності
роботи
органів
1. Сприятливи
й ґрунт для
розвитку
корупції
2. Падіння
ефективності
7. Уряд як сервіс (3)
В ідеалі діяльність уряду має реалізовувати
такі права громадян:
• Знати, як і ким розглядається питання
• Бачити загальну картину процесу
• Отримати адекватне пояснення
• Вимагати більш ефективного виконання
урядом своїх обов’язків
• Право контролювати на всіх стадіях
8. Характеристика уряду як системи
• Існує потік задач:
– Запити від громадян і організацій
– Запити від інших органів
• Кожна задача вимагає певних стадій обробки, що
характеризуються:
– Відповідальною стороною
– Необхідними ресурсами/передумовами/підзадачами
– Процедурою обробки
– Часовими рамками
– Очікуваним(и) результатом(ами) / наслідками
– Напрямком передачі в залежності від результату
9. Проблематика системи
• Немає простого способу отримати загальну
картину в цілому по системі
• Неефективна взаємодія ланок системи
– Часто надлишкова інформація
– Нераціональна і обмежена
комунікація/зворотній зв’язок
• Контрольні механізми – аудит або ревізія –
надто сфокусовані на обмеженій кількості
показників (і їм бракує мотивації)
10. Національні традиції неефективності
• Прийомні/неприйомні години кожної
інстанції знижують пропускну здатність
• Надлишкова неефективна документація
• Надлишкові та невиправдані процеси
• Нечітка субординація і система
відповідальності
11. Підсумок
• Громадяни не є клієнтами для апарату
влади
• Державний апарат не є конкурентоздатним
для задоволення законних потреб
громадян
13. «Задачник» для уряду
Потрібен «кістяк» - допоміжна система, яка б
формалізувала процедури і відповідальність
•Системи такого класу існують і ефективно використовуються в ІТ-
сфері – т.з. системи Bug Tracking, або ж «задачники»
•Кожен запит в системі подається як талон (ticket), що збирає і несе
в собі всю необхідну інформацію для виконання задачі
•Талони мають такі ознаки як: пріоритет, очікуваний/необхідний
час виконання, відповідальний виконавець, статус та ін.
•Талони можуть враховувати підзадачі, результати одне одного,
об’єднуватися в більш узагальнені задачі
•Задачники починають з успіхом проникати в інші сектори,
зокрема у фінансовий
14. Public API для уряду
• Хоча «задачник» сам по собі дозволить більш
ефективно і прозоро обробляти запити, цього
недостатньо для ефективного публічного контролю
• Формалізована і захищена система API дозволить:
– Спростити комунікацію між однорідними «задачниками»,
що обслуговують різні органи влади
– Відкрити можливості для аналізу неконфіденційної
(неперсональної) інформації щодо виконання запитів
органами державної влади в усіх необхідних (затребуваних
громадою) формах і аспектах
– Інтегрувати наявні інформаційні ресурси для отримання
узгодженої якісної інформації як для адміністративних, так і
для аналітичних потреб
15. Активна творчість спільноти
• Маючи надійний безперервний потік даних від уряду,
ІТ-спільнота буде здатна створювати і розвивати утиліти:
– Проміжні інтерфейси для об’єднання з уже існуючими
сервісами (наприклад, вже наявними ІТ-порталами від
громади та держорганів), статистичними збірками (т.з.
порталами відкритих даних)
– Програми для стаціонарних та мобільних пристроїв
– Прошивки для автоматизованих пристроїв (таких як
дорожні реєстратори, лічильники, інші спеціалізовані
сенсори тощо)
– Різноманітні інформ. звіти (наприклад так звані
«інформери»), що легко інтегруються на веб-ресурси і
дозволяють в реальному часі бачити «зріз» того чи іншого
аспекту роботи органу (органів)
17. 1. Створення базового продукту
Створити базовий «задачник» для уряду як ядро і основну складову
системи
Необхідні риси кінцевого продукту:
– Наскільки можливо – використовувати готові напрацювання і продукти з
відкритим кодом
– Можливість гнучко задавати формалізацію адміністративних процесів
(послідовну низку фаз обробки задачі), щоб потім впроваджувати в
практику аналогічних установ
– Надійний захист конфіденційної інформації (персональні ключі,
шифрування), персоналізація дій (електронні підписи)
– Можливості горизонтальної (кластер) і вертикальної (ієрархія) інтеграції
окремих інстанцій (серверів з установленим ПЗ)
• Горизонтальна інтеграція забезпечить порівняно дешевий спосіб масштабувати
потужність системи в межах одного підрозділу
• Вертикальна інтеграція через однорідне API дозволить швидко і без зайвих затрат
інтегрувати додаткові інстанції, коли все нові і нові органи будуть переходити на
«задачник»
18. 2. Впровадження
1. Взаємодія із органами влади різних рівнів
(лобіювання, громадський тиск) щодо переходу на
клієнто-орієнтовану прозору систему роботи через
задачник
2. Аналіз адмін-процесів установ різних рівнів,
послідовна інтеграція впроваджених рішень через:
– Формалізації законних процедур обробки запитів
– Навчання співробітників установ (або виділення
відповідального)
3. Інформування громади щодо можливостей
застосування і контролю
4. Лобіювання законодавчої бази (щодо електронного
документообігу, доказовості фото- і відеозйомки тощо)
19. Запуск еволюції систем контролю
• Заохочення ІТ-спільноти до творчості на
основі аналізу отриманих даних
– Конкурси мобільних аплікацій
– Хакатони
– «Узаконення» висновків аналітичних програм
(як-то вплив рейтингу службовця в системі на
просування і оклад)
20. МОТИВАЦІЯ: погляд розробників
• Завдяки використанню типового рішення для
інтеграції відбувається:
– Скорочення ресурсів, затрачених на розробку
– Відтак затрати на кожне нове впровадження це:
– Аналіз і формалізація адмін-процесів
– Формування довідників та процедур
– Запуск сервера
– Навчання співробітників
– Простота інтеграції (при виході нових версій всі
інстанції оновлюються, і лишаються ідеально
сумісними)
21. МОТИВАЦІЯ: погляд працівників
держапарату
• Зменшення затрат часу на написання різного
роду звітів, зменшення їх кількості – адже вони
самі собою формуються в системі
• Спрощення організації робочого процесу –
один список завдань, сортований по
пріоритетах, типові рішення, нагадування
• Спрощення отримання інформації – завдяки
інтеграції з банками даних не доведеться
робити повторні запити і накопичувати
«макулатуру», все необхідне – під рукою
22. МОТИВАЦІЯ: погляд громади
• Інформація про статус запитів доступна в
реальному часі
• Завдяки електронним банкам даних не
доводиться дублювати форми і бланки –
«заява в один клік»
• Інформація надходить у зручній формі
• Скорочення часу обробки запитів
• ВАЖЛИВО! Оскільки продукт не
пропрієтарний, не постає питання про
корупційну складову самого проекту
23. Контроль і аналіз
• Запуск Open-Source проектів із розробки
«оболонок» (чи утиліт)
– Аналіз критичних точок бізнес-процесів на
основі отриманих даних
– Лобіювання спрощення та поліпшення
процедур
– Рейтингування держслужбовців відповідно до
ефективності виконання ними завдань
24. Опції фінансування
• Бюджетні кошти
• Гранти міжнародних організацій, що опікуються
проблемами прозорості і боротьби з корупцією
• Пожертви громадян – кошти, ресурси, час і вмілі
руки
• Інститути «краудфандінгу» - BigIdea, Kickstarter
• Впровадження продукту за кордоном (питання
перекладу, як правило, вирішується просто), що
може здійснюватися на платній основі
26. Аварійний спостерігач
• Проблема: поява ям на дорогах, пошкодження
або неналежна якість об’єктів комунальної
власності не завжди вчасно усувається
• Рішення: мобільна програма для смартфонів
дозволяє зареєстрованим користувачам
сфотографувати аварію і з даними геолокації
надіслати у відповідний територіальний орган
для якнайшвидшого усунення (і прослідкувати
як швидко це станеться)
27. Анти-ДТП
• Проблема: На прямому відрізку дороги неподалік від дитячого
майданчика власники спорткарів люблять перевіряти «розгон
до 100»
– Підвищена небезпека в житловому районі
– Процедура контролю через ДАІ вимагає людських ресурсів,
встановлення штатного реєстратора швидкості – коштів з
місцевого бюджету
• Рішення: мешканці району використовують розроблене ПЗ
(прошивку) для пристрою на основі веб-камери (і/або інших
елементів), реєструють і встановлюють саморобний пристрій з
унікальним підписом неподалік від критичної точки
(наприклад, пішохідного переходу). Через Wi-Fi пристрій
реєструє перевищення швидкості (або інші порушення), і
надсилає скарги із фотодоказами в ДАІ