Добрый день.
Попробовал сформулировать бизнес-процесс: "Обработка входящего запроса (от запроса до заказа)"
Файлы
-
БП_обработка_входяще.doc (44 KB, 24 downloads) 12 лет old
-
Опубликовано 12 лет назад #
-
Вопрос относительно 5-го пункта сценария. Цены которые сообщают клиенту не изменяемы, или клиент может попросить скидку, и её могут предоставить ? Если да то кто принимает это решение ?
Далее по 5-му пункту, думаю надо добавить занесение в базу причину отказа, для дальнейшего анализа отказов клиентов.Опубликовано 12 лет назад # -
Схему накидаете в моделере ?
Опубликовано 12 лет назад # -
Цитирую Alexey Turchkov:
Добрый день.
Попробовал сформулировать бизнес-процесс: "Обработка входящего запроса (от запроса до заказа)"Ваш файл испорчен
Опубликовано 12 лет назад # -
Добрый день.
Цитирую gsitov:
Вопрос относительно 5-го пункта сценария. Цены которые сообщают клиенту не изменяемы, или клиент может попросить скидку, и её могут предоставить ? Если да то кто принимает это решение ?Цены изменяемы. Клинет может попросить скидку. Клиентский менеджер получает от технического специалиста некоторые "ворота" по цене: т.е. у него есть цена ниже которой Компания не будет опускаться и верхний порог, который определяется конкурентной рыночной ценой. Дальше все зависит от самого менеджера. Т.к. он завязан на процент от заказа, ему выгоднее продать клиенту услугу подороже. Но при этом важно не перегнуть, т.к. если клиент соскочет - менеджеру вообще ничего не перепадет.
Цитирую gsitov:
Далее по 5-му пункту, думаю надо добавить занесение в базу причину отказа, для дальнейшего анализа отказов клиентов.Согласен. Безусловно это необходимо. Просто пока только накидал сценарий в крупную клетку.
Цитирую gsitov:
Схему накидаете в моделере ?Да, сегодня вечером выложу пилотный вариант схемы.
Цитирую neverpoint:
Ваш файл испорченПерезалил
Файлы
- БП_обработка_входяще.doc (44 KB, 12 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Добрый день.
Я накидал основу БП, пока без подробностей.
Предлагаю сначала определиться с общим видом описания БП, а потом уже усложнять.
Жду комментариев.Файлы
-
БП_обработка_входяще.bpm (37.2 KB, 19 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Немного модернизировал , посморите
Файлы
- БП_обработка_входяще.bpm (43.6 KB, 23 downloads) 12 лет old
Опубликовано 12 лет назад # -
-
Добрый день. Ваш вариант я посмотрел. Сегодня попробую еще усложнить....
Опубликовано 12 лет назад # -
Цитирую gsitov:
Немного модернизировал , посморите1. Какой смысл разделять по пулам "Клиентский отдел" и "Технический отдел"? Если каждый процесс разделять по подразделениям, вы потеряетесь в большом количестве процессов. А еще такое разделение в будущем затруднит анализ выполнения процессов.
2. Ваш процесс под названием "Клиентский отдел" обрывается на событии "Передать исходную информацию". А по-жизни - процесс замирает в ожидании какого-то ответа от специалиста технического отдела, так ведь? Вот и поставьте ожидание событий (согласия либо отказа клиентского отдела)
3. Почему вы остановили на границах пула стрелку потока сообщений от события "Передать исх. информацию"? Продолжите стрелку до стартового события "получить исходную информацию". Так будет правильно.
4. Избегайте рисовать лишние элементы. Тот факт, что в "Уточнить исходную информацию" и в "Согласовать цену и условия" у вас происходит информационный обмен с потенциальным клиентом - это понятно и без дополнительных стрелок передачи сообщений. И стрелок, между прочим, по жизни может быть гораздо больше, ведь, например, "предложения" и "ответы" могут следовать с обеих сторон, обсуждающих условия договора ;)
5. Ветка с условием "Пересмотр условий" - она лишняя. По всей логике вещей вы должны выйти из активности "Согласовать цену и условия" с решением "Согласовано" или "Отказ". Такое действие как "пересмотр условий" - это одна из составляющих того, что вы назвали "Согласовать цену и условия".
6. Почему событие-завершение называется "Отказ клиента"? Ведь отказаться мог не только клиент, отказаться могли и мы
7. "Контрольный звонок клиенту для контроля качества" - название не потеряет смысл, если убрать слово "контрольный". А лучше всего активности называть, начиная с глагола (ведь активность - это действие, как ни как...). А еще "звонок" - это механизм, с помощью которого вы выполняете какое-то действие (в данном случае пытаетесь выяснить мнение вашего клиента относительно какого-то качества). Составляя схему, старайтесь не использовать названия механизмов в названиях активностей, иначе вы ограничиваете себя в средствах достижения цели. В вашем примере я бы написал "Получить от клиента оценку качества" (вместо "Контрольный звонок клиенту для контроля качества") и в комментарии к активности подписал бы, что с клиентом предпочтительно связываться по телефону, но можно и по электронной почте, и при личной встрече и факсом и т.д.
8. Аналитическая диаграмма не должна читаться как детективный роман. Мне вот, например, непонятно что означает "Получить итоговые цену и условия". От кого получить, как получить, что значит итоговые?С уважением, ПС
Опубликовано 12 лет назад # -
Цитирую gsitov:
Немного модернизировал , посморите1) уточнение исходной информации думаю лучше разбить на две задачи и вот почему. Клиент может попросить скинуть ему опросник, чем сам будет сочинять что ему нужно. А вот задача получения исходной информации от клиента может быть вообще по емейл, а не в рамках одной задачи в процессе телефонного разговора. При этом клиентский менеджер заполняет некую форму или просто емейл и отсылает в техотдел. Уж больно жутко смотрится обмен сообщениями в рамках одной задачи - если захотите автоматизировать на базе того же сьют или иными инструментами то будут проблемы лишние.
2) согласование условий и пересмотр их вызывает вопросы - а тогда что согласует техдиректор?
3) задача "подписать договор" не подразумевает взаимодействие с клиентом? там нет никакого обмена с ним - для проформи сделайте хотя бы обмен сообщениями, мы не в каменном веке живем, многие сертификатами электронными дистанционно подписывают, благо законодательно это разрешено.
Опубликовано 12 лет назад # -
Все по существу. Добавлю (или скорее соглашусь развернуто) что рисовать лишние пулы нет смысла - это типичный пример как из вида потерялся happy path - скачут стрелки туда сюда и читаемость ухудщилась. Нужно всегда исходить из наиболее желаемого пути для компании и рисовать его стараться горизонтально, а всякие там нежелательные сценарии выводить в сторону. Читаемость сразу улучшиться! Я вообще избегаю пулов, кроме как использую их в качестве сущностей, черных ящиков для сторонних лиц.
Опубликовано 12 лет назад # -
Коллеги, убедительная просьба, выложите, пожалуйста крайнюю версию нашего кейса.
А то похоже, что только у меня нет ее.Заранее спасибо.
Опубликовано 12 лет назад # -
gsitov,
1. как решить, нужно ли делать отдельный процесс (в терминах моделирования - выделять в отдельный пул) или оставаться в рамках одного процесса (подсказка):
выделять в отдельные пулы процессы имеет смысл тогда, когда:
- один из процессов вообще не ваш (в этом случае их даже не детализируют, а оставляют в виде пула - черного ящика)
- процессы имеют разную частоту, разные жизненные циклы
- объект, который послан из одного процесса в другой для обработки, в этом процесс-обработчике не один. Пакетная обработка. (т.е., например, процесс планирования доставок на день обрабатывает все поступившие заявки из разных процессов).
Злоупотреблять межпроцессным взаимодействием не стоит, т.к. это усложняет не только схему, но и реализацию.
В Вашем примере техотдел обрабатывает один конкретный запрос. Получили - расценили - отдали. Все равно менеджер, пока не получит ответ от техотдела, ничего не сделает. Обычная синхронная задача.2. В постановке задачи сказано, что секретарь после идентификации заявки переводит звонок на клиентский отдел. То есть клиент на связи, менеджер уточняет, что тот хочет. Какие тут стрелочки? Какой обмен сообщениями? Лишнее.
3. После того, как технический директор решил, могут или не могут выполнить заказ, и сколько это будет стоить, он должен сообщить об этом менеджеру в любом случае, а не прерывать процесс в случае отказа, как это сделано у Вас.
В общем, я как-то так это вижу:
Опубликовано 12 лет назад # -
Последняя версия документа, переделали к наглядности к happy path
Жду комментариевФайлы
- БП_обработка_входяще.bpm (119.7 KB, 41 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Юля, предложенная нами последняя схема как мне кажется выглядит нагляднее
Опубликовано 11 лет назад #
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.