LINUX.ORG.RU
ФорумTalks

CRM и ERP не нужны, ибо не автоматизируют

 , , ,


0

1

Как некоторые из вас слышали, я уже некоторое время пытаюсь укусить локти и думаю, с какой стороны бы подступиться к нише CRM+ERP.

Существуют ли по-настоящему удобные системы совместного планирования и работы?
Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес

Последний тред
Поиски вдохновения и единомышленников
я создал в том числе потому что почувствовал, что исчерпал запас новой информации, но хронически не знаю, откуда его пополнить. Удивительно, но почему-то интернет скромно замалчивает эту сферу. К сожалению, имеющиеся у меня сведения позволяют сделать вывод: готовые CRM/ERP системы не нужны. Если клиенту нужно руками вводить информацию о клиенте, обновлять его статус и писать комментарии — это не автоматизированная связь с клиентами. Это тупо ручная система организации, поскольку незначительно отличается от создания бумажных карточек клиента от руки или на печатной машинке. «Оповещения» — это те карточки, которые коллега передал мне в отдельную стопочку.

Потому можно говорить о том, что какой-нибудь мегаплан или битрикс 24 — это, по большей части, системы организации ручного труда. Почему-то лицемерные продажники не любят слово «ручной» вместо этого применяют слово «автоматизированный».

«По большей части ручного» — потому что все таки есть некоторые элементы автоматизации. Например, слежение за времяпрепровождением сотрудников — пусть ввод и весь ручной, но сбор статистики о времени активности все-таки полуавтоматический. Или генерация PDF файлика по введенным оператором значениям — это тоже полуавтоматика. Конечно, когда я вижу, как оператор три минуты пялится в экран, чтобы распечатать мне чек по уже выполеннному заказу — это не автоматизированный процесс, а полуавтоматизированный. Так и хочется сказать «недоавтоматизированный». Но давайте здесь я еще больше не соглашусь сам с собой, потому что никому на самом деле не нужен PDF файл. Особенно сейчас, когда бизнес постепенно мигрирует в электронную нишу, и максимум что нужно печатать — это чек, хотя бы потому, что так требует законодательство. А вот если на печатаемом документе еще и нужно ставить подпись/печать — это уже лишняя и бессмысленная ручная работа оператора.

Самое труднодостижимое и самое полезное в автоматизации — когда оператор перестает замечать систему. Когда руководитель вводит в компьютер «сделать трактор», а система находит нужных свободных сотрудников, ставит им задачи со сроками, резервирует детали, заготовки, инструмент на складах и заказывает недостающее. Это то, для чего изначально вообще задумывалось ERP. К сожалению, в реальном мире возникают несостыковки, брак, работник заболел/его сбил автобус, технология изменилась, склад замело снегом. Если довести эти факторы до абсурда, то получится система планирования в рамках страны, в которой форс мажоров настолько много, что планирование со сколь бы то ни было приемлимой точностью просто невозможно.

Проблемы автоматизации, как правило, находится на стыке некоторых механизмов, например: поступил звонок от клиента — передать клиента его привычному менеджеру или первому свободному, если привычный занят. Здесь есть две точки сопряжения: распознание номера телефона и определение факта доступности менеджера. Если их не проработать, то от автоматизации не остается и следа. И если у нас в системе есть N программ/механизмов, то задача их сопряжения имеет сложность O(N^2), то есть, сопрягать N механизмов с N(-1) механизмами. Отсюда вывод: плодить программы значительно проще, чем потом лепить из них единую автоматизированную систему.

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

А что же тогда продают упомянутые мегаплан, битрикс, ну и в конце-концов SAP с Oracle? Как правило, они продают число модулей, табличек, вкладочек, рюшечек на страничках. Это свойство, которое точно противоположно автоматизированности системы — незаметности модулей, которые должен видеть только админ и которые просто тихо незаметно работают. Таким образом, когда вы внедряете эти готовые программы на предприятии, вы прежде всего ВНЕДРЯЕТЕ ПРОБЛЕМУ, а потом уже ищете ей решение. Так и вижу лозунги «Битрикс 24 — лучшая проблема для вашего бизнеса», «BMW е$@^!я с SAP», «SAP — ready when you are» (вольный перевод: «SAP — будет готова как только вы подготовитесь к ней»). Последнее, между прочим, настоящий рекламный слоган, который иронично отражает сложность внедрения SAP на предприятии — а у SAP накопился богатый опыт провалов внедрений.

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

Но я, все-таки, подходил к вопросу со стороны «чему можно научиться у этих систем? Как можно сделать их лучше, можно ли улучшить интерфейс и реализацию, чтобы по итогу получить конкурентное преимущество и оттяпать у них рыночек». А парадокс решения в том, что чем тоньше ваша система, тем проще она поддается автоматизации. Чем проще ваша БД, тем удобнее её адаптировать под нужды бизнеса. По этой причине SAP является самой-присамой неудобной базой для автоматизации на рынке.

Специалист по UX, Голден Кришна, написал целую книгу на схожую тему «Хороший интерфейс — невидимый интерфейс». Один из ключевых тезисов книги — нынче модно лепить планшеты куда ни попадя, хотя они делают устройство не проще, а сложнее. Именно это делают мегаплан-битрикс-SAP-Oracle — удовлетворяют потребность налепить китайский планшет на ваш бизнес (на удивление, довольно популярную потребность), превратив хорошо налаженное и много лет работающее предприятие в сиамского близнеца с четырьмя ногами. Мол «ваш бизнес приобрел больше ног, и теперь может ходить в два раза эффективнее». В тему планшетов/смартфонов они вам скажут «зато у нас есть готовые мобильные версии, удобно вне офиса ткнуть в смартфон и посмотреть список дел и сообщений». Я с удивлением обнаружил более одного человека, который занимается планированием не на компьютере и не на смартфоне, а тупо в бумажной тетрадке. Потому что бумажную тетрадку можно носить с собой и пользовательский интерфейс у нее заметно удобнее смартфона. К тому же, тетрадка не разобьется при падении на асфальт.

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

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

Да-я-занимаюсь-онанизмом-thread

★★★★
Ответ на: комментарий от Shadow

Все бизнес-решения принимаются не на онлайн данных, а хотя бы на суточных «срезах». ниже поясню

Ты меняешь причину со следствием: OLAP ПРИХОДИТСЯ делать по тухлому срезу, потому что иначе его никак не сделать.

ПОтому что 1С - это система проводок поверх РСУБД. Максимум, что там может облегчить жизнь - это создание регистра со срезами как «витрины данных» для анализа. Также можно делать суточные отчёты-выгрузки в какой-нибудь OLAP.
У меня был именно такой опыт, общее число номенклатурных позиций было > 100 000

Да, ETL для OLAP — это классика жанра костылестроения для РСУБД. Но если тебе нужны из онлайна свежие данные по сложным сущностям — никакой ETL тебе не поможет. Например «найти записи, ассоциированные с последними добавленными по нечеткому критерию».

общим обьемом около 50-80 тысяч позиций. Наименования нестандартизированы.

- и чтобы специальные люди вручную за ними следили. Ничего не поделать

Расчет цен идет достаточно противный — у каждой позиции есть несколько входящих цен

Нужно чётко прописать, как движется товар по организации. Иногда на одно подразделение нужно держать несколько виртуальных складов и не лениться по ним двигать товар

А складу похеру, что тебя не устраивают его наименования. Какой твой следующий ход?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

А складу похеру, что тебя не устраивают его наименования. Какой твой следующий ход?

Я хз, всегда убеждал собственников/генеральных/руководителей закупок. В итоге несогласные соглашались.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от byko3y

Например «найти записи, ассоциированные с последними добавленными по нечеткому критерию».

Это очень больная на всю голову хотелка, не должна выполняться онлайн, и вообще никак её гипотетическая реализация не повлияет на результативность торговой компании.

Да, иногда есть варианты (у оракла были), когда из почти сырого зранилища можно «повертеть» разной размерности данные с бесконечной глубиной... Но практика показала, что это дорого и почти никому не нужно.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от byko3y

Например «найти записи, ассоциированные с последними добавленными по нечеткому критерию».

Нечёткие критерии на каком-то уровне должны стать чёткими критериями.
Может дело в том, что у системы уродский язык запросов, вот сколько я не сталкиваюсь со встроенными в приложения БД, например историей браузера, или программой поиска файлов в ОС, всё их язык запросов убог в принципе, ни как не выдерживая сравнения с языком запросов в линуксовой консоли(grep,sort,uniq).
И уж тем более он не выдерживает сравнения с представлениями о том, что в таком языке ожидаешь найти.

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

torvn77 ★★★★★
()
Ответ на: комментарий от Shadow

Это очень больная на всю голову хотелка, не должна выполняться онлайн, и вообще никак её гипотетическая реализация не повлияет на результативность торговой компании

«Не стоит прогибаться под изменчивый мир — пусть лучше он прогнётся под нас». Если покупателю нужно предложить альтернативу прямо сейчас и только из того, что доступно — то вполне себе влияет, и следующей итерации ETL никто ждать не будет.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от torvn77

Более того, развитый язык есть только у онлайнпоисковиков, но там этот язык стараются спрятать подальше чтобы о нём знало как можно меньше народу, хотя вроде бы более точные запросы должны снижат нагрузку на сервер

99% пользователей поисковиков просто не пользуются этим языком. Даже я почти не пользуюсь, потому что поисковик и так находит то, что мне нужно. Например, конкретизация результатов по одному сайту в том же гугле делается мышкой без необходимости знания языка запросов. Это повышает нагрузку на сервера, но незначительно — благодаря их мудрому устройству.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

покупателю нужно предложить альтернативу

У нас в справочнике была связь один-ко-многим на каждую позицию.
Сорри, если «закупец» не сделал связи на номенклатуру, его нещадно лишали премиальной части.

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

Сорри, если «закупец» не сделал связи на номенклатуру, его нещадно лишали премиальной части

Сижу тут и думаю: автоматизация — такая автоматизация... Мне вспоминаются те светлые годы, когда юникс представлял из себя дырявый друшлаг, через который удаленно не исполнял код только ленивый. Какое решение приняли светлые умы? Сделать сервисы юникса более надежными? Нет — ввели закон, чтобы наказывать людей, взламывающих друшлаги. То есть, «лишить премиальной части».

byko3y ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.