Закон за електронното управление – разяснения

Днес в парламента влязоха предложените от Министерски съвет изменения в закона за електронното управление. Най-долу в документа може да прочетете мотивите, но като участник в процеса на съставяне на текстовете, ще си позволя да направя малко по-детайлни разяснения (както направих и с другия закон, по който съм работил – за електронната идентификация).

Измененията се разделят на две: от една страна – създаване на държавна агенция и предприятие към нея, а от друга страна – подобряване и корекция на останалите текстове от съществуващия закон, например въвеждане на изисквания за отворен код.

Ще започна с Държавна агенция „Електронно управление“. Създава се агенция (на база на дирекция/дирекции от министерство на транспорта и ИА ЕСМИС, без нови държавни служители), която, грубо казано, да определя всички в държавата какво правят във връзка с електронното управление – какви системи и как се правят, как се интегрират, как се поддържат, и т.н. „Хоризонтални политики“ е изразът, който ще чуете най-често, като това включва отворени данни, информационна сигурност и други. Целта на агенцията е да бъде силна, т.е. да съсредоточи доста контрол, защото иначе положението е „всеки прави к’вото си иска, на парче“, което мисля е очевидно от почти несъществуващите (или поне невидими) резултати до момента. Агенцията ще замести министерството на транспорта, информационните технологии и съобщенията като орган за тези политики, вкл. като такъв, който налага актове за нарушения в закона (каквито до този момент няма, въпреки че никоя администрация реално не спазва този закон).

В чл.7в са разписани всички правомощия на председателя на агенцията (като орган на властта, представляващ агенцията). Контролът, който агенцията осъществява върху проектите за електронно управление е на всички нива – от проектна идея до последващ контрол. Неща, които по принцип изискват техническа експертиза и добра архитектурна представа. Агенцията дори участва в бюджетния процес, чрез съгласуване на разходите за е-управление. Грубо казано – ако агенцията сметне, че от някой проект няма нужда, би било доста трудно този проект да се финансира в пари от бюджета.

С това има два принципни проблема – първият е, че съсредоточаването на толкова правомощия (ако щете и „власт“) в агенцията, и по-специално – председателя ѝ, е рисковано и потенциално може да доведе до корупционни практики – напр. „дайте ми 10%, иначе няма да ви одобря проекта“. От друга страна, ако агенцията е нещо, което всеки може да заобиколи, то от нея няма смисъл. За да бъде адресиран този потенциален проблем съществува Раздел III, чл.7п и 7р – „отворено управление“. Регистрите, които агенцията и предприятието водят, в които е включен целият жизнен цикъл на проектите – от идея, през комуникацията между агенцията и съответната администрация, техническо задание, обявление за обществена поръчка, текущ и последващ контрол, отчитане на резултати и поддръжка – всичко е публично, и публикувано като отворени данни. Публичността сама по себе си не предотвратява корупцията и схемите, но дава възможност за обществен натиск. Дали такъв ще има, зависи от всички.

Вторият проблем е технологичната експертиза и опитът в ръководене на ИТ проекти. Тук идва държавното предприятие „Единен системен оператор“, което трябва да поеме този аспект – всички дейности на агенцията, които тя няма експертизата да извършва, се вършат от предприятието, където се дават (близко до) пазарни ИТ заплати – нещо, което към момента не е възможно в администрацията.

Как предприятието ще може да дава пазарни заплати? Това е сложната тема, която отне най-много време. Защото не е редно предприятието да получава държавна помощ и да е конкурент на пазара. Затова дейностите му са три вида:

  • подпомагане на (председателя на) агенцията, за което агенцията плаща на разходопокривен принцип
  • вътрешно възлагане (in-house procurement) – всяка администрация може да възложи една от няколко фиксирани в закона задачи на предприятието, като заплаща на разходопокривен принцип плюс до 50% от стандартната печалба в бранша (как се определя това – методики, тарифи – вижте вл. 7м, т.9-12). Дейностите на предприятието не включват разработка на софтуер, а само съпътстващи дейности, като управление на проекти от страна на възложителя (държавата), писане на технически задания, контрол и приемане на проекти. Аз си представям, че предприятието трябва да може да направи някакви много дребни, базови софтуерни неща – например да оправи някой дребен бъг извънгаранционно, вместо за това да се минава през цялата процедура по ЗОП (дори за „малка обществена поръчка“), но не знам дали би се стигнало до това.
  • дейности на свободния пазар – предприятието може да има дейност като всяка ИТ фирма, с две ограничения – не може да участва като изпълнител на държавни поръчки, на които то е писало заданието или то управлява проекта, или извършва контрол (логично), както и приходите от дейности на свободния пазар не могат да надвишават 20% от общите приходи.

Идеята е да няма неправомерно предимство на пазара, като в същото време все пак да може да извършва услуги в администрацията, които в момента тя няма капацитет да прави. Например писането на задания се случва или вътре в администрациите, което, заради липсата на техническа експертиза, е със спорно качество, или от външен изпълнител, който обаче лесно може да влезе в конфликт на интереси, като се разбере какво да пише с някоя друга фирма, която да кандидатства и да го спечели. Т.е. идеята е лошите практики да се изолират, без това да влияе негативно на свободния пазар.

Този модел на държавна агенция + държавно предприятие се използва (с малки вариации) на доста места в Европа – Австрия, Белгия, Португалия, отчасти Естония, Великобритания. Може би има и други. Т.е. „не откриваме топлата вода“.

В някакъв смисъл, агенцията, в лицето на председателя ѝ, се явява CIO на държавата – нещо, което съм смятал за нужно доста преди да се присъединя към кабинета на г-жа Бъчварова. Съответно, към председателя на агенцията трябва да имаме доста високи изисквания. В закона такива има доста малко, поради факта, че това, за съжаление, не е конкурсна длъжност. Това лично на мен не ми харесва много, но такава е концепцията в държавата. Все пак, председателят трябва да има опит в управлението на ИКТ проекти. Защо? Защото смятам, че за да управляваш електронното управление трябва да имаш основни технически познания. Да, всеки мениджър може да придобие такива, но не мога да не се съглася със Джоел Сполски, според когото технологични структури (компании в неговия случай, държавна агенция в нашия) се управляват много по-добре от технически грамотни хора. Поради тази причина е и изискването председателят да представи публично визията си за електронното управление. Да знаем от ден 1 дали председателят е човек, който знае за какво става дума, или ще говори общи приказки и тъпотии.

„Кой ще е председателят“, се питат доста хора. Аз лично нямам представа. Вървят всякакви слухове и спекулации, които по-скоро нямат общо с реалността. Председателят, в крайна сметка, се назначава от премиера.

Толкова за агенцията и предприятието. Сега няколко думи и за другите изменения:

  • Новата ал.4 на чл.4 дава правото на гражданите да следят кой какви данни е използвал за тях при вътрешноадминистративния обмен на данни. Т.е. когато някой държавен служител реши да провери имате ли имоти, това се записва и вие по закон имате право да го знаете. Това е практичен подход към защитата на личните данни – държавата вече така или иначе ги е събрала, и продължава да ги събира. От една страна е редно да ги ползва, за да ни улесни живота (като не ни кара да си попълваме адреса на всяка бланка, например), от друга страна следва да имаме контрол върху това какво се случва с нашите данни.
  • В настоящата форма съществува т.нар. „единна среда за обмен на електронни документи“ (ЕСОЕД). Тъй като това е конкретно архитектурно решение, то не е редно да бъде в закон. Дали такъв централизиран подход към обмена на документи между администрации (т.е. всичко минава през един умен „брокер“) е добра идея или не, няма значение – важното е, че не е редно то да бъде предопределено в закона. Поради това промените го премахват. Така или иначе е стояло там достатъчно дълго време, без да има реална полза от него – ЕСОЕД е изграден, но на практика не се ползва, а функциите му са дублирани от няколко други системи. Също така той се явява single point of failure – счупи ли се, спира държавата.
  • В момента се води специален регистър на електронните услуги. С измененията той се премахва, а в общия регистър на административните услуги се добавя колонка дали е електронизирана, което е по-логичният вариант.
  • Преди година говорих за отворен код в държавата. Сега в закона се добавя Раздел V – Изисквания към проектите и дейностите в областта на електронното управление. Тук се дефинира изискването, че всеки код, който е написан по поръчка за държавата, следва да бъде отворен. Но не просто да бъде качен някъде, а да се разработва на открито, в публично хранилище за код, поддържано от агенцията. Това хранилище ще бъде или GitHub, или ще се синхронизира с GitHub, така че да се използва потенциала на т.нар. „social coding“. Това не засяга готови системи, които държавата си поръчва – ако държавата иска да си купи ERP, CRM, ГИС или нещо такова, то изпълнителят няма причина да си отваря кода, който е търговска тайна – в този случай той продава само лиценза. Но за останалите случаи, кодът следва да е отворен. Защо това е нужно – опитвам се да го обясня в лекцията си от преди година.
  • Пак в раздел V се дефинират още доста нефункционални изисквания към софтуера. Те са по-скоро принципни изисквания, а не конкретни технологични такива – нуждата от backup-и, multi-tenancy, служебни интерфейси (напр. уеб-услуги) и т.н.
  • Към адресатите на закона се добавят и банките. Т.е. когато искате кредит, например, банките ще трябва да изискват по служебен път всичките документи и хартийки, които в момента вие трябва да обикаляте да събирате. Това е улеснение и за двете страни (при условие, че държавата осигури технически средства за това, разбира се).
  • Изменят се няколко други закона, които пречат на обменянето на данни между институциите. Най-важният е този за гражданската регистрация, където пише, че за да може някоя администрация да чете данни за гражданите, трябва да сключва споразумения с ГРАО. Това е доста непрактично и на практика спира прилагането на закона за електронно управление. Държавата, по ясни правила и с ясни ограничение, трябва да може да види кой ви е постоянния адрес, тъй като вече го има, вместо всеки път да ви кара да го пишете. Още повече, че е доста странно две държавни структури да сключват договори помежду си – отношенията им се уреждат с нормативни актове, не със споразумения.

Дали всичко това ще има положителен ефект – би трябвало. Но самото му написване не значи, че реформата е готова. По-скоро това е началото на реформата. Дали агенцията ще действа така, както сме предложили, дали няма да се намерят начини за заобикаляне на смислените правила, дали депутатите ще приемат закона в този му вид – няма как да знам. Но ако законът мине, и през пролетта имаме агенция, то аз ще следя отблизо дейността ѝ, без значение дали още съм съветник или не.

4 comments

  1. „Тук се дефинира изискването, че всеки код, който е написан по поръчка за държавата, следва да бъде отворен.“
    Това звучи прекалено хубаво. Доколко широко е било обсъждано? Доколко голяма е според теб опасността тепърва „заинтересовани“ страни да изпищят и това нещо да отпадне набързо?

  2. Било е обсъждано, бизнесът официално не е против, но да, има опасност да отпадне.

  3. В текста не видях конкретна дефиниция на „отворен код“? Това умишлено ли е? Предполагам, че някакъв конкретен лиценз за този отворен код няма да се предписва / рамкира в закона?

  4. Дефиниция има в самия закон. И не, конкретен лиценз не се фиксира. Идеята е да може кодът да се преизползва от всеки, за всякакви цели. Платен е с публични средства – ако някой му намери добро приложение, да го ползва.

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *