В CRM или нет в CRM (MS)?

Question

Мы используем MS Dynamics 4.0 на работе для нашей CRM. Он обрабатывает все управление контактами, маркетинг, совместное использование ресурсов с интеграцией sharepoint, управление рабочими процессами / совместную работу и, по сути, так или иначе используется каждым отделом фирмы.

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

Нам нужно относительно простое приложение, в котором нам нужно отследить некоторые данные для обмена для определенной группы. Некоторая часть этой информации уже находится в нашей компании CRM, работающей в «компании» и «клиенте».

Этот новый проект потребует от нас добавить около 26 полей - мы не хотим раздувать нашу и без того крупную компанию - особенно потому, что только около 5% наших компаний будут использовать эти дополнительные поля.

В настоящее время мы в основном обсуждаем проектирование - гибридное решение (создайте наше собственное приложение ASP.NET, которое выглядит как CRM и связывается с ним через веб-службы, и сохраняйте все «дополнительные» поля в нашей собственной базе данных, возможно, живя в тот же сервер БД, что и наша БД CRM, поэтому мы можем легко писать запросы). Другая альтернатива - сделать это на 100% в CRM.

Я просто ищу совет для людей, которые сделали нечто подобное. Вы бы порекомендовали сделать гибридное решение, такое как это, или мы должны сделать 100% CRM? Наш крайний срок ограничен, и разработчики, работающие над проектом, имеют ограниченные знания CRM; Вот почему это немного дискуссии. Для тех, кто работает с MS Dynamics - как бы вы обычно обрабатывали такой проект, когда нам нужно добавить много полей (и даже подполей с собственными отношениями родитель-> потомок), которые будут применяться только к очень небольшому проценту наших главная сущность 'компании' .. кое-что следует отметить: у нас уже есть проблемы с производительностью, когда люди загружают эту сущность компании как есть (для отображения страницы может потребоваться 5 секунд), то же самое относится и к расширенным поискам.

Последнее, что следует отметить - эта часть приложения только для хранения данных. В конце пользователь откроет рабочую книгу VBA Excel, нажав кнопку «раскрыть данные», которая будет извлекать эти данные из любого места, где мы их храним. Мы просто не уверены, где нам следует хранить / управлять этими данными / пользовательским интерфейсом.

Большое спасибо за любые советы.

РЕДАКТИРОВАТЬ: Как я могу создать 2 списка рядом друг с другом с 2 кнопками в середине, где один список потерял «мои foos», а другой «все foos», и вы добавляете / убрать из списка «мои foos» ??? классический «у меня есть эти foos как часть меня» UI control с 2 списками и 2 кнопками со стрелками ... Должен ли я / я использовать jquery для этого? и кто-нибудь знает какой-нибудь элемент управления jquery, который уже делает все это из коробки? Это такой общий контроль, я уверен, что он должен быть где-то там. Я просмотрел некоторые наборы инструментов и элементы управления и некоторые темы здесь и увидел некоторые действительно удивительные, даже более сложные элементы управления, но не этот конкретный ..

РЕДАКТИРОВАТЬ 2: После дополнительных исследований кажется, что сохранить весь пользовательский интерфейс в CRM будет сложнее, чем просто сделать приложение ASP.NET для этой части и поместить его в iframe или модальное всплывающее окно в CRM.

Мы все еще можем настроить все поля данных и отношения в CRM - и заставить ASP.NET выполнять CRUD с помощью вызовов Webservice.

Похоже, нам пришлось бы выполнить тот же объем работы, чтобы получить функциональность, необходимую в CRM, за исключением того, что это было бы более хакерским и выполненным в javascript. В чем выгода? Хранение пользовательского интерфейса в одном месте ??? Не так уж много компромисса с ИМО ...

пока мы склоняемся к тому, чтобы хранить все данные в CRM, но помещаем пользовательский интерфейс в ASP.NET

Любой совет очень оценен. Что я говорю вменяемый? Спасибо

Answer 1

Я согласен, вам лучше использовать 100% CRM.

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

CRM не предоставляет отношения типа «один к одному», поэтому вам придется управлять этим самостоятельно. Сделайте вашу компанию сущностью N отношения, чтобы связанный объект появился в виде поиска.

В качестве альтернативы, если поиск связанной сущности слишком абстрактен для ваших пользователей, добавьте вкладку с iFrame в форму сущности компании. Используйте JavaScript, чтобы показать / скрыть вкладку, а также установить src для iFrame в качестве URL-адреса связанной сущности.

Answer 2

Создание приложений ASP.NET для создания сложного пользовательского интерфейса в iframe - это простое решение, которое я часто использую для MS Dynamics CRM 4.0 приложений.

Хранение всех данных в CRM имеет большой смысл, но создавайте пользовательский интерфейс так, как вы этого хотите.

iframe вызывает ваше приложение ASP.NET с помощью строки запроса, содержащей GUID сущности, чтобы вы могли использовать веб-службы для извлечения любой связанной информации.

Вы можете изменить поля, отображаемые в форме, с помощью JavaScript, напрямую обновить базу данных или и то, и другое для согласованности. Зачастую проще просто скрыть обновляемые поля в приложении ASP.NET, чтобы не было путаницы.

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

Научиться использовать MS CRM в качестве большого инструментария разработки - это первый шаг к возможности серьезной автоматизации бизнес-процессов.

Если у вас есть какие-либо вопросы, дайте мне знать.

Answer 3

Я бы использовал CRM для хранения данных. Вы можете вставить новые поля в отдельную панель в пользовательском интерфейсе, чтобы они не загромождали. Вы даже можете добавить Javascript в пользовательский интерфейс, чтобы скрыть панель / поля от пользователей, которые не являются частью группы, которая требует их. Я знаю, это звучит немного странно, но это гораздо меньше работы, чем придумывать совершенно другое приложение, и пользователи получат постоянный опыт. Наличие данных в одном месте также является благом для отчетности и тому подобное.

Не могу сказать наверняка, но я не думаю, что добавление нескольких столбцов к объекту (у которого уже есть столбцы базилиона) значительно ухудшит производительность. Я бы прошел установку и проверил обычные ошибки в производительности.

Answer 4

Я знаю, что это не подходит для вашей ситуации, так как вы глубоко знакомы с MS CRM, но есть хорошая статья Нила Форда, недавно опубликованная в IBM Developer Works (http://www.ibm.com/developerworks/java/library/j-eaed10/), в которой обсуждаются COTS и home выращенное программное обеспечение. Вот фрагмент кода.

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