Проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги

Ниво на конфиденциалност 1 [TLP-GREEN] РЕПУБЛИКА БЪЛГАРИЯ МИНИСТЪР НА ЕЛЕКТРОННОТО УПРАВЛЕНИЕ Проект! ДО МИНИСТЕРСКИЯ СЪВЕТ НА РЕПУБЛИКА БЪЛГАРИЯ ДОКЛАД от Валентин Мундров – министър на електронното управление ОТНОСНО: Проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги, приета с Постановление № 3 на Министерския съвет от 2017 г. УВАЖАЕМИ ГОСПОДИН МИНИСТЪР-ПРЕДСЕДАТЕЛ, УВАЖАЕМИ ЗАМЕСТНИК МИНИСТЪР-ПРЕДСЕДАТЕЛИ, УВАЖАЕМА ГОСПОЖО МИНИСТЪР, УВАЖАЕМИ ГОСПОДА МИНИСТРИ, На основание чл. 31, ал. 2 от Устройствения правилник на Министерския съвет и на неговата администрация, внасям за разглеждане от Министерския съвет проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги, приета с Постановление № 3 на Министерския съвет от 2017 г. (НОИИСРЕАУ). Законът за администрацията предвижда общите правила за организацията на административното обслужване в администрацията да се определят с наредба, приета от Министерския съвет (чл. 5а, ал. 1). Това е Наредбата за административното обслужване (НАО), която задължава администрациите да осигуряват електронни адреси и телефони за връзка за комуникация с потребителите (чл. 8а, ал. 2), но не регламентира и обратния Ниво на конфиденциалност 1 [TLP-GREEN] подход. Законодателят частично е предвидил конкретен механизъм за проактивно осъществяване на контакт с физическо лице от страна на административен орган. Съгласно чл. 18а, ал. 12 от Административнопроцесуалния кодекс, когато с индивидуален административен акт се създават права или задължения за определен срок, административните органи, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги, изпращат информация за изтичането на срока до лицата, за които се отнася актът, в случай че разполагат с техни електронни адреси. Не е предвидено уведомяването чрез телефон, нито осъществяването на контакт с гражданите в хипотези, различни от изтичане на определен срок. Съгласно чл. 26, ал. 2 от Закона за електронното управление (ЗЕУ) връчването на електронните изявления от доставчиците на електронни административни услуги може да се извършва чрез изпращане на съобщение на електронния адрес, съдържащо информация за изтегляне на съставения документ от информационна система за сигурно електронно връчване (ССЕВ), поддържана от Министерство на електронното управление (МЕУ), или от портала на електронното управление по чл. 12, ал. 1 от ЗЕУ. Документите се смятат за връчени с изтеглянето им. Като препоръчителен стандарт за качество на административното обслужване е дефиниран Стандарт за проактивно информиране на потребителя за резултата от заявената услуга – администрацията по своя инициатива уведомява потребителите по електронна поща, по телефон или по друг начин за статуса на разглежданото заявление/искане, включително за издаден акт, съответно за готов резултат от услугата, в т.ч. и при предсрочно издаване/предоставяне (т. 15 от Приложение № 8 към чл. 20, ал. 3, буква „б“ от НАО). В действащото законодателство обаче липсват конкретни разпоредби, които да уредят процеса по уведомяване на гражданина в тези случаи. Видно от цитираната фрагментирана уредба, към настоящия момент не е нормативно уредена и реализирана възможността за проактивно уведомяване на гражданите относно определени факти и обстоятелства, които засягат техни права и законни интереси, в т.ч. за получаване на резултат от изпълнение на електронни административни услуги, както и на други документи или актове, при които връчване или съобщаване се изисква от закон. В този смисъл, държавните институции не се възползват адекватно от наличните технологични условия, практики и дигитални умения на гражданите, свързани с използването на смартфони за достъп до интернет и на електронна поща. В тази връзка, с оглед преодоляване на тази нормативна празнота са и първата група промени, предложени с проекта на акт. Предложението произтича от необходимостта освен по реда на чл. 26 от ЗЕУ, връчване на електронни документи по чл. 27, ал. 4 от НОИИСРЕАУ, за които връчване или съобщаване се изисква от нормативен акт, да може да се извърши и чрез осигуряване на възможност за достъп до ССЕВ и с облекчен метод – чрез еднократен код за достъп до системата. Идеята е по този начин да може да се осигурява бърз, достъпен и защитен начин за връчване на електронни документи на физически лица, включително такива без КЕП. Механизмът е технологично приложим в кратки срокове и не изисква значителни промени в съществуващата инфраструктура. Предложението не отменя вече уредените начини за връчване чрез ССЕВ, а допълва правната рамка с временна алтернатива до внедряването на националната схема за електронна идентификация (и за определен срок след това). Втората група предложени с проекта на акт промени в НОИИСРЕАУ са обусловени от съществуващите към момента системни слабости при използването на електронни административни услуги по ЗЕУ, свързани с електронната идентификация на гражданите. Към настоящия момент физическите и юридическите лица имат възможност да се идентифицират при заявяване на електронни административни услуги 2 Ниво на конфиденциалност 1 [TLP-GREEN] чрез средствата за електронна идентификация, регламентирани в чл. 5, ал. 2 от ЗЕУ и в § 5 от Преходните и заключителни разпоредби на НОИИСРЕАУ. Едно от средствата за електронна идентификация, предвидено в чл. 5, ал. 2 от ЗЕУ, е електронният идентификатор, издаван от министъра на вътрешните работи по Закона за електронната идентификация (ЗЕИ), който следва да се съдържа в документите за самоличност на гражданите. Поради факта, че понастоящем все още не се издават документи за самоличност, които да съдържат удостоверения за електронна идентичност, част от Националната схема за електронна идентификация по ЗЕИ, административните органи предоставят достъп до електронните си административни услуги, включително през портала на електронното управление, поддържан от МЕУ, чрез квалифициран електронен подпис (КЕП), Персонален идентификационен код (ПИК) на Националната агенция за приходите и ПИК на Националния осигурителен институт. Значителна част от електронните административни услуги се заявяват чрез средства за електронна идентификация с ниво на осигуреност „високо“, на което отговаря именно КЕП. От друга страна обаче, макар притежаването на КЕП да е свързано с минимални разходи за неговото придобиване и поддържане, той се явява технически усложнено решение за голяма част от гражданите и юридическите лица, което стеснява кръга на лицата, които притежават такъв подпис. От друга страна, ПИК се издават безплатно на гражданите, но са с ниско ниво на осигуреност и чрез тях могат да се заявяват само определени административни услуги. Поради това е необходимо да бъде нормативно уреден улеснен способ за електронна идентификация на физически лица при връчване на електронни документи – резултат от изпълнение на електронни административни услуги, както и на други документи или актове, при които връчване или съобщаване се изисква от закон. Такъв способ ще е именно еднократният код за достъп до ССЕВ в комбинация с определена категория данни, посочвани от лицето при заявяване на административна услуга. На следващо място, с проекта на акт се предлага прецизиране на нормативната уредба, регламентираща процесите по планиране, вписване, утвърждаване и контрол на дейностите, проектните предложения и техническите спецификации в областта на електронното управление. Съгласно чл. 38, ал. 4 от НОИИСРЕАУ при изготвяне на технически спецификации за провеждане на обществени поръчки, чиито обхват включва само дейности по адаптиране на информационни системи, регистри или бази данни във връзка с въвеждане на еврото в Република България, възложителите могат да изготвят техническите си спецификации на базата на образец съгласно Приложение № 2 към наредбата. Разпоредбата е въведена като временна мярка, свързана с подготовката и техническата адаптация на информационните системи за въвеждане на еврото в Република България. С приключването на основните етапи на този процес и интегрирането на съответните изисквания в общите технически и административни правила, необходимостта от поддържане на отделен специфичен образец отпада. Поради това разпоредбата е загубила своето самостоятелно практическо значение и поддържането ѝ би създало излишна нормативна тежест и предпоставки за различно тълкуване. Предложените изменения са насочени към премахване на вече ненужни временни разпоредби, повишаване качеството на подготвяната от администрациите информация, осигуряване на яснота по отношение на сроковете за вписване на данни и укрепване на контролните механизми при предварителен и последващ контрол. С проекта на акт се предлагат промени и по отношение на формата, използван за издаваните от администрациите електронни документи, като се предлага това да е PDF. PDF (Portable Document Format) е отворен стандарт за обмен на документи, който става международен стандарт през 2008 г. Идеята на формата е да представя документите по един и същи начин, независимо от хардуер, операционна система или приложен софтуер, 3 Ниво на конфиденциалност 1 [TLP-GREEN] като съдържа текст, шрифтове, изображения и други елементи. Форматът в своята разновидност Portable Document Format/Archival (PDF/A) представлява общоприет формат за дългосрочно съхранение и архивиране на електронни документи. С Решение за изпълнение (ЕС) 2015/1506 на Комисията от 8 септември 2015 година за определяне на спецификации, отнасящи се до форматите на усъвършенствани електронни подписи и усъвършенствани печати, които трябва да бъдат признати от органите от публичния сектор съгласно член 27, параграф 5 и член 37, параграф 5 от Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета относно електронната идентификация и удостоверителните услуги при електронни трансакции на вътрешния пазар, Комисията определя PDF като един от основните формати, които да се признават от държавите членки при изискване на усъвършенстван електронен подпис или усъвършенстван електронен подпис, основан на квалифицирано удостоверение, както е предвидено в член 27, параграфи 1 и 2 от Регламент (ЕС) № 910/2014. В тази връзка и с оглед предвидените в Наредбата за удостоверенията за електронен подпис в администрациите промени, свързани с използването на валидатора на Комисията при валидиране на електронни подписи, трябва да се подчертае, че той функционира успешно при прочитане на подпис от PDF (PAdES). В заключение, PDF е сигурен формат, който позволява многократно възпроизвеждане без загуба на данни при всякакви устройства и без значение от софтуера, като гарантира дългосрочното съхранение на документите. Това го прави изключително подходящ за използване от администрацията, особено при предоставянето на резултат от електронни административни услуги. С предложените с проекта на акт промени в НОИИСРЕАУ се цели: • Оптимизиране и подобряване на процесите по връчване на готов резултат от заявена електронна административна услуга; • Намаляване на административната тежест за гражданите, заявители на електронни административни услуги, и подобряване на административното обслужване; • Разширяване на възможностите и средствата за електронна идентификация на гражданите и улесняване предоставянето на електронни административни услуги; • Постигане на по-висока прозрачност, предвидимост и ефективност при управлението на информационните ресурси в публичния сектор. Изготвената частична предварителна оценка на въздействието по проекта на акт е съгласувана от дирекция „Координация и модернизация на администрацията“ на Министерския съвет. Съгласно чл. 26, ал. 2-4 от Закона за нормативните актове проектът на Постановление на Министерския съвет е публикуван на интернет страницата на Министерството на електронното управление и на Портала за обществени консултации на Министерския съвет за срок от 30 дни. Направените бележки и предложения от проведените обществени консултации са отразени, съгласно приложената справка. Проектът на Постановление е съгласуван в съответствие с разпоредбите на чл. 32 от Устройствения правилник на Министерския съвет и на неговата администрация. Направените бележки и предложения са отразени, съгласно приложената справка. Предложеният проект на Постановление не води до въздействие върху държавния бюджет и не са необходими допълнителни разходи/трансфери/други плащания по бюджета на Министерството на електронното управление, поради което към проекта е приложена финансова обосновка, съгласно приложение № 2.2 към чл. 35, ал. 1, т. 4, буква „б“ от Устройствения правилник на Министерския съвет и на неговата администрация. Приемането на проекта на акт не води до изменение в целевите стойности на показателите за изпълнение, в това число и ключовите индикатори. С проекта на Постановление не се въвеждат норми на европейското право, поради което не е приложена справка за съответствието му с него. 4 Ниво на конфиденциалност 1 [TLP-GREEN] УВАЖАЕМИ ГОСПОДИН МИНИСТЪР-ПРЕДСЕДАТЕЛ, УВАЖАЕМИ ЗАМЕСТНИК МИНИСТЪР-ПРЕДСЕДАТЕЛИ, УВАЖАЕМА ГОСПОЖО МИНИСТЪР, УВАЖАЕМИ ГОСПОДА МИНИСТРИ, Във връзка с гореизложеното и на основание на чл. 8, ал. 2 от Устройствения правилник на Министерския съвет и на неговата администрация, предлагам Министерският съвет да разгледа и приеме предложения проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги, приета с Постановление № 3 на Министерския съвет от 2017 г. ВАЛЕНТИН МУНДРОВ Министър на електронното управление 5

Р Е П У Б Л И К А Б Ъ Л Г А Р И Я М И Н И С Т Е Р С К И С Ъ В Е Т Проект! П О С Т А Н О В Л Е Н И Е № от ………………. 2025 година ЗА изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги, приета с Постановление № 3 на Министерския съвет от 2017 г. (обн., ДВ, бр. 5 от 2017 г.; изм. и доп., бр. 66 от 2018 г., бр. 4 от 2020 г., бр. 47 от 2022 г. и бр. 80 от 20.09.2024 г.) М И Н И С Т Е Р С К И Я Т С Ъ В Е Т П О С Т А Н О В И: § 1. В чл. 15б се правят следните изменения и допълнения: 1. В ал. 1 думите „позволяващи вписване, заличаване и промяна на данни в регистър, както и всички други операции, предвидени в нормативен акт“ и запетаята пред тях се заличават. 2. Създава се нова ал. 2: „(2) При администриране на регистъра по ал. 1 заявителят използва реализираните функционалности на Информационната система за централизирано изграждане и поддържане на регистри по отношение на процесите по регистриране на заявления, проверка на достоверността и актуалността на данните, вписване, заличаване и промяна на данни, както и всички други специфични за регистъра операции, предвидени в нормативен акт.“ 3. Досегашните ал. 2 и 3 стават съответно ал. 3 и 4. § 2. В глава трета, раздел I „Предоставяне на електронни административни услуги“ се създава чл. 27а: „Еднократен код за достъп до ССЕВ Чл. 27а. (1) Освен по реда на чл. 26 от Закона за електронното управление, електронни документи по чл. 27, ал. 4, за които връчване или съобщаване се изисква от нормативен акт, се считат за връчени след изтеглянето им посредством еднократен код за достъп до ССЕВ. (2) Ръководителите на администрациите или упълномощени от тях лица предоставят на Министерството на електронното управление издадените от тях документи или актове по ал. 1, заедно с единен граждански номер/личен номер на чужденец, номер на мобилен телефон и/или адрес на електронна поща на лицето, за което е издаден документът, както и уникален регистров идентификатор на заявлението за административна услуга. (3) Министерството на електронното управление уведомява лицето за изготвения за него документ по ал. 1 чрез изпращане на съобщение на неговия мобилен телефон и/или адрес на електронна поща. Съобщението съдържа електронна връзка (линк) за изтегляне на документа по ал. 1, на която лицето въвежда своите: 1. единен граждански номер/личен номер на чужденец; 2. някой от следните данни: а) номер на документ за самоличност; б) номер на свидетелство за управление на моторно превозно средство; в) уникален регистров идентификатор на заявлението; 3. номер на мобилен телефон и/или адрес на електронна поща. (4) След установяване на данните на лицето на посочения от него номер на мобилен телефон и/или адрес на електронна поща се изпраща съобщение, съдържащо еднократен код за достъп до ССЕВ. Документът се смята за връчен с изтеглянето му. (5) Необходимите за идентифициране на лицето данни по ал. 3, т. 1 и т. 2 букви „а“ и „б“ се предоставят на Министерството на електронното управление от Министерството на вътрешните работи по служебен път, чрез централния компонент по чл. 7, ал. 8 (RegiX).“ § 3. В чл. 36 ал. 4 се изменя така: „(4) За издаваните от администрациите електронни документи се използва ISО 32000 – Portable Document Format (PDF), освен ако няма обоснована технологична необходимост от друг формат.“ § 4. В чл. 38 се правят следните изменения: 1. Алинея 4 се отменя. 2. В ал. 6 думите „Образците по ал. 3 и 4“ се заменят с „Образеца по ал. 3“. 3. В ал. 7 думите „образците по ал. 3 и 4“ се заменят с „образеца по ал. 3“. 4. В ал. 8 думите „образците по ал. 3 и 4“ се заменят с „образеца съгласно приложение № 1“. § 5. В чл. 52 се правят следните изменения и допълнения: 1. В ал. 1, т. 1: а) в буква „в“ накрая се поставя запетая и се добавя „включващо мотивирана аргументация за необходимостта от реализирането им“; б) буква „е“ се изменя така: „е) план-график за изпълнение на дейностите;“; в) създава се буква „ж“: „ж) индикативен бюджет, аргументиран по начин, доказващ целесъобразността му, съгласно правилата по чл. 53, ал. 2;“. 2. Алинея 3 се изменя така: „(3) Лицата по ал. 2 вписват данните по ал. 1, т. 1 и 2: 1. преди публикуването на обществената поръчка, включително и за рамково споразумение, в Регистъра на обществените поръчки; 2 2. преди обявяването на вътрешен конкурентен подбор по действащо рамково споразумение или преди възлагането на заявка по действащо рамково споразумение.“ § 6. В чл. 53 се правят следните изменения и допълнения: 1. Създава се нова ал. 5: „(5) Неизпълнението на дадените предписания по ал. 4 при последващо вписване на проектното предложение, дейността или техническата спецификация, е основание за постановяване на отказ за утвърждаване на проектно предложение или дейност или за удостоверяване на съответствие с изискванията на чл. 58а от ЗЕУ на техническа спецификация.“. 2. Досегашните ал. 5 – 8 стават съответно ал. 6 – 9. § 7. В § 5 от преходните и заключителни разпоредби се правят следните изменения и допълнения: 1. В ал. 1 думите „В срок една година“ се заменят с „В срок до три години“. 2. В ал. 2 думите „В срок три години“ се заменят с „В срок до три години“. 3. Създава се ал. 3: „(3) В срок до три години след въвеждането в продукционен режим на националната схема по ал. 1 за електронна идентификация на физически лица при връчване на електронни документи по чл. 27, ал. 4 може да се използва и еднократният код за достъп до ССЕВ в комбинация с данните по чл. 27а, ал. 3.“ § 8. Приложение № 1 към чл. 38, ал. 3 се изменя така: „Приложение № 1 към чл. 38, ал. 3 [Възложител] ТЕХНИЧЕСКА СПЕЦИФИКАЦИЯ за [Име на проект] СЪДЪРЖАНИЕ СЪДЪРЖАНИЕ ..............................................................................................................................2 1. РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ ............................4 1.1. Използвани акроними ..............................................................................................4 1.2. Технологични дефиниции .......................................................................................5 1.3. Дефиниции за нива на електронизация на услугите .............................................7 2. ВЪВЕДЕНИЕ ............................................................................................................8 2.1. Цел на документа .....................................................................................................8 3 2.2. За възложителя – функции и структура .................................................................8 2.3. За проекта..................................................................................................................9 2.4. Нормативна рамка ....................................................................................................9 3. Цели, обхват и очаквани резултати от изпълнение на проекта .........................10 3.1. Общи и специфични цели на проекта ..................................................................10 3.2. Обхват на проекта ..................................................................................................10 3.3. Целеви групи...........................................................................................................11 3.4. Очаквани резултати................................................................................................11 3.5. Период на изпълнение ...........................................................................................12 4. ТЕКУЩО СЪСТОЯНИЕ .......................................................................................12 5. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА.................................12 5.1. Общи изисквания към изпълнението на обществената поръчка .......................12 5.2. Общи организационни принципи .........................................................................12 5.3. Управление на проекта ..........................................................................................13 5.4. Управление на риска ..............................................................................................14 6. ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА .......................................................15 6.1. Анализ на данните и изискванията.......................................................................15 6.1.1. Специфични изисквания към етапите на бизнес анализа при разработка, надграждане или внедряване на информационна система.......................................................16 6.1.2. Специфични изисквания при оптимизиране на процесите по заявяване на електронни услуги и електронни административни услуги (сгл. §1, т. 2 от ЗЕУ) в зависимост от заявителя 17 6.1.3. Изисквания за оптимизиране на процесите по подаване на декларации, изискуеми в съответствие с нормативната уредба и вътрешните правила ............................20 6.1.4. Изисквания към регистрите и предоставянето на административните услуги ……………………………………………………………………………… …… 21 6.2. Изготвяне на системен проект ..............................................................................21 6.3. Разработване на софтуерното решение ................................................................22 6.4. Тестване...................................................................................................................22 6.5. Внедряване ..............................................................................................................22 6.6. Обучение .................................................................................................................22 6.7. Гаранционна поддръжка ........................................................................................23 6.7.1. Обхват на дейностите по гаранционна поддръжка.............................................23 6.7.2. Управление на инциденти .....................................................................................24 4 6.7.3. Управление на проблеми .......................................................................................25 6.7.4. Управление на качеството при отстраняване на инциденти и проблеми. Параметри на качеството.............................................................................................................25 6.7.5. Минимални изисквания към параметрите на качеството ..................................25 6.7.6. Управлението на промените..................................................................................29 7. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ ......................................................................................30 7.1. Функционални изисквания към информационната система..............................31 7.1.1. Интеграция с външни информационни системи .................................................31 7.1.2. Използване на интеграционен слой на електронното управление ....................33 7.1.3. Технически изисквания към интерфейсите .........................................................34 7.1.4. Електронна идентификация на потребителите ...................................................36 7.1.5. Отворени данни ......................................................................................................38 7.1.6. Формиране на изгледи ...........................................................................................39 7.1.7. Администриране на Системата .............................................................................39 7.2. Нефункционални изисквания към информационната система..........................40 7.2.1. Авторски права и изходен код ..............................................................................40 7.2.2. Системна и приложна архитектура ......................................................................41 7.2.3. Повторно използване (преизползване) на ресурси и готови разработки..........45 7.2.4. Изграждане и поддръжка на множество среди ...................................................48 7.2.5. Процес на разработка, тестване и разгръщане ....................................................49 7.2.6. Бързодействие и мащабируемост .........................................................................50 7.2.7. Информационна сигурност и интегритет на данните.........................................56 7.2.8. Използваемост ........................................................................................................59 7.2.9. Системен журнал....................................................................................................70 7.2.10. Дизайн на бази данни и взаимодействие с тях ....................................................72 7.2.11. Изисквания по отношение на киберсигурност в съответствие с чл. 12, ал. 1 от НМИМИС .......................................................................................................................74 8. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА 77 8.1. Дейност 1 [Наименование на дейността] .............................................................77 8.1.1. Описание на дейността ..........................................................................................77 8.1.2. Изисквания към изпълнение на дейността ..........................................................77 8.1.3. Очаквани резултати................................................................................................77 5 8.2. Дейност 2 [Наименование на дейността] .............................................................77 8.2.1. Описание на дейността ..........................................................................................77 8.2.2. Изисквания към изпълнение на дейността ..........................................................77 8.2.3. Очаквани резултати................................................................................................77 8.3. Дейност 3 [Наименование на дейността] .............................................................77 8.3.1. Описание на дейността ..........................................................................................77 8.3.2. Изисквания към изпълнение на дейността ..........................................................77 8.3.3. Очаквани резултати................................................................................................77 8.4. Дейност 4 [Наименование на дейността] .............................................................77 8.4.1. Описание на дейността ..........................................................................................77 8.4.2. Изисквания към изпълнение на дейността ..........................................................77 8.4.3. Очаквани резултати................................................................................................77 8.5. Дейност 5 [Наименование на дейността] .............................................................77 8.5.1. Описание на дейността ..........................................................................................77 8.5.2. Изисквания към изпълнение на дейността ..........................................................77 8.5.3. Очаквани резултати................................................................................................77 9. ДОКУМЕНТАЦИЯ ................................................................................................77 9.1. Изисквания към документацията..........................................................................77 9.2. Прозрачност и отчетност .......................................................................................78 9.3. Системен проект.....................................................................................................79 9.4. Техническа документация .....................................................................................79 9.5. Протоколи ...............................................................................................................80 9.6. Комуникация и доклади.........................................................................................80 9.6.1. Встъпителен доклад ...............................................................................................80 9.6.2. Междинни доклади ................................................................................................80 9.6.3. Окончателен доклад ...............................................................................................81 10. РЕЗУЛТАТИ ...........................................................................................................81 1. РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ Използвани акроними 6 Акроним Описание Технологични дефиниции Виртуална Инфраструктура, която на база съществуваща физическа комуникационна свързаност, предоставена от МЕУ, предоставя възможност за инфраструктура изграждане на отделни и защитени виртуални мрежи за всяка една от структурите в сектора, при гарантиране на сигурен и защитен обмен на информация в тях. 7 АИС Автоматизирана информационна система АМС Администрация на Министерския съвет АО Административен орган АОП Агенция по обществени поръчки АПК Административнопроцесуален кодекс БУЛСТАТ Регистър Булстат МЕУ Министерство на електронното управление ЗДОИ Закон за достъп до обществена информация ЗЕУ Закон за електронното управление ИТ Информационни технологии КАО Комплексно административно обслужване ТР Търговски регистър ДХЧО Държавен хибриден частен облак ЦАИС Централизирана автоматизирана информационна система SDK Software development kit API Application programming interface/Приложно програмен интерфейс Термин Описание Държавен хибриден Централизирана на ниво държава информационна инфраструктура частен облак (сървъри, средства за съхранение на информация, комуникационно оборудване, съпътстващо оборудване, разпределени в няколко локации, в помещения, отговарящи на критериите за изграждане на защитени центрове за данни), която предоставя физически и виртуални ресурси за ползване и администриране от секторите и структурите, които имат достъп до тях, в зависимост от нуждите им, при гарантиране на високо ниво на сигурност, надеждност, изолация на отделните ползватели и невъзможност от намеса в работоспособността на информационните им системи или неоторизиран достъп до информационните им ресурси. Изолацията на ресурсите и мрежите на отделните секторни ползватели (е- Общини, е-Правосъдие, е-Здравеопазване, е-Полиция) се гарантира с подходящи мерки на логическо ниво (формиране на отделни клъстери, виртуални информационни центрове и мрежи) и на физическо ниво (клетки и шкафове с контрол на достъпа). Софтуер с отворен код Компютърна програма, която се разпространява при условия, които осигуряват безплатен достъп до програмния код и позволяват: Използването на програмата и производните на нея компютърни програми без ограничения в целта; Промени в програмния код и адаптирането на компютърната програма за нуждите на нейните ползватели; Разпространението на производните компютърни програми при същите условия. Списък на стандартни лицензионни споразумения, които предоставят тези възможности, който може да бъде намерен в подзаконовата нормативна уредба към Закона за електронно управление или на: http://opensource.org/licenses. Машинночетим Формат на данни, който е структуриран по начин, по който, без да формат се преобразува в друг формат позволява софтуерни приложения да идентифицират, разпознават и извличат специфични данни, включително отделни факти и тяхната вътрешна структура. Отворен формат Означава формат на данни, който не налага употребата на специфична платформа или специфичен софтуер за повторната употреба на съдържанието и е предоставен на обществеността без ограничения, които биха възпрепятствали повторното използване на информация. Метаданни Данни, описващи структурата на информацията, предмет на повторно използване. 8 Официален отворен Стандарт, който е установен в писмена форма и описва спецификациите за изискванията как да се осигури софтуерна стандарт оперативна съвместимост. Система за контрол на Технология, с която се създава специално място, наречено версиите “хранилище”, където е възможно да се следят и описват промените по дадено съдържание (текст, програмен код, двоични файлове). Една система за контрол на версиите трябва да може: • Да съхранява пълна история - кой, какво и кога е променил по съдържанието в хранилището, както и защо се прави промяната; • Да позволява преглеждане на разликите между всеки две съхранени версии в хранилището; • Да позволява при необходимост съдържанието в хранилището да може да се върне към предишна съхранена версия; • Да позволява наличието на множество копия на хранилището и синхронизация между тях. Цялата информация, налична в системата за контрол на версиите за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, трябва да може да бъде достъпна публично, онлайн, в реално време. Първичен регистър Регистър, който се поддържа от първичен администратор на данни - административен орган, който по силата на закон събира или създава данни за субекти (граждани или организации) или за обекти (движими и недвижими) за първи път и изменя или заличава тези данни. Например Търговският регистър е първичен регистър за юридическите лица със стопанска цел, Имотният регистър е първичен регистър за недвижима собственост. Наличност на Процентът на договорените часове, за които компонент или услуга Системата в проценти е достъпна за определен период от време. Работни дни От понеделник до петък без националните и официалните празници. Работни часове 08:00-20:00 всеки работен ден (Работно време) Инцидент е всяко намаляване на качеството или недостъпност на Инцидент предоставяна услуга и/или непланираното ѝ прекъсване, както и неизправност на елемент от инфраструктурната конфигурация 9 Продължително Прекъсване на услугата за повече от четири (4) работни часа прекъсване Планирана Планирано прекъсване на една или повече услуги. недостъпност Неспособността на услуга или част от услуга да осигури Недостъпност нормалното обслужване Непланирана Неочаквано прекъсване на една или повече услуги или значителна недостъпност деградация на качеството на предлаганата услуга. Проблем е съвкупност от повтарящи се идентични събития или инциденти, които водят до периодично влошаване на дадена услуга, Проблем липсата ѝ или неточност в дадена процедура или функционално звено Дефиниции за нива на електронизация на услугите Ниво 1 Информация - предоставяне на информация за административни услуги по електронен път, включително за начини и места за заявяване на услугите, срокове и такси. Ниво 2 Едностранна комуникация - информация съгласно дефиницията за Ниво 1 и осигурен публичен онлайн достъп до шаблони на електронни формуляри. Ниво 3 Двустранна комуникация - заявяване на услуги изцяло по електронен път, включително електронно подаване на данни и документи, електронна обработка на формуляри и електронна идентификация на потребителите, освен ако със закон се допуска предоставяне на електронна административна услуга без идентификация;. Ниво 4 Извършване на услуги от ниво 3, за които е осигурена възможност за електронно връчване и електронно плащане, ако за получаването на електронна административна услуга се дължат такси. 2. ВЪВЕДЕНИЕ 2.1. Цел на документа 10 Термин Описание Целта на настоящия документ е да опише софтуерните изисквания към изпълнението на обществена поръчка с предмет: [опишете предмета на поръчката]. В настоящата техническа спецификация са описани и изискванията към проектната организация, документацията и отчетността. Съдържанието на настоящата техническа спецификация е задължително за прилагане от всички лица по чл.1, ал.1 и ал. 2 от ЗЕУ, публичните и секторните възложители по Закона за обществените поръчки, които са публични предприятия по смисъла на Закона за публичните предприятия, като в същото може да бъде добавян текст в зависимост от специфичните нужди на разработваната информационна система, но не може да бъде изтривано настоящото съдържание. 2.2. За възложителя – функции и структура Опишете накратко функциите на Вашата администрация. Изтрийте тази текстова кутия при финализиране на документа. Структурата на [възложителя] е представена във Фигура 1: 11 .... Финансов Контрольор ... Главен секретар Дирекция 1 Дирекция 2 Дирекция 3 Дирекция 4 Отдел 1 Отдел 1 Отдел 1 Отдел 1 Отдел 2 Отдел 2 Отдел 2 Отдел 2 Отдел 3 Отдел 3 Отдел 3 Отдел 3 Отдел 4 Отдел 4 Отдел 4 Отдел 4 Дирекция 5 Дирекция 6 Дирекция 7 Отдел 1 Отдел 1 Отдел 1 Отдел 2 Отдел 2 Отдел 2 Отдел 3 Фигура 1. Структура на [възложителя] 2.3. За проекта Кратка информация за проекта Изтрийте тази текстова кутия при финализиране на документа. 2.4. Нормативна рамка Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи: • Закон за електронното управление (ЗЕУ); • Закон за киберсигурност (ЗК); • Закон за електронната идентификация (ЗЕИ); 12 • Наредба за общите изисквания към информационните системи, регистри и електронни административни услуги (НОИИСРЕАУ); • Наредба за минималните изисквания за мрежова и информационна сигурност (НМИМИС); • Актуализирана стратегия за електронното управление; • Архитектура на електронното управление • [Документ 2] 3. Цели, обхват и очаквани резултати от изпълнение на проекта 3.1. Общи и специфични цели на проекта Проектът е насочен към [подробно описание на общата цел на проекта]. Постигането на общата цел ще бъде реализирано чрез следните специфични цели, съответстващи на планираните по проекта дейности: • [Специфична цел 1] • [Специфична цел 2] • [Специфична цел 3] • [Специфична цел 4] • [Специфична цел 5] 3.2. Обхват на проекта Описаните в т. 3.1 цели се осъществяват с изпълнението на следните основни дейности, които формират обхвата на проекта: • Дейност 1 [Наименование на дейността] • Дейност 2 [Наименование на дейността] • Дейност 3 [Наименование на дейността] • Дейност 4 [Наименование на дейността] • Дейност 5 [Наименование на дейността] Подробна информация за конкретните дейности по проекта е публично достъпна на адрес …………….. 3.3. Целеви групи 13 Целевите групи, към които е насочен проектът, обхващат: • [Целева група 1]; • [Целева група 2]; • [Целева група 3]. Вашата администрация задължително присъства в списъка с целеви групи. Други целеви групи могат да бъдат други организации, например държавни администрации, крайни потребители на административни услуги – гражданите и бизнесът, както и други лица, осъществяващи публични функции. Изтрийте тази текстова кутия при финализиране на документа. Опишете какви резултати очаквате да бъдат постигнати с реализирането на проекта. Изтрийте тази текстова кутия при финализиране на документа. 3.4. Очаквани резултати Очакваните резултати от изпълнението на настоящата поръчка са: • [Резултат 1]; • [Резултат 2]; • [Резултат 3]. 3.5. Период на изпълнение Периодът на изпълнение е [Х] месеца, но не по късно от [ДД.ММ.ГГГГ]г. Участниците трябва да изготвят подробен график, в който следва да се конкретизират сроковете за изпълнение на всяка дейност и поддейност от настоящата поръчка. Графикът 14 за изпълнение трябва да бъде съобразен с продължителността на дейността и не може да надвишава [Х] месеца от дата на сключване на договора. 4. ТЕКУЩО СЪСТОЯНИЕ Опишете текущото състояние на Вашата администрация и бизнес процесите, които имат отношение към предмета на процедурата. Изтрийте тази текстова кутия при финализиране на документа. 5. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА 5.1. Общи изисквания към изпълнението на обществената поръчка Обществената поръчка се изпълнява в рамките на [Наименование на проекта/дейността], финансиран по [Източник на финансиране]. Изпълнителят следва да спазва всички нормативни изисквания по отношение на дейността на [бенефициента] и електронното управление в Република България. 5.2. Общи организационни принципи Задължително изискване е да се спазят утвърдените хоризонтални и вертикални принципи на организация на изпълнението на предмета на обществената поръчка за гарантирано постигане на желаните резултати от проекта, така че да се покрие пълният набор от компетенции и ноу-хау, необходими за изпълнение на предмета на поръчката, а също така да се гарантира и достатъчно ниво на ангажираност с изпълнението и проблемите на проекта: • Хоризонталният принцип предполага ангажиране на специалисти от различни звена, така че да се покрие пълният набор от компетенции и ноу-хау по предмета на проекта и същевременно екипът да усвои новите разработки на достатъчно ранен етап, така че да е в състояние пълноценно да ги използва и развива и след приключване на проекта; • Вертикалният принцип включва участие на експерти и представители на различните управленски нива, така че управленският екип да покрива както експертните области, необходими за правилното и качествено изпълнение на 15 проекта, така и управленски и организационни умения и възможности за осъществяване на политиката във връзка с изпълнението на проекта. Чрез участие на ръководители на звената – ползватели на резултата от проекта, ще се гарантира достатъчно ниво на ангажираност на институцията с проблемите на проекта. 5.3. Управление на проекта1 [Моля, изтрийте ненужното!] Участниците трябва да предложат методология за управление на проекта, която смятат да приложат, като се изтъкнат ползите й за успешното изпълнение на проекта. Предложената методология трябва да съответства на най-добрите световни практики и препоръки (например Project Management Body of Knowledge (PMBOK) Guide, PRINCE2, Agile/ SCRUM/ Kanban, RUP и др. еквивалентни). Участникът следва да организира изпълнението на дейностите си съгласно принципите на избрана от него Методология за управление на ИТ проекти и да предложи план-график за изпълнение на проекта за всяка дейност и поддейност. [Моля, изтрийте ненужното!] Възложителят изисква методология за управление на проекта, която участниците трябва да приложат и която съответства на най-добрите практики и препоръки, а именно ….. [Моля, довършете изречението!]. Дейностите по управление на проекта трябва да включват като минимум управление на реализацията на целия обхват на настоящата обществена поръчка и постигане на очакваните резултати, както и разпределението на предложените участници в екипа за управление на поръчката по роли, график и дейности при изпълнение на настоящата обществена поръчка. Доброто управление на проекта трябва да осигури: • координиране на усилията на експертите от страна на Изпълнителя и Възложителя и осигуряване на висока степен на взаимодействие между членовете на проектния екип; • оптимално използване на ресурсите; • текущ контрол по изпълнението на проектните дейности; • разпространяване навреме на необходимата информация до всички участници в проекта; • идентифициране на промени и осигуряване на техните анализ и координация; • осигуряване на качеството и полагане на усилия за непрекъснато подобряване на работата за удовлетворяване на изискванията на участниците в проекта. Методологията трябва да включва подробно описание на: • фазите на проекта; 1 Под „проект“ следва да се разбира предметът на настоящата обществена поръчка 16 • организация на изпълнение: o структура на екипа на Изпълнителя; o начин на взаимодействие между членовете на екипа на Изпълнителя; o връзки за взаимодействие с екипа на Възложителя; • проектна документация: o видове доклади; o техническа и експлоатационна документация; o време на предаване; o съдържание на документите; o управление на версиите; • управление на качеството; • график за изпълнение на проекта. В графика участниците трябва да опишат дейностите и стъпките за тяхното изпълнение максимално детайлно, като покажат логическата връзка между тях. В графика трябва да са посочени датите за предаване на всеки от документите, изготвени в изпълнение на обществената поръчка. 5.4. Управление на риска В техническото си предложение участниците трябва да опишат подхода за управление на риска, който ще прилагат при изпълнението на поръчката. Участниците трябва да представят и списък с идентифицираните от Възложителя рискове с оценка на вероятност, въздействие и мерки за реакция. През времето за изпълнение на проекта Изпълнителят трябва да следи рисковете, да оценява тяхното влияние, да анализира ситуацията и да идентифицира (евентуално) нови рискове. В хода на изпълнение на поръчката Изпълнителят следва да поддържа актуален списък с рисковете и да докладва състоянието на рисковете най-малко с месечните отчети за напредъка. При изготвянето на списъка с рискове Участниците следва да вземат предвид следните идентифицирани от Възложителя рискове: ▪ Промяна в нормативната уредба, водеща до промяна на ключови компоненти на решението – предмет на разработка на настоящата обществена поръчка; ▪ Недобра комуникация между екипите на Възложителя и Изпълнителя по време на аналитичните етапи на проекта; ▪ Ненавременно изпълнение на всяко от задълженията от страна на Изпълнителя; 17 ▪ Неправилно и неефективно разпределяне на ресурсите и отговорностите при изпълнението на договора; ▪ Забавяне при изпълнение на проектните дейности, опасност от неспазване на срока за изпълнение на настоящата поръчка; ▪ Грешки при разработване на функционалностите на системата; ▪ Недостатъчна яснота по правната рамка и/или променяща се правна рамка по време на изпълнение на проекта; ▪ Липса на задълбоченост при изследването и описанието на бизнес процесите и данните; ▪ Неинформиране на Възложителя за всички потенциални проблеми, които биха могли да възникнат в хода на изпълнение на дейностите; ▪ Риск за администриране на системата след изтичане на периода на гаранционна поддръжка. 6. ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА В техническото си предложение участниците трябва да предложат подход за изпълнение на проекта, като включат минимум следните етапи: 6.1. Анализ на данните и изискванията Функционален обхват на проекта o [Моля, изтрийте ненужното!] Разработка, надграждане и внедряване на публични електронни административни услуги; o [Моля, изтрийте ненужното!] Разработка, надграждане и внедряване на вътрешноадминистративни услуги; o [Моля, изтрийте ненужното!] Разработка на нови функционалности на Системата и надграждане на съществуващи; o [Моля, изтрийте ненужното Разработка на нови регистри и надграждане на съществуващи. Актуализиране на модела на данните и системата за управление на базата данни (СУБД). ▪ В процеса на бизнес анализ да бъдат изследвана съвместимостта на бизнес процесите на Възложителя с вече одобрени оптимизирани референтни модели за предоставяне на услуги и нормативни изисквания на Базисен модел за Комплексно административно обслужване в държавната администрация. При наличие на разработени модели за предоставяне на услуги по „Епизоди от живота“ и „Събития от бизнеса“, които включват услуги, предоставяни от Възложителя, да бъдат съобразени нуждите от модификации в референтните модели, за да се 18 постигне подобряване на времето и намаляване на административната тежест при комплексно обслужване спрямо предоставянето на отделните услуги поединично; ▪ В случай че се касае за административни услуги, те трябва да бъдат разграничени на базата на разлики в бизнес процесите и да не бъдат генерализирани и/или обобщавани на базата на типа на действие (например, ако Системата издава няколко различни вида удостоверения, с които се удостоверяват различни обстоятелства, административните услуги трябва да бъдат регистрирани отделно); ▪ Удостоверителните административни услуги трябва да бъдат регистрирани и като вътрешни административни услуги и да бъде реализирана възможност за предоставянето на тези услуги като вътрешни електронно административни услуги за нуждите на комплексното административно обслужване чрез служебен онлайн интерфейс. 6.1.1. Специфични изисквания към етапите на бизнес анализа при разработка, надграждане или внедряване на информационна система Изпълнителят трябва да следва Методологията за усъвършенстване на работните процеси за предоставяне на административни услуги и Наръчника за прилагане на методологията, приета с Решение № 578 на Министерския съвет от 30 септември 2013 г.; ▪ Трябва да бъде предвидена фаза на проучване, по време на която да се дефинират потребителските нужди, да се проведат предварителни тестове с потребители и да се изработи план, по който да се адресират идентифицираните нужди; ▪ Необходимо е да бъде направен анализ на текущото състояние на данните, които ще се обработват, по отношение на тяхната изчерпателност, пълнота и качество, да се направи оценка на възможността за въвеждане на данни и обстоятелства в регистри, съгласно изискванията на нормативната уредба. Да се предложи модел на данните, съдържащ описание на основните таблици и схематично представяне на връзките между тях; ▪ В процеса на анализа трябва да се разгледа възможността обменът на данни да се основава на общи стандарти, т.е. условия за използване, формат на данните, машинна четимост, метаданни, споделени речници/таксономии, честота, детайлност и задължителни атрибути. Задължителното прилагане би гарантирало изпълнението на изискванията за повторни потребители и доставчици на данни. ▪ Трябва да бъде направен анализ, оценка и описание на работните процеси, заложени в нормативната уредба, да бъде предложена организационна архитектура на базата, на която да бъдат разработени и оптимизирани основните функционалности на Системата. ▪ Трябва да бъдат предвидени периодични продуктови тествания по време на разработката и внедряването на Системата, с извадка (фокус-група) от бъдещите потребители на Системата, чрез които да се изпита и оцени 19 използваемостта на услугите и потребителските интерфейси, както и за да бъдат отстранени затруднения и несъответствия със спецификацията; ▪ Трябва да се спазват нормативните изисквания за еднократно събиране и повторна употреба на данни в държавната администрация (съгласно АПК и ЗЕУ) и в разработените бизнес процеси да не се изискват данни за заявителя и/или за получателя на услугата, които могат да се извлекат автоматично в процеса на електронна идентификация чрез Центъра за електронна идентификация или на базата на ЕГН от КЕП. При необходимост изпълнителят трябва да предложи на Възложителя адекватни промени в нормативната уредба, които да хармонизират съответните секторни нормативни изисквания с общите разпоредби на Административнопроцесуалния кодекс, Закона за електронно управление, Закона за електронния документ и електронния подпис и приложимите подзаконови актове, ако действащата нормативна уредба изисква: o изрично попълване на типов структуриран електронен формуляр, върху който потребителите трябва да се подпишат собственоръчно и/или който да приложат като изискуем документ при заявяването на електронна административна услуга; o изрично деклариране или обявяване на обстоятелства или данни, които се администрират и/или удостоверяват от други държавни органи и могат да бъдат получени по служебен път, включително и автоматизирано през съответни интеграционни интерфейси; o други нормативни изисквания, които водят до неоптимални или ненужно бюрократични процеси, които биха могли да бъдат оптимизирани при заявяване и предоставяне на електронни административни услуги; 6.1.2. Специфични изисквания при оптимизиране на процесите по заявяване на електронни услуги и електронни административни услуги (съгл. §1, т.2 от ЗЕУ) в зависимост от заявителя ▪ Предвидените за разработка и внедряване електронни административни услуги трябва да бъдат регистрирани предварително в Регистъра на услугите към Административния регистър (съгласно чл. 61 от Закона за администрацията). Услугите, които ще бъдат надградени, и новоразработените услуги трябва да отговарят на изискванията за електронни услуги с минимално Ниво 4, където е приложимо (т.е. услугата изисква заплащане на такса), или Ниво 3, в случаите, в които за предоставяне на услугата не се изисква заплащане на такса; Дефинициите за нивата на електронизация на административните услуги са регламентирани в Наредбата за административния регистър към Закона за администрацията; ▪ При разработката на информационна система, чрез която се предоставят ЕАУ, да се предвиди изцяло автоматизираното им предоставяне, като се определи задължителното минимално ниво на електронизация на ЕАУ, съгласно т. 1.3 от техническата спецификация, както и нивото на осигуреност на средствата за електронна идентификация при заявяване 20 на ЕАУ, определено съгласно Методика за определяне от лицата по чл. 1, ал. 1 и 2 от ЗЕУ на средствата за електронна идентификация, които се използват при заявяване на ЕАУ, и тяхното ниво на осигуреност, и получаване на резултата от нея. ▪ При анализа трябва да се има предвид, ако АО предоставя ЕАУ от ниво 4, изискваща такса за плащане, тя е с намалена такса спрямо таксата за присъствено заявяване и предоставяне, ако при прилагането на методиката за определяне на разходоориентиран размер на таксите по чл. 7а на Закона за ограничаване на административното регулиране и административния контрол върху стопанската дейност се установи различен размер на разходите, съгласно чл.10а, ал 2 от ЗЕУ. ▪ Трябва да се разработят информативни текстове за всяка услуга, които включват като минимум: o условия за предоставяне на услугата; o срокове за предоставяне на услугата; o такси за заявяване и съответно предоставяне на услугата; o начини за получаване на услугата; o резултат от предоставяне на услугата; o отказ от предоставяне на услугата. ▪ Информативните текстове за всяка услуга трябва да бъдат достъпни за потребителите още като първа стъпка от заявяването на услуга; ▪ Тарифирането на услугите трябва да бъде реализирано така, че Системата да съхранява всички версии на тарифите за услуги (от дата до дата) и да прилага съответната тарифа в зависимост от момента, в който е заявена дадена услуга; ▪ Трябва да бъде оптимизиран потребителският път от влизане на сайта до заявяване и получаване на услуга и пътят от регистрация на нов потребител до заявяване и получаване на услуга; ▪ При оптимизацията на потребителския път трябва да се отчита всяко действие от страна на потребителя (натискане на бутон, въвеждане на данни, прочитане на текст и пр.), което може да се спести. ▪ Съгласно действащата нормативна уредба допустимите заявители на електронни административни услуги могат да бъдат разделени в няколко групи, като процесите по заявяване на ЕАУ и необходимите процеси по установяване на допустимостта на заявлението зависят от множество фактори. Трябва да бъде обърнато специално внимание на спецификите в процесите в зависимост от качеството, в което действа заявителят, за да се постигне максимална оптимизация 21 на процеса, като същевременно се защити сигурността на търговския и гражданския оборот. ▪ Предоставянето на ЕАУ от административните органи на гражданите и бизнеса да се извършва през Портала на електронното управление чрез хоризонталната система за е-форми, като се използва Единният модел за заявяване, заплащане и предоставяне на ЕАУ. В приложената диаграма са показани възможни разлики в бизнес процесите в зависимост от качеството, в което действа заявител на ЕАУ: Процес по заявяване в лично качество : Начин на Преглед и Заявител Обстоятелства Плащане получаване заявяване Процес по заявяване на услуга като законен представител на юридическо лице: Начин на Преглед и Заявител Обстоятелства Плащане получаване заявяване Автоматична проверка за представителна власт в ТР или БУЛСТАТ Процес по заявяване на услуга като пълномощник на физическо или юридическо лице: Приложени Начин на Преглед и Заявител Обстоятелства Плащане документи получаване заявяване Варианти за оптимизация и автоматизация: 1) Регистрация на пълномощни към профил на потребител (носи се на гише и се прикача към профил с дата ОТ / ДО) Проверка на пълномощно 2) Регистрация на пълномощни към профил на потребител - отделна ЕАУ, в бек-офиса при която потребителят прикача пълномощното и дава номер от регистъра на нотариусите, като в бек-офиса да се прави ръчна проверка в нотариалния регистър на пълномощните „Единство“, преди да се активира) ВАЖНО: Да се анализират правните и техническите възможности за осигуряване на служебен достъп до регистъра на пълномощните, воден от нотариалната камара! Процес по заявяване на услуга като длъжностно лице: Приложени Начин на Преглед и Заявител Обстоятелства Плащане документи получаване заявяване Варианти за оптимизация и автоматизация: Проверка на 1) ЧСИ / ДСИ прикачва сканирано решение по изпълнително дело и го решение по подписва с КЕП, декларирайки, че е вярно с оригинала изпълнително 2) Бек-енд системата проверява автоматично, дали има редовно дело в бек- регистриран ЧСИ / ДСИ в регистъра на камарата офиса ВАЖНО: Да се анализират правните и техническите възможности за осигуряване на служебен достъп до регистъра на пълномощните, воден от нотариалната камара! В приложената таблица са представени спецификите и разликите в бизнес процесите в зависимост от качеството, в което действа заявител на ЕАУ, които трябва да бъдат отразени при реализацията на Системата: 22 Вид заявител Особености Специфични процеси Физическо лице за собствени нужди от Заявява свое име. простият случай ЕАУ за за Това е реализиране лични нужди най- Услугата може да бъде предоставена, след като са изпълнени нуждите за идентификация, ако има такива - електронна идентификация по смисъла на ЗЕИ или ЕГН, извлечено от КЕП в 6.1.3. Изисквания за оптимизиране на процесите по подаване на декларации, изискуеми в съответствие с нормативната уредба и вътрешните правила ▪ Системата трябва да поддържа номенклатура с редактируеми шаблони на декларации, които да бъдат достъпни за актуализация за администраторите на Системата; Трябва да се поддържа история на версиите на шаблоните и да няма възможност за перманентно премахване/изтриване на шаблони, а само смяна на статуса им и публикуване на нова версия; 23 преходния период, както и три имена или анонимно. Законен представител на юридическо лице Заявява ЕАУ, за да обслужи нужди на юридическо лице, на което е законен представител (т.е. заявителят е вписан като представляващ юридическото лице в съответен регистър) Услугата може да бъде предоставена, след като са изпълнени нуждите за идентификация - електронна идентификация по смисъла на ЗЕИ или ЕГН, извлечено от КЕП в преходния период, както и автоматична проверка за представителна власт в ТР/ БУЛСТАТ/ ЦРЮЛНЦ. Пълномощник на ФЛ или ЮЛ Заявява ЕАУ, за да обслужи нужди на физическо или юридическо лице, което го е упълномощило (т.е. заявителят трябва да разполага с пълномощно, което му дава необходимия обем и обхват на представителна власт, за заявяване и/или получаване на съответната услуга) Услугата може да бъде предоставена само след проверка на представителната власт в Регистъра с пълномощни на Нотариалната камара, чрез проверка в Регистъра на овластяванията по смисъла на ЗЕИ или при създадена възможност за регистриране на пълномощни към профила на потребителя или за заявяване на услугата. Пълномощник може да бъде и посредник за предоставяне на ЕАУ по реда на ЗЕУ, в т.ч. Центрове за комплексно административно обслужване. Длъжностно лице (ЧСИ / ДСИ) Заявява ЕАУ, за да изпълни определени свои задължения като длъжностно лице спрямо друго физическо или юридическо лице, за което следва да има съответен правен интерес. Услугата може да бъде предоставена само след проверка на длъжностното лице в съответния регистър (ЧСИ/ ДСИ) и на правния интерес чрез изискване за декларирането му чрез изрична декларация, подписана с КЕП, и прилагане на копие от решение по изпълнително дело. ▪ Ако даден бизнес процес изисква подаване на декларация от страна на заявител на услуга, при достигане на съответната стъпка от процеса Системата трябва: o да попълва автоматично всички персонални данни на заявителя в електронна форма, генерирана на база на съответния шаблон на декларация; o да дава възможност на потребителя за избор на съответните обстоятелства, които може да декларира (ако шаблонът на декларацията предвижда възможност за деклариране на опционален набор от предефинирани обстоятелства); o да изисква потвърждение на обстоятелствата от страна на потребителя; o в случай че декларацията трябва да се попълни от лице, различно от заявителя, тя да може да се прикачи като електронно подписан документ или по електронен път да бъде отправяна покана към декларатора за електронно подписване. ▪ Всяка попълнена електронна декларация трябва да се прикачи автоматично от Системата към заявлението и да бъде подписана заедно с него от потребителя с електронен подпис, освен в случаите, когато заявителят и деклараторът са различни лица и декларацията е подписана отделно от декларатора. 6.1.4. Изисквания към регистрите и предоставянето на административните услуги ▪ Всяка удостоверителна административна услуга в обхвата на Системата трябва да бъде достъпна като вътрешноадминистративна електронна услуга чрез уеб услуга, като комуникацията се подписва с електронен печат на институцията и с електронен времеви печат по смисъла на Регламент (ЕС) 910/2014; ▪ Всяка услуга, за която се допуска представителна власт, трябва да бъде интегрирана с Регистъра на овластяванията по смисъла на Закона за електронната идентификация; ▪ Системата не трябва да съхранява данни, на които възложителят не е първичен администратор, в случай че данните могат да бъдат извличани в реално време от регистър на съответния първичен администратор при възможност чрез интеграционната шина за обмен на справочна и удостоверителна информация. ▪ Всички електронни административни услуги, предоставяни от административните органи на гражданите и бизнеса, трябва да се заявяват през Портал за електронно управление. ▪ При предоставянето на ЕАУ е необходимо Изпълнителят да осъществи интеграция с хоризонталните системи на електронното управление. 24 6.2. Изготвяне на системен проект Изпълнителят трябва да изготви системен проект, който подлежи на одобрение от Възложителя. В системния проект трябва да са описани всички изисквания за реализирането на системата. Изготвянето на системния проект включва следните основни задачи: ▪ Определяне на концепция на информационната система на базата на техническата спецификация; ▪ Дефиниране на детайлни изисквания и бизнес процеси, които трябва да се реализират в Системата; ▪ Дизайн на информационната система, хардуерната и комуникационната инфраструктура; ▪ Изготвяне на план за техническа реализация; ▪ Определяне на потребителския интерфейс. Изпълнението на задачите изисква дефиниране на модели на бизнес процеси, модели на стандартни справки и анализи, модели на печатни бланки, политика за сигурност и защита на данните, основни изграждащи блокове, транзакции, технология на взаимодействие, мониторинг на системата, спецификация на номенклатурите, роли в системата и други. При документирането на изискванията, с цел постигане на яснота и стандартизация на документите, е необходимо да се използва стандартен език за описание на бизнес процеси – BPMN. Системният проект подлежи на одобрение от Възложителя. В случай на забележки, корекции или допълнения от страна на Възложителя Изпълнителят е длъжен да ги отрази в системния проект в срок не по-късно от [Х] работни дни. 6.3. Разработване на софтуерното решение Етапът на разработка включва изпълнението на следните задачи: ▪ [ако е приложимо] Разработка на прототип, който трябва да бъде одобрен от Възложителя и въз основа на който трябва да се разработи цялата система; ▪ Разработка на модулите на информационната система съгласно изискванията на настоящата техническа спецификация и системния проект; ▪ Провеждане на вътрешни тестове на Системата (в среда на разработчика); ▪ Изготвяне на детайлни сценарии за провеждане на приемателните тестове за етапи „Тестване“ и „Внедряване“ на проекта. За изпълнение на дейностите по разработка на системата участниците в настоящата обществена поръчка трябва да опишат в своите технически предложения приложим подход (методология) за софтуерна разработка, която ще използват, както и инструментите за 25 разработка и средата за провеждане на вътрешните тестове. Участниците трябва да опишат как предложеният от тях подход ще бъде адаптиран за успешната реализация на Системата. 6.4. Тестване Изпълнителят трябва да проведе тестване на софтуерното решение в създадена за целта тестова среда, за да демонстрира, че изискванията са изпълнени. Изпълнителят трябва да предложи и опише методология за тестване, която ще използва в план за тестване с описание на обхвата на тестването, вид и спецификация на тестовете, управление на дефектите, регресионна политика, инструменти, логистично осигуряване и други параметри на процеса. 6.5. Внедряване Изпълнителят трябва да внедри софтуерното решение в информационната и комуникационна среда на [бенефициента]. Това включва инсталиране, конфигуриране и настройка на програмните компоненти на системата в условията на експлоатационната среда на [бенефициента]. 6.6. Обучение Изпълнителят трябва да организира и да проведе обучения за следните групи и ползватели на софтуерното решение: ▪ [Потребителска група 1]; ▪ [Потребителска група 2]; ▪ [Потребителска група 3]. За провеждането на обученията Изпълнителят е длъжен да осигури за своя сметка [включват се само тези точки, за които Възложителят няма възможност да осигури изброените ресурси]: Необходимия хардуер; Необходимия софтуер; Зала/Зали за провеждане на обученията; Учебни материали; Лектори. 6.7. Гаранционна поддръжка Изпълнителят трябва да осигури за своя сметка гаранционна поддръжка за период от минимум [X] месеца след въвеждане в експлоатация на Системата. При необходимост, по време на гаранционния период трябва да бъдат осъществявани дейности по осигуряване на експлоатационната годност на софтуера и ефективното му 26 използване от Възложителя, в случай че настъпят явни отклонения от нормалните експлоатационни характеристики, заложени в системния проект. Приоритетите на инцидентите и проблемите се определят от Възложителя в зависимост от влиянието им върху работата на администрацията. Редът на отстраняването им се определя в зависимост от техния приоритет. 6.7.1. Обхват на дейностите по гаранционна поддръжка Изпълнителят следва да предоставя услугите по гаранционна поддръжка, като предоставя за своя сметка единна точка за достъп за приемане на телефонни и e-mail съобщения Дейностите по гаранционна поддръжка трябва да включват следния минимален обхват: • Извършване на диагностика с цел осигуряване на правилното и безпроблемно функциониране на Системата; • Регистриране на инцидент в Система за управление на инциденти и проблеми; • Отстраняване на дефектите, открити в софтуерните и/или хардуерните модули; • Възстановяването на работоспособността на Системата при евентуален срив; • Предоставяне на консултации за идентифициране на проблеми в конфигурацията на ИТ средата (операционна система, база данни, middleware, хардуер и мрежи); • Регулярен мониторинг на неразрешените инциденти, дефиниране на проблеми и оценка на ефектите върху договорените параметри на качеството за наличност и достъпност на Системата; • Пълно документиране на разрешените инциденти, включително предприетите стъпки за разрешаването им, точното им класифициране, обратна връзка със засегнатите потребители относно предложеното решение, общо изразходвано време за разрешаване; • Актуализация на документацията при установени явни несъответствия с фактически реализираните функционалности, както и в случаите, в които са извършени действия по отстраняване на дефекти и грешки, в рамките на гаранционната поддръжка. За целите на дейността е необходимо да бъдат изготвени от Изпълнителя и одобрени и подписани от Възложителя: • Споразумение за нивото на предоставяните услуги към потребителите на информационни ресурси на АО (SLApm), в които са определени приоритетите за спешно обслужване; • Параметрите на качество на обслужване на Системата, съобразени с минималните изисквания към параметрите на качеството от т. 6.7.5; 27 • Комуникационни, анализаторски и документационни средства, с които функционалните звена идентифицират, анализират, проследяват и документират възникването и отстраняването на неработоспособността на информационната система. 6.7.2. Управление на инциденти (incident management) С цел осигуряване на работоспособността на Системата и повишаване на качеството на обслужване на потребителите ѝ в етапа на нейната експлоатация, Изпълнителят трябва да разработи процедури за бързо и ефективно регистриране на възникнали инциденти и безпроблемно им отстраняване. Чрез процедурата за управление на инциденти се подпомага и координира работата на въвлечените в тази дейност функционални звена, които изпълняват следните задачи: 1-во ниво на поддръжка – за изпълнение на тези дейности се сформира се екип от експерти на Възложителя или дейността се поема от екип на Изпълнителя. Задачите на екипа са да извършва дейности по наблюдение на Системата, регистриране, описание и обслужване на инциденти с цел улесняване идентифицирането на причините за възникване, първоначален анализ и класифициране на инциденти, ескалиране на заявки към 2-ро ниво поддръжка, документиране на дейностите и изготвяне на доклади. 2-ро ниво на поддръжка – екипът се сформира от експерти на Изпълнителя или от експерти на Възложителя и Изпълнителя, които разглеждат, анализират и отстраняват всички възникнали инциденти при спазване на процедурата. Екипът изпълнява следните задачи: обслужване на ескалираните от 1-во ниво на поддръжка инциденти, анализиране и класифициране на инциденти, разследване и диагностика на инцидента и установяване на средствата и каналите за разрешаване, разрешаване на инцидента и възстановяване на оперативността на всички засегнати компоненти, създаване на база данни за начина на разрешаване на инцидентите, съдържаща информация както за временните решения (work around), така и за искания за промени; 3-то ниво на поддръжка – екипът се сформира от експерти на Изпълнителя, които разрешават инцидент, ескалиран от екипа на 2-ро ниво на поддръжка, осигуряват безпроблемното функциониране на Системата, проактивно изследват инцидент с цел откриване на конкретната причина за възникването му, правят предложения за промени в компонентите, свързани с решаването на регистрирани проблеми, предоставят информация за процеса по управление на проблемите (Problem Management) относно взимане на мерки за предотвратяване повторяемостта на инцидентите. Процесът на управление на инциденти се осъществява чрез използване на Система за управление на заявки (Service/ Help Desk), собственост на Възложителя или Изпълнителя, която гарантира разпознаването им, тяхната проследимост и причините за възникването им, позволява документиране, комуникиране и одобрение по идентификация, разследване и отстраняване на причини за възникване на инциденти и проблеми. 6.7.3. Управление на проблеми (УП) (problem management) В етапа на гаранционна поддръжка се включва процесът по управление на проблеми, целта на който е да минимизира и/или елиминира влиянието на инцидентите, причинени от 28 грешки, възникнали в компонентите на системите, платформите, функционалните звена и/или процесите, имащи пряко или косвено отношение към влошаване или невъзможност за предоставяне на услугите към крайните потребители. При УП екипът от експерти на Изпълнителя трябва: • да се фокусира върху идентифицирането на причините за възникване на инциденти (root-cause analysis), повторяемостта на идентичните събития и инциденти, които водят до появата и съществуването на грешки. • да извършва всички необходими дейности за диагностициране и анализиране на причините за възникване на инцидентите и да определя начините и методите за разрешаване на проблемите, да дефинира, прилага и да носи пряка отговорност за прилагането на подходящи контролни процедури (Change Management/ Release Management) с цел безпроблемно и качествено имплементиране на одобреното постоянно или временно (work around) решение. • да поддържа база данни - инструмент за работа с нея, в която се вписват всички проблеми и съответните им решения (Knowledge Management and Known Error Data Base). • да обхване двата основни процеса – реактивно и проактивно управление на проблемите, който е част от процеса на непрекъснато подобряване на услугите (Continuous Service Improvement). 6.7.4. Управление на качеството при отстраняване на инциденти и проблеми. Параметри на качеството. Чрез гаранционната поддръжка Изпълнителят трябва да осигури гарантиране на работоспособността, на мрежовата и информационната сигурност, да поддържа непрекъснатост на работата на Системата, с което се обезпечава неприкосновеността и сигурността на обработваната информация. Параметрите на качеството на услугите, които Изпълнителят предлага в етапа на гаранционна поддръжка, се изпълняват съгласно споразумение за нивото на предоставяните услуги към потребителите на АО (SLApm). 6.7.5. Минимални изисквания към параметрите на качеството Системата трябва да работи в режим 7/24/365. Конкретните параметри, свързани с достигането на необходимото ниво на работоспособност през гаранционния период, са дадени в Таблици от 1 до 5. Таблица 1 29 Наличност на Системата в проценти и часове на годишна база Таблица 2 Таблица 3 30 Система В рамките на работните часове Максимално отпадане на в работно време година сумарно Системата за една Извън рамките на работните часове Максимално сумарно отпадане на Системата в извън работно време за една година 99,50% <15 часа 98,00% <116 часа Планиране на прекъсвания (планирана Продължителност на планирана недостъпност) на недостъпност Системата < 1 час от 1 до 6 часа от 6 до 11 часа По всяко време Извън работните часове В почивни празници дни или по време на официални Забележка: (a) Ако две (или повече (b) (с) настоящия Работните Цитираните документ. планираното прекъсвания ), часове са в При прекъсване може да които не превишават съгласно Таблица таблицата данни и настъпили промени надхвърли 11 системи са системите 11 часа, часа. „Дефиниции”. актуални към ще бъдат трябва да се раздели на датата на изготвяне на актуализирани. Важно: Обявяването на планирано прекъсване става посредством уведомяване на Възложителя минимум 7 - - - - работни начална крайна причина. засегната/и дни система/и; дата и час; дата и час; предварително. Уведомяването трябва да съдържа: Приоритети Приоритет Въздействие върху работните процеси 1 Критичен Критично влияние върху работните процеси. Изисква незабавно действие, като работата продължава • Пълно администрацията, интерфейси; до неговото прекъсване на една или прекъсване отстраняване. повече работата ЕАУ, предоставяни на регистри, от приложни програмни Таблица 4 31 • Недостъпност до предоставяни през функционалността на Системата ЕАУ, които пряко и съществено засягат ключови или голям брой клиенти; • Висок риск от финансови загуби и/или засягане на имиджа на администрацията или негови контрагенти; • Създава висок риск за компрометиране на информация в Системата; • Нарушена комуникация в инфраструктурата на държавната администрация и с други държави - членки на ЕС, или на аналогични системи; • Риск за съществено прекъсване или излизане от строя на Системата; • Критична функционалност не функционира нормално или има критично и негативно отражение върху операциите на потребителите или системната среда във ведомство на Възложителя, или в имиджа на същото, или е възникнало непланирано преустановяване на достъпността. 2 Висок Съществено влияние върху работните процеси. Изисква ангажиране на необходимите ресурси за отстраняването на проблема, като работата продължава в нормалните работни часове до неговото отстраняване. • Влошаване на качеството на предлагана услуга или достъп до такава, без пълно прекъсване; • Създаване на сериозен риск от възникване на инцидент с критичен приоритет; • Критична функционалност функционира непълноценно или има силно неблагоприятно отражение върху работните процеси вследствие на неприемлива производителност или генериране на грешни данни. 3 Среден Несъществено влияние върху работните процеси. Изисква ангажиране на необходимите ресурси за отстраняване на проблема, като работата за неговото отстраняване е не повече от 7 работни дни. • Ограничено въздействие върху работата на Системата, което засяга или създава неудобство за изпълнение на отделни функции, без да има цялостно отражение върху функциите ѝ. Забавяне на отстраняването му може да доведе до възникване на инцидент от по-високо ниво. • Нормалната производителност на Системата или част от него е влошена, но по-голяма част от функционалната му способност е незасегната. 4 Нисък Няма пряко влияние върху работните процеси в момента на възникването му. Изисква ангажирането на необходимите ресурси за отстраняване на проблема, като работата за неговото отстраняване е не-повече от 14 работни дни • В момента липсва пряко влияние върху функционирането на Системата, но нерешаването му в определен срок крие потенциален риск от възникване на инцидент с по-висок приоритет. • Обикновено се свързва с подобряване на функционирането на услуга, предоставяна от Системата или развитието й. • Отстраняването се планира съвместно с Възложителя и е обект на средносрочно планиране. Възложителят може да изисква информация или помощ по възможните решения. Таблица 5 32 Параметри на качеството при отстраняване на инцидент Приоритет инцидента на Време за реакция, max План за решение, max Начин на отстраняване Срок за отстраняване на инцидента, max 1 30 минути 2 часа В специална версия 6 часа 2 1 час 4 часа В специална версия 12 часа 3 1 работен ден 1 седмица В следваща версия 7 работни дни 4 1 работен ден 1 седмица В следваща версия 14 работни дни Забележки: • Приоритетите критичност • За инциденти временно Възложителят • Всички Системата • При обективна да ги промени за се определят на инцидент“; от 1 и 2 решение, с може да времена, посочени управление невъзможност за конкретен приоритет, което снижи на от Възложителя ако за времето изцяло се приоритета на в таблицата, инциденти на да бъдат спазени инцидент; започват съгласно точка на отстраняване на възстановява работоспособността инцидента, без да го да текат от Възложителя. сроковете в таблицата, „Определяне закрива. момента на степента на проблема бъде намерено на Системата, на регистриране в Възложителят може Параметри на качеството при отстраняване на проблем Приоритет на проблема Време за реакция, max План за решение, max Начин на отстраняване Срок за отстраняване на проблема, max 1 1 час 4 часа В специална версия 24 часа 2 2 часа 24 часа В специална версия 72 часа 3 1 работен ден 1 седмица В следваща версия 7 работни дни 4 1 работен ден 1 седмица В следваща версия 14 работни дни Забележки: • За инциденти временно Възложителят • Всички Системата за от 1 и 2 решение, с може да времена, посочени управление приоритет, което снижи на ако за изцяло се приоритета на в таблицата, инциденти на времето на отстраняване възстановява инцидента, без да го започват да текат от Възложителя. на работоспособността закрива. момента проблема бъде намерено на Системата, на регистриране в 6.7.6. Управлението на промените (Change management) В техническото си предложение участниците трябва да предложат метод за управление на промените, който ще прилагат при изпълнението на поръчката, съобразявайки се с описаните по-долу изисквания. Управлението на промените цели да гарантира осигуряването на: • ускорено и устойчиво развитие в условия на намален риск на работа на Системата; • минимизиране на неблагоприятното въздействие върху потребителите при нормалната експлоатация на електронните услуги; • навременното внедряване само на одобрени промени и с минимални грешки; • ефект от промяната върху всички засегнати компоненти на Системата; • всички спешни (критични) промени да са прегледани и одобрени; • навременно и коректно информиране на ключовите заинтересовани лица относно всички аспекти на промяната. Процесът включва: • Дефиниране на необходимостта и обхвата на промяната; • Съгласуване на необходимостта и обхвата на промяната със заинтересованите страни; • Оценка на въздействието върху бизнес процеси, системна инфраструктура или приложен софтуер, необходимия финансов ресурс, ползите и рисковете свързани с промяната; • Подаване и регистриране на искане за промяна в Системата за управление на промените на Възложителя; • Приоритизиране на подадени искания за промяна на база изготвена обосновка относно функционалните и техническите изисквания, необходимите ресурси, законовите и/или договорни изисквания, които налагат промяната; • Мотивирано одобрение или отказ за одобрение на промяната; • Планиране, управление и координиране на разработката на промяната. Изготвяне на план за разработка на промяната. В плана, ако е приложимо, се включват и дейности по конвертиране и/или миграция на данни, промени в други компоненти на Системата, засегнати услуги или инфраструктура, обслужваща Системата, промени в архивиращи процедури и/или други промени, гарантиращи успешната реализация на промяната; • Дефиниране, управление и координиране на спешните промени с цел минимизиране на вероятността за последващи инциденти, изработване на оценка на въздействието и одобряване след внедряването на спешната промяна. Създаване на процедура за предоставяне и прекратяване на 33 необходимия достъп до системите и информационните активи за пускане в експлоатация на спешни промени; • Документиране, контрол и отчитане на дейностите по изпълнение на промяната (включително документиране на отхвърлените промени, проследяване на статуса на одобрените промени и приключване на процеса на промяна) с цел гарантиране, че одобрените промени са внедрени съгласно плана за внедряване на промяната; • Актуализиране на системната документация и документацията на засегнатите работни процеси и процедури; • Приемане на промяната и въвеждане в реална експлоатация, включва: o Изготвяне на план за въвеждане в експлоатация на промяната. Като в плана се включват при необходимост и дейности, които са извън обхвата на дейностите по настоящата техническа спецификация, но са предусловие за успешното реализиране на промяната. В този случай тези предусловия се ескалират до Възложителя за предприемане на действия по компетентност; o Дефиниране на тестови сценарии и критерии за приемане на промяната, подготовка на тестова среда и фактическо тестване на промяната; o Провеждане на тестове по приемане; o Подготовка на експлоатационната среда чрез мигриране на всички промени от тестовата среда към експлоатационната (хардуер; мрежови ресурси; операционни системи; приложен софтуер; данни за настройка на системни параметри, номенклатури, вътрешни и/или външни интерфейси; транзакционни данни) и фактическо мигриране; o Подготовка на участниците (компоненти на Системата и потребители) в засегнатите от промяната работни процеси, осигуряване на канали за комуникация и обучение; o Компилиране на нова версия, инсталиране в реална среда и първоначално съпровождане. • Приключване на промяната; • Отчитане на ползите и реалните ефекти от извършената промяна. Искането за промяна може (допуска се) да се инициира и от двете страни (Възложител и Изпълнител). Упълномощени представители на Възложителя или Изпълнителя могат да инициират искане за промяна. Исканията за промяна се регистрират в Системата за управление на промени на Възложителя. Регистрираните искания за промени се разглеждат от компетентни органи, където промените се преглеждат и се взема решение за съответното действие по тях. 34 7. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ Всички информационни системи и софтуерните компоненти в администрацията, в т.ч. регистри, интернет страници, вътрешни информационни системи, потребителски интерфейси към съществуващи системи, системи за предоставяне на електронни административни услуги и за електронен документооборот, трябва да отговарят на изискванията на Закона за електронното управление, Закона за киберсигурност, Закона за достъп до обществена информация и Закона за достъп до пространствени данни и подзаконовата нормативна база към тях. Неизпълнението на тези изисквания от страна на изпълнителите по договори за разработка и/ или надграждане на информационни системи/ регистри/ ЕАУ е основание за неприемане на разработеното софтуерно решение от страна на Възложителя. 7.1.Функционални изисквания към информационната система 7.1.1. Интеграция с външни информационни системи За реализиране на основни бизнес процеси Системата трябва да поддържа интеграция в реално време с хоризонталните и централните информационни системи на електронното управление, както следва: Интеграция с хоризонталните системи на ЕУ Интеграцията на Системата с хоризонталните системи за електронно управление се осъществява чрез разработване и внедряване на служебен интерфейс за обмен на данни, както следва: 35 Код Описание Приложимост Забележка* F1 Информационна система за електронна автентикация версия 2.0 Задължително, до влизане в сила на Националната схема за електронна идентификация по ЗЕИ. F2 Информационна система за сигурно електронно връчване Задължително, ако е приложимо. F3 Информационна система за електронно плащане Задължително за информационни системи, чрез които се извършват плащания на такси за ЕАУ с ниво на електронизация 4, и други задължения. F4 Информационна система за електронни форми Задължително, ако е приложимо. ▪ [Информационна система 1] - [кратко описание]; ▪ [Информационна система 2] - [кратко описание]; ▪ [Информационна система 3] - [кратко описание]. Опишете всички информационни системи, с които е необходима интеграция, както и кратко описание за какво се използват и защо е необходима интеграция. Изтрийте тази текстова кутия при финализиране на документа. 36 F5 Информационна система за е- валидация Задължително, ако е приложимо. Код Описание Приложимост Забележка* F6 Интегрираната информационна система на държавната администрация (ИИСДА), в частност Регистъра на услугите, в който се вписват допустимите заявители и получатели на административни услуги - например: проверка на достъпа до съответните обстоятелства, посочване на идентификатор на конкретна административна услуга, за която е нужно извличането на съответните обстоятелства от регистрите; Задължително, ако чрез Системата се предлагат ЕАУ. F7 При реализиране на системи за документооборот на административните органи, касаеща обмена на електронни документи, интеграцията да се извършва съгласно технически протокол, който позволява o обмен на документи между различни системи за Задължително, ако е приложимо. Информационна система 1 Потребители Информационна система 2 [Системата] Информационна система 3 Регистър база данни Информационна система 4 7.1.2. Използване на интеграционния слой на електронното управление Интеграция на Системата чрез използване на интеграционния слой на ЕУ, включващ: 37 документооборот в различни администрации; o проследяване на движението на документа и етапа на процедурата по разглеждането или съставянето му. F8 Интеграциите с външни информационни системи и регистри трябва да се реализира чрез стандартен интеграционен слой, съгласно действащите изисквания за оперативна съвместимост Задължително Код Описание Приложимост Забележка* F9 Интеграционна шина за обмен на справочна и удостоверителна информация (RegiX): - В случай че Системата се явява първичен регистър на данни, с цел присъединяване към интеграционната шина и впоследствие използването на Задължително 38 първичните данни от други АО, е необходимо да се предвиди разработката на адаптер, който да се реализира съгласно стандарта, публикуван на Портала за електронно управление, в раздел „Разработчици“; - При условие че Системата използва данни от ПАД, трябва да бъде предвидена интеграция с първични регистри чрез стандартен междинен слой или чрез националната схема за електронна идентификация – конкретната реализация трябва да бъде одобрена от Възложителя след приключване на етапа на бизнес-анализ. F10 Интеграционна шина за обмен на електронни документи Задължително, когато се обменят електронни документи чрез документооборотни системи. F11 Интеграционна шина за достъп и управление на ИТ услуги и данни на МЕУ Препоръчително F12 Информационна система за централизирано поддържане на регистри Задължително, когато се изграждат регистри, които са били водени на хартия и не са включени в графика за привеждане на регистрите на АО в съответствие със ЗЕУ чрез ИСЦИПР (ПМС № 232/20.11.2023 г) F13 Да се реализира служебен интерфейс за автоматизиран онлайн обмен на данни и Задължително 7.1.3. Технически изисквания към интерфейсите 39 предоставяне на вътрешни електронни административни услуги. F14 Трябва да бъде разработен и внедрен служебен онлайн интерфейс за автоматизирано машинно поискване и предаване на история на изпълнените транзакции по машинен обмен на данни, предоставените електронни услуги и начислени такси, към информационни системи на други публични институции и доставчици на обществени услуги, с оглед предоставяне на КАО, съгласно действащите изисквания за оперативна съвместимост. Задължително, ако е приложимо. Код Описание Приложимост Забележка* F15 Служебните онлайн интерфейси трябва да се предоставят като уеб услуги (web-services) и да осигуряват достатъчна мащабируемост и производителност за обслужване на синхронни заявки (sync pull) в реално време, с максимално време за отговор на заявки под 1 секунда за 95% от заявките, които не включват запитвания до регистри и външни системи. Задължително F16 Необходимо е да бъде разработен и внедрен служебен онлайн интерфейс за автоматизирано изпращане на транзакционна история към системата за електронна идентификация, съгласно действащите изисквания за оперативна съвместимост. Задължително F17 Трябва да бъде разработен и внедрен служебен онлайн интерфейс за електронни разплащания чрез интеграция с Централен виртуален Задължително за информационни системи, чрез които се извършват 7.1.4. Електронна идентификация на потребителите 40 ПОС терминал, позволяващ заплащане на такси за ЕАУ и други по електронен път без дължими преводни такси и комисиони. плащания на такси за ЕАУ с ниво на електронизация 4, и други задължения F18 Всички публични и служебни онлайн интерфейси трябва да бъдат реализирани с поддръжка на режими “push” и „pull”, в асинхронен и синхронен вариант – практическото прилагане на всяка от комбинациите трябва да бъде определено на етап бизнес анализ и да бъдат съобразени реалните казуси (use cases), които всеки интерфейс обслужва. Ако е приложимо F19 Трябва да се реализира интегриране на модул за разпределен кохерентен кеш (Distributed Caching) на „горещите данни“, които Системата получава и/или които се обменят през служебните онлайн интерфейси, като логиката на Системата трябва гарантира кохерентност (Cache Coherency) между кешираните данни и данните, съхранявани в базите данни. Задължително F20 Да бъде предвидено създаването и поддържането на тестова среда, достъпна за използване и извършване на интеграционни тестове от разработчици на информационни системи, включително такива, изпълняващи дейности за други администрации или за бизнеса, с цел по-лесно и устойчиво интегриране на съществуващите и бъдещи информационни системи. Задължително Код Описание Приложимост Забележка* 41 F21 Електронната идентификация на всички потребители трябва да бъде реализирана в съответствие с изискванията на Регламент ЕС 910/2014 и ЗЕИ. Задължително До F22 влизане в сила на националната схема за електронна идентификация по ЗЕИ в Системата трябва да бъде осъществена интеграция с хоризонталната система на електронното управление – е- автентикация v2.0, която поддържа интеграция с външни доставчици на идентичност, съгласно § 5 от Преходните и заключителните разпоредби на НОИИСРЕАУ. Реализацията на интеграцията трябва да бъде осъществена по стандартни протоколи SAML 2.0 и/или OpenID Connect. Задължително F23 При вписване, заличаване, извличане, предоставяне и изпращане на данни, потребителите трябва да се идентифицират в Системата чрез прочитане на уникален идентификатор от удостоверение за квалифициран електронен подпис (КЕП). Задължително за длъжностни лица при достъп на автоматизирани информационни системи Процес по регистрация на потребители F24 Да се предостави възможност за визуализиране на информация относно стъпките по регистрация и информация във връзка с процеса за потвърждаване на регистрацията и активиране на потребителския профил. Съвети към потребителите за проверка на настройките на имейл клиентите, свързани с блокиране на спам, и съвети за включване на домейна на Възложителя в „бял списък“. Задължително F25 Да има възможност за избор на потребителско име с контекстна валидация на полетата (in-line Препоръчително 42 validation), включително и за избраното потребителско име, и визуализиране на сложността на паролата като „слаба”, „нормална” и „силна”. F26 Да се реализира функционалност за потвърждение и активиране на регистрацията чрез изпращане на съобщение до регистрирания имейл адрес на потребителя, с еднократно генериран токън с ограничена времева валидност за потвърждение на регистрацията. Възможност за последващо препращане на имейла за потвърждение, в случай че е бил блокиран от системата на потребителя. Задължително F27 При реализиране на вход в Системата с удостоверение за електронна идентичност, по Националната схема за електронна идентификация по ЗЕИ, Системата трябва да използва потребителския профил, създаден в нея, чрез интерфейси и по протоколи съгласно подзаконовата нормативна уредба към Закона за електронната идентификация. В случай че даден потребител има регистриран потребителски профил в Системата, който е създаден преди въвеждането на националната схема за електронна идентификация, Системата трябва да предлага на потребителя възможност за „сливане” на профилите и асоцииране на локалния профил с този от националната система за електронна идентификация. Допустимо е Системата да поддържа и допълнителни данни и метаданни за потребителите, но само такива, които не са включени като реквизити в централизирания профил на потребителя в системата за електронна идентификация. Задължително 7.1.5. Отворени данни 43 F28 Системата трябва да се съобразява с предпочитанията на потребителите, дефинирани в потребителските им профили в системата за електронна идентификация, по отношение на предпочитаните комуникационни канали и канали за получаване на нотификации. Задължително Код Описание Приложимост Забележка* F29 Трябва да бъде разработен и внедрен автоматизиран интерфейс за осигуряване свободен публичен автоматизиран достъп документите, информацията и данните в Системата (наричани заедно „данните”). Интерфейсът трябва да осигурява достъп данните в машинночетим, отворен формат, съгласно всички изисквания на Директива 2013/37/ЕС за повторна употреба на информацията в обществения сектор и на Закона за достъп до обществена информация. на до до Задължително системи, които предоставят по ЗДОИ за данни F30 Трябва да бъде разработен и внедрен онлайн интерфейс за предоставяне на пространствени данни, в машинночетим, отворен формат и интеграция с Националния портал за достъп до пространствени данни съгласно всички изисквания на Директива 2007/2/ЕО и Закона за достъп до пространствени данни. Трябва да се поддържат всички набори от данни, които изискуеми по Директива 2007/2/ЕО и за които Възложителят се явява първичен администратор на данните. са Задължително които обработват пространствени данни за ИС, F31 Да бъде предвидена разработката и внедряването на отворени онлайн интерфейси и практически механизми, които да улеснят търсенето и достъпа до данни, които са на разположение за повторна Задължително системи, които предоставят по ЗДОИ за данни 7.1.6. Формиране на изгледи 44 употреба, като например списъци с основни документи и съответните метаданни, достъпни онлайн и в машинночетим формат, както и интеграция с Портала за отворени данни https://data.egov.bg/, който съдържа връзки и метаданни за списъците с материали, съгласно изискванията на Закона за достъп до обществена информация (ЗДОИ). F32 Трябва да се разработи и да се поддържа актуално публично описание на всички служебни и отворени интерфейси, отворените формати за данни, заедно с историята на промените в тях, в структуриран машинночетим формат. Задължително F33 Трябва да се разработят процеси по предоставяне на данни в отворен, машинночетим формат заедно със съответните метаданни. Форматите и метаданните следва да съответстват на официалните отворени стандарти. Задължително Код Описание Приложимост Забележка* F34 Потребителите на Системата трябва да получават разрези на информацията чрез филтриране, пренареждане и агрегиране на данните. Резултатът се представя чрез: ▪ Визуализиране на таблици; ▪ Графична визуализация на екран; ▪ Експорт на данни в един или в няколко от изброените формати – ODF, Excel, PDF, HTML, TXT, XML, CSV и запис върху електронен носител. Задължително 7.1.7. Администриране на Системата 7.2.Нефункционални изисквания към информационната система 7.2.1. Авторски права и изходен код 45 Код Описание Приложимост Забележка* F35 Системата трябва да осигурява администриране на потребителите и правата за достъп чрез административен панел, с който администраторите на системата да създават профили, управляват, назначават, отнемат роли и права на потребителите. Задължително Код Описание Приложимост Забележка* NF1 Всички компютърни програми, които се разработват за реализиране на Системата, трябва да отговарят на критериите и изискванията за софтуер с отворен код. Задължително NF2 Всички авторски и сродни права върху произведения, обект на закрила на Закона за авторското право и сродните му права, включително, но не само, компютърните програми, техният изходен програмен код, структурата и дизайнът на интерфейсите и базите данни, чието разработване е включено в предмета на поръчката, възникват за Възложителя в пълен обем без ограничения в използването, изменението и разпространението им и представляват произведения, създадени по поръчка на Възложителя съгласно чл. 42, ал. 1 от Закона за авторското право и сродните му права. Задължително NF3 Приложимите и допустими лицензи за софтуер с отворен код са: • GPL (General Public License) 3.0; Задължително 46 • LGPL (Lesser General Public License); • AGPL (Affero General Public License); • Apache License 2.0; • New BSD license; • MIT License; • Mozilla Public License 2.0 • EUPL (European Union Public License). NF4 Изходният код (Source Code), разработван по проекта, както и цялата техническа документация трябва да бъдат публично достъпни онлайн като софтуер с отворен код от първия ден на разработка чрез използване на система за контрол на версиите и хранилището по глава шеста, раздел ІV „Хранилище за изходен код“ от НОИИСРЕАУ. Задължително NF5 Избраният подход за изграждане на резултатния продукт (Системата) трябва да бъде детайлно описан в техническото предложение на участниците. Да се изследва възможността резултатният продукт (Системата) да се изгради частично (библиотеки, пакети, модули) или изцяло на базата на съществуващи софтуерни решения, които са софтуер с отворен код. Когато е финансово оправдано, да се предпочита този подход пред изграждането на собствено софтуерно решение в цялост, от нулата. Задължително NF6 Да бъде предвидено използването на Система за контрол на версиите и цялата информация за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, да бъде достъпна публично, онлайн, в реално време. Задължително 7.2.2. Системна и приложна архитектура 47 Код Описание Приложимост Забележка* NF7 В Техническото си предложение участникът трябва да опише добрите практики, които ще прилага по отношение на всеки аспект от системната и приложната архитектура на Системата. Системата трябва да бъде реализирана като разпределена модулна информационна система. Системата трябва да бъде реализирана със стандартни технологии и да поддържа общоприети комуникационни стандарти, които ще гарантират съвместимост на Системата с бъдещи разработки. Съществуващите модули/ функционалности трябва да бъдат рефакторирани и/ или надградени по начин, който да осигури изпълнението на настоящето изискване. Задължително NF8 Бизнес процесите и услугите трябва да бъдат проектирани колкото се може по-независимо с цел по-лесно надграждане, разширяване и обслужване. Системата трябва да е максимално параметризирана и да позволява настройка и промяна на параметрите през служебен (администраторски) потребителски интерфейс; Трябва да бъде реализирана функционалност за текущ мониторинг, анализ и контрол на изпълнението на бизнес процесите в Системата. Препоръчително NF9 При разработката, тестването и внедряването на Системата Изпълнителят трябва да прилага наложили се архитектурни (SOA, MVC Задължително 48 или еквивалентни) модели и дизайн- шаблони, както и принципите на обектно ориентирания подход за разработка на софтуерни приложения. Системата трябва да бъде реализирана със софтуерна архитектура, ориентирана към услуги - Service Oriented Architecture (SOA). NF10 Взаимодействията между отделните модули в Системата и интеграциите с външни информационни системи трябва да се реализират и опишат под формата на уеб услуги (Web Services), които да са достъпни за ползване от други системи в държавната администрация, а за определени услуги – и за гражданите и бизнеса. За всеки от отделните модули/ функционалности на Системата следва да се реализират и опишат приложни програмни интерфейси – Application Programming Interfaces (API). Приложните програмни интерфейси трябва да са достъпни и за интеграция на нови модули и други вътрешни или външни системи. Задължително NF11 Приложните програмни интерфейси и информационните обекти задължително да поддържат атрибут за версия. Задължително NF12 Програмните интерфейси, изискуемите метаданни и атрибути за версия и достъп до стари версии трябва задължително да са налични и готови за използване минимум 24 месеца след публикуване на нова версия. Задължително NF13 Версията на програмните интерфейси, представени чрез уеб услуги, трябва да поддържа версията по един или няколко от следните начини: Задължително 49 • Като част от URL-а; • Като GET параметър; • Като HTTP header (Accept или друг). NF14 За всеки отделен приложен програмен интерфейс трябва да бъде разработен софтуерен комплект за интеграция (SDK) на поне две от популярните развойни платформи (.NET, Java, PHP). Задължително NF15 Системата трябва да осигурява възможности за разширяване, резервиране и балансиране на натоварването между множество инстанции на сървъри с еднаква роля. Задължително NF16 При разработването на Системата трябва да се предвидят възможни промени, продиктувани от непрекъснато променящата се нормативна, бизнес и технологична среда. Основно изискване се явява необходимостта информационната система да бъде разработена като гъвкава и лесно адаптивна, като отчита законодателни, административни, структурни или организационни промени, водещи до промени в работните процеси. Задължително NF17 Изпълнителят трябва да осигури механизми за реализиране на бъдещи промени в Системата без промяна на съществуващия програмен код. Когато това не е възможно, времето за промяна, компилиране и пускане в експлоатация трябва да е сведено до минимум. Бъдещото развитие на Системата ще се налага във връзка с промени в правната рамка, промени в модела на работа на потребителите, промени във външни системи, интегрирани със Системата, отстраняване на констатирани Задължително 50 проблеми, промени в модела на обслужване и др. Такива промени ще се извършват през целия период на експлоатация на Системата, включително и по време на гаранционния период. NF18 Архитектурата на Системата и всички софтуерни компоненти (системни и приложни) трябва да бъдат така подбрани и/ или разработени, че да осигуряват работоспособност и отказоустойчивост на Системата, както и недискриминационно инсталиране (без различни условия за инсталиране върху физическа и виртуална среда) и опериране в продуктивен режим, върху виртуална инфраструктура, съответно върху Държавния хибриден частен облак (ДХЧО). Задължително NF19 Мрежата на държавната администрация (ЕЕСМ) ще бъде използвана като основна комуникационна среда и като основен доставчик на защитен Интернет капацитет (Clean Pipe) – изискванията на софтуерните компоненти по отношение на използвани комуникационни протоколи, TCP портове и пр. трябва да бъдат детайлно документирани от Изпълнителя, за да се осигури максимална защита от хакерски атаки и външни прониквания чрез прилагане на подходящи политики за мрежова и информационна сигурност от Възложителя в инфраструктурата на Държавния хибриден частен облак и ЕЕСМ. Задължително NF20 За търсене трябва да се използват системи за пълнотекстово търсене (например Solr, Elastic Search). Не се Задължително 7.2.3. Повторно използване (преизползване) на ресурси и готови разработки 51 допуска използването на индекси за пълнотекстово търсене в СУБД. NF21 Системата трябва да бъде разработена така, че да позволява използването ѝ много различни институции (т.нар. multitenancy), като за използване от нова институция не трябва да се изисква нова инсталация. от Задължително, ако е приложимо NF22 Трябва да бъде създаден административен интерфейс, чрез който може да бъде извършвана конфигурацията на софтуера. Задължително NF23 Всеки обект в системата трябва да има уникален идентификатор. Задължително NF24 Записите в регистрите не трябва да подлежат на изтриване или на промяна, а всяко изтриване или промяна трябва да представлява нов запис Задължително Код Описание Приложимост Забележка* NF25 Проектът следва максимално да преизползва налични публично достъпни инструменти, библиотеки и платформи с отворен код. За реализацията на Системата следва да се използват в максимална степен софтуерни библиотеки и продукти с отворен код. Задължително NF26 Участникът следва да представи базов списък със свободните компоненти и средства, които възнамерява да използва. Отворените проекти трябва да отговарят на следните критерии: • За разработката им да се използва система за управление на версиите на кода и да е наличен механизъм за Задължително 52 съобщаване на несъответствия и приемане на допълнения; • Да имат разработена техническа документация за актуалната стабилна версия; • Да имат повече от един активен програмист, работещ по развитието им; • Да имат възможност за предоставяне на комерсиална поддръжка; • Да нямат намаляваща от година на година активност; • По възможност проектите да са подкрепени от организации с идеална цел, държавни или комерсиални организации; • По възможност проектите да имат разработени unit tests с code coverage над 50%, а проектът да използва Continuous Integration (CI) подходи – build bots, unit tests run, регулярно използване на статични/динамични анализатори на кода и др. NF27 Използването на софтуер със затворен код и на инструменти, библиотеки, продукти и системи с платен лиценз става за сметка на Изпълнителя, като е допустимо в случаите, когато липсва подходяща свободна алтернатива с необходимата функционалност или тя не отговаря на горните условия. Задължително NF28 Изпълнителят трябва да осигури поддръжка от комерсиална организация, развиваща основните отворени продукти, които ще бъдат използвани като минимум за операционните системи и софтуерните продукти за управление на базите данни. Препоръчително NF29 При използването на свободни имплементации на софтуерни Задължително 53 библиотеки е необходимо да се организира копие (fork) на съответното хранилище в общото хранилище за проекти с отворен код, финансирани с публични средства в България (ttps://git.egov.bg/explore/projects). Използващите свободните библиотеки компоненти задават за „upstream repo” хранилищата, като задължително се реферира използваната версия/ commit identificator. NF30 Когато се налага промяна в изходния код на използван софтуерен компонент, промените трябва да се извършват във fork хранилището в съответствие с изискванията на основния проект. Изпълнителят трябва да извърши необходимите действия за включване на направените промени в основния проект чрез „pull requests” и извършване на необходимите изисквани от разработчиците на основния проект промени до приемането им. Тези дейности трябва да бъдат извършвани по време на целия проект. При установяване на наличие на нови версии на използваните проекти се извършва анализ на влиянието върху настоящата система. В случаите, при които се оптимизира използвана функционалност, отстраняват се пропуски в сигурността, стабилността или бързодействието, новата версия се извлича и използва след успешното изпълнение на интеграционните тестове. Задължително 7.2.4. Изграждане и поддръжка на множество среди Изпълнителят трябва да изгради и да поддържа минимум следните логически разделени среди: Управлението на средите трябва да става чрез автоматизирана система за провизиране и разгръщане на системните компоненти. При необходимост от страна на Възложителя Изпълнителят трябва да съдейства за изграждането на нови системни среди. Участникът може да предложи изграждането на допълнителни среди според спецификите на предложеното решение. 7.2.5. Процес на разработка, тестване и разгръщане 54 Среда Описаниe Среда за развойна дейност (Development) Чрез Development средата се усъвършенстването и развитието допълнителните софтуерни управление на разработката автоматизирано тестване и осигурява работата на Системата. системи и инсталации, – continuous integration др. по разработката, В тази среда са налични и необходими за средства, системи за Staging Чрез Staging средата се версия от Development средата извършват всички интеграционни натоварване. извършват тестове преди върху Production тестове, както разгръщане на нова средата. В нея се и тестовете за Тестова (Sandbox, Testing) Чрез Sandbox средата всички, Системата, могат да тестват на продукционната среда. които трябва да интеграцията си, се интегрират към без да застрашават работата Продукционна (Production) Това е средата, която е интеграция със съответните публично достъпна за външни системи и реална експлоатация и услуги. Код Описание Приложимост Забележка* NF31 Процесите, Системата, прозрачност и контрол над проекта. гражданите и по-висока отворена системите свързани с развитието на трябва да гарантират висока възможност за обществен всички разработки по Изграждането на доверие в в бизнеса налага радикално публичност и прозрачност чрез разработка и публикуването на компоненти под отворен Задължително 55 лиценз от самото начало на разработката. По този начин те биха могли да съдействат в процесите по развитие и тестване на разработките през целия им жизнен цикъл. NF32 Всички софтуерни приложения, системи, подсистеми, библиотеки и компоненти, които са необходими за реализацията на Системата, трябва да бъдат разработвани като софтуер с отворен код и да бъдат достъпни в публично хранилище. Към настоящия момент следва да се използва общото хранилище за проекти с отворен код, финансирани с публични средства в България (https://git.egov.bg/explore/projects). В Задължително. случай че върху част от компонентите, нужни за компилация, има авторски права, те могат да бъдат или в отделно хранилище с подходящия за това лиценз или за тях трябва да бъде предоставен заместващ „mock up“ компонент, така че да не се нарушава компилацията на проекта. NF33 За всеки един разработван компонент Изпълнителят трябва да покрие следните изисквания за гарантиране на качеството на извършваната разработка и на крайния продукт: • Документиране на Системата в изходния код, минимум на ниво процедура/функция/клас; • Покритие на минимум 50% от изходния код с функционални тестове [в случай на надграждане на съществуваща система – 50% от новата функционалност и 20% от съществуващата] ; • Използване на continuous integration практики; • Използване на dependency management. Участникът трябва да опише детайлно подхода си за покриване на изискванията. Задължително 7.2.6. Бързодействие и мащабируемост 7.2.6.1. Контрол на натоварването и защита от DoS/ DDoS атаки 56 NF34 Във всеки един компонент на Системата, който се build-ва и подготвя за инсталация (deployment), е необходимо да присъстват следните реквизити: • Дата и час на build; • Място/среда на build; • Потребител, извършил/стартирал build процеса. Идентификатор на ревизията от кодовото хранилище на компонента, срещу която се извършва build-ът. Задължително Код Описание Приложимост Забележка* NF35 Системата трябва да поддържа на приложно ниво „Rate Limiting” и/или „Throttling” на заявки от един и същ клиентски адрес както към страниците с уеб съдържание, така и по отношение на заявките към приложните програмни интерфейси, достъпни публично или служебно като уеб услуги (Web Services) и служебни интерфейси. Задължително NF36 Системата трябва да позволява конфигуриране от страна на администраторите на лимитите за отделни страници, уеб услуги и ресурси, които се достъпват с отделен URL/URI. Задължително NF37 Системата трябва да поддържа възможност за конфигуриране на различни лимити за конкретни автентикирани потребители (напр. системи на други администрации) и трябва да предоставя възможност за генериране на справки и статистики за броя заявки по ресурси и услуги. Задължително 7.2.6.2. Кохерентно кеширане на данни и заявки 57 Код Описание Приложимост Забележка* NF38 Отделните информационни системи, подсистеми и интерфейси трябва да бъдат проектирани и да използват системи за разпределен кохерентен кеш в случаите, в които това би довело до подобряване на производителността и мащабируемостта, чрез спестяване на заявки към СУБД или файловите системи на сървърите. Задължително NF39 Изпълнителят трябва да опише детайлно подхода и използваните механизми и технологии за реализация на разпределения кохерентен кеш, както и системните компоненти, които ще използват разпределения кеш. Задължително NF40 Разпределеният кохерентен кеш трябва да поддържа възможност за компресия на подходящите за това данни – например тези от текстов тип; компресирането на данни може да бъде реализирано и на приложно ниво. Задължително NF41 Използваният алгоритъм за създаване на ключове за съхранение/намиране на данни в кеша не трябва да допуска колизии и трябва оптимално да използва процесорните ресурси за генериране на хешове. Задължително NF42 Изпълнителят трябва да подбере подходящи софтуерни решения с отворен код за реализиране на буфериране и кеширане на данните в оперативната памет на сървърите. В зависимост от конкретните приложни случаи (Use Cases) е допустимо да се използват и внедрят различни технологии, които покриват по-добре конкретните нужди – например Задължително 7.2.6.3. Бързодействие 58 решения като Memcached или Redis в комбинация с Redis GeoAPI могат да осигурят порядъци по-висока мащабируемост и производителност за често достъпвани оперативни данни, номенклатурни данни или документи. NF43 Като минимум разпределен кохерентен кеш трябва да се предвиди при: ▪ Извличане на информация от номенклатури и атомични данни за статус и актуално състояние на партиди от регистри в информационните системи; ▪ Извличане на информация от предефинирани периодични справки; ▪ Информация от лога на транзакциите при достъп с електронно-ИД до дадена услуга; ▪ Информация за извършените плащания; ▪ Други, които са идентифицирани на етап бизнес и системен анализ. От кеша следва да бъдат изключени прикачени файлове и големи по обем резултати от справки. Задължително Код Описание Приложимост Забележка* NF44 При визуализация на уеб страници системите трябва да осигуряват висока производителност и минимално време за отговор на заявки - средното време за заявка трябва да бъде по-малко от 1 секунда, с максимум 1 секунда стандартно отклонение за 95% от заявките, без да се включва мрежовото времезакъснение (Network Latency) при транспорт на пакети между клиента и Задължително 7.2.6.4. Използване на HTTP/2 59 сървъра [В случай че функционалните изисквания предвиждат визуализация на справки или сложни електронни документи, изискването се адаптира, като се съобразява спецификата на функционалността]. Трябва да бъдат създадени тестове за натоварване. Код Описание Приложимост Забележка* NF45 С оглед намаляване на служебния трафик, времената за отговор и натоварването на сървърите следва да се използва HTTP/2 протокол при предоставяне на публични потребителски интерфейси с включени като минимум следните възможности: ▪ Включена header compression; ▪ Използване на brotli алгоритъм за компресия; ▪ Включен HTTP pipelining; ▪ HTTP/2 Server push, приоритизиращ специфични компоненти, изграждащи страниците (CSS, JavaScript файлове и др.). Задължително NF46 Публичните потребителски интерфейси трябва да поддържат адаптивен избор на TLS cipher suites според вида на процесорната архитектура на клиентското устройство - AES-GCM за x86 работни станции и преносими компютри (с налични AES-NI CPU разширения), и ChaCha20/Poly1305 за мобилни устройства (основно базирани на ARM процесори). Задължително NF47 Ако клиентският браузър/клиент не поддържа HTTP/2, трябва да бъде Задължително 7.2.6.5. Подписване на документи 60 предвиден fall-back механизъм към HTTP/1.1. Тази възможност трябва да може лесно да се реконфигурира в бъдеще и да отпадне, когато браузърите/клиентите, неподдържащи HTTP/2, станат незначителен процент. Код Описание Приложимост Забележка* NF48 При реализацията на електронно подписване с всички видове електронен подпис трябва да се подписва сигурен хеш-ключ, генериран на базата на образа/съдържанието, а не да се подписва цялото съдържание. Задължително NF49 Минимално допустимият алгоритъм за хеширане, който трябва да се използва при електронно подписване, е SHA- 256. В случаите, в които не се подписва уеб съдържание (например документи, файлове и др.), е необходимо да се реализира поточно хеширане, като се избягва зареждането на цялото съдържание в оперативната памет. Задължително NF50 Системата трябва да поддържа подписване на електронни изявления и електронни документи и с електронни подписи, издадени от Доставчици на доверителни услуги в ЕС, които отговарят на изискванията за унифициран профил на електронните подписи, съгласно подзаконовите правила към Регламент ЕС 910/2014, които влизат в сила и са задължителни от 1 януари 2017 г. Задължително NF51 Трябва да бъдат анализирани техническите възможности за Задължително 61 реализиране на подписване на електронни изявления и документи без използване на Java аплет и без да се изисква от потребителите да инсталират Java Runtime, като по този начин се осигури максимална съвместимост на процеса на подписване с всички съвременни браузъри. Такава реализация може да бъде осъществена чрез: ▪ използване на стандартни компоненти с отворен код, отговарящи на горните условия, които са разработени по други проекти на държавната администрация и са достъпни в хранилището, поддържано от Министерство на електронното управление – при наличие на такива компоненти в хранилището те трябва да се преизползват и само да бъдат интегрирани в Системата; ▪ използване на плъгин-модули с отворен код, достъпни за най- разпространените браузъри (Browser Plug-ins), които са адаптирани и поддържат унифицираните профили на електронните подписи, издавани от доставчик на удостоверителни услуги в ЕС, и съответните драйвери за крайни устройства за четене на сигурни носители или по стандартизиран в националната нормативна уредба протокол за подписване извън браузъра; 7.2.6.6. Качество и сигурност на програмните продукти и приложенията 7.2.7. Информационна сигурност и интегритет на данните 62 ▪ чрез интеграция с услуги за отдалечено подписване, предлагани от доставчици на доверителни услуги в ЕС. Код Описание Приложимост Забележка* NF52 Да бъде предвидено спазването на добри практики на софтуерната разработка – покритие на изходния код с тестове – над 60%, документиране на изходния код, използване на среда за непрекъсната интеграция (Continuous Integration), възможност за компилиране и пакетиране на продукта с една команда, възможност за инсталиране на нова версия на сървъра с една команда, система за управление на зависимостите (Dependency Management); Задължително NF53 Публичните модули, които ще предоставят информация и електронни услуги в Интернет, трябва да отговарят на актуалните web стандарти за визуализиране на съдържание. Задължително Код Описание Приложимост Забележка* NF54 Не се допуска съхранението на пароли на администратори, на вътрешни и външни потребители и на акаунти за достъп на системи (ако такива се използват) в явен вид. Всички пароли трябва да бъдат защитени с подходящи сигурни алгоритми (напр. BCrypt, PBKDF2, scrypt (RFC 7914) за съхранение на пароли и където е Задължително 63 възможно, да се използва и прозрачно криптиране на данните в СУБД със сертификати (transparent data-at-rest encryption). NF55 Да бъде предвидена система за ежедневно създаване на резервни копия на данните, които да се съхраняват извън инфраструктурата на системата. Задължително NF56 Не се допуска използването на Self- Signed сертификати за публични услуги. Задължително NF57 Всички уебстраници (вътрешни и публично достъпни в Интернет) трябва да бъдат достъпни единствено и само през протокол HTTPS. Криптирането трябва да се базира на сигурен сертификат с валидирана идентичност (Verified Identity), позволяващ задължително прилагане на TLS 1.2, който е издаден от удостоверителен орган, разпознаван от най-често използваните браузъри (Microsoft Internet Explorer, Google Chorme, Mozilla Firefox). Ежегодното преиздаване и подновяване на сертификата трябва да бъде включено като разходи и дейности в гаранционната поддръжка за целия срок на поддръжката. Задължително NF58 Трябва да бъдат извършени тестове за сигурност на всички уебстраници, като минимум чрез автоматизираните средства на SSL Labs за изпитване на сървърна сигурност (https://www.ssllabs.com/ssltest/). За Задължително нуждите на автентикация с КЕП трябва да се предвиди имплементирането на обратен прокси сървър (Reverse Proxy) с балансиране на натоварването, който да препраща клиентските сертификати към вътрешните приложни сървъри с 64 нестандартно поле (дефинирано в процеса на разработка на Системата) в HTTP Header-а. Схемата за проксиране на заявките трябва да бъде защитена от Spoofing. NF59 Като временна мярка за съвместимост настройките на web сървърите и Reverse Proxy сървърите трябва да бъдат балансирани така, че Системата да позволява използване и на клиентски браузъри, поддържащи по-стария протокол TLS 1.1. Това изключение от общите изисквания за информационна сигурност не се прилага за достъпа на служебни потребители от държавната администрация и доставчици на обществени услуги, които имат служебен достъп до ресурси на Системата. Задължително NF60 При разгръщането на всички web услуги (Web Services) трябва да се използва единствено протокол HTTPS със задължително прилагане на минимум TLS 1.2. Задължително NF61 Програмният код трябва да включва методи за автоматична санитизация на въвежданите данни и потребителски действия за защита от злонамерени атаки, като минимум SQL инжекции, XSS атаки и други познати методи за атаки, и да отговаря, където е необходимо, на Наредбата за минималните изисквания за мрежова и информационна сигурност. Задължително NF62 При проектирането и разработката на компонентите на Системата и при подготовката и разгръщането на средите трябва да се спазват последните актуални препоръки на Задължително 65 OWASP (Open Web Application Security Project). NF63 Трябва да бъде изграден модул за проследимост на действия и събития в Системата. Записът за всяко действие (добавяне, изтриване, модификация, четене) трябва да съдържа следните атрибути: o Уникален номер; o Точно време на възникване на събитието; o Вид (номенклатура от идентификатори за вид събитие); o Данни за информационна система, където е възникнало събитието; o Име или идентификатор на компонент в информационната система, регистрирал събитието; o Приоритет; o Описание на събитието; o Данни за събитието. Задължително NF64 Астрономическото време за удостоверяване настъпването на факти с правно или техническо значение се отчита с точност до година, дата, час, минута, секунда и при технологична необходимост - милисекунда, изписани в съответствие със стандарта БДС ISO 8601:2006. Задължително NF65 Астрономическото време за удостоверяване настъпването на факти с правно значение и на такива, за които се изисква противопоставеност, трябва да бъде удостоверявано с електронен времеви печат по смисъла на Глава III, Раздел 6 от Регламент ЕС 910/2014. Трябва да бъде реализирана функционалност за получаване на точно астрономическо време, отговарящо на горните условия от доставчик на доверителни услуги или Задължително 7.2.8. Използваемост 7.2.8.1. Общи изисквания за използваемост и достъпност 66 от държавен орган, осигуряващ такава услуга, отговаряща на изискванията на RFC 3161. NF66 Трябва да бъдат проведени тестове за проникване (penetration tests), с които да се идентифицират и коригират слаби места в сигурността на Системата. Задължително NF67 При идентификация на регистри и бази данни да се използва електронно удостоверение във формат X.509, издаден за съответния регистър. Идентификацията се осъществява двустранно по протокол TLS (Transport Layer Security - Сигурност на транспортния слой), версия 1.2 или по- висока, дефиниран в Препоръка RFC 5246, приета от IETF Задължително NF68 Информационните системи на административните органи да се идентифицират пред регистрите чрез цифров сертификат, двустранно по протокол TLS (Transport Layer Security - Сигурност на транспортния слой), версия 1.2 или по-висока. Задължително Код Описание Приложимост NF69 При проектирането и разработката на страници и мобилни приложения трябва спазват стандартите за достъпност на потребителския интерфейс за хора с WCAG 2.1. интернет да се увреждания Задължително NF70 Съдържанието на интернет страниците и мобилните приложения на административните органи, на доставчиците на обществени на лицата, осъществяващи публични трябва да отговаря на последната обнародвана услуги и функции, в Задължително 67 „Официалния вестник” на Европейския съюз версия на хармонизирания стандарт EN 301 549, освен в случаите по чл. 58в, ал. 2 или 3 от ЗЕУ. NF71 Всички ресурси трябва да са достъпни чрез GET заявка на уникален адрес (URL). Не се допуска използване на POST за достигане до формуляр за подаване не заявление, за генериране на справка и други. Задължително NF72 Функционалностите на потребителския интерфейс на Системата трябва да бъдат независими от използваните от потребителите интернет браузъри и устройства, при условие че последните са версии в период на поддръжка от съответните производители. Трябва да бъде осигурена възможност за ползване на публичните модули на приложимите услуги през мобилни устройства – таблети и смарт- телефони, чрез оптимизация на потребителските интерфейси за мобилни устройства (Responsive Design). При използване на Captcha се осигуряват алтернативни форми с използване на изходи за различни видове сетивни възприятия, съобразени с различните увреждания. Задължително NF73 Не се допуска използване на Captcha като механизъм за ограничаване на достъпа до документи и/или услуги. Алтернативно, Системата трябва да поддържа „Rate Limiting” и/или „Throttling” съгласно изискванията в т. 7.1.1. от настоящите изисквания. Допуска се използването на Captcha единствено при идентифицирани много последователни опити от предполагаем „бот“. Задължително NF74 Трябва да бъде осигурен бърз и лесен достъп до електронните услуги и те да бъдат промотирани с подходящи навигационни елементи на публичната интернет страница – банери, елементи от главното меню и др. Задължително NF75 Публичните уебстраници на Системата трябва да бъдат проектирани и оптимизирани за ефективно и бързо индексиране от търсещи Задължително 68 машини с цел популяризиране сред потребителите и по-добра откриваемост при търсене по ключови думи и фрази. При разработката на страниците и при изготвяне на автоматизираните процедури за разгръщане на нова версия на Системата трябва да се използват инструменти за минимизиране и оптимизация на размера на изходния код (HTML, JavaScript и пр.) с оглед намаляване обема на файловете и по-бързо зареждане на страниците. NF76 Не се допуска използването на HTML Frames, за да не се пречи на оптимизациите за търсещи машини. Задължително NF77 При разработката на публични уеббазирани страници трябва да се използват и да се реализира поддръжка на: o Стандартните семантични елементи на HTML5 (HTML Semantic Elements); Задължително o JSON-LD 1.0 (http://www.w3.org/TR/json- ld/); o Open Graph Protocol (http://ogp.me) за осигуряване на поддръжка за качествено споделяне на ресурси в социални мрежи и мобилни приложения. NF78 В екранните форми на Системата трябва да се използват потребителски бутони с унифициран размер и лесни за разбиране текстове в еднакъв стил. Задължително NF79 Всички текстови елементи от потребителския интерфейс трябва да бъдат визуализирани с шрифтове, които са подходящи за изобразяване на екран и които осигуряват максимална съвместимост и еднакво възпроизвеждане под различни клиентски операционни системи и браузъри. Не се допуска използването на серифни шрифтове (Serif). Задължително 69 NF80 Полета, опции от менюта и командни бутони, които не са разрешени конкретно за ролята на влезлия в системата потребител, не трябва да са достъпни за този потребител. Това не отменя необходимостта от ограничаване на достъпа до бизнес логиката на приложението чрез декларативен или програмен подход. Задължително NF81 Всяка екранна форма трябва да има наименование, което да се изписва в горната част на екранната форма. Наименованията трябва да подсказват на потребителя какво е предназначението на формата. Задължително NF82 Всички търсения трябва да са нечувствителни към малки и главни букви. Задължително NF83 Полетата за пароли трябва задължително да различават малки и главни букви. Задължително NF84 Полетата за потребителски имена трябва да позволяват използване на имейл адреси като потребителско име, включително да допускат всички символи, регламентирани в RFC 1123, за наименуването на хостове. Задължително NF85 Главните и малките букви на въвежданите данни се запазват непроменени, не се допуска Системата да променя капитализацията на данните, въвеждани от потребителите. Задължително NF86 Системата трябва да позволява въвеждане на данни, съдържащи както български, така и символи на официалните езици на ЕС. Задължително NF87 Наименованията на полетата следва да са достатъчно описателни, като максимално се доближават до характера на съдържащите се в тях данни. Задължително NF88 Системата трябва да поддържа прекъсване на потребителски сесии при липса на активност. Времето трябва да може да се променя от администратора на системата без промяна в изходния код. Настройките за време за прекъсване на неактивни сесии трябва да включват и възможността администраторите да Задължително 7.2.8.2. Интернационализация 70 дефинират стилизирана страница с информативно съобщение, към която да пренасочва автоматично браузърите на потребителите в случай на прекъсната Системата сесия. NF89 Дългите списъци с резултати трябва да се разделят на номерирани страници с навигационни елементи за преминаване предишна, следваща, първа и последна страница, към конкретна страница. Навигационните елементи трябва да са логически обособени и свързани със списък и да се визуализират в началото и на HTML контейнера, съдържащ списъка. подходящи към съответния в края Задължително NF90 За големите йерархически категоризации да се предвиди възможност и за навигация нива или чрез отложено зареждане (lazy трябва по load). Задължително NF91 Интернет страниците на администрациите трябва отговарят на правилата за институционална идентичност, определени министъра на електронното управление. Наименованията на домейните и поддомейните, използвани от административните органи официалните им интернет страници и трябва да отговарят на изискванията на чл. НОИИСРЕАУ. Ако се използват споделени информационни ресурси от ДХЧО за инсталиране на Системата, за публичен интернет може да се използват поддомейни egov.bg със следната конвенция: [име на система].egov.bg. Например: iara-iss.egov.bg, strategy.egov.bg и др. от за портали, 47 от достъп в на Задължително Код Описание Приложимост Забележка NF92 Системата трябва да може да съхранява и едновременно да визуализира данни и съдържание, Задължително 71 което е въведено/генерирано на различни езици. NF93 Всички софтуерни компоненти на Системата, използваните софтуерни библиотеки и развойни комплекти, приложните сървъри и сървърите за управление на бази данни, елементите от потребителския интерфейс, програмно-приложните интерфейси, web услугите и др. трябва да поддържат стандартно и да са конфигурирани изрично за спазване на минимум Unicode 5.2 стандарт при съхранението и обработката на текстови данни, съответно трябва да се използва само UTF-8 кодиране на текстовите данни. Задължително NF94 Всички публично достъпни потребителски интерфейси следва да поддържат многоезичност, като минимум български и английски език. Задължително NF95 Публичната част на Системата трябва да бъде разработена и да включва набори с текстове на минимум два официални езика в ЕС, а именно български и английски език. Преводите на английски език трябва да бъдат осъществени професионално, като не се допуска използването на средства за машинен превод без ръчна проверка и корекции от професионални преводачи. Задължително NF96 Версиите на съдържанието на съответните езици трябва да включват всички текстове, които се визуализират във всички елементи на потребителския интерфейс, справките, генерираните от системата електронни документи, съобщения, нотификации, имейл съобщения, номенклатурите и таксономиите и др. Данните, които се Задължително 72 съхраняват в Системата само на български език, се изписват/визуализират на български език. NF97 Системата трябва да позволява превод на всички многоезични текстове с подходящ потребителски интерфейс, достъпен за администратори на Системата, без промени в изходния код. Модулът за превод на текстове, използвани в Системата, трябва да поддържа и контекстни референции, които да позволяват на администраторите да тестват и да проверяват бързо и лесно направените преводи и тяхната съгласуваност в реалните екрани, страници и документи. Задължително NF98 Публичната част на Системата трябва да позволява превключване между работните езици на потребителския интерфейс в реално време от профила на потребителя и от подходящ, видим и лесно достъпен навигационен елемент в горната част на всяка страница, който включва не само текст, но и подходяща интернационална икона за съответния език. Задължително NF99 При визуализация на числа трябва да се използва разделител за хиляди (интервал). Задължително NF100 При визуализация на дати и точно време в елементи от потребителския интерфейс в генерирани справки или в електронни документи всички формати за дата и час трябва да са съобразени с избрания от потребителя език/локация в настройките на неговия профил: Задължително 7.2.8.3. Изисквания за използваемост на потребителския интерфейс 73 • За България стандартният формат е „DD.MM.YYYY HH:MM:SS”, като наличието на време към датата е в зависимост от вида на визуализираната информация и бизнес смисъла от показването на точно време; • Системата трябва да поддържа и всички формати съгласно ISO БДС 8601:2006. Код Описание Приложимост Забележка NF101 Електронните форми за подаване на заявления и за обявяване на обстоятелства трябва да бъдат реализирани с AJAX или с аналогична технология, като по този начин се гарантират следните функционалности: • Контекстна валидация на въвежданите данни на ниво „поле” от форма и контекстни съобщения за грешка/невалидни данни в реално време; • Възможност за избор на стойности от номенклатури чрез търсене в списък по част от дума (autocomplete) и визуализиране на записи, отговарящи на въведеното до момента, без да е необходимо пълните номенклатури да са заредени в браузъра на клиента и потребителят да скролира дълги списъци с повече от 10 стойности. Задължително NF102 В електронните форми трябва да бъде реализирана валидация на Задължително 74 въвежданите от потребителите данни на ниво „поле” (in-line validation). Валидацията трябва да се извършва в реално време на сървъра, като при успешна валидация данните от съответното поле следва да бъдат запазени от сървъра. NF103 Системата трябва да гарантира, че въведените, валидираните и запазените от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност, потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи. Задължително NF104 Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на Системата, без да са необходими промени в изходния код, на контекстна помощна информация за: o всяка електронна форма или стъпка от процес, за която има отделен екран/форма; o всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично); o всяко отделно поле за въвеждане на данни. Задължително 75 NF105 Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета. Задължително NF106 Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини. Задължително NF107 Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро- бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на „Mouse Hover/Mouse Over” събития. Задължително 7.2.8.4. Изисквания за използваемост в случаи на прекъснати бизнес процеси 76 NF108 При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани. Задължително NF109 Потребителският интерфейс следва да бъде достъпен за хора с увреждания съгласно изискванията на чл. 48, ал. 5 от ЗОП. Задължително Код Описание Приложимост Забележка NF110 Системата трябва да съхранява перманентно всеки започнал процес/процедура по подаване на заявление или обявяване на обстоятелства, текущия му статус и всички въведени данни и прикачени документи дори ако потребителят е прекъснал волно или неволно потребителската си сесия. Задължително NF111 При вход в системата потребителят трябва да получава прегледна и ясна нотификация, че има започнати, но недовършени/ неизпратени/ неподписани заявления, и да бъде подканен да отвори модула за преглед на историята на транзакциите. Задължително NF112 Модулът за преглед на историята на транзакциите трябва да поддържа следните функционалности: • Да визуализира списък с историята на подадените Задължително 7.2.8.5. Изисквания за проактивно информиране на потребителите 77 заявления, като минимум със следните колони – дата, входящ номер, код на типа формуляр, подател (име на потребител и имена на физическото лице - подател), статус на заявлението; • Да предлага видни и лесни за използване от потребителите контроли/инструменти: - за филтриране на списъка (от дата до дата, за предефинирани периоди, като „последния един месец”, „последната една година”; - сортиране на списъка по всяка от колоните, без това да премахва текущия филтър; - свободно търсене по ключови думи по всички колони в списъка и метаданните на прикачените/свързаните документи със заявленията, което да води до динамично филтриране на списъка. Код Описание Приложимост Забележка NF113 За всички публични интернет страници трябва да бъде реализирана функционалност за публикуване на всяко периодично обновявано съдържание (новини, обявления, обществени поръчки, отворени работни позиции, нормативни документи, отговори по ЗДОИ и др.) в стандартен формат (RSS 2.х, Atom или еквивалент), както и поддържането на публично достъпни статистики за посещаемостта на страницата. Задължително 7.2.9. Системен журнал 78 NF114 Системата трябва да поддържа възможност за автоматично генериране на електронни бюлетини, които да се разпращат периодично или при настъпване на събития по електронна поща до регистрираните в Системата потребители, които са заявили или са се съгласили да получават такива бюлетини; Потребителите трябва да имат възможност да настройват предпочитанията през потребителския си профил в Системата. Задължително Код Описание Приложимост Забележка NF115 Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни: • дата/час на действието; • модул на системата, в който се извършва действието; • действие; • обект, над който е извършено действието; • допълнителна информация; • IP адрес и браузър на потребителя. Задължително NF116 По време на работа на системата потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на Системата. Задължително NF117 Специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално Задължително 7.2.10. Дизайн на бази данни и взаимодействие с тях 79 предвидена за целта база данни, отделна от работната база данни на системата. NF118 Данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на системата трябва първо да възстанови архивните данни. Задължително NF119 Трябва да бъде предоставен достъп до системния журнал на органите на реда чрез потребителски или програмен интерфейс; за достъпа трябва да се изисква електронна идентификация. Задължително Код Описание Приложимост Забележка NF120 Дизайнът на схемата на базата данни (ако има такава) трябва да бъде с максимално ниво на нормализация, освен ако това не би навредило сериозно на производителността. Задължително NF121 Базата данни трябва да може да оперира в клъстер, в определени случаи следва да бъде използван т.нар. sharding. Задължително NF122 Имената на таблиците и колоните трябва да следват унифицирана конвенция. Задължително NF123 Трябва да бъдат създадени индекси по определени колони, така че да се оптимизират най-често използваните Задължително 80 заявки; създаването на индекс трябва да е мотивирано и подкрепено със замервания. NF124 Връзките между таблици трябва да са дефинирани чрез foreign key. Задължително NF125 Периодично трябва да бъде правен анализ на заявките, включително чрез EXPLAIN (при SQL бази данни), и да бъдат предприети мерки за оптимизиране на бавните такива. Задължително NF126 Задължително трябва да се използват транзакции, като нивото на изолация трябва да бъде мотивирано в предадената документация. Задължително NF127 При операции върху много записи (batch) следва да се избягват дългопродължаващи транзакции. Задължително NF128 Заявките трябва да бъдат ограничени в броя записи, които връщат. Задължително NF129 При използване на ORM или на друг слой на абстракция между приложението и базата данни, трябва да се минимизира броят на излишните заявки (т.нар. n+1 selects проблем). Задължително NF130 При използване на нерелационна база данни трябва да се използват по- бързи и компактни протоколи за комуникация, ако такива са достъпни. Задължително NF131 При обработката на данните да се спазват формализираните описания, които подлежат на задължително унифициране: 1. имена; 2. адрес; 3. единен граждански номер; 4. личен номер на чужденец; Задължително 7.2.11. Изисквания по отношение на киберсигурност в съответствие с чл. 12, ал. 1 от НМИМИС С цел достигане на изискваното ниво на сигурност на информацията, в мрежите и информационните системи следва да се предвидят следните изисквания: 81 5. ЛН - личен номер (за гражданите на Европейския съюз и техните семейства); 6. единен идентификационен код, определен от Агенцията по вписванията; 7. единен идентификационен код (код по БУЛСТАТ); 8. служебен номер по чл. 84, ал. 3 от Данъчно-осигурителния процесуален кодекс; 9. наименование на юридическо лице; 10. телефонни номера; 11. други, определени от министъра на електронното управление. NF132 Във връзка с изискванията за оперативна съвместимост, при разработка на Системата да се предвиди: • използването на дефинираните вече обекти в Регистъра на информационните обекти; • вписване на формализирани описания на данните, ако чрез Системата се обработват данни, за които АО е първичен администратор. Задължително Код Описание Приложимост Забележка NF133 Да бъдат включени адекватни и комплексни изисквания за мрежова и информационна сигурност, основани на анализ и оценка на риска, с цел да Задължително 82 се гарантира, че изискваното ниво на сигурност на информацията, мрежите и информационните системи е заложено още в етапа на разработка и внедряване NF134 Да се представят анализ и оценка на риска, които да послужат като основа за включването на адекватни и комплексни изисквания за мрежова и информационна сигурност. Задължително NF135 Ненужните портове по протоколи TCP и User Datagram Protocol (UDP) да бъдат забранени чрез адекватно конфигуриране на използваните софтуерни решения, хардуерни устройства и оборудване за защита и контрол на трафика. Задължително NF136 Да се използва отделна, изолирана от другите информационни и комуникационни системи и от интернет, подходящо защитена среда (мрежа, система, софтуер и др.) за целите на администриране на информационните и комуникационните системи и техните компоненти. Тази среда трябва да не се използва за други цели. Задължително NF137 Да се валидират всички входни данни, постъпващи от клиента, включително съдържанието, предоставено от потребителя, и съдържанието на браузъра, като headеrs на препращащия и потребителски агент Задължително NF138 Всички данни да бъдат кодирани с HTML, изпращани от клиента и показвани в уебстраница. Задължително 83 NF139 Да се ограничават заявките и по- специално по максимална дължина на съдържанието, максимална дължина на заявката и максимална дължина на заявката по URL. Задължително NF140 Да се конфигурират типът и размерът на headers, които уебсървърът ще приеме. Задължително NF141 Да се ограничава времетраенето на връзката (connection Timeout) - времето, за което сървърът изчаква всички headers на заявката, преди да я прекъсне, както и минималният брой байтове в секунда при изпращане на отговор на заявка. Задължително NF142 Да се въведе ограничение на броя неуспешни опити за влизане в системата Задължително NF143 Да не се допуска извеждането на списък на уебдиректориите. Задължително NF144 Бисквитките (cookies) задължително да имат: • флаг за защита (security flag), който инструктира браузъра, че „бисквитката“ може да бъде достъпна само чрез защитени SSL канали; • флаг HTTP only, който инструктира браузъра, че „бисквитката“ може да бъде достъпна само от сървъра, а не от скриптовете, от страна на клиента. Задължително NF145 Да се предвидят и предприемат мерки за защита на DNS, като задължително се прилага DNSSEC (Domain Name System Security Extensions); Задължително 84 NF146 По отношение на системните записи (Logs) да бъдат предвидени следните възможности: • в сървъри за приложения, които поддържат критични дейности, сървъри от системната инфраструктура, сървъри от мрежовата инфраструктура, охранителни съоръжения, станции за инженеринг и поддръжка на индустриални системи, мрежово оборудване и работни места на администратори се регистрират автоматично всички събития, които са свързани най-малко с автентикация на потребителите, управление на профилите, правата на достъп, промени в правилата за сигурност и функциониране на информационните и комуникационните системи; • за всяко от тези събития в записите се отбелязва с астрономическото време, когато е настъпило събитието; • да бъде предвидена възможност за синхронизиране на часовниците на компоненти на информационните и комуникационните системи, като се използва протокол NTP V4 (Network Time Protocol, версия 4.0 и следващи), основан на RFC 5905 на IETF от 2010 г., като се осигурява хронометрична детерминация с времевата скала на UTC (Coordinated Universal Time), или аналогичен; • да се предвиди как информацията ще бъде архивирана за срок, не по- кратък от дванадесет месеца Задължително 8. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА 8.1. Дейност 1 [Наименование на дейността] 8.1.1. Описание на дейността 8.1.2. Изисквания към изпълнение на дейността 8.1.3. Очаквани резултати 8.2. Дейност 2 [Наименование на дейността] 8.2.1. Описание на дейността 8.2.2. Изисквания към изпълнение на дейността 8.2.3. Очаквани резултати 8.3. Дейност 3 [Наименование на дейността] 8.3.1. Описание на дейността 8.3.2. Изисквания към изпълнение на дейността 8.3.3. Очаквани резултати 8.4. Дейност 4 [Наименование на дейността] 8.4.1. Описание на дейността 8.4.2. Изисквания към изпълнение на дейността 8.4.3. Очаквани резултати 8.5. Дейност 5 [Наименование на дейността] 8.5.1. Описание на дейността 8.5.2. Изисквания към изпълнение на дейността 8.5.3. Очаквани резултати 9. ДОКУМЕНТАЦИЯ 9.1. Изисквания към документацията ▪ Цялата документация и всички технически описания, ръководства за работа, администриране и поддръжка на Системата, включително на нейните съставни части, трябва да бъдат налични и на български език; 85 ▪ Всички документи трябва да бъдат предоставени от Изпълнителя в електронен формат (ODF/ /Office Open XML/MS Word DOC/RTF/PDF/HTML или др.), позволяващ пълнотекстово търсене/търсене по ключови думи и копиране на части от съдържанието от оригиналните документи във външни документи, за вътрешна употреба на възложителя; ▪ Навсякъде, където в документацията има включени диаграми или графики, те трябва да бъдат вградени в документите в оригиналния си векторен формат; ▪ Детайлна техническа документация на програмния приложен интерфейс (API), включително за поддържаните web услуги, команди, структури от данни и др. Документацията да бъде придружена и с примерен програмен код и/или библиотеки (SDK) за реализиране на интеграция с външни системи, разработен(и) на Java или .NET. Примерният код трябва да е напълно работоспособен и да демонстрира базови итерации с API-то: o Регистриране на крайна точка (end-point) за получаване на актуализации от Системата в реално време; o Заявки за получаване на номенклатурни данни (списъци, таксономии); o Заявки за актуализиране на номенклатурни данни (списъци, таксономии); o Регистрация на потребител; o Идентификация и оторизация на потребител или web услуга; ▪ Документацията за приложния програмен интерфейс (API) трябва да бъде публично достъпна; ▪ Всеки предоставен REST приложно-програмен интерфейс трябва да бъде документиран чрез API Blueprint (https://github.com/apiaryio/api-blueprint), Swagger (http://swagger.io) или чрез аналогична технология. Аналогично представяне трябва да бъде изготвено и за SOAP интерфейсите; ▪ Детайлна техническа документация за схемата на базата данни – структури за данни, индекси, дялове, съхранени процедури, конфигурации за репликация на данни и др. ▪ Ръководства на потребителя и администратора за работа и администриране на Системата. ▪ Обща информация, инструкции и процедури за администриране и поддръжка на приложните сървъри, сървърите за бази данни и др. ▪ Обща информация, инструкции и процедури за администриране, архивиране и възстановяване, и поддръжка на сървъра за управление на бази данни. 86 9.2. Прозрачност и отчетност ▪ В обхвата на проекта е включено извършване на дейности по анализ на бизнес процеси и нормативна уредба, проектиране на системна и приложна архитектура, разработване на компютърни програми и други дейности, свързани с предоставяне на специализирани професионални услуги. Изпълнителят и Възложителят трябва да публикуват подробни месечни отчети в машинночетим отворен формат за извършените дейности, включително количеството изработени човекодни по дейности, извършени от консултанти, експерти, специалисти и служители на Изпълнителя и Възложителя. Документацията, предоставена от Изпълнителя на Възложителя, трябва да бъде: ▪ на български език; ▪ само в електронен формат, като копирането и редактирането на предоставените документи следва да бъде лесно осъществимо; ▪ актуализирана в съответствие със съгласувана с възложителя процедура, която следва да включва документи, подлежащи на промяна/актуализация, крайни срокове и нужната за случая методология. Минимално изискуемата документация по проекта включва следните документи: 9.3. Системен проект Изпълнителят на настоящата поръчка трябва да дефинира в детайли конкретния обхват на реализация на софтуерната разработка и да документира изискванията към софтуера в детайлна техническа спецификация (системен проект), която ще послужи за пряка изходна база за разработка. При документирането на изискванията – с цел постигане на яснота и стандартизация на документите, е необходимо да се използва утвърдена нотация за описание на бизнес модели. Изготвената детайлна техническа спецификация (системен проект) се представя за одобрение на Възложителя. В случай на забележки, корекции или допълнения от страна на Възложителя Изпълнителят е длъжен да ги отрази в детайлната техническа спецификация (системен проект). 9.4. Техническа документация Всички продукти, които ще се доставят, трябва да са със специфична документация за инсталиране и/или техническа документация, в това число: ▪ Ръководство за администратора, включващо всички необходими процедури и скриптове по инсталиране, конфигуриране, архивиране, възстановяване и други, необходими за администриране на Системата; 87 ▪ Документи за крайния ползвател – Изпълнителят трябва да предостави главното Ръководство на ползвателите на софтуера. Документът е предназначен за крайните ползватели. Той трябва да описва цялостната функционалност на приложния софтуер и съответното му използване от крайни ползватели; ▪ Детайлно описание на базата данни; ▪ Описание на софтуерните модули; ▪ Описание на изходния програмен код. 9.5. Протоколи Изпълнителят трябва да изготвя протоколи от изпълнението на различните етапи на проекта, описани в раздел 8 на настоящия документ, заедно със съпътстващите ги документи – резултати от изпълнението на етапите. 9.6. Комуникация и доклади За успешното изпълнение на проекта участниците в настоящата обществена поръчка трябва да предложат адекватен механизъм за управление на проектната комуникация, който е неразделна част от предлаганата цялостна проектна методология. Управлението на комуникацията трябва да включва изготвяне на минимум следните регулярни доклади за статуса и напредъка на изпълнението на поръчката: 9.6.1. Встъпителен доклад Встъпителният доклад трябва да бъде предоставен до един месец от подписването на договора и да съдържа описание минимум на: ▪ Подробен работен план и актуализиран времеви график за периода на проекта; ▪ Начини на комуникация; ▪ Отговорни лица и екипи. Встъпителният доклад следва да бъде одобрен от Възложителя. 9.6.2. Междинни доклади Междинните доклади трябва да бъдат представяни и да се предават при приключване на всяка от дейностите и поддейностите и/или при настъпване на събитие. Междинните доклади трябва да съдържат информация относно изпълнението на дейностите и поддейностите по предварително изготвения проектен план. Докладът за междинния напредък трябва да бъде подготвен по следния начин: 88 ▪ Общ прогрес по дейностите през периода; ▪ Постигнати проектни резултати за периода; ▪ Срещнати проблеми, причини и мерки, предприети за преодоляването им; ▪ Рискове за изпълнение на свързани дейности и на проекта като цяло и предприети мерки; ▪ Актуализиран план за изпълнение, ако има такъв. Всеки междинен доклад следва да бъде одобрен от Възложителя. 9.6.3. Окончателен доклад В края на периода за изпълнение трябва да се представи окончателен доклад. Окончателният доклад трябва да съдържа описание на изпълнението и резултати. Докладите се изпращат до отговорния служител на възложителя. За тази цел възложителят ще определи в договора отговорния/отговорните служител/служители. Всички доклади се представят на български език в електронен формат и изпращат от Изпълнителя по договора чрез системата за сигурно електронно връчване или на официалния е-мейл на Възложителя. Докладите се одобряват от отговорния/отговорните служител/служители в срок до 5 работни дни. Възложителят задължително входира в своята деловодна система преписката по договора. Всички доклади трябва да се представят на възложителя на български език на електронен носител. Представянето на докладите трябва да се извършва чрез подписване на двустранни предавателно-приемателни протоколи, подписани от представители на изпълнителя и на възложителя. Възложителят разглежда представените доклади и уведомява изпълнителя за приемането им без забележки или ги връща за преработване, допълване и/или окомплектоване, ако не отговарят на изискванията, като чрез упълномощено в договора лице дава указания и определя срок за отстраняване на констатираните недостатъци и пропуски. 10. РЕЗУЛТАТИ Очакваните резултати от изпълнението на настоящата обществена поръчка са следните: (Описват се конкретните резултати съобразно одобреното проектно предложение)” § 9. Приложение № 2 към чл. 38, ал. 4 се отменя. ПРЕХОДНИ И ЗАКЛЮЧИТЕЛНИ РАЗПОРЕДБИ 89 § 10. В срок до три месеца от обнародването на постановлението в „Държавен вестник“ министърът на електронното управление осигурява технологична и техническа възможност за осъществяване на достъпа до ССЕВ по чл. 27а. § 11. Постановлението влиза в сила от деня на обнародването му в „Държавен вестник“, с изключение на § 2, който влиза в сила три месеца след обнародването му. МИНИСТЪР - ПРЕДСЕДАТЕЛ: РОСЕН ЖЕЛЯЗКОВ ГЛАВЕН СЕКРЕТАР НА МИНИСТЕРСКИЯ СЪВЕТ: ГАБРИЕЛА КОЗАРЕВА ______________________________________________________________ ГЛАВЕН СЕКРЕТАР НА МЕУ: РОСИЦА ЦВЕТКОВА ДИРЕКТОР НА ДИРЕКЦИЯ ПДОП: ВЯРА ПАНАЙОТОВА 90

Образецът на частична предварителна оценка на въздействието влиза в сила от 01 януари 2021 г. Частична предварителна оценка на въздействието Институция: Министерство на електронното управление Нормативен акт: Проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги, приета с Постановление № 3 на Министерския съвет от 2017 г. Лице за контакт: Вяра Панайотова Директор на дирекция „Правни дейности и Телефон и ел. поща: 02/949 2386 v.panayotova@egov.government.bg обществени поръчки“, Министерство електронното управление на 1. Проблем/проблеми за решаване: Проблем 1 „Недостатъчно използване осъществяване на контакт с гражданите услуги“ 1.1. Кратко опишете проблема/проблемите и причините Законът за администрацията предвижда обслужване в администрацията да се 1). Това е Наредбата за административното да осигуряват електронни адреси и телефони 2), но не регламентира и обратния механизъм за проактивно осъществяване орган. Съгласно чл. 18а, ал. 12 от административен акт се създават права органи, лицата, осъществяващи публични услуги, изпращат информация за изтичането че разполагат с техни електронни адреси. осъществяването на контакт с гражданите Съгласно чл. 26, ал. 2 от Закона за изявления от доставчиците на електронни изпращане на съобщение на електронния на при за общите определят с за подход. на контакт или функции, на Не в хипотези, електронното адрес, съвременните технологии в процеса на предоставянето на електронни административни неговото/тяхното възникване. По възможност посочете числови стойности. правила за организацията на административното наредба, приета от Министерския съвет (чл. 5а, ал. обслужване (НАО), която задължава администрациите връзка за комуникация с потребителите (чл. 8а, ал. Законодателят частично е предвидил конкретен с физическо лице от страна на административен Административнопроцесуалния кодекс, когато с индивидуален задължения за определен срок, административните и организациите, предоставящи обществени срока до лицата, за които се отнася актът, в случай е предвидено уведомяването чрез телефон, нито различни от изтичане на определен срок. управление (ЗЕУ) връчването на електронните административни услуги може да се извършва чрез съдържащо информация за изтегляне на съставения 2 документ от информационна система за сигурно електронно връчване, поддържана от Министерство на електронното управление (ССЕВ), или от портала на електронното управление по чл. 12, ал. 1 от ЗЕУ. Документите се смятат за връчени с изтеглянето им. Като препоръчителен стандарт за качество на административното обслужване е дефиниран Стандарт за проактивно информиране на потребителя за резултата от заявената услуга – администрацията по своя инициатива уведомява потребителите по електронна поща, по телефон или по друг начин за статуса на разглежданото заявление/искане, включително за издаден акт, съответно за готов резултат от услугата, в т.ч. и при предсрочно издаване/предоставяне (т. 15 от Приложение № 8 към чл. 20, ал. 3, буква „б“ от НАО). В действащото законодателство обаче липсват конкретни разпоредби, които да уредят процеса по уведомяване на гражданина в тези случаи. Видно от цитираната фрагментирана уредба, към настоящия момент не е нормативно уредена и реализирана възможността за проактивно уведомяване на гражданите относно определени факти и обстоятелства, които засягат техни права и законни интереси, в т.ч. за получаване на резултат от изпълнение на електронни административни услуги, както и на други документи или актове, при които връчване или съобщаване се изисква от закон. В този смисъл, държавните институции не се възползват адекватно от наличните технологични условия, практики и дигитални умения на гражданите, свързани с използването на смартфони за достъп до интернет и на електронна поща. 1.2. Посочете възможно ли е проблемът да се реши в рамките на съществуващото законодателство чрез промяна в организацията на работа и/или чрез въвеждане на нови технологични възможности (например съвместни инспекции между няколко органа и др.). Проблемът не може да бъде решен в рамките на съществуващата нормативна уредба чрез промяна в организацията на работа и/или чрез въвеждане на нови технологични възможности. За преодоляване на констатирания проблем е необходимо да се извършат нормативни промени, с които да бъдат уредени ред и процедура за получаване от гражданите на резултат от изпълнение на заявени от тях електронни административни услуги. 1.3. Посочете защо действащата нормативна рамка не позволява решаване на проблема/проблемите. Действащата нормативна уредба не урежда ред за проактивно информиране на потребителя за резултата от заявената от него електронна административна услуга. 1.4. Посочете задължителните действия, произтичащи от нормативни актове от по-висока степен или актове от правото на ЕС. По констатирания проблем няма задължителни действия, които да произтичат от нормативни актове от по-висока степен или актове от правото на ЕС. 1.5. Посочете дали са извършени последващи оценки на нормативния акт или анализи за изпълнението на политиката и какви са резултатите от тях? Не са извършени последващи оценки на нормативния акт, както и анализи за изпълнението на политиката. Проблем 2 „Слабости при електронната идентификация на лицата“ 1.1. Кратко опишете проблема/проблемите и причините за неговото/тяхното възникване. По възможност посочете числови стойности. Налице са системни слабости при използването на електронни административни услуги по ЗЕУ, свързани с електронната идентификация на гражданите. Към настоящия момент физическите и юридически лица имат възможност да се идентифицират при заявяване на електронни административни услуги чрез средствата за електронна идентификация, регламентирани в чл. 5, ал. 2 от ЗЕУ и в § 5 от Преходните и заключителни разпоредби на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги (ПЗР на НОИИСРЕАУ). Едно от средствата за електронна идентификация, предвидено в чл. 5, ал. 2 от ЗЕУ, е електронният идентификатор, издаван от министъра на вътрешните работи по Закона за електронната идентификация (ЗЕИ) и който следва да се съдържа в документите за самоличност на гражданите. 3 Поради факта, че понастоящем все още не се издават лични карти/международни паспорти, които да съдържат удостоверения за електронна идентичност, част от Националната схема за електронна идентификация по ЗЕИ, административните органи предоставят достъп до електронните си административни услуги, включително през портала на електронното управление, поддържан от Министерството на електронното управление, чрез квалифициран електронен подпис (КЕП), Персонален идентификационен код (ПИК) на Националната агенция за приходите (НАП), ПИК на Националния осигурителен институт (НОИ), на основание § 5 от ПЗР на НОИИСРЕАУ. Значителна част от електронните административни услуги се заявяват чрез средства за електронна идентификация с ниво на осигуреност „високо“, на което отговаря именно КЕП. От друга страна обаче, макар притежаването на КЕП да е свързано с минимални разходи за неговото придобиване и поддържане, той се явява технически усложнено решение за голяма част от гражданите и юридическите лица, което стеснява кръга на лицата, които притежават такъв подпис. ПИК се издават безплатно на гражданите, но са с ниско ниво на осигуреност и чрез тях могат да се заявяват само определени административни услуги. Поради това е необходимо да бъде нормативно уреден улеснен способ за електронна идентификация на физически лица при връчване на електронни документи – резултат от изпълнение на електронни административни услуги, както и на други документи или актове, при които връчване или съобщаване се изисква от закон. 1.2. Посочете възможно ли е проблемът да се реши в рамките на съществуващото законодателство чрез промяна в организацията на работа и/или чрез въвеждане на нови технологични възможности (например съвместни инспекции между няколко органа и др.). Проблемът не може да бъде решен в рамките на съществуващата нормативна уредба чрез промяна в организацията на работа и/или чрез въвеждане на нови технологични възможности. За преодоляване на констатирания проблем е необходимо да се извършат нормативни промени, с които да бъде уреден конкретен способ за електронна идентификация на лицата. 1.3. Посочете защо действащата нормативна рамка не позволява решаване на проблема/проблемите. Действащата нормативна уредба на чл. 5, ал. 2, т. 4 от ЗЕУ урежда възможност за електронна идентификация на гражданите със средства за електронна идентификация, определени с НОИИСРЕАУ, като за целта са необходими съответните нормативни промени в наредбата. 1.4. Посочете задължителните действия, произтичащи от нормативни актове от по-висока степен или актове от правото на ЕС. По констатирания проблем няма задължителни действия, които да произтичат от нормативни актове от по-висока степен или актове от правото на ЕС. 1.5. Посочете дали са извършени последващи оценки на нормативния акт или анализи за изпълнението на политиката и какви са резултатите от тях? Не са извършени последващи оценки на нормативния акт, както и анализи за изпълнението на политиката. Проблем 3 „Констатирана необходимост от прецизиране на нормативната уредба, регламентираща процесите по планиране, вписване, утвърждаване и контрол на дейностите, проектните предложения и техническите спецификации в областта на електронното управление“ 1.1. Кратко опишете проблема/проблемите и причините за неговото/тяхното възникване. По възможност посочете числови стойности. Съгласно чл. 38, ал. 4 от НОИИСРЕАУ при изготвяне на технически спецификации за провеждане на обществени поръчки, чийто обхват включва само дейности по адаптиране на информационни системи, регистри или бази данни във връзка с въвеждане на еврото в Република България, възложителите могат да изготвят техническите си спецификации на базата на образец съгласно Приложение № 2 към наредбата. Разпоредбата е въведена като временна мярка, свързана с подготовката и техническата адаптация на информационните системи за въвеждане на еврото в Република България. С приключването на основните етапи на този процес и интегрирането на съответните изисквания в общите технически и административни правила, необходимостта от 4 поддържане на отделен специфичен образец отпада. Поради това разпоредбата е загубила своето самостоятелно практическо значение и поддържането ѝ би създало излишна нормативна тежест и предпоставки за различно тълкуване. 1.2. Посочете възможно ли е проблемът да се реши в рамките на съществуващото законодателство чрез промяна в организацията на работа и/или чрез въвеждане на нови технологични възможности (например съвместни инспекции между няколко органа и др.). Проблемът не може да бъде решен в рамките на съществуващата нормативна уредба чрез промяна в организацията на работа и/или чрез въвеждане на нови технологични възможности. За преодоляване на констатирания проблем е необходимо да бъдат извършени съответните нормативни промени в НОИИСРЕАУ. 1.3. Посочете защо действащата нормативна рамка не позволява решаване на проблема/проблемите. Отпаднала е необходимостта от съществуването на уредените в действащата нормативна уредба правила за изготвяне на конкретни технически спецификации. 1.4. Посочете задължителните действия, произтичащи от нормативни актове от по-висока степен или актове от правото на ЕС. По констатирания проблем няма задължителни действия, които да произтичат от нормативни актове от по-висока степен или актове от правото на ЕС. 1.5. Посочете дали са извършени последващи оценки на нормативния акт или анализи за изпълнението на политиката и какви са резултатите от тях? Не са извършени последващи оценки на нормативния акт, както и анализи за изпълнението на политиката. 2. Цели: По отношение на Проблем 1 Цел 1 Оптимизиране и подобряване на процесите по връчване на готов резултат от заявена електронна административна услуга. Цел 2 Намаляване на административната тежест за гражданите, заявители на електронни административни услуги, и подобряване на административното обслужване. По отношение на Проблем 2 Цел 3 Разширяване на възможностите и средствата за електронна идентификация на гражданите и улесняване предоставянето на електронни административни услуги. По отношение на Проблем 3 Цел 4 Постигане на по-висока прозрачност, предвидимост и ефективност при управлението на информационните ресурси в публичния сектор. 3. Заинтересовани страни: 1. Министерството на електронното управление; 2. Органи на изпълнителната власт, които предоставят електронни административни услуги: 2.1. Централни органи на изпълнителната власт по чл. 19, ал. 2 от Закона за администрацията (ЗА) – броят им се определя при назначаване на правителство; 2.2. Териториални органи на изпълнителната власт по чл. 19, ал. 3 от ЗА – 28 областни управители; 265 кметове на общини; 35 кметове на райони; 3050 кметове на кметства; 967 кметски наместници; 5 2.3. Органи на изпълнителната власт по чл. 19, ал. 4 от ЗА – 9 председатели на държавни агенции; 5 държавни комисии; 32 изпълнителни директори на изпълнителни агенции; 72 ръководители на държавни институции, създадени със закон или постановление на МС, които имат функции във връзка с осъществяването на изпълнителната власт; 3. Граждани, заявители на електронни административни услуги (броят им се променя в зависимост от динамиката на обществените отношения). Посочете всички потенциални заинтересовани страни/групи заинтересовани страни (в рамките на процеса по извършване на частичната предварителна частична оценка на въздействието и/или при обществените консултации по чл. 26 от Закона за нормативните актове), върху които предложенията ще окажат пряко или косвено въздействие (бизнес в дадена област/всички предприемачи, неправителствени организации, граждани/техни представители, държавни органи/общини и др.). 4. Варианти на действие. Анализ на въздействията: 4.1. По проблем 1: „Недостатъчно използване на съвременните технологии в процеса на осъществяване на контакт с гражданите при предоставянето на електронни административни услуги“ Вариант 1 „Без действие“: Описание: При варианта „Без действие“ не се предприемат никакви действия, което означава, че съществуващото положение ще продължи без промяна, съответно ще бъде усложнен и забавен процесът по получаване от гражданите на резултат от изпълнение на заявени от тях електронни административни услуги. Вариантът, при който не се предприемат действия, е лишен от аргументи и ползи, поради което не се препоръчва изборът и прилагането му. Положителни (икономически/социални/екологични) въздействия: Не са идентифицирани положителни въздействия. (върху всяка заинтересована страна/група заинтересовани страни) Отрицателни (икономически/социални/екологични) въздействия: В случай че не бъде приет проектът на Постановление на Министерския съвет за изменение и допълнение на НОИИСРЕАУ, администрациите ще продължат да използват съществуващите правила за връчване на резултат от изпълнение на заявени електронни административни услуги. Това ще препятства възможността за улесняване и разширяване използването на електронни административни услуги от страна на гражданите. Няма да бъдат нормативно уредени процедурите за реализиране на практика на Стандарта за проактивно информиране на потребителите за резултата от заявената услуга. Държавните институции ще продължат да използват морално остарели методи и няма да се възползват адекватно от наличните технологични условия, практики и дигитални умения на гражданите, свързани с използването на смартфони за достъп до интернет и на електронна поща. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Не са идентифицирани. Въздействия върху малките и средните предприятия: Не са идентифицирани. Административна тежест: Не е идентифицирана. 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 6 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) Вариант 2 „Приемане на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги“: Описание: Прилагането на Вариант 2 е свързано с приемането на съответните промени в НОИИСРЕАУ, чрез които да бъдат регламентирани правила и ред за получаване от гражданите на резултат от изпълнение на електронни административни услуги, както и на други документи или актове, при които връчване или съобщаване се изисква от закон, чрез еднократен код за достъп до ССЕВ. Положителни (икономически/социални/екологични) въздействия: При този вариант на действие ще бъде уредена допълнителна възможност за получаване на готовите резултати от заявените от гражданите електронни административни услуги, чрез използване на широко достъпните технологични възможности. По този начин процесът ще бъде улеснен, което ще доведе и до намаляване на административната тежест за гражданите. Ще бъде нормативно регламентирана възможността за проактивна комуникация с гражданите, което ще повиши използването на електронните административни услуги. Ще бъде осигурена техническа възможност данните за електронна поща и телефонен номер, които гражданите предоставят в заявлението за предоставяне на съответната електронна административна услуга, да се използват за получаване на готовия резултат от нея. (върху всяка заинтересована страна/група заинтересовани страни) Отрицателни (икономически/социални/екологични) въздействия: Не се очакват. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Не са идентифицирани. Въздействия върху малките и средните предприятия Не са идентифицирани. Административна тежест: Ще се намали административната тежест върху гражданите. Не се въвеждат такси, нови регулаторни режими или нови административни услуги. (въздействията върху малките и средните предприятия; административна тежест) 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) 4.2. По проблем 2: „Слабости при електронната идентификация на лицата“ Вариант 1 „Без действие“: Описание: При варианта „Без действие“ не се предприемат никакви действия, което означава, че ще се запазят регламентираните в действащото законодателство средства за електронна идентификация на гражданите и организациите. Вариантът, при който не се предприемат действия, е лишен от аргументи и ползи, поради което не се препоръчва изборът и прилагането му. 7 Положителни (икономически/социални/екологични) въздействия: Не са идентифицирани положителни въздействия. (върху всяка заинтересована страна/група заинтересовани страни) Отрицателни (икономически/социални/екологични) въздействия: В случай че не бъде приет проектът на Постановление на Министерския съвет за изменение и допълнение на НОИИСРЕАУ, ще се запазят съществуващите слабости при използването на електронни административни услуги по ЗЕУ, свързани с електронната идентификация на гражданите. Една част от тях са свързани с усложнени технически решения, които изискват разходи за придобиване и поддържане на КЕП. Друга част пък, поради ниското си ниво на осигуреност, предоставят възможност за заявяване само на определен кръг електронни административни услуги. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Не са идентифицирани. Въздействия върху малките и средните предприятия: Не са идентифицирани. Административна тежест: Не е идентифицирана. 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) Вариант 2 „Приемане на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги“: Описание: Прилагането на Вариант 2 е свързано с приемането на съответните промени в НОИИСРЕАУ, чрез които да бъде регламентирано още едно допълнително средство за електронна идентификация на лицата при връчване на електронни документи – резултат от изпълнение на електронни административни услуги, както и на други документи или актове, при които връчване или съобщаване се изисква от закон. В тези случаи като средство за електронна идентификация ще може да се използва еднократен код за достъп до ССЕВ в комбинация с определен набор от идентификатори, посочени от самото лице. Положителни (икономически/социални/екологични) въздействия: При този вариант на действие ще бъде нормативно уреден улеснен способ за електронна идентификация на физически лица при връчване на електронни документи – резултат от изпълнение на електронни административни услуги, както и на други документи или актове, при които връчване или съобщаване се изисква от закон. При прилагане на предложения подход на действие ще се преодолее и проблемът, свързан с идентификацията на заявителите при предоставяне на електронни административни услуги, като се повиши сигурността при тяхното използване. Ще се използват възможностите, които дава действащото законодателство, за уреждане и на допълнителни средства за електронна идентификация. Въведеният нов способ ще е не само сигурен и надежден, но и ще бъде реализиран чрез технологично решение, базирано на реалната използваемост на „устройството в джоба ми“. (върху всяка заинтересована страна/група заинтересовани страни) 8 Отрицателни (икономически/социални/екологични) въздействия: Не се очакват. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Не са идентифицирани. Въздействия върху малките и средните предприятия Не са идентифицирани. Административна тежест: Ще се намали административната тежест върху гражданите. Не се въвеждат такси, нови регулаторни режими или нови административни услуги. (въздействията върху малките и средните предприятия; административна тежест) 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) 4.3. По проблем 3: „Констатирана необходимост от прецизиране на нормативната уредба, регламентираща процесите по планиране, вписване, утвърждаване и контрол на дейностите, проектните предложения и техническите спецификации в областта на електронното управление“ Вариант 1 „Без действие“: Описание: При варианта „Без действие“ не се предприемат никакви действия, което означава, че ще се запазят регламентираните в действащото законодателство изискванията към изготвяне на техническите спецификации за провеждане на обществени поръчки, чиито обхват включва само дейности по адаптиране на информационни системи, регистри или бази данни във връзка с въвеждане на еврото в Република България. Вариантът, при който не се предприемат действия, е лишен от аргументи и ползи, поради което не се препоръчва изборът и прилагането му. Положителни (икономически/социални/екологични) въздействия: Не са идентифицирани положителни въздействия. (върху всяка заинтересована страна/група заинтересовани страни) Отрицателни (икономически/социални/екологични) въздействия: В случай че не бъде приет проектът на Постановление на Министерския съвет за изменение и допълнение на НОИИСРЕАУ, ще се запазят съществуващите изисквания и образци, необходимостта от които е отпаднала. Ще е налице липса на практическо значение от съществуването на конкретни правила, което ще създаде излишна нормативна тежест и предпоставки за различно тълкуване. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Не са идентифицирани. Въздействия върху малките и средните предприятия: Не са идентифицирани. Административна тежест: 9 Не е идентифицирана. 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) Вариант 2 „Приемане на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги“: Описание: Прилагането на Вариант 2 е свързано с приемането на съответните промени в НОИИСРЕАУ, чрез които ще отпаднат съществуващи изисквания при изготвянето на техническите спецификации за провеждане на обществени поръчки, чиито обхват включва само дейности по адаптиране на информационни системи, регистри или бази данни във връзка с въвеждане на еврото в Република България. Ще бъдат актуализирани образците на документи. Положителни (икономически/социални/екологични) въздействия: При този вариант на действие ще бъдат направени съответните нормативни изменения, чрез които ще се осигури ясна, непротиворечива и последователна нормативна рамка, съобразена с принципите на ефективно и прозрачно управление на информационните ресурси в публичния сектор. Ще бъдат премахнати вече ненужни временни разпоредби, което ще повиши качеството на подготвяната от администрациите информация и ще осигури яснота по отношение на сроковете за вписване на данни и укрепване на контролните механизми при предварителен и последващ контрол. По този начин ще се гарантира яснота относно целите, обхвата и необходимостта от предвидените дейности. С приемането на измененията ще се постигне: • подобряване на качеството на планирането и вписването на дейности; • ясна и непротиворечива нормативна рамка; • повишена прозрачност и отчетност при разходване на публични средства; • по-ефективен контрол и намаляване на административните несъответствия; • укрепване на процесите по управление на информационните ресурси в публичния сектор. (върху всяка заинтересована страна/група заинтересовани страни) Отрицателни (икономически/социални/екологични) въздействия: Не се очакват. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Не са идентифицирани. Въздействия върху малките и средните предприятия Не са идентифицирани. Административна тежест: Не е идентифицирана. (въздействията върху малките и средните предприятия; административна тежест) 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) 5. Сравняване на вариантите: 10 Степени на изпълнение по критерии: 1) висока; 2) средна; 3) ниска. Вариант „Без действие“ Вариант 2 Цел 1: „Оптимизиране и подобряване на процесите по връчване на готов резултат от заявена електронна административна услуга“ 3 1 т с о н в Цел 2: „Намаляване на административната тежест за гражданите, заявители на електронни административни услуги, и подобряване на административното обслужване“ 3 1 и т к е ф Е Цел 3: „Разширяване на възможностите и средствата за електронна идентификация на гражданите и улесняване предоставянето на електронни административни услуги“ 3 1 Цел 4: „Постигане на по-висока прозрачност, предвидимост и ефективност при управлението на информационните ресурси в публичния сектор“ 3 1 Цел 1: „Оптимизиране и подобряване на процесите по връчване на готов резултат от заявена електронна административна услуга“ 3 1 т с о н Цел 2: „Намаляване на административната тежест за гражданите, заявители на електронни административни услуги, и подобряване на административното обслужване“ 3 1 с а к и ф Е Цел 3: „Разширяване на възможностите и средствата за електронна идентификация на гражданите и улесняване предоставянето на електронни административни услуги“ 3 1 Цел 4: „Постигане на по-висока прозрачност, предвидимост и ефективност при управлението на информационните ресурси в публичния сектор“ 3 1 Цел 1: „Оптимизиране и подобряване на процесите по връчване на готов резултат от заявена електронна административна услуга“ 3 1 т с о н а Цел 2: „Намаляване на административната тежест за гражданите, заявители на електронни административни услуги, и подобряване на административното обслужване“ 3 1 в у с а л г ъ С Цел 3: „Разширяване на възможностите и средствата за електронна идентификация на гражданите и улесняване предоставянето на електронни административни услуги“ 3 1 Цел 4: „Постигане на по-висока прозрачност, предвидимост и ефективност при управлението на информационните ресурси в публичния сектор“ 3 1 1.2. Посочете ефикасност, 1.1. Сравнете вариантите чрез сравняване на ключовите им степента, в която вариантите ще изпълнят определените цели, ефективност, чрез която се измерва степента, до която която отразява степента, до която целите могат да бъдат разходи; съгласуваност, която показва степента, до която вариантите положителни и отрицателни съгласно основните критерии за вариантите постигат целите на постигнати при определено ниво на съответстват на действащите въздействия. сравняване на вариантите: предложението; ресурсите или при най-малко стратегически документи. 11 6. Избор на препоръчителен вариант: По проблем 1: Препоръчва се за решаване на поставения проблем да бъде избран Вариант 2 „Приемане на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги“. По проблем 2: Препоръчва се за решаване на поставения проблем да бъде избран Вариант 2 „Приемане на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги“. По проблем 3: Препоръчва се за решаване на поставения проблем да бъде избран Вариант 2 „Приемане на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги“. Аргументите за това са свързани със следното: 1. Вариант 2 се отличава с най-висока степен на ефективност, във връзка с неговата целесъобразност и с най-висок потенциал за постигане на целите. 2. Вариант 2 се характеризира с най-висока степен на ефикасност сред идентифицираните варианти на действие с оглед на ефекта за заинтересованите страни и за обществото. 3. Вариант 2 се отличава с най-висока степен на съгласуваност. Посочете препоръчителните варианти за решаване на поставения проблем/проблеми. 6.1. Промяна в административната тежест за физическите и юридическите лица от прилагането на препоръчителния вариант (включително по отделните проблеми): При възприемане на предложения вариант на действие по Проблем 1 и Проблем 2 се очаква намаляване на административната тежест за гражданите. 1.1. Изборът следва да е съотносим с посочените специфични въздействия на препоръчителния вариант за решаване на всеки проблем. 1.2. Ако се предвижда въвеждането на такса, представете образуването на нейния размер съгласно Методиката по чл. 7а от Закона за ограничаване на административното регулиране и административния контрол върху стопанската дейност. 6.2. Създават ли се нови/засягат ли се съществуващи регулаторни режими и услуги от прилагането на препоръчителния вариант (включително по отделните проблеми)? Не се създават нови регулаторни режими, не се засягат съществуващи режими и услуги. 1.1. Изборът следва да е съотносим с посочените специфични въздействия на избрания вариант. 1.2. В случай че се предвижда създаване нов регулаторен режим, посочете неговия вид (за стопанска дейност: лицензионен, регистрационен; за отделна стелка или действие: разрешителен, уведомителен; удостоверителен и по какъв начин това съответства с постигането на целите). 1.3. Мотивирайте създаването на новия регулаторен режим съгласно изискванията на чл. 3, ал. 4 от Закона за ограничаване на административното регулиране и административния контрол върху стопанската дейност. 1.4. Посочете предложените нови регулаторни режими отговарят ли на изискванията на чл. 10 – 12 от Закона за дейностите по предоставяне на услуги. 12 1.5. Посочете изпълнено ли е изискването на § 2 от Допълнителните разпоредби на Закона за дейностите по предоставяне на услуги. 1.6. В случай че се изменят регулаторни режими или административни услуги, посочете промяната. 6.3. Създават ли се нови регистри от прилагането на препоръчителния вариант (включително по отделните проблеми)? Когато отговорът е „Да“, посочете регистрите, които се създават и по какъв начин те ще бъдат интегрирани в общата регистрова инфраструктура. 6.4. По какъв начин препоръчителният вариант въздейства върху микро-, малките и средните предприятия (МСП) (включително по отделните проблеми)? Изборът следва да е съотносим с посочените специфични въздействия на препоръчителния вариант. 6.5. Потенциални рискове от прилагането на препоръчителния вариант (включително по отделните проблеми): Не са идентифицирани потенциални рискове от изпълнението на избрания вариант на действие, включително и за възникване на съдебни спорове. Посочете възможните рискове от прилагането на препоръчителния вариант, различни от отрицателните въздействия, напр. възникване на съдебни спорове и др. 7. Консултации: Посочете основните заинтересовани страни, с които са проведени консултации. Посочете резултатите от консултациите, включително на ниво ЕС: спорни въпроси, многократно поставяни въпроси и др. На основание чл. 26, ал. 4, изр. първо от Закона за нормативните актове, проектът на нормативен акт ще бъде публикуван на Портала за обществени консултации и на официалната интернет страница на Министерството на електронното управление за срок от 30 дни. Проектът на нормативен акт ще бъде съгласуван по реда на чл. 32 от Устройствения правилник на Министерския съвет и на неговата администрация. Обобщете най-важните въпроси за обществени консултации. Посочете индикативен график за тяхното провеждане и видовете консултационни процедури. 8. Приемането на нормативния акт произтича ли от правото на Европейския съюз? …………………………………………………………………..……………………… …………………………………………………………………………………………. 1.1. Посочете изискванията на правото на Европейския съюз, включително информацията по т. 6.2 и 6.3, дали е извършена оценка на въздействието на ниво Европейски съюз, и я приложете (или посочете връзка към източник). 1.2. Изборът трябва да съответства на посоченото в раздел 1, съгласно неговата т. 1.5. 13 9. Изисква ли се извършване на цялостна предварителна оценка на въздействието поради очаквани значителни последици? (преценка съгласно чл. 20, ал. 3, т. 2 от Закона за нормативните актове) 10. Приложения: Приложете необходимата допълнителна информация и документи. 11. Информационни източници: 1. Закон за администрацията; 2. Закон за електронното управление; 3. Наредба за административното обслужване; 4. Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги. Посочете изчерпателен списък на информационните източници, които са послужили за оценка на въздействията на отделните варианти и при избора на вариант за действие: регистри, бази данни, аналитични материали и др. 12. Име, длъжност, дата и подпис на директора на дирекцията, отговорна за извършването на частичната предварителна оценка на въздействието: Име и длъжност: Вяра Панайотова – директор на дирекция „Правни дейности и обществени поръчки“ в Министерство на електронното управление Дата: 14.11.2025 г. Подпис:

* Съгласно чл. 17 от Наредбата за обхвата и методологията за извършване на оценка на въздействието, изводите и относимата информация от извършената частична предварителна оценка на въздействието се включват във финансовата обосновка по чл. 35, ал. 1, т. 4 от Устройствения правилник на Министерския съвет и на неговата администрация. ** При съгласуването по чл. 32 от Устройствения правилник на Министерския съвет и на неговата администрация кръгът от въпроси, проблеми и решения, разгледани в оценката на въздействието се съпоставя с кръга от въпроси, засегнати в проекта на нормативен акт. Становище от съгласуване на предварителна оценка на въздействието на проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги Страница 1 от 2 Становище администрацията на Съгласуването се извършва на основание на Министерския чл. 21, ал. 5 от Закона за съвет нормативните актове Проект на акт: Вид оценка: Частична Постановление на Министерския съвет за Становище по ред: Единствено съгласуване изменение и допълнение изисквания към на Наредбата за общите информационните системи, Номер и дата: 2 1 .1 1 .2 0 2 5 г . 0 4 .2 5 - 6 1 / 2 1 .1 1 .2 0 2 5 г . X регистрите електронните административни S ig n e d b y : V io le t a P e t r o v a Y o r d a n o v a и услуги В отговор на №: МЕУ-17073/14.11.2025 г. Институция: Министерство на електронното управление Диспозитив: Съгласува с препоръки Основание: Чл. 30б, ал.3, т. 2, б. „а“ от Устройствения Министерския съвет администрация правилник на и на неговата I. По Проверка в на 2025 г. установи, изменение и регистрите и законодателството включени в законодателната инициатива: оперативните програми на че предложеният проект допълнение на Наредбата за общите електронните административни изисква подзаконовите оперативната програма на Министерския Министерския съвет за на Постановление изисквания към услуги не е включен в нормативни актове на съвет за съответния първото и второто полугодие на Министерския съвет за информационните системи, тях. Доброто планиране на Министерския съвет да бъдат период. *** На основание чл. 30б, ал. 4 от Устройствения правилник на Министерския съвет и на неговата администрация е необходимо окончателната оценка на въздействието да бъде съобразена с препоръките от становището. **** На основание чл. 85, ал. 1 от Устройствения правилник на Министерския съвет и на неговата администрация е необходимо това становище да бъде публикувано заедно с преработената оценка на въздействието и проекта на акт при обществените консултации, провеждани в изпълнение на Закона за нормативните актове. Становище от съгласуване на предварителна оценка на въздействието на проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги Страница 2 от 2 ДИРЕКТОР НА ДИРЕКЦИЯ „КООРДИНАЦИЯ И МОДЕРНИЗАЦИЯ НА АДМИНИСТРАЦИЯТА“ В АДМИНИСТРАЦИЯТА НА МИНИСТЕРСКИЯ СЪВЕТ 21.11.2025 г . X Sig n ed b y: Iskre n Pa vlo v Iva n o v ИСКРЕН ИВАНОВ