В соответствии с подпунктом 17) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года "Об информатизации" ПРИКАЗЫВАЮ:
1. Утвердить прилагаемые Правила разработки, сопровождения реализации и развития архитектуры государственных органов.
2. Департаменту информатизации Министерства информации и коммуникаций Республики Казахстан обеспечить:
1) государственную регистрацию настоящего приказа в Министерстве юстиции Республики Казахстан;
2) направление копии настоящего приказа в печатном и электронном виде на официальное опубликование в периодические печатные издания и информационно-правовую систему "Әділет" в течение десяти календарных дней после его государственной регистрации в Министерстве юстиции Республики Казахстан;
3) направление копии настоящего приказа в печатном и электронном виде в Республиканский центр правовой информации в течении десяти календарных дней со дня его государственной регистрации в Министерстве юстиции Республики Казахстан для включения в эталонный контрольный банк нормативных правовых актов Республики Казахстан;
4) размещение настоящего приказа на интернет-ресурсе Министерства информации и коммуникаций Республики Казахстан;
5) в течение десяти рабочих дней после государственной регистрации настоящего приказа в Министерстве юстиции Республики Казахстан представление в Юридический департамент Министерства информации и коммуникаций Республики Казахстан сведений об исполнении мероприятий, предусмотренных подпунктами 1), 2) и 3) пункта 2 настоящего приказа.
3. Контроль за исполнением настоящего приказа возложить на вице-министра информации и коммуникаций Республики Казахстан.
4. Настоящий приказ вводится в действие со дня его первого официального опубликования.
Министр | |
информации и коммуникаций | |
Республики Казахстан | Д. Абаев |
"СОГЛАСОВАН"
Министр национальной экономике
Республики Казахстан
_________К. Бишимбаев
10 ноября 2016 года
| Утверждены приказом Министра информации и коммуникаций Республики Казахстан от 19 сентября 2016 года № 159 |
Правила
разработки, сопровождения реализации и развития архитектуры
государственных органов
Глава 1. Общие положения
1. Настоящие Правила разработки, сопровождения реализации и развития архитектуры государственных органов (далее – Правила) разработаны в соответствии с подпунктом 17) статьи 7 Закона Республики Казахстан от 24 ноября 2015 года "Об информатизации" (далее – Закон) и определяют порядок разработки, сопровождения реализации и развития архитектуры государственных органов.
2. Правила не распространяются на электронные информационные ресурсы, информационные системы и информационно-коммуникационную инфраструктуру, содержащие, обрабатывающие и (или) передающие сведения, отнесенные к государственным секретам в соответствии с Законом Республики Казахстан от 15 марта 1999 года "О государственных секретах".
3. В настоящих Правилах используются следующие основные понятия:
1) архитектура информационных систем – слой архитектуры государственного органа, представляющий собой описание информационных систем государственных органов, автоматизирующих государственные функции и оказывающих вытекающие из них государственные услуги, прикладных программных продуктов, процессов их взаимодействия и отношений к функциональным возможностям государственного органа;
2) модель интеграции информационных систем – представление совокупности точек взаимодействия, форматов и способов взаимодействия информационных систем, предназначенное для стандартизации информационного взаимодействия и исключения дублирования данных;
3) модель информационных систем – представление информационных систем, сгруппированных в комплексы и распределенных по направлениям деятельности государственного органа, предназначенное для описания совокупности информационных систем и выявления пересечений между ними;
4) архитектура информационно-коммуникационной инфраструктуры (далее – архитектура ИК-инфраструктуры) – слой архитектуры государственного органа, представляющий собой описание программных продуктов, аппаратно-программных комплексов, сети телекоммуникаций, средств информационной безопасности и инженерной инфраструктуры;
5) модель информационно-коммуникационной инфраструктуры – представление компонентов информационно-коммуникационной инфраструктуры, сгруппированных по физическим серверным площадкам и связанных между собой топологией сетей связи;
6) межведомственный проект в отрасли информационно-коммуникационных технологий (далее – отраслевой ИКТ-проект) – проект в отрасли информационно-коммуникационных технологий, осуществляемый несколькими государственными органами;
7) внутриведомственный проект в отрасли информационно-коммуникационных технологий (далее – внутриведомственный ИКТ-проект) – проект в отрасли информационно-коммуникационных технологий, осуществляемый одним государственным органом;
8) проект в отрасли информационно-коммуникационных технологий (далее – ИКТ-проект) – экономически обоснованный комплекс работ по созданию, развитию и сопровождению объектов информатизации, финансирование которого осуществляются за счет бюджетных средств, а также иных источников финансирования, не запрещенных законодательством Республики Казахстан;
9) проектная документация проекта в отрасли информационно-коммуникационных технологий (далее – проектная документация) - совокупность документов, включающая инвестиционное предложение, финансово-экономическое обоснование, концепцию проекта государственного-частного партнерства и технико-экономическое обоснование бюджетных инвестиций, содержащая описание проекта в отрасли информационно-коммуникационных технологий, раскрывающее целесообразность реализации, технико-экономические параметры проекта, а также основные технические, технологические и иные решения;
10) портфель проектов в отрасли информационно-коммуникационных технологий (далее – портфель ИКТ-проектов) – набор проектов в отрасли информационно-коммуникационных технологий, объединенных вместе с целью эффективного управления их реализацией;
11) отраслевой проект в отрасли информационно-коммуникационных технологий (далее – отраслевой ИКТ-проект) – проект в отрасли информационно-коммуникационных технологий, осуществляемый уполномоченным государственным органом определенной отрасли (сферы) с участием коммерческих предприятий и бюджетных организаций отрасли (сферы);
12) информационное обеспечение – качественная мера оценки доступности документов, данных и электронных информационных ресурсов, используемых для принятия решений;
13) уполномоченный орган в сфере информатизации (далее – уполномоченный орган) – центральный исполнительный орган, осуществляющий руководство и межотраслевую координацию в сфере информатизации и "электронного правительства";
14) информационное взаимодействие – процесс обмена сведениями и информацией между структурными подразделениями государственного органа, государственного органа с подведомственными организациями, другими государственными органами, физическими и юридическими лицами;
15) модель информационного взаимодействия – представление информационного взаимодействия государственного органа, предназначенное для приоритезации, стандартизации и оптимизации информационного взаимодействия государственного органа;
16) архитектура данных – слой архитектуры государственного органа, представляющий собой описание информационных ресурсов, содержащихся в них данных, информационного взаимодействия, а также подходов и средств управления данными;
17) модель данных – представление ключевых видов данных, их состояния и взаимосвязей, необходимых для обеспечения бесперебойного функционирования государственного органа;
18) архитектура деятельности – слой архитектуры государственного органа, представляющий собой описание стратегических приоритетов, целей, задач, организационной структуры, направлений деятельности, функциональных возможностей, функций и услуг государственного органа;
19) модель деятельности – представление совокупности структурных, операционных и финансовых механизмов, основных результатов деятельности и услуг, предназначенное для описания ключевых принципов работы государственного органа;
20) модель мотивации деятельности – представление взаимосвязи средств и способов достижения видения, миссии, целей и задач государственного органа, предназначенных для реализации необходимых изменений;
21) текущее состояние архитектуры государственного органа (далее – текущая архитектура) – набор представлений, отражающий существующий на определенный момент времени набор компонентов архитектуры государственного органа и отношений между ними, который используется для поддержки существующих потребностей государственного органа и является основой для долгосрочного планирования и проведения краткосрочных изменений;
22) масштаб архитектуры государственного органа (далее – масштаб архитектуры) – границы работ по разработке и развитию архитектуры государственного органа, характеризующиеся количеством структурных подразделений и подведомственных организаций, слоев архитектуры государственного органа, детализацией компонентов и представлений архитектуры государственного органа, а также временными рамками планируемых изменений;
23) оценка уровня готовности процессов по управлению архитектурой государственного органа – совокупность мероприятий, направленных на определение объективной оценки масштаба и эффективности реализации архитектуры государственного органа и позволяющих выявить пробелы, недостатки и перспективы совершенствования;
24) сопровождение реализации архитектуры государственного органа (далее – сопровождение реализации архитектуры) – совокупность мероприятий по оценке соответствия архитектуре государственного органа, оценке уровня готовности процессов по управлению архитектурой государственного органа и внесению изменений в утвержденную архитектуру государственного органа, направленных на эффективное управление реализацией архитектуры государственного органа;
25) слой архитектуры государственного органа (далее – слой архитектуры) – составная часть архитектуры государственного органа, характеризующая состояние государственного органа с одной перспективы, описывающей деятельность, или данные, или информационные системы, или ИК-инфраструктуру;
26) компонент архитектуры государственного органа (далее – компонент архитектуры) – элемент архитектуры государственного органа, отражающий текущее и (или) планируемое состояние одного объекта деятельности государственного органа;
27) контекст архитектуры государственного органа (далее – контекст архитектуры) – внутренняя среда и внешние условия функционирования государственного органа, в рамках которых осуществляется разработка и развитие архитектуры государственного органа;
28) целевое (планируемое) состояние архитектуры государственного органа (далее – целевая архитектура) – набор представлений, отражающий планируемый набор компонентов архитектуры государственного органа и отношений между ними, который используется для определения необходимых преобразований, направленных на улучшение результатов деятельности и достижению целей, задач, и целевых индикаторов, и показателей результатов документов Системы государственного планирования;
29) заинтересованная сторона архитектуры государственного органа и проекта в отрасли информационно-коммуникационных технологий (далее – заинтересованная сторона) - юридическое лицо (государственное юридическое лицо, казенное предприятие, государственное предприятие на праве хозяйственного ведения, субъект квазигосударственного сектора), на деятельность которого окажет влияние разработка или развитие архитектуры государственного органа, имеющее ожидания и интересы в отношении архитектуры государственного органа, либо отдельных компонентов архитектуры и проектов в отрасли информационно-коммуникационных технологий;
30) модель архитектуры государственного органа (далее – модель архитектуры) – графический формат представления компонентов архитектуры государственного органа;
31) оценка соответствия архитектуре государственного органа (далее – оценка соответствия архитектуре) – оценка соответствия структуры и содержания объектов информатизации "электронного правительства" утвержденной архитектуре государственного органа на стадиях разработки проектной, технической и конкурсной документации, реализации и ввода в эксплуатацию объектов информатизации;
32) сегмент архитектуры государственного органа (далее – сегмент архитектуры) – составная часть архитектуры государственного органа, содержащая описание всех слоев архитектуры государственного органа в рамках одного либо нескольких направлений деятельности, структурных подразделений или функциональных возможностей государственного органа;
33) представление архитектуры государственного органа (далее – представление) – описание одного либо нескольких компонентов архитектуры и отношений между ними в виде списков, таблиц и моделей, используемое для отражения определенных аспектов структуры, состояния и поведения компонентов текущей и (или) целевой архитектуры государственного органа;
34) шаблон архитектуры государственного органа (далее – шаблон архитектуры) – инструмент выбора оптимального варианта реализации компонентов архитектуры государственного органа в рамках решения типовых задач по проектированию объектов информатизации "электронного правительства";
35) ограничение архитектуры государственного органа (далее – ограничение) – внутриведомственные либо внешние лимиты, требования или условия, накладываемые на архитектуру государственного органа;
36) мониторинг реализации архитектуры государственного органа – совокупность мероприятий по регулярному и систематическому сбору и анализу информации о ходе реализации архитектур государственных органов, а также оценке степени достижения планируемых результатов утвержденной архитектуры государственного органа и отдельных проектов в отрасли информационно-коммуникационных технологий по сравнению с фактическими результатами их выполнения, учитываемые при формировании отчета сервисного интегратора о ходе работ по реализации архитектуры государственных органов;
37) ожидания заинтересованной стороны архитектуры государственного органа и проекта в отрасли информационно-коммуникационных технологий (далее – ожидания заинтересованной стороны) - общие потребности и интересы, которые относятся к вопросам оптимизации и автоматизации деятельности государственного органа или иным аспектам проведения информатизации, являющиеся приоритетными либо критически важными для одной или нескольких заинтересованных сторон;
38) функциональная модель государственного органа - представление иерархии функциональных возможностей государственного органа в разрезе направлений деятельности, предназначенное для описания компетенций государственного органа;
39) функциональная возможность государственного органа (далее – функциональная возможность) – уникальный сгруппированный набор организационных единиц, нормативно-правового обеспечения, людских ресурсов, объектов информатизации, государственных функций и вытекающих из них услуг, предназначенный для описания наличия способности выполнения определенных видов деятельности у государственного органа;
40) оценка состояния функциональных возможностей – совокупность мероприятий, направленных на получение оценки способности государственного органа к улучшению результатов деятельности, а также достижению целей, задач, целевых индикаторов и показателей результатов документов Системы государственного планирования;
41) сервисный интегратор "электронного правительства" (далее – сервисный интегратор) – юридическое лицо, определяемое Правительством Республики Казахстан, на которое возложены функции по методологическому обеспечению развития архитектуры "электронного правительства" и типовой архитектуры "электронного акимата", а также иные функции, предусмотренные Законом.
Иные понятия и термины, используемые в настоящих Правилах, применяются в соответствии с законодательством Республики Казахстан.
4. Архитектура государственного органа (далее – архитектура) предназначена для решения следующих задач:
1) формирование долгосрочного плана информатизации государственного органа;
2) определение приоритетных направлений расходов на информатизацию государственного органа;
3) оптимизация расходов на информатизацию государственного органа;
4) исключение дублирования объектов информатизации и создание возможностей для совместного использования объектов информатизации в государственном органе или несколькими государственными органами;
5) определение оптимального уровня и формата автоматизации государственных функций государственного органа и оказания вытекающих из них государственных услуг;
6) обеспечение оптимального выбора и эффективного внедрения информационно-коммуникационных технологий в государственном органе.
5. Архитектура состоит из следующих слоев архитектуры:
1) архитектура деятельности;
2) архитектура данных;
3) архитектура информационных систем;
4) архитектура ИК-инфраструктуры.
6. Слои архитектуры включают описание текущей архитектуры и целевой архитектуры.
7 Целевая архитектура отражает пятилетний план информатизации деятельности государственного органа.
8. Формирование архитектуры осуществляется в следующем порядке:
1) инициация разработки или развития архитектуры;
2) разработка архитектуры;
3) реализация архитектуры;
4) развитие архитектуры.
9. Сервисный интегратор размещает сведения о компонентах архитектуры на архитектурном портале "электронного правительства" (далее – архитектурный портал).
10. Типовая архитектура "электронного акимата" состоит из:
1) типового набора целевых индикаторов информатизации местных исполнительных органов;
2) типового набора нефункциональных требований к информационно-коммуникационной инфраструктуре (далее – ИК-инфраструктура) и типовой состав компонентов ИК-инфраструктуры;
3) типового набора, включающего в себя:
функциональные возможности местных исполнительных органов и описание оптимальных, стандартных способов их автоматизации;
информационные ресурсы и описание подходов к их ведению, управлению и обмену сведениями между центральным исполнительными органами, государственными органами, непосредственно подчиненными и подотчетными Президенту Республики Казахстан, и местными исполнительными органами;
описание областей автоматизации и функциональных требований к программным продуктам, направленным на автоматизацию функциональных возможностей местных исполнительных органов.
11. Развитие типовой архитектуры "электронного акимата" как компонента архитектуры "электронного правительства" осуществляется сервисным интегратором в следующем порядке:
1) утверждение методических рекомендаций по проведению обследования местных исполнительных органов и разработке типовой архитектуры "электронного акимата" в рамках осуществления методологического обеспечения развития архитектуры "электронного правительства", предусмотренного подпунктом 3) статьи 12 Закона;
2) проведение обследования местных исполнительных органов административно-территориальных единиц для последующего развития типовой архитектуры "электронного акимата";
3) формирование проекта типовой архитектуры "электронного акимата".
12. Внесение предложений уполномоченному органу по изменению типовой архитектуры "электронного акимата" осуществляется сервисным интегратором на основании мотивированного запроса государственного органа.
13. Архитектура местного исполнительного органа области, города республиканского значения, столицы включает в себя местный исполнительный орган района, города областного значения, района в городе, а также аппарат акима города районного значения, поселка, села, сельского округа и разрабатывается на основе типовой архитектуры "электронного акимата" с учетом направлений деятельности местного исполнительного органа и особенностей социально-экономического развития административно-территориальной единицы.
Глава 2. Порядок разработки архитектуры
Параграф 1. Инициация разработки архитектуры
14. Архитектура разрабатывается в соответствии с настоящими Правилами и методологическим обеспечением сервисного интегратора.
В случае отсутствия утвержденной архитектуры государственный орган инициирует разработку архитектуры.
15. Инициация разработки архитектуры включает следующие этапы:
1) анализ потребности и подготовка заявки в произвольной форме на инициацию разработки (далее – заявка на разработку);
2) рассмотрение заявки на разработку.
16. Инициация разработки архитектуры осуществляется с 1 января по 1 февраля в первом полугодии или с 1 июня по 1 июля во втором полугодии календарного года.
17. Предпосылками разработки архитектуры являются:
1) образование или реорганизация государственных органов Республики Казахстан;
2) необходимость разработки стратегии развития информационно-коммуникационных технологий, концепции и (или) долгосрочных планов информатизации государственного органа;
3) перевод ИК-инфраструктуры государственного органа на ИК-платформу "электронного правительства" в соответствии с правилами реализации сервисной модели информатизации, утвержденными приказом исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 28 января 2016 года № 129 (зарегистрированный в Реестре государственной регистрации нормативных правовых актов за № 13282) (далее – правила реализации сервисной модели информатизации);
4) необходимость создания или развития информационных систем и (или) ИК-инфраструктуры государственного органа;
5) низкая сумма значений критериев оценки эффективности деятельности государственных органов по применению информационно-коммуникационных технологий по результату оценки эффективности государственных органов по применению информационно-коммуникационных технологий в течение трех и более лет.
18. Государственный орган в рамках анализа потребности в разработке архитектуры:
1) устанавливает наличие оснований и срочности разработки архитектуры;
2) определяет существующие и возможные негативные последствия для государственного органа в случае отсутствия утвержденной архитектуры в указанный период.
19. Основанием для разработки архитектуры являются:
1) наличие финансирования;
2) согласованная уполномоченным органом заявка на разработку.
20. Срочность разработки архитектуры обусловлена безотлагательностью и сроками реализации:
1) мероприятий и инициатив, закрепленных в документах Системы государственного планирования;
2) норм и требований законодательства Республики Казахстан.
21. Государственный орган по результатам анализа потребности формирует и направляет уполномоченному органу на согласование заявку на разработку в произвольной форме.
22. Государственный орган в заявке на разработку:
1) указывает предпосылки для разработки архитектуры и приводит обоснование сроков проведения работ;
2) описывает функциональный и технологический масштаб архитектуры.
23. Сервисный интегратор осуществляет разъяснение возникающих вопросов и консультирование государственных органов при подготовке заявок на разработку.
24. Уполномоченный орган рассматривает заявку на разработку пятнадцать календарных дней с даты ее поступления.
25. Уполномоченный орган оценивает обоснованность, необходимость и определяет приоритетность разработки архитектуры.
26. При наличии основания и срочности разработки архитектуры:
1) уполномоченный орган в зависимости от срочности и приоритетности работ определяет сроки разработки;
2) уполномоченный орган направляет обоснованный ответ в государственный орган, подавший заявку с указанием сроков разработки архитектуры.
27. Основанием для отказа в разработке архитектуры является отсутствие доводов для разработки архитектуры и (или) обоснования сроков проведения работ определенных подпунктом 1) пункта 22 настоящих Правил.
28. Планирование расходов на выполнение работ по разработке архитектуры производится государственными органами в соответствии с инструкцией по составлению, представлению и рассмотрению расчета расходов на государственные закупки товаров, работ, услуг в сфере информатизации, утвержденной приказом исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 16 марта 2016 года № 274 (зарегистрированный в Реестре государственной регистрации нормативных правовых актов за № 13631).
29. Необходимый объем работ по разработке архитектуры определяется сервисным интегратором по запросу заинтересованного государственного органа.
30. Необходимый объем расходов по разработке архитектуры включается в бюджетную заявку государственного органа на соответствующий период.
Параграф 2. Разработка проекта архитектуры
31. Архитектура для центральных исполнительных органов и государственных органов, непосредственно подчиненных и подотчетных Президенту Республики Казахстан, разрабатывается сервисным интегратором в соответствии с настоящими Правилами, требованиями по развитию архитектуры "электронного правительства", утвержденных приказом исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 28 января 2016 года № 124 (зарегистрированный в Реестре государственной регистрации нормативных правовых актов за № 13350) (далее – Требования), а также на основании целей и задач государственного органа.
32. Архитектура для местных исполнительных органов разрабатывается сервисным интегратором на основании типовой архитектуры "электронного акимата", утверждаемой в соответствии с подпунктом 18) статьи 7 Закона (далее – Типовая архитектура), в соответствии с настоящими Правилами, Требованиями, а также на основании целей и задач государственного органа.
33. В процессе разработки архитектуры государственный орган:
1) обеспечивает сбор и своевременное предоставление информации, необходимой для разработки архитектуры, сервисному интегратору;
2) обеспечивает компетентный и квалифицированный состав участников для разработки архитектуры;
3) обеспечивает участие представителей государственного органа и подведомственных организаций в проведении интервью и совещаний;
4) организует и координирует работы по разработке архитектуры со стороны государственного органа;
5) организует согласование и утверждение проекта архитектуры.
34. Местный исполнительный орган в процессе разработки архитектуры кроме перечисленного выше:
1) обеспечивает включение мероприятий по реализации архитектуры и отдельных проектов информатизации в план мероприятий по реализации программы развития территории;
2) предоставляет уполномоченному органу на ежеквартальной основе информации о статусе реализации архитектуры посредством архитектурного портала;
3) предоставляет информацию о реализации мероприятий по информатизации в рамках регламентных процедур отчетности о реализации программы развития территории.
35. Состав участников разработки архитектуры включает:
1) не менее двух представителей от каждого структурного подразделения государственного органа, в том числе руководителя структурного подразделения или его заместителя;
2) представителей заинтересованных подведомственных организаций;
3) представителей уполномоченного органа;
4) представителей сервисного интегратора, непосредственно осуществляющие разработку архитектуры.
36. Разработка архитектуры осуществляется в соответствии со следующими принципами:
1) обоснованность – обеспечение полноты и достоверности исходной информации, представленной государственным органом и необходимой для разработки архитектуры;
2) единообразие – использование единых принципов, подходов и инструментов разработки или развития архитектуры;
3) прагматичность - ясность, полезность, практичность и реализуемость разработанной архитектуры;
4) итеративность – проведение этапов разработки архитектуры до получения удовлетворительного результата;
5) согласованность – соответствие разработанной архитектуры требованиям законодательства Республики Казахстан, согласованность слоев архитектуры между собой, отсутствие в архитектуре дублирующих и конфликтующих компонентов;
6) гибкость – обеспечение возможности автономного обновления только необходимой части архитектуры;
7) прозрачность – обеспечение доступности результатов разработки архитектуры для всех государственных органов и заинтересованных сторон на всех этапах разработки архитектуры;
8) причастность (соавторство) – обеспечение регулярного участия руководителей и сотрудников государственного органа в разработке архитектуры для контроля и принятии необходимых решений;
9) осведомленность – обеспечение постоянного и всестороннего информирования руководителей государственного органа и уполномоченного органа о статусе разработки архитектуры, а также возникающих в процессе разработки архитектуры рисках и проблемах.
37. Уполномоченный орган направляет в произвольной форме уведомление сервисному интегратору о необходимости разработки архитектуры.
38. Разработка архитектуры осуществляется восемь месяцев с момента получения сервисным интегратором уведомления о необходимости разработки архитектуры от уполномоченного органа в случае наличия необходимого финансирования для проведения работ.
39. Разработка архитектуры включает следующие этапы:
1) подготовка к разработке архитектуры;
2) разработка проекта архитектуры;
3) планирование реализации архитектуры;
4) согласование и утверждение архитектуры.
40. Сервисный интегратор обеспечивает обучение и методологическое обеспечение участников разработки архитектуры от государственного органа этапам разработки, сопровождения реализации и развития архитектуры.
41. Разработка проекта архитектуры осуществляется путем последовательного построения слоев архитектуры в следующем порядке:
1) разработка архитектуры деятельности;
2) разработка архитектуры данных;
3) разработка архитектуры информационных систем;
4) разработка архитектуры ИК-инфраструктуры.
42. Повторение действий при разработке архитектуры могут проводиться в рамках одного слоя архитектуры, между несколькими или всеми слоями архитектуры.
43. Сервисный интегратор на подготовительном этапе определяет требования и ожидания государственного органа от разработки архитектуры, включая:
1) контекст архитектуры;
2) недостатки и ограничения деятельности, решаемые посредством разработки архитектуры;
3) цели и целевые индикаторы для оценки корректности, и качества разработанной архитектуры;
4) перечень заинтересованных сторон с указанием ожиданий заинтересованной стороны.
44. Архитектура деятельности формирует требования к компонентам всех слоев архитектуры.
45. В рамках разработки архитектуры деятельности сервисный интегратор выполняет следующие задачи:
1) выявляет перечень целей, задач и целевых индикаторов государственного органа, отраженных в документах Системы государственного планирования, соответствующих контексту разрабатываемой архитектуры;
2) выявляет перечень направлений деятельности государственного органа;
3) описывает текущее состояние модели деятельности государственного органа либо, в случае необходимости, отдельных направлений деятельности государственного органа;
4) анализирует модели деятельности, цели, задачи и целевые индикаторы, соответствующие контексту разрабатываемой архитектуры, а также ожидания заинтересованных сторон, выявляет и категоризирует перечень стратегических приоритетов государственного органа и формирует текущее состояние модели мотивации деятельности;
5) анализирует организационную структуру и положения структурных подразделений, и по результатам группирует государственные функции и услуги в перечень функциональных возможностей для центрального исполнительного органа и государственного органа, непосредственно подчиненного и подотчетного Президенту Республики Казахстан, либо адаптирует типовую архитектуру "электронного акимата";
6) описывает текущее состояние функциональной модели государственного органа из перечня функциональных возможностей;
7) соотносит функциональную модель государственного органа с перечнем стратегических приоритетов и выявляет перечень стратегически значимых функциональных возможностей;
8) проводит оценку состояния функциональных возможностей;
9) соотносит и детализирует существующие недостатки и ограничения деятельности с функциональной моделью, определяет возможные причины их возникновения;
10) формирует и определяет приоритетный перечень предложений по оптимизации государственных функций и услуг путем их сопоставления с функциональной моделью государственного органа, руководствуясь шаблонами архитектуры;
11) формирует целевое состояние модели мотивации деятельности, модели деятельности и функциональной модели государственного органа;
12) формирует резюме архитектуры деятельности для обсуждения результатов с заинтересованными сторонами.
46. В рамках разработки архитектуры данных сервисный интегратор выполняет следующие задачи:
1) определяет перечень информации (документов), которая создается и используется в рамках стратегически значимых функциональных возможностей целевого состояния функциональной модели и описывает текущее состояние модели данных;
2) определяет наличие недостатков и ограничений деятельности государственного органа, связанных с отсутствием или недостаточным развитием информационного обеспечения, и степень их влияния на результаты деятельности;
3) выявляет приоритеты автоматизации функциональных возможностей;
4) определяет требования к способу автоматизации и необходимый уровень автоматизации функциональных возможностей, руководствуясь шаблонами архитектуры и (или) типовой архитектурой "электронного акимата";
5) определяет требования к характеристикам информационного обеспечения для стратегически значимых функциональных возможностей целевого состояния функциональной модели;
6) выявляет существующие потоки информационного взаимодействия государственного органа и описывает текущее состояние модели информационного взаимодействия;
7) определяет уровень соответствия существующего информационного обеспечения требованиям согласно подпункта 2) настоящего пункта и выявляет возможности по его улучшению, руководствуясь шаблонами архитектуры и (или) типовой архитектурой "электронного акимата";
8) определяет перечень источников информации на уровне структурных подразделений, подведомственных организаций или других государственных органов, покрывающих потребности в информации целевого состояния функциональной модели;
9) в случае отсутствия эталонных источников информации, отбирает источники информации путем проведения анализа и оценки качества, хранимых в них данных в соответствии с методикой;
10) формирует и приоритезирует перечень предложений по управлению информационным обеспечением, оптимизации и унификации информационного взаимодействия, определению ответственности за ведение информации, руководствуясь шаблонами архитектуры;
11) формирует целевое состояние модели данных и модели информационного взаимодействия;
12) формирует резюме архитектуры данных для обсуждения результатов с заинтересованными сторонами.
47. В рамках разработки архитектуры информационных систем сервисный интегратор выполняет следующие задачи:
1) определяет перечень и характеристики существующих информационных систем государственного органа;
2) описывает текущие ИКТ-проекты;
3) описывает текущее состояние модели информационных систем;
4) соотносит перечень существующих и планируемых к реализации информационных систем с целевым состоянием функциональной модели и определяет соответствие требованиям к характеристикам информационного обеспечения, уровень покрытия стратегически значимых функциональных возможностей, наличие функционального дублирования и текущий уровень автоматизации стратегически значимых функциональных возможностей;
5) определяет типы информации из перечня информации определенной в соответствии с подпунктом 1) пункта 46 настоящих Правил, востребованной стратегически значимыми функциональными возможностями, которые создаются либо потребляются существующими информационными системами, наличие дублирования хранимых данных и возможности для интеграции информационных систем;
6) описывает текущее состояние модели интеграции информационных систем;
7) классифицирует информационные системы в соответствии с правилами классификации объектов информатизации и классификатором объектов информатизации, утвержденных приказом исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 28 января 2016 года № 135 (зарегистрированные в Реестре государственной регистрации нормативных правовых актов за № 13349) (далее – правила классификации объектов информатизации и классификатором объектов информатизации), и определяет их соответствие требованиям законодательства Республики Казахстан и к классу информационной системы;
8) определяет планируемый уровень соответствия требованиям к характеристикам информационного обеспечения, и уровень покрытия стратегически значимых функциональных возможностей;
9) описывает и приоритезирует перечень предложений по полноценному охвату и обеспечению требуемого уровня информационного обеспечения и автоматизации стратегически значимых функциональных возможностей, руководствуясь шаблонами архитектуры;
10) определяет требования к структуре, масштабу, мощности, интеграции, функциональным границам и архитектуре информационных систем, руководствуясь шаблонами архитектуры;
11) формирует целевое состояние модели информационных систем;
12) формирует целевое состояние модели интеграции информационных систем в соответствии с требованиями целевого состояния модели информационного взаимодействия;
13) формирует резюме архитектуры информационных систем для обсуждения результатов с заинтересованными сторонами.
48. В рамках разработки архитектуры ИК-инфраструктуры сервисный интегратор выполняет следующие задачи:
1) определяет перечень, характеристики и месторасположение существующих компонентов ИК-инфраструктуры государственного органа;
2) описывает текущее состояние модели ИК-инфраструктуры;
3) сопоставляет компоненты ИК-инфраструктуры с целевым состоянием функциональной модели, модели информационных систем и модели интеграции информационных систем;
4) классифицирует компоненты ИК-инфраструктуры в соответствии с правилами классификации объектов информатизации и классификатором объектов информатизации, и определяет соответствие компонента ИК-инфраструктуры требованиям законодательства Республики Казахстан в области информатизации и к классу объекта информатизации;
5) формирует требования к нефункциональным характеристикам и определяет соответствие данным требованиям существующих компонентов ИК-инфраструктуры;
6) определяет существующий уровень нагрузки и текущее состояние компонентов ИК-инфраструктуры, в том числе достижение окончания сроков выпуска и технической поддержки, а также амортизации;
7) формирует и приоритезирует перечень предложений по внедрению, своевременной полной или частичной замене, консолидации, стандартизации, обновлению и (или) выводу из эксплуатации компонентов ИК-инфраструктуры, а также об изменении места расположения и (или) перераспределении компонентов ИК-инфраструктуры, руководствуясь шаблонами архитектуры и (или) типовой архитектурой "электронного акимата";
8) формирует целевое состояние модели ИК-инфраструктуры в соответствии с требованиями целевой архитектуры деятельности и целевой архитектуры информационных систем;
9) формирует резюме архитектуры ИК-инфраструктуры для обсуждения результатов с заинтересованными сторонами.
49. Целевое состояние модели мотивации деятельности, модели деятельности, функциональной модели, модели данных, модели информационного взаимодействия, модели информационных систем, модели интеграции информационных систем, модели ИК-инфраструктуры для местных исполнительных органов формируется на основании типовой архитектуры "электронного акимата".
50. По результатам разработки целевого состояния модели информационных систем, модели интеграции информационных систем и модели ИК-инфраструктуры, сервисным интегратором разрабатывается архитектурный дизайн программного продукта, который содержит:
1) общее описание программного продукта;
2) описание принципов реализации, требований и ограничений;
3) описание автоматизируемых функций и бизнес-процессов;
4) описание компонентов программного продукта;
5) описание необходимых интеграций программного продукта;
6) описание требований к нефункциональным характеристикам программного продукта.
51. Сервисный интегратор в рамках разработки каждого слоя архитектуры:
1) обеспечивает сопоставление текущего и целевого состояния моделей архитектуры, для выявления компонентов архитектуры, в отношении которых отсутствуют рекомендации;
2) обеспечивает проверку полноты, целостности и эффективности целевой архитектурой в целях определения пересечений и конфликтов между компонентами архитектуры, а также упущенных и избыточных компонентов архитектуры;
3) выявляет возможности для повторного использования компонентов архитектуры и стандартных решений на межведомственном уровне.
52. По результатам выполнения каждой из задач в рамках разработки архитектуры сервисный интегратор проводит обсуждение и согласование промежуточных результатов разработки проекта архитектуры с государственным органом.
53. По результатам завершения работ над слоем архитектуры сервисный интегратор проводит презентацию промежуточных результатов разработки архитектуры для государственного органа.
54. По результатам обсуждений и презентаций сервисный интегратор вносит необходимые изменения в проект архитектуры.
55. По завершении работ в рамках всех слоев архитектуры результаты работ оформляются и формализуются сервисным интегратором в форме проекта архитектуры в соответствии с его методологическим обеспечением.
56. Спорные вопросы и противоречия между государственным органом, уполномоченным органом и сервисным интегратором в рамках проекта архитектуры выносятся на рассмотрение экспертного совета в сфере информатизации (далее - экспертный совет).
57. Проект архитектуры местного исполнительного органа области, города республиканского значения, столицы после согласования местным исполнительным органом направляется на согласование в уполномоченный орган по государственному планированию.
58. После согласования государственным органом проекта архитектуры сервисный интегратор размещает информацию о проекте архитектуры на архитектурном портале для дальнейшего использования государственными органами для мониторинга, анализа и планирования в сфере информатизации и дальнейшего согласования проекта архитектуры иными государственными органами на экспертном совете.
59. Государственный орган направляет на согласование проект архитектуры в адрес рабочего органа экспертного совета для рассмотрения экспертным советом в соответствии с параграфом 4 главы 2 настоящих Правил, на основании подпункта 5) статьи 9 и подпункта 5) статьи 10 Закона.
Параграф 3. Планирование реализации архитектуры
60. После согласования экспертным советом проекта архитектуры сервисный интегратор осуществляет планирование реализации архитектуры.
61. Планирование реализации архитектуры охватывает ИКТ-проекты в среднесрочной (от года до двух лет реализации) и долгосрочной перспективе (от трех до пяти лет реализации).
62. Планирование реализации архитектуры обеспечивает формирование ИКТ-проектов, учет взаимосвязей между ИКТ-проектами и проведение изменений в рамках всех слоев архитектуры.
63. При планировании реализации архитектуры учитываются цели, задачи и целевые индикаторы разработки архитектуры, требования законодательства Республики Казахстан, а также сроки, стоимость и ресурсы, необходимые для реализации архитектуры.
64. В рамках планирования реализации архитектуры сервисный интегратор выполняет следующие задачи:
1) анализирует текущие ИКТ-проекты и оценивает их соответствие компонентам целевой архитектуры;
2) проводит комплексный анализ текущих ИКТ-проектов и формирует выводы о степени эффективности текущего портфеля ИКТ-проектов;
3) выявляет компоненты целевой архитектуры, не охваченные текущими ИКТ-проектами;
4) формирует предложения по консолидации, приостановлению, отказу от реализации или пересмотру текущих ИКТ-проектов, в том числе изменение приоритета, бюджета, сроков и масштаба реализации, в целях обеспечения соответствия компонентам целевой архитектуры;
5) определяет состав ИКТ-проектов в дополнение к текущему портфелю ИКТ-проектов для обеспечения охвата всех компонентов целевой архитектуры;
6) формирует целевой портфель ИКТ-проектов, в который включаются текущие ИКТ-проекты с учетом рекомендаций по их пересмотру и дополнительные ИКТ-проекты;
7) проводит описание ИКТ-проектов;
8) проводит оценку соответствия целям, задачам и целевым индикаторам разработки архитектуры и сравнение эффективности целевого портфеля ИКТ-проектов с текущим портфелем ИКТ-проектов и, в случае необходимости, пересматривает состав и содержание ИКТ-проектов и компонентов архитектуры;
9) формирует резюме характеристик целевого портфеля ИКТ-проектов, содержащее описание сроков и необходимого объема инвестиций, прогнозируемого эффекта и ожидаемых результатов от инвестиций, целевых индикаторов реализации архитектуры и отдельных ИКТ-проектов, сравнение показателей существующего и целевого портфеля ИКТ-проектов;
10) формирует план-график реализации архитектуры с описанием переходных состояний архитектуры для описания этапов проводимых изменений.
65. В рамках описания ИКТ-проектов сервисный интегратор выполняет следующие задачи:
1) проводит описание ИКТ-проекта, включая цель, задачи, ожидаемые показатели результата, а также формирование содержания и масштаба ИКТ-проекта;
2) определяет категорию ИКТ-проекта (внутриведомственный, межведомственный, отраслевой);
3) определяет заинтересованные стороны ИКТ-проекта (заказчик, собственник, владелец, исполнитель);
4) определяет взаимосвязи со стратегическими приоритетами, функциональными возможностями и компонентами целевой архитектуры;
5) определяет либо корректирует класс объекта информатизации;
6) выбирает оптимальный формат реализации ИКТ-проекта, в том числе внедрения сервисных программных продуктов, готовых и стандартных решений, создания, развития или списания действующих информационных систем;
7) определяет угрозы и риски реализации ИКТ-проекта, а также подходы к своевременному реагированию на их возникновение;
8) определяет необходимость и оптимальную модель финансирования ИКТ-проекта;
9) устанавливает предельные границы бюджета ИКТ-проекта в соответствии с целями, задачами и целевыми индикаторами разработки архитектуры;
10) определяет приоритет и зависимости между внутриведомственными, отраслевыми и межведомственными ИКТ-проектами, устанавливает последовательность и сроки их реализации;
11) определяет ключевые этапы реализации ИКТ-проекта и ожидаемые результаты для каждого из этапов;
12) формирует рекомендации по пересмотру существующих ИКТ-проектов.
66. По результатам описания ИКТ-проектов и составления план-графика реализации архитектуры сервисный интегратор проводит обсуждение состава и содержания ИКТ-проектов с заинтересованными сторонами государственного органа.
67. По результатам обсуждения план-графика реализации архитектуры и ИКТ-проектов сервисный интегратор проводит презентацию результатов для государственного органа.
68. Государственный орган проводит оценку результатов разработки проекта архитектуры по отношению к целям, задачам и показателям архитектуры.
69. По результатам обсуждений и презентаций сервисный интегратор вносит необходимые изменения в план-график реализации архитектуры и описание ИКТ-проектов.
70. Результаты планирования (план-график реализации архитектуры и описание ИКТ-проектов) согласуются государственным органом и включаются в проект архитектуры.
71. Сервисный интегратор размещает информацию о дополненном проекте архитектуры на архитектурном портале для дальнейшего использования государственными органами для мониторинга, анализа и планирования в сфере информатизации.
72. Государственный орган направляет согласованный и дополненный результатами планирования реализации проект архитектуры рабочему органу экспертного совета для вынесения на рассмотрение экспертного совета в соответствии с параграфом 4 главы 2 настоящих Правил, на основании подпункта 5) статьи 9 и подпункта 5) статьи 10 Закона.
Параграф 4. Согласование и утверждение архитектуры
73. Экспертный совет осуществляет рассмотрение, и согласование проекта архитектуры в сроки, определенные пунктом 75 настоящих Правил.
74. Экспертный совет в рамках рассмотрения и согласования проекта архитектуры обеспечивает:
1) коллегиальное разрешение спорных вопросов между государственными органами и сервисным интегратором, возникающих в процессе разработки и планирования реализации проекта архитектуры;
2) разностороннюю оценку, обсуждение и формирование предложений по обеспечению полноты и качества разрабатываемого проекта архитектуры.
75. При соблюдении требований пункта 76 Правил экспертный совет рассматривает и принимает решение о согласовании проекта архитектуры в срок сорок пять календарных дней с даты поступления документов в рабочий орган экспертного совета.
76. Экспертный совет рассматривает:
1) проект архитектуры на предмет:
полноты и достаточности информации для принятия решения;
исключения противоречий между архитектурами нескольких государственных органов в рамках смежных направлений деятельности и сквозных межведомственных функций;
достижения межведомственных индикаторов и показателей по информатизации;
возможности повторного использования компонентов архитектуры;
2) результаты планирования реализации архитектуры на предмет:
оценки избыточности и полноты целевого портфеля ИКТ-проектов;
приоритезации межведомственных и отраслевых ИКТ-проектов;
координации реализации межведомственных ИКТ-проектов;
оценки показателей реализации архитектуры и ИКТ-проектов информатизации;
оценки и корректировки стоимости целевого портфеля ИКТ-проектов и отдельных ИКТ-проектов.
77. По мере необходимости экспертный совет дает рекомендации и предложения к проекту архитектуры.
78. В случае наличия рекомендаций и предложений экспертного совета государственный орган повторно направляет доработанный проект архитектуры в экспертный совет в соответствии со сроками, указанными в решении экспертного совета, либо не позднее тридцати календарных дней с даты вынесения решения экспертного совета, если такой срок не установлен.
79. Экспертный совет согласовывает представленный проект архитектуры в случае отсутствия рекомендаций и предложений либо их устранения.
80. По результатам согласования экспертного совета проект архитектуры утверждается и подлежит реализации.
81. Проект архитектуры местного исполнительного органа для соответствующей административно-территориальной единицы (области, города республиканского значения, столицы), включает в себя местный исполнительный орган района, города областного значения, района в городе, а также аппарат акима города районного значения, поселка, села, сельского округа и утверждается акиматом области, городом республиканского значения, столицей.
82. Государственный орган отражает информацию об утвержденной архитектуре на архитектурном портале.
83. Государственные органы создают необходимые организационные и технические условия для реализации архитектуры в соответствии с требованиями, утвержденной архитектуры и правилами реализации сервисной модели информатизации.
84. Государственный орган после утверждения архитектуры инициирует внесение изменений в документы Системы государственного планирования с целью отражения в них целевых индикаторов реализации архитектуры и показателей результата отдельных ИКТ-проектов.
85. В зависимости от категории, ИКТ-проекты и их показатели результатов определяются в документах Системы государственного планирования:
1) в стратегических планах государственных органов внутриведомственные ИКТ-проекты;
2) в отраслевых и государственных программах отраслевые ИКТ-проекты;
3) в государственной программе в сфере информатизации межведомственные ИКТ-проекты.
86. Государственный орган в рамках утвержденной архитектуры проводит:
1) инициацию государственных инвестиционных проектов и планирование государственных закупок товаров, работ и услуг в сфере информатизации;
2) консолидацию, приостановление, изменение, пересмотр или отказ от реализации существующих ИКТ-проектов в соответствии с требованиями законодательства Республики Казахстан.
87. В зависимости от выбранной модели финансирования на основе описания ИКТ-проектов государственный орган разрабатывает и (или) организует разработку необходимой технической и проектной документации ИКТ-проектов в соответствии с требованиями законодательства Республики Казахстан.
88. Содержание утвержденной архитектуры, моделей архитектуры и архитектурных дизайнов программных продуктов для дальнейшей реализации включается в состав:
1) технической и проектной документации ИКТ-проектов;
2) конкурсной документации и договоров о государственных закупках товаров, работ и услуг в сфере информатизации.
89. Государственный орган инициирует разработку сервисных программных продуктов в соответствии с правилами реализации сервисной модели информатизации.
90. Сервисный интегратор в целях реализации архитектуры информирует оператора ИК-инфраструктуры и потенциальных поставщиков (подрядчиков) о потребностях государственных органов в товарах, работах, услугах, связанных с автоматизацией государственных функций и государственных услуг в рамках реализации сервисной модели информатизации.
91. Государственный орган в соответствии с утвержденной архитектурой определяет требования к уровню обслуживания объектов информатизации.
92. В целях проведения достоверной и объективной оценки эффективности, результативности и рисков реализации утвержденной архитектуры и отдельных ИКТ-проектов государственный орган обеспечивает учет сведений о статусе объектов информатизации "электронного правительства" на архитектурном портале в соответствии с правилами регистрации информационных систем государственных органов, учета сведений об объектах информатизации "электронного правительства", и размещения электронных копий технической документации объектов информатизации "электронного правительства", утвержденными приказом исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 28 января 2016 года № 128 (зарегистрированный в Реестре государственной регистрации нормативных правовых актов за № 13320).
Глава 3. Порядок сопровождения реализации архитектуры
93. Сопровождение реализации архитектуры осуществляется в следующем порядке:
1) оценка соответствия архитектуре;
2) оценка уровня готовности процессов по управлению архитектурой;
3) внесение изменений в архитектуру государственного органа.
Параграф 1. Оценка соответствия архитектуре
94. Оценка соответствия архитектуре осуществляется в целях обеспечения выявления, согласования и обоснования изменений требований к создаваемым и развиваемым объектам информатизации в утвержденной архитектуре.
95. Оценка соответствия архитектуре проводится сервисным интегратором посредством выявления несоответствия ИКТ-проектов требованиям утвержденной архитектуры, на этапах:
1) планирования ИКТ-проекта;
2) инвестиционного периода ИКТ-проекта;
3) постинвестиционного периода ИКТ-проекта.
96. Оценка соответствия архитектуре на этапе планирования ИКТ-проекта осуществляется путем:
1) экспертизы проектной документации, на соответствие Требованиям, утвержденной архитектуре и типовой архитектуре "электронного акимата";
2) экспертизы расчета расходов на государственные закупки товаров, работ и услуг в сфере информатизации.
97. Государственный орган до утверждения архитектуры осуществляет планирование расходов по бюджетным программам в сфере информатизации в соответствии с Правилами составления и представления бюджетной заявки, утвержденными приказом Министра финансов Республики Казахстан от 24 ноября 2014 года № 511 (зарегистрированные в Реестре государственной регистрации нормативных правовых актов за № 10007).
98. Государственный орган осуществляет реализацию ИКТ-проектов в соответствии со стандартами по управлению проектами, действующими на территории Республики Казахстан, в том числе СТ РК ISO 21500-2014-Руководство по управлению проектами.
99. Оценка соответствия архитектуре для государственных органов до утверждения архитектуры проводится относительно государственных органов смежных и пересекающихся отраслей (сфер) государственного управления.
100. Оценка соответствия архитектуре в инвестиционном периоде ИКТ-проекта осуществляется путем:
1) оценки планов государственных закупок ИКТ-проектов, технических спецификаций и фактов проведения государственных закупок на предмет соответствия приобретаемых объектов информатизации архитектуре;
2) оценки характеристик, состава и содержания результатов ИКТ-проектов на этапах ввода объектов информатизации в эксплуатацию.
101. Оценка соответствия архитектуре в постинвестиционном периоде ИКТ-проекта осуществляется путем:
1) оценки соответствия целей и показателей результата ИКТ-проектов существующим целям, задачам и целевым индикаторам Системы государственного планирования;
2) оценки наличия технологических рисков объектов информатизации, а также инновационных перспективных технологий для повышения эффективности деятельности;
3) оценки состояния функциональных возможностей;
4) оценки соответствия результатов реализации ИКТ-проекта существующим ожиданиям заинтересованных сторон и социально-экономическим условиям.
102. По результатам оценки соответствия архитектуре сервисный интегратор выносит заключение об уровне соответствия ИКТ-проекта и архитектурных компонентов, в том числе:
1) не соответствует архитектуре;
2) частично соответствует архитектуре;
3) полностью соответствует архитектуре.
103. В случае несоответствия или частичного соответствия результатов реализации ИКТ-проекта, утвержденной архитектуре сервисным интегратором формулируются рекомендации по доработке результатов реализации ИКТ-проектов.
104. В случае несоответствия утвержденной архитектуре и отсутствия возможности доработки результатов ИКТ-проектов, сервисным интегратором подготавливается заявка на изменение утвержденной архитектуры государственного органа в произвольной форме (далее – заявка на изменение) в соответствии с параграфом 3 главы 3 настоящих Правил.
Параграф 2. Оценка уровня готовности процессов
по управлению архитектурой
105. Сервисный интегратор на ежегодной основе до 30 ноября проводит оценку уровня готовности процессов по управлению архитектурой в соответствии с методологическим обеспечением.
106. Оценка уровня готовности процессов по управлению архитектурой проводится по следующим направлениям:
1) объем фактического исполнения утвержденной архитектуры;
2) охват и полнота практического применения утвержденной архитектуры;
3) результативность реализации утвержденной архитектуры.
107. Оценка уровня готовности процессов по управлению архитектурой проводится на внеочередной основе по запросу экспертного совета.
108. Оценка уровня готовности процессов по управлению архитектурой производится по результатам мониторинга реализации архитектуры и оценки соответствия архитектуре с использованием сведений архитектурного портала.
109. Результаты оценки уровня готовности процессов по управлению архитектурой используются при проведении оценки эффективности деятельности государственных органов по применению информационно-коммуникационных технологий в соответствии с требованиями методики оценки эффективности деятельности государственных органов по применению информационно-коммуникационных технологий, утвержденными приказом исполняющего обязанности Министра по инвестициям и развитию Республики Казахстан от 30 декабря 2015 года № 1279 (зарегистрированный в Реестре государственной регистрации нормативных правовых актов за № 12961).
110. Результаты оценки уровня готовности процессов по управлению архитектурой включаются сервисным интегратором в отчет о ходе работ по реализации архитектуры и представляются раз в год на рассмотрение экспертного совета.
111. Отчет о ходе работ по реализации архитектуры содержит следующую информацию:
1) общие сведения и статус реализации работ в разрезе государственных органов;
2) описание результатов реализации архитектуры;
3) существующие и потенциальные недостатки и риски в разрезе государственных органов;
4) выводы и рекомендации.
112. По результатам рассмотрения экспертным советом отчета о ходе работ по реализации архитектуры, уполномоченным органом могут быть инициированы изменения утвержденной архитектуры.
Параграф 3. Внесение изменений в архитектуру
государственного органа
113. Государственные органы обеспечивают мониторинг процессов и событий, которые напрямую или косвенно влияют на необходимость внесения изменений в утвержденную архитектуру, в том числе:
1) изменения состава и содержания законодательства Республики Казахстан, регламентирующего деятельность государственного органа, которые влекут изменения:
целей, задач и целевых индикаторов, в рамках документов Системы государственного планирования;
организационной структуры;
перечня подведомственных организаций;
направлений деятельности, компетенций и полномочий;
государственных функций, и вытекающих из них государственных услуг, а также процессов их исполнения;
2) изменения требований к информационному обеспечению, включая изменения:
типов и источников информации;
форматов хранения и передачи информации;
требований к отчетности;
3) достижение сроков амортизации и износа существующих компонентов ИК-инфраструктуры, в том числе вывод из эксплуатации или прекращение поддержки производителем программного обеспечения и оборудования.
114. В случае выявления в процессе реализации архитектуры необходимости изменения утвержденной архитектуры, государственный орган оформляет заявку на изменение архитектуры.
115. Уполномоченный орган в соответствии с подпунктом 41) статьи 7 Закона осуществляет мониторинг хода реализации утвержденной архитектуры.
116. В рамках проведения мониторинга реализации ИКТ-проектов уполномоченный орган обеспечивает оценку эффективности, результативности и рисков исполнения ИКТ-проектов на всех этапах реализации, в том числе:
1) несвоевременное проведение работ;
2) неполноценное проведение работ;
3) существенное превышение бюджетов;
4) не достижение либо частичное достижение целей и показателей результата, в том числе первоначально запланированной финансовой и социальной выгоды;
5) не востребованность и отсутствие использования результатов ИКТ-проектов;
6) не соответствие функциональных характеристик результатов ИКТ-проектов соглашению об уровне обслуживания и ожиданиям пользователей объектов информатизации.
117. В случае неудовлетворительных результатов реализации утвержденной архитектуры и ИКТ-проектов, а также отсутствия обоснования отклонений, уполномоченным органом подготавливается заявка на изменение утвержденной архитектуры государственного органа с указаниями и рекомендациями по изменению компонентов архитектуры и ИКТ-проектов.
118. Государственным органом, уполномоченным органом и (или) сервисным интегратором по результатам реализации архитектуры, в ходе мониторинга реализации архитектуры и оценки соответствия архитектуре, выявляются:
1) фактические изменения архитектуры в рамках реализации ИКТ-проектов;
2) потребности в развитии утвержденной архитектуры;
3) необходимые объемы изменений на основе выявленных потребностей в развитии утвержденной архитектуры.
119. Внесение изменений в архитектуру государственного органа проводится по результатам выявления потребности в развитии утвержденной архитектуры и производится описание необходимых изменений в форме заявки на изменение.
120. В рамках заявки на изменение производится:
1) описание предлагаемых изменений;
2) описание факторов и причин, влияющих на необходимость изменений;
3) оценка сроков и срочности предлагаемых изменений;
4) оценка масштаба и объемов предлагаемых изменений;
5) оценка ожидаемых результатов от реализации предлагаемых изменений;
6) оценка последствий, рисков и затрат, связанных с реализацией предлагаемых изменений.
121. Заявка на изменение направляется в рабочий орган экспертного совета.
122. Экспертный совет рассматривает запрос на изменение утвержденной архитектуры в течение сорока пяти календарных дней.
123. Экспертный совет рассматривает заявку на изменение утвержденной архитектуры на предмет:
1) целесообразности и обоснованности предлагаемых изменений;
2) наличия альтернатив реализации предлагаемых изменений;
3) срочности и своевременности предлагаемых изменений;
4) сложности и реализуемости предлагаемых изменений;
5) последствий предлагаемых изменений на внутриведомственном и межведомственном уровне;
6) согласованности изменений с зависимыми внутриведомственными, межведомственными и отраслевыми ИКТ-проектами других государственных органов.
124. В случае если внесение изменений в утвержденную архитектуру и ИКТ-проекты не представляется возможным, государственные органы корректируют полученные результаты ИКТ-проекта.
125. По результатам рассмотрения заявки на изменение утвержденной архитектуры экспертный совет:
1) отклоняет заявку на изменение утвержденной архитектуры в случае отсутствия целесообразности, наличия альтернатив реализации и высокой сложности предлагаемых изменений;
2) возвращает на доработку заявку на изменение утвержденной архитектуры в случае недостаточной обоснованности наличия необходимости корректировки масштаба, стоимости, рисков и сроков реализации;
3) согласует заявку на изменение утвержденной архитектуры в случае отсутствия замечаний и предложений либо устранения замечаний и предложений.
126. На основе согласованной экспертным советом заявки на изменение утвержденной архитектуры, государственный орган инициирует развитие архитектуры.
Глава 4. Порядок развития архитектуры
127. Развитие архитектуры инициируется по результатам согласования экспертным советом заявки на изменение утвержденной архитектуры в соответствии с требованиями параграфа 3 главы 3 настоящих Правил.
128. Предпосылками для развития архитектуры являются изменения:
1) состава и содержания нормативных правовых актов и документов Системы государственного планирования, регулирующих деятельность государственного органа;
2) требований к информационному обеспечению деятельности, информационным системам и ИК-инфраструктуре государственного органа;
3) структуры и (или) объема бюджетных расходов в сфере информатизации.
129. Срочность развития архитектуры обусловлена сроками проведения работ, определенными в согласованной заявке на изменение утвержденной архитектуры в соответствии с требованиями пунктов 20 и 26 настоящих Правил.
130. Развитие архитектуры осуществляется в масштабе всего государственного органа, отдельных сегментов архитектуры либо отдельных слоев архитектуры.
131. Развитие архитектуры осуществляется аналогично разработке архитектуры в порядке, установленном главой 2 настоящих Правил.
132. Развитие архитектуры в зависимости от масштаба подразделяется на актуализацию, изменение и переработку утвержденной архитектуры.
133. Актуализация архитектуры связана с частичными изменениями отдельных компонентов архитектуры либо требованием государственного органа по уменьшению количества ИКТ-проектов, в том числе:
1) редакционные изменения - переименование и корректировка значений отдельных компонентов архитектуры с целью увеличения их корректности, применимости и понятности;
2) исключение компонентов – исключение компонентов либо их составных частей из архитектуры.
134. Работы по актуализации архитектуры выполняются сервисным интегратором по согласованию с уполномоченным органом, а также государственным органом, в лице структурных подразделений государственного органа, инициировавших изменение и (или) являющихся заинтересованными сторонами, затронутыми изменениями ИКТ-проектов.
135. Актуализация архитектуры осуществляется в срок не более двух месяцев с момента согласования экспертным советом заявки на изменение утвержденной архитектуры.
136. Изменение архитектуры связано с необходимостью корректировки компонентов архитектуры не более одного слоя или сегмента архитектуры, либо требованием государственного органа по получению дополнительных результатов от предусмотренных в утвержденной архитектуре ИКТ-проектов:
1) пересмотр компонентов - замена компонентов архитектуры;
2) структурные изменения – изменения в структуре, содержании, отношениях между компонентами архитектуры;
3) перераспределение компонентов – объединение, разделение либо перенос компонентов архитектуры или их составных частей.
137. К участию в работе по изменению утвержденной архитектуры привлекаются сотрудники уполномоченного органа, сервисного интегратора, а также структурных подразделений и подведомственных организаций государственного органа, затронутых проводимыми изменениями.
138. Изменение архитектуры осуществляется в срок не более трех месяцев с момента согласования экспертным советом заявки на изменение утвержденной архитектуры в рамках сопровождения реализации архитектуры.
139. Переработка архитектуры связана с необходимостью проведения концептуальных и фундаментальных изменений либо требованием государственного органа по увеличению количества ИКТ-проектов путем добавления новых компонентов архитектуры, затрагивающих два и более слоя или сегмента архитектуры.
140. К участию в работе по переработке утвержденной архитектуры привлекаются сотрудники всех структурных подразделений и подведомственных организаций государственного органа.
141. Переработка архитектуры осуществляется в установленные для разработки архитектуры порядке и сроки в соответствии с главой 2 настоящих Правил.
142. Необходимый объем расходов по развитию архитектуры включается в бюджетную заявку государственного органа на соответствующий период.
143. Результаты работ по развитию архитектуры оформляются в виде проекта архитектуры и подлежат согласованию экспертным советом в соответствии с параграфом 4 главы 2 настоящих Правил.
144. Результаты работ по развитию архитектуры местного исполнительного органа области, города республиканского значения, столицы направляется на согласование в уполномоченный орган по государственному планированию.
145. По результатам согласования экспертного совета проект развития архитектуры утверждается и подлежит реализации.
146. Сервисный интегратор отражает результаты работ по развитию архитектуры на архитектурном портале.