Вопрос

Здравствуйте.

Сталкивался ли кто с необходимостью через бизнес-процесс вытянуть организационную роль контакта?

Получилось вытянуть родительскую роль "Inherited from", для всех контактов читается значение - "All employees". 

Подскажите, реально ли без побочных "костылей" с помощью процесса прочитать орг. роль?

У меня такой же вопрос

5 комментариев

Добрый день!
У контакта может быть несколько орг. ролей, так как это деталь.
Для того, чтобы прочитать орг. роли, нужно найти пользователя контакта, далее считать роли этого пользователя


Добрый день,

Это не очень сложно: но нужно учитывать структуру таблиц где хранятся роли и вхождения в роли. Посмотрите таблицы / объекты "Объект администрирования" и "Вхождение пользователя в роли". В первой хранятся роли и сами пользователи, а во второй хранятся вхождения этих пользователей в соответствующие роли. Так же в таблицах есть тип роли, по которому можно определить организационная это роли или функциональная.

Сидоров Александр В.,

Делала в точности также, только в "Роли пользователя" читала первую запись выборки, а не коллекцию. Спасибо большое, попробую.

Тёскин Дмитрий Валерьевич,

здравствуйте, Дмитрий. 

По таблицам посмотрела. На примере одного контакта: достаточное количество записей орг. ролей вышло. Точно известно, что контакт в настоящее время состоит в одной организационной роли. Эту роль и нужно выцепить.

Вся информация о пользователях и ролях и вхождении первых во вторые хранится в таблицах SysAdminUnit, SysUserInRole и SysAdminUnitInRole. В последнюю переносится после выполнения действия актуализации. Возможно, Вы как раз ещё не актуализировали.

Если есть доступ к базе, сделайте SQL-запросами выборку из этих таблиц: сначала по имени определите Id этого пользователя, а потом посмотрите роли, в которые он входит. Когда структура и условия фильтрации станут ясны, можно будет повторить аналогичные условия выборки средствами движка процессов.

Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

Доброго дня. 

Есть в системе Контрагент, и есть Контакт у этого Контрагента.

И есть ответственный, как у Контрагента, так и у Контакта.

Однако, если у Контрагентов один Ответственный - это ведущий менеджер, то у Контактов пользователь Supervisor.

Как бы привести в соответствие ответственных из Контрагента в Контакты. Не в ручную, а автоматизированно. 

 

Есть идея, что это можно сделать через бизнес-процессы, только пока опыт их использования не позволяет это с точностью утверждать. 

Если это так, то подскажите, какая документация может помочь? 

Или если не бизнес-процессы, то что? 

Или может даже есть почти рабочий бизнес-процесс, который надо будет немного отредактировать под себя.

У меня такой же вопрос

14 комментариев

Добрый день!
Ответственный у контрагентов и контактов - это тот, кто создал контрагент и контакт.
Привести в соответствие по вашему описанию можно скриптом в базе, например:

update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.AccountId = a.Id
 
либо (в зависимости от связи)
 
update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.Id = a.PrimaryContactId

Но, при создании новых контрагентов или контактов владельцы все равно будут проставлены по описанной выше логике. Так что надо будет либо сделать периодический бизнес процесс по обновлению, либо процесс по сигналу создания объекта (контрагента или контакта).

Сидоров Александр В.,

То есть в бизнес-процесс можно зашить этот скрипт?

Bogdan Zozulya,

Да, можно. Элемент "Задание сценарий", в нем вызов CustomQuery

Можно, но не нужно. Внутри БП для этого есть более подходящие способы: элементы чтения и изменения данных или работа в скрипте с EntitySchemaQuery.

А приведенный выше скрипт — для быстрого единоразового изменения всех требуемых записей, если есть доступ к базе.

Зверев Александр, 

Вот с этим сейчас и завяз. Вроде все логично, вижу эти возможности, но пока не осознал, как с этим совладать. В связи с чем у меня был попутный вопрос в стартовом посте насчет справочной инфы. В принципе на часть вопроса Вы уже ответили. Что это действительно возможно. Попробую в документации узнать как именно это сделать. 

Bogdan Zozulya,

С документацией по настройке бизнес-процессов можете ознакомиться по этой ссылке на Академии и более подробно по работе с данными здесь.

Алла Савельева,

огромное спасибо, я думаю предостаточно наводок и данных, Пойду поднимать свою компетенцию владения системой. 

Можно сделать два отдельных механизма: один — для разового запуска в начале, другой — постоянно готовый сработать БП на событии изменения поля «Ответственный» контрагента: получаем значение поля и элементом изменения данных меняем ответственного во всех контактах, у которых указан этот контрагент.

Bogdan Zozulya,

Если возникнут дополнительные вопросы, спрашивайте - с радостью помогу.

Алла Савельева,

Спасибо, пожалуй воспользуюсь. Вот здесь как указать чтобы он взял данные из Ответственного в Контрагенте? 

Сидоров Александр В.,

А как разницу связей выявить? Куда мне посмотреть, чтобы определить какой из вариаций скрипта мне подходит?

В зависимости от того, как связаны интересующие контакты с контрагентом: по полю в контрагенте «Основной контакт» или наоборот, по полю в контакте «Контрагент».

Зверев Александр,

Понял, внимательно изучил, второй вариант, по полю «Контрагент» в «Контакте». Выходит второй вариант скрипта. верно?  

update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.Id = a.PrimaryContactId

Нет.

Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

Добрый день!

Подскажите пожалуйста, каким образом можно настроить автоматический ответ на письмо, как в Outlook? Например: на любое входящее сообщение CRM должна отсылать шаблонный ответ "Письмо получено. Спасибо за обращение."

У меня такой же вопрос

1 комментарий
Лучший ответ

Письмо єто активность с типом Emailте как вариант создать БП со стартовым сигналом слушающим добавление входящего Email и использовать элемент БП Отправить письмо для формирования ответа

Письмо єто активность с типом Emailте как вариант создать БП со стартовым сигналом слушающим добавление входящего Email и использовать элемент БП Отправить письмо для формирования ответа

Войдите или зарегистрируйтесь, чтобы комментировать
Идея

Коллеги, сделайте уже автоматическое добавление кастомных связей активности в параметры процессной задачи. Ну сил уже нет.

Реализована
3 комментария

Здравствуйте, Дмитрий!

Данная функциональность будет реализована в версии 7.10 релиз которого состоится в ближайшие 2 недели (в 7.10 это будет реализовано для разделов).
А в 7.10.1 реализация данного функционала охватит еще и кастомные поля.

Ага, ну прикольно тогда

Добрый день!

Действительно в версии 7.10 список связей в элементе Задача строится на основании текущего списка связей в разделе Активности. Добавить новую связь можно напрямую в таблицу EntityConnection. Также связь автоматически создается, если для раздела создан кейс. 

 

Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

Добрый день.
После обновления до версии 7.7 возникла проблема при открытии БП в дизайнере процессов.
Бесконечно крутится загрузка, а в консоли появляется следующая ошибка:

Путём проб и ошибок выяснилось, что эта ошибка возникает после использования в элементе "Задача" и "Звонок" события "После сохранения записи"(Ошибка возникает даже если в указанное поле вписать только комментарий). Как быть с решением указанной проблемы?

И ещё один вопрос: Как обратиться к параметру в элементе Скрипт?
Обращение в виде LeadId(идентификатор Лида) - вызывает ошибку при публикации БП.

У меня такой же вопрос

8 комментариев

Предположим у нас есть параметр процесса Text с типом "Строка".
В версии 760 (и более ранних) значение этого параметра можно было получить следующим кодом:
var leadId = LeadId;
В версии 770 этот код будет выглядеть по другому:
var leadId = Get("LeadId");

Что Вы хотите реализовать в событии "После сохранения записи"?

"Демьяник Алексей" написал:В версии 770 этот код будет выглядеть по другому:
var leadId = Get("LeadId");

"Демьяник Алексей" написал:В версии 770 этот код будет выглядеть по другому:
var leadId = Get("LeadId");

А как передать значение параметру? В документации информации не нашёл.

"Демьяник Алексей" написал:Что Вы хотите реализовать в событии "После сохранения записи"?

Обновление поля. Но на данный момент даже наличие комментария в этом поле вызывает ошибку.

"Коновалов Игорь" написал:

А как передать значение параметру? В документации информации не нашёл.

Топики:

http://www.community.terrasoft.ru/forum/topic/16294
http://www.community.terrasoft.ru/forum/topic/16335
http://www.community.terrasoft.ru/forum/topic/16361
http://www.community.terrasoft.ru/forum/topic/11784
http://www.community.terrasoft.ru/forum/topic/13848
http://www.community.terrasoft.ru/forum/topic/12023
http://www.community.terrasoft.ru/forum/topic/9477

Академия:
http://academy.terrasoft.ru/documents/docs/technic/BPMS/7.7.0/BPMonline…
http://academy.terrasoft.ru/documents/docs/technic/BPMS/7.7.0/BPMonline…
http://academy.terrasoft.ru/documents/?product=BPMS&ver=7.7.0

"Коновалов Игорь" написал:

Обновление поля. Но на данный момент даже наличие комментария в этом поле вызывает ошибку.

Насколько мне известно это исправлено в последних версиях 7.7 (для sales enterprise это 7.7.0.2875).

Спасибо за информацию.

Добрый день!
Подскажите, пожалуйста, можно ли с помощью стандартных инструментов в дизайнере построить бизнес-процесс, который бы вызывался кнопкой из карточки физ.лица и автоматически создавал продажу и продукт в продаже?
Общая схема такая:
1. Есть заявка на продукт с сайта, в которой уже указан продукт
2. Сотрудник call-Центра связывается с клиентом, редактирует карточку заявки и карточку физ.лица.
3. Запускает бизнес-процесс создания продажи и продукта в продаже из карточки физ.лица
4. Этот же бизнес-процесс привязывает заявку к продаже

Здравствуйте, Дарья!

Данную задачу можно реализовать, но не стандартными инструментами.
Вам необходимо:
1) Добавить кнопку на страницу редактирования. Подробнее
2) В обработчик кнопки добавить логику запуска процесса (за пример можно взять действие "Отправить на визирование" на странице редактирования раздела "Договоры"). В процесс необходимо передать Id открытой записи.
3) Собственно реализовать процесс

Алексей, спасибо за ответ!
Не отображается страница по ссылке "Подробнее" (ошибка 404, страница не найдена).

Здравствуйте!

Поправил.

Войдите или зарегистрируйтесь, чтобы комментировать
Идея
Сейчас элемент "Изменение прав доступа" позволяет работать только с вручную введенными значениями. Но не позволяет изменять права доступа для пользователей, полученных в результате самого бизнес процесса.Например, сменился ответственный по контактам. Необходимо новому предоставить доступ к истории работы с клиентом. Сейчас приходится это делать вручную. А можно было бы через БП. Спасибо.
Реализована
2 комментария

Поторопился.
Нашел. Оказывается, можно.

Павел, но это обозначает, что мы можем улучшить нашу документацию или UX самих элементов, так что всё равно спасибо за идею. В версии 7.7 мы перерабатываем интерфейс построителя процессов. Уверена, что в новом интерфейсе функции станут более понятными.

Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

День добрый, Коллеги!

Необходима помощь в решении нескольких тривиальных задач при построении БП (решение желательно листинг простенький или ссылку)

1) Как программно через элемент БП задание-сценарий получить ID созданной записи из элемента Страница редактирования

2) Как программно через элемент БП задание-сценарий получить/установить параметр БП

3) Как в условном потоке написать условие ID!=null, при том что ID с типом уникальный идентификатор

Данные вопросы возникли при решении простой задачи: при входе в подпроцесс на него передается AccountID -> при старте БП идет проверка AccountID есть/нет
если есть, то идем к шагу задачи
если нет, то идем на шаг с создание Контрагента

На данный момент реализация проверки на AccountID!=null довольно убогая... через чтение данных получаю count записей с id = AccountID и в условном потоке проверяю сравнением...

p.s. так же наблюдается некоторая странность при запуске подпроцесса. Первая задача падает в расписание, а не появляется сразу на экран (остальные задачи в подпроцессе отрабатывают нормально), возможно есть какая-нибудь настройка или прием?

p.p.s. Я пытался найти описание методов для получения коллекции параметров БП в SDK, но не нашел ) если они там есть и я просто проглядел - скиньте ссылку

Заранее спасибо!

У меня такой же вопрос

4 комментария

Артем, добрый день.

Прежде всего, хочу уточнить, что в стартовом элементе с типом "Сигнал" можно сразу же задать условия, выполнение которых является обязательным для старта БП по данному сигналу:

Но, т.к. в таком случае, Вам бы пришлось создать два БП, рассмотрим конкретно Ваш кейс.
БП будет следующим:

Стартовое сообщение - сигнал на объекте "Активность" после добавления новой записи.
Далее в элементе "Чтение данных" считываем все поля записи, по которой был запущен процесс:

После этого, создаем условный поток к элементу "Создание нового контрагента", условие следующее:

ReadDataUserTask1.ResultEntity.GetTypedColumnValue<Guid>("Account.Id") != Guid.Empty

где ReadDataUserTask1 - название элемента "Чтение данных".

и потом добавляем поток по умолчанию к элементу "Создать новую задачу".

В принципе это всё.

Если будут вопросы - обращайтесь.

Спасибо, Дмитрий!
Вопрос N3 можно считать решенным ) (не знал что в условии можно использовать C#)

К сожалению, Ваш способ по созданию контрагента мне не подходит по причине того, что необходимо далее передавать AccountID в подпроцесс (видимо нужно было более детально описать пример).

если при старте родительского БП AccountID был заполнен (была связь Лида с контрагентом), то передавать далее в подпроцесс необходимо именно его
, а если при старте родительского БП AccountID пустой (например Лида квалифицировали как контакт и поле Контрагент пустое), то передавать далее в подпроцесс необходимо идентификатор записи из шага "Создайте нового контрагента".

Можно конечно решить вопрос с помощью конструктора, но это избыточность в чистом виде =\ куда проще мне было бы вставить после шага "Создайте нового контрагента" скриптик, который просто заполнил бы параметр процесса AccountID идентификатором созданной записи из шага "Создайте нового контрагента" + я практически на 100% уверен что в будущем еще не раз придется работать с параметрами БП через скрипт.

Так что вопросы 1,2 все еще актуальны

Артём, добрый день.

Если Вы добавили в структуру процесса параметр MyParam с типом GUID, то обратиться к нему можно просто:

MyParam = new Guid(stringGuid);
Guid fromParam = MyParam;

это по второму вопросу. Т.е. обращаемся в любом скрипте процесса по имени параметра.

По первому вопросу:

Если Вы раскроете действие "Открыть карточку редактирования", то увидите там параметр RecordId, с него и считывайте:

Guid recordId = OpenPageElement1.RecordId;

Спасибо Дмитрий!
На этот раз все вопросы сняты

С уважением,
Волков Артем

Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

Опишу ситуацию:
По старой версии БП были запущены процессы. После этого возникла необходимость изменить БП и были внесены соответствующие изменения. Старые БП нельзя просто так завершить, в виду того, что их выполнение не предполагает быстрого выполнения (например, ожидается ответ от клиента, а это нельзя никак ускорить так, чтобы завершить БП).
Вопрос: как сделать так, чтобы незавершенные БП пошли дальше по новому БП?
Новая версия БП довольно серьезно отличается от старой (новые ветки, задачи, добавлены новые параметры). Есть ли какой-то алгоритм как можно сделать безболезненный переход? Поделитесь опытом как вы решали такие ситуации.

У меня такой же вопрос

7 комментариев

Было такое, решали тем, что "замыкали" выходы со всех задач старого процесса на новый. Возможно вариации, но общая схема такая:
1) В новом процессе:
- добавляем параметр процесса OldActionName, тип строка, в нем будет передано название того элемента старого процесса, из которого попали в новый. Если процесс запускаем сам по себе - значение будет пусто.
- в начале ставим блок-условие, которое анализирует значение параметра OldActionName и переходит на соответствующую задачу.
2) В старом процессе:
- добавляем блок-подпроцесс с новым процессом
- после блоков-задач ставим блок-скрипт, который выставляет значение параметра OldActionName нового процесса, и собственно переходит на новый процесс.

Чтобы не превращать оба процесса в "паутину" связей :), можно сначала запросом к таблице tbl_WorkflowItem определить названия незавершенных элементов процессов, и настроить переходы только для них.

"Валерий Андрусик" написал:Возможно вариации, но общая схема такая

Валерий, спасибо за то, что поделились опытом. Все еще думаю как сделать лучше.

А что если изменять значения параметров в диаграмме и элементах уже запущенного БП, и сделать так, чтобы эти параметры указывали на следующий исполняемый элемент из нового БП, тогда не нужно будет 2 отдельных процесса (старый и новый), то есть внести изменения в таблицы tbl_Workflow и tbl_WorkflowItem?

Дело в том, что сама диаграмма хранится как сервис. В tbl_WorkflowItem мы видим только отработанные и текущие элементы процессов (будущих там нет). Ядро Террасофт создает следующую запись в tbl_WorkflowItem только при отработке текущей задачи, ориентирусь на схему процесса в tbl_Service.
Если я правильно понял, у вас на рабочей базе работает старый процесс, а на базе разработки вы расширили его же. Если при этом у вас в новой версии диаграммы сохранились все элементы старой, с теми же кодами, то думаю можно просто обновить сервис - при отработке элемента ядро найдет в новой диаграмме новые связи. А вот если изменения повлекли в том числе и удаление элементов или их переименование - тогда хуже. Я бы тогда советовал сделать новый процесс (с другим USI), и настроить переход на него. Может еще специалисты Террасофт посоветует что-то.

То есть, насколько я понимаю, ключевым является наличие последнего выполняемого элемента и не завершенного в новом БП? То есть оно должно его найти в новой схеме БП и дальше идти по схеме? Если оно этого элемента, на котором в старой схеме БП остановилось, не находит в новом, то тогда ошибка, иначе - все должно быть ок.

Очень интересненько... возьму на заметку.

Да, правильно

Действительно, Валерий правильно подсказал решение. Оно и довольно простое, но в то же время приводит к результату. Процессы при экспорте-импорте в xml файлах указаны только перечень элементов процесса. Элементы же хранятся в tbl_WorkflowItem и кто у них следующий узнают только после перехода в состояние "Выполнено", тогда в сервисе процесса ищется тот, который должен выполняться следующим. Поэтому предложенная "подмена" - это почти законный способ "перевести" элементы старого процесса на выполнение в рамках нового.

Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

В бизнес процессах если используется задержка процесса по времени, то следующая задача после процесса не создается автоматически.
т.е. чтобы запустить задачу надо выполнить следующий шаг запущенного процесса.
Это не всегда удобно, т.к. таких процессов может быть запущенно огромное количество и пользователь не помнит, а может и не знает, что надо продолжить процесс.
Предлагается при окончании задержки выполнения процесса, чтобы автоматически запускалось окно создания задачи

У меня такой же вопрос

3 комментария

В базовой конфигурации такой функциональности нет, взгляните на наше расширение (http://community.terrasoft.ua/catalog/4881), возможно заинтересует.

"Валерий Андрусик" написал:

Валерий, ваше решение достаточно интересное хотелось бы узнать о нем подробнее - стоимость, условие внедрения.
Что касается затрагиваемой мною темы, то здесь я считаю что была недоработка системы, т.е. если пользователь отменил действие или что то допустил не то, это другое дело, но запланированная задержка, должна быть задержкой на указанный промежуток времени, а не на все время :smile:

Да, проблему с задержкой обсуждали вот тут:
http://community.terrasoft.ua/ideas/3363

Войдите или зарегистрируйтесь, чтобы комментировать
Публикация

Описываемый раздел входит в пакет сервисов проектных элементов БП наряду с разделами «Процессы» и «Статистика», описанных в предыдущих публикациях.

 

Предыстория появления этого раздела, несомненно, заслуживает упоминания, так как во многом раскрывает его функцию. Организация, в которой используется больше сотни бизнес-процессов, постоянно сталкивалась с ситуацией, условно изображённой на рисунке ниже:

 

 

И благо, если достаточно просто добавить ещё одну стрелку с результатом. А если в указанном случае необходимо запустить целый каскад процессов, включающих в том числе и повторное прохождение некоторых шагов текущего процесса? Понятно, что изначально везде сена не подстелишь, расчёт был на то, что в схеме БП будут предусмотрены только типичные ситуации. Однако реальная жизнь упорно не хотела укладываться ни в одну схему. Постоянно приходилось что-то менять, дорабатывать, схемы процессов усложнялись, затем и в усложнённых схемах возникали ситуации, когда опять «за панамой надо прямо, а бульдог тянет в бок…», словом, программист, который занимался этой работой понял, что если он не хочет провести в командировке всю оставшуюся жизнь, должен предложить какое-то радикальное решение, снимающее противоречие между идеальной схемой и реальной жизнью. Используя ресурс выходного дня решение было найдено и воплощено в виде предлагаемого раздела.

 

Представьте, что некий пользователь попробует заварить чай по схеме чаепития, что используется на обучении. В первый раз всё прошло гладко, во второй раз пришлось добавить какие-то дополнительные шаги, в третий – добавить несколько веток, превратившихся в подпроцесс (например, сперва это был поход в магазин за сахаром, потом ещё и поход за чаем, потом их модифицировали в один типовой подпроцесс «поход в магазин» с двумя ветками), а через месяц оказалось, что в магазине поставили кофейный аппарат, и если чай нужен срочно, то его следует готовить прямо в аппарате…

 

Описанная аналогия хотя и выдумана, но отнюдь не надумана. Даже в функциях некоторых бизнес-процессов изначально заложена изрядная доля неопределённости. Представьте, сколько хлопот может доставить процесс с таким невинным названием, как «Торги». В любой момент торгов может возникнуть непредвиденная ситуация, которая должна в корне поменять не только дальнейшие наши действия, но и заставить переделать и то, что уже было пройдено! Простейший пример: клиент сперва согласился, а потом передумал. Причём передумал тогда, когда двигаясь по стандартной схеме уже завизирован договор и даже, может быть, подписан одной из сторон. Создавать доп. соглашение? Отказаться от работ? Перенести сроки, изменить стоимость? А если «урезаем осетра», то надо менять и техническое задание, которое было написано (и подписано) по предшествовавшему процессу гораздо ранее, пересчитывать часы… О куче возникающих согласовательных процедур даже говорить не стоит, их может быть бесконечно много.

 

Но важнее всего – что делать со схемой БП? Изменить согласно возникшим реалиям? Или эта ситуация исключительна, и больше никогда не повторится?

 

Решением таких проблем и стал раздел «Ситуации», где используются процессы со схемой, генерируемой «по факту». Оказалось, что число возможных «жёстко зашитых» действий даже в организации со сложной и запутанной бизнес-логикой вполне поддаётся учёту, хотя комбинаций этих действий может быть бесконечно много. Здесь оргомную помощь оказал раздел «Статистика», описанный в одной из предыдущих публикаций. Решение напрашивалось само собой: константные действия «зашить» в специальные подпроцессы, названные «типовыми решениями».

 

 

Как видно на скриншоте, типовое решение суть ситуативный запуск некоего бизнес-процесса, права на использование которого разграничиваются тут же. Например, такое типовое решение, как «Согласовать решение с ген. директором» могут добавить многие участники процесса, но удалить (фактически, отменить запуск) может только ген. директор. Обратите внимание, что права на добавление/удаление типовых решений в ситуацию раздаются не определённым пользователям или их группам, а ролям в бизнес процессе (в предыдущей публикации описана логика работы ролей в БП и трансляции роли в определённого пользователя). По факту это означает следующее: один и тот же пользователь системы в одном процессе может являться менеджером по продажам, а в другом – менеджером по повторным продажам, и в зависимости от своей роли иметь различные права на добавление типовых решений.

 

Сами типовые решения могут представлять как небольшой процесс из одного-двух шагов, так и очень сложные схемы. Фактически, в типовое решение можно обернуть любой бизнес-процесс.

 

 

 

Например, в первом приближении, на ум сразу приходят несколько хорошо известных типовых решений: «Доставка», «Визирование», «Презентация», «Назначение», «Согласование» и т.п. Как правило, это те «кирпичики», из которых можно составить любой бизнес-процесс любой компании. Специфика бизнеса, конечно, накладывает свой отпечаток на состав и количество этих «кирпичиков», но, полагаю, любую сложную бизнес-логику можно свести к какому-то, относительно небольшому количеству типовых решений. И чем больше различных бизнес-процессов используется в компании, тем очевидней выгода от такого подхода.

 

Подготовив ряд «кирпичиков» можно попытаться заранее стандартизировать и возникающие ситуации, распределив их по типам и категориям.

 

Категории объединяют в себе несколько типов ситуаций:

 

 

К примеру, в категорию «Торги» входят типы ситуаций, где требуется «Изменить стоимость» и «Изменить сроки», а в категорию – «Доп. соглашение к договору» - типы «Порядок подписания договора» и «Изменение сроков».

 

 

Функция категорий и типов жёстко разграничена: типы управляют ходом типового решения, а категории – их запуском. Поясню на упоминавшемся выше шуточном примере: в категории «Порыв ветра» существуют два типа ситуаций: «Стоимость унесённого предмета меньше 10 рублей (Ветер унёс панаму)» и «Стоимость больше 10 рублей (Ветер унёс контракт на сто тысяч миллионов)» и одно типовое решение «Догнать унесённый предмет». При возникновении ситуации указанной категории типовое решение «Догнать унесённый предмет» будет добавлено автоматически, но внутри типового решения будут задействованы две различные ветки. Для ситуации с типом «Ветер унёс панаму» система предложит диалог с бульдогом, а в ситуации второго типа - демократический вариант будет невозможен, не стоит даже и предлагать. Приблизительно так будет выглядеть начало типового решения.

 

 

Автоматическое добавление типового решения регулируется в этом же справочнике, на детали «Типовые решения в категории»:

 

 

Выбор типового решения осуществляется из справочника типовых решений. Если указать, что типовое решение добавляется автоматически, система сразу после создания ситуации данной категории добавит такое решение в ситуацию. Иначе добавление такого решения будет возможно вручную (только для пользователей, чьи роли в процессе позволяют его добавлять). Галочка «Добавлять в начало очереди» управляет приоритетом выполнения типовых решений (скажем, что сделать раньше, когда решение по ситуации принято: согласовать решение с руководством или сперва сообщить решение клиенту?). Состояние ситуации указывает, когда следует начинать выполнение типового решения (оба упомянутых случая – для состояния «Решение принято», ведь пока у ситуации состояние «Поиск решения», к примеру, ещё нечего согласовывать и нечего сообщать клиенту).

 

Рассмотрим, как всё это работает на примере ситуации из категории «Торги». Предположим, позвонил клиент и сообщил, что стоимость работ превышает его бюджет. Менеджер, принявший звонок, в разделе «Ситуации» добавляет ситуацию категории «Торги»:

 

 

В карточке ситуации следует обязательно указать, какое решение может быть принято. Поле «Тип» фильтруется по категории, согласно настройкам справочника категорий.

 

Здесь же следует указать, кто (по мнению пользователя, вводящего ситуацию) может принять решение:

 

 

Обратите внимание, что поле «Ответственный за принятие решения» обязательно, но недоступно для прямого редактирования. От пользователя требуется выбрать роль принимающего решение, а система сама транслирует роль в пользователя. Так система управляет и обязательностью полей «Связи». Например, если указать, что решение принимает куратор проекта, то система не сможет транслировать пользователя, если не указан проект, и обязательное поле не будет заполнено. При корректном заполнении роли (это те самые роли в процессе, что используются в элементах БП), пользователь, которому будет передан шаг, транслируется успешно:

 


 

Изначально состояние ситуации устанавливается в «Поиск решения». Переходы между состояниями осуществляются автоматически по следующей схеме:

 

 

Согласно настройке типовых решений в справочнике категорий, сами типовые решения могут менять состояния ситуаций (например, если решение не устраивает клиента, система переведёт его из состояние «Решение принято» в состояние «Решение отменено», а затем, при выполнении типовых решений для данного состояния – опять в состояние «Поиск решения», и.т.д.). Сам процесс, управляющий обработкой ситуаций контролирует состояния. При изменении состояния запускаются типовые решения согласно их очереди, и после выполнения каждого из типовых решений  процесс проверяет, не изменилось ли состояние (и не требуется ли запустить другое типовое решение). В нашем тестовом примере после нажатия на ОК в разделе «Ситуации» появилась новая запись, а на деталь «Типовые решения» были добавлены решения, которые соледует добавлять автоматически согласно настройками справочника категорий:

 

 

Ответственному за принятие решения открылась карточка ситуации следующего вида:

 

 

В ней видно как обсуждение ситуации, так и список добавленных типовых решений. Пользователь может удалять типовые решения, менять их очерёдность, добавлять другие решения (что не были добавлены автоматически), всё согласно настройкам прав.

 

 

Система контролирует, чтобы не было добавлено одно и то же типовое решение для одного и того же состояния. Порядок выполнения типовых решений можно менять, разумеется, только внутри определённого состояния:

 

 

При нажатии «ОК» производится проверка, является ли текущий пользователь тем, кто принимает решение согласно указанной роли. Если это так – нажатие на «ОК» рассматривается, как согласие с описанным в комментариях решением. Иначе окно ситуации передаётся пользователю с ролью, которую укажет текущий пользователь. То есть, принятие решения по ситуации может выглядеть, например, так: менеджер указал в качестве принимающего решения куратора проекта, тот, в свою очередь, передал эту роль зав. отдела,  тот тоже колеблется и для полной уверенности передал ген. директору, который сказал: «разбирайтесь сами» и вернул ситуацию куратору проекта. А куратор, посмотрев обсуждение, решил, что надо спросить в финансовом отделе, можно ли «урезать осетра», и передал ситуацию главному бухгалтеру… и т.д., пока, наконец, главный бухгалтер не сказал: да, согласен, делаем именно так. На всякий случай система переспрашивает, точно ли пользователь берёт на себя ответственность за принятие решения:

 

 

И в случае утвердительного ответа заполняет служебную информацию по ситуации, кто и когда принял решение. Состояние меняется на «Решение принято», выполняются типовые решения для данного состояния (например, согласовать решение с ген. директором и сообщить решение клиенту), и если во время их выполнения ситуация не изменила состояние на «Решение отменено», то ситуация переходит в состояние «Выполнение решения», запускаются следующие типовые решения и т.д.

 

Фактически, процесс, управляющий ситуацией, через «пинг-понг» между ответственными за принятие решения идёт по пути от поиска решения до его выполнения, нанизывая на нить прямого пути жемчужины типовых решений, ситуативно меняя направление, ставя задачи, выполняя условные переходы, задавая вопросы и т.п., пока решение не будет выполнено. И тогда полную схему разрешения ситуации такого типа такой категории можно обернуть в новое типовое решение, или даже фиксированную схему бизнес-процесса, повторив  в ней пройденные шаги уже без «пинг-понга», с чёткой постановкой задач, сохранив её в виде сервиса.

 

Очевидным является применение раздела «Ситуации» в случаях, когда клиент отказался от бизнес-консультирования. Получив вместе с пакетом проектных элементов и этот раздел, клиент сам может сможет «на лету» обрабатывать различные бизнес-ситуации, а затем при желании оборачивать их в схемы бизнес – процессов. При этом сами эти схемы могут автоматически модифицироваться, если со временем где-то посредине существующей схемы возникает новая ситуация: существующее прохождение расширяется новой веткой.

 

Признаться, я сам до конца не изучил возможности этого раздела, но полагаю, что его потенциал высок, хотя очевидным недостатком является сложность управления типовыми решениями, в особенности с непривычки. Отмечу, что сам автор свой первый автогенерируемый процесс настраивал около шести часов, хотя разработка константной схемы заняла бы в три раза меньше времени. Но зато испытания на практике лишь одного такого процесса избавило от необходимости делать ещё десяток процессов, не говоря уже об обширности нетипичных ситуаций, им охваченных (скриншот раздела с рабочей базы клиента):

 

 

Можно было бы ещё многое сказать об особенностях и хитростях использования раздела «Ситуации», но здесь, как раз, та ситуация, когда лучше один раз увидеть, чем сто раз услышать. Поэтому отмечу лишь, что решение легко переносится на любые версии с 3.2.0. по 3.3.2 вместе с пакетом проектных элементов.

Поделиться

0 комментариев
Войдите или зарегистрируйтесь, чтобы комментировать