Это пример реального проекта

Прогнозирование длительности задач и закономерностей возникновения инцидентов

Бесплатная консультация

Концепция проекта

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

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

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

Перед нами стояли две основные задачи:

cheked

Прогнозировать длительность этапов и задач проекта

cheked

Выявлять закономерности возникновения инцидентов

Прогнозирование длительности задач

Вызовы и цели

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

Этап анализа

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

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

Основные риски:

Некоторые ключевые факторы, влияющие на результат, могут отсутствовать в текущей системе учёта.

Недостаточный объём данных.

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

Менее значимые риски:

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

Характеристики новых проектов могут быть совершенно новыми (например, использование нового оборудования в новом месте). Это влияет на качество прогнозов.

Возможны проблемы с шумом в данных.

Предварительный план

01

Определить объём доступных данных.

02

Выявить и задокументировать структуру задачи (все её характеристики и связанные объекты).

03

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

04

По возможности преобразовать категориальные характеристики в числовые значения.

05

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

06

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

07

Изучить способы получения данных от компании.

08

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

09

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

Выявление закономерностей инцидентов

Вызовы и цели

Инцидент (или проблема) — это задокументированное событие, которое может вызвать задержки, проблемы или отклонения от ожидаемых результатов. Например, в строительном проекте это может быть поломка оборудования или другое нежелательное событие.

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

Наша цель — использовать собранные данные для выявления наиболее часто повторяющихся закономерностей причин инцидентов, чтобы руководство могло предотвратить их в будущем. Такие закономерности могут быть простыми, например: «Оборудование X низкого качества, так как оно выходило из строя в 20 случаях из 34», или более сложными, такими как: «Оборудование X не следует использовать вместе с оборудованием Y» или «Оборудование X не следует использовать в определённых условиях» и т.д.

Этап анализа:
Определение закономерностей инцидентов

Описание

01

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

02

Для каждого класса необходимо включить не только сами инциденты, но и все подобные случаи, когда инцидентов не произошло. Случаи с инцидентами называются «позитивными», а случаи без инцидентов — «негативными».

03

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

04

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

Риски, которые необходимо минимизировать

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

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

Могут отсутствовать данные о негативных случаях (когда инцидентов не происходило). Если у нас есть только позитивные случаи, этого недостаточно для решения задачи.

Даже если мы найдём корреляцию между данными и результатом для некоторых классов инцидентов, это не гарантирует того же для других классов.

Предварительный план

01

Определить все классы инцидентов.

02

Проверить наличие данных о негативных случаях (когда инцидентов не происходило).

03

Выбрать 1–3 наиболее значимых класса инцидентов для тестирования.

04

Определить полный набор характеристик для выбранных классов.

05

Получить все необходимые данные.

06

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

07

После этого шага мы определим выполнимость решения и продолжим работу над проектом.

Чтобы узнать больше, посетите нашу страницу разработки программного обеспечения для прогнозирования

Узнать больше

Трансформируйте свой бизнес сегодня —
Получите бесплатную консультацию

Свяжитесь с нами, и первая консультация будет бесплатной.

Пожалуйста, введите ваше имя

Пожалуйста, введите ваш email

Пожалуйста, введите сообщение

Свяжитесь с нами через мессенджеры: