Дмитрий, добрый день.
Вы затронули тему малоценности товара. Это еще больше лишает смысла видеть БП в том виде, как он описан в условии задачи. Дороже будет возврат...
Дмитрий, добрый день.
Вы затронули тему малоценности товара. Это еще больше лишает смысла видеть БП в том виде, как он описан в условии задачи. Дороже будет возврат...
В описании процесса указано, что один из вариантов действий - это утилизация товара клиентом на месте с предоставлением гарантий утилизации.
Принцип клиенто-ориентированности в данном процессе выражается в том, что:
1. мы работаем с любыми обращениями (если клиент обратился, то означает, что он не ушел)
2. надо понять по какой причине некачественный товар попал к клиенту или стал таковым в процессе хранения, транспортировки, реализации и т.д. Соответственно, аналитики должны предложить программу минимизации возвратов
3. есть параметры (метрики) самого процесса возврата - скорость реакции, общее время, финансовые затраты на оформление документов, транспортировку, складские операции и т.д.
4. Вы абсолютно правы, что есть финансовые нюансы связанные с ценообразованием, но я бы добавил, что есть и другие моменты - товар, который лежит на складе, тоже меняет свою ценность (складские издержки, замороженные средства, вопросы сезонности или потери новизны). Соответственно, если возвращается кондиционный товар, то необходимо учитывать эти факторы - возможно имеет смысл дать дополнительную скидку для реализации или вообще пойти на нетрадиционные шаги - промо-акции, благотворительсть и т.д.
5. Можно совместить процессный подход не только с системами класса CRM, но и с системами риск-менеджмента (хотя некорые CRM включают эти возможности изначально). Я имею в виду, что можно ввести систему репутации клиентов и учитывать эту репутацию при заключении договоров.
6. Разработать систему мониторинга процесса, применять инструменты бизнес-аналитики. Провести кластерный анализ клиентов. На основе этого проводить не ковровую маркетинговую политику, а избирательную.
Дмитрий, я не знаю, насколько глубоки Ваши притязания в акцентировании на клиенто-ориентированности, но мое лично мнение, что можно пойди настолько далеко, насколько это будет требовать сам бизнес. ОН должен быть готов к тому, чтобы определить разумные границы.
Еще раз спасибо за Ваше участие.
Дмитрий, у меня нет притязаний:-))
Спасибо за ответ!
Я может быть не совсем корректно выразил мысль, которую хотел донести.
А мысль в следующем.
Есть бизнес-процесс "возврат товара". Было дано его описание.
Так вот мое мнение, что описание этого бизнес-процесса было слишком усложнено.
Я бы описал задачу гораздо короче:
1. есть причина возврата товара со стороны клиента (например, брак, несезонность и др.);
2. есть сам возвращаемый товар (со всеми артикулами, сроками и т.д.);
3. есть условия возврата товара (договор, целостность упаковки, гарантия и т.д.);
4. есть процедура оформления возврата (непосредственно приемка товара от клиента).
Все остальные данные либо укладываются в эти пункты, либо не имеют непосредственного отношения к возврату товара, имхо.
Да, и еще. По поводу Вашего 2-го пункта про причины брака. Не относится понимание того, из-за чего к клиенту попал брак, к БП "Возврат товара". Это я точно знаю.
А про клиенто-ориентированность (пусть будет через дефис:-)) это же не я придумал, это из вводной:-))
Удачи!
Кстати, 4-ый пункт скорее относится к БП "Складская логистика", надо просто запустить этот процесс, имхо.
Коллеги
Это все конечно очень интересно, но условно-финальную схему мы увидим?
Коллеги, добрый вечер!
Условно финальная версия БП. Из основных изменений – инициировать процедуру возврата может как поступление «Обращение», так и комплекта документов на возврат установленного образца.
Евгений!
Не до конца ясна логика одновременной отправки двух сообщений после "Записать в БД" из процесса "Получения претензионных документов". Поясните, пожалуйста.
Цитирую Pavel-Smirnov:
Евгений!Не до конца ясна логика одновременной отправки двух сообщений после "Записать в БД" из процесса "Получения претензионных документов". Поясните, пожалуйста.
Полагаю, там должна быть развилка или/или.
Еще замечания:
- в этом же пуле задача "Идентифицировать" должен читать БД
- БД соединена с задачами потоками сообщений
Eugen,
А если клиенту отказано в регистрации претензии, а он все равно присылает претензионные документы? Наверное, после шага "Идентифицировать" в процессе "Получение претензионных документов" надо просто проверить, принята ли претензия.
и еще вопрос:
в процессе "жизненный цикл претензии" стоит inclusive event. Если по условию запущены обе ветки - получен товар и получены документы, а потом одна из веток прервется (например, отклонено по товару). То что произойдет на собирающем гейтвее - он будет ждать прихода всех запущенных веток? Или нужно ставить терминатор, чтобы все прихлопнул?
Цитирую Юлия Вагнер:
Или нужно ставить терминатор, чтобы все прихлопнул?
Кстати да.
Здравствуйте! По процессу, я смотрю, жизнь бьет ключом… ок, продолжим.
По замечания:
1. Павел, Вы правы должно быть или/или.
2. Анатолий, по первому пункту согласен, должна и теперь читает, также добавил чтение из БД в пуле оприходование.
По второму пункту не понял, а где не поток сообщений?
3. Юлия, согласен замечание по делу, но в данном случае цель была разгрузить схему. На мой взгляд, все разборки с документами будут происходить в подпроцессе «Обработать документ».
4. Согласен, терминаторы к месту.
Цитирую Eugen:
1. Павел, Вы правы должно быть или/или.
Евгений, "или/или" что? Поясните - что проверяет этот гейт и какие значения могут принимать результат проверки?
У вас или гейт лишний, или процесс "Жизненный цикл претензии" стартует дважды на одну претензию, или я "чего-то не догоняю".
С уважением, ПС.
Цитирую Pavel-Smirnov:
Евгений, "или/или" что? Поясните - что проверяет этот гейт и какие значения могут принимать результат проверки?
У вас или гейт лишний, или процесс "Жизненный цикл претензии" стартует дважды на одну претензию, или я "чего-то не догоняю".
С уважением, ПС.
Коллеги, тут именно должна быть параллельная развилка. Один поток будет направлен на получение товара на склад, а другая будет направлена на обработку документов в подпроцессе "Получение оригинальных документов"(поскольку обработка документов уже была проделана в процессе "Получение приетензионных документов"). Необходимо поставить условие на нижней ветки развилки Inclusive Gateway процесса "Жизненный цикл претензий".
Цитирую mousem:
Коллеги, тут именно должна быть параллельная развилка. Один поток будет направлен на получение товара на склад, а другая будет направлена на обработку документов в подпроцессе "Получение оригинальных документов"(поскольку обработка документов уже была проделана в процессе "Получение приетензионных документов"). Необходимо поставить условие на нижней ветки развилки Inclusive Gateway процесса "Жизненный цикл претензий".
mousem,
Ничего не понял из вашего объяснения. Нарисуйте на диаграмме, пожалуйста.
Mousem,
На схеме нарисовано, что message event из процесса "Получение претенз. документов" запускает экземпляр процесса "Жизненный цикл". Но разве message event из процесса "Обращение" уже раньше не запустил экземпляр процесса "Жизненный цикл"?
И еще. Даже если есть какой-то смысл в том, чтобы message event из процесса "Получение претенз. документов" запустил экземпляр процесса "Жизненный цикл", в этом случае второму (параллельному) message event из процесса "Получение претенз. документов" некуда будет прийти, потому что в подпроцессе "Получение оригиналов документов" еще не выполнены задачи, расположенные перед событием - приемкой сообщения из процесса "Получение претенз. документов".
Как-то так.
А когда будет второй тренинг? Хочется уже увидеть правильный вариант :)
Цитирую Pavel-Smirnov:
Mousem,На схеме нарисовано, что message event из процесса "Получение претенз. документов" запускает экземпляр процесса "Жизненный цикл". Но разве message event из процесса "Обращение" уже раньше не запустил экземпляр процесса "Жизненный цикл"?
По сути обращением может являться Непосредственное вербальное обращение клиента ( звонок, письменное обращение и т.д.) или непосредственная отправка документов. Поэтому возможно 2 варианта запуска экземпляра процесса "Жизненный цикл".
На рисунке показан условный ход потоков.
PS Условия на нижней ветки развилки Inclusive Gateway процесса "Жизненный цикл претензий" не должно быть.
Mousem,
И еще замечание - ветки из гейтов не могут подписываться вопросами. У вас подписано "Получены документы?" - так нельзя. Прочитав вопрос, программа не поймет - идти ей по этой ветки или не идти.
Цитирую Pavel-Smirnov:
Mousem,И еще замечание - ветки из гейтов не могут подписываться вопросами. У вас подписано "Получены документы?" - так нельзя. Прочитав вопрос, программа не поймет - идти ей по этой ветки или не идти.
К сожалению 3-ий курс будет происходить лишь в эту субботу. Поэтому данная интерпретация модели воспринимается нами лишь как наглядная схема.
В предыдущем посту я пояснил, что все таки условия "Получены документы?" не должно быть.
А как правильно тогда подписать ветку, чтобы программа ее правильно восприняла и наглядно можно было понять ход процесса? Поясните пожалуйста.
Цитирую mousem:
По сути обращением может являться Непосредственное вербальное обращение клиента ( звонок, письменное обращение и т.д.) или непосредственная отправка документов. Поэтому возможно 2 варианта запуска экземпляра процесса "Жизненный цикл".
А вот и не возможно. Если у вас не сработает процесс "Обращение", у вас не появится запись в БД и, значит, вы не сможете идентифицировать полученные документы или товар на склад.
А еще красную линию вы нарисовали по-хитрому. После гейта линия разойдется по каждой из трех выходящих веток гейта.
Вы написали "3-ий курс". А что - второй уже был? Схема, которую вы выложили, - это результат работы на 2-ом тренинге?
Цитирую Pavel-Smirnov:
А вот и не возможно. Если у вас не сработает процесс "Обращение", у вас не появится запись в БД и, значит, вы не сможете идентифицировать полученные документы или товар на склад.А еще красную линию вы нарисовали по-хитрому. После гейта линия разойдется по каждой из трех выходящих веток гейта.
Вы написали "3-ий курс". А что - второй уже был? Схема, которую вы выложили, - это результат работы на 2-ом тренинге?
Вы правы - тут уже обсуждается результат работы 2-ого тренинга.
Красная линия пойдет в реале по 2-ум веткам, одна из которых будет ожидать реального прихода документов, другая приход товара. 3-я( то есть верхняя ветка) должна была быть с чертой,т.е. быть "по умолчанию". Мы кстати не поняли как поставить эту черточку.
На сколько я помню, если не удалось идентифицировать документы, то в задаче "записать в БД" неявно создается обращение. Анатолий Белайчук на тренинге оговорил, что запись в БД Datastore происходит неявно и указывать ее не надо.
Вы к сожалению не ответили на вопрос:
Цитирую mousem:
А как правильно тогда подписать ветку, чтобы программа ее правильно восприняла и наглядно можно было понять ход процесса? Поясните пожалуйста.
1. Переход по-умолчанию активизируется только если условия для всех остальных путей оказались ложными - это правило из методички, которую раздавали на первом тренинге.Зачем вам переход по умолчанию, если все остальные пути у вас не подписаны условиями? На вашей диаграмме сработают все три ветки из гейта в процессе "Жизненный цикл". И, кстати, пустая ветка там вообще лишняя (бессмысленная)
2. Представим ситуацию, что вы получили документы, не получив предварительно обращения. Документы будут обработаны, проверены и записаны в БД. А потом процесс одновременно отправит два сообщения, одно из которых стартует процесс "Жизненный цикл", но куда отправляться второму? Второе сообщение еще никто не ждет, ведь еще не выполнены задачи "Записать в БД" и "Оповестить клиента об ожидании документов".
3. Я не могу "правильно подписать ветку", потому что вообще не понимаю как работает ваш процесс. Но я такой же ученик, как и вы. Вот заглянет Анатолий или Юлия, они обязательно подскажут.
С уважением, ПС.
Цитирую Pavel-Smirnov:
1. Переход по-умолчанию активизируется только если условия для всех остальных путей оказались ложными - это правило из методички, которую раздавали на первом тренинге.Зачем вам переход по умолчанию, если все остальные пути у вас не подписаны условиями? На вашей диаграмме сработают все три ветки из гейта в процессе "Жизненный цикл". И, кстати, пустая ветка там вообще лишняя (бессмысленная)
2. Представим ситуацию, что вы получили документы, не получив предварительно обращения. Документы будут обработаны, проверены и записаны в БД. А потом процесс одновременно отправит два сообщения, одно из которых стартует процесс "Жизненный цикл", но куда отправляться второму? Второе сообщение еще никто не ждет, ведь еще не выполнены задачи "Записать в БД" и "Оповестить клиента об ожидании документов".
3. Я не могу "правильно подписать ветку", потому что вообще не понимаю как работает ваш процесс. Но я такой же ученик, как и вы. Вот заглянет Анатолий или Юлия, они обязательно подскажут.
С уважением, ПС.
Интересно получается - Вы говорите, что неправильно подписывать ветку, но не говорите как правильно. Ждем участия в дискуссии Анатолия тогда.
Ветка 3-я бессмысленна - согласен. Вопрос "Как поставить черточку?", чтобы было видно что данная ветка "по умолчанию" - остается в силе.
Задачи "Записать в БД" и "Оповестить клиента об ожидании документов" - это секундное дело. Возможно стоит поставить таймер на отправку сообщения из процесса "Получение претенз. документов" в подпроцесс "Получение оригиналов документов". Появляется одна нестыковка - клиент уже отправил нам документы и мы его вновь оповещаем о необходимости снова прислать документ.
Во нафлудили! :) На самом деле я конечно рад, что форум зажил. ОК, будем разгребать.
Опубликованная версия - это итог второго тренинга. Условно-финальная.
1. Главное что надо понять в этой схеме - основной поток работ "Жизненный цикл претензии" может запускаться либо по обращению, либо по приходу документов. В первом случае поток работ "Получены претензионные документы" определяет по базе, что они относятся к уже зарегистрированной у нас претензии, и шлет сообщение в промежуточное событие внутри подпроцесса "Получить оригинальные документы". Во втором случае он сам инициирует основной поток работ.
2. Развилка и/или там строго по делу, и третья ветвь необходима. В чем тут дело:
- ожидать товар иногда надо, а иногда нет (уничтожили и прислали нам акт)
- оригиналы документов нужны всегда, но они могут уже быть у нас на руках (вариант два предыдущего пункта)
- если обе ветки опциональны, то возможен вариант когда не активируется ни та, ни другая - для этого и нужна третья безусловная ветвь.
Что касается названий - ну да, правильнее было бы назвать ветвь не "Получены документы?" а "Документы не получены". Формулировки с вопросительным знаком уместны на развилки, а на ветвях - логические утверждения. Но пусть неудачные названия будут самым большим недостатком наших моделей!
Валентин,
Если я правильно понял Анатолия:
1. последний гейт в процессе "Получение претензионных документов" - не параллельный гейт, а "или/или"
2. ветка с процедурой "товар получен на склад" должна быть подписана условием
Цитирую Pavel-Smirnov:
Валентин,
Если я правильно понял Анатолия:
1. последний гейт в процессе "Получение претензионных документов" - не параллельный гейт, а "или/или"
2. ветка с процедурой "товар получен на склад" должна быть подписана условием
Так точно.
Цитирую Анатолий Белайчук:
Так точно.
Соглашусь, поскольку могут прийти не оригиналы документов.
Здравствуйте всем!
К сожалению, я пока совсем не знаю Bizagi, поэтому моя схема очень корявая, но смысл, мне кажется, ясен.
Я выкладываю ее, чтобы сегодня на семинаре мне объяснили, что я делаю (и думаю) не так.
Выкладываю пока только в виде файла.
Жду критику.
Дмитрий
По условиям задачи в ней в общем случае наличествуют:
- заявление клиента о возврате (электронное)
- оригиналы документов, присланные по почте (бумаги)
- сам товар, доставленный на наш склад
Причем могут быть разные варианты - например, товары иногда требуются, иногда нет (есть акт об утилизации). Кроме того, последовательность жестко задавать нельзя: процесс может начаться с заявления, а может с пришедших по почте оригинальных документов.
Эти условия сильно усложняют процесс, а Ваша схема их не учитывает, в ней всего одно взаимодействие с клиентом - на старте процесса.
Замечание по технике: вместо развилки "Есть еще товар?" тут был бы уместнее цикл по объектам (товарам).
Вы должны авторизоваться, чтобы публиковать сообщения.