Сотрудники компаний выполняют множество задач во время исполнения своих служебных обязанностей. У каждой задачи есть некоторый срок и зачастую этот срок выставляется неверно, что влияет как на распределение нагрузки между сотрудниками, так и на и планирование производственного процесса.
Ошибочное выставление срока выполнения работы является одним из ключевых факторов, влияющих на загруженность сотрудника. Он возникает по следующим причинам:
Существуют различные инструменты, позволяющие визуализировать имеющуюся информацию в DirectumRX, которую затем можно использовать для анализа. Однако у данных инструментов есть несколько существенных недостатков:
Решить проблему выставления планового срока можно с помощью методов машинного обучения, прогнозирующих количество рабочих часов, необходимого для выполнения работы. На основе спрогнозированных часов можно получить срок (дата и время), к которому задача должна быть выполнена.
Стоит отметить, что описанная автоматизация выставления срока применима только к тем задачам, в которых допускается нерегламентированный срок выполнения поставленной задачи т.к. для строго регламентированных это может создать лишнюю путаницу в сроках выполнения.
В зависимости от бизнес-процессов может быть использована различная информация, позволяющая прогнозировать срок выполнения задачи. При реализации идеи автоматизации выставления срока использовались следующие признаки, характеризующие как задачу, так и информацию об исполнителе:
Исходный набор данных представлял собой информацию о 8 тыс. заданий, 20% которых использовался в качестве тестовых данных. Информация о зданиях описывалась 30 признаками, при этом целевым признаком являлось количество рабочих часов с точностью до 1 знака после запятой.
В качестве алгоритма для построения модели использовался алгоритм Random Forest, который показал на тестовых данных
Для обеспечения прогноза необходимого количества рабочих часов с помощью машинного обучения используется сторонний RESTful WEB-сервис, цель которого получить необходимую информацию со стороны DirectumRX и вернуть в ответ спрогнозированное количество рабочих часов. В качестве инструмента разработки использовался фреймворк Flask.
Схема взаимодействия следующая:
Для обеспечения обмена данными между сервисом и DirectumRX на стороне DirectumRX была разработана задача, в рамках которой реализован механизм отправки данных на разработанный сервис и получение результатов прогноза. Разработанная задача во многом отражает «простую задачу», однако данное решение может применяться и для других видов задач. Для обеспечения отправки запросов на сервис использовалась библиотека RESTSharp, которую необходимо подключить как стороннюю библиотеку.
Периодическое обновление модели путем обучения на новых данных на стороне DirectumRX осуществляется с помощью фонового процесса, обрабатывающего информацию, полученную из базы данных DirectumRX и сохраняющего ее в файл, который затем считывается на стороне сервиса и обучает модель.
Одним из важных этапов разработки является перенос разработанного приложения и прикладной разработки в DirectumRX с места разработки до места непосредственной эксплуатации. Если в случае прикладной разработки в DirectumRX данные механизмы уже реализованы, то для переноса и развёртывания разработанного сервиса необходимо использовать сторонние технологии – например, виртуализацию. Этот подход позволяет развернуть приложение изолированно от места развертывания, сохранив все его необходимые зависимости, и дает возможность упростить процесс переноса и обезопасить от конфликтов версий.
Одним из самых популярных подходов к развертыванию приложений является запуск приложения в контейнере. Контейнеризация приложения позволяет запустить приложение изолировано от хост-машины и упрощает перенос с одного сервера на другой. Кроме того, все необходимые зависимости хранятся внутри контейнера, что и обезопасит от конфликтов версий. Для автоматизации создания и запуска контейнеров использовалось программное обеспечение Docker.
Таким образом, использование автоматизации выставления срока позволит лучше распределять нагрузку среди работников компании, а также упростит планирование производственного процесса.
Буду рад отклику сообщества по идее и ее реализации.
Идея использования интеллекта для прогнозирования срока выполнения заданий витает достаточно давно. Чтобы оценить предлагаемую вами идею и реализацию не хватает данных о результатах вашего тестирования. Интересно было бы увидеть.
На мой взгляд, существенной проблемой в кейсе определения срока является оценка объема работ, который поставлен в задаче инициатором. Скорее всего, неправильно его оценивать по количеству вложений, стажу исполнителя и другим признакам, ведь основная суть задания кроется в его тексте. Думаю, что интеллект здесь должен уметь предсказывать обычный срок выполнения аналогичных заданий. Для этого нужно будет классифицировать все задания данного исполнителя по группам и вычислить среднее время исполнения. Таким образом, если получится провести автоматическую классификацию заданий по определенным группам, то эту задачу решить можно. К сожалению, пока видится, что качественную классификацию и обучение можно провести только в режиме с участием человека-оператора, а для данного кейса это будет неприемлемо.
Айрат, данная реализация является прототипом, поэтому пока не могу представить более детальные результаты тестирования. Ввиду того, что классификация текста или темы задачи является отдельной проблемой, на текущий момент определение вида работы остается за инициатором задачи (при заполнении карточки задачи инициатору необходимо заполнить специальное поле с видом работы), хотя даже при автоматической классификации необходимо сохранять за инициатором право внести изменения в результаты классификации (здесь я исхожу из того, что инициатор при постановке задачи понимает к какой группе работ относится та или иная задача). Стоит заметить, что помимо объема выполняемой работы немаловажную роль играет исполнитель: его загруженность, опыт работы, специальные навыки. Это позволяет сделать прогноз более предсказуемым и интерпретируемым, например, стоит ожидать более длительного времени выполнения задачи от того исполнителя, который в меньшей степени обладает специальными навыками для решения задачи. Если имеется у сотрудника большая загруженность по задачам, то имеет смысл либо поднять приоритет задачи, либо отправить задачу на выполнение другому сотруднику.
Михаил, вы правильно заметили, что задача классификации стоит отдельным столпом и скорее всего туда не стоит глубоко погружаться в рамках вашего прототипа. На мой взгляд, описанный вами подход логичный и правильный. Очень бы хотелось увидеть, что у вас в итоге получится.
Пока размышлял над вашим кейсом, придумал свой. В моей работе я запускаю много процессов по предопределенными регламентам (согласование документов, исходящих писем, согласование оплаты поставщикам и др.). Несмотря на то, что сроки выполнения заданий по регламенту обычно предопределены (часы, дни), мне приходится достаточно часто "зарываться" в ход процесса, чтобы понять как скоро я получу ожидаемый результат. Обычно, это рутинный процесс с моей стороны, который требует затрат времени, чтобы проанализировать каждый этап.
Было бы здорово, чтобы система предоставляла свой прогноз получения результата. И здесь можно учитывать множество тех факторов, которые вы описывали выше:
ИМХО, это все посильно автоматизировать, в т.ч. с использованием инструментов машинного обучения. Ну, не магия ли будет? =)
Авторизуйтесь, чтобы написать комментарий