Comments 15
Отсутствие поддержки со стороны руководства. Очень странная ошибка, но она имеет место быть.
ИМХО, крайне популярная (вкупе с «саобтажем») ошибка, которая допускается при внедрении CRM системы.
Если в CRM не работают руководители, если не заставляют делать это своих подчиненных — все будет без толку. Без дисциплины пользователей через 2-4-6 месяцев проект так и умрет, не родившись толком.
UFO just landed and posted this here
Добрый день. Поддержка также может осуществляться с двух сторон:
1. Администратора (эксперта) внутри компании, который следит за обновлениями, правами доступа, действиями и т.д. Обычно для этого в CRM логируются действия, а вендор предоставляет информацию об обновлениях. О RegionSoft CRM могу сказать, что она проста в администрировании и при стандартном внедрении, без доработок и персональных проектов, никаких сложных проблем не вызывает — всё решается письмом, по телефону или даже в чате. Естественно, бесплатно.
2. Вендора — он постоянно развивает CRM, добавляет функциональность. У нас обновления между версиями (например с 5.0 на 6.0) делаются за плату (гораздо ниже стоимости лицензий), но перевод не принудительный — клиент сам решает, какая версия ему нужна.
И, конечно же, вендор оказывает техническую поддержу. Здесь политика разная: кто-то принуждает купить пакет поддержки с лицензиями, кто-то предоставляет ограниченный круг услуг. У нас есть стандартная бесплатная техническая поддержка по телефону и платные пакеты, в зависимости от потребности. Техподдержка с сеансом подключения через удалённый рабочий стол — 1 600 р./час, стандартная при внедрении сроком более месяца — 7 000 в месяц и т.д. При этом оказывается она в приоритетном порядке и на высоком уровне.
1. Администратора (эксперта) внутри компании, который следит за обновлениями, правами доступа, действиями и т.д. Обычно для этого в CRM логируются действия, а вендор предоставляет информацию об обновлениях. О RegionSoft CRM могу сказать, что она проста в администрировании и при стандартном внедрении, без доработок и персональных проектов, никаких сложных проблем не вызывает — всё решается письмом, по телефону или даже в чате. Естественно, бесплатно.
2. Вендора — он постоянно развивает CRM, добавляет функциональность. У нас обновления между версиями (например с 5.0 на 6.0) делаются за плату (гораздо ниже стоимости лицензий), но перевод не принудительный — клиент сам решает, какая версия ему нужна.
И, конечно же, вендор оказывает техническую поддержу. Здесь политика разная: кто-то принуждает купить пакет поддержки с лицензиями, кто-то предоставляет ограниченный круг услуг. У нас есть стандартная бесплатная техническая поддержка по телефону и платные пакеты, в зависимости от потребности. Техподдержка с сеансом подключения через удалённый рабочий стол — 1 600 р./час, стандартная при внедрении сроком более месяца — 7 000 в месяц и т.д. При этом оказывается она в приоритетном порядке и на высоком уровне.
Соберите требования к CRM со всех отделов, обсудите их, выявите точки пересечения.Подскажите, как это сделать на практике?
Вопросы вида «а не нужен ли вам CRM?», «зачем вам нужен CRM?» задавать, очевидно, бессмысленно, т.к. их просто не поймут.
Требования к CRM, как и к любому программному продукту, будь то сайт или КИС, выявляются одинаково.
1. Во-первых, для составления ТЗ, договора, или сметы, либо просто записки на список изменений, вы должны составить список того, ЧТО умеет система. Не КАК, а ЧТО. Для этого надо провести определенную аналитическую работу, чтобы заинтересованные лица смогли объяснить, ЗАЧЕМ.
2.Соответственно, вы можете выявить это ЗАЧЕМ исходя из обычного разговора с заинтересованными лицами. например, пройтись по четырем группам вопросов: качественные (быстро надежно), функциональные (чтобы счет печатался), UX (чтобы я нажимаю кнопку затем спрашивает год и говорит что делать), возможностей (нам надо импортировать прайсы или допустим вот есть у нас мобильное приложение, интегрировать хотим).
3. Ответы конвертируете в задачи в разрезе «ЗАЧЕМ». Точки пересечения тоже могут всплыть, если заинтересованных лиц много, в том числе из из Вашей компании, и есть несколько отделов. Тут просто важно понять кто заинтересован, кто с системой пересекаться будет, а кто решения принимать и платить за работу. Все «Зачем» валидируются исходя из этого.
4. Как задавать вопросы, в принципе, понятно: поменьше закрытых вопросов (да/нет), побольше открытых. «Как вы работаете», «Кто ваши клиенты», «Как проходит день», «На чем теряете время», «Почему отвалился последний клиент».
Если отдел говорит «покажите что есть», «нужна CRM», «не нужна CRM» — уводите разговор в тему «если бы вам надо было организовать идеальную работу, как бы вы сделали это на экселе и стикерах?» и «Вы молодцы, что у вас все отлично работает в отделе, это большая редкость, значит процесс менять не надо, просто переложить на машину чтобы вам вообще ничего на работе не делать, пусть машина работает.» — потому что сейчас рано обсуждать «КАК», и не с отделами надо обсуждать «ЧТО».
<sarcasm>
5. Осознайте, что «коробка» по-честному не сможет закрыть вопросы, которые всплывают, и людям нужна разработка, а не подстроиться под готовый продукт и «новая функциональность каждый месяц».
</sarcasm>
1. Во-первых, для составления ТЗ, договора, или сметы, либо просто записки на список изменений, вы должны составить список того, ЧТО умеет система. Не КАК, а ЧТО. Для этого надо провести определенную аналитическую работу, чтобы заинтересованные лица смогли объяснить, ЗАЧЕМ.
2.Соответственно, вы можете выявить это ЗАЧЕМ исходя из обычного разговора с заинтересованными лицами. например, пройтись по четырем группам вопросов: качественные (быстро надежно), функциональные (чтобы счет печатался), UX (чтобы я нажимаю кнопку затем спрашивает год и говорит что делать), возможностей (нам надо импортировать прайсы или допустим вот есть у нас мобильное приложение, интегрировать хотим).
3. Ответы конвертируете в задачи в разрезе «ЗАЧЕМ». Точки пересечения тоже могут всплыть, если заинтересованных лиц много, в том числе из из Вашей компании, и есть несколько отделов. Тут просто важно понять кто заинтересован, кто с системой пересекаться будет, а кто решения принимать и платить за работу. Все «Зачем» валидируются исходя из этого.
4. Как задавать вопросы, в принципе, понятно: поменьше закрытых вопросов (да/нет), побольше открытых. «Как вы работаете», «Кто ваши клиенты», «Как проходит день», «На чем теряете время», «Почему отвалился последний клиент».
Если отдел говорит «покажите что есть», «нужна CRM», «не нужна CRM» — уводите разговор в тему «если бы вам надо было организовать идеальную работу, как бы вы сделали это на экселе и стикерах?» и «Вы молодцы, что у вас все отлично работает в отделе, это большая редкость, значит процесс менять не надо, просто переложить на машину чтобы вам вообще ничего на работе не делать, пусть машина работает.» — потому что сейчас рано обсуждать «КАК», и не с отделами надо обсуждать «ЧТО».
<sarcasm>
5. Осознайте, что «коробка» по-честному не сможет закрыть вопросы, которые всплывают, и людям нужна разработка, а не подстроиться под готовый продукт и «новая функциональность каждый месяц».
</sarcasm>
Отличный комментарий, по сути грамотные советы.
Единственное, не понимаю, почему сарказм. Есть два основных типа клиентов: 1) кому базовая поставка подходит или даже «велика», они за пару часов разворачивают систему и приступают к обучению, внесению данных, настройке — в общем работают; 2) кто хочет доработать CRM точно под свой бизнес (создать отчёты, настроить интеграции и проч.) — они проходят стадию составления ТЗ и платной доработки.
Подстраиваться под готовый продукт точно не стоит, особенно, если это затрагивает важные бизнес-процессы. А насчёт «новой функциональности каждый месяц» — что же здесь плохого, небольшие доработки и фичи, бесплатное обновление. Они точно ещё никому во вред не шли — обычный рутинный труд вендора.
Единственное, не понимаю, почему сарказм. Есть два основных типа клиентов: 1) кому базовая поставка подходит или даже «велика», они за пару часов разворачивают систему и приступают к обучению, внесению данных, настройке — в общем работают; 2) кто хочет доработать CRM точно под свой бизнес (создать отчёты, настроить интеграции и проч.) — они проходят стадию составления ТЗ и платной доработки.
Подстраиваться под готовый продукт точно не стоит, особенно, если это затрагивает важные бизнес-процессы. А насчёт «новой функциональности каждый месяц» — что же здесь плохого, небольшие доработки и фичи, бесплатное обновление. Они точно ещё никому во вред не шли — обычный рутинный труд вендора.
Ну, если быть точнее, то не 2, а 4. 4-я не используется, поэтому три.
1. Компания не подстраивается под ПО, ПО (глобально) не подстраивается под компанию. Например, gmail, AmoCRM.
2. Компания подстраивается под ПО, ПО не меняется. Например, крупная компания которая внезапно выросла, а как рулить не знает. Например, 1С-бухгалтерия.
3. Компания не подстраивается под ПО, ПО меняется/пишется под компанию. Например, уже есть работающие бизнес-процессы, которые надо переложить на систему. Любая платная разработка.
В зоне №2 есть два типа клиентов.
Первый — бюджетные, который выбирают CRM или другое ПО под возможности. Они смотрят, «есть ли модуль счета», а если говорить про сайты, то «есть ли модуль расчета доставки». На основе этого делают выбор. Решается вопрос автоматизации, совсем не закрываются вопросы внутренние в компании.
Второй — большие (выше среднего) компании, которым надо оптимизировать всё и много. Например, поставить SAP. Или 1С, и дальше плясать от этого. Разрабатывать свой аналог SAP в компании, в которой беспорядок, складывается в зону 4 (ПО пишется, компания меняется), что немного безумно и дорого. Также в этой подгруппе всякого рода внедренцы, консалтинг, бизнес-тренеры. Например, за стопятьсоттыщ рублей внедрят Microsoft Dynamics.
А теперь почему я (субъективно) считаю, что «доработки» от лукавого. Если в компании есть проблемы, которые надо решить, то решение диаметрально противоположно проблеме. И решение разрабатывается ровно под проблему. Если проблема решается самой подходящей затычкой — это не решение, это затычка. Допустим, в компании есть отдельный этап формирования зон работы по регионам с последующим планированием обзвона. По-хорошему пишется формирование зон работы по регионам с последующим планированием обзвона. По не-хорошему под это подстраиваются существующие решения, например, пресловутый модуль ERP из Битрикс24 и другие подобные блок-схемы. Ещё хуже, когда под доработкой вместо того, что надо написать, пишется не то, что нужно, а «создать отчёты, настроить интеграции и проч.»
По-хорошему (опять субъективно) — система должна быть платформой. Т.е. что писать не надо:
Авторизация (про роли и права тут нет)
Уведомления по всем каналам, события
Логи, очереди, трансзакции, бекапы.
Прикладывание-скачивание файлов.
Комментарии к чему-либо
Задачи, календарь.
Причем в таком виде оно не пригодно к употреблению, зато даёт хороший старт и экономию на разработке.
Я не отрицаю действенность остальных подходов. До сих пор сайты разрабатываются не на фреймворках, а на джумлах-битриксах. Такой подход тоже жив, и до сих пор люди выбирают по базовому функционалу, а затем дорабатывают + обновляют. Просто я считаю такой подход как в сайтах, так и в КИС не самым эффективным экономически.
Кому такой подход подход подойдет — я перечислил. Либо продукт из коробки идеально устраивает (для совсем молодых стартапов), либо есть внедренец, который грамотно все расскажет и подшлифует бизнес-процессы (для растущих и при этом больших контор с беспорядком внутри). Для компании с хорошими бизнес-процессами такой подход будет скорее в минус, чем в плюс.
1. Компания не подстраивается под ПО, ПО (глобально) не подстраивается под компанию. Например, gmail, AmoCRM.
2. Компания подстраивается под ПО, ПО не меняется. Например, крупная компания которая внезапно выросла, а как рулить не знает. Например, 1С-бухгалтерия.
3. Компания не подстраивается под ПО, ПО меняется/пишется под компанию. Например, уже есть работающие бизнес-процессы, которые надо переложить на систему. Любая платная разработка.
В зоне №2 есть два типа клиентов.
Первый — бюджетные, который выбирают CRM или другое ПО под возможности. Они смотрят, «есть ли модуль счета», а если говорить про сайты, то «есть ли модуль расчета доставки». На основе этого делают выбор. Решается вопрос автоматизации, совсем не закрываются вопросы внутренние в компании.
Второй — большие (выше среднего) компании, которым надо оптимизировать всё и много. Например, поставить SAP. Или 1С, и дальше плясать от этого. Разрабатывать свой аналог SAP в компании, в которой беспорядок, складывается в зону 4 (ПО пишется, компания меняется), что немного безумно и дорого. Также в этой подгруппе всякого рода внедренцы, консалтинг, бизнес-тренеры. Например, за стопятьсоттыщ рублей внедрят Microsoft Dynamics.
А теперь почему я (субъективно) считаю, что «доработки» от лукавого. Если в компании есть проблемы, которые надо решить, то решение диаметрально противоположно проблеме. И решение разрабатывается ровно под проблему. Если проблема решается самой подходящей затычкой — это не решение, это затычка. Допустим, в компании есть отдельный этап формирования зон работы по регионам с последующим планированием обзвона. По-хорошему пишется формирование зон работы по регионам с последующим планированием обзвона. По не-хорошему под это подстраиваются существующие решения, например, пресловутый модуль ERP из Битрикс24 и другие подобные блок-схемы. Ещё хуже, когда под доработкой вместо того, что надо написать, пишется не то, что нужно, а «создать отчёты, настроить интеграции и проч.»
По-хорошему (опять субъективно) — система должна быть платформой. Т.е. что писать не надо:
Авторизация (про роли и права тут нет)
Уведомления по всем каналам, события
Логи, очереди, трансзакции, бекапы.
Прикладывание-скачивание файлов.
Комментарии к чему-либо
Задачи, календарь.
Причем в таком виде оно не пригодно к употреблению, зато даёт хороший старт и экономию на разработке.
Я не отрицаю действенность остальных подходов. До сих пор сайты разрабатываются не на фреймворках, а на джумлах-битриксах. Такой подход тоже жив, и до сих пор люди выбирают по базовому функционалу, а затем дорабатывают + обновляют. Просто я считаю такой подход как в сайтах, так и в КИС не самым эффективным экономически.
Кому такой подход подход подойдет — я перечислил. Либо продукт из коробки идеально устраивает (для совсем молодых стартапов), либо есть внедренец, который грамотно все расскажет и подшлифует бизнес-процессы (для растущих и при этом больших контор с беспорядком внутри). Для компании с хорошими бизнес-процессами такой подход будет скорее в минус, чем в плюс.
Забыл сказать — есть система разарабывается под задачи — нельзя, повторяю, нельзя давать демо-версии и презентации.
Компания подстраивается под ПО, ПО не меняется. Например, крупная компания которая внезапно выросла, а как рулить не знает. Например, 1С-бухгалтерия.
То ли я мысль вашу неверно уловил, то ли пример неудачный.
Первое что будет переписано с ног до головы во внезапно выросшей компании — всевозможные 1С-ки.
Компания выросла и ей надо делать налоговую отчетность и счета выставлять.
Где взять готовую форму счета? Правильно, в 1С. Вторым этапом её подстраивать, да, но сначала посмотрим на менюшки и прикинем, что нам пригодится.
Компания выросла и ей понадобилось для 2000 человек расставлять задания. Что делать? Давайте поставим Asana и будем всем говорить чтобы задания через неё ставились.
Компания выросла, и ей понадобилось делать запись на прием к врачу. Блокноты и стикеры везде валяются, клиенты недовольные. Берём CRM для записей и планирования (такие тоже есть) и смотрим. Ага, оказывается надо спрашивать, во сколько удобно приехать (поле такое есть) и говорить, когда у врачей «окна». Подстроились.
Компания выросла, и ей понадобилось официантам на кухню заказы передавать. Ищем вендора, ставим. Отлично, теперь понятно как нам и что делать. Дальше подстроимся.
Компания выросла, и ей понадобился SAP.
Компания выросла, и ей понадобился сайт. Айда посмотрим, гляньте у битрикса есть корзина и новости — то, что надо. Елена, отныне будешь на сайт новости писать.
Компания выросла, и ей понадобилось считать, сколько у кого на компьютере оперативки и где какая лицензия. Давайте нагуглим «ПО для сисадминов». О, смотрите, есть поле «обновление по сети». Заюзаем, отлично. Подстроились.
Компания выросла, и ей понадобилась телефония. Давайте mango-office подключим. О, смотрите, у манго есть внутренние номера. Давайте настроим, круто же. И женский голос будет говорит «Мы рога! Мы копыта! Говорите после сигнала!». Подстроились.
Компания выросла, и ей понадобилось клиентскую базу писать. О, смотрите, тут в CRM есть такая штука как KPI. Щас настроим, будем штрафы и премии выписывать. О, а еще оказывается можно файлы обсуждать. Как же мы жили без этого, а? Подключаем!
Компания выросла и ей понадобилось как-нибудь отдел разработчиков запланировать. О смотрите, редмайн! С модулем скрам! Всё, айда теперь все проекты тут, будем по скраму работать, будем на виртуальную доску стикеры клеить и их двигать.
Где взять готовую форму счета? Правильно, в 1С. Вторым этапом её подстраивать, да, но сначала посмотрим на менюшки и прикинем, что нам пригодится.
Компания выросла и ей понадобилось для 2000 человек расставлять задания. Что делать? Давайте поставим Asana и будем всем говорить чтобы задания через неё ставились.
Компания выросла, и ей понадобилось делать запись на прием к врачу. Блокноты и стикеры везде валяются, клиенты недовольные. Берём CRM для записей и планирования (такие тоже есть) и смотрим. Ага, оказывается надо спрашивать, во сколько удобно приехать (поле такое есть) и говорить, когда у врачей «окна». Подстроились.
Компания выросла, и ей понадобилось официантам на кухню заказы передавать. Ищем вендора, ставим. Отлично, теперь понятно как нам и что делать. Дальше подстроимся.
Компания выросла, и ей понадобился SAP.
Компания выросла, и ей понадобился сайт. Айда посмотрим, гляньте у битрикса есть корзина и новости — то, что надо. Елена, отныне будешь на сайт новости писать.
Компания выросла, и ей понадобилось считать, сколько у кого на компьютере оперативки и где какая лицензия. Давайте нагуглим «ПО для сисадминов». О, смотрите, есть поле «обновление по сети». Заюзаем, отлично. Подстроились.
Компания выросла, и ей понадобилась телефония. Давайте mango-office подключим. О, смотрите, у манго есть внутренние номера. Давайте настроим, круто же. И женский голос будет говорит «Мы рога! Мы копыта! Говорите после сигнала!». Подстроились.
Компания выросла, и ей понадобилось клиентскую базу писать. О, смотрите, тут в CRM есть такая штука как KPI. Щас настроим, будем штрафы и премии выписывать. О, а еще оказывается можно файлы обсуждать. Как же мы жили без этого, а? Подключаем!
Компания выросла и ей понадобилось как-нибудь отдел разработчиков запланировать. О смотрите, редмайн! С модулем скрам! Всё, айда теперь все проекты тут, будем по скраму работать, будем на виртуальную доску стикеры клеить и их двигать.
Если речь идёт о сборе требований внутри компании, то:
1. Не нужно разговаривать в терминах CRM — пользователям они ни о чём не говорят. Можно установить руководителям подразделений демо-версию или ознакомиться с ней на рабочем совещании, чтобы все поняли, какова структура ПО, что от него можно ждать, а что — нет.
2. От каждого отдела (или нескольких отделов смежной деятельности) должен быть представитель рабочей группы, который владеет пониманием работы в целом и может выяснить, что нужно коллегам: описание их периодических задач, источники данных, согласования, процессы и проч. Можно разработать унифицированную форму или таблицу, можно собирать информацию любым другим способом.
3. Внутри рабочей группы рассмотреть собранные требования и определить пересечения и наложения. Например, нужно создать внутри CRM отчёт для логистов и выясняется, что менеджер по работе с агентами нуждается почти в том же массиве и т.д. Все дублирующие запросы исключить.
4. Создать описание необходимой функциональности, целей, задач, сравнить с тем, что есть в CRM.
5. Совместно с вендором (если есть опыт — самостоятельно) составить техническое задание, если необходима доработка. тут уже свои нюансы, мы об этом ещё будем писать.
1. Не нужно разговаривать в терминах CRM — пользователям они ни о чём не говорят. Можно установить руководителям подразделений демо-версию или ознакомиться с ней на рабочем совещании, чтобы все поняли, какова структура ПО, что от него можно ждать, а что — нет.
2. От каждого отдела (или нескольких отделов смежной деятельности) должен быть представитель рабочей группы, который владеет пониманием работы в целом и может выяснить, что нужно коллегам: описание их периодических задач, источники данных, согласования, процессы и проч. Можно разработать унифицированную форму или таблицу, можно собирать информацию любым другим способом.
3. Внутри рабочей группы рассмотреть собранные требования и определить пересечения и наложения. Например, нужно создать внутри CRM отчёт для логистов и выясняется, что менеджер по работе с агентами нуждается почти в том же массиве и т.д. Все дублирующие запросы исключить.
4. Создать описание необходимой функциональности, целей, задач, сравнить с тем, что есть в CRM.
5. Совместно с вендором (если есть опыт — самостоятельно) составить техническое задание, если необходима доработка. тут уже свои нюансы, мы об этом ещё будем писать.
«Попросите системного администратора или внутреннего эксперта обойти всех сотрудников и настроить вид и цветовую схему CRM под желания каждого пользователя — так системой будет приятнее пользоваться.»
Практика 16 лет работы в коллективе, на 90% состоящем из женщин говорит «НЕТ!!!».
Настройка одного рабочего места может занять от одного дня до бесконечности.
Намного правильнее задать один общий вид для всех и предоставить документацию по настройке рабочего места под себя пользователям.
В итоге намного легче обеспечивать поддержку решения, меньше непроизводитльсных трат времени IT-отдела.
Практика 16 лет работы в коллективе, на 90% состоящем из женщин говорит «НЕТ!!!».
Настройка одного рабочего места может занять от одного дня до бесконечности.
Намного правильнее задать один общий вид для всех и предоставить документацию по настройке рабочего места под себя пользователям.
В итоге намного легче обеспечивать поддержку решения, меньше непроизводитльсных трат времени IT-отдела.
Всё верно — недаром мы рекомендуем распечатать документацию для каждого пользователя. Но иногда проще подойти и помочь, чем отвечать на вопросы коллег, которые будут в любом случае. В посте речь и идёт исключительно о настройках рабочего стола системы — все остальные должны создаваться самим пользователем в процессе работы так, как ему удобно и необходимо для быстрого доступа к важным/часто используемым разделам.
Sign up to leave a comment.
Внедрение CRM: как не быть близким к провалу