Работа нескольких отделов продаж в одной базе.

[Alasm]

Есть несколько проектов, вернее НЕСКОЛЬКО отделов продаж, у каждого разные продукты и прайсы, но Клиенты (Бизнес-партнеры и Контакты) общие, т.е. их видят все, править может только Оператор и выше.
Общее руководство "видит" все действия БП (Бизнес-партнеров), контакты и пр.
Начальник каждого отдела - записи только своего отдела - это все прекрасно регулируется ролями безопастности и Подразделениями.
Сложность в том, что у каждого из БП должен быть свой куратор/ответственный - менеджер отдела продаж, в каждом отделе свой. Т.е. за "ООО Висилиск" в проекте "А" ответственный Иван Иванович, в в Проекте "Б" ответственный Борис Бирисович.(кол-во ответственных = кол-ву отделов продаж/проектов)
Именно по-этому не подходит существующий аттрибут "Owner", т.к. он содержит только одно значение.

Решение типа - на каждый отдел новый лукап с пользователем (получается закладка в Бизнес-партнере с кучей лукапов) совсем не эстетично, и наверно неправильно - делать 15 одинаковых связей между сущностями, но это выход.
Сделал связь многие-ко-многим с Пользователем - как и положено, в БП появилась вкладка (или как правильно - слева область где Действия, контакты, адреса), назвал "Менеджеры", сделал представления для проектов а-ля "Клиенты проекта "А", которые формируются по правилу "Если подразделение связанной сущности Пользователь = А", все ок.
Как вот сделать бизнес-процесс, например, по смене ответственного в действиях в случае замены менеджера одного на другого не придумал.
Я остановился на такой логике: если был добавлен еще один менеджер из такого-же проекта(отдела), то все действия, назначенные первому, переназначаются новому и связь с первым менеджером удаляется.
Еще есть выход - "развести" проекты по разным деплоям - но пропадает эффект синергии для заказчика.... да и гемора с отчетами, синхронизация БП и всего прочего... б-р-р..
У кого какие есть мнения или решения?
Возможно нужно перестроить методы работы Отделов продаж - но это дело не быстрое и не благодарное ...

[Alasm]

Из рук-ва администратора:

Zitat:

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

Интересно, почему с "Несколькими клиентскими базами"?

[slivka_83]

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

По Вашему вопросу: а зачем нужны эти кураторы? чем руководителей не хватает?

[Артем Enot Грунин]

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

[Alasm]

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

[slivka_83]

Zitat:

Slivka_83 - а в чем прикол разных баз у холдинга? Получается тратим деньги (з.п. менеджеров и т.д) на поиск в одной фирме и еще раз тратим в следующей ....

Одна дочерняя компания продает подводные лодки, а друга дочернияя компания пирожки с маком

[slivka_83]

Zitat:

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

Т.е. Вы хотите сказать, что продажники после заключения сделки "умывают руки"? Ну так переназначьте запись на этого Вашего куратора и все

[Артем Enot Грунин]

Когда вы смотрите Историю или Действия Организации вы можете включать в нее не только те Действия, которые были выполнены по отношению непосредственно клиенту, но и ко всем связанным записям (контакты от организации, сделки, заказы и пр.) - на вкладке Действия и Журнал есть выпадающие списки представлений. Иными словами, создайте новый объект "Направление", разрешите для него Действия, свяжите его с Пользователем (владельцем должен быть пользователь), Подразделением и Организацией и дело в шляпе. Тогда к каждой Организации может быть приколочено несколько ваших Направлений деятельности и за каждым из них закреплен конкретный менеджер. Тогда можно будет прицепить БП на смену ответственного за Направление у конкретной Организации и дело в шляпе.

[Alasm]

slivka_83
Дело в том, что и подводные лодки и пирожки еще и воздух и лыжи - все это продается одним и тем же Бизнес-партнерам. Именно в общей базе весь цымус - если ты захочешь продавать им же например гвозди - есть уже готовая база - на запуск такого проекта уйдет очень мало времяни.
Что имелось ввиду под "умывают руки"? Конечно они не умывают - идут повторные продажи (в идеале).
Еще раз. Каждый из менеджеров продает свою группу товаров-услуг, вернее не свою, а своего подразделения. Таким образом на одного Бизнес-партнера приходиться по менеджеру от каждого отдела продаж. И продавать позиции своего отдела этому БП может только один менеджер - он и есть ответственный. Вопрос в том что бы не делать 100 связей для лукапов типа "один-ко-многим: Пользователь - Бизнес партнер" для каждого отдела. Гораздо нагляднее и правильнее одна связь "многие-ко-многим: Пользователь - Бизнес-партнер (см. картинку).
Затык в том, что отследить в бизнес-процессах эту связь не могу....

[slivka_83]

Я окончательно запутался...

Zitat:

продавать позиции своего отдела этому БП может только один менеджер - он и есть ответственный. Вопрос в том что бы не делать 100 связей для лукапов типа "один-ко-многим: Пользователь - Бизнес партнер" для каждого отдела.

Но у каждой записи и так есть владелец, т.е. связь Пользователь - Бизнес партнер и так существует! и она одна (по умолчанию )???

[Alasm]

slivka_83 Блин. А отделов-то Несколько! Нужен ответственный в КАЖДОМ отделе! ) читай с начала.
Артем Enot Грунин Про связанные понятно.Организации - это Бизнес-партнеры?
Все одно никак. Сделал по твоему сценарию - но при смене владельца у Направления - он сменился и в других записях - владелец и есть владелец что он один. Да и дубль инфы у Направления с Подразделениями получается.... но идея хорошая, например для автоматического назначения ответственного для БП из ответственного для направления.

[Bondonello]

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

[Артем Enot Грунин]

Коллеги, я забил...

[slivka_83]

я тоже хамят тут

[Alasm]

Информ-ативные посты, что скажешь.
slivka_83 Почему читай с начала - так "ответственный" в моем контексте это "менеджер, который отвечает за взаимодействие с БП в рамках отдела в котором он работает, т.е. продает (и остальные телодвижения тоже) ему товары и услуги, на которых этот отдел специализируется" и таких отделов 15 (будет больше). Об этом в первом посте написано, а он в начале (сверху, up, колесико от себя)...
Bondonello
Ваш вариант похож на ответ....
Расшаривают - т.е. дают доступ выше чтения? А какие типы связей у БЛ с остальными сущьностами?

Еще есть мысль реализовать через роли отношений - выйдет что путное отпишу.

[Bondonello]

Zitat:

Расшаривают - т.е. дают доступ выше чтения? А какие типы связей у БЛ с остальными сущьностами?

С помощью плагинов можно настроить на любой вид прав: чтение, полный доступ ...
Есть сущность: Бизнес-линия, которая связана отношение 1:N с сущностью Бизнес-линия для организации (БЛ для ВС, БЛ для Заказа ...). БЛ для организации связана уже с организацией, и при создании нового объекта БЛ в орг-ции (открытии БЛ) происходит предоставление доступа к организации назначенному ответственному по БЛ.