Привет, Хабр!
В этой статье мы хотим поделиться своим опытом работы с программным продуктом Microsoft Dymanics CRM 2013 Online – для чего и как его можно использовать, возможные проблемы типового развертывания, типовой функционал – достоинства, недостатки и пути решения проблем с наименьшими затратами.
Все изложенные тезисы основаны на практическом опыте внедрения системы у конкретного заказчика. Поэтому мы постарались опустить описание типовых задач, а сконцентрировать внимание на нюансах, с которыми может столкнуться большинство компаний при настройке системы и адаптации под требования бизнеса. Итак…
Когда вариант с облачными решениями становится привлекательным (наше субъективное мнение):
В итоге мы можем получить богатый функционал «из коробки» с возможностью его расширения и адаптации под требования бизнеса. На описании функционала и возможностей останавливаться нет смысла, вся информация в избыточном количестве имеется в открытых источниках информации.
Дальше настраиваем пользователей. И у нас есть два варианта: либо делаем пользователей CRM Online в облаке вручную, либо настраиваем интеграцию с существующим доменом AD. Отдельно остановимся на интеграции с Active Directory.
Преимущество использования интеграции с AD очевидно. С точки зрения администрирования – у нас будет единый механизм для управления пользователями, единые логины и пароли, — нам не придется вести отдельный набор учетных записей в домене и в CRM. Если пользователь увольняется, его доступ блокируется ко всем информационным ресурсам компании, включая CRM. Также возможно использовать одни и те же доменные политики, такие как сложность пароля, количество неправильных попыток и т.п. Но, для настройки интеграции потребуются и дополнительные ресурсы:
Нашего заказчика устроил более простой вариант с синхронизацией AD посредством DirSync.
Работа с почтой в CRM Online и CRM On-Premises — это тема для отдельной статьи. Сейчас же отметим, что наиболее полно почта в CRM Online интегрируется с облачными службами Exchange Onlinе, Gmail, Yahoo. В случае использования внешних коннекторов (Server Side Synchronization) есть ограничения в процессе синхронизации отправленной почты из CRM Online и почтовыми ящиками пользователей. В нашем случае используется синхронизация почты через внешний коннектор.
Доступ настроен, можно начинать работать. Но, как правило, требуется (или хочется) перенести исторические данные в новую систему. В общих случаях здесь все просто – CRM поддерживает основные открытые форматы данных, также можно выгрузить шаблоны в формате XML для подготовки данных для загрузки.
Какие здесь могут быть подводные камни? Рассмотрим практический бизнес-кейс.
В CRM организованы справочники географических понятий. Реализация произведена через создание новых сущностей системы по принципу: «Федеральный округ» — «Субъект РФ» — «Населенный пункт». То есть организована структура иерархических справочников. Такое решение (возможно, не идеальное) достаточно удобно с точки зрения пользователя и администрирования данных. Оно позволит в дальнейшем расширять аналитику по городам (например, численность населения, закрепление персональной ответственности, классификация по интересам и прочее).
В шаблоны, подготовленные CRM, внесены данные и успешно загружены в систему. Двигаемся дальше.
Теперь готовим данные по клиентам компании, опять же, на основе шаблонов CRM. В данных по каждому клиенту в обязательном порядке содержится информация о его географической принадлежности (федеральный округ, субъект РФ, населенный пункт). Начинаем загрузку.
Здесь мы сталкиваемся с первой проблемой — система выдает ошибки импорта (ссылка на дублирующие данные). В чем же дело?
А дело в том, что населенных пунктов с одинаковыми названиями в различных субъектах РФ множество. Оказывается, несмотря на то, что мы организовали иерархическую структуру справочников и при подготовке шаблона с данными для загрузки указали, в каком субъекте РФ находится тот или иной населенный пункт с одинаковым названием, при импорте система игнорирует этот факт и смотрит уникальность по каждому полю. Так как городов с одинаковыми названиями у нас много, то загрузить такие данные CRM не может.
Выход из ситуации? На усмотрение компании их может быть несколько:
Какой способ выбрать, каждая компания выбирает сама. Главное — знать о потенциальной проблеме и на этапе планирования работ учесть возможные риски.
Кстати, аналогичная проблема может возникнуть и при импорте организаций и контактов: здесь может появиться конфликт между полем «Телефон» в организации и полем «Рабочий телефон» контакта (CRM не допускает в этом поле одинаковых значений). Выход – либо разные значения номеров телефонов, либо использование собственных полей (атрибутов).
С чем еще можно столкнуться, продвигаясь далее, при первичной настройке основных разделов системы?
Рассмотрим следующий практический бизнес-кейс на примере компании, которая занимается производство и продажей обуви или одежды. Как правило, такие компании привыкли оперировать примерно таким минимальным набором характеристик единицы товара:
Все отлично и логично. Но, к сожалению, в дальнейшем мы поймем, что воспользоваться стандартным функционалом формирования коммерческих предложений, заказов, счетов мы попросту не сможем.
Дело в том, что при выборе продуктов для спецификации документа нам будет доступно для его идентификации только поле «наименование». Таким образом, мы увидим список одинаковых названий товарных позиций (артикул, цвет, размер и прочее — недоступны). Модификация штатного функционала работы со спецификацией довольно трудоемка; к тому же модифицировать придется отдельно для каждого раздела (возможная сделка, коммерческое предложение, заказ, счет).
Вариант, требующий гораздо меньших затрат и более универсальный, — это создание js-скрипта, который регистрируется в свойствах формы.
Дополнительно вводим еще одно поле в карточку продукта, где будем записывать собственно его наименование, а системное поле «наименование» переименуем в «полное наименование». Принцип работы скрипта следующий (например): он считывает информацию из полей «наименование», «цвет», «размер» и автоматически записывает данные в поле «полное наименование» через разделитель (пробел, запятая). Таким образом мы автоматически получаем уникальное наименование единицы товара в виде «туфли Shoes, черный, 42». Это значение и будет автоматически отображаться в стандартных спецификациях CRM.
Для создания такого скрипта хорошо подходит функция наподобие string.format, она принимает маску в формате .Net
После подключения этой функции к решению можно написать небольшую обертку, которая принимает формат и список полей, вычисляет их значения и записывает отформатированный результат в нужное поле.
Как видно, здесь
‘name’ – это имя поля наименование сущности
‘{0} {1} {2}‘ – маска, соединяющая 3 строки через пробелы
[‘etrnova_fullname’, ‘etrnova_colour’, ‘size’] – имена полей, которые подставляются в маску.
Результат достигнут. Возможно, решение не идеальное, но нетрудозатратное и быстрое. Тем более, что данный механизм формирования составного поля в дальнейшем можно применить и в других разделах системы (в случае необходимости).
Как известно, в Microsoft Dymanics CRM 2013 теперь все объекты теперь могут включать в себя картинки (фотографии).
Но есть ограничения:
Если такие ограничения не влияют на объект «Контакт», например, фотография партнера, то практическое применение для других объектов становится весьма условным (ограничения по количеству и маленький размер).
Но в реальной жизни нередко возникает потребность в работе с изображениями без ограничения их количества и размера, например:
Возможно ли реализовать такой функционал, какими способами и с какими затратами? Давайте рассмотрим.
Тут может быть несколько вариантов решения, каждый — со своими недостатками. Можно сделать дочернюю сущность, в которой есть поле «фотография». Поле чего, используя JavaScript API, отображать фотографии в виде списка. Есть прекрасное коммерческое решение, которое использует этот подход. Недостаток подхода — упомянутое ограничение по размеру фотографий. Чтобы попытаться его обойти, можно записать фотографию в текстовое поле в формате Base64. Конечно, это приведет к излишнему потреблению места, однако, если фотографий не очень много, решение вполне приемлемо.
При этом ограничения на размер изображения не будет, но будет ограничение на размер файла с фотографией ~500кб; также фотографии могут быть существенно больше, чем 144x144.
Ну и наконец, если хочется полностью обойти это ограничение, можно хранить фотографии в сторонней системе, и написать интерфейс, который отображает их список внутри сущности. Такое решение, конечно, гораздо сложнее с точки зрения установки и поддержки, но в некоторых случаях оправдано.
В нашем случае наиболее предпочтительным оказался второй вариант, поскольку он с одной стороны предоставляет возможность хранить картинки достаточного для наших задач размера, с другой стороны — менее сложен в развертывании, чем третий. Для его реализации создаем сущность Photo в ней делаем стоковые поля …EntityId, …EntityType, ImageContent, на форме реализуем интерфейс для отображения и редактирования набора картинок, наподобие следующего:
Таким образом, можно решить возникшую проблему и расширить функционал системы. Мы думаем, что найдется еще много бизнес-задач, где это решение может быть применено.
В большинстве случаев базовый функционал для организации работы с организациями и контактами, который предлагает система, более чем достаточен (с учетом возможных дополнительных настроек разделов штатными средствами системы).
Единственное неудобство, с которым часто сталкиваются пользователи, связано исключительно со спецификой нашей страны. Ни для кого не секрет, что в силу различных причин у одной и той же компании может быть несколько юридических лиц. При этом контакты остаются одни и те же.
К сожалению, стандартный функционал CRM позволяет связать контакт только с одной организацией, а использование функционала «головная организация» не всегда удобно, в частности, ссылка на контакт не появляется в связанном представлении контактов в организации, что не всегда удобно для оперативной работы конечных пользователей.
Можно ли достаточно легко обойти это недостаток системы? Можно.
На самом деле, поле «контакт» придется оставить, возможно, переименовать его в «основной контакт», и можно завести также связь Многое-ко-Многим между клиентами и контактами. На форму нужно добавить на форму специальную табличку для отображения редактирования контактов. Основной контакт будет использоваться в представлениях, а также, допустим, при построении графиков, которые не поддерживают множественные связи.
После этой процедуры появляется возможность выбора нескольких организаций из списка при формировании (редактировании) информации о контакте.
Соответственно, в карточке контакта будет указано, с какими организациями он связан. А после сохранения данных указанный контакт автоматически отобразится в связанном представлении в каждой указанной организации.
Стандартная система прав доступа CRM позволяет оперировать ролями прав доступа к разделам информации и записям на уровне пользователя, подразделения и организации, а также на уровне рабочих групп. Этой системы управления правами доступа пользователей в большинстве случаев бывает достаточно. Однако в реально жизни бывают исключения. Пример — в компании есть региональные менеджеры, которые контролируют сделки в закрепленных за ними регионах. Причем в штатной структуре компании все региональные менеджеры находятся в одном структурном подразделении.
Если оперировать штатными средствами, то вариант решения будет таким: необходимо вводить «искусственные» штатные подразделения для раздачи прав доступа на записи. Это, с одной стороны, решит проблему, не прибегая к услугам технических специалистов, но с другой стороны, породит новую проблему — штатная структура компании в CRM будет отличаться от реально существующей, плюс количество этих искусственно созданных подразделений будет равно количеству региональных менеджеров.
Но существует и другой способ решить эту проблему, причем права доступа на записи будут раздаваться на основе информации о том, к какому региону принадлежит организация (интерес, сделка). Для этого для начала более посмотрим на то, как устроена система прав доступа в CRM. Предположим, пользователь пытается получить доступ определенного типа (на чтение, на изменения и т.п.) к некой записи. Почему он может его получить? Есть два варианта:
Таким образом мы можем “расшаривать” каждую запись для регионального менеджера, соответствующего региону сущности. Это несложная работа, и её легко автоматизировать, написав специальный plugin, который будет предоставлять (или убирать) общий доступ при изменении поля, определяющего регион.
Обратим внимание на раздел “тип отношений”. Мы видим пункты “Назначить”, “Общий доступ” и т.п., и для каждого из этих действий можно определить тип поведения. Например, выбрав для пункта “Общий доступ” тип поведения «каскад», мы получим следующее: если кто-то предоставляет общий доступ к сущности, то мы получим доступ и к дочерней тоже.
Конечно, мы хотим, чтобы права у региональных менеджеров были не только на запись, но и на все дочерние записи. Для этого настраиваем отношение:
Итак,
Продукт, возможно, спорный и неоднозначный: с одной стороны, он позволяет проводить настройки (UI, струкутра базы данных, бизнес-процессы) под бизнес-требования штатными средствами, не прибегая к программированию (и это, однозначно, его сильная сторона и конкурентное преимущество). Но с другой стороны, в этом заключается и его «слабость» — пользователь оказывается зажат в рамки этого штатного функционала, и дальнейшие расширения функционала возможны только с помощью технических специалистов (то есть программирование).
Данное утверждение справедливо и для настройки пользовательского интерфейса, и для бизнес-процессов, и для базовой логики работы системы.
В качестве простого бизнес-решения может подойти решение «из коробки», в случае сложных бизнес-процессов и бизнес-требований, выходящих за рамки базового функционала, увы, без доработок не обойтись, вопрос только — какой ценой…
В этой статье мы хотим поделиться своим опытом работы с программным продуктом Microsoft Dymanics CRM 2013 Online – для чего и как его можно использовать, возможные проблемы типового развертывания, типовой функционал – достоинства, недостатки и пути решения проблем с наименьшими затратами.
Все изложенные тезисы основаны на практическом опыте внедрения системы у конкретного заказчика. Поэтому мы постарались опустить описание типовых задач, а сконцентрировать внимание на нюансах, с которыми может столкнуться большинство компаний при настройке системы и адаптации под требования бизнеса. Итак…
Почему «облако»?
Когда вариант с облачными решениями становится привлекательным (наше субъективное мнение):
- есть потребность в CRM системе, но нет четкого видения «что, зачем и как»;
- количество потенциальных пользователей системы достаточно небольшое;
- отсутствует необходимая инфраструктура для развертывания решения;
- есть желание оптимизировать организацию внутренней системы поддержки нового решения;
- нужно минимизировать финансовые затраты на приобретение (поддержку) решения – здесь все ясно – пробный период в 30 дней, невысокая стоимость подписки, достаточно льготные условия оплаты (отсрочка платежа).
В итоге мы можем получить богатый функционал «из коробки» с возможностью его расширения и адаптации под требования бизнеса. На описании функционала и возможностей останавливаться нет смысла, вся информация в избыточном количестве имеется в открытых источниках информации.
Зарегистрировали. Что дальше?
Дальше настраиваем пользователей. И у нас есть два варианта: либо делаем пользователей CRM Online в облаке вручную, либо настраиваем интеграцию с существующим доменом AD. Отдельно остановимся на интеграции с Active Directory.
Преимущество использования интеграции с AD очевидно. С точки зрения администрирования – у нас будет единый механизм для управления пользователями, единые логины и пароли, — нам не придется вести отдельный набор учетных записей в домене и в CRM. Если пользователь увольняется, его доступ блокируется ко всем информационным ресурсам компании, включая CRM. Также возможно использовать одни и те же доменные политики, такие как сложность пароля, количество неправильных попыток и т.п. Но, для настройки интеграции потребуются и дополнительные ресурсы:
- Если хотим просто синхронизировать, то потребуется сервер в домене с программным обеспечением DirSync.
- Если хотим организовать единый вход (Single Sign On), тогда потребуется инфраструктура ADFS.
Нашего заказчика устроил более простой вариант с синхронизацией AD посредством DirSync.
Подробнее про настройку синхронизации с AD можно посмотреть на странице
Настройка почтовой системы.
Работа с почтой в CRM Online и CRM On-Premises — это тема для отдельной статьи. Сейчас же отметим, что наиболее полно почта в CRM Online интегрируется с облачными службами Exchange Onlinе, Gmail, Yahoo. В случае использования внешних коннекторов (Server Side Synchronization) есть ограничения в процессе синхронизации отправленной почты из CRM Online и почтовыми ящиками пользователей. В нашем случае используется синхронизация почты через внешний коннектор.
Подробнее про конфигурацию почты можете посмотреть здесь и здесь
Загрузка начальных данных
Доступ настроен, можно начинать работать. Но, как правило, требуется (или хочется) перенести исторические данные в новую систему. В общих случаях здесь все просто – CRM поддерживает основные открытые форматы данных, также можно выгрузить шаблоны в формате XML для подготовки данных для загрузки.
Какие здесь могут быть подводные камни? Рассмотрим практический бизнес-кейс.
В CRM организованы справочники географических понятий. Реализация произведена через создание новых сущностей системы по принципу: «Федеральный округ» — «Субъект РФ» — «Населенный пункт». То есть организована структура иерархических справочников. Такое решение (возможно, не идеальное) достаточно удобно с точки зрения пользователя и администрирования данных. Оно позволит в дальнейшем расширять аналитику по городам (например, численность населения, закрепление персональной ответственности, классификация по интересам и прочее).
В шаблоны, подготовленные CRM, внесены данные и успешно загружены в систему. Двигаемся дальше.
Теперь готовим данные по клиентам компании, опять же, на основе шаблонов CRM. В данных по каждому клиенту в обязательном порядке содержится информация о его географической принадлежности (федеральный округ, субъект РФ, населенный пункт). Начинаем загрузку.
Здесь мы сталкиваемся с первой проблемой — система выдает ошибки импорта (ссылка на дублирующие данные). В чем же дело?
А дело в том, что населенных пунктов с одинаковыми названиями в различных субъектах РФ множество. Оказывается, несмотря на то, что мы организовали иерархическую структуру справочников и при подготовке шаблона с данными для загрузки указали, в каком субъекте РФ находится тот или иной населенный пункт с одинаковым названием, при импорте система игнорирует этот факт и смотрит уникальность по каждому полю. Так как городов с одинаковыми названиями у нас много, то загрузить такие данные CRM не может.
Выход из ситуации? На усмотрение компании их может быть несколько:
- другая система организации справочной информации, например, в виде одной сложной сущности со всеми необходимыми атрибутами, но, как показывает практика, организация связи типа «сам на себя» — не лучший вариант;
- организация загрузки данных с помощью скриптов (требуется привлечение соответствующих технических специалистов);
- изменение наименования населенных пунктов: у каждого уникальное название, после успешного импорта можно переименовать обратно без потери информации (это дополнительный объем работы по последующей корректировке данных).
Какой способ выбрать, каждая компания выбирает сама. Главное — знать о потенциальной проблеме и на этапе планирования работ учесть возможные риски.
Кстати, аналогичная проблема может возникнуть и при импорте организаций и контактов: здесь может появиться конфликт между полем «Телефон» в организации и полем «Рабочий телефон» контакта (CRM не допускает в этом поле одинаковых значений). Выход – либо разные значения номеров телефонов, либо использование собственных полей (атрибутов).
Доработка основного функционала CRM (Продукты)
С чем еще можно столкнуться, продвигаясь далее, при первичной настройке основных разделов системы?
Рассмотрим следующий практический бизнес-кейс на примере компании, которая занимается производство и продажей обуви или одежды. Как правило, такие компании привыкли оперировать примерно таким минимальным набором характеристик единицы товара:
- наименование;
- цвет;
- размер;
- артикул;
- сезон;
| артикул | наименование | цвет | размер | сезон |
| 000142 | туфли Shoes | черный | 42 | осень |
| 000143 | туфли Shoes | черный | 43 | осень |
Все отлично и логично. Но, к сожалению, в дальнейшем мы поймем, что воспользоваться стандартным функционалом формирования коммерческих предложений, заказов, счетов мы попросту не сможем.
Дело в том, что при выборе продуктов для спецификации документа нам будет доступно для его идентификации только поле «наименование». Таким образом, мы увидим список одинаковых названий товарных позиций (артикул, цвет, размер и прочее — недоступны). Модификация штатного функционала работы со спецификацией довольно трудоемка; к тому же модифицировать придется отдельно для каждого раздела (возможная сделка, коммерческое предложение, заказ, счет).
Вариант, требующий гораздо меньших затрат и более универсальный, — это создание js-скрипта, который регистрируется в свойствах формы.
Дополнительно вводим еще одно поле в карточку продукта, где будем записывать собственно его наименование, а системное поле «наименование» переименуем в «полное наименование». Принцип работы скрипта следующий (например): он считывает информацию из полей «наименование», «цвет», «размер» и автоматически записывает данные в поле «полное наименование» через разделитель (пробел, запятая). Таким образом мы автоматически получаем уникальное наименование единицы товара в виде «туфли Shoes, черный, 42». Это значение и будет автоматически отображаться в стандартных спецификациях CRM.
Для создания такого скрипта хорошо подходит функция наподобие string.format, она принимает маску в формате .Net
После подключения этой функции к решению можно написать небольшую обертку, которая принимает формат и список полей, вычисляет их значения и записывает отформатированный результат в нужное поле.
function calcName(name, mask, params) {
var name = Xrm.Page.getAttribute(name);
var vals = [];
for (param in params) {
var val = Xrm.Page.getAttribute(params[param]);
val = val != null ? val.getValue() : "";
vals.push(val != null ? val : "");
}
name.setValue(mask.format.apply(mask, vals));
}
После чего привязать функцию к событиям изменения формы.
Как видно, здесь
‘name’ – это имя поля наименование сущности
‘{0} {1} {2}‘ – маска, соединяющая 3 строки через пробелы
[‘etrnova_fullname’, ‘etrnova_colour’, ‘size’] – имена полей, которые подставляются в маску.
Результат достигнут. Возможно, решение не идеальное, но нетрудозатратное и быстрое. Тем более, что данный механизм формирования составного поля в дальнейшем можно применить и в других разделах системы (в случае необходимости).
Фотографии в CRM
Как известно, в Microsoft Dymanics CRM 2013 теперь все объекты теперь могут включать в себя картинки (фотографии).
Но есть ограничения:
- хранятся они в поле с типом «изображение»;
- выводятся только в верхний левый угол формы;
- на один объект может быть только одно поле-изображение;
- размер изображения ограничен 144x144px.
Если такие ограничения не влияют на объект «Контакт», например, фотография партнера, то практическое применение для других объектов становится весьма условным (ограничения по количеству и маленький размер).
Но в реальной жизни нередко возникает потребность в работе с изображениями без ограничения их количества и размера, например:
- карточки продукта (изображения товара);
- клиенты (мерчендайзинг).
Возможно ли реализовать такой функционал, какими способами и с какими затратами? Давайте рассмотрим.
Тут может быть несколько вариантов решения, каждый — со своими недостатками. Можно сделать дочернюю сущность, в которой есть поле «фотография». Поле чего, используя JavaScript API, отображать фотографии в виде списка. Есть прекрасное коммерческое решение, которое использует этот подход. Недостаток подхода — упомянутое ограничение по размеру фотографий. Чтобы попытаться его обойти, можно записать фотографию в текстовое поле в формате Base64. Конечно, это приведет к излишнему потреблению места, однако, если фотографий не очень много, решение вполне приемлемо.
При этом ограничения на размер изображения не будет, но будет ограничение на размер файла с фотографией ~500кб; также фотографии могут быть существенно больше, чем 144x144.
Ну и наконец, если хочется полностью обойти это ограничение, можно хранить фотографии в сторонней системе, и написать интерфейс, который отображает их список внутри сущности. Такое решение, конечно, гораздо сложнее с точки зрения установки и поддержки, но в некоторых случаях оправдано.
В нашем случае наиболее предпочтительным оказался второй вариант, поскольку он с одной стороны предоставляет возможность хранить картинки достаточного для наших задач размера, с другой стороны — менее сложен в развертывании, чем третий. Для его реализации создаем сущность Photo в ней делаем стоковые поля …EntityId, …EntityType, ImageContent, на форме реализуем интерфейс для отображения и редактирования набора картинок, наподобие следующего:
Таким образом, можно решить возникшую проблему и расширить функционал системы. Мы думаем, что найдется еще много бизнес-задач, где это решение может быть применено.
Организации и контакты
В большинстве случаев базовый функционал для организации работы с организациями и контактами, который предлагает система, более чем достаточен (с учетом возможных дополнительных настроек разделов штатными средствами системы).
Единственное неудобство, с которым часто сталкиваются пользователи, связано исключительно со спецификой нашей страны. Ни для кого не секрет, что в силу различных причин у одной и той же компании может быть несколько юридических лиц. При этом контакты остаются одни и те же.
К сожалению, стандартный функционал CRM позволяет связать контакт только с одной организацией, а использование функционала «головная организация» не всегда удобно, в частности, ссылка на контакт не появляется в связанном представлении контактов в организации, что не всегда удобно для оперативной работы конечных пользователей.
Можно ли достаточно легко обойти это недостаток системы? Можно.
На самом деле, поле «контакт» придется оставить, возможно, переименовать его в «основной контакт», и можно завести также связь Многое-ко-Многим между клиентами и контактами. На форму нужно добавить на форму специальную табличку для отображения редактирования контактов. Основной контакт будет использоваться в представлениях, а также, допустим, при построении графиков, которые не поддерживают множественные связи.
После этой процедуры появляется возможность выбора нескольких организаций из списка при формировании (редактировании) информации о контакте.
Соответственно, в карточке контакта будет указано, с какими организациями он связан. А после сохранения данных указанный контакт автоматически отобразится в связанном представлении в каждой указанной организации.
Доработка прав доступа
Стандартная система прав доступа CRM позволяет оперировать ролями прав доступа к разделам информации и записям на уровне пользователя, подразделения и организации, а также на уровне рабочих групп. Этой системы управления правами доступа пользователей в большинстве случаев бывает достаточно. Однако в реально жизни бывают исключения. Пример — в компании есть региональные менеджеры, которые контролируют сделки в закрепленных за ними регионах. Причем в штатной структуре компании все региональные менеджеры находятся в одном структурном подразделении.
Если оперировать штатными средствами, то вариант решения будет таким: необходимо вводить «искусственные» штатные подразделения для раздачи прав доступа на записи. Это, с одной стороны, решит проблему, не прибегая к услугам технических специалистов, но с другой стороны, породит новую проблему — штатная структура компании в CRM будет отличаться от реально существующей, плюс количество этих искусственно созданных подразделений будет равно количеству региональных менеджеров.
Но существует и другой способ решить эту проблему, причем права доступа на записи будут раздаваться на основе информации о том, к какому региону принадлежит организация (интерес, сделка). Для этого для начала более посмотрим на то, как устроена система прав доступа в CRM. Предположим, пользователь пытается получить доступ определенного типа (на чтение, на изменения и т.п.) к некой записи. Почему он может его получить? Есть два варианта:
- Среди ролей пользователя есть такая, которая позволяет получить требуемый доступ к сущности.
- Пользователю предоставлен доступ к ней (“share”).
Таким образом мы можем “расшаривать” каждую запись для регионального менеджера, соответствующего региону сущности. Это несложная работа, и её легко автоматизировать, написав специальный plugin, который будет предоставлять (или убирать) общий доступ при изменении поля, определяющего регион.
Обратим внимание на раздел “тип отношений”. Мы видим пункты “Назначить”, “Общий доступ” и т.п., и для каждого из этих действий можно определить тип поведения. Например, выбрав для пункта “Общий доступ” тип поведения «каскад», мы получим следующее: если кто-то предоставляет общий доступ к сущности, то мы получим доступ и к дочерней тоже.
Конечно, мы хотим, чтобы права у региональных менеджеров были не только на запись, но и на все дочерние записи. Для этого настраиваем отношение:
Заключение
Итак,
- Microsoft Dynamics CRM 2013 Online «из коробки» представляет из себя мощный и достаточный инструмент.
- Microsoft Dynamics CRM 2013 Online обладает простотой и гибкостью настройки бизнес-процессов и объектов системы без программирования.
- Расширение функционала Microsoft Dynamics CRM 2013 Online, которое невозможно произвести с помощью настроек, достаточно быстро и легко решаются с помощью средств программирования.
- Используемые технологии и архитектура решения позволяют адаптировать систему под конкретную специфику деятельности практически любой компании и интегрировать решение с существующими информационными системами.
Продукт, возможно, спорный и неоднозначный: с одной стороны, он позволяет проводить настройки (UI, струкутра базы данных, бизнес-процессы) под бизнес-требования штатными средствами, не прибегая к программированию (и это, однозначно, его сильная сторона и конкурентное преимущество). Но с другой стороны, в этом заключается и его «слабость» — пользователь оказывается зажат в рамки этого штатного функционала, и дальнейшие расширения функционала возможны только с помощью технических специалистов (то есть программирование).
Данное утверждение справедливо и для настройки пользовательского интерфейса, и для бизнес-процессов, и для базовой логики работы системы.
В качестве простого бизнес-решения может подойти решение «из коробки», в случае сложных бизнес-процессов и бизнес-требований, выходящих за рамки базового функционала, увы, без доработок не обойтись, вопрос только — какой ценой…
