Если вы вендор CRM-систем или любого другого ПО/сервиса/услуги для бизнеса, то наверняка знаете, что пользователь с хорошо собранными требованиями — большая редкость. Мы в RegionSoft составили список самых распространённых случаев:
- клиент приходит ни с чем и из него приходится
выбиватьбуквально тянуть клещами информацию о бизнес-процессах, потребностях и задачах, стоящих перед автоматизацией;
- клиент приносит техническое задание, разработанное несколько лет назад при первой попытке внедрить CRM;
- клиент рассказывает о себе, о своём бизнесе, о проблемах, об экономике, о политике, а вендор понимает, что из этого ляжет в основу ТЗ и внедрения;
- клиент молча просит счёт, молча получает лицензии и молча начинает использовать систему;
- клиент собрал и структурировал требования, готов передать их вендору, чтобы тот приступил к внедрению и/или разработке ТЗ (минута научной фантастики в нашем блоге).
Мы разработали подробный чек-лист для сбора требований, чтобы последний пункт из фантастики стал несколько ближе к реальности. Поехали.
Рабочая группа
Если в компании больше одного подразделения, то один человек не справится с внедрением CRM, даже если к нему на подмогу придёт орава бизнес-консультантов (на самом деле, они никому не помогут, только денег отъедят, но мы сегодня не об этом). Поэтому первый шаг, который предстоит сделать для качественного сбора требований, это создать рабочую группу. В неё могут войти руководители подразделений (это самый простой и очевидный вариант), а могут — самые сильные и включённые сотрудники, которые владеют всей информацией и вникают во все процессы. Вы же не будете говорить, что начальники отделов всегда самые грамотные и опытные? Вот и мы не будем. Члены рабочей группы должны:
- знать работу своего подразделения настолько хорошо, насколько это возможно
- быть контактным и готовым обсуждать вопросы и договариваться (поверьте, придётся)
- видеть взаимосвязи между подразделениями и уметь их учитывать
- понимать глобальные бизнес-цели компании
- знать положение дел в компании в целом (позиция на рынке, конкуренты, клиенты и т.д.).
Это удивительное дело, но стоит сформироваться группе и начать составлять первый шаблон сбора требований, так сразу неплохие, в общем-то, коллеги превращаются в агрессивных акул. В этом нет ничего предосудительного: каждый хочет сделать так, чтобы автоматизация покрыла как можно больше задач именно его подразделения. Такое положение вещей сглаживается либо в ходе работы либо после первой встречи (созвона) с вендором, который объясняет, что софт сам не продаёт, клиентов не ищет, код не пишет, баги не фиксит и деньги не зарабатывает. То есть работать всё равно придётся.
Несколько моментов:
- В рабочую группу обязательно должен входить CTO, CIO или CEO. Ну или соответствующие им люди с менее пафосными названиями.
- Не стоит поручать внедрение одному лишь директору по продажам или по маркетингу — они непременно стянут одеяло на себя, и у вас будет не просто лоскутная, но ещё и дырявая автоматизация (если вообще будет). Дело в том, что CRM-система — это не просто набор функциональности, это программный комплекс, с которым работают сразу несколько подразделений (либо вся компания целиком), и важно, чтобы внедрение прошло гладко и с практической (пользовательской), и с технической стороны, без перекосов в сторону того или иного отдела.
- Все действия, обсуждения и заключения рабочей группы должны протоколироваться, чтобы не упустить важную информацию и исключить дальнейшие разбирательства.
Примерный план работы проектной группы по внедрению CRM
- Обсуждение и формирование единой формы сбора требований. Это может быть таблица примерно такого вида:
- Сбор требований и обсуждение их внутри подразделения.
- Обсуждение требований внутри рабочей группы.
- Сведение требований в единый документ, исключение пересекающихся пунктов.
- Разделение требований на функциональные и нефункциональные.
- Установление специфических требований, обусловленных особенностями бизнеса компании.
- Согласование итогового документа всеми сторонами, обсуждение с руководством.
- Работа с вендором может вестись параллельно (так гораздо легче), а может инициироваться уже после сбора требований и выбора нескольких CRM-систем для дальнейшего общения с разработчиками.
На этом этапе особенно важно, чтобы CRM-система не превратилась в инструмент давления, шантажа или превосходства. Например, маркетинг может объявить себя холдером всех процессов и оттеснить продажи, проигнорировать их интересы. Или, например, лидер рабочей группы может «забыть» пригласить к обсуждению представителей технической поддержки, думая, что они воспримут систему как данность. Такой расклад уже давно описан в известной басне Крылова:
Когда в товарищах согласья нет,
На лад их дело не пойдёт,
И выйдет из него не дело, только мука.
Это вообще очень современная басня, идеально подходит к работе с проектом внедрения, что внутри команды заказчика, что между заказчиком и вендором. Так что главное — правильно впрячься и начать работать.
Базовое самообследование компании
Прежде, чем перейти непосредственно к требованиям, стоит собрать небольшой анамнез состояния компании — во-первых, это всё равно понадобится при разговоре с вендором, а, во-вторых, может открыть для вас самих что-то новое ну или как минимум подсчитать количество лицензий (если система, например, как RegionSoft CRM, предлагает конкурентные лицензии) или количество пользователей (если речь о SaaS — то есть об аренде софта).
Итак, что вам непременно понадобится для выбора CRM-системы и дальнейшего внедрения.
- Размер компании: численность сотрудников, удалённых/совмещающих/полевых сотрудников, руководящих лиц.
- Подразделения, их функции и взаимосвязи. Лучше всего нарисовать эти отношения на бумаге, а потом перевести в электронный вид с помощью любого/любимого инструмента. Оргструктура и функциональности сильно разнятся от компании к компании, но вот на рисунке фрагмент того, как это может выглядеть. Да, даже в небольшой компании схема может удручать своими первичными размерами и связями, зато отсюда же стартует разбор бизнес-процессов и понимание того, всё ли на своих местах, есть ли дублирование функций и т.д.
- Размер и примерная структура клиентской базы. Первое, что вам надо знать — это какой тип карточки клиента вам понадобится: для юридических или физических лиц (ну или оба и ещё доработанный для B2G — а вдруг?). Второе — увы и ах, но некоторые вендоры до сих пор умудряются продавать СУБД клиентам отдельно, и вы при 100 000 записей можете, например, влететь на необходимость покупки MS SQL. Ну и опять же, это важный элемент анализа бизнес-процессов. Заодно вы оцените, где и как хранится ваша клиентская база, какая её часть потеряна, бесполезна или «крысится» продажниками.
- Список потенциальных пользователей CRM-системы, можно прямо поимённо. Во-первых, вы оцените будущие затраты на обучение, во-вторых, сможете наметить ранних последователей, будущих холдеров процессов и внутренних экспертов.
- Уже существующий в компании пул программного обеспечения нужен вам для того, чтобы понять, что из имеющегося зоопарка сможет заменить CRM-система (и за что вы перестанете платить), с чем придётся интегрироваться, откуда мигрировать, а что так и останется работать, как работало. Например, RegionSoft CRM в самой навороченной конфигурации Enterprise способна заменить все планировщики, картотеку клиентов с исчерпывающим досье, почтовый клиент, систему управления проектами, складскую программу, тикет-систему и багтрекер (для нетехнической компании, хотя мы сами её используем для этих целей вполне успешно), базу знаний и проч.
- Бюджет на CRM (покупка + внедрение). Мы уже писали, сколько стоит CRM — почитайте подробный текст на эту тему. Повторимся лишь, что нередко прайс-лист и калькулятор на сайте разработчика и цена проекта внедрения — абсолютно разные вещи, всё зависит как раз от ваших потребностей (в доработке, обучении, установке, поддержке и т.д.).
После того, как эта информация собрана и структурирована, можно запускать два параллельных процесса: отбор вендоров и сбор требований всех типов. Чем больше вы общаетесь с поставщиками CRM-системы, тем лучше — вы полностью погрузитесь и в терминологию, и в особенности выбора корпоративного ПО.
Ищите вендора
Поиск вендора — отдельная большая история, в которой нет мелочей. Считайте, в ближайшей перспективе эта компания станет вашим партнёром, помощником и консультантом. Мало, что сойтись должно всё: от отношений до потребностей, так ещё и важно, чтобы вас не бросили на полпути. А такое может легко случиться, если вы, например, доверитесь молодой компании-разработчику, которая через год внезапно решит, что продавать раскрашенные сноуборды выгоднее, чем пилить и поддерживать CRM (так и есть). Но это такой минимальный «визуальный» отбор, на самом деле есть более важные маркеры неплохого вендора.
- Тип поставки CRM-системы. Буквально года три назад, на пике повальной моды на облака, мы могли бы агрессивно написать «не берите облачников — у них цена владения заоблачная». Однако разработчики быстро огляделись, увидели, что приличный бизнес не всё и не всегда готов доверить облачному хранилищу (клиентскую базу и данные о поставщиках в первую очередь) и почти все серьёзные вендоры выпустили и облачные SaaS-версии (платите каждый месяц, храните в облаке), и серверные SaaS (платите каждый месяц, храните у себя) и полный on-premise (платите один раз + за обновления, храните у себя). Не будем мучить вас расчётами, всё уже было написано до нас и нами. Ну и да, цена аренды всегда выше, но иногда аренда оправдана.
- Обновляемость системы — спросите вендора, как часто происходят минорные обновления, как часто — мажорные, что входит в те и другие, какие из них платные, какие — нет, как они накатываются.
- Опыт компании-вендора (или его отдельных сотрудников) в сфере, аналогичной вашей. В принципе, в подавляющем количестве случаев этот пункт необязателен — внедрение в большинстве сфер довольно однородно. Но если у вас специфическая отрасль (медицинский центр) или вы — крупный завод, то не лишним будет узнать у вендора, есть ли у него опыт похожих внедрений. Опыта и функциональности CRM-ки для стартаперов может просто не хватить для внедрения в производственно-торговом холдинге.
- Возможность доработки системы силами вендора — в принципе, пункт кажется очевидным, и разработчик всегда готов доработать свою систему. Но всё же уточняйте — бывает, что бизнес-модель системы не предполагает глубокую кастомизацию.
- Ресурс вендора в отношении технической поддержки — уточните, что входит в платную техподдержку, что в бесплатную, какие категории инцидентов и в какие сроки обслуживаются. Платная ТП — это абсолютно нормально, главное, понять, за что платите: за приоритет, за опыт сотрудников, за сложность или за всё вместе взятое.
- Возможность обучения — тоже вроде бы очевидная вещь, на которой однако вендоры могут и сэкономить и отказаться от обучения вовсе или под видом обучения провести презентацию продукта. Некоторые популярные вендоры на российском рынке представляют отсутствие необходимости обучить персонал как маркетинговое преимущество, так и заявляя, что «обучение не требуется», а в «интерфейс легко влюбиться». Ну, во-первых, вам с интерфейсом работать, а не на свидания ходить, а во-вторых это звучит примерно как «вот на механике нужно учиться, а с коробкой автомат две педальки, одна ручка — сел и поехал». Понятно, что обучение необходимо более, чем в половине компаний (а по-честному, во всех) — хотя бы для того, чтобы сотрудники могли задать вопросы и быстро стартовать основную работу в системе.
Впрочем, мы увлеклись разговором о вендорах — давайте уже смотреть, что же входит в требования, и все ли они должны быть у вашей компании.
Функциональные требования
Функциональные требования — это лаконичные описания требуемого от системы поведения в тех сферах, которые касаются основной рабочей деятельности сотрудника, подразделения, компании. В общем, как раз — что должно быть и как примерно оно должно работать.
Вот список того, что чаще всего нужно от CRM-системы любой компании:
- управление контактами
- управление задачами, постановка задач, делегирование
- персональное и коллективное планирование
- интеграция с почтовым клиентом или наличие встроенного
- интеграция с телефонией
- интеграция с бухгалтерской системой
- управление учётными записями сотрудников
- разделение прав доступа сотрудников
- отчётность (включая воронку продаж)
- база знаний
- пользовательские шаблоны (договоры, коммерческие предложения, первичка)
- минимальная аналитика.
Это необходимый и обязательный минимум, который нужен любому бизнесу в России. Сюда же, к функциональным требованиям относят специфические требования, характерные для конкретного бизнеса: управление производством, управление складом, кассы, сканеры штрих-кодов, интеграция с сайтом и т.д. Все перечисленные возможности в идеале должны реализовываться внутри интерфейса системы и комплиментарных ей продуктов-сателлитов (например, у нас есть базовый продукт — RegionSoft CRM, а расширение её возможностей происходит за счёт наших же разработок — VoIP Connector и Application Server, но никак не за счёт сторонних приложений). Однако может быть так, что часть функционала реализована за счёт плагинов сторонних разработчиков. Если ваш выбор пал на такую систему — приготовьтесь платить и за них тоже.
Вы можете спросить, зачем собирать вот эти требования, ведь они есть абсолютно во всех системах — сложно представить CRM без менеджера контактов или какого-никакого календаря, например. Отвечаем.
- Нет, не у всех. Даже среди CRM «на слуху» можно найти системы, например, без коллективного или перспективного планирования рабочих задач, без адекватной интеграции с телефонией и т.д.
- Вам может быть что-то особенно важно — например, флажки статуса клиента в карточке, всплывание карточки при звонке, возможность делегирования задач, приватные клиенты или просмотр воронки продаж в разрезе менеджеров, периодов и т.д. Мелочь, а у кого-то её может не быть и это уже платная доработка, в то время как у другого вендора всё это есть в базовой поставке.
- Опять же, нужно проверить весь список необходимой вам функциональности и уточнить, поддерживается ли он вендором или необходима доработка.
Однажды у нас произошёл спонтанный диалог на одном из деловых сайтов — посмотрите, как ставится вопрос и как отвечает представитель вендора (нас то бишь). Примерно так и должен выглядеть профессиональный диалог во время выбора CRM-системы. Речь, кстати, идёт как раз о функциональных требованиях.
Что ещё важно знать, собирая функциональные требования к CRM.
- Когда требования будут собраны, обязательно проставьте приоритеты и ранжируйте список: по срочности (что должно быть сразу, а что — потом) и важности (что можно реализовать в последнюю очередь).
- Вам не нужно создавать ТЗ — его разрабатывает ваш вендор. Почему — мы уже объясняли один и второй раз.
- Не нужно прибегать к формализации (квалифицированный лид должен быть передан соответствующему менеджеру согласно внутренней процедуре К-8785ап «О формировании пула заинтересованных лиц и делегировании процесса продаж») или писать фривольно (когда продаван впаяет этому лоху кпэшку, обметить его красным и кинуть ропу для сабмита). Пишите простым человеческим языком, желательно русским — у вас нет задачи показать себя, у вас есть задача донести до инженеров и аналитиков вендора свои пожелания.
- Не стремитесь вписать в требования всё, что нужно и не нужно — тут нет понятия «всякий случай». Если есть сомнения в необходимости функциональности, отправьте такие пункты в отдельный блок. Может так случиться, что после старта использования CRM-системы вы пересмотрите процессы и что-то вам уже не понадобится.
Нефункциональные требования
Это блок требований, связанный с техническими сторонами эксплуатации CRM-системы. Некоторые клиенты боятся показать свою технологическую некомпетентность и стесняются задавать такие вопросы. Не стесняйтесь — это ваше право, и вам важно знать о параметрах, которые определяют качество вашей дальнейшей работы.
- Если CRM облачная, обязательно запросите информацию о том, как часто создаются бэкапы, где они хранятся, на каких условиях предоставляются владельцу данных (то бишь вам). Узнайте показатель доступности — в идеале вам должны в рамках договора гарантировать 99,9% времени безотказной работы. Узнайте, сколько занимает аварийное восстановление данных. Спросите, на серверах какой страны будут храниться данные (скорее всего, это у всех Россия, но всё же уточните, потому что вам предстоит хранить клиентскую базу — то есть персональные данные).
- Пропишите требования к интеграции: с телефонией, 1С, виртуальной АТС и проч.
- Определите требования к миграции и импорту данных. Составьте список источников, откуда предстоит мигрировать существующие данные (записи в Excel, СУБД старой CRM или иного ПО и т.д.). Часть накопленной информации вам придётся перенести вручную, большую часть электронных данных вам поможет перенести вендор.
- Любого вендора расспросите о масштабировании — что будет, если у вас втрое вырастет количество пользователей, а если на 1 млн. (ну или иное число в ваших масштабах) увеличится количество записей? Укажите в требованиях возможную нагрузку на CRM-систему (у нас 7 000 клиентов, до 600 000 покупок в месяц, по каждой сделке нужно хранить минимум 7 документов и т.д.).
- Определите требования к стоимости — сколько вы готовы потратить на CRM. Разобраться в нюансах ценообразования проекта внедрения CRM вам поможет эта статья.
- Пропишите требования к удалённой/мобильной работе, если в вашей компании это необходимо. Желательно пояснить, кем и как будут использоваться удалённые и мобильные возможности.
У каждой компании может быть свой дополнительный набор нефункциональных требований, связанный с техническим штатом, оснащением и т.д. Попросите ИТ-отдел или системного администратора прописать базовые требования к бизнес-ПО в вашей компании.
Бизнес-требования
В принципе, бизнес-требования можно отнести к функциональным, но мы выделим их в отдельную группу. Дело в том, что сейчас одна из самых нужных и удачных фишек в CRM-системах — бизнес-процессы. Но в силу ряда сложившихся заблуждений к бизнес-процессам обращаются лишь крупные компании, которые имеют сложные цепочки рутинных и повторяющихся задач. Между тем, автоматизация любого цикличного процесса в компании здорово освободит руки персоналу и позволит им работать головой, а не на автомате. К тому же, сократится время согласования, а ни одна задача не будет забыта — экземпляр процесса сам напомнит всем ответственным, что пора выполнить свою часть работы.
Поэтому с бизнес-требованиями обязательно нужно поработать.
Для начала определите цели и задачи вашего бизнеса. Основное отличие: цели — это большие и глобальные (рост продаж на 140% за год), задачи — небольшие и выполнимые (обучить персонал новой технологии продаж, внедрить автоматизацию, привлечь клиентов высокодоходного сегмента и проч.). Скорее всего, вендору эта информация не будет полезной, а вот вам самим для понимания и настройки бизнес-процессов — вполне. Внимание! Не требуйте выполнения этих задач от вендора, он вам даёт инструмент, ваша задача — овладеть им как самурайским мечом.
А вот после этого нужно приступать к самому важному моменту — пересмотру бизнес-процессов в компании.
- Выпишите существующие процессы (если они есть), опишите этапы, сроки, ответственных, ресурсы, контрольные точки.
- Опишите все рутинные и повторяющиеся задачи, которые можно внести в рамки автоматического бизнес-процесса (это могут быть и выполнение заказа, включая производство, и консультация клиента, и работа с VIP-ом, и даже оформление отпуска). Пропишите этапы, сроки, ответственных, ресурсы, контрольные точки.
- Определите поддерживающие процессы — не рутинные, но крайне важные повторяющиеся события в компании. Например, ежегодное бюджетирование — огромный, колоссальный процесс со сложными согласованиями. Необходимо реализовать его в CRM как бизнес-процесс — тогда в нужный момент вы получите уведомление о старте подготовки бюджета на 2019 год и сделаете всё не аврально, а слаженно (не всегда с первого раза).
Эти пункты довольно просто звучат, но являются едва ли не сложнейшей частью внедрения, поскольку в части компаний приходится не проектировать и прописывать процессы, а разгребать бардак и строить управленческие потоки заново.Кстати, внедрение CRM — отличный повод пересмотреть хаос и превратить его в космос.
Бизнес-процессы можно создавать и пересматривать уже после старта внедрения, чтобы не терять время: чем раньше вы автоматизируетесь, тем больше шансов опередить конкурентов за счёт скорости, точности, срочности и аналитики. Говоря простым языком, ваши клиенты на своей шкуре почувствуют, что вы внедрили CRM и с вами стало приятнее иметь дело.
Важные замечания по процессу сбора требований
Требования очень плотно пересекаются с техническим заданием, но им не являются. Тем не менее, несмотря на то, что требования не подписываются сторонами, как вы могли уже понять из статьи, они важны — причём как для самой компании, так и для вендора. Наличие требований к CRM — залог того, что вы готовы к диалогу, а не к пассивному ожиданию чуда, которое должен сотворить разработчик.
- Все требования по сути — контрольный список того, что у вас должно быть, и с которым вы будете сопоставлять функциональность выбранных CRM-систем. Поэтому прописывайте даже мельчайшие детали, чтобы максимально точно подобрать «свой» софт.
- Не забывайте присваивать категории важности каждому требованию. Создайте стандартную для себя шкалу и ориентируйтесь по ней (например, высокая важность, средняя важность, низкая важность, факультативно).
- Работая над требованиями, мысленно прогоняйте в голове модель использования того, о чём вы пишите. CRM должна стать не идеалом и не дорогой вазой империи Цин на полке, а инструментом, решающим конкретные деловые задачи, вашим помощником. Поэтому не нужно писать в требованиях несбыточные желания, хотелки и прочие фантазии. Только рабочий процесс, только деловой подход.
Нужно ли мне это всё?
- Оформите требования так, чтобы их было приятно читать и удобно понимать. Пусть они станут отправной точкой технического задания.
- Не увязайте в функциональных требованиях, это должен быть качественный, детальный, но всё же список, а не полное изложение всех потребностей бизнеса с деталями, подробностями и примерами.
Чаще всего компании игнорируют требования. Причин на то масса: начиная с того, что CRM навязали сверху и заканчивая тем, что никому не охота разбираться в хитрых отношениях внутри компании. Могу провести аналогию с автомобилем: если вы сами переберёте электрику и повесите кучку проводов на соплях, есть вероятность, что оно поедет и даже повезёт, но в какой-то момент обязательно откажет сигнал или не сработает поворотник. А это уже прямой путь к ДТП. Так и тут — в «бардачной» компании можно работать, зарабатывать, получать премии и т.д. Но однажды из-за разлаженности процессов пойдут крупные сбои, которые приведут к потере сотрудников, ушедшим клиентам и просевшей прибыли.
Требования к CRM — это гарантия сокращения рисков при внедрении, более быстрая реализация проекта, более точная расчётная стоимость внедрения CRM-системы. Когда вы собрали требования и посмотрели на свой бизнес со стороны, вы общаетесь со знанием дела и легко избежите возможных манипуляций вендора (увы, такие ребята на рынке есть). В общем, собирайте требования, передавайте их вендору, работайте над проектом своего долгосрочного инструмента — CRM-системы, и тогда сроки проекта и окупаемость инвестиций в автоматизацию не разочаруют.
Комментарии (28)
ArturSitnikoff
06.02.2018 23:03-1От обширного комментария воздержусь, так как уже написал статью на эту тему для публикации в конце недели. Раньше не представляется возможным, так как статья выходит в день запуска проекта, она описывает проект, с кучей скриншотов, если дать почитать и не дать попользоваться, будет нехорошо…
Так вот разработанный проект — CRM для учета клиентов компьютерных мастерских. Но CRM её особо и не назовешь, CRM подразумевает гибкую настройку под разный бизнес, а здесь ни какой гибкой настройки нет, так как ориентация исключительно на один бизнес и ни шага в сторону. Когда продукт заточен под конкретный бизнес и настройки не нужны практически, эти «настройки» являются штатным программным интерфейсом.
Я считаю невозможно одним продуктом угодить одновременно трейдерам с Уолл Стрит для ведения учета клиентов и гарантийному сервису завода SAMSUNG в Китае. Проще сделать два продукта и каждый проработать под свои нюансы бизнеса. Это во многом выйдет плюсом. Больше довольных клиентов, меньше лишнего в кодовой базе каждого проекта, повышенная производительность, простота, разделение разных проектов на разных доменах, как простой метод масштабирования системы.
Люди не знают какую CRM им выбрать лишь потому, что конкретно для их бизнеса еще не появился тот самый продукт, после 5 минут демо-пользования которым человек понимает — мне больше не нужно ничего искать, вот оно решение всех моих проблем.
Verovir
06.02.2018 23:45+1Я вот прям подпишусь, чтобы не пропустить вашу статью. А причина моего интереса проста — вот эти ваши слова:
Я считаю невозможно одним продуктом угодить одновременно трейдерам с Уолл Стрит для ведения учета клиентов и гарантийному сервису завода SAMSUNG в Китае. Проще сделать два продукта и каждый проработать под свои нюансы бизнеса.
Это говорит ровно об одном — вы не имеете обширного опыта в автоматизации. Начнём с того, что вы привели два примера компаний, которые имеют разные типы ПО для работы. Уолл-Стрит мы трогать не будем, их системы в корне отличаются от всего, что может видеть обычный инженер. А вот гарантийный сервисный завод вполне спокойно укладывается в любую мало-мальски развитую CRM с доработкой. Писать CRM под каждый бизнес — это либо не CRM, либо безумие и дороговизна. В общем, ваше мнение больше чем странное.ArturSitnikoff
07.02.2018 00:34Вы совершенно правы, обширного опыта автоматизации не имею, но прекрасно разбираюсь во всех рабочих процессах одного бизнеса и не встречал такой CRM, где можно было бы за пару минут настроить подобную форму, с дальнейшим выводом на печать товарного чека на основе введенных данных. Как минимум пару часов провозиться придется с настройкой, а это лишь единичный случай из огромного множества нюансов.
Что будет лучше, объяснить директору ремонтной мастерской как такую форму создать и настроить документ для печати, или предоставить ему эту форму в один клик готовую? Какое обоснование преимущества универсальной CRM перед узкоспециализированным софтом?Verovir
07.02.2018 10:11+1А зачем настраивать за пять минут? Есть норматив внедрения, есть проект — постепенно всё автоматизируется и начинает работать. Хорошо, давайте попробуем поговорить от противного. Пусть есть вендор А, который готов насоздавать CRM под все отрасли — и это будут очень дорогие системы. И что, по-вашему, лучше — доработать универсальное решение за пару месяцев или настроить за пару часов или отвалить десяток миллионов за систему «взял и поехал»? Тот же ваш сервис-центр просто не потянет это. Вы придумали одну фишечку и хотите её продать на Хабре? Велкам. Но не нужно писать абсолютно фантасмагорические вещи про «индивидуальные» софтины.
И потом, зачем директору что-то объяснять? Вы внедряете, настраиваете и обучаете. Обоснований вам вагон:
— дешевле — не нужно искать инвестора на каждую разработку
— быстрее
— можно начать работать и дорабатывать по ходу дела
— прокачаны все функции.
Для того и существуют CRM, чтобы их можно было дорабатывать и быстро имплементировать. А вы сейчас просто демонстрируете некомпетентность. Написать формочку для печати чеков != стать автоматизатором и внедренцем.
tas
07.02.2018 10:16+1Какое обоснование преимущества универсальной CRM перед узкоспециализированным софтом?
Если бизнес не состоит из одной формы и пары отчетов, то преимуществ может быть очень много, например:
- Готовые (обновляемые) отчеты для предоставления регулирующим органам
- Готовые адаптеры для импорта и экспорта данных в другое ПО
- Обеспечение требований по безопасности, производительности и т.п.
- Наличие готовых специалистов или готовность работников изучать это ПО для повышения своих компетенций (не будет такого, что человек, который является экспертом в доморощенной программе, при смене работы будет себя чувствовать как рыба на суше)
- И т.д...
QDeathNick
07.02.2018 12:47Может быть очень удобно в начале «предоставить ему эту форму в один клик готовую», но сколько раз я сталкивался с людьми, купившими готовый продукт и желающими «всего лишь добавить ещё одну колонку со скидкой». А я смотрю на экзешник который им впарили без возможности какого либо конфигурирования и объясняю им, что исправить это будет стоить им столько же, сколько они уже отвалили такому внедренцу.
не встречал такой CRM, где можно было бы за пару минут настроить подобную форму
За пару минут конечно нет, но и пару часов тут не нужны. Зато у вас будет полноценный конструктор, который позволит изменить/добавить всё что угодно.
А потом вам в сети мастерских потребуется система для работы с кадрами, и вам придётся покупать ещё и её, а бизнес-процессы кадровика принципиально не отличаются от работы с клиентами, а ещё вам желательно с поставщиками где-то вести переговоры и система ведения проектов чтобы планировать открытие новых мастерских и вы будете покупать и покупать «заточенные продукты», вместо того чтобы настраивать новые требуемые процессы в одном и том же удобном конструкторе.
Директору мастерской можно продавать эту форму и в универсальной системе, жаль, что их CRM называют, они уже давно гораздо шире, и некоторым удаётся не превратится в монстра «CRM-ERP-ЦУП», так как они не делают разницы между CRM, ERP и ЦУП, а остаются универсальным удобным инструментом для любых процессов.
Я пока не встретил ни одного бизнеса, который бы был полностью удовлетворён своей текущей системой, каждый дорастает до определённого момента, когда хочется большего. И одни постоянно растут, а другие постоянно упираются в ограничения.
Так может стоит готовится к этому заранее?ArturSitnikoff
07.02.2018 15:56В описанном мной случае речь идет об онлайн-сервисе, который планируется как продукт с поддержкой и постоянным введением новых функциональностей по желаниям потребителей. Работа с филиалами и кадрами в минимальном варианте тоже реализована. По сути я просто переработал свой прошлый индивидуальный заказ, разработанный для частного пользования в компьютерной мастерской и запускаю в массовое использование по желанию. И вместо того чтобы бесконечно наращивать функционал, открываю что есть, там уже осудите по факту, осталось лишь два три дня настройке и контрольным проверкам уделить.
Уверен, что именно специалисты компьютерных мастерских оценят функциональность, так как она реализовывает список их требований к бизнес логике и детали рабочих процессов. Просто заказчик попался целеустремленный, предоставил рабочее место в своем офисе и разработка велась больше месяца, прям посреди рабочего процесса мастерской, я задавал миллион вопросов, он спрашивал не меньше, можно ли это, а можно ли так… В итоге получился уникальный продукт, совершенно не похожий на CRM.
Основываясь на своем опыте разработки узкоспециализированного ПО для бизнеса и озвучил свое мнение по теме. Никого не призываю бросать CRM и писать под каждый бизнес индивидуальное ПО. Но если перед клиентом будет ПО разработанное для его рода деятельности, у него даже вопросов не возникнет как им пользоваться в целом. Это вполне заслуживающая внимания мысль, для развития софтвенного бизнеса, в ответ на «собираем требования к CRM». Можно например иметь группы настроек, которые будут применяться к программе в момент регистрации, тогда ПО как было универсальным, так и останется, но вместо объяснений клиенту что и как, можно заготовить патч, который сформирует за клиента большинство настроек.
Учитывая «имеющиеся» мнения что CRM это просто развод клиента на бабки, такого рода забота может вполне способствовать привлечению новых клиентовQDeathNick
08.02.2018 16:37Уверен, что именно специалисты компьютерных мастерских оценят функциональность, так как она реализовывает список их требований к бизнес логике и детали рабочих процессов.
Я бы не был так уверен, пока их фактически не оценят.
Как показала моя практика у каждого своё видение бизнес-процессов и не каждый готов их менять под какую-то спецпрограмму.
Можно например иметь группы настроек, которые будут применяться к программе в момент регистрации
А ещё добавить модульность, автоматический контроль зависимостей при установке модулей и вы получите удобный инструмент.
Jon7
07.02.2018 17:42Это криво спроектированная простейшая типовая форма. Тут нет никакой специализации вообще. Не требуется никаких 2 часов для ее настройки, достаточно типового шаблона.
ncix
07.02.2018 10:59+1Есть один аспект, принципиально различающий клиентов. Это собственно вопрос, существует ли в принципе в компании-заказчике методология продаж или нет. Если нет — то CRM ничего не изменит. Сначала необходимо будет выстроить процессы продаж, а потом уже класть их на систему. Тут без консультанта, понимающего специфику продаж в конкретной отрасли, обойтись очень сложно.
Так что на старте нужно задать заказчику простой вопрос — чего вы ждёте от CRM, какие результаты внедрения должны быть?
RegionSoft
07.02.2018 12:01+2Совершенно верно — если в компании нет методологии, нет бизнес-процессов в принципе, то про это есть известная вендорская поговорка: «получим автоматизированный бардак». Но если мы обратимся к вопросу методологии продаж, тот тут тоже есть «подводный» камень — методология может быть тоже не органичной, а насаженной «сверху», как раз консультантом или тренером. Эти парни не всегда отвечают за свою работу. Тогда опять же нет понимания процессов, и в них нужно ковыряться. Но это так, ремарка, тема совсем не хабровская.
Вот вам анекдот про большинство консультантовЖили-были мыши. Все их обижали. Однажды пришли мыши к сове:
-Мудрая сова, помоги! Все нас едят. Скоро нас не останется. Что делать?
Подумала сова и говорит:
-Мыши! Станьте ежами! Будете колючими и для охотников недоступны.
Побежали мыши радостно:
-Станем ежами! Станем ежами!
Вдруг одна остановилась:
-А кто-нибудь знает: как стать ежами?
Никто. Побежали обратно к сове.
-Сова! А как нам стать ежами???
-Мыши! Идите к чёрту! Я не тактик, я — стратег !ncix
07.02.2018 12:18методология может быть тоже не органичной, а насаженной «сверху», как раз консультантом или тренером. Эти парни не всегда отвечают за свою работу. Тогда опять же нет понимания процессов, и в них нужно ковыряться
Совершенно верно. Но вы сейчас говорите о том, что ваш человек, занимающийся внедрением, по факту выполняет работу консультанта, только называется иначе и должен отработать качественнее. Собственно внедренная CRM тоже может оказаться "неорганичной". Да и в любом случае, конечные пользователи будут сопротивляться и саботировать работу, по-началу. Но про это вы наверняка хорошо знаете. Кстати с удовольствием почитал бы про опыт борьбы с таким явлением.
RegionSoft
07.02.2018 12:40+1Саботаж сотрудников — отдельная история. Конкретно про неё мы пока не писали, но был пост, где вопрос бойкота ПО мы поднимали — вот здесь. Тут опять же нет универсальных рецептов, могут быть лишь рекомендации, потому что всё зависит от модели управления, позиции руководства и собственно, отношения персонала к компании.
ROI4CIO
07.02.2018 14:19-1Очень информативная статья, спасибо большое. Про выбор вендора и CRM — мы тоже работаем над тем, чтобы можно было всем независимо сравнить ИТ-продукты по характеристикам, по примерам внедрений в других компаниях. Вот один из примеров сравнений нескольких CRM
Antislovoblud
07.02.2018 14:59-3Для начала, изучите термин «информативный», а уж затем пишите своё мнение. Про знания даже не пишу…
DRDOS
07.02.2018 14:28Статья о том как показаться умным, развести клиента, а потом ни за, что не отвечать!
Antislovoblud
07.02.2018 14:52-3Статью читать, но советы не применять.
Категорически.
Далее подробно.
? Про заблуждение о требованиях, цитата: «… то наверняка знаете, что пользователь с хорошо собранными требованиями — большая редкость…».
Пользователь априори не в состоянии выдвигать требования к технической системе, поскольку у него нет знаний и он использует её по прямому назначению, участвуя в эксплуатации, но не разрабатывает и не сопровождает АС. У пользователя есть потребности (нужна в чём то), но не требования и, даже, не критерии.
Следствие этому заблуждению, есть Ваши последующие ошибочные организационные и технические решения.
Вам следует уметь собирать потребности, преобразовывать их в требования (функциональные и структурные), уметь формулировать цели и задачи и т.д…
? Про внедрение, цитата: «Не стоит поручать внедрение одному лишь директору по продажам или по маркетингу…».
Директор априори не может внедрять, но должен управлять внедрением, поскольку в его обязанности может входит функция организации работ, а не реализации, т.е., в д.с., разработка (внедрение есть часть разработки) – ещё одна грубая методическая ошибка.
См. организация и планирование деятельности.
? Про планирование, цитата: «Примерный план работы проектной группы по внедрению…».
> План тесть заранее сформированный порядок и последовательность осуществления деятельности для достижения цели. Это кратко.
Прочитали? Осознали различия между контекстом своего «плана» в статье и определением выше?
Про функциональные требования – в статье заявлено, но контекст не соответствует понятию «функция».
Про бизнес-требования – в статье заявлено, но контекст не соответствует понятиям «бизнес» и «требование».
И т.д.
? Про глупость, цитата: «Требования очень плотно пересекаются с техническим заданием, но им не являются...».
Для начала, изучите понятие «требование», а также «ТЗ».
> Требование – положение нормативного документа, содержащее критерии, которые должны быть соблюдены. [ГОСТ 1.1 2002] Пояснение: выполнение обязательно.
> Техническое задание – является исходным документом для разработки и испытания изделия. Содержит описание назначения и области применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний. Разрабатывается на основе исходных требований заказчика, результатов выполненных научно-исследовательских работ, научного прогнозирования, экономических исследований, анализа передовых достижений и технического уровня отечественной и зарубежной техники, а также изучения патентной документации. [ГОСТ 19.101-77, ГОСТ 25123-82]
Понятие «функция» изучить самостоятельно, а также запомнить, что в контексте должно присутствовать описание полезной работы. Пример – автоматическое формирование первичной и сводной отчётности, выполняемой по вызову из…
Понятие «интеграция», применительно к АС, это не функция (см.определение).
Обывательски — думаете одно, делаете второе, а подразумеваете третье…
Академически – статья содержит не точную и недостоверную информацию, чем вводит читателей в заблуждение.
Вывод: статью не читать, советы не применять.
PS: В прочем, если нужно продуцирование квази-деятельности – статья это самое оно…
Axelus Автор
07.02.2018 17:14+2Сложно отвечать на комментарии, которые выпадают из контекста статьи. Конечно, можно еще придраться к грамматическим ошибкам, неверно расставленным запятым, плохой согласованности текста. И даже сбегать посмотреть на учебники по русскому языку и привести список параграфов для изучения. По-моему, очень смахивает на профанацию.
P.S. Блин, чё написал… Пошел изучать термин «Профанация» :)Antislovoblud
07.02.2018 20:06-1Верно. Комментарий должен содержать позицию читатели плюс обоснование позиции. Желательно ссылки на достоверные источники информации.
1. Ссылаетесь на гипотетические придирки к грамматическим ошибкам, но не приводите цитат, и, тем более, не даёте им оценку. По пунктуации аналигочно.
2. К чему Вы применяете термин «профанация», также не указываете. Формулировка «смахивает», также не однозначна.
Вывод: Ваш комментарий также не имеет ценности. В обывательской формулировке это есть «флэйм» (жаргон применяемый в форумах).
В моих формулировках есть логические ошибки? (это риторический вопрос).Axelus Автор
08.02.2018 10:36+2> Вывод: Ваш комментарий также не имеет ценности.
Безусловно, каждый человек имеет право на высказывание своего мнения. Ваше мнение я также уважаю, хотя не согласен с ним, поскольку у разных людей разное понимание о ценностях. Для одних важна публикация флуда в чужом блоге, и он для них является ценностью, а другие за свои ценности готовы совершать героические поступки и жертвовать собственной жизнью. Данную ветку диалога больше поддерживать не буду, поскольку не вижу смысла в этом.
aPiks
Как мне кажется, создание фокус группы сильно не поможет, так как люди, которые не имеют представления о том, что можно автоматизировать, а что — нет, тут не помощники. Мое мнение, что вы, как создатель CRM, должны запустить пару человек в организацию клиента, которые будут смотреть на бизнес изнутри, общаться с менеджерами, передовыми работниками и настоящими старожилами. И в таком случае, ваши сотрудники, путем сбора информации и наблюдения, смогут предложить какие бизнес — процедуры можно успешно автоматизировать, а какие — нет или лучше не автоматизировать.
А ваш поход — будьте благоразумны и не хотите того, что мы реализовать не сможем — нелогичен, потому что люди не знаю и не понимают что вы можете. Они специалисты в другой области. Когда среднестатистический человек приходит и просит построить ему компьютер в какой-то салон ПК, ему не говорят скажите нам точные ТТХ компьютера, вплоть до длины проводка от HDD до питания.
У него спрашивают для каких задач ему ПК, где будет использоваться и тд… И на основании этого говорят, что можно собрать, в какой конфигурации и как лучше…
Надеюсь, вы поняли мое сравнение.
ncix
И соглашусь и нет. Если вы "на берегу" не донесете Заказчику мысль, что для достижения результата понадобится работа и с его стороны, в какой-то момент ваших спецов начнут игнорировать, пропускать встречи, кормить завтраками. Проект начнет тормозить. Чтобы этого избежать в уставе проекта фиксируется рабочая группа, в том числе со стороны заказчика.
Чаще бывает наоборот. Заказчик начинает фонтанировать идеями, вы киваете, записываете и говорите "конечно-конечно". На выходе получаете вместо CRM некий CRM-ERP-ЦУП с невероятно усложненным функционалом, как следствие скверно работающий и вызывающий недовольство пользователей. Или вообще встреваете в токсичный проект без окончания. Границы проекта должны быть четко очерчены. Излишние фантазии заказчика нужно решительно пресекать. Особенно если уже зафиксированы стоимости и сроки. Говорить "нет" клиенту при внедрении и даже при продаже исключительно важно.
Axelus Автор
Вопрос, на самом деле нетривиальный и каждый раз должен решаться индивидуально в зависимости от особенностей заказчика. Главное, что нужно соблюсти, — это условие работы экспертов с экспертами и именно наличие фокус-группы со стороны заказчика, на которой можно проводить опытную эксплуатацию результатов внедрения. Эксперты со стороны заказчика — это в первую очередь высококвалифицированные специалисты, которые понимают задачи заказчика и способны их формулировать в общем плане. Эксперты со стороны внедренца — это опытные специалисты, досконально знающие технологии, которые планируется использовать для автоматизации, умеющие понять заказчика и сформулировать задание уже на техническом языке для разработчиков.
Когда речь идет о том, что нужно общаться с линейным персоналом, да, это безусловно необходимо, но лишь для того, чтобы выслушать людей, обобщить их пожелания в предпроектном документе и утвердить или отклонить/переформулировать их с экспертами заказчика. Линейный персонал не имеет решающего голоса, поскольку он не видит статегической задачи, но учитывать его мнение, тем не менее, необходимо, с этим я полностью согласен.