Представьте себе следующую ситуацию: вы работаете в отделе продаж и вам поступает заявка на 150+ позиций какой-либо продукции из более или менее схожих категорий (например металлорежущий инструмент).
Скорее всего у вас уже есть десяток другой прайс-листов от ваших поставщиков, в каждом из которых возможно по 10 000 + позиций, и вы конечно хотите дать клиенту самое конкурентоспособное предложение.
Будет совершенно логично предположить, что с очень большой вероятностью, один и тот же товар у разных поставщиков может стоить по разному, а другой товар возможно будет вообще только у одного поставщика.
Получается, чтобы сделать лучшее предложение клиенту вам следует заняться поиском каждой позиции последовательно у всех поставщиков по ряду критериев (например найти самое дешевое предложение или предложение с подходящим количеством на складе).
Но есть один нюанс — так как все прайс-листы составляют разные люди, то почти в 80% случаев один и тот же товар они назовут хоть немного, но по разному.
Рисунок 1 — Разные варианта названий свёрел
Так что, если каждому товару не присвоен свой уникальный и общепринятый идентификатор во всех прайс-листах и во всех запросах от клиентов, то просто так использовать функцию ВПР и даже Lookup, к сожалению не получится, и вам, как бы это не было грустно, придется заниматься долгой и не очень интересной работой, которая затянется может на день, а может и на все два.
Начало
Когда я пришел на работу в отдел продаж одного российского завода — изготовителя металлорежущего инструмента, оказалось такие заявки приходят не по одному разу в день и чем быстрее клиент получает ответ, тем выше вероятность, что произойдет продажа.
И вот мне, как новенькому приносят пачку листов А4 на которых 11 шрифтом распечатана заявка из 1000+ позиций, а рядом подписаны цены ручкой (!). Да еще, около каждой указано с НДС она или без.
Как мне сказали — самое сложное уже сделали за меня, так что остается всего лишь перенести без ошибок 1000+ цен в электронный вид и выставить счет.
И вправду, “Совсем не трудно!” — подумал я, и начал бить по клавишам нумпада.
Спустя 25 минут монотонной работы и разглядывания не всегда понятного, в данном случае — женского почерка, я вдруг подумал: “Что — то здесь не так. Так быть точно не должно!”
Чтобы понять почему так не должно быть, и как быть должно на самом деле, я решил взглянуть на весь процесс поэтапно, и расспросив коллег, узнал о том как все устроено:
- Заявка приходит по почте, обычно в формате .xls
- Ее распечатывают и отдают в отдел снабжения.
- Там милая девушка внимательно его изучает, открывает на мониторе необходимые прайсы и начинает подбирать.
Она примерно знает что и в каких прайс-листах искать и где скорее всего дешевле, но как бы хорошо она не ориентировалась во всем этом, за более чем 10 летний опыт ей не удалось бы выучить наизусть даже сотни цен на самые популярные позиции, хотя бы потому что они меняются как минимум раз в год. - Спустя пару дней, а иногда недель, заполненная таблица попадает в руки менеджера по продажам, то есть в мои. И начинается та самая работа, которой я только что занимался.
- Я выставляю счет, радостный звоню заказчику что бы об этом сообщить, а он мне в ответ:
“Большое спасибо за предложение, но я уже оплатил счет, который мне выставила другая компания два дня назад.”
Страшнее слов не придумаешь. Хорошо что моя коллега из отдела снабжения не слышала — подумал я, и начал размышлять как устроить этот процесс так, чтобы глаза и руки сразу двух человек не стирались до мазолей, ещё и с нулевым результатом в итоге.
Следующую заявку мне дали обрабатывать уже самому. Я сделал тоже самое что и моя коллега, но электронную таблицу уже не распечатывал, а открыл в левой половине экрана, разместив в правой три нужных прайс-листа.
Начав с первой позиции, я нашел её во всех трех прайсах и скопировал ячейку с самой выгодной ценой в столбец справа. Повторив действие n раз, возникло ощущение, что я знаю как сделать эту работу в сотню раз быстрее!
Решение
Я подумал — Нужно просто свести все прайс-листы в одну большую таблицу, а в ячейку справа от позиции запроса сразу вывести самую лучшую цену, а рядом для проверки вывести название это самой позиции с лучшей ценой.
Отлично! В тот же вечер, я приступил к работе.
Вся проблема заключалась в том, чтобы объяснить системе какая позиция подходящая, а какая нет…
К этому моменту у меня был опыт создания системы на чистых формулах в Excel, которая берет названия товаров одежды на английском языке и переводит их в однотипные названия на русском.
Она определяет категорию, цвет, пол, бренд и т.д. и работает так: если в названии есть слово hat, то в русском названии появляется слово “шапка”, дальше если есть yellow или yell (некоторые писали так) — получаем название “желтая шапка”, тоже самое с остальными словами и в итоге получаем название — “Желтая мужская шапка Ski-doo”.
Тоже самое делается и с описанием, а потом загружается в интернет магазин. Таким образом, я с 90% точностью обрабатывал тысячи товаров. Основываясь на этом, я и начал работу над новой системой.
Первое что мне требовалось — это определение категории, например если в названии есть “Сверло” или ”сверла”, то присваивается категория “Сверло”, а дальше начинается определение его параметров.
Если слово “Сверло” было чаще всего написано в одном из 5 вариантов (Сверло, сверло, сверла, сверл., Свёрла), то параметры этого сверла каждый писал в меру своей компетентности, как на рисунке 1.
Следующий и самый сложный шаг — определить и привести к одному виду эти самые категории для каждой позиции.
Сделать это я решил с помощью регулярных выражений. Но как написать такое выражение, которое охватит максимум вариаций записи характеристик? Конечно одним выражением не обойтись, и для ускорения работы нужно понять какие структуры описания характеристик используют чаще всего, и охватить их в первую очередь.
Так как я знал, что мне придется делать тоже самое еще для десятка другого категорий, решил сразу это автоматизировать и занялся системой выявления наиболее часто используемых шаблонов в описании товаров.
Это тянет на отдельную статью, поэтому сразу опишу что получилось:
10 регулярных выражений, которые определяют от 1 до 5 цифровых параметров.
3 выражения, определяющих ГОСТ.
Остальные параметры, такие как марка металла или форма хвостовика, определял простым условием содержания текста в названии.
В итоге получилось 10 характеристик.
Я сразу провел первый тест, на сверлах и все сработало! я получил готовый список с типовым описанием всех позиций в прайс-листах.
Рисунок 2 — Типовое описание
Дальше сделал тоже самое для запроса — привел названия к типовому виду. Теперь, осталось только воспользоваться старым добрым ВПР, и вот спустя пару секунд у меня есть готовый список с самыми лучшими ценами и изначальными названиями подобранных позиций. Кроме этого у меня сразу была информация кто поставщик и сколько есть позиций на складе. Это полезно, в случае если случится продажа — я не забуду где какие цены взял.
Это был только первый шаг.
Так как у каждой категории свои характеристики, то для каждой нужен и свой шаблон их поиска. Потратив пару дней, я составил таблицу с шаблонами для 8 основных категорий, и смог правильно определить примерно 70% позиций. Но даже с такой точностью, я смог обрабатывать большинство заявок не только быстрее коллег, но и быстрее всех конкурентов.
Как только это увидели в отделе, все заявки полились рекой ко мне на проработку, и стало ясно — либо я поделюсь системой со всеми, либо вернусь к тому от чего хотел уйти — погрязну в монотонной работе.
Так как система работала на Excel и макросах и содержала ~100 000 позиций, то на ежедневное обновление уходило около 40 минут и при этом работать в таблицах было невозможно. Так что устанавливать один и тот же файл на каждый компьютер, я решил даже и не пытаться, не говоря уже о том, что исправлять ошибки и вносить изменения в систему пришлось бы у каждого пользователя отдельно. Нужно было быстро искать подходящий, легкий для переноса системы вариант, и я решил попробовал Google spreadsheets. Это должно было решить ряд проблем:
Все прайс-листы будут сводиться и обновляются в облаке по расписанию и к ним будут имеют доступ все пользователи.
Работать можно будет из любого места где есть интернет, хоть со смартфона.
Модернизировать и исправлять систему я смогу хоть откуда и сразу для всех пользователей.
В начале, я попробовал сделать все на таких же формулах, но когда таблица из 100 позиций обрабатывалась уже 3 минуты, я понял что от формул придется отказаться, и начал изучать документацию Google app script (gas) — это тот же js, только с добавлением функций от гугла.
После переноса всей логики в gas, я обнаружил следующую проблему: если в запросе была описана только одна характеристика, например только диаметр сверла, то в большинстве прайсов были диаметр х длина, а так как система определяет максимум параметров, то в выборе участвуют только позиции в которых количество описанных характеристик совпадает с их количеством в запросе. Это серьезная недоработка и ее нужно было исправлять.
Здесь я снова воспользовался регулярными выражениями и каждую строку из запроса которую только что преобразовал в строку с типовыми характеристиками, я превратил в регулярное выражение, где отсутствующая характеристика ‘*’ заменялась на ‘.*?’ и означала что система при поиске пропустит эту характеристику и перейдет к следующей.
Но здесь я столкнулся с новой проблемой — не всегда нужно выбрать именно самую недорогую позицию, иногда нужно выбрать самое длинное или короткое сверло, посмотреть какие вообще есть сверла с заданным диаметром, или у кого их больше всего на складе.
Здесь решение оказалось проще — делаю проход по всем строкам, собираю подходящие под шаблон позиции и вывожу их в выпадающий список, с указанием всей информации.
Рабочий лист теперь выглядит так:
Рисунок 3 — Лист для сопоставления заявки и прайсов
В первый столбец вставляется целиком запрос в табличном виде, во второй количество. В третий столбец автоматически попадают типизированные описания. В четвертом столбце в каждую строку добавляется раскрывающийся список из всех подходящих позиций, которые удалось найти системе, по умолчанию сортируются по возрастанию цены, но если нужно, можно переключить на сортировку по количеству на складе или поставщику.
Теперь осталось самое последнее — выставить счет. Для этого в столбцах справа формируется шаблон, который можно быстро загрузить в 1С:
Рисунок 4 — шаблон для загрузки в 1С
Шаблон содержит в себе исчерпывающую информацию — поставщика с его артикулом по позиции, название, количество, и цену. Отсюда же можно отправлять запросы на счета разным поставщикам, или создавать счет не заходя в 1С, кому как нужно.
Итог:
Обрабатывать заявки стали ~ в 20 раз быстрее (30 минут вместо 1 дня на заявку из 100 позиций), подбор по оптимальным ценам стал в разы эффективнее, так как теперь нет проблемы что кому-то лень перебирать все прайсы или делать запросы по всем поставщикам.
Планы на будущее:
Научиться использовать и перевести массивные вычисления на google engine, большие таблицы перевести в big data, а для быстрого выявления шаблонов написать нейросеть. Так что буду очень признателен, если кто-то поделится опытом об их использовании в комментариях.
Послесловие:
В процессе работы были написаны десятки полезных функций, которые могут быть полезными многим, кто уже работает в gas, и даже тем кто только собирается. Например: автоматическая загрузка файлов из Gmail или по ссылке на Gdrive и преобразование их в формат google таблиц, поиск и копирование строк из файлов на диске по слову в названии, и так далее. Их буду публиковать в следующих статьях.
В случае интереса к этой статье, подробнее опишу работу программы со вставками кода.
Спасибо за прочтение.
Комментарии (138)
erwins22
04.02.2018 18:57Подобно, я показал как секретарю работать в ворде и ускорил ее работу в 10 раз.
1С: УТ (КА или ERP)
berezuev
04.02.2018 18:59+1Следующим этапом можно будет выгнать 90% продажников, ибо 10% будут справляться со всеми заказами.
А вообще, день на обработку заказа — это ад. И если начальство никак это не пытались это исправить, значит в компании что-то не так.
opetrenko
05.02.2018 06:08Наборот, продажники теперь могут заняться продажами. От мосигры есть хорошие статьи о том, что продажник — не робот выдающий.
Интересно, как поменялась жизнь продажников на заводе автора?
mgremlin
04.02.2018 19:11Это выглядит неплохо для форума по маркетингу. Если никто на этом форуме в маркетинге не понимает примерно ничего. В формате Хабра это просто несерьезно… Вы действительно собираетесь здесь формулы excel обсуждать? Вообще-то, для подобных целей человечество придумало базы данных.
Единственное, что в этом опыте было бы сколько-то интересным — это merge, алгоритм признания внешне разных товаров одинаковыми. И — sic! — механизмы обработки ошибок, в том числе — false positive. Но вот именно об этом не написано ничего…
А 30 минут — это совершенно не достижение. Должно вообще клиенту в реальном времени цены отдавать.
Примеров — горы, часто разговор о десятках и сотнях миллионов позиций, и обрабатывают это вовсе не суперкомпьютеры, а как бы не VPS за 5 баксов в месяц.slonpts
05.02.2018 08:11+3По-моему, статья скорее про то, как с помощью имеющихся ресурсов за короткое время сделано существенное улучшение.
Потому что правильную систему надо покупать/разрабатывать и внедрять, это много времени и денег — а руководство может и не выделить столько. А когда уже есть существенное улучшение и пользователи его с руками отрывают, то и деньги легче найдутся, и внедрять легче будет.mgremlin
05.02.2018 08:23Нет проблем. но это никак не может быть темой для статьи на профессиональном ресурсе. Как выше справедливо написали — обучил бы девочку документы в ворде печатать, а не писать от руки — это тоже стало бы очень существенным улучшением, только вот тема такая для хабра не подходит никак.
artmmslv
05.02.2018 10:57Есть техника сложная, есть простая. У сложной техники цена высокая, у простой — низкая. У простой техники есть свои преимущества. И писать про простую технику сюда считаю правильным.
mgremlin
05.02.2018 11:20Я на 146% уверен, что сделать (если не умеешь сам — нанять за копейки фрила) нормальный вариант — с бд и простейшей мордой хоть на PHP, было бы дешевле, быстрее, результат был бы более поддерживаемым, работало бы все мгновенно, а не 30 минут и пр, пр, пр.
AmberSP
05.02.2018 14:25Результат труда фрилансера за 3 копейки — быстрее и надёжнее? И легко поддерживать?
Всё же не соглашусь. Формулы и «администрирование» тиражного продукта поддерживать гораздо проще и работает это гораздо надёжней, чем наколенная поделка Васи.mgremlin
05.02.2018 14:38Да. Безусловно. простой пример: достаточно в любом прайсе допустить ошибку (или как-нибудь криво изменить название) — и все, надо править регулярки и формулы. Понятно же, что на любую регулярку можно найти false positive, да?
В то время как простейшая поделка, разбивающая описание на токены и сравнивающая расстояние, скорее всего будет и дальше работать с каменным лицом.
В 1000 раз быстрее.AmberSP
05.02.2018 15:05Нас рассудит только двухлетний эксперимент по эксплуатации двух вариантов в схожих организациях. Всё остальное — бессмысленный разговор.
c4boomb
05.02.2018 15:19Вы программист, который не понимает клиентов.
Пожелаю вам удачи, прийти к руководству завода и предложить заказать PHP script на freelance у никому неизвестного исполнителя.mgremlin
05.02.2018 15:34Спасибо за комплимент. Если б написали еще и «молодой программист» — я был бы совсем счастлив.
К руководству завода с похожими предложениями я впервые пришел в 89 году. Но годы летят, и вот уже лет 25 с идеями к руководству не хожу.
Но, чувствую, стоит начать! 8-)
А вы всерьез считаете, что пользоваться невнятными скриптами продажника — это круче? И у руководства — если что — найдет большую поддержку?
Вы никогда не видели сайтов заводов, сделанных фрилансерами? У них, наверное, инициативного продажника не нашлось, ага.
А главное — нам всем очень не хватает их опыта тут, на хабре. И не дай Бог, хоть строчку кода напишут! Или формулу хоть одну! так и надо: «я сбацал очень клевый сайт. Но код не покажу, адрес не дам, про структуру ни слова. Но пасаран.»c4boomb
05.02.2018 15:53Моя позиция в этом вопросе — не связываться с заводами )
mgremlin
05.02.2018 16:08А я вот, наоборот — призадумался. Это ж какое поле для деятельности!
Кроме шуток, ситуация абсолютно аналогична той, с которой я начинал 30 лет назад! Ну задачи чуток другие были, заовд оборонный, клиентов на стороне нет, но метода та же самая: бланки, их ручкой заполняют, переписывают из других бланков, ошибаются, «крыжат», «сводят» — и буквально любое телодвижение в сторону автоматизации ускоряет дело в какое-то невероятное количество раз.
Как-то странно думать, что рынок для таких экзерсисов есть и сейчас 8-)
А ведь была у меня когда-то (активно воруемая) программка автоматизированной обработки прайсов на Access95, емнип… Этакая мельница: что ни кинь — выйдет мука заданного сорта. Но бросил лет 15 назад, подумал — нет рынка, уж теперь-то у всех этот вопрос решен. Оказывается — нет!DMGarikk
05.02.2018 16:21Но бросил лет 15 назад, подумал — нет рынка, уж теперь-то у всех этот вопрос решен. Оказывается — нет!
рынок есть, но как вы думаете сколько вам готовы заплатить за такую автоматизацию?mgremlin
05.02.2018 17:42Это так не оценить.
Если речь про публичный сервис-автомат, то это будет недорого, поскольку потребляемые ресурсы незначительны. Но можно брать массой.
А сколько готов заплатить бизнес — тут все зависит от того, есть ли сейчас хоть один конкурент, который всех делает как детей одним фактом мгновенной проценки и отгрузки. Как только хоть один такой вариант у покупателей появится, так сразу же сознание владельцев конкурентов начнет вмещать очень существенные суммы 8-) Вплоть до сотен тыр разово + помесячное обслуживание.DMGarikk
06.02.2018 00:55в большинстве случаев анрил, если они в 18 году до этого еще не дошли то проблема уже структурная
внедрение даже подобной системы это десятки человекочасов с боем с сопротивляющимся отделом, а «очень дорого» (с)mgremlin
06.02.2018 09:01понятно, что структурная. Но я такое видел не раз. подобные «взлеты с BC в XVI век» делаются сверху. Просто придет новый начальник, ужаснется, и создаст группу рядом. Там ведь много народу не надо… и как только новая заработает — старых разгонят.
Да, есть сложные процессы, которые действительно долго, дорого и сложно автоматизировать. Но — не этот.DMGarikk
06.02.2018 15:03Просто придет новый начальник
вот это тут самое главное
другое дело что нормальный начальник в 18 году будет нормальную ERP внедрять, а не костылики вместо экселя строитьmgremlin
06.02.2018 15:23Внедрять? Нет. Он будет ныть, на ковре у правления, например, или совдире. А внедрять будет IT + интегратор, когда/если решение окажется положительным. Сильно потом, и совсем не то, что продажникам надо. И легко может оказаться, что автоматизируют все, кроме вот этого тупого перемалывания прайсов, потому как в коробке его нет, надо дописать коннектор, а подрядчик тупит, а когда выкатит — работает не так, а потом формат поменяется и вообще все надо будет переделывать… так и живем на экселе 8-)
Так что, вариант покупки сервиса за 300-500-999р/рабочее место/месяц — своей властью, внутри отдельского бюджета — выглядит вполне жизненным.DMGarikk
06.02.2018 17:54А внедрять будет IT + интегратор
без начальника, IT + интегратор ничего не внедрят, к томуже я представляю себе ИТ отдел завода, три Василия с зарплатой 5000р вешающих сопли на свичах из магазина
тут как раз проблема в начальнике как источнике движущей силы этого процесса, выбить бюджет+тащить интеграцию
Интегратору то пофиг, ему бабла заплатили, а на территорию не пустили он и уехал… как внедрять месяцами можно
Мы тут в одной конторе элементарный EDI для выгрузки счетовфактур внедряли два года тупо потому что всем какбы-ответственным наплевать с высокой колокольни… при этом бабло было заплачено за весь процесс
apapacy
06.02.2018 16:31Нормальную это какую? Как начальник распознает нормальную? Как поймет что внедренцы адекватные?.. Тут уже сейчас как минимум два внедренца, которые вообще не собираются вникать в суть проблемы а пишут радужные посты типа это все уже решено до Вас остается только пригласить нас.
igorsmi
05.02.2018 10:57Статья в топе на первом месте, значит многим это интересно. Так что не нужно делать выводы за весь хабр о том, что данная статья для него это не серьёзно.
mgremlin
05.02.2018 11:18Дык! Тема мне тоже интересна — я тоже зашел.
Другое дело, что даже беглый взгляд привел к разочарованию…
А минусы ставить я не люблю — человек все же старался.
Вот и топ…apapacy
05.02.2018 11:33Не но плюсы тоже есть у статьи. И много.
mgremlin
05.02.2018 11:47+1Да, я тоже удивился.
Но вот серьезно: неужели хоть кто-нибудь, претендующий на какой-то минимальный профессионализм в IT, мог найти в этой статье хоть что-то новое для себя?apapacy
05.02.2018 12:15В постановке задачи есть надчем подумать. Очень часто программные продукты рассчитаныина некие идеальные условия которые существуют только в головах разработчиков. Особенно это касается производства. Где большая номенклатура продукции и применяемых материалов.
mgremlin
05.02.2018 12:26И где тут постановка задачи?
Больше того: уверен, что доля ручного труда осталась немалой, личное участие автора для функционирования системы необходимо, вероятность ошибок велика, и они обрабатываются примерно никак.
Я б тоже с удовольствием почитал не про реализацию неизвестно чего на уровне курсача техникума, а про теорию. Поскольку сам занимался этим вопросом в свое время, и точно знаю, что тогда на 100% задачу не решил 8-)
Простой вопрос: что делать с позициями, которые ни в одну из регулярок не провалились? Хоть какой-то список на review выдается? А его кто-нибудь когда-нибудь смотрит? 8-)
Что, если на каком-нибудь заводе перепутают колонки с ценой и количеством? Или убьют кодировку? Или формат числа в колонке цены? или случайно поставят себе курс 1$=3 рубля? Так вот и будут всем счета выставлять по 3 рубля рублями, да?
Вот если бы статья была про это — я б тоже поставил плюс. А кто их ставит сейчас — представления не имею.apapacy
05.02.2018 12:34Постановка примерно такая. Есть заявки в форме электронных писем, факсов, текста, pdf, сканов документов. И есть кроме своих столько же прайсов поставщиков в такой же форме. Необходимо однозначно сопоставить цены в прайсах с номенклатурой заявок.
mgremlin
05.02.2018 14:32Это цель. А задача, которая тут решалась — окучить исходные данные и подготовить их к максимально быстрой обработке. Кстати, с большой вероятностью, решение этой задачи позволит примерно так же обрабатывать и входящие блоки — там тоже наверняка черт ногу сломит.
MockBeard
05.02.2018 14:47отличный пример, как решение собранное на коленке сильно облегчает жизнь людей без внедрения тяжелых решений. коэффициент Цена/Качество просто зашкаливает ))
lexmirnov
05.02.2018 15:22Решение офигенное по КПД — с минимальными затратами реализован функционал, приносящий прибыль.
mgremlin
05.02.2018 15:52А точнее — не приносящий столько убытков.
Завтра появится примитивный стартап, обсчитывающий любой запрос в онлайне, безгеморно отгружающий и тп — и все подобные формулы будут списаны в утиль.
Серьезно говорю, я такое видел не раз.
У меня недавно перед глазами прожект прошел про радиодетали — так там конкуренты миллисекундами меряются. А базы колоссальные, сотни миллионов позиций. Уверяю вас, никто суперкомпьютерами не пользуется 8-) так, впски по 500р в месяц. А вот расстояние в ДЦ играет реальную роль, прямо и недвусмысленно отражаясь на продажах.Komrus
05.02.2018 19:20Где колоссальные базы — там прайсы от производителей тоже (как и в описываемом автором статьи случае) идут в виде случайным образом форматированных xls файлов? :)
Или всё-таки через API отдаются?mgremlin
05.02.2018 20:12Вот чего не знаю — того не знаю. Я видел уже готовые базы.
Хотя, зная modus operandi китайских производителей (а радиодетали — они же все из китая, да?), могу предположить, что случайно форматированные xls-файлы — это только у самых культурных. А наверняка найдутся и те, кто только по телефону прайс озвучивает 8-) ну или могут сканы в pdf прислать.
Но у людей там в любом случае есть проблема ровно того же порядка: надо помэпить пользовательский запрос (который, ясно, может быть любым) на имеющуюся номенклатуру. И сделать это не за 30 минут, а за десятки msec, максимум — сотни. Если больше — пролет.
NeverIn
04.02.2018 19:19+6Вы существенно улучшили техпроцесс компании, отразилось ли это материально на вас и коллегах? Оценил ли это работодатель премией, или допустим вы стали эффективнее и поэтому ваш доход стал выше?
AndreySaha
04.02.2018 20:30во-первых, наверное, стало проще работать, во-вторых, опыт. выводы насчет работодателя уже всем понятны, а возможно и оценили каким-либо образом
gazdovsky Автор
04.02.2018 20:50Материально, конечно отразилось — выросла выручка всего отдела, а за ней и ежемесячная премия
Platon_msk
04.02.2018 20:12Нейросети и регулярки, это круто. Наверно.
Но лет 15 назад у меня была задача сопоставления наименований товарных позиций различных поставщиков. Я не знал про нейросети тогда, поэтому вынужден был применить нечёткий поиск. N-граммы работали на ура, выдавая подобные наименования, отсортированные по степени близости к исходному. Не в Excel, конечно, но в Access это работало на ура.
ArVaganov
04.02.2018 23:31Алгоритмы на основе триграм, levenshtein distance или match against бд вероятнее всего, будут эффективнее чем 10 регулярок, упомянутых, но почему-то не присутствующих в статье. Я не специалист по нейросетям, можете пояснить, они подходят для такого рода задач?
Platon_msk
05.02.2018 00:05На самом деле в моём комментарии присутствует огромная доля сарказма. Математика триграмм ничтожна по отношению к регуляркам, а тем более нейросетям. Микроскоп и гвозди, это вещи, которые нужно хранить и применять по отдельности.
justhabrauser
04.02.2018 21:09+1Возможно такое ускорение связано с тем, что с помощью новой системы продажники и/или снабженцы стали в 20 раз быстрее получать свои «законные» откаты.
В таком ракурсе Вы не рассматривали?
Louie
04.02.2018 22:38Я не из робкого десятка, но читать жутковато. Представил, как разверзлась земля — а оттуда голос: «Нужно просто свести все прайс-листы в одну большую таблицу» и демонический смех.
Это тянет на отдельную статью, кстати
SbWereWolf
04.02.2018 22:42+2с одной стороны отличное решение в стиле спасение утопающих — дело рук сами утопающих, с другой стороны рассказывать программистам, знакомым с СУБД, о программировании под Excel это как то не очень.
Но с точки зрения эффективности — затрат рабочего времени (стоимости рабочего времени) в отношении к полезному эффекту — очень крутое решение, если бы эту задачу решал программист, то обошлось бы в разы дороже.vics001
05.02.2018 02:54Постоянно пользуюсь Excel для прототипов. Пишу рекурсивные функции, строю графики, проверяю ошибки. Особенно в задачах моделирования и симуляции, абсолютно необходимый инструмент.
apapacy
04.02.2018 23:54Автору респект как инициативному работнику. Я тоже очень долго работал в конторе не в ИТ отделе, но обладая некотороыми заниями в ИТ. Что касается этого пути с Excel. Поверьте мне, электроные таблицы предназначены для быстрого составления отчетов которые помещаются на один экран. Положительный эффект от Excel сильно уменьшается с объемом таблиц, с количеством таблиц и с тем насколько долго эта система эксплуатируется. Через лет 5-10 работы (и даже раньше) приходится чуть ли не каждую цифру с калькулятором проверять потому что пока работник который что-то знал был в отпуске, с таблицей работал работник которого не жалко. Он добавил пару строк или столбцов в результате где-то сместились формулы, какие-то формулы забыли скопировать, а добавленные в конце или в начале строки не вошли в итоги.
Так что по хорошему нужно чтобы ИТ-служба это все отработала. Хотя там тоже могут быть проблемы. Если там нет хороших разработчиков на Вас может свалиться некая самописная «ЕРП» с которой будет работать настолько удобно что вы будете готовы считать на счетах.gazdovsky Автор
05.02.2018 07:22Спасибо! Тут полностью согласен — использовать Excel для работы с таблицей больше 25 000 строк, стало очень непросто. Возможно дело в том, что я недостаточно занимался оптимизацией логики, но это уже другой разговор. Вообще, про Excel упомянул только чтобы показать через что пришел к своему решению, а так, вся логика давно на App Script.
nikvel
05.02.2018 09:01Попробуйте Power Bi.
Да и в целом Вам лучше смотреть в сторону механизма выборки из массива, можно и из гугл-таблиц данные подтягивать.
Ведь всем не нужны ВСЕ данные, достаточна малая часть.
Ну а потом, опыт подскажет прямой путь в настоящие БД…gazdovsky Автор
05.02.2018 10:58Спасибо за наводку!
remzalp
05.02.2018 15:48https://www.youtube.com/watch?v=fIf7c49iiIk
Чудеснейший пример как на Python + Pandas можно заменить примерно треть функционала БД с достаточной скоростью.
http://edu.skillfactory.ru/excelpython
Повтор будет послезавтра.
И да, это не реклама скиллфактори. Просто редко встречал адекватного человека из Р*****ома, а тут он еще и интересно рассказывает на достаточно реальных примерах.
x67
05.02.2018 00:55Интересно, какие у вас были зарплаты и каких денег стоили эти счета, если руководство могло позволить себе потратить 2 человеко-дня на представления предложения покупателю
Dessloch
05.02.2018 03:21На самом деле статья о том что кое-где в России по-прежнему каменный век. И на ИТшника там смотрят как на мальчик-поменяй-мышку.
sbh
05.02.2018 08:49До тех пор, пока он не показывает, как делать их работу в 20 раз быстрее чем они.
mgremlin
05.02.2018 11:21Тогда его начнут ненавидеть и сольют при первой возможности.
apapacy
05.02.2018 11:50Я наблюдал два варианта развития. Первый положительный когда работника начали ценить и продвигать по служебной лестнице со сказочной скоростью. И второй когда работника все же не сокращали первым соаратом. Но на него ложился совершенно дикий объём работ при этом его все считали ниразу не специалистом.
NNikolay
05.02.2018 03:29Это всё очень вперчатляет! Велосипед пару раз изобретён и классические грабли собраны, но так продвинуться вперёд самостоятельно — это реально круто.
Я не согласен с советами про ERP, если предприятие этого ещё не сдалало — не в Ваших силах это изменить. Это как совет «станьте ежами».
Я подобные задачки решал несколько раз, поэтому хочу дать пару советов:
1. Утащите все данные в Google BigQuery. С одной стороны, это сервис внутри гугловой инфры, Google Sheets умеют из него писать и читать. Не придётся миргировать всю систему за раз. С другой стороны, это настоящая база данных с масштабом, SQL, клиентами под разные языки программирования и т.п. Работать будет за секунды, даже не за десятки.
2. Утащите всю логику в SQL на BigQuery. Иначе через пол года сами утоните в своих функциях. Вы, конечно, не послушаете. Но как уже утоните, тогда будете знать куда мигрировать.
3. Я правильно понял, что цены поставщиков меняются часто, а набор товаров — редко? Уже советовали вверху — нужно разделить задачи поиска актуальной цены и задачу матчинга товаров. Введите свой стандарт написания и свою номинклатуру товаров. Все товары поставщиков сматчить один раз к этой номинклатуре. Далее использовать эту таблицу индексов для поиска цены (DB & SQL — никуда без этого).
4. Учитесь кодить на питоне. Под эти задачи очень подходит. Он сможет работать с базой данных и слать туда SQL. Плюс при желании настроить нейросетку — вот они библиотеки, все рядом.
5. До нейросетки стоит попробовать n-gramm. Или уже делали? Ещё хороший контрольный признак — это разброс цен. Если алгоритм сматчил товар за 100 руб и за 10000 руб — что-то явно не так.gazdovsky Автор
05.02.2018 07:07Благодарю за советы!
По 1, 2 и 3 пунктам — в целом в эту сторону и планировал двигаться. Спасибо, что окончательно убедили.
4. По питону — понял, буду учить.
5. n-gramm делал, но он мне не совсем подошел — а именно, я хотел чтобы система точно понимала какой признак определился, длина или например диаметр. А так как в описании иногда бывает много мусора, то все перемешивалось. Возможно как раз контрольный признак меня спасет, так что есть повод вернуться к этомуVVizard
06.02.2018 09:48Учите лучше 1С. Продукты на платформе 1С сердце любого предприятия, и ваши навыки пригодятся вам и в других задачах. При этом изучение 1С на порядок проще питона (т.к. платформа 1С это сразу и среда разработки и СУБД, плюс много готовых решений которые делают примерно то что вам нужно).
Просто как пример: infostart.ru/public/596761, infostart.ru/public/754248
Ndochp
05.02.2018 15:28Советы про ЕРП не зря — много раз видел людей сидящих на 1С торговле и использующих её только для подготовки печатных документов и контроля склада. А ведь там есть регистр «Номенклатура поставщиков» сделанный как раз для сведения к единой позиции всех вариантов уже давным давно. Но он сделан настолько не бросающимся в глаза, что мало кто его использует.
Так что вполне возможно, что и у автора 1С есть. Только в неё вносят тот самый подготовленный автором счёт после оплаты в документ реализации. И опять руками.
justmara
05.02.2018 16:08Утащите все данные в Google BigQuery.
Предварительно посоветовавшись с безопасниками, ага. А то предприятия — они разные бывают. С разными подходами к "хранению информации в сети Интернет"
Утащите всю логику в SQL
Правильно. Чтоб потом понимать, почему именно больше никогда-никогда не пытаться реализовывать логику в SQL.
NNikolay
06.02.2018 11:34Ну, в данном случае данные уже в Google Sheets.
Про SQL и не начинайте:) Для каждого инструмента свои задачи. В моём понимании его задача — это по большей части именно SQL.
VVizard
06.02.2018 09:42На мой взгляд для решения описанной задачи очень подходит 1С.
Особенно она подходит менеджеру который не собирается становиться программистом. Так же как выше заметили полно обработок решающих подобные проблемы, бери любую и дорабатывай под себя.
Порог вхождения в разработку на платформе очень низкий, при этом 1С уже есть у них так что покупать ничего не нужно.
Zwe3do4et
05.02.2018 06:12может кто-то еще поделится своим опытом решения подобных задач либо готовые продукты которые могут это все делать?
чисто с обывательской стороны интересно, как можно ускорить/автоматизировать и т.д. подобные задачи.Louie
05.02.2018 10:41Задачи все решаемы, но лучше сначала уточнить место приложения усилий. Например, в данной статье клиент пишет заявку, не зная конечной цены товара. Потом некий персонал в мыле обрабатывает заявку, уточняет-выясняет-ставит цены и отправляет клиенту счет с ценами. Клиент смотрит на счет и принимает решение о покупке исходя из цен в нем. По моему опыту, при таком подходе, за этим счетом следует уточненная заявка от клиента и еще один счет. Все при деле, когда на сайте компании «цена по запросу». Емэйлы летают, бумаги печатаются, эксели кипят
zorg00
05.02.2018 07:24Странно, как Ваш завод вообще работает. В Exel учет ведут… Государственный что ли?
gazdovsky Автор
05.02.2018 07:28Завод давно не государственный. Не пойму почему вы решили что мы весь учет ведем в Excel. Учет раньше велся в 1С, сейчас переходим на ERP
erwins22
05.02.2018 10:38ERP или 1С ERP?
почему отказались?gazdovsky Автор
05.02.2018 12:121С ERP. Раньше была 1с8, но она была полностью самописной быстро, да еще «на коленке», поэтому вести управленческий учет было практически невозможно и в руководстве решили, что проще новую заказать
erwins22
05.02.2018 12:43Тогда вы основная проблема автоматизации организации, так как делаете удобной работу не в общей базе, а в экселе ускоряя отдельные этапы, но делая общую производительность намного хуже. Вместо того что бы переделать номенклатуру один раз и выделить человека для заведения НСИ, вы продолжаете автоматизировать хаос.
apapacy
05.02.2018 15:53Я просто ждал эту фразу в обсуждении. В класическом варианте она звучит так: «Бардак автоматизироать невозможно». Я ее воспринимаю как нежелание решать действительную проблему в управлении организацией, а предлагать решение которое легче всего реализовать и более того которое уже реализовано в станрдартной конфигурации 1с или в ERP.
Ну будет НСИ. Скорее всего есть уже эта НСИ. Какое это отношение имеет к разбираемой проблеме. К тому что приходит заявка факсом или прайсы в сканах.mgremlin
05.02.2018 16:10Вы и в рамках данной статьи ничего не сможете сделать с прайсом в сканах.
Так что, ответ простой: любой вход переводится в электронный вид, если надо — вычитывается, приводится в принятую внутри компании номенклатуру, и либо проценивается, либо принимается в качестве источника данных.
SergeKuznetsov
06.02.2018 13:35А если к 1С прикрутить решение 1C-B2B то можно еще в разы ускорить обработку заявок от клиентов ;)
schernolyas
05.02.2018 07:24Браво!!! Аплодирую стоя!
В далеком 2002-ом я делал нечто подобное. Оказывается, проблема автоматизации ручного труда еще актуальна :-(gazdovsky Автор
05.02.2018 08:10Благодарю! Проблема не то, что актуальна, судя по тому, что мы в разы опережаем по скорости подготовки предложений большинство конкурентов — такое ощущение, что над ней даже работать не начали. По крайней мере, такая ситуация сейчас в нашей отрасли. Иногда мне удается пообщаться с руководством заводов по выпуску схожей с нашей продукции, и когда я рассказываю им о том как работает наш отдел продаж, выражение их лица резко меняется, глаза округляются, а я в их глазах видимо становлюсь профи-программистом, хотя сам и понимаю что даже далеко не джуниор.
justmara
05.02.2018 10:17Фокус в том, что вся эта оптимизация действительно выглядит как простая фигня, которую может сделать студент. И да, она будет работать и прям сразу давать профит.
В долгосрочной же перспективе получается, что сейчас все привыкнут к этому процессу, а когда вы уволитесь — то всё повиснет в состоянии "ЗАМИНИРОВАНО". Т.е. будет работать до первого сбоя, а тогда вообще всё встанет раком и, возможно, надолго. Потому что все привычные (до этого момента) процессы позабыты/заброшены, а новый перестал работать и чинить его некому.
Тогда встаёт вопрос о каком-то централизованном решении — подрядчик, например. Который разрабатывает и внедряет. А это разом другой порядок расходов.
А подрядчик не дурак — он захочет не одного клиента окучить и будет рожать универсального монстра, который бы подходил всем…
И тут мы получаем ещё одну 1С.
В общем бизнесу бывает просто страшно менять текущий процесс, потому что он более-менее справляется, а большего и не нужно.
Anymorficus
07.02.2018 06:22«то всё повиснет в состоянии „ЗАМИНИРОВАНО“»
А вот я за то? чтоб оставить Так «как есть» (AS-IS).
А то знаем, турнут потом после идеальной «неоплачиваемой» отладки и два года оно будет крутиться вполне сносно. А ты крутись как хочешь.
Автор. Оставь так, а все дальнейшие улучшения только на тестовой удалённой машине, к которой доступ только у тебя. Как отладишь методу продать внедрение и поддержку через «знакомого программиста» своему руководству, а потом и «соседним» заводам.
Aquahawk
05.02.2018 11:08т.е. вы хотите сказать что нормальным разработчикам стоит попробовать походить по подобным фирмам и предложить им улучшение их жизни? Или таких предложений вагон и это просто самодурство собственников и директоров?
Estee
05.02.2018 12:57+1Стоит однозначно. Но для этого нужны не только навыки в разработке, но и навыки в умении разговаривать с руководством и сотрудниками подобных фирм. И сначала понять, надо ли такое улучшение кому-то в этой фирме. А то может оказаться, что начальник отдела продаж не хочет, чтобы сотрудников под его началом стало в 20 раз меньше. А начальнику просто пофиг, так как продажники, которые делают предложения из экселя — народ дешевый и много тут не сэкономишь. И тогда этот проект может стать кошмаром для внедрения: пофигизм плюс саботаж.
agugnin
05.02.2018 13:47Проблема в том, что в большинстве случаев эфективно решить задачу можно только пощупав ее изнутри. И в топике именно такой случай — специалист по продажам с толикой знаний в разработке ПО прочувствовал все нюансы и выдал решение, наилучшим образом приспособленное к ее решению. В противовес этому — я многократно видел как клиент приходил, и вроде-бы нормально ставил тз профессиональным разработчикам, но т.к. разработчики понимают задачу только в рамках тз, результат остваляет желать лучшего в плане юзабельности и это выливается потом в тонны дополнений и исправлений.
mgremlin
05.02.2018 08:31А я — в 89. Тогда были магические слова «расчет зарплаты».
В 2002 уже давно работала самопальная ERP, которая для начала разговора сгребала все прайсы в базу и трамбовала, смердживая на основе полу-самопального полнотекстового поиска. Клиенты уже могли пробить свои хотелки через веб-интерфейс в режиме онлайн.
Надо объявить перепись: кто раньше? 8-)
tuxx
05.02.2018 10:00тут больше проблема в начальстве, которое просто сидит на жопе ровно, т.к. «продажи идут»
ahdenchik
05.02.2018 10:15Оффтопик, возможно, но почему завод не может единую классификацию выпускаемой продукции ввести вместо всей этой эвристики? Или у вас таки не завод, а оптовый склад?
gazdovsky Автор
05.02.2018 12:21То, что я описал в статье, это часть комплексного процесса обработки заявки:
Чаще всего заявки включают не только инструмент который мы изготавливаем сами, и заказчики очень не любит их делить между поставщиками, поэтому мы вынуждены непрофильную продукцию закупать на стороне.
Описывать как мы заводим заказы в 1С я понятное дело не стал, а рассказал о другой части процесса.Ndochp
05.02.2018 15:33На всякий случай, вашу задачу в 1С ЕРП решает блок «Регистрация цен поставщиков»
1c-v8.ru/articles/64-registratsiya-tsen-postavshchikov-ut-11
(функционал УТ11 в ЕРП входит полностью)apapacy
05.02.2018 19:01В том то и вопрос что сначала нужно определить какую задачу решать а потом уже решать. Вопрос в том что одна и та же позиция в номенклатуре может в прайсах и в заявках называться совершенно по-разному. И это исходные условия. Это внешняя по отношению к предприятию информация. И наоборот две позиции которые называеются пркатически одинаково (разница 1% текста) на самом деле совершенно разные по содержанию т.к. этот 1% может касаться или точности или материала или покрытия. В реальности есть специалисты у которых обработка заявок как битва за урожай. С другой стороны разработчики которые уверены что если создать справочник инструменты и поставщики а также документ прайсы то все проблемы будут разрешены. А также администрация которая вынуждена привлекать или сторонних консультантов которые как правило (даже самые лучшие и независимые) продвигают некоторый близкий их бизнесу продукт. Или же (что не немного лучше) штат собственных ИТ которые зачастую те что остались, и собираются сделать это все «на Делфях». Вобщем ситуация очнь непростая.
Ndochp
06.02.2018 10:05Я для того ссылку и привёл, что
1. ЕРП уже внедряется на предприятии автора. Желательно, чтобы инструмент использовался наиболее полно, иначе будет больше проблем, чем выгоды.
2. Если вы приглядитесь, там в регистрации для номенклатуры две колонки — номенклатура (то, как эта штука называется у нас и проходит по складскому учёту) и номенклатура поставщика (то, как эта позиция называется в прайсе этого поставщика)
Соответственно, загрузка делается примерно так: проглатываем прайс, (колонки поставщик, цена, номенклатура поставщика, возможно спец условия для цены) заполняем известные позиции по колонке «номенклатура» (исторически подобранные), выдаём строки, в которых колонка «номенклатура» не заполнена для заполнения с ручным контролем. И вот там уже специалист (та самая девушка с 10 годами опыта) и смотрит на все важные 1% различия. Если нужно — создаёт в нашем справочнике новую позицию.
Если у нас вдруг и заказчик странный, и в заказе то, как он называет позиции, а не как мы хотим, то и его названия можно загрузить в таблицу соответствия и при получении заказа преобразовать в наши термины. Но это редко.
Главной задачей становится таким образом не разбор синонимов, а поиск аналогов. Так как (особенно во всякой машинерии) болт с большей прочностью, который есть на складе вполне может быть аналогом, а вот с меньшей, как ни странно, тоже может, но это надо отдельно уточнить у заказчика.apapacy
06.02.2018 12:59Как однако все просто оказалось. По этому поводу есть английская пословица. Человек у которого в руках молоток все проблемы кажутся гвоздями.
OlehR
05.02.2018 12:131) Автор просто молодец. От него ожилали рутинную работу — он занялся автоматизацией и на минуточку ускорил процес в 20!!! раз. Кроме того после етого етапа зделать полную автоматизацию будет намного проще.
OrangeGrunge
05.02.2018 14:17они не поощрили увеличение производительности труда
Понимаете, это специфика. Логика руководителей работает следующим образом.
- Работник получает процент за выполнение задач.
- Чем больше задач он выполняет, тем больше денег зарабатывает.
- За счёт чего он выполняет больше задач — неважно.
- Факт в том, что он стал зарабатывать больше.
За что же его ещё поощрять?
За то, что поделился решением с остальными? Ну, спасибо, конечно, но это его личное дело.DMGarikk
05.02.2018 15:22Работник получает процент за выполнение задач.
Чем больше задач он выполняет, тем больше денег зарабатывает.
Ооо, а это может повлечь за собой эффект Стаханова. дальше снизят процент за выполнение задач, сократят лишних сотрудников и начнут задирать планы оставшимся
Именно на таких предприятиях это чаще всего и случается, где руководству пофиг на мотивацию персоналаOrangeGrunge
05.02.2018 15:39Вы совершенно правы.
Но как вы рассуждали бы на месте руководства? Какие меры предприняли бы?
Не хочу защищать описанную вами модель, но готов оппонировать, так как интересен взгляд со стороны.DMGarikk
05.02.2018 16:20как руководство я конечно бы сократил отдел и вообще бы обрадовался и таки вложился в нормальную автоматизацию с целью сокращение вообще всей бюрократии
===
а чтобы не разбежались сотрудники надо взяться за организацию мотивации персонала, потому что на любом заводе любой слесарь знает что если работать в три пота то потом будет хуже, посколько менеджмент быстро сообразит что производительность выросла, а зарплата 70тыс для рядового слесаря это выше рынка (можно сколько угодно спорить что это нормально в такой модели, но я сталкивался даже с тем что в цех приходила толпа экономистов и отдел планирования и убеждали слесарей что «физически невозможно столько сделать вы обманываете»)
OrangeGrunge
05.02.2018 13:47Не ожидал увидеть в этой статье номенклатуру металлореза. Выходит, мы с Вами коллеги (но уже не конкуренты, я из этой сферы ушёл).
Занимался чем-то подобным, но моя идея состояла в разработке универсального каталога на Excel. Если грубо — вводишь тип инструмента, его геометрические характеристики и применимость по ISO, а таблица выплёвывает ряд подходящих решений разных производителей. Основная головная боль при обработке заявок (и особенно — тендеров) — подбор аналогов, которые у зарубежных производителей именуются совершенно по-разному, порой без какой-либо видимой логики. И моя самоделка заметно сужала поле поиска.
Жаль, что с моим уходом всё это стало ненужным, ибо делал для себя.
Осуждающим: почему-то именно в сфере продаж металлорежущего инструмента я столкнулся с невероятной «чёрствостью» бизнес-процессов. Наверное, это относится ко многим областям, связанным с поставками на наши крупные предприятия. Поэтому уровень автоматизации предельно низок, да и подготовка персонала обычно оставляет желать лучшего, как у поставщиков, так и у потребителей, а «заявка» как правило представляет собой кашу из зарубежных обозначений, написанных кириллическими буквами, неактуальных ГОСТов и просто орфографических ошибок.
Для примера — в одном российском филиале очень крупного немецкого торгового дома (определённо известного автору) есть даже специальная должность: человек днями напролёт занимается вычиткой заявок, поступивших от полевых продажников. А это, извините, 50-60 килорублей в месяц — не дешевле ли автоматизировать процесс?.. Видимо, нет.
Автор проделал очень важную и сложную работу в тех условиях, которые ему достались.
Спасибо за статью.
shomnest
05.02.2018 14:06Отличная статья, спасибо, было интересно.
Вот прям как раз сейчас, в течении последних нескольких дней, кручу в голове приложение для знакомой конторы. Один в один та же ситуация с подбором товаров по поставщикам, только оборудование и инвентарь, около 25 прайсов, обновляющихся ежемесячно. Тема точно актуальная, но 100% решаться должна через БД, вот руки не доходят сесть подумать над парсером экселя в бд, пока что единственное, что в голову пришло.
Вы меня замотивировали, сэнкс)Maalox
05.02.2018 17:16Напишите пожалуйста статью с вариантами решения. У меня описанная проблема очень актуальна, но я не понимаю какими инструментами её можно решить. По логике автоматически определяя группу товара мы понимаем какими характеристиками этот товар обладает. Зная что мы ищем (длину сверла, хвостовик и т.д.) мы можем распарсить входное наименование на характеристики и затем подобрать по характеристикам 2 или 3 самых выгодных решения (в идеале не только по цене но и сроку поставки и стоимости доставки). Но как это технически воплотить — мне совсем непонятно.
shomnest
05.02.2018 17:37Предложение по написанию статьи годное, может что-то и получится.
По теме как я это вижу — максимально атомарно разобрать каждый прайс и потом при помощи флагов поиска в gui проводить подбор по определенным параметрам. Большую трудность по мне, представляет более или менее однообразный разбор таблиц экселя, которые за частую одна на другую не похожи.
Посмотрим.Maalox
05.02.2018 19:14Как раз с разбором таблиц проблем нет. Сложность в том чтобы преобразовать строку вида «сверло длинной серии ц/х 12 р6м5» в набор характеристик не прибегая к регэкспам, потому что порядок слов и вообще их наличие под вопросом. А дальше сделать то-же самое для прайса поставщиков и затем сопоставить. Что это должно быть?
shomnest
05.02.2018 20:13Уже после того как написал комментарий, понял, что мы с вами говорим о немного разных задачах, ваша сложнее и по ее решению напрашивается только одно — нейронные сети.
gazdovsky Автор
05.02.2018 19:59Самое забавное — именно реализацию в коде я решил не включать сразу из-за того что считаю ее вполне очевидной, поэтому и написал:
В случае интереса к этой статье, подробнее опишу работу программы со вставками кода.
Теперь, раз интерес все же есть, возникает вопрос к вам, уважаемые хабровчане — о чем лучше писать:
Как выявить самые эффективные регулярные выражения в зависимости от категории?
Как с их помощью привести прайс к одному виду?
Как сматчить все совпадения?
Или как я устроил разбор однообразных таблиц excel?
Или обо всем по порядку?
И с учетом всех комментариев, стоит ли описывать мое, как оказалось невероятно примитивное решение, или стоит сначала что то поумнее придумать?
Буду благодарен за ваше мнениеshomnest
05.02.2018 20:16Было бы интересно почитать про приведение к одному типу, т.к. то, что предлагали для парсинга мне, это два с половиной десятка экселевских таблиц, некоторые с картинкам, с разным количеством столбцов и, естественно, по нескольку книг в одном документе.
mgremlin
05.02.2018 20:17Обо всем по порядку, за исключением разбора таблиц.
Причем, интереснее алгоритмы, чем реализация, поскольку реализаций самых разных — горы, и ваша точно не будет новой и вызывающей, что ли. Просто исходя из результата.
А вот в алгоритмах вы вполне могли выдумать что-то новое и интересное.
GreedyIvan
05.02.2018 14:59С точки зрения сотрудника — это безусловный плюс. Такая инициатива должна приветствоваться. Но с точки зрения руководства, перед расширением этого опыта на весь отдел, необходимо решить вопрос построения на основе этой технологии бизнес-процесса и невилирования фактора автобуса. Тогда станет понятна не эмоциональная, а практическая стоимость данного процесса. Насколько данный бизнес-процесс будет работать независимо от исполнителей и сколько будет стоить его обслуживание, когда автор станет недоступен.
Способность к автоматизации бизнес-процессов на первых порах окрыляет. Но главное не забывать, что автоматизация — это, в первую очередь уменьшение человеческого фактора в процессе, а не уменьшение выполняемой людьми работы.
Другими словами, если мощность процесса возросла с 10 до 100, то должны быть механизмы, поддерживающие эту новую мощность на новом уровне. И если эти механизмы более человеко-зависимы, то такое улучшение стратегически играет в минус.
Aleksalt
05.02.2018 15:00Реакция на повышение производительности труда у нас и у них.
Россия.
— Я повысил производительность в 20 раз!!!
— Пфффф!
Япония.
— Я повысил эффективность на 2%!
— Офигеть, ты крут, на медальку и деньжат!mgremlin
05.02.2018 15:25Дык, база разная.
В данном конкретном случае (когда до рации заявки обрабатывались куском угля на полях старой газеты) и в 2000 раз ускориться — плюнуть раз, любой студент справится.
А в Японии, когда навнедрено всяких кайдзенов да канбанов по 5 вагонов на каждого человека, 2% добавить — банда сеньоров за год работы зафейлит на раз.Aleksalt
05.02.2018 15:352000 раз?
— Пффф!mgremlin
05.02.2018 15:42ну почему? Надо просто написать статью про какой-нить Clickhouse, наворотить на плюсах что-нить, нейросетку сваять — и описать тут хотя бы самые общие принципы. Ошибки честно обработать, написать хоть какие тесты. Кода накидать мудреного строк 500…
И тогда, даже если это не даст кратного ускорения, все будут молча обтекать. Ну или говорить: ну ты крут, чувак.
А когда любой представляет, что подобное он бы сделал (чтоб не сказать — делал 20 или 30 лет назад) за пару вечеров в самой обычной базе — ну ессно будет пфф, куда деваться…
antonn
05.02.2018 15:33Мне для ЕГАИС пришлось для более надежных связок двух справочников (многие-ко-многим, разумеется) использовать нечеткое сравнение строк. В принципе, довольно точно определяла и разделяла позиции типа «Водка таежная» и «Таежная Водка 'Элитная'».
erwins22
05.02.2018 16:39Но если честно, хотелось бы почитать статью с настраиваемым сравнением строк.
Частая задача с которой сталкиваюсь это адреса написанные как бог на душу положит.
Хотелось бы поиск в базе автоматически наиболее похожего и т д.antonn
05.02.2018 18:22Вероятно готовые средства для web по части адресов уже есть, тут вопрос скорее с актуализацией справочника (ну а код можно посмотреть в скриптах), может и веб-сервисы есть готовые.
А настройка «сравнения» была костыльная — нечеткое сравнение шло через «Расстояние Левенштейна» и сортировались по нему, отбрасывалось слишком большое заданное в константе и выведенное эмпирически. Алгоритм давал ошибки, но в целом работы убавилось на порядки. И применялся он, конечно же, только когда была ситуация с замножением связей, потому что 100% безошибочного алгоритма не бывает.
VVizard
06.02.2018 10:04Проблема подобных подборов в большом количестве ошибок.
В вашем примере «Водка таежная» и «Таежная Водка 'Элитная'» вполне могут быть и разными товарами, без контекста этого понять нельзя.
Layner
05.02.2018 17:15Автор молодец, сам много лет подобное изобретаю везде где работаю.
тут бы сделал так: залил прайсы в базу которую больше всего знаю, например MSSQL. Почти у всех прайсов сейчас есть внутренний код товара в этой организации, а то и два кода… Привязывайся к любому. Получается надо один раз свести все товары, сделать перекрестную таблицу. «Свести товары» — это самое сложное, тут надо как автор, через регулярные выражения и т.п. А далее по кодам работать ежедневно прайсы обновлять. Выделять новые строки, или исчезнувшие позиции. Ну если кто нибудь поменяет коды — по последнему разобранному прайсы от этой организации по наименованиям вычистить новые коды.
Ну и выбрать позиции уже составит не 30 минут, а ровно столько, сколько потребуется времени распознать позиции в заявке. Критерии выборки от количества и т.п. устанавливаем (например сверла от 100шт берем в Фирма1, а от 10000шт в Фирма2). В эту же секунду всё будет в лучшем виде!
Т.е. гугля бы в помощь не привлекал, сервер БД самый верный помощник. Высвободившихся людей вы посадил на периодическую выверку соответствия. Это не сложно, когда удобная отображалка.
zorg00
05.02.2018 20:02По хорошему, надо весь завод датчиками и камерами оснастить, и в БД смотреть где-что делается. А отдел продаж продаж автоматизировать по максимуму, а не в Excel макросы писать.
gazdovsky Автор
06.02.2018 08:50Про БД и смотреть где-что делается, подумываю написать статью, как реализовал это у нас через qr коды и веб-приложение у каждого рабочего. Рабочий сканирует код — в Google Spreadsheets появляется запись с его операцией, временем, и трудоемкостью. В итоге каждый рабочий видит свою статистику за месяц в режиме реального времени, а мы в свою очередь видим что где делается, и все довольны. Но вдруг снова примитив
micbsv
05.02.2018 22:39Я так в 90-х автоматизировал работу отдела корреспондентских отношений в банке, в котором работал аккаунт-менеджером — парсил макросами файлы с платежными поручениями, вгонял в эксел, в базу Oracle и распечатывал мемориальные ордера. В результате работа дня выполнялась минут за 30. Начальник, увидев, попросил поставить макрос и девченкам.
Потом меня взяли в IT-отдел, научили C/C++ и я уже стал писать для операционистов зала.
А потом я по интернету и телефону нашел контракт и свалил в США C++ программистом по рабочей визе, было это 18 лет назад…
chipollone
05.02.2018 23:02Добрый день. Мой товарищ (на Хабре не зарегистрирован) работает над схожей проблемой и хотел бы обсудить с Вами идеи реализации. Вы могли бы связаться с ним по скайпу (happy_romko) или по почте (reserved4shainsky@yandex.ru)?
paranoya_prod
06.02.2018 10:49По моему опыту, автоматизировать, то есть, как минимум, уменьшить затрачиваемое время на какую-любо операцию можно в 99% российских организациях. И таких операций целый состав и две тележки. И не для всех операций нужно покупать ERP, 1С, документооборот. Для многих вещей хватает любого офисного программного обеспечения и встроенной в него возможности написания скриптов. Что автор и продемонстрировал.
apapacy
06.02.2018 13:13Вспомнил ещё об одном отрицательном моменте рационализации снизу. В смысле когда один работник начинает делать все быстро и хорошо по своей инициативе без общего преобразования системы. Через месяц все привыкают к хорошему но в своей работе ничего не меняют. В результате если раньше заявка конкретно на сверла поступала за три дня до часа Х то теперь будет поступать за 30 минут до часа Х. Просто по всей цепочки до и после исполнителя работники расслабятся. А потом ещё потребуют всю информацию от исполнителя на дискете плюс распечатки. И в случае опечатки отыграются что вот они эти компьютеры.
zxxc
06.02.2018 17:26Дело не в системе или процессе, а в общем незрелом бизнесе и его винтиках. Когда вместо того чтобы достичь общей цели — постротить камаз и продать его за деньги — люди придираются к опечаткам и смазанным печатям
alexey-gorin
07.02.2018 06:22Интересный вариант решения конечно на гугл-таблицах. О таких технологиях мы в свое время даже не задумывались.
Вижу также огромное количество комментов, где тоже перечисляются вполне интересные варианты решения. И это говорит о том, что проблема продолжает существовать и однозначного решения нет. Причем в каждой нише есть свои нюансы.
Мы неоднократно подходили к решению данной проблемы. В основном, как настройка бизнес-процессов для наших клиентов на Интернет-магазины. Одно из них в 1С — конфигурация, которая натягивается на УТ и является надстройкой. Там полноценный обработчик прайсов, товары могут называться совершеннно по-разному, но все сводится в 1 номенклатуру. Цены в разных валютах. Рекомендуемая цена от некоторых жирных поставщиков и т.д.
Суть в том, что для заказа у нас сразу видны все данные по каждому товару. То есть цены и остатки по каждому поставщику, а также предлагаемый системой оптимальный поставщик. Некоторые наши клиенты обрабатывают по 100 разных поставщиков.
Другое наше решение специализировано под биржу товаров шинно-дисковой тематики. Несколько сотен поставщиков регулярно присылают свои прайсы на емайл. Все участники проекта получают полный ассортимент товаров от других поставщиков. Для каждого участника сразу же вычисляется и розничная цена по настроенным для него правилам.
Смысл написанного мною текста в том, что наши оба решения это довольно емкие проекты, которые разрабатывались длительное время и не одним специалистом.
Так что респект автору за оригинальное и относительно простое решение. Перспектив для него на этом рынке предостаточно.
LESHIY_ODESSA
07.02.2018 16:58Я как то сталкивался с тем чтобы создать свою базу данных. Есть конечно Microsoft Access, но так же натолкнулся на такой вариант — My Visual DataBase.
Еще можно поискать программки типа ukrsklad.com заточенные на локальный рынок. Сидит программист годами и выполняет хотелки клиентов. Клиенты работают и довольны.
То есть по сути зачем вам изобретать велосипед, когда сотни предприятий работают по схожим с вами сценариям.
Тоже занимался ускорением работы. Смотрю секретарша вручную вносит в базу данных с распечатки звонки. Начал выяснять и оказывается она распечатывает EXCEL файл и ручками всё вносит. В общем пол дня помозговал, один раз сбегал к бухгалтерам, которые в EXCEL профи и вся её работа начала делаться за пять минут, вместо нескольких дней тупого набора.
«Награду» за это я получил мгновенно. Стал делать её работу. Пять минут в месяц, но всё равно обидно.
ZEEGIN
В 1С: УТ (КА или ERP) можно сразу вести номенклатуру поставщика, которая сохраняется в соответствии с собственной номенклатурой. Причем сохраняется и вся динамика цен разных позиций разных поставщиков которую можно использовать в маркетинге и ценообразовании, например для составления правил формирования цен по ценовым групам (средняя по прайсам поставщиков, самая низкая из всех поставщиков плюс 3 % и т.п.) и потом использовать это все подборе при заполнении заявок клиентам.
ВПР — это круто, но только если надо разово что-то свести, а для решения вашей задачи уже есть отработанные и хорошо документированные механизмы.
Как частное решение — это круто.
PS. Заявку на 100 позиций делать за 30 минут — это пипец долго.
MakarkinPRO
а в обычной 1С УТ 11 например такой есть механизм? и с почты умеет вытягивать и распаршивать XLS?
erwins22
а зачем? есть криптопровайдеры с защищеной верифицируемой почтой например тензор и т д, который обменивается накладными напрямую база — база через обработку.
А обычной почтой можно легко подменить письмо.
MakarkinPRO
а если таких поставщиков 20, и они не пускают в свои базы, а только на почту шлют? )
erwins22
А зачем кого то пускать?
У них настраивается, что для такого то контрагента накладные уходят автоматом при запуске обработки обмена. Накладные подписываются цифровой подпись и уходят криптопровайдеру. Потом запускаете у себя и они приходят к вам. Причем этот обмен юридически значим и безотзывен.
Например, где я работал 50% контрагентов с 90% оборота ходили так.
Знаете как это упрощает документооборот. Не нужны бумажные документы от слова совсем.
Так как отчетность в налоговую все и так отправляют электронно, то сбис или тензор или что то еще есть уже.
x67
Интересно, а есть такое же, только для счетов? Большинство до сих пор используют бумажные счета или pdf, информация из которых перебивается в 1с руками
URURU
диадок
stilet69
Есть. Добавляется учетная запись одного из операторов документооборота и можно счетами бросаться через него.
ZEEGIN
Все это езжено изъезжено, описано в официальной документации, сняты сотни видеогайдов на ютубе, и тысячи частных доработок на инфостате.
Парсить из почты я не видел, но просто парсить — да, это часть механизма. Загружать можно при поступлении товаров и просто так отдельно, вести можно цены поставщиков и цены конкурентов.
emil36
да, можно и парсить сразу xls при получении письма. хз, прикольно, конечно, но уже есть готовые продукты.
NNikolay
А можете привести пример? Тема интересная.
Я знаю Talend ETL (со своими ограничениями), ну и просто на питоне парсить.
zxxc
Лет 10 назад, тоже автомотизировал работу отдела продаж, у них 20 позиций в заявке в среднем 25минут оформляли
После автомотизации некоторые личности за 8 секунд стали такую заявку оформлять (на конкурентные товары им получалась больше премия)
И уволили они потом в сумме человек 20 из отдела в 24 человека
А потом все равно новых наняли, правда уже на каждого продажника было не по 15клиентов, а по 100-120
Я думал уже эти вопросы давно решены, если не компанией то конкурентами
А факт что нет, показатель видимо недостатка конкуренции в отрасли.
Автор мог бы свою компанию открыть и заработал бы больше