З аказчик - группа строительных компаний, специализирующихся на полном комплексе фасадных и витражных работ - от поректирования и производства конструцкций до монтажа.
Задача
В любой крупной организации процесс согласования документов является многоэтапным. Из-за большого количества участников принятие решения растягивается на несколько дней, что негативно влияет на скорость и эффективность компании в целом. Перед нами была поставлена, на первый взгляд, традиционная задача по автоматизации процесса согласования документов, но постепенно требования росли. Неизменными оставались следующие задачи:
- Максимальная скорость согласования
- Фиксация факта согласования ответственными сотрудниками
- Наличие возможности отслеживания статуса согласовываемого документа
Решение
Исходя их нашего опыта решения подобных задач мы понимали, что в дальнейшем требования к реализованному решению будут расти или меняться. Поэтому мы предложили Заказчику разработку по методологии Agile, позволяющую оперативно получать необходимый на данный момент функционал и корректировать список требований исходя из потребностей сотрудников и обратной связи, полученной от них. Заказчик с радостью принял наше предложение.
Этап 1. Базовая автоматизация
Было решено начать с реализации бизнес-процесса штатными средствами Битрикс24. Мы провели брифирование сотрудников и согласовали схему прохождения согласования, учтя особенность внутренних правил компании и пожелания всех участников.
В зависимости от типа согласовываемого документа и должности инициировавшего его сотрудника реализовывались различные цепочки согласований. Загруженный документ помещался на Битрикс Диск. Далее процесс собрал подтверждения (или отказы) о согласовании и комментарии, если такие были.
По завершении первого этапа мы автоматизировали цепочку согласований, но сам документ находился на диске, комментарии оставались внутри процесса и в уведомлениях. Если же требовались дальнейшие действия с документом, например, передать в бухгалтерию (на начальном этапе Заказчиком было решено не включать ее в работу бизнес-процесса), или отправить подрядчикам, то для этого приходилось отдельно отправлять документ, и отдельно печатать подтверждение о согласовании и комментарии.
Для удобства работы с архивом заявок был сформирован универсальный список. Бизнес-процесс при запуске добавлял в него новую запись до дополнял ее по мере поступления информации.
Такая реализация ускорила процесс согласования, но не являлась оптимально и завершенной.
Этап 2. Разработка приложения
Собрав обратную связь от сотрудников, Заказчик попросил реализовать механизм, позволяющий в результате формирования получить единый файл, содержащий и сам документ, и историю его формирования. Поскольку изначальный документ мог быть загружен в разных форматах (PDF, JPG, PNG, BMP), то решено было остановиться на формате PDF, который позволяет формировать многостраничные документы и обладает средствами защиты документа, а также позволяет использовать цифровую подпись.
Самым очевидном решением была разработка приложения для Битрикс24 и активити* для бизнес-процесса.
*-Активити бизнес - процесса это дополнительный блок, доступный в конструкторе бизнес-процессов, и обладающий собственными параметрами.
Активити отвечал за связь бизнес-процесса с приложением. Приложение же должно связываться с веб-сервисом, формирующим итоговый документ, и передавать его обратно в активити бизнес-процесса.
Изначально мы не рассматривали размещение приложения в облаке Битрикс24, поскольку оно было ресурсоемким и требовало работы со специальными библиотеками, позволяющими редактировать и формировать PDF. Мы планировали разместить приложение на хостинге, имеющемся у клиента. Но на этапе отладки выяснилось, что далеко не все хостинги готовы устанавливать нужные нам библиотеки и давать расширенные права на работу с файловой системой. А стоимость услуг хостингов, отвечающих нашим требованиям, не устраивала Заказчика. Поэтому было найдено компромиссное решение - в серверной Заказчика был размещен простой веб-сервер, на котором мы и разместили наше приложение.
После реализации второго этапа, независимо от формата загруженного документа формировался итоговый PDF-файл, начало которого дублировало исходный файл (если загружено было изображение, то оно размещалось на первой странице), а на следующих страницах с заранее заданным форматированием отображались данные, собранные по цепочке согласования. Время согласования, данные согласовавшего лица и комментарии, если они были оставлены.
Этап 3. Версия 2.0
Решение оказалось удачным, и началось его активное использование сотрудниками компании. Количество документов, согласованных через бизнес-процесс, стремительно росло, в т.ч. и благодаря полному отказу руководства Заказчика от согласований в прежнем формате.
Благодаря такому интенсивному использованию проявились слабые места реализованного нами решения:
- При загрузке объемных многостраничных сканов договоров в формате PDF не хватало мощности веб сервера или обработка происходила достаточно долго
- Если на обработку одновременно попадало два документа, то обрабатывался только один из них.
- В случае недоступности веб-сервера документы не отправлялись на обработку и не могли быть отправлены повторно
- Если во время обработки документа происходил какой-либо сбой (файл не был сформирован или исходных файл не мог быть корректно обработан), то скрипт возвращал ошибку, а процесс завершался просто уведомляя инициатора о технической ошибке.
Собрав эти замечания и пожелания мы пришли к выводу, что существующее решение необходимо существенно переработать. Новая схема работы выглядела следующим образом:
- Для обработки объемных документов увеличили объем оперативной памяти на веб сервере и оптимизировали сам скрипт.
- Для одновременной обработки нескольких документов активити бизнес-процесса было доработано - проверялась доступность сервера и отправка осуществлялась не один раз, а за несколько попыток с интервалом между ними. Все ответы сервера выводились в лог бизнес-процесса, что позволяло более точно следить за ходом обработки файла.
- Функционал скрипта был разделен на две основные функции - прием и передача файлов и данных и непосредственно генерация файла. После получения файла и данных скрипт отправлял в приложение Б24 ответ, подтверждающий получение данных. Полученные данные записывались в базу данных, откуда потом попадали на обработку скриптом, отвечающим за генерацию PDF. Результат отправлялся обратно в приложение Битрикс24, фиксируя статус успешной передачи файла. Отправка осуществлялась также за несколько попыток, т.к. теоретически возможны сбои в передаче, связанные с временной недоступностью Битрикс24.
- Для отслеживания документов, находящихся на обработке на сервере был сформирован веб-интерфейс, отображающих статус текущих документов и позволяющий проследить историю формирования файлов. В веб-интерфейсе были реализованы функции принудительной повторной отправки сформированного файла в Битрикс24.
- Доступность сервера проверялась отправкой тестового запроса - если сервер был недоступен, администратору портала отправлялось уведомление.
В результате удалось повысить надежность работы и прозрачность прохождения обработки документов - в логе бизнес-процесса были видны все шаги обработки и передачи документа, а на стороне веб сервера в веб-интерфейсе можно было отслеживать статусы приема, обработки отправки документов.
Этап 4. Развитие
Спустя некоторое время после внедрения переработанного решения Заказчик захотел расширить возможности бизнес-процесса. Использовалось решение стороннего разработчика, также реализованное как приложение для Битрикс24 и имеющее собственное активити для бизнес-процесса. Такое активити было добавлено в бизнес-процесс, и у пользователей появилась возможность динамически формировать чат для обсуждения конкретного документа. История переписки также фиксировалась в логе бизнес-процесса.
На этом же этапе к работе с бизнес-процессом была добавлена бухгалтерия для обработки согласованных финансовых документов. Т.о. после согласования инициатор мог следить уже не только за статусом согласования документа, но и за статусом оплаты счетов.
Результат
В результате Заказчик получил решение, отвечающее его потребностям. Время согласования сократилось до 1-2 дней (ранее согласование могло растягиваться на недели, а некоторые документы и вовсе терялись) благодаря удобству отслеживания статуса бизнес-процесса и ряду уведомлений, отправляемых сотрудникам, от которых требуется реакция. Переписка, связанная с согласованием, теперь могла вестись в формате чата между всеми участниками согласования, что позволило сократить время согласования. В последней редакции вероятность программного сбоя или потери документа была сведена к минимуму, поскольку большинство действий дублировалось в двух системах.
P.S.: С обновлением мобильного приложения Битрикс24 и появлением в нем функционала бизнес-процессов время согласования большинства документов сократилось до 1 рабочего дня. Поскольку теперь ответственные за согласование могли реагировать более оперативно.
