Постановка задачи
Для простоты представим, что предприятие структурно разделено на два уровня. (В общем случае уровней может быть сколько угодно).
На уровне предприятия производятся следующие работы:
- Формулируются требования к предприятию в целом и выявляются ограничения, накладываемые внешними условиями;
- Определяются производственные мощности предприятия;
- Формулируются стратегические цели предприятия и текущие планы (задания);
- Задания для предприятия декомпозируются на задания для подразделений. При этом учитываются возможности отдельных подразделений;
- Задания передаются подразделениям.
На уровне подразделения производятся следующие работы:
- Задания для подразделения валидируются на предмет возможности их выполнения;
- В случае успешной валидации задачи для подразделения декомпозируются на задания исполнителям;
- Исполнители выполняют задания;
- Анализируется ход выполнения этих заданий;
- Анализируется ход выполнения заданий подразделения в целом;
- Анализируются завершенные операции, как на уровне исполнителей, так и на уровне подразделения в целом;
- На основе собранных фактов определяются производственные возможности каждого исполнителя;
- Находятся узкие места, требующие усиления;
- Анализируются производственные возможности подразделения в целом, и информация об этом передается на уровень предприятия.
На уровне предприятия работа продолжается:
- Принимается и анализируется информация о ходе выполнения фактических работ;
- Изучаются фактические возможности подразделений;
- Эта информация используется для определения узких мест и возможности их усиления;
- Эта же информация используется для определения производственных возможностей предприятия в целом.
Таким образом, в каждой структурной единице приходится выполнять следующие работы:
- Валидировать поступающие с верхнего структурного уровня задания;
- Создавать планируемые сценарии планируемых работ, которые по замыслу их создателя должны привести к выполнению заданий, пришедших с верхнего структурного уровня;
- Валидировать планы, и на их основе создавать задания, которые назначать конкретным исполнителям;
- Выполнять задания;
- Анализировать результаты выполненных работ;
- На основе полученных данных производить корректировку планируемых работ, и координацию этих изменений как со смежными единицами, так и с верхней структурной единицей;
- Поддерживать знание о производственной мощности каждого исполнителя;
- С целью повышения производительности находить и «расшивать» узкие места;
- Вычислять суммарную производственную мощность структурной единицы в целом. Информацию об этом передается как смежным единицам, так и на уровень выше.
Пусть перед ИТ отделом стоит задача: необходимо автоматизировать следующие функции:
- Моделирование операций и сценариев на основе типовых схем;
- Сравнение полученных результатов с планируемыми;
- Корректировка планов.
Введение
Я хочу объяснить, почему для решения подобной задачи использование обычного движка workflow не годится. Существуют ограничения, о которых я расскажу.
Планирование работ обычно происходит путем множества «забросов», где каждый «заброс» – это сценарий будущих работ. Каждый сценарий содержит некоторое количество планируемых операций, расположенных на временной оси и связанных между собой логическими условиями, например такими:
- После завершения операции 3 начнется выполнение операции 5;
- Результат операции 5 будет играть роль вспомогательного инструмента в операции 6.
Существует разница между индивидуальным сценарием и типовым сценарием. Чтобы объяснить разницу между ними, я прибегну к аналогии со строительным проектом.
Пример из области строительства
Представьте себе, что вы планируете построить собственный дом. Для такого строительства нужен проект. Проект делает проектная организация. Вы заказываете разработку проекта вашего будущего дома в проектной организации, где вас спрашивают: вам разработать типовой проект, или индивидуальный? При этом типовой стоит 20000 рублей, а индивидуальный – 200000, то есть, на порядок дороже! Для ответа на этот вопрос вы должны знать, чем типовой проект отличается от индивидуального.
Отличие в том, что типовой проект не адаптирован под конкретные условия. Конкретные условия – это (в том числе) геология и рельеф местности. Например, уклон в 30 градусов на песчаном склоне, затапливаемом в половодье.
Представьте себе, если на таком склоне будет построен дом на ленточном фундаменте, так как указано в типовом проекте. Понятно, что он долго не простоит – его смоет. Чтобы такой дом стоял долго, его надо поставить на сваи, которые придется бить на глубину, достаточную, чтобы упереться в материнское основание и с частотой, которая способна выдержать нагрузку сползающего слоя песка. Если бы вы заказали индивидуальный проект, то расчет такого фундамента вам сделает проектная организация. В типовом проекте вы не найдете свайный фундамент, потому что типовой проект рассчитан на типовые условия.
Пусть в проекте указано, что в качестве щебенистой фракции в бетоне, который идет на заливку перекрытия, необходимо использовать гранитный щебень фракции 20-50. Но местный производитель готов поставить только известняковый. Покупать же гранитный щебень невероятно дорого! Вопрос: можно ли заменить гранитный щебень на известняковый? Проектная организация, зная местные условия, может произвести замену материала, перечитав допустимые нагрузки, и предложить залить перекрытие бетоном толщиной не 20 см, а 30 см. Правда, для этого придется заменить фундаментные блоки на монолитный ростверк, что приведет к удорожанию фундамента. Поэтому возникает вопрос, что дешевле: привезти гранитный щебень, или пойти на удорожание фундамента? Если вы закажете индивидуальный проект, то эти вопросы задаст вам исполнитель проектных работ. Он же даст и ответы на них. Если же вы купите типовой проект, то вам придется задавать эти вопросы самостоятельно и решать их на свой страх и риск.
Если вы достаточно опытный строитель, если готовы провести экспертизу типового проекта и оценить возможность его адаптации к конкретным местным условиям, то вам для работы достаточно типового проекта. Если же вы не обладаете нужным опытом, то стоит заказать индивидуальный проект.
Пример из области управления производством
Индивидуальный сценарий отличается от типового сценария тем же: на основе типового сценария создается индивидуальный сценарий. Создается он путем адаптации его (типового сценария) к конкретным условиям: конкретным датам и конкретным исполнителям, материалам и проч.
Типовой строительный проект требует «посадки на местность». Это значит, что достаточно будет указать координаты углов и отметку высоты, чтобы типовой проект начал приобретать черты индивидуального. Для типового сценария «посадка на место» означает привязку к конкретному времени: указание времени начала выполнения. Эту «посадку» может осуществить движок автоматически.
Типовой проект требует адаптации под местные строительные материалы, геологию и рельеф. Для типового сценария это означает, что его надо адаптировать под конкретные условия и конкретных исполнителей. Адаптация эта будет выглядеть как назначение конкретных исполнителей на роли, корректировку планируемых длительностей операций, замену одних операций на другие, или изменение порядка операций и тд.
Зачем моделировать сценарии?
Так есть ли необходимость в моделировании индивидуальных или в моделировании типовых сценариев?
Правило для выбора объекта автоматизации гласит: для автоматизации надо выбирать те функции, автоматизация которых принесет пользу. Это значит, что автоматизации подлежат часто встречающиеся случаи (даже, если автоматизация каждого из них дает небольшой экономический эффект), а также редко встречающиеся случаи, но автоматизация каждого из которых дает большой экономический эффект (например, путем снижения рисков).
Типовые сценарии требуют адаптации к реальным условиям с частотой от «почти никогда» до «почти всегда».
Надо ли моделировать индивидуальные сценарии, или не надо, надо ли моделировать типовые, или не надо — зависит от выгоды, извлекаемой из этого моделирования.
Когда мы можем не моделировать индивидуальные сценарии?
- Когда отклонения планируемых сценариев от типового происходят редко, и анализ этих отклонений не дает ощутимой выгоды.
Когда мы вынуждены моделировать индивидуальные сценарии?
- Когда отклонения индивидуальных сценариев от типового происходят часто;
- Когда отклонения происходят редко, но анализ этих отклонений дает ощутимую выгоду.
Итак, можно сделать вывод, что моделирование индивидуальных сценариев нужно, когда они (сценарии) часто отклоняются от типового, или, когда идет непрерывное улучшение производственного процесса.
Когда можно не моделировать типовые сценарии?
- Когда отклонения планируемых сценариев от типового сценария происходят очень часто.
Когда надо моделировать типовые сценарии?
- Когда отклонения планируемых сценариев от типового сценария происходят редко.
Формулировка проблемы
Теперь вернемся к вопросу, почему для решения поставленной выше задачи нельзя использовать обычный инструмент workflow.
В постановке задачи есть пункты:
- Моделирование операций и сценариев на основе типовых схем;
- Сравнение полученных результатов с планируемыми;
- Корректировка планов.
Эти функции нельзя автоматизировать, если в информационной системе не будут храниться модели планируемых сценариев.
Есть редакторы диаграмм Ганта, которые позволяют строить модели планируемых сценариев.
Однако могут возникнуть две задачи:
- Может понадобиться типовой сценарий, поскольку отклонения индивидуальных сценариев от типового случаются редко. Это решается путем создания типовой диаграммы Ганта;
- Может понадобиться моделировать ветвление планируемого сценария в зависимости от условий, складывающихся в процессе выполнения работ. Эта задача с помощью диаграммы Ганта уже не решается.
Есть нотация BPMN. Эта нотация предназначена для моделирования типовых сценариев, но в ней нельзя создать модель индивидуального сценария.
Вывод
На сегодняшний день я не нашел информационной системы или нотации, которые предложили бы моделирование как типовых, так и индивидуальных сценариев с учетом ветвлений. Скорее всего, я мало искал. Если кто-то знает подобные системы, сообщите, пожалуйста!
Спасибо за внимание!
Комментарии (51)
satsyuk
28.06.2016 11:54Мы используем нотацию BPMN2 для написания сценариев. В BPMN2 есть понятие UserTask для организации интерфейса с пользователем. UserTask могут быть назначены в явном виде как для конкретного пользователя системы, так и для группы пользователей. Также вместо явного указания пользователя или группы можно указать переменную процесса, значение которой можно менять в самом процессе в зависимости от различных событий. Так что мне также не совсем понятно Ваше утверждение по поводу того, чем типовой сценарий отличается от индивидуального.
maxstroy
28.06.2016 11:59Пусть у нас есть база данных, в которой хранятся данные о произошедших событиях: операциях. Пусть есть база, хранящая информацию о типовых сценариях — там, где хранятся модели в нотации BPMN2. Пусть мы потеряли информацию о типовых сценариях в нотации BPMN2. Как на восстановить индивидуальные, не имея типовых? Если индивидуальные сценарии хранятся в БД, то труда это не составит — вот они. Если же не хранятся, то мы их не восстановим. Вопрос: можно ли увидеть модели сценариев в БД, если из нее убрать все модели всех типовых сценариев?
satsyuk
28.06.2016 12:17BPMN2 — это описание сценария. Нет такого понятия как типовой или индивидуальный. Это зависит от контекста выполнения. В хранилище (БД, либо в памяти, либо еще где...) по каждому выполняющемуся сценарию хранится его контекст. Перед продолжением выполнения любого процесса из хранилища поднимается его контекст и берется описание BPMN процесса и… поехали. Если чего-то нет, то, соответственно, и выполнить невозможно
maxstroy
28.06.2016 13:01Нет такого понятия как типовой или индивидуальный.
Я привел пример из строительства. Он широко распространен
maxstroy
28.06.2016 13:09Вы предлагаете хранить дельты: есть типовой сценарий, есть индивидуальные отличия между типовым и индивидуальными сценариями (то, что Вы называете «контекст») Индивидуальный сценарий при таком моделировании получается путем суммирования типового сценария с дельтой. Так он строится, но не хранится. Вопрос о том, как хранить сценарии — вторичен, главное, что есть возможность построения типового сценария. Но встает вопрос: насколько велика эта дельта теоретически? Ведь в реальных ситуациях индивидуальный сценарий может перестать быть даже похожим на типовой. Есть ли возможность хранить такие дельты?
VolCh
28.06.2016 13:28Чем вариант глобального процесса, в которой типовой сценарий исполняется как путь для значений различных параметров по умолчанию, а индивидуальные на основе других значений их и их сочетаний?
maxstroy
28.06.2016 14:05Вы повторили идею хранения «дельт». Да, это работает, если дельты покрывают все нужные нам кейсы, например, если мы в итоге на основании типового сценария построили нечто. что совершенно не похоже не типовой: разное количество операций, разные названия операций, порядок другой. Если при помощи «других значений и их сочетаний» можно замоделировать любой сценарий, отличный от типового, то задача решена.
ok-home
28.06.2016 13:41Насколько я понимаю, вам нужно перед каждым выполнением процесса ( сценария ):
— взять типовой процесс
— отредактировать его
— запустить на исполнение.
если пользователи у вас достаточной квалификации, чтобы выполнять подобную процедуру — в чем проблема?
храните типовой сценарий — копируйте в новый и редактируйте.
хранится будет типовой, а исполнятся, хранится и анализироваться будет то что реально исполняется.
кто мешает хранить «кучу» сценариев в базе? — вопрос что вы с этим потом делать будете.maxstroy
28.06.2016 13:46храните типовой сценарий — копируйте в новый и редактируйте.
Я бы рад копировать, но некуда, потому что нет возможности их хранить. Есть возможность хранить только типовые. И да, когда накапливается много (очень много) типовых сценариев, то с ними действительно уже нечего не сделать. Именно поэтому хранить их надо порознь
ok-home
28.06.2016 13:59— взять типовой процесс
— отредактировать его
— запустить на исполнение.
тут одно из двух
— если отредактировать = «поменять параметры типового» = изменить производительность, количество исполнителей, материалы — хорошо опишите типовой процесс с параметрами, и храниться параметры будут в конкретных экземплярах типового процесса
— если отредактировать — изменить логику процесса, фактически " картинку модели" — то придется хранить каждый процесс ( он в вашей терминологии станет типовым ) — иначе нечего запускать на исполнение.maxstroy
28.06.2016 14:11Запуск типового сценария невозможен. Типовой сценарий надо посадить на временную ось, а коль скоро это произошло, типовой сценарий перестал быть типовым. а стал индивидуальным.
Хранение индивидуальных сценариев позволяет мне делать диаграмма Ганта, но BPMN — нет.
Я не хочу редактировать типовой сценарий. Это документ. который лежит в сейфе и абы кто его не трогает. Вот создавай свой чертеж и там делай, что хочешь в рамках дозволенного. Поэтому надо так: создать на основе типового сценария свой личный, адаптировать его и запустить
ok-home
28.06.2016 14:32+1Вы не ответили на вопрос — что значит отредактировать. Изменить параметры или изменить процесс ( логику )
Не сохранив процесс его невозможно запустить ( на любом движке ), если вы сохранили процесс — получаете кучу процессов и не важно как вы их назовете, типовыми или личными.
Если меняются только параметры — все хранится в исполняемых экземплярах.
Гант позволяет хранить промежуточные состояния исполнения «проекта», изменяемого в процессе исполнения. Собственно никакого индивидуального сценария здесь нет. Можете добавлять/убирать любые этапы в процессе выполнения.
В BPMN — изменение логики экземпляра БП не предусмотрено, у него другие цели.maxstroy
28.06.2016 14:40Отредактировать можно индивидуальный сценарий. Типовой редактированию не подлежит, потому что делал его технолог и никто, кроме него не может править типовые сценарии. Итак, на основе типового создается индивидуальный. Далее он адаптируется под конкретные нужды конкретных людей в конкретное время и конкретные ресурсы. При этом может измениться все: последовательность операций, их состав, длительность, участники, короче, все, что угодно.
Я хочу хранить индивидуальные сценарии отдельно от типовых — это все-таки разные документы.
Если меняются параметры, то индивидуальный сценарий строится на основе типового при помощи «дельт», то есть, хранение индивидуальных настроечных параметров — это хранение «дельт». Но можно хранить не «дельты» а «снимки». И второе — именно то, что нам надо.
Как пример, диаграмма Ганта хранит сценарий как есть — без дельт. И нельзя путать планируемый Гант и реальный — это разные документы
solovetski
28.06.2016 17:23The client’s pool is the black box. It means
that we will not describe the client’s process.maxstroy
28.06.2016 17:31Це про другое)). Мы не моделируем сценарий работ клиента, потому что мы о нем ничего не знаем. М ыже моделируем те сценарии, про которые нам все известно
solovetski
28.06.2016 18:00Почему тогда у вас на пуле клиента присутствуют события и задачи? Согласно стандарту и рекомендациям пул клиента должен быть чистым, как вот здесь:
maxstroy
29.06.2016 08:06Потому что BPMN имеет три уровня для описания сценариев. Первый — обычная блок-схема, второй — это полновесный инструмент аналитика и третий уровень — уровень автоматизации. Книга Брюса Сильвера начинается с описания этих трех уровней и для каждого уровня он дает свои правила моделирования. Вы указали на правило для уровня автоматизации, но для уровня блок-схем это правило не действует. Мы можем наэтом уровне моделировать в том числе и действия клиента
ok-home
29.06.2016 09:47А вам какой уровень нужен?
maxstroy
29.06.2016 09:52На деле нам нужен уровень автоматизации. Картинка — лишь картинка. Строить модели на основе картинок, скорее всего, не удастся. Если строить модель, то на основе языка BPMN, но не нотации. То есть, понадобится та часть, которая называется Model, но не понадобится та часть, которая называется Notation.
ok-home
29.06.2016 10:15Если вы переходите в уровень автоматизации.
Вы вынужденно переходите к сохранению индивидуальных процессов, иначе процесс не запускается
и соответственно к хранению в базе экземпляра процесса ( те действия пользователей( системы ) которые выполняются в процессе исполнения процесса ). Так как, в вашей терминологии, не бывает 2-х одинаковых индивидуальных процессов — храните все с разными наименованиями(атрибутами). с вытекающими отсюда проблемами большого количества процессов.
Храните Типовые процессы в одном месте ( разделе общей БД, или другой БД, или на флэшке в сейфе ) Копируйте и создавайте новый индивидуальный процесс каждый раз когда вам это нужно в рабочей БД. Редактируйте ( если квалификация пользователя это позволяет )
И не важно, что это — Гант, BPMN. — количество индивидуальных процессов в связи с вашими требованиями будет одинаково.
Просто для Ганта есть возможность менять процесс в процессе исполнения, для BPMN — нет.
Если нужно как то упорядочивать структуру хранения процессов — любое файлохранилище, которое для вас удобноmaxstroy
29.06.2016 10:24Я бы сказал так (разделяя объект и его модель, чтобы не путаться): мы вынужденно переходим к моделированию индивидуальных процессов и хранению этих моделей в БД, Но это делает и обычный движок BPMN: он хранит модели операций, но не хранит информацию о связях межу ними. Эту информацию можно найти только в моделях типовых процессов в виде моделей типовых связей, но нельзя в моделях процессов в виде моделей связей. И модель процесса я все-таки называю сценарием, иначе нам трудно понять, о чем мы говорим: о процессе, или о его модели. Ведь в БД не хранятся объекты предметной области, там хранятся модели этих объектов, поэтому стоит различать процессы и их модели
ok-home
29.06.2016 10:36«он хранит модели операций, но не хранит информацию о связях межу ними» — я не ГУРУ — но это нонсенс — как тогда движок исполняет операции ??
Для БД ( движок BPMN ) — объект предметной области — последовательность выполнения операций c конкретными атрибутами
ничего другого там хранить нельзя.
Если «объект предметной области» — изделие которое выходит с производства, то оно точно не хранится в БД.maxstroy
29.06.2016 10:52как тогда движок исполняет операции ??
Движок воспринимает стартовые события. Как только возникает стартовое событие из того класса событий, на который ссылается модель типового сценария, движок создает модель этого события и запускает сканирование типового сценария, который связан с классом таких событий (но не с данным событием). Сканируя типовой сценарий, движок создает модели операций, решений, и проч… Но не создает модели связей! Что ему мешает это делать, не понятно.
Объектом не может быть «выполнение», потому что объект — это существительное, а выполнение — глагол. Объектом может быть сценарий, — это да.
В БД хранятся только модели. Сама модель может стать объектом для моделирования, но тогда мы строим модель моделиok-home
29.06.2016 10:58движок исполняет тот «сценарий» — который хранится в БД, в предыдущем посте я предложил вам хранить в БД индивидуальные сценарии. Других вариантов не существует.
maxstroy
29.06.2016 11:03Да, нам надо найти ИС, которая хранит индивидуальные сценарии. Только я бы поправил терминологию, потому что выражение «движок исполняет сценарий» не верное Сценарий исполняют исполнители. — люди, машины и проч., а движок лишь диспетчерирует работы — указывает в какой последовательности и кто должен выполнять сценарий.
batalov
29.06.2016 08:02Проект дома и проект БП конечно в чем-то похожи, но есть и существенные отличия. Дом мы построили один раз, и наш проект будь он типовой или индивидуальный ушел в архив. БП же выполняется регулярно, поэтому мы его и автоматизируем. И фактически при каждом запуске могут произойти более или менее существенные отклонения от зафиксированного сценария, я так понимаю проблематика публикации где-то тут: как моделировать бизнес процессы таким образом, чтобы их было удобно автоматизировать, а также модернизировать и оптимизировать? Действительно, универсального решения так пока и не придумали, хотя методологий существует масса, и каскад с Гантом, и Agile со Scrum, и BPMS с BPMN и SOA с массой технологий вокруг, и все они с большим или меньшим успехом применяются.
maxstroy
29.06.2016 08:13Дом мы построили один раз, и наш проект будь он типовой или индивидуальный ушел в архив. БП же выполняется регулярно, поэтому мы его и автоматизируем.
Будьте внимательны и следите за руками. Итак, вы говорите, что индивидуальный проект дома ушел в архив. Типовой, на основе которого он был создан, тоже в архиве. Но именно этого мне не хватает. Мне не хватает того, чтобы индивидуальный проект БП хранился в базе. Типовой там есть. а вот индивидуального нет. На мой взгляд причина в некорректной терминологии, которой пользуются Б-аналитики. Вы говорите, что БП выполняется регулярно. Но в моей терминологии это значит, что БП много и все они основаны на одном типовом процессе. Проблема в том, что многие называют процессы «реализациями» процесса, «инстансами» процесса, «экземплярами процесса». Но, следуя тогда этой аналогии, конкретный дом — это экземпляр дома, а типовой проект — это дом. Что звучит дико, но в ИТ отрасли это я слышу постоянно. У меня есть статья на тему неправильных терминов и истории их происхождения. Надо — сброшуVolCh
29.06.2016 09:00Для типовых процессов может существовать множество экземпляров, а для индивидуальных только один. Этакий синглтон.
А по аналогии: конкретный типовой дом — это результат исполнения экземпляра типового процесса описанного в типовом проекте. Проект — это не дом и даже не процесс. Это (вкупе с остальной документацией) — описание процесса. Процесс — работы по проекту. Экземпляр процесса — работы по конкретному адресу. Дом — результат работ.maxstroy
29.06.2016 09:08Это тот вопрос, почему я расположил эту статью в разделе «семантика».
Начнем с того, что такое конкретный типовой дом? Что такое конкретный типовой слон? Я знаю, что все слоны, так же как и все дома уникальны. Что такое типовой дом, или типовой слон с вашей точки зрения, и чем типовой дом отличается от конкретного типового дома?VolCh
30.06.2016 06:15Типовой дом — дом, построенный по типовому проекту. Класс домов. Конкретный типовой дом — дом, построенный по типовому проекту по конкретному адресу.
maxstroy
30.06.2016 09:06Тогда что такое типовой слон? Или типовой ландыш? Ведь проекта для строительства слона не существует
maxstroy
30.06.2016 09:09Нельзя давать определение объекта через термин, который не введен в рассмотрение ранее. Получается, что типовой дом водится через термин типовой проект, но тогда надо дать определение термина типовой проект))
VolCh
01.07.2016 13:13Типовой проект — проект строительства типовых домов :)
В естественных языках циклические графы определений — норма.maxstroy
01.07.2016 16:27Хорошо, мы немного зашли в тупик, который сам по себе не очень интересен. Однако, посмотрите обсуждение типового сценария с Катричеком Игорем: https://www.facebook.com/groups/bsfpclub/permalink/1752163081674128/ Возможно, будет интересно.
maxstroy
30.06.2016 09:17Я бы попробовал так. Типовой — значит принадлежит типу. Тип — это то же, что и вторичная сущность по-Аристотелю, то есть, идея. Идея хранится в сознании. У этой идеи есть элементы, Аристотель называл их атрибуты.
batalov
29.06.2016 09:59Сбрасывайте, конечно, интересно. Я думаю, с терминологией надо определиться в рамках решаемых проблем, иначе можно уйти в глубокую философию. Б-аналитики, как вы их называете, на мой взгляд являются по большей части интерфейсом между ИТ и бизнесом. Бизнесу важно достигать целей, а ИТ важно все автоматизировать. В данном случае не совсем понятно, в каком контексте вы работаете. Если в ИТ — то описание бизнес-процесса например в BPMN — это модель, в строительстве домов аналог — проект дома, это тоже модель. Дом — это инстанс, реализация модели, если вы строите для себя — будет в единственном экземпляре, если это П44Т — их будут тысячи. Можно создать реализацию безо всякого моделирования вообще — так природа поступает. С бизнес процессами то же самое, можете их описывать или нет, они происходят. Если их описать и привязать ключевые события к какой-то системе, можно попытаться ими управлять. Что из этого вы хотите хранить и зачем — мне пока не очень понятно.
maxstroy
29.06.2016 10:11Я специально написал требования к ИС языком пользователя. У пользователя (пусть собирает паровые котлы) есть технология производства котла — типовой сценарий работ и есть конкретные работы по изготовлению конкретного котла — сценарий производства котла номер 123. Понятно, что сценарии производства котла номер 123 и номер 124 — разные. Но ИТ сразу скажет, что это:
1. не сценарии, а экземпляры сценария
2. типовой сценарий — это просто сценарий.
И вот тут ИТ специалист сильно расходится с общепринятой терминологией. Он считает, что есть дом и экземпляр дома, в то время, как в общепринятой терминологии есть дом и тип домов (в логике Аристотеля) или класс домов (в математической логике).
Причины смешения терминов я объяснил в статье Моделирование объектов учета параграф 12.5. Приложение E: терминологические коллизииbatalov
29.06.2016 10:22Статья немаленькая, за 5 минут не освоить, спасибо, поизучаю. То, что терминология ИТ специфична, это нормально — вы же не станете требовать от хирурга чтобы он «по-человечески» в своей среде изъяснялся, а не на латыни, а то не всем понятно о чем это он ;). Если мы говорим о ТЗ, ФТ и прочих интерфейсах с заказчиком (или общении хирурга о предстоящей операции с родственниками пациента), то это конечно совсем другая история.
maxstroy
29.06.2016 10:26Я бы не рекомендовал читать статью. Она — лишь вершина айсберга и мы недавно засекали время, которое нужно для погружение в нее: 20 часов лекций и 80 часов самостоятельной работы с литературой. Я лишь сослался на параграф, который самодостаточный
batalov
29.06.2016 10:34Главное, чтобы было интересно. Если действительно будет интересно так долго, то это круто. Но я конечно сомневаюсь. Проверим :)
maxstroy
30.06.2016 09:04Если не затруднит, буду признателен за отзыв после прочтения.
batalov
30.06.2016 09:51Хорошо, пока что действительно интересно, но следуя вашим советам не тороплюсь :). А вы читали «Сумму технологий» Лема? Он в этой тематике очень глубоко копнул, а книга 1963 года выпуска, так что не совсем согласен с вашим утверждением в начале статьи, что моделирование реальности слабо исследовано. Вассерман еще рекомендует «Структуру реальности», «Слепой часовщик» и «Анти-Дюринг» для формирования целостной картины мира, но я еще даже «Сумму технологий» не осилил, уже второй месяц читаю.
maxstroy
30.06.2016 10:05Я не встречал еще ни одной книги, которая бы описывала точно наш опыт восприятия и моделирования результатов восприятия. Всякий раз я наблюдаю одну и ту же картину: дается гипотеза, а затем части этой гипотезы превращаются автором в «реальность». Например, допустим, что пространство — это граф, получим из этого выводы о том, что граф описывает все наблюдаемые нами явления, из чего автор делает вывод: пространство — граф! Так или иначе, во всех книгах это присутствует. Всегда можно найти это место, где автор сам себя обманул. Поэтому мне сложно читать много литры, — заранее известен конец. Хотелось бы найти такого автора, который не погрешит перед истиной. Книги такие есть, но они рядом, не про моделирование предметной области. Например, «Бах, Эшер, Гедель». Недавно в учебнике матлогики я нашел ошибку. Показал ее преподавателю матлогики, а он ее не понял. Так что надо иметь очень тренированный ум и дисциплину, чтобы двигаться, не увязнув в иллюзиях
VolCh
Чем отличается моделирование типового сценария от индивидуального в вашем понимании?
maxstroy
конкретный индивидуальный сценарий отличается от типового тем же, чем индивидуальный проект дома от типового. Я постарался очень подробно описать это различие в тексте. Поэтому вопрос: что именно было плохо объяснено?
DmitryMironov
Проекты домов будут отличаться только спецификой реальзации. Нотации описания данных проектов будут абсолютно одинаковы: Чертежи, сметы и т.д. Или вы считаете что для каждого индивидуального проекта дома будут изобретены новые правила выполнения чертежей и смет?
Поэтому вопрос по нотации и вызывает столько вопросов.
maxstroy
Условные обозначения в документах действительно одинаковые для всех документов. Иначе мы не смогли бы их читать. Но количество документов, которые можно построить на основе этих обозначений, — бесконечно много.
Так в нашем случае — правила описания сценариев — одни для всех сценариев, но разные для каждого сценария. При этом в типовом сценарии могут быть элементы, которых нет в индивидуальном, например, указание различий в исполнении в зависимости от времени года, а в индивидуальном есть элементы, которых нет в типовом, например, дата начала выполнения сценария
VolCh
Я понимаю вроде бы чем отличаются сценарии, я не понимаю чем отличается их моделирование, тем более в BPMN. В BPMN не хватает каких-то сущностей или связей между ними, чтобы моделировать индивидуальные сценарии? Или вам не хватает чего-то вроде наследования, что бы указать «этот сценарий является индивидуальным. базовый у него такой-то, отличия от него такие-то?», чтобы индивидуальные сценарии автоматически изменялись с базовым, если, скажем, мы поменяли тип какого-то этапа с ручного на автоматический?
А в целом я не вижу в BPMN проблем держать типовой процесс как шаблон для индивидуальных. Наметились отличия — скопипастили и правим. Можно даже заводить глобальный объединяющий типовой с индивидуальными с анализом какого-то условия типа номера договора для выбора или типового или одного из десятков-сотен-тысяч-… индивидуальных (а-ля switch {case: case: default:}).
maxstroy
Атрибуты у них разные. Если у сценария есть правило для ветвления, то в типовом — правило для создания правил ветвления. То есть в первом случае это будет звучать так: если сумма сделки больше 100 рублей, то пойдешь направо, если меньше — налево. Во втором кейсе это звучит так: Каждый раз, когда вы столкнетесь с подобной ситуацией, рекомендация следующая: Если сумма текущей сделки больше 100, то ходите направо, где бы вы не находились при этом, но следите, чтобы не упасть. В противном случае ходите налево, но также смотрите по сторонам. Если налево или направо пойти нельзя, используйте все свои знания и опыт, чтобы адаптировать типовой сценарий под конретные нужды.