Comments 21
Прочитал документ. Это не стандарт, а ТЗ на модуль для какого-нибудь отраслевого ситуационного центра.
Нормальные информационные системы (а тем более ГИСы) в нашей стране создаются на основе ГОСТ 34. Наверно, новый стандарт должен основываться на определениях существующего стандарта? В частности в ГОСТ 34 определено понятие функция. Наверно и надо вводить понятие определение качества функции автоматизированной системы.
Опыт подсказывает, что прежде чем автоматизировать фукнцию (хорошо, назовем это сервис ПГУ), надо создать процесс, а это разработка нормативно-правовой базы, заканчивающейся как правило административным регламентом (ну тут вам виднее). Соответственно, первоначально идет мониторинг качества исполнения регламента, а уже потом он накладывается на мониторинг автоматизированной функции. А иначе получится как всегда с любыми государственными (не обязательно обладающими таким статусом) системами: мы создали и запустили софт по автоматизации в надежде что-то улучшить, но про тех, кто с этим должен работать, не подумали.
Добрый день!
На стандарт это точно не похоже, но лиха беда - начало. Пока не стало слишком поздно, рекомендую прочитать книгу Wil van der Aalst "Process Mining". Успехов! Тоже в Сбере проработал 12 лет...
Стандарты для ГИСов - это круто, конечно, но есть вопросы:
Как уже сказали выше - большинство ГИС разрабатывается по 34-му ГОСТу, как с ним быть? Отменить, как уже отменили РД-50?
Что делать с 676 ПП, которое тоже в определенной степени регламентирует процессы разработки ГИСов?
Что делать с самодеятельностью разных ОИВов, колхозящих собственные процессы разработки ГИСов? Вот, ближайший пример - Росстандарт, например : https://zakupki.gov.ru/epz/order/notice/ok504/view/common-info.html?regNumber=0173100009221000054
Ну, как я понял из предложенного документа, нет цели стандартизировать подход к созданию ГИС. Есть цель мониторинга качества предоставляемых услуг с помощью ЕПГУ (который сам является ГИС). По-хорошему вопрос его мониторинга должен ставиться как доработка. Но прежде доработки надо стандартизовать подход к измерению качества предоставляемых государством услуг в "твердом" виде, а не в электронном.
Не понимаю, почему предложенный документ назвали "стандартом".
Есть цель, чтобы бизнес мониторинг появился в ведомствах.
Если ведомство вывело сервис на портал Госуслуг - welcome подключиться к существующему бизнес мониторингу портала Госуслуг.
Если ведомство выводит сервисы не на портале Госуслуг (иные фронтальные поверхности, услуги в "твердом" виде) то используя принципы из Стандарта бизнес мониторинг рекомендуется реализовать на локальном уровне. В "твердом" виде мониторинг будет выглядеть весьма схожим образом. Доля отказов в определенном регионе зашкаливает - ну очевидно что это сигнал что надо разбираться вне зависимости от того, что заявление подано с портала Госуслуг или в "твердом" виде.
Почему назвали документ "Стандартом". Ну предложите как это назвать... "Методологические рекомендации"?
Если ведомство вывело сервис на портал Госуслуг - welcome подключиться к существующему бизнес мониторингу портала Госуслуг.
Если сервис выведен на ЕПГУ, как правило "под капотом" скрываются межведомственные запросы (иначе это был бы моментальный сервис, как проверка штрафов ГИБДД, когда информация берется только из одной конкретной ГИС). Вы хотите считать KPI ответственного за услугу ведомства (а потом и ставить цели по его оптимизации), при этом у этого ведомства нет никакого воздействия на смежные, откуда они получают информацию. На выходе будет саботаж)
Как это решать? Практически у любой государственной услуги есть административный регламент её предоставления. Изначально надо введенные вами понятия (в упрощенном виде) добавить в регламенты предоставления этих услуг. Но вы решаете задачи только минцифры... Можно провести аналитику регламентов всех услуг (начать хотя бы с тех, которые предоставляются на федеральном уровне и от ФОИВов).
И, наверно, стоит задуматься вот над чем. ЕПГУ - одна из разновидностей автоматизированной системы. Автоматизированная система представляет из себя набор функций. Для определения надежности у нас есть ГОСТ 24.701-86, в частности один из показателей надежности надежность реализации функций системы. Возможно, стоит использовать и остальные определения из стандарта.
P.S. документ не должен быть таким большим, его мало кто прочитает.
А для разработки и управлением требований советую посмотреть в сторону 3SL Cradle. Все станет намного проще.
Ниже размещен весь документ — пишите в комментариях, предлагайте, критикуйте.
Ну что ж, давайте предметно — о больном, о статусах (5.2): а вариант ошибок в принципе не рассматривается, или им статус не нужен? Вот у меня сейчас на Госуслугах висит пачка заявлений со статусом «Ошибка получения заявления ведомством». Это ошибка на чьей стороне? Кто за нее отвечает — портал или ОГВ? Угадай, пользователь. А каковы последствия ошибки? Расслабьтесь, вы уже все сделали, а мы будем пытаться передать заявление еще раз? Или ты давай, пользователь, как баран долбись в закрытую калитку?
И, чтобы два раза не вставать, когда на Госуслугах поменяется форма заявления на выдачу общегражданского паспорта, которая не соответствует нормативке МВД? МВД клянется, что все поправки отправило в Минцифру, Минцифра — что повесили на портал все согласно ТЗ. Никто не виноват.
На практике есть 3 варианта работы с порталом Госуслуг
Ведомство дает отказной статус по принципу произвольного заполнения руками сотрудника. Здесь очевидна проблема человеческого фактора. Конечному пользователю не всегда понятно что произошло и главное - что с этим делать.
Ведомство дает отказной статус по некой рекомендованной методике. Здесь в меньшей степени присутствует человеческий фактор. Тексты стандартизированы, рекомендация что делать выражена в четком виде.
Ведомство дает отказной статус, используя предзаполненный справочник по отказам. Человеческий актор почти исключен.
Наш бизнес мониторинг позволяет видеть ручные комментарии к статусам и там нам совместно с ведомствами много чего предстоит сделать...
Факт в том, что первый шаг начинается с осознания. Мониторинг системно показывает процесные изъяны процессов, с которыми сложно спорить.
Наша цель конечно из состояния 1. прийти в состояние 3.
Статус непринятия заявления ведомством мне знаком по личной практике, проблем с интерпертацией кто виноват и что делать лично у меня не возникало — все четко было расписано в том случае.
Заместителем Министра Минцифры
П - пафос
Это страшная статья, это не про людей и не для людей.
Это не про то, как проектировать такие системы, что в них включать, как определять алгоритм работы и её тестировать.
С статье про людей нет ничего, только одна сиротливая фраза "Одна из главных задач государства – упростить жизнь граждан и бизнеса, быстро и качественно предоставляя нужные им сервисы."
И ничего общего с тем, как проектируются и создаются формальные, информационные системы.
Статья на уровне начинающего HR.
Мне жаль, но у меня возникло и осталось такое мнение. Особенно после
"3.1. Регулярный мониторинг Сотрудники ОГВ и/или уполномоченной организации, предоставляющей сервис, должны осуществлять регулярный мониторинг показателей, реагировать на отставания от целевых значений и принимать меры по их устранению. В ОГВ и/или уполномоченной организации должны быть определены ответственные за предоставление сервиса:
• заместитель руководителя;
• руководитель подразделения;
• сотрудник подразделения.
В общем виде ответственность сотрудников представляется в виде таблицы: Ответственный сотрудник Ежедневный мониторинг Еженедельный мониторинг Ежемесячный мониторинг Ежеквартальный мониторинг Сотрудник подразделения • • • • Руководитель подразделения • • •"
Так и предствил себе вопрос начальника сотруднику
"ну что там у нас с услугами? Народ доволен?"
«Это страшная статья, это не про людей и не для людей. …»
Обидно конечно такое читать :( Не соглашусь.
Как показала практика, это все таки для людей.
Исторически на портале Госуслуг сервисы госуслуг выглядели как большой аналог бумажной анкеты. Работало по принципу запустили и забыли.
Что мы сделали? Процесно радикально изменили методологию и технологию оказания услуг - ввели атомарные экраны, сценарии, опросные квизы, многое другое и (!) технологически реализовали механизм, автоматически ставящий услугу на новую систему бизнес мониторинга (раньше вообще бизнес мониторинга никакого не было, лезли в эксплуатацию чтобы получить нужные данные по запросу).
Таким образом, услуги стало возможным централизованно единообразно мониторить по понятным и прозрачным показателям.
По каждой услуге был назначен ответственный, в обязанности которого входит смотреть на динамику базовых индикаторов, анализировать и непрерывно улучшать качество услуги (TQM - Total Quality Management).
Это работает, это доказанный эффективный инструмент на больших массовых процессах, это реализовано как единообразный универсальный механизм. То есть напрашивается необходимость этот подход тиражировать. Решили такие решения оформлять в виде Стандартов и предлагать использовать в Гос цифре.
"Про людей и для людей". В первом квартале прошлого года оценка NPS портала Госуслуг была чуть более 30%, сейчас выше 50%.
В этом большая заслуга выстраивания системы мониторинга и работы с качеством.
«И ничего общего с тем, как проектируются и создаются формальные, информационные системы.»
Все таки задача запускать не «формальные», а реально работающие, эффективные ГИСы.
Предположим ведомство решило запустить новый ГИС. В ведомстве работает конкретный специалист, который предполагается будет знаком со Стандартами. Тогда логично предположить, что такой специалист еще на этапе формирования требований к ГИСу будет закладывать заранее требования к системе бизнес мониторинга, чтобы видеть как работают процессы на ежедневных дэшбордах, анализировать и работать с качеством/инцидентами. По сути нормально управлять процессом.
Минцифры задает систему координат, ожидания что такие элементы как бизнес мониторинг должны иметь место быть при проектировании ГИСов.
Простыми словами - в ведомствах должны появиться ответственные, которые начнут по цифрам, а не по звездам понимать что происходит по сервисам, за которые они отвечают. Технически система мониторинга должна иметь место быть. Это программа минимум. И это оч сильно влияет на качество.
С формальной точки зрения, в 676 говорится про метод рекомендации Минцифры и отсмотр ТЗ от 100 млн руб.
А Вы, вместо эмоций, соплей и обид, прошли бы сами раз в эти госуслуги своими ногами без помощников и свиты и получили бы полное понимание того, что эти ваши "госуслуги" всего лишь декорация к тому самому кондовому ЖЭКу советских времен. ( как пример: передача данных поверки водосчетчика из "Жилищника" в "Мои документы", который платежки и шлет. Расстояние 500 м, но процесс занял у меня три дня хождения ногами и переноской бумаги с "мокрой(!!!)' печатью при том, что по стандарту в "Жилищнике" набивают текст руками в экселе, потом по почте отправляют в "Мои документы", там распечатывают и с бумаги вводят в ЭВМ. Строку с моей квартирой оператор пропустила просто ). И так почти в половине обращений. ( резидентное разрешение оплатить смог с Госуслуг только после личного анализа кода и писем в прокуратуру - ответ умиляет "один департамент не выгрузил данные другому департаменту")
То, что Вы озаботились единообразием пользовательских архитектур, это очень хорошо, но предложенный Вами текст ничего общего не имеет с проектированием формальных систем, совсем.
Наверно я сейчас начну тривиальные для некоторых вещи писать, но если не начать с определения предметной области толково и правильно, то программисты возьмут тот формализм, что есть ( тот самый живучий ЖЭК) и попытаются его как то впихнуть в ЭВМ.
И весь Ваш текст именно эту парадигму и поддерживает. И я не зря привел пассаж о контроле - Вы там что собираетесь контролировать? Начальник помощника контролирует ? А кто контролирует алгоритм работы? Если превышено запланированное время работы программы, то диалог начальника с сотрудником полностью бессмысленнен и бесполезен. Нужно анализировать алгоритм, данные, процедуру, архитектуру. Такое нарушение это ЧП в проектировании, а у Вас тут типа "ну что, сколько раз нарушили? Всего пяток? Ну бывает, работаете над собой, исправляйте"
Написал письмо по теме:
Госуслуги, уязвимость сессии, но ответа не получил.
Если у вас есть время на статьи, найдется минутка на ответ/толкнуть в бок своих коллег?
Зачем нужны стандарты для ГИСов: опыт Госуслуг