Импортозамещение по плану. Масштабная цифровизация в Правительстве Вологодской области

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

Подготовка рабочей группы.

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

Подходы к обследованию и проектированию.

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

1. Организуем от 3 до 5 итераций обследования с конкретной рабочей группой по процессу.
2. Первично собираем информацию по бизнес-процессам и актуальные требования.
3. Проектируем интерфейсы на макапах в Figma и схемы в Visio.
4. На следующей итерации – представляем результаты рабочей группе и уточняем требования.
5. После завершения обследования и протоколирования всех решений рабочей группы, оформляем процесс в проектном решении.

Основные плюсы такого подхода:

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

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

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

Подготовка мигратора и требований к объему переносимых данных.

Немаловажным условием для успеха проекта было донесение до заказчика, что весь объем исторической информации из Directum 5 не будет мигрирован. Более того – это и не нужно. Было принято решение о минимально необходимом объеме данных, для переноса. То есть только тех данных, которые действительно нужны в новой системе и отсутствие их там повлечет негативные последствия. По итогу было принято решение о переносе:

1. Документов в работе, поручения по которым пока не выполнены.
2. Документов, пришедших по МЭДО. Так как для ответов на них требуются физические связки в новой системе.
3. Записи справочников НСИ только по актуальным процессам, с исключением дублирования записей.
4. Поручений в работе в виде справочника исторических поручений. Основная цель – дать возможность пользователю быстро стартовать созданное поручение в Directum RX, не заполняя его снова. Для этого требовалось перенести метаданные из Directum 5 и связанные документы.

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

Изменение подходов к проведению тестовой эксплуатации.

Для повышения эффективности работ в период тестовой эксплуатации были предложены следующие изменения процесса:

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

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

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

2. Тестовая эксплуатация была разделена на два этапа.

• первичный – для тестирования разработанного по ПР функционала;
• вторичный – для приемки исправлений, зафиксированных на первом этапе.

Первичный этап проходил очно, с участием консультантов СТАРКОВ Групп на территории заказчика. Был организован учебный класс, с возможностью удаленного подключения сотрудников из дома, а также организованы выходы на места к сотрудникам, которые по каким-либо причинам не могли покинуть рабочее место.

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

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

Обучение пользователей.

Очень ответственный и зачастую недооцениваемый этап работ – это обучение. Перед командой стояла достаточно сложная задача – обучить 2000 пользователей, порядка 200 делопроизводителей, не менее 50 руководителей высшего звена и их приемные, порядка 70 ОМСУ. Весь объем работ необходимо было выполнить в 2-х недельный период, с учетом того, что руководители, приемные и делопроизводители должны проходить обучение очно.

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

• Создали сценарий для обучения пользователей основному функционалу в RX и базовым процессам, которые свойственны для роли «Пользователь». Согласовали сценарий с Заказчиком;
• Записали 50-минутный видеоролик с озвучкой и пояснениями о работе в системе;
• Распределили всех пользователей по группам (спасибо заказчику – помогли с этой нелегкой задачей). Получилось порядка 20 групп по 100 человек (максимальная емкость конференции);
• Организовали по два вебинара в день в течение 2-х недель для организованных групп. Т.е. пользователи смотрели записанный ролик в удаленном формате. В живую это никак не отличалось от варианта, когда бы консультант лично читал сценарий и нажимал кнопки;
• На каждом вебинаре дежурил один консультант СТАРКОВ Групп и администратор заказчика. Был организован чат, в котором обучаемые могли задать свои вопросы, на которые получали ответ онлайн;
• Вебинары записывались и далее сохранялись в облаке. Всем участникам вебинара предоставлялась ссылка на запись после мероприятия.

По началу подход с вебинарами вызывал сомнения и успешность его была под вопросом. В последствии, по итогам выделили неоспоримые плюсы:

1. Пользователи не выходят куда-то вовне и не теряют времени на дорогу до места проведения обучения.
2. Трудоемкость на подготовку и проведение подобного масштабного обучения значительно снижена. Фактически она равняется 40 часам консультанта на вебинарах и примерно столько же на подготовку ролика.
3. Вся история, в том числе вопросы, задаваемые во время вебинара, сохранена. Каждый записанный вебинар может быть пересмотрен заново.
4. В целом, так как план обучения один и тот же, консультанту нет необходимости читать «вживую» одно и тоже 20 раз подряд.
5. Сам ролик к вебинару – это уже готовая интерактивная инструкция, которую можно использовать в будущем.

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

Аттестация.

Требование к проведению аттестации всех пользователей сформулировал сам заказчик. Здесь спасибо опыту коллег из Тюмени, так как данное мероприятие «подсмотрено» оттуда. Заказчик на уровне заместителя губернатора смог согласовать требования к обязательному прохождению аттестации всеми пользователями системы. Непрохождение аттестации автоматически отменяет оказание консультаций пользователю по телефону во время проведения опытно-промышленной эксплуатации. Фактически «убиваем 2 зайцев»: аттестованные пользователи становятся более компетентны, так как не выучив материал аттестацию не пройдешь; снижается нагрузка на службу поддержки, так как есть формальный признак отказа в консультации ввиду отсутствия отметки об аттестации.

Для подготовки к аттестации были проведены следующие мероприятия:

1. Разработаны интерактивные обучающие ролики по каждому модулю и процессу (по ролям). Каждый ролик лаконичен и не занимает более 15 минут.
2. Также разработана пользовательская документация – инструкции по процессам. Все инструкции разбиты по процессам и ролям в каждом из них. Сами инструкции реализованы максимально просто – в виде презентаций с минимумом текстовой информации и максимально визуализирующими процесс работы.
3. Заказчик на общекорпоративном ресурсе для проведения обучений (внутренняя система обучения) реализовал структуру для хранения всей необходимой учебной информации и дал к ней доступ всем сотрудникам.
4. Совместно с заказчиком консультанты СТАРКОВ Групп разработали тесты по каждому автоматизированному процессу для проверки знаний сотрудников. В тестах сгенерированы правильные и неправильные ответы. Заказчик организовал возможность прохождения тестов для всех пользователей, с фиксацией статистики и проходными баллами. Вся статистика предоставлена руководителям подразделений пользователей, а также в службу поддержки.

Особенности миграции и организация процесса перехода.

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

• подготовлены чек-листы настроек системы после миграции;
• подготовлены чек-листы проверок и тестирования работоспособности системы после миграции;
• проведены несколько итераций тестовых миграций на тестовом контуре с использованием мигратора, адаптированного под требования заказчика;
• подготовлен детальный почасовой план-график проведения миграции, распределены роли для каждого сотрудника и определена зона ответственности. Работы организованы с учетом комфортного времени выполнения в рамках часовых поясов (команда распределенная);
• подготовлены интеграционные механизмы для перехода с задач из Directum 5 на фоновые процессы в Directum RX с учетом отката;
• определен путь отката в случае неудачи.

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

Привлечение инженеров поддержки к проведению опытно-промышленной эксплуатации.

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

При реализации проекта по переходу ПВО на Directum RX было принято решение о включении в состав проектной команды 2-х инженеров СПС уже на этапе обучения пользователей. Инженеры совместно с рядовыми сотрудниками заказчика учились работе в системе и постигали её особенности. Далее привлекались уже как «дополнительные руки» на этап миграции. В конце концов, стали полноправными участниками команды на этап ОПЭ. Таким образом проработав вместе с командой внедрения инженерам удалось «войти» в проект, а команде внедрения «выйти» и передать знания инженерам.

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

Модуль «Правовые акты» и «Локальные правовые акты»

Автоматизирован процесс работы с региональными правовыми актами и правовыми актами органов исполнительной власти от создания проекта до публикации его на региональный и федеральный порталы правовой информации. Учтена этапность и специфика требований заказчика, организована выгрузка проектов правовых актов на региональный портал для проведения экспертиз. Работа с правовыми актами реализована в рамках регламентов согласования для последующей удобной настройки администраторами системы в случае изменений в регламенте работы Правительства.  Дополнительно реализован функционал по включению проектов документов в повестку заседания Правительства с формированием отчетной формы «Повестка заседания» и принятия проекта правового акта с помощью листа опроса. Организована работа руководителей по согласованию в МП Solo.

Рисунок 1. Обложка модуля Правовые акты

 Рисунок 2. Задача на согласование по регламенту нормативного правового акта

Модуль «Согласование» и «Автодоставка»

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

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

 Рисунок 3.Задание на рассмотрение руководителем

Между системой подведомственных учреждений области (СЭД БУ) и автоматизированной системой электронного документооборота органов исполнительной власти организован механизм «сквозного» согласования проектов исходящих писем с регистрацией в двух системах в зависимости от подписанта. Процесс инициируется на стороне подведомственной системы. Вся информация о согласовании отображается в специальном справочнике.

Рисунок 4. Справочник «Сквозные процессы»

Доработки в «Поручениях»

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

Рисунок 5. Задача на исполнение поручения

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

Рисунок 6. Справочник «Поручения»

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

Рисунок 7. Задание на приемку работ по поручению

При выдаче поручений руководителями было реализовано требование по утверждению проектов поручений не только в рамках задачи на рассмотрение документа, но и при выдаче подчиненных поручений. Создана кастомная задача «Утверждение поручений», в том числе доступная в мобильном приложении «Solo».

Рисунок 8. Задание на утверждение проекта резолюции по подчиненному поручению

Межсистемная интеграция по формату МЭДО, ГАС

При переходе на Directum RX было необходимо учесть, что между системой электронного документооборота для подведомственных учреждений (СЭД БУ) и основной системой органов исполнительной власти, работающей на Directum 5, функционировал модуль «Региональный документооборот», обеспечивающий юридически-значимый обмен служебной корреспонденцией между органами исполнительной государственной власти Вологодской области и подведомственными учреждениями по формату МЭДО (2.6-2.7).

При переходе на Directum RX было принято решение использовать решение Интеграция с МЭДО, доработанное в соответствии с приказом Министерства цифрового развития, связи и массовых коммуникаций РФ от 29.06.2022 г №500/82 «Об утверждении Технических требований к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота».

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

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

Рисунок 9 Обложка модуля «Интеграция»

Интеграция с автономным модулем редактирования «Мой офис»

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

Рисунок 10. Вид шаблона документа в тестовом редакторе «Мой офис»

Доработки мобильных решений

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

Специально для проекта компанией Directum был разработан отдельный модуль «Мобильные решения», позволяющий администраторам создавать списки папок, отображаемых у конкретного пользователя в мобильном приложении Solo.

Рисунок 11. Обложка модуля мобильные решения

Рисунок 12. Справочник «Настройки видимых папок»

Рисунок 13. Отображение папок в мобильном приложении Solo

Кастомная «Простая задача»

Пользователи при работе с базовыми процессами (поручения, согласование) активно пользуются функционалом подзадач. Основное требование к функционалу подзадач от заказчика – возможность указывать в подзадачах только сотрудников, работающих в АСЭД. Вся орг. структура органов власти ведется в АСЭД, далее выполняется синхронизация в подведомственную систему СЭД БУ.

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

Рисунок 14. Кастомная простая задача. Выбор исполнителей

Рисунок 15. Задание на исполнение по простой задаче

Автоочистка папок пользователей

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

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

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

Созданный механизм позволяет удалять задания из конкретной папки после выполнения в соответствии с настройками. Настройки задаются в справочнике: указывается количество дней после выполнения задания. За выполнение очистки отвечает фоновый процесс.

Рисунок 16. Справочник «Настройка автоочистки папок»

Поиск по ключевым словам

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

Рисунок 17. Пример входящего письма ограниченного доступа

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

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

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

Рисунок 18. Справочник «Настройка полнотекстового поиска документов ДСП»

Использование механизмов Service Kit

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

Такие инструменты были реализованы в решении Service Kit, ранее описанном в заявке Awards .

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