Автоматизация документооборота. Разработка приложения для Битрикс24

Иногда наши заказчики обращаются к нам за решением нестандартных задач по расширению возможностей облачной версии Битрикс24. Подобные нетипичные задачи зачастую возникают в крупных компаниях со сложной структурой и сложившейся культурой по принятию решений и порядком документооборота. Этот кейс интересен как самим решением - разработкой приложения для Битрикс24, так и постепенным путем его разработки и внедрения по методологии Agile.

  • КлиентООО "ФасКон", СК МиАл
  • ОтрасльСтроительство
  • УслугиBitrix24, Process automation , Development , Consulting
  • Сайтhttp://skmial.su/

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

Задача

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

  • Максимальная скорость согласования
  • Фиксация факта согласования ответственными сотрудниками
  • Наличие возможности отслеживания статуса согласовываемого документа
Автоматизация  документооборота. Разработка приложения для Битрикс24

Решение

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

Этап 1. Базовая автоматизация

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

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

Для удобства работы с архивом заявок был сформирован универсальный список. Бизнес-процесс при запуске добавлял в него новую запись до дополнял ее по мере поступления информации.

Такая реализация ускорила процесс согласования, но не являлась оптимально и завершенной.

Этап 2. Разработка приложения
Приложение для Битрикс24. Схема

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

Самым очевидном решением была разработка приложения для Битрикс24 и активити* для бизнес-процесса.

*-Активити бизнес - процесса это дополнительный блок, доступный в конструкторе бизнес-процессов, и обладающий собственными параметрами.

Приложение для Битрикс24. Активити бизнес-процесса

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

Изначально мы не рассматривали размещение приложения в облаке Битрикс24, поскольку оно было ресурсоемким и требовало работы со специальными библиотеками, позволяющими редактировать и формировать PDF. Мы планировали разместить приложение на хостинге, имеющемся у клиента. Но на этапе отладки выяснилось, что далеко не все хостинги готовы устанавливать нужные нам библиотеки и давать расширенные права на работу с файловой системой. А стоимость услуг хостингов, отвечающих нашим требованиям, не устраивала Заказчика. Поэтому было найдено компромиссное решение - в серверной Заказчика был размещен простой веб-сервер, на котором мы и разместили наше приложение.

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

Этап 3. Версия 2.0
Веб интерфейс сереврной части

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

Благодаря такому интенсивному использованию проявились слабые места реализованного нами решения:

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

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

  • Для обработки объемных документов увеличили объем оперативной памяти на веб сервере и оптимизировали сам скрипт.
  • Для одновременной обработки нескольких документов активити бизнес-процесса было доработано - проверялась доступность сервера и отправка осуществлялась не один раз, а за несколько попыток с интервалом между ними. Все ответы сервера выводились в лог бизнес-процесса, что позволяло более точно следить за ходом обработки файла.
  • Функционал скрипта был разделен на две основные функции - прием и передача файлов и данных и непосредственно генерация файла. После получения файла и данных скрипт отправлял в приложение Б24 ответ, подтверждающий получение данных. Полученные данные записывались в базу данных, откуда потом попадали на обработку скриптом, отвечающим за генерацию PDF. Результат отправлялся обратно в приложение Битрикс24, фиксируя статус успешной передачи файла. Отправка осуществлялась также за несколько попыток, т.к. теоретически возможны сбои в передаче, связанные с временной недоступностью Битрикс24.
  • Для отслеживания документов, находящихся на обработке на сервере был сформирован веб-интерфейс, отображающих статус текущих документов и позволяющий проследить историю формирования файлов. В веб-интерфейсе были реализованы функции принудительной повторной отправки сформированного файла в Битрикс24.
  • Доступность сервера проверялась отправкой тестового запроса - если сервер был недоступен, администратору портала отправлялось уведомление.

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

Этап 4. Развитие

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

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

Результат

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

P.S.: С обновлением мобильного приложения Битрикс24 и появлением в нем функционала бизнес-процессов время согласования большинства документов сократилось до 1 рабочего дня. Поскольку теперь ответственные за согласование могли реагировать более оперативно.

Наши работы
Новые потрясающие проекты для наших удивительных клиентов