Pull to refresh

Различия в моделировании планируемых и фактически свершившихся операций

CRM systems *IT Terminology
В предыдущей статье «Зачем нужно моделировать индивидуальные и типовые сценарии?» я рассказал про необходимость моделирования как типовых, так и индивидуальных сценариев в тех случаях, когда заказчик хочет автоматизировать три функции:

  1. Моделирование операций и сценариев на основе типовых схем.
  2. Сравнение полученных результатов с планируемыми.
  3. Корректировка планов.

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



Для описания свершившихся действий нам достаточно четырех координат: трех пространственных и одной временной. Конечно, это четырехмерное пространство моделировать в лоб достаточно накладно – понадобится слишком много памяти компьютера, а анализ накопленных данных станет невозможным. Для сокращения модели до приемлемого уровня мы способны выделять из этого четырехмерного пространства некоторые подпространства, наделяя их определенными свойствами. Например, если мы говорим о табуретке, то мы, как правило, пренебрегаем тем, что эта табуретка меняется во времени, — мы считаем ее статичным объектом. Это позволяет нам один раз описать ее геометрию, чтобы потом на нее ссылаться. Если мы говорим о капле воды, то, указывая ее траекторию, мы, как правило, пренебрегаем тем, что она в процессе полета испарялась. Если капель много: так много, что описать траекторию каждой из них не представляется возможным, мы идем дальше и говорим о траекториях капель в целом, вводя новый объект в рассмотрение – поток воды, и, в частности, фонтан. Мы говорим, что фонтан «бьет», но рассматриваем его уже как статичный объект. Таких уловок в моделировании немного и все они классифицированы.

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

Кейс 1


Пусть надо рассчитать стоимость заказа. Мы знаем, что эту работу способен сделать любой комплектовщик из отдела комплектации. Пусть в отделе пять комплектовщиков. При планировании работ мы не знаем, какой конкретно сотрудник будет выполнять эту работу. Поэтому мы пишем: операцию «рассчитать стоимость заказа №123» будет исполнять любой комплектовщик из отдела комплектации.

Пусть расчет заказа завершен. Теперь мы знаем, что расчет произвел расчетчик номер четыре – Сидоров Иван Иванович. Для моделирования этого факта мы пишем: операцию «расчет стоимости заказа №123» выполнил «расчетчик №4», роль которого исполнял «Сидоров Иван Иванович»

Кейс 2


Пусть запланирована операция по сборке мебели. В плане указано: начало работ 22-го июля с 9-00 до 18-00. Так мы смоделировали вариабельность будущего. Мы не знаем, когда точно произойдет начала операции по сборке мебели, Поэтому нам пришлось указать допустимый коридор значений.

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

Кейс 3


Пусть известно, что, если стоимость контракта №123 будет меньше 1000000 рублей, то куратором исполнения контракта будет менеджер по продажам. Если стоимость контракта №123 окажется больше 1000000 рублей, то куратором должен стать начальник отдела продаж. Так мы моделируем вариабельность будущего через операторы ветвления: If (условие) Then (действие).

Пусть реальная стоимость контракта составила 998000 рублей. Поэтому куратором был назначен менеджер по продажам №2 – Иванов. Мы моделируем это так: поскольку стоимость контракта меньше 1000000 рублей, куратором был назначен менеджер по продажам №2.

Моделирование прошлого и будущего


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

Кейс 1


Пусть мы не знаем, кто конкретно сделал расчет заказа, но мы знаем, что какой-то расчетчик из отдела комплектации. Тогда мы моделируем это знание таким образом: операцию «расчет стоимости заказа №123» выполнил кто-то из расчетчиков отдела комплектации.

Кейс 2


Допустим, нам известно, что операция по сборке мебели происходила 22-го июля, известно также, что начало ее выполнения произошло с 9-00 до 18-00. Для моделирования этого факта мы говорим: начало операции состоялось в промежутке между 9-00 и 18-00.

Кейс 3


Допустим, что мы не знаем, кто был куратором выполнения контракта: то ли менеджер по продажам №2, то ли начальник отдела. Кроме того, нам не известна точная сумма контракта. Однако, нам известно, что куратором был менеджер по продажам №2, если сумма сделки была меньше миллиона рублей, и начальник отдела продаж, если сумма сделки была больше миллиона рублей. При моделировании мы говорим: если стоимость контракта была меньше миллиона рублей, то ее куратором был менеджер по продажам, если больше – начальник отдела.

Трактовка моделей прошлого и будущего


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

Моделирование операций


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

  1. Выдвигается гипотеза – алгоритм.
  2. Для этого алгоритма указываются все необходимые ресурсы.
  3. Если ресурсы не найдены, то мы выдвигаем другой алгоритм решения задачи в качестве рабочей гипотезы и повторяем цикл.

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

Выполнение операций


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

Выводы


Таким образом, на производстве выполняются следующие функции:

  1. Создание гипотез решения задач — траекторий.
  2. Проверка гипотез на существующих ресурсах.
  3. Выбраковка нерабочих гипотез и принятие рабочих гипотез к исполнению.
  4. Определение промежуточных точек перепланирования.
  5. Создание заданий до ближайших точек планирования.
  6. Сбор информации о фактически выполненных работах и определение фактических состояний на момент завершения заданий.
  7. Сравнение полученного состояния с запланированным.
  8. Корректировка траекторий по ходу движения.

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

При работе по сменно-суточным заданиям, горизонт планирования – сутки. Это значит, что анализ и перепланирование производится раз в сутки.

При работе по типовым сценариям в нотации BPMN горизонтом планирования является время выполнения текущей операции. То есть, после завершения текущей операции принимается решение о дальнейших действиях: начинать или не начинать следующую операцию. К сожалению, в BPMN нет возможности перепланировать сценарий выполнения работ. Это приводит к тому, что аналитики вынуждены придумывать сложные конструкции (case management), которые «затыкают дыру» в существующей методологии.

При работе с диаграммой Ганта корректировка планов происходит по наступлению контрольных событий: начало, или окончание операций, наступление вех. Это наиболее продуманная методология для планирования и контроля выполнения операций.

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

В следующий раз я расскажу про моделирование деятельности.
Tags:
Hubs:
Total votes 6: ↑4 and ↓2 +2
Views 2.4K
Comments Comments 2