Институт проблем правоприменения

eulogo

  • Главная
  • Хроника
  • О нас
  • Направления исследований
  • Продукты
  • Контакты
  • RU
  • EN

Алексей Кнорре, Иван Бегтин. Ведомости, Extra Jus: Интерфейс не той системы

Алексей Кнорре, Иван Бегтин. Ведомости, Extra Jus: Интерфейс ... Image 1

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

 IT-эксперт Иван Бегтин и социолог Алексей Кнорре о разработке государственных информационных систем.

Компьютер и набор программ на нем – неотъемлемая часть рабочего места практически в любой современной организации. Это справедливо и для всех структур государственного организма. В реестре федеральных государственных информационных систем (ГИС) до передачи его из Роскомнадзора в Министерство связи и массовых коммуникаций (на начало 2016 г.) находилось 339 ГИСа, большинство из которых были введены в 2011 г.

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

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

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

Такие проблемы возникают из-за того, как обычно принято разрабатывать автоматизированные системы для ведомств в России:

– выделить деньги;

– написать техническое задание (в котором будет много про системную архитектуру и аппаратное обеспечение, но почти ничего про нагрузочное тестирование, изучение требований пользователей и апробацию удобства интерфейса);

– объявить тендер на разработку системы и отдать его на исполнение сторонней IT-компании.

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

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

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

Можно предложить по крайней мере два метода борьбы с такими проблемами. Первый – не отдавать разработку автоматизированных систем сторонним компаниям, а формировать отдел разработки внутри ведомства (так называемый inhouse software development), при котором программисты сфокусированы на одном проекте, по умолчанию заинтересованы в его успешном внедрении и могут быстро и постоянно реагировать на возникающие проблемы и потребности пользователей. По такому пути идут, например, правительство Великобритании, которое много лет назад создало команду Alpha Team для переработки государственного портала gov.uk, а также США, создавшие команду 18F, которая последовательно переделывают один за другим государственные порталы, адаптируя их под нужды граждан.

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

Источник: Ведомости, Extra Jus.

Меню раздела

  • Анонсы
  • Новости
  • Публикации сотрудников в СМИ
  • Комментарии в СМИ
  • СМИ об ИПП
  • Мероприятия ИПП
Атлас прецедента
Аналитический отчет «Контроль и надзор»
Российская база бухгалтерской отчетности

Вакансии

Все наши образовательные проекты

Тэги

  • судебные решения
  • социология права
  • правоприменение
  • статистика
  • реформа
  • реформа полиции
  • открытость
  • уголовное следствие
  • криминальная статистика
  • арбитраж
  • сравнительное правоведение
  • компаративистика
  • профессия
  • эффективность
  • экономическая преступность
  • уголовный процесс
  • прокуратура
  • закон
  • судья
  • правоохранительные органы
  • бизнес
  • оппозиция
  • отчетность
  • экономика
  • общественная дискуссия
  • реформа судебной системы
  • изменения в законодательстве
  • законодательная активность
  • адвокат
  • Интернет
© 2009-2025 «Институт проблем правоприменения»
Тел. (812) 386 76 12
E-mail: ipp@eu.spb.ru
Телеграм

Наш имидж-пакет Вы можете скачать здесь

Политика АНООВО «ЕУСПб» в отношении обработки персональных данных