уряд Open source (1)

280 views

Published on

1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
280
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

уряд Open source (1)

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

×