На главную.

CRM системы в банках.

Оглавление

1. Что такое CRM система.

2. CRM системы в банках, опыт разработки.

3. CRM система в банке и попытка её использовать не только как CRM но и как ERP.

4. Расширенные возможности CRM системы.

5. Текущая ситуация с SalesLogix.

6. Переход с толстого клиента на тонкий в банке.

7. Дальнейшее развитие системы, перспективы и размышления.

1. Что такое CRM система.

CRM (Customer Relationship Management System.) - корпоративная информационная система, предназначенная для автоматизации CRM-стратегии компании, в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах (контрагентах) и истории взаимоотношений с ними, установления и улучшения бизнес-процедур и последующего анализа результатов (википедия). CRM система работает вокруг 3-x групп сущноcтей, которые в неё входят:
  1. Организации (accounts)
  2. Контакты (contacts)
  3. Активности (Activities)
У Оргнаизациий есть Контакты, через которые фирма, у которой установленна CRM, взаимодействует с ними. Виды взаимодествия и информация о них содержаться в Активностях. История взаимодействий сохранятется и её всегда можно проследить. Помимо основных сущностей есть дополнительные – такие как календарь, сделки, пользователи, отчеты и др. Идея системы – обеспечить более гибкое и опертаивное взаимодейсвие с клиентами, а так же анализируя историю взаимодействий планировать стартегию развития предприятия.
наверх.

2. CRM системы в банках, опыт разработки.

Я 3 года работал с CRM SalesLogix и чтобы не пропал сей труд решил его как-то обощить и просто написать о том, что я делал и предположить кому и для чего это нужно. Как программист изначально я видел только странную программу с кучей закладок и формочек. Так же постоянно писались письма от заказчиков по пожеланиям того что они хотели бы видеть в данной программе. Первое с чем я столкнулся это был Dashboard – его не было в стандартной поставке от Sage, точнее тот который был, не удовлетворял клиента. Поэтому был написанн свой, написан до меня и я его только дописывал и улучшал. Dashboard, в нашем случае, выглядел как одно большое окошко, в котором было 4 маленьких. В первом была таблица организаций, во втором контакты, в 3-ем Activity – описание текущий взаимодейсвтий с данной организацей и в последнем информация о месторасположении. Соотвественно в каждом окошке был поиск и при нахождении той или иной записи остальные три отображали соответвующую данной записи информацию. Следующим заданием была закладка Membership. Необходимо было в заклкде для Организаций отобразить поддерживаемые торговые площадки и информацию по ним. После этой формы стало более менее понятно чем помогает этот программный продукт работникам фирмы. Можно сказать что это был очень удобный путеводитель по струткутре взаимодействия с клиентами и в нем всегда можно было узнать кто есть кто и зачем он нужен. Работа программы крутится вокруг следующих основных сущностей – Организации, с которыми взаимодействует предприятие, контакты – по которым можно связаться с организацией (они в свою очереь входят в организацию) и активности – это то как взаимодействует ваша фирма с ними. Все активности пишутся в историю активностей, по которой можно уже проводить анализ развития отношений. Все красиво и удобно, но кто это будет заполнять и как? Тут долго оставались вопросы, т.к. сами клиенты не вводили данные, а продублировать все разговоры по телефону и переговоры – это значит тратить свое время на документирование, что не всегда удобно и не всегда отражает все тонкости взаимодействия. Но даже при таком недостатке удобство работы было существенным – всегда можно было найти любую организацию, посмотреть историю взаимодейсвия с ней, найти все контакты. Разбираясь дальше, выяснилось что через SalesLogix можно отправлять электронные письма клиентам и получать их от клиентов, рассылать автоматичексие напоминаня назначать общие собрания с извещением по почте участников о том когда и где им надо быть. Помимо почты сам клиент SalesLogix может отправлять с определенным интервалом напоминание о собрании или каком другом мероприятии. Так же есть история мероприятий. Далее выяснилось что есть неплохая система генерации отчетов которую можно встроить в SalesLogix и эти отчеты можно рассылать клиентам или же заинтересованным в этом лицам. Отсюда получается что у нас есть программа которая является хорошым информатором всех и вся.
наверх.

3. CRM система в банке и попытка её использовать не только как CRM но и как ERP.

Освоив данную CRM я столкнулся с её применением в банке. Там всё оказалось гораздо интереснее. Помимо ручного ввода информации о клиентах в неё, так же оказалось что она сама может записывать номера всех звонков сделанные на и с телефонов которые принадлежат фирме. И даже если к примеру менеджер поленился или забыл внести информацию о переговорах с клиентом система всегда может сохранить факт звонка и занести его в историю переговоров для соответвующего контакта или же оперативно проинформировать о появлении телефонов не привязанных ни к какому контакту. Ещё поддреживалась возможность автоответчика и телефонных конференций. Так же в данной CRM был список всех сотрудников банка и при приходе на работу каждый сотрудник отмечал во сколько он пришел и ушел. При определенных денежных затратах эта информация может заноситься автоматически, но этого просто не было в той фирме где я работал. Таким образом контролировалась трудовая дисциплина. Помимо контроля так же рассылалсиь поздравления с днем рождения и различные сообщения сотрудникам. Для банков CRM система оказалась более наглядной. Я разрабатывал модуль – “Карточки”. Этот модуль представлял из себя набор форм, которые заполнял опператор во время открытия клиентом банковского счета или получения кредита. Это показалось мне очень удобным. Т.к. карточка может заполняться в режиме диалога с клиентом и на каждый банковский счет клиента есть своя карточка в которой можно увидеть состояние счета. Транши погашения по кредитам так же автоматически попадали в CRM систему и в при необходимости программа оповешала по почте клиента или сотрудников банка. Так же всегда можно было посмотреть в CRM историю оппераци по счету к которому привязывалась карточка. Были и более сложные карточки, которые работали со списком счетов. Так же в каком-то виде присутсвовалли формы для составления бухгалтерсокй отчетности и её интеграции с 1С. На сколько глубока была интеграция с данной программой я не могу судить, т.к. не работал на этом направлении но вид документов был как в 1С. Возможно просто шаблон общий был.
наверх.

4. Расширенные возможности CRM системы.

Анализируя использование данной сиситемы задумался над тем как же её используют на самом деле. Из приложения которое просто сохраняет историю работы с клиентом оно выросло до приложения которое несет на себе кучу различных функций, как контрольных так и организационных. Получается что-то наподобие “палочки выручалочки” которая делает всё что от неё требуют. Т.е. из CRM она превращается в Автоматизированную Систему Управления Преприятия для банков и бирж. Более того благодаря широким возможностям настройки и добавления нового функционала SalesLogix можно изменить до неузнаваемости и заставить выполнять функциональность очень далекую от взаимодейсвия с клиентами. Практически любую функциональность, которая приходит в голову можно сделать в рамках данной CRM. Сама система в итоге просто превращается в набор инструментов или во что-то наподобие оболочки внутри которой можно разместить всё что захочется в рамках информационных технологий. С одной стороны это подкупает, т.к. программа позволяющая осуществить любые фантазии всегда найдёт своего клиента. С другой появляются опасения что её могут начать нецелесообразно использовать (“микроскопом гвозди забивать”). Фактически из CRM SalesLogix превращается в ERP-систему (Enterprise Resource Planning System — Система планирования ресурсов предприятия) — это интегрированная система на базе информационных технологий для управления внутренними и внешними ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие ресурсы). Цель системы — содействие потокам информации между всеми хозяйственными подразделениями (бизнес-функциями) внутри предприятия и информационная поддержка связей с другими предприятиями( взято с википедии). Возникает предположение что фирма Sage сделала ERP-систему и продает её под видом CRM. Или же, как вариант, - заложенная в систему гибкость и расширяемость породила соблазн использовать её не поназначению и позволила ей быть немного больше чем просто CRM, что и обеспечило ей широкую популярность. Позиционирование ERP-системы, как CRM позволило легче продвигаться на рынке, предоставляя в первую очередь покупателю функции взаимодействия с клиентами и далее, в процессе использования, расширяясь на всю деятельность организации. Т.к. я не видел остальных продуктов от Sage и не работал с ними как программист я не могу это утверждать на 100 %, но вероятность того что все они по сути одна и та же ERP система только, ради успешности её продвижения на рынке, представленная в виде множества специфичексих систем. Которые содержат в себе формы и сущности необходимые для быстрого внедрения в сферу управления тем или иным процессом. Подобная гибкость помимо прямого применения данной CRM системы, даёт широкие возможности для проведения различных аналитических операций направленных на улучшение работы с клиентами и на более интенсивное их привлечение. Можно добавить модули которые будут выявлять предпочтения текущих клиентов и на их соснове делать какие-то выводы и планировать дальнейшую стратегию развития компании.
наверх.

5. Текущая ситуация с SalesLogix.

Изначально клиент для SalesLogix представлял собой программу устанавливаемую на рабочую станцию, которая обменивалась информацией с сервером (толстый клиент). Но последние версии клиентов запускаются непосредсвенно в интернет браузерах (internet explorer, firefox) (тонкий клиент) и по заявлению фирмы Sage они намеренны в дальнейшем отказаться от своего первого варианта клиента в пользу второго. Отсюда была поставленна задача перехода с одного клиента на другой. В процессе перехода с толстого клиента SalelsLogix на тонкий возникло множество проблем, отчасти связанных с концепцей самого тонкого клиента и отчасти с неудобством и ошибками в предлагаемом продукте от Sage. В теории тонкий клиент должен быть минимизирован и оптимизирован с точки зрения интерфейса с пользователем. И в идеале чем больше страниц с меньшим числом контролов на них тем лучше, но в реальности заказчик не всегда идет на уступки в вопросе графического интерфейса и требует чтобы всё работало в интернет браузере, а выглядело как и раньше в толстом клиенте. К тому же CRM система используется, как информационный ресурс и призвана как можно оперативней и подробней предоставлять информацию пользователю и в наиболее полном объеме. Что входит в противоречие с принципом – чем больше страниц с меньшим числом контролов тем лучше. Отсюда, возможно, для сохранения гибкости следовало бы оставить толстый клиент и тонкий и поддерживать оба, но к сожалению технологии на которых был разработан толстый клиент SalesLogix устарели и переписать толстый на новые технологии, так чтобы он был совместим с тонким и разработка функционала на нем велась бы как минумум на том же языке прораммирования что и тонкий требует больших трудозатрат. Плюс поддержка двух клиентов требует больше финансовых затрат чем одного. Мы в поцессе перехода с киента на клиент в итоге всё сделали на Slverlight и встроили его в SalesLogix. Фактически полчучился вариант когда толстый клиент запускался в интернет браузере. Под удар попала безопасность такого решения. Чтобы воспользоваться старым толстым клиентом необходимо было его предварительно установить на рабочую станцию, а в случае с Silverlight достаточно завладеть пользовательскми паролем для входа в систему. В нашем случае система использовалась внутри локальной сети предприятия и доступ к ней из вне был не возможен, что позволило пойти на такое снижение уровня безопасности. Хотя ничего не мешает восполнить этот пробел в безопасности другими способами защиты, т.к. повышая доступность и удобство использования системы чаще всего приходится менять и способы защиты от взлома подобных систем. Переход на Silverlight не был безболезненным и потребовал много усилий для разрешения противоречий между SalesLogix и Silverlight, проблем добавил не очнеь удобный интерфейс для разработки приложения и множество мелких ошибок в актульной на тот момнет версии продукта. Возможно, это было связанно с несовсем удачной концепцией выбранной фирмой Sage или же с техническим прогрессом в сфере информационных технологий. Есть мысли, что команда Sage предполагала, что развитие средств разработки пойдёт немного по другому сценарию, чем оно пошло на самом деле. Далее я описал в краце как развивалсиь события в процесе перехода с толстого клиента на тонкий.
наверх.

6. Переход с толстого клиента на тонкий в банке.

Программное обеспечение призванное облегчить разработку оказалось гораздо менее удобным чем MS Visual Studio. Для создания приложений под Web используется Application Architect. С помощью него можно генерить сущности таблиц для работы с ними в программе, но сами таблицы приходится создавать по-прежнему в программе Architect. Так же в Application Architect есть средства разработки форм, но они всегда серверные и любой контрол на них это AJAX контрол. Остюда сложная форма с множеством контролов очень медленно работает. И требует большого числа усилий при разработке. Препядствием стали так же функциональные блоки которые можно было создавать в данном приложении (обработчики событий например). Их можно быстро и легко создать, но очень сложно удалять. Чтобы их полностью удалить, приходилось бегать поиском по файловой системе и искать файлы с их декларациями. Так же в разрабатываемом нами приложении была функциональность требующая создания нескольких диалоговых окон – когда из одного диалогового окна создавалось другое. Пришлось воспользоваться хаком, выложенном на форуме по настройке данного функционала. Так же в Application Architect плохо работали связки один ко многим. Стабильно работала только один к одному, что тоже доставляло множество хлопот. Так же Lazy Initialization ставила в тупик. При привязке к определенным полям таблицы других таблиц не всегда очевидно было что имя_таблицы.имя_поля_с_форен_кей_другой_таблицы.имя_поля будет работать. В итоге спустя некоторое время было решено частично отказаться от Application Architect и использовать его только для генерации NHibernate сущностей. А далее вся разработка форм велась в Visual Studio. Но это не изменило координально ситуации. Т.к. странички всё равно работали медленно и время от времени выбрасывалсиь странные ошибки. Проблема была в exjs которую использовали в Sage. Ошибки были из её недр при использовании аякса. Так же пришлось очень много писать на яваскрипте чтобы увеличить скорость работы приложения. Вобщем в виду недостаточного колличества разработчиков и отсутвия достаточного опыта у некоторых из них, было решено писать свой сайт на Silverlight и встраивать его в SalesLogix. При этом использовались те же NHibernate сущности и так же сайт крутился внутри SalelsLogix, отсюда получал доступ к системе безопасности от Sage и всем его библиотекам. Данный подход помог очень сильно ускорить работу приложения и так же снизить трудозатраты на её разработку. Но соеденить данное приложение с SalesLogix безболезненно не удалось. Проблема была в сущностях, которые генерил из таблиц NHibernate. Они были не сериализуемыми, а доступ к ним был через интерфейсы. Отсюда приходилось вместо использования RiaServices пользоваться WCF сервисами. На стороне сервера создавались сериализуемые классы, которые фактичекси повотряли весь набор полей сущностей от NHibernate и уже они передавалисть клинету. После операции сохранения сущности копировались в NHibernate сущнсоти и писались в базу. При первом обращении к серверу требуемые сущности генерились из NHibernate сущностей. Был ещё момнет с сущностями - Веб сервисы передают информацию о классах с сервера каждый в своей области видимости и возникала ситуация когда на клиент приходит объект одного и того же класса но в разных сервисах и программа на клиенте видела их как 2 объекта от разных классов. Данная проблема решалась с помощью интерфейсов на клиенте, либо с помощью промежуточного приложения через которое дергались все веб сервисы. Так же для обращения к базовому классу через потомков использовался рефлекшн. Это только те трудности с которыми я столкнулся, так же у приложения было множество других проблем. Но их решали другие разработчики. В итоге в приемлемые сроки разработка была законченна и отдана на тестирование клиенту. В ходе данной работы вознкли пожелания-предложения фирме Sage. 1. Сделать разработку CRM приложения через Visual Studio. 2. Использовать Silverlight для разработки тослтого клиента, рабоатющего в браузере. Тонкий клиент на технологии ASP.NET лучше оставить, для взаимодейсвия с внешними пользователями, а так же для работы с системой с помощью мобильных устройств с низкой производительностью.
наверх.

7. Дальнейшее развитие системы, перспективы и размышления.

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