альтернативный текст

Заголовок

Экспертиза бюджетных инвестиционных проектов в сфере информатизации

Сервисный интегратор «электронного правительства» проводит экспертизу в сфере информатизации инвестиционных предложений, финансово-экономических обоснований бюджетных инвестиций, а также технических заданий на создание или развитие объектов информатизации «электронного правительства» в соответствии с подпунктом 10 статьи 12 Закона Республики Казахстан «Об информатизации».

Требования и критерии оценки инвестиционных предложений и ФЭО бюджетных инвестиций определены Правилами проведения экспертизы в сфере информатизации инвестиционных предложений, финансово-экономических обоснований бюджетных инвестиций, в соответствии с которыми экспертиза проводится на предмет целесообразности проекта и оптимальности используемых технических решений, а также на соответствие требованиям по развитию архитектуры «электронного правительства», утвержденной архитектуре государственного органа, типовой архитектуре «электронного акимата» и на наличие возможности использования стандартных решений при создании и развитии объектов информатизации «электронного правительства».

Согласно Правилам, инвестиционное предложение по бюджетным инвестиционным проектам вносится на экспертизу с приложением технического задания на создание и развитие объектов информатизации «электронного правительства».

По бюджетным инвестициям посредством участия государства в уставном капитале юридических лиц вносятся инвестиционное предложение, ФЭО бюджетных инвестиций. По скорректированным технико-экономическим обоснованиям экспертиза в сфере информатизации осуществляется в порядке, предусмотренном для ФЭО бюджетных инвестиций.

Требования к порядку разработки технического задания на создание и развитие объектов информатизации «электронного правительства» определены Правилами составления и рассмотрения технических заданий на создание и развитие объектов информатизации «электронного правительства». ТЗ предоставляется на экспертизу в пакете документов инвестиционного предложения и должно соответствовать технико-экономическим параметрам, установленным в инвестиционном предложении. 

Нормативно-правовая база

При проведении экспертизы в сфере информатизации Сервисный интегратор руководствуется следующими нормативно-техническими актами:

·       Закон Республики Казахстан «Об информатизации» от 24 ноября 2015 года № 418-V ЗРК.

·       Приказ Министра цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан от 29 июня 2019 года № 144/НҚ «Об утверждении Правил проведения экспертизы в сфере информатизации инвестиционных предложений, финансово-экономических обоснований бюджетных инвестиций»

·       Правила разработки или корректировки, проведения необходимых экспертиз инвестиционного предложения государственного инвестиционного проекта, а также планирования, рассмотрения, отбора, мониторинга и оценки реализации бюджетных инвестиций и определения целесообразности бюджетного кредитования от 5 декабря 2014 года № 129.

·       Приказ Министра цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан от 29 июня 2019 года № 143/НҚ «Об утверждении Правил составления и рассмотрения технических заданий на создание и развитие объектов информатизации «электронного правительства»

·       Методика расчета и нормативов затрат на создание, развитие и сопровождение информационных систем государственных органов от 28 января 2016 года № 133

·       Постановление Правительства Республики Казахстан от 20 декабря 2016 года № 832 Об утверждении единых требований в области информационно-коммуникационных технологий и обеспечения информационной безопасности

·       Приказ Министра информации и коммуникаций Республики Казахстан от 31 мая 2018 года № 239 «Об утверждении Требований по развитию архитектуры «электронного правительства»

Помощь государственным органам

В данном разделе представлен свод наиболее типичных ошибок, допускаемых государственными органами – администраторами бюджетных программ при разработке инвестиционных предложений, ФЭО бюджетных инвестиций и технических заданий, который составлен Сервисным интегратором на основании проведенных экспертиз.

 

Типичные ошибки в разработке инвестиционных предложений и ФЭО бюджетных инвестиций

1.     Необходимость создаваемого Проекта не обоснована целями, задачами и показателями, указанными в программных и стратегических документах государственных органов.

2.     Отсутствие или слабое раскрытие маркетингового анализа отрасли Проекта. Необходимо представить качественное описание проблем, недочетов или задач, которые государственный орган видит в своей текущей деятельности (отрасли). Это описание должно подкрепляться статистическими данными. Например, количество потребителей, количество оказанных услуг за период, средняя длительность оказания услуги или функции; средняя производительность сотрудника при выполнении функции или услуги; финансовые расходы при оказании услуги, функции (штат или содержание подведомственных организаций, бумага, транспорт, командировочные, связь, аренда, услуги других компаний). Должно также быть представлено описание существующих систем, которые уже функционируют и используются в государственном органе, существующее оборудование и каналы связи, которые могут быть использованы.

3.     Зачастую отсутствует конкретная постановка целей и задач Проекта и не приводятся конкретные измеримые показатели достижения целей Проекта. При этом, зачастую прямые и конечные показатели не коррелируются с целью Проекта. Достижение цели Проекта должно проверяться через эти показатели. Прямые показатели, при этом, должны отражать результаты, которые будут достигнуты по завершении инвестиционного периода. Конечные показатели, которые должны быть достигнуты в постинвестиционый период проекта, должны отражать, что изменит предлагаемый ИТ-проект в существующей деятельности ГО (какие характеристики оказываемых услуг и функций поменяются) и как это отразится на работе внутренних сотрудников и удовлетворение потребителей.

4.     Выбор оптимального варианта реализации Проекта производится по отдельным позициям, а не в комплексе, то есть альтернативные решения представляются по Проекту не в целом, а по отдельным компонентам. При этом, не проводится анализ альтернативных вариантов реализации проекта, с учетом возможности использования существующих решений и готовых продуктов для сокращения рисков и сроков реализации планируемого ИТ-проекта:

-   при закупе серверного оборудования не рассматривается вариант хостинга виртуальных серверов для сокращения издержек на реализацию Проекта;

-   не проводится анализ существующих готовых программных решений с открытым кодом вместо приобретения проприетарного ЛПО;

-   не проводится анализ варианта реализации Проекта на базе существующих ведомственных и межведомственных информационных систем государственных органов без необходимости создания новой информационной системы.

5.     Либо приводится неполный перечень товаров и услуг, закупаемых для реализации Проекта (в инвестиционном периоде) и эксплуатации Проекта (в постинвестиционном периоде), либо стоимость закупаемых товаров и услуг не обосновывается коммерческими предложениями, прайс-листами и прочими подтверждающими стоимость Проекта документами.

6.     Сроки разработки Проекта не основаны на применении нормативов и план-графике реализации Проекта. Зачастую при расчете сроков реализации Проекта не учтены риски реализации Проекта.

7.     План-графики Проектов не снижают рисков в случае неудачного завершения Проекта (снижение затрат на закуп основных средств до момента создания и приемки ППО).

8.     В большинстве Проектов не полностью описан текущий/ планируемый бизнес-процесс выполнения функций и предоставления услуг. Эффективность Проекта недостаточно проанализирована со следующей точки зрения:

-       сокращение времени как на оказание, так и на получение госуслуги;

-       сокращение трудоемкости;

-       сокращение количества запрашиваемых документов;

-       исключение непосредственных контактов услугодателя и услугополучателя.

9.     Риски Проекта должны иметь количественные показатели (оценку стоимости ущерба при наступлении риска, оценку вероятности наступления рисков) и обозначение конкретных владельцев рисков.

10. Зачастую отсутствуют проработанные критерии, позволяющие определить, какие способы финансирования (например, по механизму ГЧП, или СМИ) оптимальны для планируемого ИТ-проекта.

 

Типичные ошибки в разработке технических заданий

1.     Непредоставление технического задания (ТЗ) в пакете инвестиционного предложения бюджетных инвестиций.

2.     Несоответствие структуры и содержания ТЗ требованиям СТ РК 34.015-2002. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

3.     Несоответствие стадий, этапов и содержания работ жизненного цикла ИС требованиям СТ РК 34.019 – 2005. Информационная технология. Процессы жизненного цикла программных средств.

4.     Несоответствие ТЗ Единым требованиям в области информационно-коммуникационных технологий и обеспечения информационной безопасности, утвержденных ППРК от 20 декабря 2016 года № 832.

5.     Нечеткие цели и задачи Проекта. Создание Системы должно решать проблемы, которые ставятся и (или) решаются на каждом уровне. Цели создания Системы и выполнения работ должны коррелировать с показателями назначения Системы. Задачи должны коррелировать с работами, приведенными в составе работ в ТЗ. Задачи представляют собой последовательность шагов для достижения цели (результата). Результат – это показатели объекта автоматизации, которые должны быть достигнуты в результате создания Системы и выполнения работ.

6.     Отсутствие в ТЗ четко обозначенного перечня объектов автоматизации, структурного описания автоматизируемых бизнес-процессов, описание специфики процессов. Объектом автоматизации является деятельность пользователей системы. Каждая деятельность объектов автоматизации регламентируется соответствующим документом/положением, распоряжением и т. п. Должна быть приведена ссылка на нормативные документы, краткое описание деятельности в виде основных процедур и операций, перечень участников этой деятельности, т.е. тех, кто выполняет эти операции. В разделе следует указывать только те процессы, которые будут автоматизированы в рамках настоящего ТЗ без упоминаний об уже автоматизированных или не подлежащих автоматизации в данный момент. Должно быть приведено описание существующих систем, которые уже функционируют и используются на объекте автоматизации и должны быть учтены при проектировании, существующее оборудование и каналы связи, которые могут быть использованы.

7.     Отсутствие в ТЗ четко обозначенного перечня подсистем, их назначения и основных характеристик, соответствующих выполняемым задачам Проекта. Описание логической и физической архитектуры системы, помимо перечня функциональных и технологических подсистем, должно содержать описание и таких элементов архитектуры как сервера, приложения, СУБД, АРМ пользователей, библиотеки функций, запускаемые командные файлы и управляющие скрипты, входящие в состав системы. То есть все, что будет устанавливаться при развертывании системы или собираться при сборке в отдельные элементы/шаблоны. Число функциональных подсистем должно соответствовать числу автоматизируемых процессов, обозначенных в назначении системы. Если подсистемы развернуты на различных физических/виртуальных устройствах, должны быть указаны средства и технологии, обеспечивающие связь между устройствами. По каждой подсистеме должен быть представлен перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации, описываемых, как действие пользователя или системы над информационным объектами или документами.

8.     Зачастую не указываются конкретные требования к информационному взаимодействию Системы с внешними системами. Помимо перечня систем, с которыми должно быть обеспечено взаимодействие, должно быть указано:

-       в части какой информации (объектов, справочников) должен происходить обмен с внешними и смежными системами;

-       какие данные передаются;

-       направление передачи данных;

-       способ передачи данных (полностью автоматически, при участии пользователя);

-       требования к допустимой нагрузке на канал передачи данных.

Точный состав внешних систем должен быть определен исполнителем на основании анализа нормативной базы и обследования объекта автоматизации (процессов автоматизируемой деятельности). При этом по результатам анализа/обследования может быть выявлена как необходимость взаимодействия, так и отсутствие такой необходимости.

9.     Зачастую требования к развитию или модернизации Системы неконкретны и не соответствуют утвержденной архитектуре ГО (при ее наличии). Рекомендуем включать в требования к развитию краткие сведения о целевой архитектуре Системы, в случае, если предусмотрено последующее развитие. Также могут быть определены ограничения модернизации для обеспечения совместимости с платформами, смежными системами, хранилищами данных и применяемыми техническими средствами. Перспективы развития, модернизации системы и выполнения работ должны коррелировать с показателями назначения Системы. Основным показателем назначения являются показатели количества пользователей, числа обрабатываемых объектов, пропускной способности и времени получения отчетности в рамках заданного режима работы системы. В части количества пользователей должно быть приведено расчетное и максимальное количество пользователей Системы. В части значений по показателям, связанным с временем получения отчетности в Системе, должна быть представлена информация о времени обработки соответствующих запросов Системой отдельно для каждого вида отчета.

10. Зачастую в ТЗ отсутствует, или представлен неполный перечень требований к информационному обеспечению. Информационное обеспечение системы должно представлять собой совокупность всех необходимых для функционирования системы данных и систем обеспечения. В состав информационного обеспечения входят:

-       нормативно-справочная информация;

-       информационные объекты;

-       входные и выходные данные;

-       структура управления базами данных.

Должны быть перечислены:

-       требования к составу, структуре и способам организации данных в системе;

-       требования к информационному обмену между компонентами системы;

-       требования к информационной совместимости со смежными системами;

-       требования по использованию унифицированных документов и классификаторов;

-       требования по применению систем управления базами данных;

-       требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

-       требования к защите данных от разрушений при авариях и сбоях в электропитании системы;

-       требования к контролю, хранению, обновлению и восстановлению данных;

-       требования к процедуре придания юридической силы документам, продуцируемым техническими средствами Системы.

11. Зачастую в ТЗ представлен неполный перечень требований к программному обеспечению. Должны быть указаны:

-       состав и структура программного обеспечения, включая операционные системы, СУБД, базовые платформы, используемые библиотеки компонентов и шаблоны;

-       в случае использования базового ПО должны быть определены и ограничены функции, которые возложены на базовое ПО;

-       перечень покупных программных средств;

-       требования к необходимости согласован и т.п.

12. Зачастую требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие не содержат основных мероприятий, которые следует выполнить при подготовке объекта автоматизации к вводу Системы в действие, и их исполнителей. Должны быть освещены следующие основные вопросы:

-       Кто и как должен разворачивать и настраивать систему и что для этого может быть предоставлено?

-       Кто и как должен загрузить исходные данные, справочники, исторические данные?

-       Кто, как и в какой последовательности должен изменить конфигурацию смежных систем и систем, выводимых из эксплуатации по итогам ввода в эксплуатацию создаваемой Системы?

-       Кто и как должен разработать и утвердить нормативную документацию?

-       Кто и как должен подготовить пользователей и организовать эксплуатацию системы?

Обратная связь