NonsensПрактически во всех CRM наличествует нечто, напоминающее управление бизнес-процессами. В MS CRM это Workflow. В рекламе CRM от Раруса видел какую-то графическую рисовалку бизнес-процессов. Кто-нибудь пользовался этим на практике (ну или хотя бы пробовал)? Поделитесь впечатлениями пожалуйста.

ОК. Давайте обсудим. Мжно прямо на конкретном прмере. Есть учетная система, и есть некая CRM. И есть некий бизнес-процес. Им надо как то управлять. Зачем? А что бы ни че незабыть.

Идет поток Заявок конечных Клиентов на покупку Товара. Это рождает Поток Заявок на Заказ Товара от Поставщиков. При этом возникает тормоз. Заявки комплектуются от разных Поставщиков, и в разное время, отгружаются даже частично....

В итоге....мучительно трудно вспомнить ....что там и как ...что заказали, что отгрузили, что еще надо Достать...

Просили одно (атрикул конкретный). А мы Заказали Иной артикул. И заменили. А там еще Упаковка вмешалась....надо дробить...

И как это все описать - разрулить???? Учтите, что тупо вводить перекрестные списки товаров (заявок) ....это нам не дано. Надо чтобы ...оно все САМО отразилось....

Допустим - я это все описал. В графах и разных деревьях. ОК. Поможет?? Трудно сказать. Надо подумать...

Nonsens UK0IAIУчтите, что тупо вводить перекрестные списки товаров (заявок) ....

Вот это не очень понял, поясните пожалуйста. Куда и с какой целью нужно что-то вводить?

UK0IAIНадо чтобы ...оно все САМО отразилось....
Отразилось где?

Для контроля бизнес-процесса - допустим, мы описали Б-П, в терминах (этапы, узлы..), у нас циркулирует (в системе), я бы сказал, многострочная информация. Списки товаров. (Счета, накладные..)

Мы (юзеры), постоянно производим операцию ( по сути) - сравнения списков (чтобы выработать свое управленч.решение) или создаем Задачи (CRM).

Беда в том, что, скажем, Заявка клиента (список) и скажем, Счет на оплату, и скажем, Накладная товарная -- все это может иметь принципиально разное (не сопоставимое) содержимое.

Если мы хотим, что наша ИТ, хоть както была эффективна, то она должна иметь в себе некий "робот", что САМ разруливает эту информационную несовместимость. Тогда действительно, можно радоваться наличию BPM в наших системах.

BPM актуально еще тогда, когда например, цикл от Заказа до Продажи Товара занимает несколько месяцев, а вопрос проработки Заказа - состоит из большого кол-ва этапов (согласования), как например, в... бизнесе...продажа поковок (отливок...)

Робот - в моенм понимании- это фоновый процес, который ведет протокол. если мы, по жесткому регламенту, запрещаем себе "ручной ввод всех видов Доков", и только через функцию ВВОД НА ОСНОВАНИИ - тогда наша ИТ в принципе способна САМА формировть ТАБЛИЦЫ ПЕРЕКРЕСТНЫХ ССЫЛОК, которые однозначно РАЗРЕШАЮТ задачу ...контроля (б-п продажи товаров)...

Ну так примерно...в кратце я хотел сказать...что наболело конкретно...

Да, прихожу к выводу - что этот "робот" штука не сложная...

WJ2 UK0IAI

Трудно выписать готовый рецепт, когда нет точного диагноза, но из всего Вами описанного могу точно сказать - BPM-система способна разрулить подобную ситуацию. Однако, это вовсе не значит, что можно поставить BPMS - и в данных тут же настанет порядок. Здесь есть над чем подумать аналитику. Процесс придется описывать, с тем бардаком, который творится в документах нужно тоже разбираться.
К примеру, заказчик разместил заявку на вашем сайте. Следующим шагом система (имеется в виду BPMS) обращается в базу данных на предмет наличия заказанных позиций. Если все есть, то процесс движется одним путем, если чего-то не хватает, то задача переходит к лицу, принимающему решение. Это лицо имеет варианты: предложить аналогичный товар (получить согласие заказчика), предложить изготовить (согласовать сроки), купить у кого-то и продать заказчику. Дальше - это как опишете процесс. Однако, в этом случае все изменения будут согласованы с заказчиком, а, следовательно, избавляетесь от несоветствия в документах. Процесс может выполняться до тех пор, пока не будет выполнен заказ (имеется в виду запущенный экземпляр процесса). Для того, чтобы ответственному за процесс не держать в голове все имеющиеся в работе процессы, можно настроить процесс таким образом, чтобы все действия были ему видны. Можно также настроить таймеры, которые контролируют время прохождения процесса, выполняя в критических точках предписанные действия (какие именно - решаете вы, настраивая процесс).
Если у вас на предприятии кроме CRM имеются еще системы учета, то BРMS позволит избежать дублирования ввода данных, необходимости синхронизации справочников, раскладывая и доставая данные из внешних приложений на нужном шаге процесса. Какие данные, в какие системы и в каком виде помещать - это вы определяете сами.
Так в общих чертах выглядит работа с BPMS.
Стоит еще добавить, что в случае критического поведения процесса некоторые системы позволяют изменить ход процесса, не нанося ущерба запущенным экземплярам.
Если во время работы выявляются слабые места в процессе, то модель процесса может быть изменена, что и рекомендует цикл Шухарта-Деминга.
Вы в этом смысле говорили о BPM для CRM?

Да-да, Вы отлично все это сформулировали. Я, наверно, включился в обсуждение темы что бы... немножко осознать...точку отсчета. И мы очень хорошо это описали.

Встречный вопрос
Интересно а какому проценту заказчиков нужен BPM в CRM?
Возьмем мелкосреднюю продажную конторку - 10/15 манагеров, старший манагер, 1 админ (скорее всего совместитель), директор, уборщица... :)

Меня задел этот вопрос...и я понял, что мне срочно нужен это самый BPM в моей маленькой CRM. Зашиваемся.