Microsoft Dynamics CRM: подходы к настройке и интеграции

Прежде чем двигаться далее, хотелось бы сказать несколько слов об особенностях системы Microsoft Dynamics CRM. По сути, данная система представляет собой конструктор, включающий в себя некую базовую функциональность с возможностями ее расширения. Сама система есть разветвленное веб-приложение со всеми вытекающими последствиями – разработка под систему выполняется с использованием .NET Framework (версии 2.0 и выше), «тонкого» клиента, встроенной интеграции с MS Outlook и MS Exchange и т.д. Все это открывает широкие возможности для интеграции Microsoft Dynamics CRM с другими системами, учитывая, конечно, перечисленные выше возможности и они же ограничения.

Технические особенности интеграции Microsoft Dynamics CRM с различными ИТ-системами

Если абстрагироваться от множества интеграционных технологий и их названий, можно выделить следующие способы интеграции Microsoft Dynamics CRM c другими ИТ-системами:

• Интеграция «визуальных» интерфейсов (интерфейсов пользователя);
• Интеграция при возникновении событий (еще ее можно назвать online-интеграция);
• Интеграция по расписанию.

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

1. Интеграция «визуальных» интерфейсов.

Применение этого способа возможно, если интегрируемые системы имеют веб-интерфейс и могут работать в браузере Internet Explorer. В этом случае либо часть интерфейса системы Microsoft Dynamics CRM встраивается в интерфейс какой-либо формы другой системы, либо наоборот. Как показывает практика, при этом следует учитывать следующие особенности:

• Аутентификация пользователей

Поскольку Microsoft Dynamics CRM поддерживает аутентификацию пользователей с использованием Active Directory желательно, чтобы ИТ-система, с которой выполняется интеграция, поддерживала такой же метод аутентификации. Как правило, большинство крупных ИТ-систем имеют свою собственную систему аутентификации, отличную от вышеуказанной. Это приводит к тому, что пользователю необходимо вводить логин и пароль в различных системах как минимум дважды.

• Разделение интерфейсов и их автоматическая идентификация

В то время как для Microsoft Dynamics CRM является обычным вызов отдельной карточки, например, контакта по URL-адресу с передачей идентификационных данных этого контакта (значения типа guid), для других систем выделить отдельную часть, соответствующую одному объекту со всей логикой - задача довольно непростая. Поэтому на практике приходится искать различные способы либо реализации такой интеграции, либо ее обхода путем изменения бизнес-процесса. Последнее требует времени на согласование вносимых изменений с заказчиком, что может привести к затягиванию сроков реализации интеграционного проекта.

2. Интеграция при возникновении событий

Такой способ интеграции бывает необходим в том случае, когда требуется при изменении экземпляра объекта в Microsoft Dynamics CRM сразу же передать информацию об этом факте в другую(ие) ИТ-систему(ы) или наоборот: из других ИТ-систем в Microsoft Dynamics CRM.

В первом случае благодаря механизму plug-in’ов практически не возникает проблем с реализацией данной задачи. Однако во втором случае определенные сложности все же могут возникнуть. Дело в том, что некоторые системы не поддерживают на уровне приложения внутренней логики обработки событий, оставляя ее на физическом уровне хранилища данных – какой-либо базы данных, например, MS SQL Server или Oracle. Одним из методов здесь является реализация механизма триггеров. Его реализация достаточно проста, но в силу сложности систем (один объект системы, как правило, хранится в нескольких таблицах базы данных, которые связаны между собой и другими объектами базы данных не одной связью) возникает риск получить блокировку системы или всей интеграционной связки. В результате это приводит либо к отказу от такого способа, либо к сложностям реализации, увеличивающим стоимость и сроки проекта.

3. Интеграция по расписанию

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

Особенности взаимоотношений с заказчиком в рамках интеграционного проекта

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

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

• Проблема разграничения зон ответственности сторон

Зачастую для решения поставленных задач по интеграции заказчиком привлекается третий участник – некая компания, сопровождающая интегрируемую систему (а, возможно, и не одну), но возможности влиять на которую достаточно малы. Как правило, обсуждение участия компании-аутсорсера в проекте начинается уже после его старта, по факту возникновения сложностей на проекте. Как свидетельствует опыт компании GMCS, снизить риски, в том числе в рамках интеграционных проектов, можно, если изначально четко оговорить степень участия и ответственность каждой из сторон.

• Проблема постановки задач и проработки механизмов реализации интеграционного проекта.

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

Требования к команде проекта

Задачи интеграции Microsoft Dynamics CRM являются достаточно сложными и трудоемкими. Это предъявляет особые требования к команде проекта, ее технической и организационной подготовке.

Прежде всего, в команде проекта должен быть архитектор, хорошо разбирающийся в технической архитектуре Microsoft Dynamics CRM, обладающий опытом настройки и разработки для нее, и, что самое важное, опытом ее интеграции с другими ИТ-системами. Также от архитектора требуется умение руководить группой разработчиков (если она есть), поскольку все взаимоотношения «разработчик-консультант» будут проходить через него. Помимо этого архитектор должен обладать развитыми навыками коммуникации, т.к. ему часто придется общаться с представителями заказчика, и навыками написания документации, поскольку вся документация перед отправкой на согласование заказчику должна проходить его оценку.

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

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

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

Эксперты рынка

• Могильников Евгений, к.ф.-м.н., доц., департамент решений Майкрософт Рус компании GMCS