ПРЕДИСЛОВИЕ.
Данная статья пылится на Инфостарте с 2017 года, и на данный момент скорее всего является устаревшей. Но еще может пригодиться тем, кто использует конфигурацию CRM PROF предыдущего поколения (на обычных формах) от фирмы Рарус. Пользователи данной программы из статьи могут узнать про то как можно расширить функционал, программисты - про некоторые особенности механизмов конфигурации.
ПОЕХАЛИ.
Итак, мой "живой клиент" это реальная организация, которая продает программное обеспечение и оказывает услуги по его настройке. Все как в мире 1С, с одним отличием, что предприятие занимается не 1С.
Структура предприятия такова:
- Отдел продаж.
- Отдел обслуживания (Корп. отдел).
- Отдел тех. поддержки.
- Бухгалтерия.
Немного о каждом отделе:
Отдел продаж - это классический кол. центр по "подогреву" холодных контактов. Основной задачей отдела является получить базу с контактными данными о клиенте и выполнить ее обзвон. Целью обзвона является встреча с потенциальным покупателем для презентации. После того как договоренность о встрече достигнута, информация передается начальнику отдела, а от него - консультанту, который проводит презентацию и доводит процесс до продажи. В отделе продаж потенциальные клиенты делятся на 2 категории: Холодные и горячие.
Отдел обслуживания получает уже действующего клиента, т.е. такого, который приобрел программу в первый раз или продлил подписку. Основной задачей отдела обслуживания является не забыть, во время выставить клиенту счет на новый период, проследить, что бы клиент его оплатил и получил все необходимые документы. Еще одной задачей отдела является допродажы и переводы на более старшие версии ПО. В отделе обслуживания действующие клиенты делятся на 3 категории: Новые, постоянные и отказники.
Отдел тех. поддержки - решает текущие проблемы, возникающие при эксплуатации ПО (установка, переустановка, настройка, обучение, для профилактики проводит анализ логов, которые автоматически приходят по почте).
На данный момент отдел продаж использует самописную конфигурацию, разработанную мной в 2004 году, на версии 7.7. Конфигурация уже сильно перегружена данными и постоянно вылетает. Кроме того при разработке были применены многочисленные внешние компоненты, которые плохо работают с современными операционными системами. Ну и, конечно же, Эксель - куда без него?
Менеджеры отдела продаж вносят в базу проекты, которые называются «Заявки» и регистрируют контакты с потенциальными покупателями. В основном это исходящие телефонные звонки. По результатам контактов происходит либо планирование следующего контакта, которое называется "Перенос", либо полный отказ, либо успешное завершение этапа, которое называется "Выдать заявку". Заявка выдается начальнику отдела для утверждения и для последующей передачи консультанту, который должен довести дело до продажи.
Тем временем отдел обслуживания и бухгалтерия работают в программе 1С:Бухгалтерия 8, которая была некоторым образом доработана для удобства обслуживания действующих клиентов. Менеджеры отдела обслуживания работают по следующей методике:
При входе в программу, менеджер открывает форму списка контрагентов. Из формы списка вызывает, специальный отчет, который показывает, у каких клиентов скоро заканчивается период подписки. Далее менеджер открывает форму элемента (карточку контрагента), переходит на закладку "Счета-фактуры". Копирует последний счет, распечатывает его или сохраняет в эксель... и так по всем остальным. После того как счета готовы к отправке, менеджер отправляет их разными каналами и вводит в программу документ "Событие", в котором фиксирует о чем он говорил с контактным лицом контрагента. Кроме того менеджеры отдела обслуживания планируют себе контакты (телефонные звонки), с теми контрагентами с которыми возможны допродажи или переводы.
Отдел тех. поддержки тоже работает в отдельной программе, написанной на Access-е. В этой программе, кроме специфических операций, регистрируются и аналогичные с другими базами операции. Например, регистрируются события/контакты с клиентом.
В итоге, из-за того что информация о контактах с клиентом находится в трех разных программах возникают как внутренние так и внешние конфликты. Менеджеры из разных отделов могут обрабатывать одного и того же клиента что в итоге приводит к различным скандалам как внутри предприятия, так и с клиентом. Но время не стоит на месте, и предприятие решило объединить все отделы в одно информационное пространство.
Сначала решили объединить отдел продаж и отдел обслуживания. Т.е. работу отдела продаж перевести в 1С: Бухгалтерию 8, предварительно ее доработав. Зная потребности отдела продаж в разных фильтрах и прочих плюшках, было решено использовать Рарус CRM ПРОФ.
На этом вступление заканчивается и начинается история.
1) Было решено "правильно" объединить в 1С: Бухгалтерию 8 и CRM. Под словом "правильно" подразумевается, что после процесса объединения двух конфигураций все чужеродные, по отношению к бухгалтерии, объекты и программный код, должны иметь префикс CRM. Основной целью такого требования, разумеется, было, поддержание простоты процесса обновления бухгалтерии. Процесс занял 130-140 часов и был успешно завершен.
2) Для работы отдела продаж было решено использовать блок бизнес-процессов и задач. Для регистрации заявок, переносов и т.д. был разработан новый бизнес-процесс "Заявка" на основании существующего «Поручение». Для удобства работы пользователей была разработана специфическая форма для объекта «Задача». Эта форма открывается только для тех задач, которые сформированы новым бизнес-процессом «Заявка».
3) После запуска нового бизнес-процесса пользователи начали работать в форме "Рабочего стола". В программе CRM существует автоматизированное рабочее место (АРМ), которое называется «Рабочий стол (CRM)». Это обработка, которая может открываться автоматически, при входе пользователя в программу. Рабочий стол состоит из двух форм. Левая – это «Панель управления», правая – сам рабочий стол. Панель управления отвечает за ввод новых объектов, рабочий стол – за работу с существующими объектами. Для более удобного представления данных рабочий стол разбит на участки/блоки при помощи закладок. На закладках отображаются списки различных объектов (контакты, контрагенты, задачи и т.д.), а так же элементы для установки произвольных фильтров. Оказалось, что пользователям очень не хватает наглядности при работе с данными фильтрами. А именно, пользователи попросили сделать так, что бы было видно, сколько бизнес-процессов попадает в тот или иной фильтр.
.
В итоге данная доработка была распространена на все закладки, где есть подобная форма настройки фильтров (задачи, контакты, контрагенты и т.д.). Реализовать и внедрить данную доработку оказалось совсем не сложно - все необходимые данные были либо в элементе формы, в котором расположен фильтр, либо их можно было получить уже существующей функцией.
4) Следующим запросом пользователей было, снова, расширение возможности фильтров в разделе бизнес-процессы. Нужно было реализовать возможность устанавливать фильтры не только по реквизитам бизнес процесса, но и по другим произвольным реквизитам, которых, кстати, не было вообще. Первое что пришло мне на ум, были свойства и категории, но провозившись несколько дней, оказалось, что решение задачи через использование свойств и категорий не подходит по следующей причине. Пользователь захотел, что бы дополнительные фильтры можно было бы накладывать в той же форме настройки фильтров.
Теперь немного технической информации.
В конфигурации CRM ПРОФ. за данную возможность отвечает обработка CRM_Фильтры. В эту обработку передается форма списка бизнес-процессов, т.е. элемент формы, содержащий список бизнес-процессов. Как потом оказалось, это была не форма списка бизнес-процесса, а форма списка записей регистра сведений CRM_ БизнесПроцессы - но об этом позже. Так же, в обработку CRM_Фильтры передаются установленные пользователем фильтры, которые определяются только из тех, которые возможны для данной формы. Поначалу я думал, что механизм фильтров работает через запрос, который формируется динамически, на основании выбранных, пользователем полей, но оказалось что все намного проще. Пользователь для настройки фильтров может использовать только те поля, которые присутствуют в форме списка и для которых существует возможность установить стандартный отбор.
В итоге для того что бы реализовать данную задачу на родном механизме, этот механизм пришлось бы отключить и разработать новый с нуля. Такое положение дел меня не устраивало, и я решил пойти другим путем. Если количество вариантов фильтров зависит от формы списка тогда нужно просто расширить эту форму соответствующими колонками/реквизитами. Я решил, что пользователю не нужно бесконечно много отборов и наверняка есть некоторое их число, которое удовлетворит всех пользователей. Достаточно это количество определить и внести изменения в форму списка (элемент формы, который отображает список бизнес-процессов), что бы стандартных механизм фильтров это подхватил и задействовал как свой родной. Так я и поступил.
В ходе расследования оказалось что: список бизнес-процессов, который видит пользователь на рабочем столе, это форма списка записей регистра сведений CRM_ БизнесПроцессы. При записи любой задачи программа автоматически пишет в этот регистр некоторые данные, которые берет, в том числе и из карточки самого бизнес процесса. Оговорив все возможные варианты фильтров, которые могли понадобиться пользователям, я выделил группы по некоторым признакам. Для того что бы реализовать дополнительные отборы нужно было в регистр сведений CRM_ БизнесПроцессы добавить новые ресурсы а в сам бизнес-процесс добавить соответствующие реквизиты - что и было сделано. Кроме того была изменена (расширена) родная процедура записи данных в регистр CRM_ БизнесПроцессы.
Особенность данного процесса в том, что для хранения данных новых реквизитов я не создавал новые справочники или другие хранилища. Все оказалось проще. Я проанализировал реквизиты документов из конфигурации CRM. (События, Телемаркетинг, Анкета, Маркетинговая кампания и пр.) и оказалось то, что если в бизнес-процесс добавить некоторые из этих реквизитов (понятно без фанатизма), то это охватит намного больше вариантов, из тех которые хотели пользователи. Например: если пользователь говорил что ему нужен будет фильтр по тем бизнес-процессам (заявкам), которые участвуют в некоторой акции, то я добавил в бизнес-процесс и регистр сведений реквизит содержащий ссылку на документ "Маркетинговая компания", и кроме того еще и на реквизит этого документа "Вид кампании" который ссылается на «родной» справочник "Виды кампаний". и т.д. Вот собственно результат:
После данных манипуляций появилась возможность устанавливать необходимые отборы, используя штатный механизм фильтров.
5) Но и этого оказалось недостаточно. Пришлось еще раз расширить варианты фильтрации данных. Представьте себе: менеджер отдела продаж ведет большое количество проектов (заявок). За месяц их число может достигать сотни, за год – тысячи. В постоянном обороте у менеджера, который проработал около года, всегда находится порядка 300 заявок, т.е. потенциальных интересов. Из этих 300 заявок, порядка 100 очень горячих, т.е. тех, которые уже готовы к следующему этапу отношений - встрече. Так вот, работая на закладке рабочего стола "Бизнес-процессы", менеджеру достаточно часто приходится производить поиск заявок, по контрагенту. Но если по самому контрагенту можно настроить фильтр, хотя это не очень удобно: нужно открывать форму настройки отбора/фильтра, там искать реквизит бизнес-процесса "Контрагент", вводить значение и т.д., то выполнить поиск или фильтрацию заявок по реквизитам контрагента вообще не возможно.
Штатный механизм конфигурации CRM предполагает, что для этих целей нужно перейти на закладку «Контрагенты» - ввести искомое значение в поисковую строку - получить некоторый результат в виде списка отфильтрованных контрагентов. Далее, нужно найти подходящего контрагента - открыть его карточку - перейти на закладку бизнес-процессы и получить собственно список процессов, в моем случае – заявок. А для того что бы перейти на последнюю, не выполненную задачу, нужно постараться еще больше. Но не будем о грустном… Было решено подключить стандартный механизм поиска, к списку бизнес-процессов.
Стандартный механизм поиска в списках представляет собой одно поле для ввода значений поиска и еще одно - для выбора варианта/настройки поиска. Такой механизм используется во множестве типовых конфигураций от 1С, это: УТ 10, УПП, КА и других. Как правило, данных механизм используется для поиска номенклатуры или контрагентов. Он хорошо масштабируется, поэтому его легко можно «прикрутить» к любому справочнику и выполнять поиск элементов данного справочника не только по реквизитам самого справочника, но и по любым другим реквизитам, любой таблицы, которая имеет ссылку на данный справочник. Центральным ядром данного механизма является обработка УниверсальныйПоискОбъектов. В данную обработку передается искомое значение и настройка, а обработка сама строит, если нужно динамический запрос к различным таблицам базы данных, находит нужные значения и отображает их пользователю в виде фильтра/отбора элементов некоторого справочника.
Так вот, у этого замечательного механизма оказался один существенный недостаток. Он очень хорошо работает, когда основной таблицей, в которой осуществляется поиск, является «Справочник», и совсем не работает, когда основной таблицей является любая другая, в моем случае таблица записей регистра сведений "CRM_ БизнесПроцессы". Пришлось вмешаться и сюда. Вся доработка пришлась на обработку "УниверсальныйПоискОбъектов". Кроме того на закладку рабочего стола бизнес-процессы, над формой списка, были добавлены поля для управления поиском. И механизм заработал. Сюрпризом оказалось то, что механизм поиска сам подхватил, установленные пользователем, фильтры.
Теперь менеджеры могут найти заявки не только по названию контрагента, но и по всем связанным полям, а это: реквизиты контрагента, телефоны, адреса, контактные лица, контактная информация контактных лиц и все это работает с оглядкой на те фильтры, которые менеджер уже сам установил. Как по мне механизм поиска получился очень мощным.
.
6) Но и это оказалось не последней каплей. Проблема появилась в планировании даты завершения бизнес-процесса и связана она с методикой, заложенной в CRM. Проблема в том, что для того чтобы узнать когда по плану завершится бизнес-процесс, нужно в карточке бизнес процесса, вручную, устанавливать планируемую дату завершения. Но существуют процессы, которые не позволяют узнать заранее планируемую дату завершения. Мой процесс «Заявка» оказался именно таким. Дело в том, что после очередного контакта с клиентом, процесс может быть перенесен на неопределенный срок – это регистрируется и планируется задачей с этапом «Перенос». В этом случае планируемой датой завершения процесса выступает планируемая дата выполнения задачи «Перенос». Проблема возникает там, где менеджеру необходимо отфильтровать бизнес-процессы «Заявки» именно по дате переноса. Для этого необходимо после выполнения переноса заходить в карточку бизнес-процесса и сдвигать дату до даты переноса, и так каждый раз. Либо же пользоваться стандартным механизмом и смотреть на закладку «Задачи». Но на один процесс может приходиться несколько задач, кроме того в задачах нет возможности поиска по контрагенту, потому что реквизит «Контрагент» там просто отсутствует. Да и вообще, со списком задач работать не так удобно, потому что их много, их нужно постоянно фильтровать и группировать, В общем, типовой механизм оказался не удобным и не эффективным. Было решено изменить данный механизм так, что бы при создании задачи, в регистр сведений CRM_ БизнесПроцессы записывалась дата переноса. В итоге, в стандартном фильтре бизнес-процессов появилась возможность фильтровать заявки и другие процессы по плановой дате последней задачи.
7) Ну и на закуску осталось добавить, что и это не полностью удовлетворило пользователей. Дело в том, что бы двигать бизнес-процесс дальше нужно выполнять задачи, а что бы их выполнять нужно открывать форму задачи и нажимать там на соответствующие кнопки. Как вы, наверное, поняли, мои менеджеры не захотели работать в двух списках: бизнес-процессах и задачах. Поэтому было решено поступить следующим образом. Когда пользователь открывает карточку бизнес-процесса, программа определяет последнюю, не выполненную задачу, и открывает форму этой задачи, а форма бизнес-процесса, в этом случае, не открывается вообще. Теперь пользователь работает только в одном списке, в котором у него есть возможности поиска и отбора, а также управления бизнес-процессом.
Как я писал в начале, для бизнес-процесса "Заявка" была разработана отдельная форма задачи. За основу была взята доработанная ранее, форма элемента справочника контрагенты. Это было сделано для унификации, что бы менеджеры из разных отделов при необходимости могли быстро с ориентироваться. Вот скриншоты первых двух закладок
:
На этом все. Надеюсь, мой практический опыт кому-нибудь окажется полезным.
