Как стать автором
Обновить

Комментарии 30

Всё так.
Дополню, что CRM задачи по зарегистрированным клиентам отлично решались в 1C Предприятие ещё почти 20 лет назад.
Чтобы не платить за ERP/недоERP, раньше можно было использовать OpenERP — прикрутить в неё интеграцию с первичными документами 1C, завести склад, CRM, прикрутить телефонию и почту. Как сейчас с odoo — не знаю, слышал, там много стали монетизировать в ущерб «на коленке хорошо и дёшево».
А Bitrix24 — это не CRM, это внутренний портал.
С odoo грустно — причём больше именно с точки зрения того, как её воспринимают те, кому в ней работать. Да и внедрение + «допил» там ну очень не простое. Я, наверное, про опенсорс и другие формы существования систем напишу отдельный пост, потому что это мне как инженеру ближе всяких там карточек клиентов и первички. Интереснее — точно.

Odoo офигенна в том плане что дает хороший каркас. Но она крайне трудоемка при переделывании под себя. Из коробки прекрасная crm. С полпинка работает интеграция с телефонией. Все отношения с клиентами ведем в ней по сей день. Недостатки: нет или кривые печатные формы для рсбу, интеграция с 1с ручками те нет. Отчеты пишем сами. Формы делаем сами. Трудоемко и криво, хотя я не программист почти. Хотя было написано около 50 тысяч строк кода, всё в итоге задвинуто в долгий ящик. Попыток внедрить было несколько, и в итоге я сейчас использую отраслевое решение на 1с для текущих заявок, для отношений с клиентами и потенциалом — одуу, бухгалтерия — 1с бухгалтерия и 1с отчетность. Такой зоопарк.

Можно узнать подробнее, почему с Odoo грустно?

Сейчас смотрю в сторону этой системы и любая информация полезна.

У меня в жизни было мало опыта с CRM'ами, но что я обнаружил за свой малый опыт: CRM используется для автоматизации отлаженных бизнес-процессов. У любого многолетнего бизнеса есть отлаженные бизнес-процессы. В чём же проблема?


В том, что есть бизнес-процесс, есть несколько участников бизнес-процесса, и у каждого участника бизнес-процесса есть кусочки процесса, которые важны ему. А так же есть кусочки, которые "не важны, т.к. касаются других".


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


А дальше… А дальше легко обнаруживается, что причина, почему гендиректор пушит "за CRM" состоит в том, что он хочет, чтобы туда записали его видение бизнес-процесса, а все остальные подчинились. В его представлении это и есть цель внедрения CRM — "навести порядок".


Ура, IT-отдел только что использовали в качестве тупого тяжёлого предмета в корпоративном срачике. Удачи общения с сейлзами.

почему гендиректор пушит «за CRM» состоит в том, что он хочет, чтобы туда записали его видение бизнес-процесса, а все остальные подчинились

Интересно, имеет ли перспективу децентрализированная CRM система, где каждый отдел будет настраивать свои процессы, а пересечения будут только на границах доменов?

Например, отдел по работе с клиентами выставляет контракт, в каком виде ему должны передаваться клиенты на обслуживание. Какие нужны поля, данные. Отдел продаж на свое усмотрение настраивает свои процессы, но в итоге должен отдать карточку клиента в требуемом формате в момент первой сделки. А как они ее соберут, — сделают лендинг на 18 полей, или будут узнавать, отправляя письма почтовыми голубями, уже их дело и ответственность

Это интересная идея. Нетривиальная, по этой причине сложная в реализации, но перспективная имхо

С заголовком на 100% согласен, с содержанием не так все очевидно. Моя личная боль в том, что CRM/ERP как правило проблемы клиента не решают, да, есть конструкторы крутые но ими никто и никогда не будет пользоваться, в остальных случаях вот эти вот проблемы решили — на эти забили, ну так это не работает.

Более того почтив се еще и сделаны как на коленке: интерфейс убог чуть более чем полностью, программная часть недалеко ушла. Вот у вас в списке амо — это CRM у которой я интерфейс окирпичу меньше чем за минуту, а глюки исчисляются сотнями, ну кмон…
Это обычные муки выбора.
Есть делема в таких выборах которая называется: Suite или Best of breed?
Ты либо выбираешь нечто универсальное, либо нечто узко специализированное.
У каждого подхода есть плюсы и минусы.

Бывало даже пытаешься разработать свое. Универсальное. Но там тоже фракталы и боли.

BPM & BPMN — это очень больная штука. Я в свое время наболелся и в итоге ушел в ACM (adaptive case management). По этой концепции работает AmoCRM, OmniDesk, FreeScout…
Это проще, гибче, легче.

В итоге я пришел к такой концепции:
1. Беру готовые best of breed без перегрузки функционала — типа AmoCRM, OmniDesk, GitHub…
2. Интегрирую их через IFTTT, Zapier или своими скриптами
3. На стыках процессов использую конструкторы типа Notion или Airtable.

Получается закрыть любые процессы. И при этом затраты на минималках.

Ну а в крупных бизнесах — многое пишется под себя. Но это очень рискованно, больно и дорого. Однако если все сделать хорошо, то бывает выгодно.
тут проблема не в выборе CRM/ERP
тут больше проблема в в том готова ли компания сломаться (если мягко сказать — перестроиться под покупную штуку) или готова написать своё, под свой бизнес, под свой процесс работы. Да, написать своё дорого(на первый взгляд), долго (почти на 100%).
но надо оценивать что такое дорого — купить готовое — 100%, что не охватит все варианты, нюансы работы конторы, следовательно придётся заказывать правки, изменения в купленное. что в конечном итоге приведёт к совершенно новой версии «купленного».
не менять купленное — есть риск порушить свой бизнес.
если есть понимание у руководства, то такое пишется своими руками своими прогерами (хорошо если есть среди них понимающие сам процесс ведения дел в конторе)
но это позволяет гибко подстраивать программное обеспечение под все изменения жизни, под все внешние и внутренние хотелки. И да, это не будет законченный продукт, это будет постоянно меняющийся продукт, но он будет отвечать всем потребностям конкретной конторы
(если только будут в штате обслуживания этого продукта адекватные прогеры (что не есть просто)) и понятие руководства что это не закончится никогда.

Я один считаю, что эта статья должна была начинаться со слов "мы решили внедрить CRM для того, чтобы решить %суть_проблемы%"? А то так прытко перешли к отсеиванию, что голова закружилась.


ЗЫ. "с требованиями у нас средненько: я выбивал их из них практически насильно. Зато я и мой босс чётко видели". Прям вот взаимоисключающие заявления.

«мы решили внедрить CRM для того, чтобы решить %суть_проблемы%»?
Вы правы. Я подумал, что Хабру не шибко интересны наши торговые процессы, поэтому сразу зациклился на софт. Наверное, в одном из постов раскрою эту тему (если будет о чём написать).
ЗЫ. «с требованиями у нас средненько: я выбивал их из них практически насильно. Зато я и мой босс чётко видели». Прям вот взаимоисключающие заявления.
Нет. Насаживать процессы строго сверху нельзя — ни в коем случае. Поэтому вот прямо сейчас ведётся работа по формализации требований конкретных сотрудников и отделов. Можно направить и упаковать в технологию, но процесс должен идти от холдера — это я уже просёк.

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


Не понимаю как вы с опытом сисадмина пытаетесь влезть в IT- консалтинг. Серьезно, это требует большого опыта в первую очередь в бизнесе.

Процессы и правда нельзя, но цели процесса и показатели их оценки вы обязаны дать сверху. Или с боку, если культура компании позволяет.
Я бы сказал, что CRM в первую очередь это процессы в компании. А конкретная система и ее адоптация под конкретные нужды, это вопрос вторичный.
Вооот, вот и вы клоните в сторону процессов — что изначально CRM было не свойственно. Вот теперь я пытаюсь раскопать, что делать с процессами, а заодно, — не стоит ли их поменять, косяков хватает. Проблема уже в пассивных участниках самих процессов — насадить что-то сверху не очень, по опыту знаю.
А вот тут вы совершаете классическую ошибку…

Мне пришлось учавствовать как в провальной попытке введения CRM, так и в очень успешной. И вот в чем суть:

Изначально, CRM это вообще не система, и даже не совсем процессы. CRM (Customer Relationships Management), это подход к управлению жизненным циклом клиента в компании. Успешная интеграция начинается с очень детального анализа что происходит с (потенциальным) клиентом с момента самого первого контакта с ним, и до того момента, когда он уже перестает быть клиентом (чего желательно избежать).

Для того, чтобы все клиенты получали одинаковый (в идеале — одинаково хороший) сервис, необходимо гарантировать, что все сотрудники будут вести себя одинаково (правильно) в одинаковых ситуациях. Таким образом клиент не должен будет подбирать время чтобы позвонить, чтобы «не нарваться» на кого-то, или наоборот, «поймать» конкретного менеджера, ибо «он/она единственный/ная кто разбирается...»
Так же, нужно гарантировать, что VIP клиент получит VIP обслуживание, даже если «нарвался» на кого-то, кто только вчера начал работать, и ничего не знает.
То же верно и для клиента, который по каким-то (заранее сформулированным) параметрам вдруг стал VIP, хотя еще вчера им не был.

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

После того, как процессы проработаны и всех удовлетворяют, можно задумываться о программном обеспечение. И тут цель не «изменить компанию под CRM систему», а наоборот — подобрать (и доработать) программный продукт CRM, для уже существующего «CRM подхода» в компании для обеспечения и автоматизации уже существующих процессов.

Вполне возможно, что из-за каких-то технических ограничений (или преимуществ) придется вносить корректировки в сами процессы, но это уже мелочи.

Согласен чуть больше чем на 146 процентов. Скажу больше — очень многие компании с 50+ офисов продаж и/или обслуживания начинают именно с процессов. Сначала какая-нибудь Cammunda, потом какая-нибудь CRM. Но, надо отдельно заметить, что у таких компаний есть ресурсы для всех этих внедрений, которых нет у малого бизнеса.

после прочтения приходит зыбкое понимание, почему все еще выжывают и множатся всякие BPMN конструкторы…
Не просто выживают, а цветут! К счастью, не везде BPMN, это лютая нотация, мне «посчастливилось» с ней поработать. По уровню с ними может сравниться только Pega BPM и ей подобные. Но это уже совсем не CRM, причём для больших. А мы маленькие :-)
Ув. автор, вы решаете не ту задачу.
Вам была поставлена цель «автоматизировать до зубов».
Почему-то Вы решили, что она достигается внедрением CRM, и начали тестировать продукты на соответствие определению из Википедии.
Абстрагируйтесь от калек (CRM, ERP, BPM), подбирайте систему для решения своих задач.
У Вас маленькая компания, по бюджету может быть только коробочное решение, под которое нужно будет подстраивать свои процессы.
Любая уникальность в таких масштабах — это просто бардак.

Если CRM будет внедрена до нормальной автоматизации бэка — это отличный способ сделать весь бардак внутри компании прозрачным для клиента. Это если вы не собираетесь оставить в CRM только воронку.

Согласен, что решений очень много, они весьма нагромождены, и лучшее для себя выбрать довольно трудно.


Вот насчёт AmoCRM и проблемы зоопарка плагинов не соглашусь – на позапрошлой работе была всего дюжина продажников+менеджеров, все сидели в Амо с кучей плагинов/аддонов, особенно для сохранения писем, СМС, звонков, ещё всякие плюшки, и это работает реально хорошо из коробки, один раз настроили и всё. Детальнее сказать не могу, я там был разрабом и аналитиком, просто дружил с менеджерами, но фидбек довольно позитивный.

не согласен с заголовком, в базе ты получаешь CRM если сильно не кастомизишь, а вот если сильно кастомизить, то много чего можно получить :)
вот если сильно кастомизить
в конечном итоге получится что-то конкретно своё, только написанное на «псевдо языке программирования» и поддерживать это могут не все, т.е. необходим определённый штат знатоков.
, Майкрософтовское решение хорошо выстраивается под любые задачи но это выстраивание, как выяснилось, требует больших денег, поскольку CRM/ERP универсальная для международных норм, а в России много специфики и, как следствие, доработок, за которые нужно платить партнёрским компаниям. Когда ты малый бизнес и осознаёшь масштаб, кажется, что тебя сейчас раздавят


Внедрил в компании меньше вашей. Тут не должно что то казаться, тут надо сказать партнёру что ты хочешь — тебе скажут стоимость твоих доработок.
Как выше писали — есть смысл менять компанию именно под софт чем софт под вас. Потому как любая программа — это чей то набор Бест практис, и врятли ваша компания — вот прям уникальная на белом свете. Скорее вы просто еще не прошли путь который прошли другие компании, и в последствии реализовали в софте.
есть смысл менять компанию именно под софт чем софт под вас. Потому как любая программа — это чей то набор Бест практис, и врятли ваша компания — вот прям уникальная на белом свете. Скорее вы просто еще не прошли путь который прошли другие компании, и в последствии реализовали в софте.
вот не скажи. у кого-то и бест, не факт, что у других это подойдёт…
вот проверено на своей шкуре…
очень давно начали писать для себя — долго сомневался, правильно или нет…
но в итоге — своё оказалось — своё намного удобнее, и намного эффективнее стороннего.
заопенсорсили?
нет. частные решения, частных задач.
продукт работал, но доводить до какого либо стороннего применения смысла не было.

Вы никогда не выберете, потому что систему надо выбирать не сисадмину или ИТшнику компании, а интегратору, компании или человеку, котрый будет внедрять это в бизнес процессы. По тексту ясно, что вы не он

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории