ИТ-практика: как штурмовать госсектор?

Заказ от госструктуры на реализацию какого-либо проекта для многих ИТ-компаний сродни "счастливому билету". Но далеко не все заранее представляют себе те риски и препятствия, с которыми придется иметь дело. Ведь госсектор не просто капризный заказчик. Это совершенно особый сегмент ИТ-потребителей.

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

Прогресс поневоле

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

Регламенты, функциональный состав и задачи проектов автоматизации прописаны на уровне законодательства и могут не в полной мере разделяться региональными и федеральными органами исполнительной власти.

К примеру, требования к таким системам, как АСУ "Госзакупки", установленные на уровне федерального законодательства, носят достаточно общий характер (ФЗ-94.Ст.16.7. Порядок пользования официальными сайтами и требования к технологическим, программным, лингвистическим, правовым и организационным средствам обеспечения пользования указанными сайтами устанавливаются Правительством Российской Федерации).

Регламент регионального уровня зависит от особенностей принятой схемы размещения заказа. Кроме того, он более детализирован, что увеличивает список требований к системе. И он условно гибкий, это проявляется при прохождении соответствующей бюрократической процедуры.

Стоит отметить еще одну особенность госсектора — быстросрочные постановления, меняющие базу используемой нормативно-справочной информации. К примеру, каталог товаров, работ и услуг, закупаемых госсектором, отражен в 4 различных справочниках, имеющих различную структуру и кодификацию. Данные постановления носят не рекомендательный, а обязательный характер, и разработчикам приходится в кратчайшие сроки вносить изменения в программное обеспечение.

Справочники по номенклатуре для госсектора

Источник: Cnews Analytics, 2007

Сроки внесения изменений в действительности минимальны, к примеру, постановление Правительства №807 от 27 декабря 2006 года вступило в силу 1 января 2007 года.

Бег с препятствиями

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

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

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

Одним из спорных моментов можно назвать выбор поставщиков на основе результатов конкурса, где коррумпированность органов исполнительной власти играет не последнюю роль. Статистика внедрений АИС "Госзакупки" показывает, что в 50% случаев программные решения в регионах и федеральных органах исполнительной власти создаются силами компаний, не являющихся разработчиками специализированного ПО. Успех подобных инициатив сомнителен, поэтому данные регионы уже планируют в своих бюджетах финансирование проектов внедрения с привлечением консалтинговых компаний.

Поставщикам решений приходится затрачивать свои усилия на отстаивание собственных интересов, что приводит к загрузке как со стороны ФАС, так и со стороны заказчиков, составляющих развернутые ответы на жалобы и запросы участников размещения заказа.

Еще одно препятствие на пути автоматизации - малая инициативность госорганов в области совершенствования и использования информационных технологий, т.е. отсутствие активной позиции заказчика.

Как и во многих сферах, внедрение ИТ-проектов в госсекторе наталкивается на проблемы финансирования. Существующий бюджетный принцип формирования затрат на ИТ не предполагает быстрого реагирования на изменения в законодательстве, значит, внедрение происходит далеко не сразу. К действующему закону ФЗ-94 вышел новый закон 218 ФЗ от 24.07.07, и в нем предусмотрен механизм увеличения бюджета, но только на некоторые виды товаров, работ и услуг, в том числе НИОКР.

Есть и кадровая проблема. Уровень компетенций сотрудников госструктур в области информационных технологий и решений не достаточно высок. Закон о местном самоуправлении 131-ФЗ, вступивший в силу 1 января 2006 года, позволяет муниципальному образованию формировать требования в конкурсной документации при проведении конкурса на выбор поставщика ПО в части средств управления СУБД, базовым ПО, что может идти вразрез с ИТ-стратегией региона. Немногочисленные сотрудники ИТ-подразделения муниципального образования диктуют свои позиции, которые основываются подчас на личном небольшом опыте разработок.

Штурм госсектора

Попробуем, на примере все той же АИС "Госзакупки", детально описать этапы с учетом действующих рисков и способов их контроля и устранения. Риски могут быть спрогнозированы и по каждому из них либо приняты меры по устранению, либо проведена корректировка плана в случае их принятия.

Тендер. Этот этап, как правило, проводится персоналом, не имеющим соответствующей квалификации, и опыт показывает, что для проведения открытого конкурса на выбор поставщика решения привлечение специальной организации — только зря потраченные средства.

Для сокращения этих рисков должна быть четко налажена схема общения представителей поставщиков и заказчиков — проектный офис. Регламентирована переписка — ее формат и периодичность, для сокращения командировочных расходов есть смысл использовать ЭЦП. Должны быть назначены полномочные представители.

Обследование и написание ТЗ. При формировании требований в конкурсной документации заказчик не проводит обследования и поэтому использует готовые технические спецификации поставщиков ПО или описывает свои требования кратко, без указания выходных форм, поэтому, например, практика внедрения АИС "Госзакупки" предусматривает разработку нового технического задания после проведения обследования и анкетирования ключевых пользователей. При этом заказчик может быть лоялен к данному документу и не обратить в процессе его согласования внимания на важные моменты или предъявлять к поставщику завышенные требования по соблюдению ГОСТов, которые представляют собой устаревшие стандарты.

Важным моментом в составлении требований является документ, описывающий интерфейсы системы. На наш взгляд, единственный актуальный закон, регламентирующий этот этап — Федеральный закон от 27.07.2006 N 149-ФЗ "Об информации, информационных технологиях и о защите информации" (принят ГД ФС РФ 08.07.2006).

Разработка, тестирование и настройка. Несмотря на различные бюджеты, резервируемые регионами и муниципальными образованиями на внедрение АИС "Госзакупки", исполнитель должен включать в проектную группу аналитика с опытом успешного внедрения автоматизированной системы и архитектора, владеющего знаниями о структуре системы и ее версии.

Важной особенностью построения АИС "Госзакупки" является консолидация требований разных заказчиков-потребителей в одной версии системы и выбор оптимального решения. Создание разных версий системы приведет к увеличению используемых ресурсов для обновления системы в связи с изменением законодательства или апдейтом разных проектов. Не все заказчики понимают эту особенность и стараются максимально "дожать" поставщика для реализации своих пожеланий.

Для поставщика также важно организовать качественное тестирование системы на различных этапах ведения проекта, в том числе после загрузки базовых справочников и данных. Важным этапом тестирования является нагрузочное тестирование на устойчивость системы в процессе ее длительной эксплуатации.

Обучение. Оно должно проходить с использованием всех возможных средств — теоретических и практических занятий, тренингов, курсов, дистанционного обучения. Исполнитель должен предоставлять актуальную документацию и обучающий материал, написанный доступным языком (с учетом низкой компьютерной грамотности пользователей). Хорошей практикой стало обучение тьютеров (учителей) в составе отделов государственного и муниципального заказа и создание компетенции в области проведения обучения теоретическим и практическим знаниям. Хорошо проведенное обучение — залог успеха этапа опытной эксплуатации.

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

Для снижения рисков в ходе данного этапа должен быть своевременно принят и опубликован регламент работы с автоматизированной системой. В эксплуатационную документацию должны входить такие документы, как регламент использования системы, положение об эксплуатирующем подразделении, регламент по взаимодействию с исполнителем.

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

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

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

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

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

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

Юлия Обаляева
Источник: CNews