Мобильность в плюс. Внедрение мобильного приложения на проекте с историей

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

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

Оцениваем применимость и доработки

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

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

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

1. Рассмотрение входящего документа, вынесение резолюции по нему.
2. Создание подчиненных поручений и выполнение поручений вышестоящего руководителя.
3. Согласование документов (договоров, писем, служебных записок).

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

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

Работа с типовыми маршрутами

Рассмотрение документов

С этой группой блоков вопросов не возникло, так как функционал DIRECTUM Solo максимально адаптирован для вынесения резолюции и создания поручений. Здесь прикладная разработка осталась без изменений.

Исполнение поручений

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

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

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

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

Согласование документов

Наверное, это был наиболее трудоемкий блок работ. Условно все блоки согласования можно было разделить на два вида:

Согласование документа непосредственным руководителем инициатора задачи

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

Как я уже писал выше, на момент внедрения Solo для iOS не поддерживало запрос параметров, поэтому было принято решение, что при выполнении задания на мобильном клиенте параметры запрашиваться не будут. Для этого использовалась функция IsNOMADRuntimeContext. Если задание выполнялось в мобильном приложении, то функция возвращала значение true, при выполнении из desktop – значение false. В случае, если возвращалось значение true, запрос параметров не выполнялся. При необходимости корректировки списка согласующих руководитель, выполняющий задание в мобильном приложении, возвращал задание на доработку инициатору задачи, указывая необходимые корректировки в тексте.

Прочие блоки согласования

Главной особенностью этих блоков было автоподписание всех документов, указанных в определенном параметре, при выполнении задания с результатом «Согласовано». При этом в desktop-клиенте было реализовано диалоговое окно, позволяющее оставить комментарий к электронной подписи для каждого отдельного документа.

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

Использование электронных подписей (ЭП)

Вопрос подписания документов стал основным при реализации согласования с помощью мобильных решений. Заказчик использовал ЭП, выданные собственным удостоверяющим центром на базе Microsoft. Еще одним ограничением был отказ от покупки «КриптоПро CSP» для подписания документов при использовании DIRECTUM Solo для iOS. Ну, и третьим ограничением стала необходимость формирования отчетов о согласовании документов по ЭП.

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

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

Вывод

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

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

В результате такого подхода к внедрению сами мобильные решения стали тем, что так давно хотели руководители: в них отразились те минимальные 20% функционала системы, которые они использовали в 80% случаев. Очень часто на проектах я слышал фразу «Сделайте мне три кнопки, все остальное уберите, и я буду счастлив». Мобильные решения сделали некоторых авторов подобных требований счастливее!