Добрый день!
В прикрепленном файле описание процедуры подбора персонала и картинка из моделера (это д/з ко второму семинару по bpmn). Конструктивная критика приветствуется)
Прием_на_работу_Ник.png (180.3 KB, 212 downloads) 12 лет old Вот описание процесса в пдф
БП-подбор_персонала.pdf (28.2 KB, 79 downloads) 12 лет old Я не волшебник, я тоже учусь. Но, мне кажется, у вас есть ошибки (отметил их красными комментариями).
p.s. вы всё пытаетесь уместить в один процесс. Я бы разбил на несколько: контроль вакансий в компании, поиск кандидатов, собеседование/выбор, оформление документов приема на работу
Image_010.png (162.5 KB, 132 downloads) 12 лет old Господа
Такое впечатление, что на первом тренинге у нас не было темы "Межпроцессное взаимодействие" и мы не разбирались с тем, что прием на работу, работа с резюме и работа с соискателем - это три разных процесса. Я в недоумении.
Добрый день,
Хочу поучаствовать в разработке данного БП на семинаре 01.10
Предлагаю свое видение, исходя из информации в текстовом файле.
Позволю себе следующие допущения:
1) Начало цепочки = "необходим новый сотрудник"; "появилась вакансия" - не подходит, т.к. не всякая вакансия должна быть закрыта.
2) Ген. директор не отдает заявку в кадры, т.к. это не входит в его набор должностных обязанностей. Заявку отдает начальник подразделения, если она утверждена.
3) Сообщение в АХО об организации рабочего места нужно в том случае если:
Вакансия открыта под новую должность и места такового не существует
В сроки найден новый кандидат, которого примут на работу, и вакансия не "повисла" по разным причинам.
Эти допущения реализованы в моих схемах.
Схемы составлены с точки зрения межпроцессного взаимодействия.
Критика приветствуется.
Разместить_заявку_в_ (21.6 KB, 40 downloads) 12 лет old Подбор_кандидата.png (62.6 KB, 38 downloads) 12 лет old Заявка_на_подбор.png (34.9 KB, 19 downloads) 12 лет old 
Подбор_персонала.bpm (58 KB, 39 downloads) 12 лет old Выкладываю дополнительные схемы которые не влезли в первый ответ
Прием_на_работу_канд (38.4 KB, 16 downloads) 12 лет old Интервью_с_кандидато.png (40.6 KB, 14 downloads) 12 лет old Постарался исправить свой "сырой" вариант, который в начале темы. Вот что получилось.
Прием_на_работу_111.png (225.5 KB, 133 downloads) 12 лет old Добрый день!
У меня родился вот такой вариант описания процесса.
Прием_на_работу_KraYS.png (129.5 KB, 64 downloads) 12 лет old Выкладываю свой вариант с межпроцессными взаимодействиями, хотя на мой взгляд пока получается довольно громоздко.
У Николая вариант похож на правду но не понимаю, что значит одна из развязок - вопрос по развязке в приложении
у Сергея на мой взгляд отработан только happy path а варианты ошибок и неудачных завершений проработаны слабо - из разряда
"оценить соискателя" - а мы его уже где-то нашли?
провести собеседование - а он пришел? а он согласился?
Подбор_персонала_v2.png (200.2 KB, 104 downloads) 12 лет old Подбор_персонала_v2.bpm (75.4 KB, 48 downloads) 12 лет old вопрос для Николая - что означает сия развязка, к чему сообщение?
прием_на_работу_-_воп (14.6 KB, 13 downloads) 12 лет old прием_на_работу_-_воп (21.4 KB, 18 downloads) 12 лет old Подбор сотрудника без конкурса
Подбор_без_конкурса.png (71 KB, 26 downloads) 12 лет old Подбор_без_конкурса.bpm (20.5 KB, 13 downloads) 12 лет old Выкладываю схему процесса, собранную на тренинге 1.10.11
Модель_{Трудоустройс.bpm (30.1 KB, 60 downloads) 12 лет old Отлично!
Единственное к чему могу придраться - "Пригласить на работу" это, скорее, user task и к тому же часть подпроцесса "Оформить на работу".
А я бы придрался еще к "Сообщить об отказе" - это скорее всего send task, а не script task
Цитирую Pavel-Smirnov:
А я бы придрался еще к "Сообщить об отказе" - это скорее всего send task, а не script task
Нет. Это или script task, если имеется в виду информирование по email, или user task, если имеется в виду, что сотрудник отдела кадров должен связаться с соискателем любым способом.
Цитирую Анатолий Белайчук:
Нет. Это или script task, если имеется в виду информирование по email, или user task, если имеется в виду, что сотрудник отдела кадров должен связаться с соискателем любым способом.
Я, наверное, что-то упустил на первом тренинге. Если "информирование по e-mail" - это script task, тогда что такое send task?
Цитирую Pavel-Smirnov:
Я, наверное, что-то упустил на первом тренинге. Если "информирование по e-mail" - это script task, тогда что такое send task?
Send task это строго то же самое, что intermediate message throwing event. Ну с той только разницей, что send task можно исполнить в цикле, а event нельзя.
На аналитической диаграмме это может быть все что угодно, на исполняемой - отправка сообщения от одного процесса другому.
Я конечно извиняюсь, что вмешиваюсь, но приведенные схемы вызвали во мне тихий ужас (извините за эмоции)
1) Попробуйте взять а правило и выстраивать в горизонтальную линию happy path - наиболее желаемый для организации сценарий, а уже все остальные разводить ниже выше. Совет всем авторам - переделайте и увидите как читаемость возрастет
2) Складывается впечатление, что авторы практически не знакомы с множественными экзмеплярами задач, В частности это относится к приему и обработке заявок. Объясню - как только вы размещаете информацию о вакансии в интернете, к вам начинают сыпаться резюме. Именно поэтому с этого момента исполнители по обработке резюме и приглашение на собеседования должны выполняться множественными экземплярами задач ... Обозначаетая это в виде черточек на задаче где возможна параллельная обработка - вертикальные, где последовательная, например проведение собеседований, а за дверью ждут соискатели - горизонтальные черточки.
3) насчет пулов я уже писал - твердо считаю, что в одной диаграмме следует указывать только один процесс и если плодить пулы то только для обозначение сущностей, черных ящиков. А все процессы выносить через подпроцессы реюзебл в другие диаграммы и там делать точно так же. Тогда будет порядок и система с описанием, а не монструозные схемы, в которых каждый работник, желая их исполнить, будет долго вычислять себя) в конце концов главная ценность bpmn в том, что позволяет составлять диаграммы прямого действия, не только и не столько для машин, сколько для людей. А судя по примерам, которые приводят авторы - они создают диаграммы для машин. Для машин существует тьма других инструментариев)
Цитирую neverpoint:
А судя по примерам, которые приводят авторы - они создают диаграммы для машин. Для машин существует тьма других инструментариев)
Да, именно для машин.
А какие именно другие инструменты вы посоветуете?
С уважением, ПС
Цитирую neverpoint:
1) Попробуйте взять а правило и выстраивать в горизонтальную линию happy path - наиболее желаемый для организации сценарий, а уже все остальные разводить ниже выше. Совет всем авторам - переделайте и увидите как читаемость возрастет
Можно моделировать с помощью дорожек, можно с помощью happy path. У обоих способов есть плюсы и минусы; я тоже предпочитаю второй способ, но не стал бы его столь категорично навязывать.
Цитирую neverpoint:
2) Складывается впечатление, что авторы практически не знакомы с множественными экзмеплярами задач, В частности это относится к приему и обработке заявок. Объясню - как только вы размещаете информацию о вакансии в интернете, к вам начинают сыпаться резюме. Именно поэтому с этого момента исполнители по обработке резюме и приглашение на собеседования должны выполняться множественными экземплярами задач ... Обозначаетая это в виде черточек на задаче где возможна параллельная обработка - вертикальные, где последовательная, например проведение собеседований, а за дверью ждут соискатели - горизонтальные черточки.
Складывается впечатление, что вы с multi-instance циклом тоже знакомы не очень хорошо. Объясняю: цикл по объектам можно использовать только в ситуации, когда объем работы - число повторений цикла - известен до начала цикла. В данном случае число резюме заранее неизвестно, поэтому цикл по объектам использовать не получится.
Цитирую neverpoint:
3) насчет пулов я уже писал - твердо считаю, что в одной диаграмме следует указывать только один процесс и если плодить пулы то только для обозначение сущностей, черных ящиков. А все процессы выносить через подпроцессы реюзебл в другие диаграммы и там делать точно так же. Тогда будет порядок и система с описанием, а не монструозные схемы, в которых каждый работник, желая их исполнить, будет долго вычислять себя) в конце концов главная ценность bpmn в том, что позволяет составлять диаграммы прямого действия, не только и не столько для машин, сколько для людей. А судя по примерам, которые приводят авторы - они создают диаграммы для машин. Для машин существует тьма других инструментариев)
Считать так вы конечно можете, но это означает отказ от моделирования межпроцессного взаимодействия.
Предложите свою схему, посмотрим насколько она будет "для людей".
Цитирую Анатолий Белайчук:
Считать так вы конечно можете, но это означает отказ от моделирования межпроцессного взаимодействия.
А кто отказывается от межпроцессорного взаимодействия? можно показывать это взаимодействие иными способами, нежели раскрывать нутро других процессов в схеме процесса. К тому же исполнителю процесса не всегда необходимо знать внутренние процессы, исполнитель которого другой участник. Мало того, лучше бы его процесс взаимодействовал с процессом другого участника без раскрытия внутренностей, путем обмена сообщений и тп.
Судя по реакции на мои комментарии, я хочу оговориться, что 15 лет занимаюсь моделированием процессов, но с нотацией BPMN знаком недавно и потому могу ошибаться в плане обозначений. Что касается самого моделирования, логики, принципов - это обкатано в полевых условиях, но не с помощью данной нотации. Грубо говоря, если я не знаю французский язык, это не значит что я не вылечу зуб французу, являясь стоматологом)
Цитирую Анатолий Белайчук:
Складывается впечатление, что вы с multi-instance циклом тоже знакомы не очень хорошо. Объясняю: цикл по объектам можно использовать только в ситуации, когда объем работы - число повторений цикла - известен до начала цикла. В данном случае число резюме заранее неизвестно, поэтому цикл по объектам использовать не получится.
Предложите свою схему, посмотрим насколько она будет "для людей".
Вот как раз "люди" в при просмотре резюме и при собеседовании используют пакетный подход. Никто не бежит сломя голову при звуке поступившего емейла с резюме его рассматривать. Кадровик смотрит - поступило 10 экземпляров резюме и выделяет время рабочее для рассмотрения этих резюме. Затем приходит в назначеное время 8 кандидатов, сидят в приемной - то же заведомо известно количество. Ситуации, когда события сыплются спонтанно и в неизвестном количестве, а исполнитель словно теннисист на тренажере отрабатывает эти события, похоже скорее не на людей, а на компьютер, которые обрабатывает запросы по мере их поступления...
В свете последних комментариев во всех ветках, призываю участников форума, имеющих техническое образование, в том числе в области программирования - постараться не поддаваться соблазну использовать эти знания в проектировании процессов с человеческим лицом. Я сам в далеком прошлом программист и знаю, как этот соблазн мешает учитывать человеческий фактор призывая людей работать как машины, а не машины для людей. Кстати на личной странице Анатолия я читал про человеческий фактор и призывы создавать диаграммы для людей, а не продавливать людей под схемы. Вспоминается борьба с протоптанными тропинками по газонам - не проще положить асфальт, чем людей переделывать, тем более если так людям удобно?
Цитирую neverpoint:
А кто отказывается от межпроцессорного взаимодействия?
Я сказал "отказ от моделирования межпроцессного взаимодействия". Как еще прикажете трактовать ваш призыв "одна страница - один процесс"?
Цитирую neverpoint:
можно показывать это взаимодействие иными способами, нежели раскрывать нутро других процессов в схеме процесса.
Можно показать? Так покажите, а мы посмотрим.
Цитирую neverpoint:
К тому же исполнителю процесса не всегда необходимо знать внутренние процессы, исполнитель которого другой участник. Мало того, лучше бы его процесс взаимодействовал с процессом другого участника без раскрытия внутренностей, путем обмена сообщений и тп.
"Процесс участника"?!! Это что вообще такое? Какой-то оксюморон.
Цитирую Анатолий Белайчук:
"Процесс участника"?!! Это что вообще такое? Какой-то оксюморон.
В моем подходе к моделированию процессов, каждый процесс обязательно должен иметь родительскую задачу. Так вот исполнитель этой родительской задачи и есть то самый участник (корректнее было конечно назвать исполнитель, я допустил неточность), а процесс, который вложен в эту задачу - процесс исполнителя. Но его можно назвать и процесс участника, ибо исполнитель родительской задачи фактически является участником вложенного процесса ибо контролирует вложенные задачи, у которых свои исполнители - тем самым принимая участие. Исполнителя родительской задачи, в которую включен процесс, иначе я называю руководителем процесса. Руководитель процесса вправе на ходу изменить вложенный в его задачу процесс если готов взять на себя ответственность за достижения цели процесса. У него особые полномочия и он таким образом участник вложенного процесса
Павел,
схема в лучших традициях тренинга :)
А что если кандидата записывать в базу, даже если вакансии пока нет? Так, на будущее.
И еще такой момент: Вы не допускаете мысли, что ни один кандидат не подаст резюме? (я сейчас знаю две компании, которые не могут найти сотрудника на вакантную должность, и они ищут сами, и уже не один месяц!) Я бы предусмотрела и активный поиск. В Вашей схеме предусмотрено, что выбор не состоялся, т.е. с точки зрения техники все будет ок., но как-то неправильно заведомо пустой список обрабатывать.
Еще: представьте ситуацию, когда пришел кандидат, который просто супер как подходит, и это ясно с первого взгляда, и вы не можете его упустить. А у Вас в процессе выбор состоится только через четыре недели. Что будете делать в этом случае?
можно показывать это взаимодействие иными способами, нежели раскрывать нутро других процессов в схеме процесса.
Показать - можно, сделать исполняемым - нельзя.
В принципе, можно вообще все процессы изобразить в виде пулов. Получится High level diagramm. С точки зрения полезности - это "маст хэв".
Теперь представите себе, что Вы детализировали один процесс, который, в числе прочих действий, обменивается сообщениями с другим процессом. Вы предлагаете тот другой процесс оставить в виде пула? Ок. Но как Вы укажете, какое сообщение кто принимает, если сообщений несколько разных? На межпроцессной диаграмме Вы должны их соединить непосредственно Message Event отправитель - Message Event получатель.
Мне кажется, что у Вас опыт описания процессов, но Вы не представляете себе, как это работает в BPMS. Это не умаляет Вашего опыта, но здесь на форуме у участников конечная цель - исполняемые процессы, т.к. сам форум - это тоже часть вполне конкретного тренинга. Поэтому просто постарайтесь смотреть на работы через эту же призму.
Цитирую Юлия Вагнер:
Так, на будущее.
Процесс приема на работу неисчерпаем, как электрон.
Цитирую Анатолий Белайчук:
Процесс приема на работу неисчерпаем, как электрон.
Скорее "как атом", ибо, согласно современным представлениям физики элементарных частиц, электрон неделим и бесструктурен (как минимум до расстояний 10−17 см).
Цитирую Юлия Вагнер:
Теперь представите себе, что Вы детализировали один процесс, который, в числе прочих действий, обменивается сообщениями с другим процессом. Вы предлагаете тот другой процесс оставить в виде пула? Ок. Но как Вы укажете, какое сообщение кто принимает, если сообщений несколько разных? На межпроцессной диаграмме Вы должны их соединить непосредственно Message Event отправитель - Message Event получатель..
Вообще то в нотации 2.0 для этого предназначена диаграмма обмена сообщениями - которое не то же самое что и диаграмма процесса. Если почитаете комментарии работников IBM то вся эта канитель с уточнением понятия хореографии и диаграммами обмена сообщений была введена чтобы не городить монструозные трудночитаемые диаграммы процессов где рабочий процесс окружен кучей пулов и стрелок взаимодействия с внутренностями этих пулов, содержащих процессы. Таким образом работник имеет дело с самой диаграммой процесса и диаграммами обмена сообщений и хареографиями, регламентирующими этот обмен. Грубо говоря диаграмма обмена сообщениями и хареография это интерфейс обмена процесса с другими процессами и протокол этого обмена. Привязка при межпроцессорном взаимодействии к внутренностям процессов уменьшает гибкость или иными словами руководство множеством процессов в компании. Точки входа выхода в процессе соединяются с задачами в процессе внутри и могут изменятся не меняя завязанные на этом процессе другие задачи. Зачем дергать другой отдел или работника что изменилась диаграмма если при этом межпроцессорном взаимодействие осталось прежним? Это я про гибкость - есть и еще много нюансов но не будем о них тут
Вы беретесь рассуждать о том, в чем слабо разбираетесь. Одна "хареография" чего стоит. К вашему сведению, диаграмма обмена сообщений ("хареография") есть принадлежность BPMN 1.x. А в BPMN 2.0 это понятие не уточнилось, а полностью переопределено. (За что, кстати, авторам отдельное "спасибо".)
Цитирую Анатолий Белайчук:
Вы беретесь рассуждать о том, в чем слабо разбираетесь. Одна "хареография" чего стоит. К вашему сведению, диаграмма обмена сообщений ("хареография") есть принадлежность BPMN 1.x. А в BPMN 2.0 это понятие не уточнилось, а полностью переопределено. (За что, кстати, авторам отдельное "спасибо".)
Сразу попрошу прощения, я почему-то диаграмму взаимодействия обозвал диаграммой обмена сообщениями, хотя отчасти это и так ибо хореография описывает последовательность обмена сообщениями и мало того!! внимание - вы можете включить логику в порядок обмена сообщениями!
Диаграмма взаимодействия, на мой взгляд, как раз удачно определена в BPMN 2.0 и решает множество "бытовых" задач бизнеса. Постараюсь рассказать простым языком, чтобы донести до всех суть.
Ваша компания заключает договор на обслуживание с сервисной фирмой по обслуживанию, скажем, линии по производству йогуртов. Поскольку обслуживание такое подразумевает множество работ, как по объему так и по времени, профилактических и срочных - то необходима четкая регламентация взаимодействия между вами (из контекста ясно, что вы это молокозавод) и сервисной компанией. Но как эту регламентацию осуществить не вмешиваясь в процессы друг друга, но при этом задав логику совместной работы? И тут приходит на помощь диаграмма взаимодействия - хореография
1) В такой диаграмме задачи - почти как стандартные задачи, но в них присутствуют участники взаимодействия (они отображаются внутри значка задачи). Эти задачи могут связываться в цепочку, в которой могут присутствовать логические операции, например распараллеливание (ну прям как в диаграмме процесса!)
2) Общение вашей фирмы и сервисной компании обозначаются на диаграмме взаимодействия цепочкой таких задач, хореографией в которой могут участвовать и другие фирмы (например таможенные брокеры, если запчасти импортные и нужна растаможка, транспортники и тп)
3) при таком раскладе вы можете сконцентрировать внимание читающего диаграмму именно на логике взаимодействия, а не внутренних процессах друг друга.
4) и так - вы начертили диаграмму взаимодействия - создали четкую хореографию в виде приложения к договору обслуживания вашей производственной линией. Хореография согласована, договор подписан, вы спокойно улетаете на моря, а работники вашей фирмы и сервисной слаженно работают, словно танцуют, следуя утвержденной хореографией. Не работа, а танец!
Резюме - Диаграммы обмена сообщениями с использованием задач хореографии значительно упрощают описание взаимодействия различных сущностей. Участникам не нужно вникать куда улетают их запросы в недра процесса другой Фирмы и когда они оттуда вернутся, причем если это обучная диаграмма процессов, то дико разным юрлицам совать нос почему там затормозилось и видеть какие то задачи согласования и прочее. Есть договор меджу юрлицами и он все регламентирует.
P.S. Немного лирики. Кабинетная система, когда для получения справки вас гоняли по кабинетам, то есть заставляли участвовать в бизнес процессе чужой организации шляясь по разным этажам - и есть типичный пример отсутствия хореографии. Пример ее присутствия - система одного окна или как сейчас модно, портала государственных услуг.
Полная каша. Диаграмма взаимодействия (collaboration diagram), диаграмма хореографии (choreography) и диаграмма обмена сообщениям (conversation) - это три разных вида диаграмм BPMN 2.0.
Вы меня извините за прямоту, но я опасаюсь за ваш английский. Взаимодействие по английски это не что иное как interaction...
BPMN 2 has two diagrams for interactions: Collaboration and Choreography.
The first is available in BPMN 1.x, and enhanced in BPMN 2, while the second
is in BPMN 2 only. The diagrams show different aspects of interactions,
sometimes using different notations for the same concepts, or highlighting
some concepts over others.
(c) Conrad Bock, National Institute of Standards
and Technology, USA, and Stephen A. White
PhD, International Business Machines
Если у вас возникла каша от написанного мной, то я готов ответить на любые вопросы и разъяснить каждое слово...
С моим английским, в отличие от вашего русского, все в порядке. По крайней мере у англоязычных читателей http://www.mainthing.ru претензий до сих пор не возникало. Предлагаете переводить collaboration diagram как "диаграмма сотрудничества"?
Перечитайте свое предыдущее сообщение - вы употребляете термин "диаграмма взаимодействия" и тут же упоминаете хореографию (хорошо что не хареографию). При этом судя по контексту, имеется в виду Choreography. Будьте поаккуратнее с терминологией, во избежание неоднозначности советую давать в скобках английский термин.
Что касается вашего источника, то он не вполне прав: в BPMN 1.x хореография уже была, только этим термином в нем называлось то, что сейчас (в BPMN 2.0) называется collaboration. И он неправ дважды, потому что в BPMN 2.0 есть еще диаграмма conversation, которая описывает еще один аспект interaction.
Цитирую Анатолий Белайчук:
С моим английским, в отличие от вашего русского, все в порядке. По крайней мере у англоязычных читателей http://www.mainthing.ru претензий до сих пор не возникало. Предлагаете переводить collaboration diagram как "диаграмма сотрудничества"?Перечитайте свое предыдущее сообщение - вы употребляете термин "диаграмма взаимодействия" и тут же упоминаете хореографию (хорошо что не хареографию). При этом судя по контексту, имеется в виду Choreography. Будьте поаккуратнее с терминологией, во избежание неоднозначности советую давать в скобках английский термин.
Что касается вашего источника, то он не вполне прав: в BPMN 1.x хореография уже была, только этим термином в нем называлось то, что сейчас (в BPMN 2.0) называется collaboration. И он неправ дважды, потому что в BPMN 2.0 есть еще диаграмма conversation, которая описывает еще один аспект interaction.
В русском языке я не специалист, так что могу ошибаться грамматически, но не логически. Предлагаю не путать более общее понятие взаимодействия с более узким collaboration и разделять их, да пусть будет "сотрудничество". . Что касается источника, это из книги BPMN 2.0 Handbook second edition, в написании которой приняли участие разработчики стандарта BPMN 2.0 - считаю, что авторам виднее что они имели в виду
Увы и ах, но даже авторы, принимавшие участие, ошибаются - несколько установленных фактов есть у меня на блоге. Стандарт BPMN - это плод коллективного творчества: масса организаций и отдельных лиц вносят свой вклад. Отсюда неточности и расхождения в трактовках.
Вы же любите читать первоисточники - проверьте сами и убедитесь.
Цитирую Анатолий Белайчук:
Увы и ах, но даже авторы, принимавшие участие, ошибаются - несколько установленных фактов есть у меня на блоге. Стандарт BPMN - это плод коллективного творчества: масса организаций и отдельных лиц вносят свой вклад. Отсюда неточности и расхождения в трактовках.Вы же любите читать первоисточники - проверьте сами и убедитесь.
Читаю изучаю... Уже писал, что планируем переход на нотацию BPMN 2.0 отсюда интерес в тч к форуму. Сама нотация грамотная, интерпретации у всех разные. Думаю прав тот, у которого это реально, а не формально работает. Любая реально работающая схема, даже клинописью лучше самой придуманной модели, на местах которую игнорируют и продолжают работать передавая друг другу что делать из уст в уста
Вы должны авторизоваться, чтобы публиковать сообщения.
