IT ManagerИТ в бизнесеЧто хочет бизнес

Шаблон для дружбы с госзаказчиком

Юлия Рузматова | 21.11.2019

Шаблон для дружбы с госзаказчиком

То, что с госзаказчиками лучше работать, чем нет, – понимает каждая ИТ-компания. Для крупных игроков ИТ-рынка госзаказ жизненно необходим. Он составляет существенную часть оборота и подразумевает проекты, которые имеют начало, но не имеют строгого окончания, поскольку цифровизация работы госорганов и модернизация оргпроцессов и ИТ-систем, обеспечивающих деятельность госучреждений – процесс априори бесконечный. Для средних и небольших фирм опыт выполнения госпроектов могут стать отличной базой для роста бизнеса и повышения его стабильности. Точно так же любая, хоть раз столкнувшаяся с участием в госпроекте ИТ-компания понимает, что более капризного и требовательного заказчика, чем госучреждение представить себе сложно. А потому вопрос, как упростить взаимодействие с госзаказчиком и сделать это не во вред, а на пользу проектам, является на сегодня почти таким же важным, как исторические «что делать?» и «кто виноват?» И еще один

Во что ввязываемся?

Во-первых, нужно учитывать масштабность проектов и их социальную значимость. Допустим, вы участвуете в автоматизации процессов, которые так или иначе затрагивают выплаты населению, прием заявлений или что-то подобное. В случае сбоя недовольство возникнет не только у заказчика, но и у граждан. А это грозит ИТ-разработчику репутационным ущербом, превышающим обычные штрафные санкции. Во-вторых, в любом госпроекте мы имеем дело с огромным количеством нормативных, правовых и иных актов, определяющих требования к разрабатываемым ИТ-решениям. Регламенты невозможно не учитывать, даже если они нередко противоречат друг другу. Третье, что нужно предусмотреть, – обилие разнообразных организационных процессов. И то, что можно было бы поставить на первое место, – жесткие требования к детальному оформлению результатов проекта и к пакету итоговой документации. Для госзаказчика работа ИТ-системы «на бумаге» (и ее соответствие всем другим бумагам) не менее, а в чем-то и более важна, нежели реальность, в которой живут обычные люди. Просто потому, что документооборот – это и есть реальность для госструктур. Вопрос в том, как в нее эффективно встроиться ИТ-подрядчику?

По ГОСТам или по Agile?

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

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

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

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

Шаг влево, шаг вправо – шаблон!

Шаг первый: анализ предметной области (НПА, интервью, обследование).

Шаг второй: декомпозиция предметной области:

  • выделение бизнес-функций системы;

  • разбивка бизнес-функций на бизнес-процессы;

  • выделение отдельных информационных объектов и потоков между ними.

Шаг третий: формирование бизнес-архитектуры.

Шаг четвертый: проектирование предметной области.

Варианты шаблонов:

  • реестр нормативных правовых актов;

  • реестр информационных объектов;

  • глоссарий;

  • реестр открытых вопросов;

  • постановка задачи на описание функции системы;

  • постановка задачи на описание информационного объекта системы (документа, справочника, отчета).

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

От каждого – по шаблону!

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

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

На основе полученных данных заполняется Реестр информационных объектов, где функции, бизнес-процессы и информационные объекты кодируются, проводится их трассировка по основным параметрам.

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

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

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

Выгоды шаблонизации

  • Выстроенные процессы производства во всех проектах (единообразно, по одним правилам).

  • Возможность ротации сотрудников между проектами без снижения результативности.

  • Сокращение трудозатрат.

  • Быстрая адаптация новых членов проектной команды.

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

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

 

Горячие темы: Бизнес в цифре

Журнал: Журнал IT-Manager [№ 11/2019], Подписка на журналы

ОТР

Об авторах

Юлия Рузматова

Юлия Рузматова

 начальник управления анализа и проектирования производственного департамента компании ОТР


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Компании сообщают

Мероприятия

24.01.2020 — 02.03.2020
Лучший ОЦО России и СНГ 2019

Radisson Collection Moscow

27.02.2020
IT в страховании

Отель Шератон Палас

24.03.2020 — 25.03.2020
ИТС регионам

Воронеж, Отель «Воронеж Mariott»

28.03.2020
Оранжевый океан

Москва