Так он ходит-то по веткам как положено, ну пойдет он направо, а про функцию слева ещё не знает. Пока мы до конца не дойдем, мы не знаем, что собрали всю информацию о среде выполнения. Можно встретив ресурс, посмотреть, где он ещё занят, и в тех функциях взять его задачи для приоритезации, НО: в этот момент ему задачи нижестоящие функции ещё не передали, мы про них тоже ничего не знаем.
Хороший вопрос, действительно, из двух функций всегда будут выполнятся сначала задачи функции, самой близкой к генератору. Алгоритм обходит дерево процесса сверху вниз, видит наличие задач и назначает их в работу, т.к. до нижней функции он ещё не дошел и не знает, про её существование. Тут надо будет подумать.
Тут вопрос в уровне декомпозиции процесса. В зависимости от целей моделирования договариваются «на берегу» до какого уровня детализировать модели. Я рекомендую детализацию до уровня функций — целенаправленных действий одного сотрудника. Нам не надо дробить функцию «Подписание документа» на действия «Поиск документа в системе», «Печать документа» и «Подписание документа» — мы НЕ отвечаем на вопрос «Как он это делает?», а отвечаем на вопрос «Зачем он это делает?».
Бывают исключения, например когда в предыдущем примере подписать может не только исполнитель, а и его начальник, то это будет две функции «Подготовка документа» и «Подписание», у второй функции будет два альтернативных ресурса. Либо если исполнитель в течении дня только готовит документы, а подписывать он их должен пачкой вечером или на следующий день (ну мало-ли), то так же это будет 2 функции, т.к. после подготовки документов процесс останавливается и ждет наступления управляющего события «Каждый вечер в 19:00».
В вашем случае достаточно объединить действия одного исполнителя в одну функцию, тогда он не возьмет из очереди новую задачу, пока полностью не завершит начатое, что вам и надо. Для приоритезации выполнения задач есть приоритеты — глобальный и локальный, но они предназначены для немного других целей — например если сотрудник освободился и у него в очереди две задачи разных типов, например «Обслужить клиента» и «Позвонить подруге», то будет взята на исполнение задача с наибольшим приоритетом, т.е. звонок подруге.
Я работал на этом симуляторе и иногда поглядывал на него при написании своего. ИМХО — Арис лучшие свои годы уже пережил, сейчас там так все наворочено и столько сложных, запутанного функционала, что люди просто боятся в нем разбираться, даже консультанты. В симулятор я старался взять только достаточно понятные и прозрачные свойства процесса, которые сам использовал. Насчет конкретно «Переключения» — я им в банковской сфере никогда не пользовался, не представляю как операционист будет «тупить» и ничего не делать в специальное время. Пусть «тупит» во время работы над задачей, тогда мы его правильно посчитаем и включим в себестоимость выполнения функции.
А насчет фичи — сбор данных это все-таки этап моделирования, для этого сервис не предназначен, для моделирования полно доступного софта. Если будут предложения по симуляции — готов рассмотреть и оперативно внедрить, лишь бы на пользу было.
Со временем там как раз никаких хитростей нет. Есть следующие параметры:
1. Время такта — 1 сек, с такой частотой происходит обновление визуальной информации в реальном времени. Это время адаптивно может увеличиться, если расчет не успел выполниться за этот период.
2. Время старта процесса, процессное время, задается в настройках, по умолчанию 9:00
3. Скорость — период процессного времени, равный периоду реального времени, задается в настройках. По умолчанию на 1 сек. реального рассчитывается 1 минута процессного. При включенном ускорении этот параметр умножется от 2 до 60 раз
А далее с каждым тактом, к начальному времени прибавляем скорость, умноженную на количество тактов (например на 3 секунде расчета 9:00 + 01:00*3 = 9:03 — время процесса). Во всех расчетах, используем время процесса, что бы вовремя остановиться.
Спасибо за найденный баг. Это была рудиментная ошибка. Задачи из рабочей очереди переставали очищаться, если находилась хоть одна невыполненная задача. Из-за этого росла длинна очереди задач в работе. Сейчас ошибка исправлена, текущая актуальная версия сервиса 01.03.5, обновите пожалуйста кеш вашего броузера.
Читал уже сокращенную версию, замечаний нет. По-поводу продолжения, интересует, как технаря, вопросы бизнесовые: какую бизнес-модель и как выбирать, куда и в каких пропорциях планировать расходы. Все цифры надо же на основе каких-то фактов строить, а не на интуиции?
Рассмешили своим консалтингомаркетингом. К вам обратились с заказом на создание страницы для продажи, например трактора. И производитель прекрасно знает, для кого он нужен, как продавать, «потребительскуюценность» и т.п. Просто передайте дизайнеру задачу и не морочьте никому голову.
Такая-же фигня, я им в начале проекта бью себя в грудь — «Да я рубаха-парень, такой же как вы был программист», а они меня к концу «злым следователем» кличут.
Бывают исключения, например когда в предыдущем примере подписать может не только исполнитель, а и его начальник, то это будет две функции «Подготовка документа» и «Подписание», у второй функции будет два альтернативных ресурса. Либо если исполнитель в течении дня только готовит документы, а подписывать он их должен пачкой вечером или на следующий день (ну мало-ли), то так же это будет 2 функции, т.к. после подготовки документов процесс останавливается и ждет наступления управляющего события «Каждый вечер в 19:00».
В вашем случае достаточно объединить действия одного исполнителя в одну функцию, тогда он не возьмет из очереди новую задачу, пока полностью не завершит начатое, что вам и надо. Для приоритезации выполнения задач есть приоритеты — глобальный и локальный, но они предназначены для немного других целей — например если сотрудник освободился и у него в очереди две задачи разных типов, например «Обслужить клиента» и «Позвонить подруге», то будет взята на исполнение задача с наибольшим приоритетом, т.е. звонок подруге.
А насчет фичи — сбор данных это все-таки этап моделирования, для этого сервис не предназначен, для моделирования полно доступного софта. Если будут предложения по симуляции — готов рассмотреть и оперативно внедрить, лишь бы на пользу было.
1. Время такта — 1 сек, с такой частотой происходит обновление визуальной информации в реальном времени. Это время адаптивно может увеличиться, если расчет не успел выполниться за этот период.
2. Время старта процесса, процессное время, задается в настройках, по умолчанию 9:00
3. Скорость — период процессного времени, равный периоду реального времени, задается в настройках. По умолчанию на 1 сек. реального рассчитывается 1 минута процессного. При включенном ускорении этот параметр умножется от 2 до 60 раз
А далее с каждым тактом, к начальному времени прибавляем скорость, умноженную на количество тактов (например на 3 секунде расчета 9:00 + 01:00*3 = 9:03 — время процесса). Во всех расчетах, используем время процесса, что бы вовремя остановиться.
Если не затруднит, пришлите пожалуйста скриншот запрета, попробую разобраться с провайдером.