Схема отношений между сущностями - посоветуйте как правильно

[senin24]

Здравствуйте
Веду подготовку ТЗ по настройке CRM для организации.
Специфика Компании
Одновременное выполнение небольшого количества проектов (1-5 шт.), которые по времени выполняются в течении неск месяцев каждый. У каждого проекта один заказчик, и много подрядчиков, т.е. Компания является координатором проекта.

В качестве сущности Проекта выбрана стандартная сущность - Возможная сделка.
Нужно отслеживать подрядчиков по проекту, и договор между Компанией и клиентом.

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

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

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

[senin24]

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

[-O_o-]

Цитата:

Сообщение от senin24

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

Вечер добрый.
Хотел бы отметить сразу несколько тревожных на мой взгляд моментов.

1. Насчет сущности "Проект"
Почему вы решили использовать ВС для решения вашего вопроса? Что будите делать, когда компания начнет заниматься продажами со (счетами, заказами, договорами и ком.предами) ?

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

Цитата:

Если вы уверены, что этого достаточно - действуйте. Если же ролей хотя бы три (партнер, субподрядчик, генподрядчик, офшор, служба доставки крошки-картошки). Я бы пересмотрел мнение на предмет соединений.

Я бы сделал просто сощность "участник" например, в которой бы создал 2-ва поля. лукам на организацию и список ролей. Таким образом вы сможете хоть 100 компаний присоединить поб разными ролями к этому проекту

3. Справочник услуг.
Рекомендовал бы связаться его с сущностью "участник" отношением N:N. Таким образом у вас будет контейнер по проекту. Какие компании с какой ролью и услугой.

3. По поводу диаграммы.
В стандартной модели CRM у одной организации куча контактов, а не наоборот. И лучше уберите стрелочки, а то запутанно все

Вроде бы ничего не забыл

[senin24]

Спасибо за развернутый ответ.
Стрелочки точно вносят смуту - уберу))

1. По ВС - думаю не проблема - потом можно будет добавить поле с выбором вида ВС (Проект, Заказ, Продажа и т.п.). А делать отдельную сущность, которая по сути бы повторяла функционал ВС - слишком трудоемко.

2 и 3. Специфики такова, что Подрядчики занимаются строго определенными услугами и каждый раз указывать для них заново роль (тип услуги) – неудобно и чревато ошибками. Но идея очень интересная.

4. Да, вы правы, я ошибся, конечно же стандартно одна Организация ко множеству контактов

Обновил схему

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

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

[senin24]

Мне кажется, соединения/подключения это слишком универсальный и мощный инструмент, чтобы его доверять среднестатистическому менеджеру (в моем случае точно) - с течением времени, люди поменяются, потом не рагребешься в записях - кто как что наподсоединял (( а с жестким отношением все более прозрачно и вероятность ошибки меньше.
Если ошибаюсь, поправьте.

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

Все верно, "четкие" связи значительно более прозрачны для пользователя. В вашем случае таких две: "подрядчик" и "конкурент". Если вы уверены, что этого достаточно - действуйте. Если же ролей хотя бы три (партнер, субподрядчик, генподрядчик, офшор, служба доставки крошки-картошки). Я бы пересмотрел мнение на предмет соединений.

[senin24]

т.е. слишком много связей между одними и теми же сущностями усложнит поддержку системы?

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

Вы, кстати, уверены что конкурент - это отдельная сущность? Понимаю, что вы хотите использовать стандартный объект, однако это тоже не всегда удобно. В ряде отраслей (например, в той же ИТ) нет четкой грани между партнером и конкурентом. Как правило все компании соглашаются на подряды, хотя изначально может идти конкуренция за клиента.
Я это говорю к тому, что конкурент, скорее всего, это тоже организация

[senin24]

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