Привет, читатель!
Меня зовут Дмитрий Огуряев, я специалист в области массового розничного обслуживания. Большую часть жизни проработал в крупных розничных банках и последний год являюсь Заместителем Министра Минцифры, отвечающим за портал Госуслуг, а также за ряд иных направлений.
В силу своего опыта работы с разнородными процессами, большими данными, а также математического образования, сформировалось определенное видение, как помочь государственной цифровизации сделать существенный шаг вперед в своем развитии.
Начну с идеологии. Аналитическая геометрия началась с Декартовой системы координат. В любой области кажется логичным всем договориться о некой общей системе координат. Без стандартизации и прозрачной системы координат, хотя бы на уровне что такое хорошо и что такое плохо, невозможно строить большие розничные конвейеры.
В области государственной цифровизации сформированы верхнеуровневые цели (без бумаги, онлайн, без личных визитов, цифровой вход - цифровой выход и тд). Но как достичь этих целей? Из каких строительных материалов строить цифровой небоскреб? В этой статье как раз попытаюсь приблизить ответ на этот злободневный вопрос.
Здесь вспоминается стихотворение Маяковского «Что такое хорошо и что такое плохо».
Государственные информационные системы (ГИСы), которыми управляют всевозможные государственные органы, очень похожи между собой по функционалу и решаемым задачам.
Но при этом каждый раз изобретается велосипед в виде очередного ГИСа. Это плохо.
Беда в том, что проектируя велосипед, изобретатели не являются большими специалистами в такой узкой области как спицы от колес. Ну действительно, нельзя же быть большим специалистом сразу во всех деталях велосипеда. Кто ж знал, что их нужно было делать стальными, а не деревянными? Это плохо.
А теперь – что такое хорошо в моем понимании.
Существует профессиональная компетенция в определенных областях. В этих областях накоплен опыт, который разумно использовать.
Этот опыт буду дальше называть Стандартами.
Стандарты не позволят делать спицы для велосипедного колеса деревянными.
Стандарты устанавливают минимальные требования к определенной узкопрофильной области. Это гарантия не упасть ниже определенного уровня ожиданий. Лучше можно. Хуже планки, установленной Стандартами, нельзя.
Использование Стандартов – хорошо. Но их сейчас нет. Значит мы их будем создавать и внедрять.
Что такое стандарты для ГИСов?
Стандарт – это три составляющие:
1. Организационная
Регулирующие нормативные документы, кто и за что отвечает.
2. Бизнес архитектура
Типовые процессы, параметризация.
3. ИТ архитектура
Типовые ИТ решения.
Стандарт получается самодостаточным и полноценно покрывает узкую функциональную область.
Своей задачей видим сделать Стандарты такими, что даже неподготовленные люди могли прочесть и понять, что такое хорошо и что такое плохо.
Как запустить Стандарты?
Есть Президиум Правительственной комиссии, при котором есть Архитектурный совет. Данный совет будет рассматривать и рекомендовать к применению Стандарты.
Одна голова хорошо – две лучше, а несколько тысяч голов еще лучше. Любой из Вас может сделать свой вклад в общее дело цифровизации государственной инфраструктуры. К данном статье приложен драфт Стандарта Бизнес мониторинга. Это будет первым документом, вынесенным на Архитектурный совет. Документ составлен по реальному опыту бизнес мониторинга портала Госуслуг, который позволил в короткое время существенно поднять качество и сделать процесс оказания госуслуг управляемым.
Ниже размещен весь документ - пишите в комментариях, предлагайте, критикуйте.
Вкратце про опыт Бизнес мониторинга портала Госуслуг
Ранее, чтобы понять, что происходит с сервисом на портале Госуслуг, приходилось запрашивать эксплуатацию, которая на ходу генерировала скрипты запросов в боевую базу. Это было небыстро и отвлекало дефицитные ресурсы эксплуатации.
Правильным решением было создание Аналитического кластера, который хранит базовые данные по услугам и позволяет отслеживать ключевые индикаторы в BI решении на основе open source компонентов. Обновление осуществляется 4 раза в сутки, что для бизнес мониторинга более чем достаточно.
Для онлайн мониторинга используются средства технического мониторинга, но это уже совсем другая история (отдельный Стандарт).
На портале Госуслуг в прошлом году были внедрены новые формы госуслуг, работающие по принципу Лего. При выводе каждой новой услуги в новых формах автоматически происходит добавление такой услуги в бизнес мониторинг.
Это критически важно для новых услуг, которые на этапе запуска нуждаются в плотном контроле на период отладки. Сейчас все новые услуги покрыты бизнес мониторингом, за которым пристально следят выделенные специалисты.
Кто это использует?
Используют прежде всего CJM (Customer Journey Manager) РТЛабс. Каждый сервис закреплен за отдельным CJM, который должен регулярно мониторить свои сервисы, анализировать тренды, предлагать улучшения как на стороне портала Госуслуг, так и на стороне смежников.
Часто бизнес мониторинг по аномальным отклонениям помогает ловить нетривиальные ошибки.
Помимо специалистов CJM бизнес мониторинг доступен сотрудникам профильных ведомств, которые непосредственно отвечают за оказание услуги. Это помогает быть в едином информационном поле и общаться на одном языке.
Любая система предполагает контроль – по каждому, имеющему доступ к бизнес мониторингу, есть отчет об активности в системе, так что уклониться от анализа подответственных сервисов затруднительно. Но данный контроль на текущий момент является избыточным – мониторинг достаточно популярен и активно используется как основной инструмент просмотра статистики и трендов по индикаторам. Сознательность имеет место быть.
Какие еще Стандарты будут в ближайшем будущем?
В целом, до конца года планируется утвердить около 10 Стандартов. По всем ним планируем выкладывать короткие статьи на Хабре для критики и предложений.
Следующими стандартами будут Стандарты Уведомлений и Цифрового ассистента (чат бот).
Помогут ли Стандарты? На сколько они полезны?
Я почти 10 лет проработал в Сбербанке. Пришел в Сберкассу в 2011 году, уходил из технологического лидера, ставшего лидирующей экосистемой страны. В начале пути в Сберкассе было 17 территориальных банков и порядка 80 так называемых ОСБов (области). Не было единой системы, не было единой системы координат, не было базовой стандартизации.
Тогда со всей страны собрали всех руководителей (несколько тысяч человек), вывезли в гостиницу на несколько дней, где несколько дней в большом зале зачитывали и обсуждали стандарты. Хорошо помню пламенную речь одного оратора про «счастливых роботов», после которой половина зала аплодировала…
Так вот, те кто аплодировали в скором времени либо покинули Сбер, либо сильно поменяли свое мнение. Потому что большие системы не могут работать без наведения порядка. Даже не лучший стандарт в любой области лучше, чем анархия. Как показала жизнь – это работает.
Стандарт Бизнес мониторинга (драфт)
Иллюстрации: Михаил Голев
Комментарии (21)
PereslavlFoto
29.09.2021 13:40Когда портал Госуслуг будет переведён на свободную (!) лицензию Creative Commons?
ZhilkinSerg
29.09.2021 18:56Она же не очень хорошо для кода подходит.
PereslavlFoto
29.09.2021 19:33+1Конечно, речь не про код, а про контент.
Dmitry_Oguryaev Автор
01.10.2021 13:07Мы думаем про это.
Для начала, как минимум, гос органы смогут переиспользовать наши наработки/подходы.
WizardryIB
29.09.2021 14:41+1Добрый день!
На стандарт это точно не похоже, но лиха беда - начало. Пока не стало слишком поздно, рекомендую прочитать книгу Wil van der Aalst "Process Mining". Успехов! Тоже в Сбере проработал 12 лет...
a_nick
29.09.2021 15:13Стандарты для ГИСов - это круто, конечно, но есть вопросы:
Как уже сказали выше - большинство ГИС разрабатывается по 34-му ГОСТу, как с ним быть? Отменить, как уже отменили РД-50?
Что делать с 676 ПП, которое тоже в определенной степени регламентирует процессы разработки ГИСов?
Что делать с самодеятельностью разных ОИВов, колхозящих собственные процессы разработки ГИСов? Вот, ближайший пример - Росстандарт, например : https://zakupki.gov.ru/epz/order/notice/ok504/view/common-info.html?regNumber=0173100009221000054
vvpoloskin
29.09.2021 17:30Ну, как я понял из предложенного документа, нет цели стандартизировать подход к созданию ГИС. Есть цель мониторинга качества предоставляемых услуг с помощью ЕПГУ (который сам является ГИС). По-хорошему вопрос его мониторинга должен ставиться как доработка. Но прежде доработки надо стандартизовать подход к измерению качества предоставляемых государством услуг в "твердом" виде, а не в электронном.
Не понимаю, почему предложенный документ назвали "стандартом".
Dmitry_Oguryaev Автор
01.10.2021 13:04-1Есть цель, чтобы бизнес мониторинг появился в ведомствах.
Если ведомство вывело сервис на портал Госуслуг - welcome подключиться к существующему бизнес мониторингу портала Госуслуг.
Если ведомство выводит сервисы не на портале Госуслуг (иные фронтальные поверхности, услуги в "твердом" виде) то используя принципы из Стандарта бизнес мониторинг рекомендуется реализовать на локальном уровне. В "твердом" виде мониторинг будет выглядеть весьма схожим образом. Доля отказов в определенном регионе зашкаливает - ну очевидно что это сигнал что надо разбираться вне зависимости от того, что заявление подано с портала Госуслуг или в "твердом" виде.
Почему назвали документ "Стандартом". Ну предложите как это назвать... "Методологические рекомендации"?
vvpoloskin
01.10.2021 17:16Если ведомство вывело сервис на портал Госуслуг - welcome подключиться к существующему бизнес мониторингу портала Госуслуг.
Если сервис выведен на ЕПГУ, как правило "под капотом" скрываются межведомственные запросы (иначе это был бы моментальный сервис, как проверка штрафов ГИБДД, когда информация берется только из одной конкретной ГИС). Вы хотите считать KPI ответственного за услугу ведомства (а потом и ставить цели по его оптимизации), при этом у этого ведомства нет никакого воздействия на смежные, откуда они получают информацию. На выходе будет саботаж)
Как это решать? Практически у любой государственной услуги есть административный регламент её предоставления. Изначально надо введенные вами понятия (в упрощенном виде) добавить в регламенты предоставления этих услуг. Но вы решаете задачи только минцифры... Можно провести аналитику регламентов всех услуг (начать хотя бы с тех, которые предоставляются на федеральном уровне и от ФОИВов).
И, наверно, стоит задуматься вот над чем. ЕПГУ - одна из разновидностей автоматизированной системы. Автоматизированная система представляет из себя набор функций. Для определения надежности у нас есть ГОСТ 24.701-86, в частности один из показателей надежности надежность реализации функций системы. Возможно, стоит использовать и остальные определения из стандарта.
P.S. документ не должен быть таким большим, его мало кто прочитает.
WizardryIB
29.09.2021 15:27+1А для разработки и управлением требований советую посмотреть в сторону 3SL Cradle. Все станет намного проще.
ifap
29.09.2021 18:15+3Ниже размещен весь документ — пишите в комментариях, предлагайте, критикуйте.
Ну что ж, давайте предметно — о больном, о статусах (5.2): а вариант ошибок в принципе не рассматривается, или им статус не нужен? Вот у меня сейчас на Госуслугах висит пачка заявлений со статусом «Ошибка получения заявления ведомством». Это ошибка на чьей стороне? Кто за нее отвечает — портал или ОГВ? Угадай, пользователь. А каковы последствия ошибки? Расслабьтесь, вы уже все сделали, а мы будем пытаться передать заявление еще раз? Или ты давай, пользователь, как баран долбись в закрытую калитку?
И, чтобы два раза не вставать, когда на Госуслугах поменяется форма заявления на выдачу общегражданского паспорта, которая не соответствует нормативке МВД? МВД клянется, что все поправки отправило в Минцифру, Минцифра — что повесили на портал все согласно ТЗ. Никто не виноват.Dmitry_Oguryaev Автор
01.10.2021 13:18-1На практике есть 3 варианта работы с порталом Госуслуг
Ведомство дает отказной статус по принципу произвольного заполнения руками сотрудника. Здесь очевидна проблема человеческого фактора. Конечному пользователю не всегда понятно что произошло и главное - что с этим делать.
Ведомство дает отказной статус по некой рекомендованной методике. Здесь в меньшей степени присутствует человеческий фактор. Тексты стандартизированы, рекомендация что делать выражена в четком виде.
Ведомство дает отказной статус, используя предзаполненный справочник по отказам. Человеческий актор почти исключен.
Наш бизнес мониторинг позволяет видеть ручные комментарии к статусам и там нам совместно с ведомствами много чего предстоит сделать...
Факт в том, что первый шаг начинается с осознания. Мониторинг системно показывает процесные изъяны процессов, с которыми сложно спорить.
Наша цель конечно из состояния 1. прийти в состояние 3.
ifap
01.10.2021 13:50+1Вы точно прочли мой комментарий? «Ошибка получения заявления ведомством» — это технический сбой, AFAIK такое уже больше двух недель происходит на стороне прокуратуры, поддержка Госуслуг в курсе но ничего поделать на своей стороне не может. Но это я узнаю «из переписки», а не из статуса.
Статус непринятия заявления ведомством мне знаком по личной практике, проблем с интерпертацией кто виноват и что делать лично у меня не возникало — все четко было расписано в том случае.
kompilainenn2
29.09.2021 18:57+2Заместителем Министра Минцифры
П - пафос
Dmitry_Oguryaev Автор
01.10.2021 12:52-1Пафос - это красные ленточки перерезать, да по форумам себя хвалить.
В Минцифры нет пафоса.
ChePeter
29.09.2021 19:45+2Это страшная статья, это не про людей и не для людей.
Это не про то, как проектировать такие системы, что в них включать, как определять алгоритм работы и её тестировать.
С статье про людей нет ничего, только одна сиротливая фраза "Одна из главных задач государства – упростить жизнь граждан и бизнеса, быстро и качественно предоставляя нужные им сервисы."
И ничего общего с тем, как проектируются и создаются формальные, информационные системы.
Статья на уровне начинающего HR.
Мне жаль, но у меня возникло и осталось такое мнение. Особенно после
"3.1. Регулярный мониторинг Сотрудники ОГВ и/или уполномоченной организации, предоставляющей сервис, должны осуществлять регулярный мониторинг показателей, реагировать на отставания от целевых значений и принимать меры по их устранению. В ОГВ и/или уполномоченной организации должны быть определены ответственные за предоставление сервиса:
• заместитель руководителя;
• руководитель подразделения;
• сотрудник подразделения.
В общем виде ответственность сотрудников представляется в виде таблицы: Ответственный сотрудник Ежедневный мониторинг Еженедельный мониторинг Ежемесячный мониторинг Ежеквартальный мониторинг Сотрудник подразделения • • • • Руководитель подразделения • • •"
Так и предствил себе вопрос начальника сотруднику
"ну что там у нас с услугами? Народ доволен?"
Dmitry_Oguryaev Автор
01.10.2021 12:47«Это страшная статья, это не про людей и не для людей. …»
Обидно конечно такое читать :( Не соглашусь.
Как показала практика, это все таки для людей.
Исторически на портале Госуслуг сервисы госуслуг выглядели как большой аналог бумажной анкеты. Работало по принципу запустили и забыли.
Что мы сделали? Процесно радикально изменили методологию и технологию оказания услуг - ввели атомарные экраны, сценарии, опросные квизы, многое другое и (!) технологически реализовали механизм, автоматически ставящий услугу на новую систему бизнес мониторинга (раньше вообще бизнес мониторинга никакого не было, лезли в эксплуатацию чтобы получить нужные данные по запросу).
Таким образом, услуги стало возможным централизованно единообразно мониторить по понятным и прозрачным показателям.
По каждой услуге был назначен ответственный, в обязанности которого входит смотреть на динамику базовых индикаторов, анализировать и непрерывно улучшать качество услуги (TQM - Total Quality Management).
Это работает, это доказанный эффективный инструмент на больших массовых процессах, это реализовано как единообразный универсальный механизм. То есть напрашивается необходимость этот подход тиражировать. Решили такие решения оформлять в виде Стандартов и предлагать использовать в Гос цифре.
"Про людей и для людей". В первом квартале прошлого года оценка NPS портала Госуслуг была чуть более 30%, сейчас выше 50%.
В этом большая заслуга выстраивания системы мониторинга и работы с качеством.
«И ничего общего с тем, как проектируются и создаются формальные, информационные системы.»
Все таки задача запускать не «формальные», а реально работающие, эффективные ГИСы.
Предположим ведомство решило запустить новый ГИС. В ведомстве работает конкретный специалист, который предполагается будет знаком со Стандартами. Тогда логично предположить, что такой специалист еще на этапе формирования требований к ГИСу будет закладывать заранее требования к системе бизнес мониторинга, чтобы видеть как работают процессы на ежедневных дэшбордах, анализировать и работать с качеством/инцидентами. По сути нормально управлять процессом.
Минцифры задает систему координат, ожидания что такие элементы как бизнес мониторинг должны иметь место быть при проектировании ГИСов.
Простыми словами - в ведомствах должны появиться ответственные, которые начнут по цифрам, а не по звездам понимать что происходит по сервисам, за которые они отвечают. Технически система мониторинга должна иметь место быть. Это программа минимум. И это оч сильно влияет на качество.
С формальной точки зрения, в 676 говорится про метод рекомендации Минцифры и отсмотр ТЗ от 100 млн руб.
ChePeter
01.10.2021 13:51А Вы, вместо эмоций, соплей и обид, прошли бы сами раз в эти госуслуги своими ногами без помощников и свиты и получили бы полное понимание того, что эти ваши "госуслуги" всего лишь декорация к тому самому кондовому ЖЭКу советских времен. ( как пример: передача данных поверки водосчетчика из "Жилищника" в "Мои документы", который платежки и шлет. Расстояние 500 м, но процесс занял у меня три дня хождения ногами и переноской бумаги с "мокрой(!!!)' печатью при том, что по стандарту в "Жилищнике" набивают текст руками в экселе, потом по почте отправляют в "Мои документы", там распечатывают и с бумаги вводят в ЭВМ. Строку с моей квартирой оператор пропустила просто ). И так почти в половине обращений. ( резидентное разрешение оплатить смог с Госуслуг только после личного анализа кода и писем в прокуратуру - ответ умиляет "один департамент не выгрузил данные другому департаменту")
То, что Вы озаботились единообразием пользовательских архитектур, это очень хорошо, но предложенный Вами текст ничего общего не имеет с проектированием формальных систем, совсем.
Наверно я сейчас начну тривиальные для некоторых вещи писать, но если не начать с определения предметной области толково и правильно, то программисты возьмут тот формализм, что есть ( тот самый живучий ЖЭК) и попытаются его как то впихнуть в ЭВМ.
И весь Ваш текст именно эту парадигму и поддерживает. И я не зря привел пассаж о контроле - Вы там что собираетесь контролировать? Начальник помощника контролирует ? А кто контролирует алгоритм работы? Если превышено запланированное время работы программы, то диалог начальника с сотрудником полностью бессмысленнен и бесполезен. Нужно анализировать алгоритм, данные, процедуру, архитектуру. Такое нарушение это ЧП в проектировании, а у Вас тут типа "ну что, сколько раз нарушили? Всего пяток? Ну бывает, работаете над собой, исправляйте"
vvpoloskin
01.10.2021 17:27Какой-то странный у вас пассаж. Вам показывают методические рекомендации, вы их воспринимаете как ТЗ в свою сторону. Призываете откинуть эмоции, в то же время сами разводите сопли из-за своей квитанции.
Проблемы есть, но они как правило носят организационный характер, а не технический.
ne555
30.09.2021 08:45+1Написал письмо по теме:
Госуслуги, уязвимость сессии, но ответа не получил.
Если у вас есть время на статьи, найдется минутка на ответ/толкнуть в бок своих коллег?
vvpoloskin
Прочитал документ. Это не стандарт, а ТЗ на модуль для какого-нибудь отраслевого ситуационного центра.
Нормальные информационные системы (а тем более ГИСы) в нашей стране создаются на основе ГОСТ 34. Наверно, новый стандарт должен основываться на определениях существующего стандарта? В частности в ГОСТ 34 определено понятие функция. Наверно и надо вводить понятие определение качества функции автоматизированной системы.
Опыт подсказывает, что прежде чем автоматизировать фукнцию (хорошо, назовем это сервис ПГУ), надо создать процесс, а это разработка нормативно-правовой базы, заканчивающейся как правило административным регламентом (ну тут вам виднее). Соответственно, первоначально идет мониторинг качества исполнения регламента, а уже потом он накладывается на мониторинг автоматизированной функции. А иначе получится как всегда с любыми государственными (не обязательно обладающими таким статусом) системами: мы создали и запустили софт по автоматизации в надежде что-то улучшить, но про тех, кто с этим должен работать, не подумали.