CRM+Front

Dec. 11th, 2009 11:39 pm
tsegelnyk: (Default)
Интересно. В одной компании, для того, чтобы в CRM работали, то в функционал CRM добавили функции Фронта. Таким образом продавец делает фиксирует информацию о клиенте - когда приходил, зачем приходил, сколько и зачем мы ему звонили, что ответил и так далее. В конце концов, это приводит к продаже продукта. И вот заведение его продуктов, его параметров происходит в самой CRM системе, с последующей передачей в учетные системы, если таковые имеются.

Подход, нельзя сказать, что инновационный, но малоиспользуемый точно.

Подход для той компании, которая не хочет особо заморачиваться на продвижении персонала, на обучение, на демонстрацию преимуществ CRM системы при продажах. Компании, которая желает административным способом заставить, именно заставить, работать в этой программе. Сначала как во Фронтальной, а потом, потихоньку, будут использовать особенности CRM системы.
tsegelnyk: (Default)
Был свидетелем забавного диалога.
Интегратор, далее И, Заказчик, далее З.

З: Как-то плохо у нас работает "поиск" в нашей новой, почти внедренной, программе..
И: Да, понимаете, это происходит потому, что поиск клиента происходит не по сущности, которая принадлежит сущности клиент. Поиск происходит по сущности сделка. потом необходимо сопоставить с клиентом и отобразить вам клиента.
З: и?
И: Ну как же. Вот поиск по "фамилии" нормально идет?
З: Ну, в целом, да, лучше.
И: Вооот, это потому что ищется в той же сущности.
З: Ну хорошо, но что делать? В БТ есть такое требование. Мы хотим идентифицировать клиента по номеру договора, по номеру его карты.
И: Ну-у-у, надо чтобы _ваш_ администратор базы посмотрел в чем проблема и сделал оптимизацию.
З: Ээээ, как это? Ведь мы покупаем решение, которое должно работать так как нужно, или хотя бы описано в БТ.
И: И что? Мы же _только_ интеграторы. Мы берем систему и _немножко_ оптимизируем под ваши требования. Мы же не меняем базу, а значит не можем нести за нее ответственность. Все вопросы к разработчику базы, т.е. к Oracle.
З: (непонимающе) Да как же это? Вы нам продали решение...
И: (раздраженно) Ну вот смотрите. Есть база данных, а есть программа (надстройка), которая строится на ней. И вот саму надстройку мы можем крутить, вертеть как угодно, а вот база - это не наше. Это все Oracle. Вот вы же официально являетесь пользователем Oracle, вот обращайтесь к ним, пишите запрос, мы вам поможем составить, и будем ждать ответа.
З: ...

В целом, проблему решили. Благо нашлись правильные слова, люди, которые решили объединить усилия для решения задачи Заказчика. Но сам диалог очень показателен. Показателен с точки зрения работы и общения с заказчиком ДО продажи, ДО начала внедрения и ПОСЛЕ - ближе к окончанию внедрения, к окончанию работ, подписанию актов выполненных работ.

Я считаю, искренне считаю, что Интегратор _должен_ решать проблемы и задачи Заказчика. Не просто внедрять программу, не просто внедрить и забыть, а выполнить _действительно_ то, что было обещано в периоде обработки клиента при продаже своего _решения_. Мне кажется, что задача Интегратора самостоятельно разобраться во всех нюансах, проблемах, которые могли появится во время внедрения. Честь и хвала заказчика, если он вмешается и поможет, но это не его обязанность, если это не указано напрямую в Договоре. Но рассчитывать нужно и правильно только на свои силы. А абстрагироваться от проблемы, уходить от ответа или прикрываться тем, что "это не наше" - признак слабости компании. Я за компании-интеграторы, которые ответственно подходят к внедрению РЕШЕНИЯ. Именно решения, потому что Заказчику как правило нужен _ожидаемый _результат_, а не печать в прессе: "Был успешно внедрен проект .... в таком-то банке ".
tsegelnyk: (Default)
1. в Бизнес-требованиях написано: "После создания договора, печатается договор".
Казалось бы, все верно и логично. А на деле - продуктов, которые предоставляет компания больше 20-ти и прямой подвязки определенного продукта к конкретному договору не происходит. Продавец _ДОЛЖЕН_ сам выбрать нужный договор и послать его на печать. И ведь не придерешься. Договор создается, документ печатается.

Я бы писал так: "После создания договора, система автоматически печатает необходимый договор, исходя из параметров, которые выбрал продавец в программе при введении договора в систему. Так же печатает все необходимые печатные формы после введния договора в систему (тут нужен перечень этих печатных форм)".

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

Обычно, все эти задачи, описываются в начальных документа типа "Видение проекта" или "Бизнес-требования верхнего уровня". И все в них гладко, звучат пафосные слова, умные слова -- кра-со-та.

Что происходит дальше?

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

О том как избежать, как максимально избежать, поговорим в следующих материалах.
tsegelnyk: (Default)
Должны участвовать в проекте на 100%.

Как только сотрудник будет работать 50% на 50% со своей основной деятельностью, то процент занятий по основному роду занятия будет увеличиваться, а по проекту уменьшаться. Так происходит а) в силу привычки б) в силу того, что вертикальный руководитель "более" весом нежели горизонтальный в) нах надо вообще мне этот проект, у меня своих дел полно

Чем больше сотрудников у которых работа поделена на основную и проектную, тем выше риски проекта.
tsegelnyk: (Default)
Сегодня затрону тему той информации, которая должна быть в CRM системе или Фронте.

Совершенно ясно, что всего предусмотреть на этапе сбора требований невозможно, особенно когда руководители говорят о каком-то "космосе" или большой зеленой кнопке, которая решит все их проблемы. Безусловно, величайшая миссия, возложенная на аналитиков как раз и состоит в том, чтобы предугадать какие поля, какая информация понадобится для анализа деятельности финансовых гидов, или для старта маркетинговой кампании, или для анализа продаж. Как правило, руководители редко бывают довольны той информацией, которая в итоге будет поступать к ним. Я постараюсь описать несколько несложных приемов, чтобы свести эти проблемы к минимуму.

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

2. Разговаривайте с заказчиком не о "космосе", а о том, какую практическую пользу должна принести внедряемая система

3. Общайтесь с сотрудниками, которые _будут_ пользоваться программой. Помните, что внедряете вы для заказчика, а пользоваться программой будут другие. Об этом я поговорю чуть подробнее позже.

4. Отталкивайтесь от мировых best-practices. Безусловно их нужно адаптировать для Украины.

5. Обязательно используйте свой опыт.

Profile

tsegelnyk: (Default)
tsegelnyk

August 2011

S M T W T F S
 1 23 456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 24th, 2017 09:03 pm
Powered by Dreamwidth Studios