А что мешало сразу сделать сущность с набором атрибутов вроде «группа» или «алиас» (в смысле "=то же самое"), которые и фильтры и аналитика уже сами обработают потом как надо? И уже сам конкретный атрибут для сущности и называть «контрагент»/«партнёр»/«контактное лицо» или ещё как вздумается.
Вам интересно будет узнать, что я в такой крупной компании выполнял роль руководителя проекта от Заказчика и как раз был инициатором, в частности внедрения MDM. Другими словами, с одной стороны я выступаю на стороне Заказчика перед Подрядчиком, а с другой, я точно также, как и Подрядчик нам, полноценно сдаю результаты проекта своему руководству (а не просто прикрываю ему задницу и выполняю его KPI, чем грешат многие другие — одна из главных, имхо, причин всех плохих проектных результатов). Так вот, бороться «с круглыми кирпичами» приходилось уже мне самому и сложившимися у нас БП (здесь, кстати, очень важен размер своего административного ресурса в компании-внедренце), когда я сам разобрался и понял, каким «это должно стать». И честно признаюсь, борьба шла во многом не в мою пользу. Так что, сложившаяся рыночная ситуация, когда Подрядчики спешат «продать коробку», а не получившие желаемого Заказчики спешат «меньше или ничего» за неё заплатить — мне очень не удивительна. Полностью конструктивного диалога между П. и З. — не происходит (но мог бы).
Цитата: «правильнее было идти от процесса, а не от систем».
Это значит, сначала узнать, что Заказчик хочет дом из «круглых кирпичей» (как у него до автоматизации БП часто и выглядит), а потом вы вместе начинаете искать среди готовых решений «круглокирпичные». И понятно, что не находите и совместно соглашаетесь на «потом доработать напильником». (уже, наверное, понятно, что тут я не согласен с вашей цитатой) Имхо, стоит всё же показывать/пояснять, как на текущих предлагаемых ИТ решениях и их возможностях можно выстроить БП без внесения в них изменений и что менять, как ни крути, нужно и придётся. Иначе (если снять розовые очки и оценить все риски), чем крупнее Заказчик, тем острее он чувствует, что где-то его всё-таки «поимели» (не видя полного желаемого результата) и начинает выкручиваться из ситуации уже финансово (способов — масса, вплоть до не заплатить совсем или вернуть частично или все деньги — будет зависеть от степени «обиды» и жадности клиента).
Всё верно написано. MDM это основополагающая «система информационного порядка» в бизнесе. Когда «всё понял» — ясно, что именно с неё лучше и начинать автоматизировать бизнес. И тем не менее, почти все выбирают дорогу «граблей»: сначала автоматизируем «бардак», а после приходим к осознанию содеянного. Даже наглядный (в т.ч. инсайдерский) западный опыт, хоть и много чему учит, но «учатся мало» на нём.
Это значит, сначала узнать, что Заказчик хочет дом из «круглых кирпичей» (как у него до автоматизации БП часто и выглядит), а потом вы вместе начинаете искать среди готовых решений «круглокирпичные». И понятно, что не находите и совместно соглашаетесь на «потом доработать напильником». (уже, наверное, понятно, что тут я не согласен с вашей цитатой) Имхо, стоит всё же показывать/пояснять, как на текущих предлагаемых ИТ решениях и их возможностях можно выстроить БП без внесения в них изменений и что менять, как ни крути, нужно и придётся. Иначе (если снять розовые очки и оценить все риски), чем крупнее Заказчик, тем острее он чувствует, что где-то его всё-таки «поимели» (не видя полного желаемого результата) и начинает выкручиваться из ситуации уже финансово (способов — масса, вплоть до не заплатить совсем или вернуть частично или все деньги — будет зависеть от степени «обиды» и жадности клиента).