Процесс гарантийного ремонта
Файлы
-
Ремонт.bpm (22.5 KB, 39 downloads) 12 лет old
-
Опубликовано 12 лет назад #
-
Последняя версия, надписал выходы. Изменил немного выход первого подпроцесса.
Файлы
- Ремонт_v.3.bpm (35.8 KB, 76 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
В порядке придирки: "успешные" выходы из подпроцессов не должны называться "Передача на входной контроль", "Передача на исследование" и т.п. Куда (в какой подпроцесс) переходить дальше - это дело вышестоящего уровня (в данном случае процесса верхнего уровня). Дело же рассматриваемого подпроцесса - доложить "наверх", что все в порядке или что произошло какое-то отклонение. А там уж пусть принимают решение.
Поэтому выходы должны назваться соответственно "Ремонт у производителя", "Изделие принято", т.е. быть привязаны к контексту текущего, а не следующего подпроцесса.
Можно просто и без затей назвать их "Успех".
Или же можно принять соглашение, что выход без имени (как в подпроцессе "Оформить акт исследования") всегда соответствует успешному (желаемому) завершению. Разумеется, больше одного безымянного выхода быть не может.
А в остальном выглядит очень симпатично.
Опубликовано 12 лет назад # -
Можно вопрос? Зачем проверка "Гарантийное письмо получено?" после активности "Получить гарантийное письмо"? Разве возможна ситуация, когда гарантийное письмо не получено, и при этом активность "получить гарантийное письмо" завершена?
Файлы
-
Image_002.jpg (22.7 KB, 12 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Активность "Получить гарантийное письмо" - это не активность, а ожидание наступления одного из событий: "письмо получено" или "все мыслимые сроки ожидания вышли (и, значит, больше письма не ждем)".
Поэтому я бы нарисовал диаграмму немного по-другому. С учетом сказанного выше и, плюс к тому, - еще бы добавил возможность выхода из активности "Принять решение о возможности ремонта" при наступлении события "гарантийное письмо таки получено" (а вдруг письмо получим в момент принятия решения о возможности ремонта)
Файлы
- Image_003.jpg (100.2 KB, 32 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Павел
Хороший вопрос. Ответ: оба варианта корректны.
В исходной схеме мы ставим задачу человеку: "выбей из заказчика гарантийное письмо". Как он с ним связывается и когда решает бросать это безнадежное дело - его проблема. Для нас важно, чтобы он в конце концов нам сказал - получилось или нет.
В Вашей схеме подразумевается, что гарантийное письмо неким автоматическим образом попадет в наш процесс. Каким именно? Ну например как-то так: http://mainthing.ru/ru/item/482/
Вопрос: а надо ли нам заморачиваться всеми этими сообщениями или проще вернуться к исходной схеме? В ней которой есть человек, который за все отвечает. С точки зрения владельца процесса, понятно и комфортно.
Опубликовано 12 лет назад # -
Мне сразу бросились в глаза две присоединенные ошибки к задаче проверки ремонта - рекламация на месте и ремонт на месте, сразу возникло ощущение что что то не так. Заглянув внутрь я понял - автор смешал функциональные уровни задач. Задачу ремонта на месте нужно было вынести в главную диаграмму, как и рекламацию на месте. Ведь на этом же уровне и обычный ремонт - а они могут коррелировать по запчастям и прочим общим объектам. Изменения сценария ремонта путем выхода через ошибку выглядит неестественным - это же не нарушения хода задачи а один из вариантов развития событий
Опубликовано 12 лет назад # -
Цитирую neverpoint:
Заглянув внутрь я понял - автор смешал функциональные уровни задач. Задачу ремонта на месте нужно было вынести в главную диаграмму, как и рекламацию на месте. Ведь на этом же уровне и обычный ремонт - а они могут коррелировать по запчастям и прочим общим объектам.Сложно же будет читать диаграммы, в которых запрещено использование подпроцессов в угоду правилу "все, что на одном уровне, рисовать на главной диаграмме" :)
Опубликовано 12 лет назад # -
Цитирую neverpoint:
Ведь на этом же уровне и обычный ремонт - а они могут коррелировать по запчастям и прочим общим объектам.И...? Поясните свою мысль пожалуйста - как корреляция по общим объектам относится к разбиению на подпроцессы?
Цитирую neverpoint:
Изменения сценария ремонта путем выхода через ошибку выглядит неестественным - это же не нарушения хода задачи а один из вариантов развития событийВы узко трактуете событие "ошибка", буквально трактуя его название.
Опубликовано 12 лет назад # -
Цитирую Анатолий Белайчук:
И...? Поясните свою мысль пожалуйста - как корреляция по общим объектам относится к разбиению на подпроцессы?Вы узко трактуете событие "ошибка", буквально трактуя его название.
Прелесть нотации BPMN в том, что ее без особой подготовки у меня читает и секретарша и охранник, но только если сохранить естесственность условных обозначений нотации. Как только мы начинаем жанглировать понятиями терминами и правилами то специалисты может нас и поймут, но информационная ценность диаграмм как инструкций прямого действия очень пострадает.
Опубликовано 12 лет назад # -
Цитирую neverpoint:
Прелесть нотации BPMN в том, что ее без особой подготовки у меня читает и секретарша и охранник, но только если сохранить естесственность условных обозначений нотации. Как только мы начинаем жанглировать понятиями терминами и правилами то специалисты может нас и поймут, но информационная ценность диаграмм как инструкций прямого действия очень пострадает.А Вы не называйте это "ошибкой", а обзовите, ну допустим "статус завершения", и все встанет на свои места. Не все в мире заканчивается хорошо или плохо, иногда бывает "как-то так получилось" ))
Опубликовано 12 лет назад # -
Цитирую Анатолий Белайчук:
И...? Поясните свою мысль пожалуйста - как корреляция по общим объектам относится к разбиению на подпроцессы?Вы узко трактуете событие "ошибка", буквально трактуя его название.
Кстати - стандарт BPMN 2.0 указывает на возможность внутрикорпоративных уточнений этого стандарта. Хотелось бы услышать от Анатолия, считает ли он правильным (во избежании путаницы при внедрении), при переходе компании на модель описания бизнес процессов путем BPMN создание внутрикорпоративных правил использования нотации, к примеру уточнение правил использования различных событий, задач, артефактов и тп... И если да, то хотелось бы посмотреть отрывок такого примера. Очень много тем на форуме посвящены толкованию того или иного случая использования обозначений, при условии конечно если речь не идет о прямом противоречии стандарту...
Опубликовано 12 лет назад # -
Цитирую neverpoint:
Прелесть нотации BPMN в том, что ее без особой подготовки у меня читает и секретарша и охранник, но только если сохранить естесственность условных обозначений нотации. Как только мы начинаем жанглировать понятиями терминами и правилами то специалисты может нас и поймут, но информационная ценность диаграмм как инструкций прямого действия очень пострадает.Кому поп, кому попадья, а кому свинячий хрящик. Можно рисовать "аналитические" диаграммы - плюсом будет интуитивная понятность, минусом - масса недоговоренностей и белых пятен. А можно рисовать "исполняемые" диаграммы, и плюсы с минусами поменяются местами.
Прелесть BPMN не в том, что он прост и всем понятен, а в том, что он методологически нейтрален - разные люди используют его очень по-разному и для очень разных целей. На вещи надо смотреть ширше, а к людЯм быть мягше.
Цитирую neverpoint:
Кстати - стандарт BPMN 2.0 указывает на возможность внутрикорпоративных уточнений этого стандарта. Хотелось бы услышать от Анатолия, считает ли он правильным (во избежании путаницы при внедрении), при переходе компании на модель описания бизнес процессов путем BPMN создание внутрикорпоративных правил использования нотации, к примеру уточнение правил использования различных событий, задач, артефактов и тп... И если да, то хотелось бы посмотреть отрывок такого примера. Очень много тем на форуме посвящены толкованию того или иного случая использования обозначений, при условии конечно если речь не идет о прямом противоречии стандарту...BPMN эклектичен и избыточен. Поэтому безусловно, эффективное его использование предполагает выработку внутреннего соглашения по моделированию. Но только сами, все сами...
Опубликовано 12 лет назад #
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.