С момента прошлой публикации пришлось примеряться к ряду различных задач, связанных тем или иным образом с обработкой данных. Задачи совершенно разные, но во всех случаях инструменты R позволили элегантно и эффективно их решить. Ниже, собственно, кейсы (картинок нет).
Case #1: Анализ документов (Web-scrapping)
Постановка проектной задачи проста. Необходимо провести экспертный анализ документов, доступных только по запросам на веб портале и по относящимся к исходной задаче составить аналитический отчет. Звучит просто если бы не следующие нюансы:
- БД документов недоступна напрямую.
- Никакого API к порталу не существует.
- Документы по прямой ссылке нельзя адресовать, только через механизм создания сессионного подключения и поиска.
- Полный текст документа недоступен, его показ формируется JS скриптами для «постраничного» листания.
- По каждому из подходящих документов необходимо, опираясь на plain text 1-ой страницы сделать реферативную сводку по его атрибутам.
- Документов ~100 тыс, реально относящихся к задаче ~0.5%, времени на первый релиз ~ 1 неделя.
Группа «классических» аналитиков засучили рукава и ушли в сверхурочный режим чтения и ручной обработки документов. Ни времени ни желания убеждать в ущербности этого подхода не было.
Мы пошли другим путем, а именно, веб-скраппинг средствами R. По поводу веб-скраппинга в интернете и на хабре достаточно много материалов, не буду повторяться. Пример подобной публикации на хабре: «Web Scraping с помощью python».
В классическом подходе для подобных задач используют Perl\Python, но мы решили не делать микс из инструментов, а использовать R в боевых условиях. Задача была решена более чем успешно в таких конечных метриках:
- 0.5 дня на анализ портала (структура, запросы, ответы, навигация) средствами разработчиков, встроенных в Chrome\Firefox.
- 1 день на разработку R скриптов по подготовке списков документов и их последующему атрибутивному обогащению.
- ~8 часов на формирование задач, автоматизированный сбор данных и формирование табличного представления.
- ~2 дня на ручное ознакомление со списком, отсечение лишнего и прочтение потенциально подходящих документов. После прочтения неподходящими были признаны лишь пара десятков документов.
Несмотря на то, что документы генерировались динамически (JS), удалось найти лазейку по получению 1-ой страницы, а там были все необходимые атрибуты, и тем самым обойтись без Selenium\PahntomJS. Это существенно ускорило процесс сбора данных.
Более того, поскольку веб-запросы работают в асинхронном режиме, задача была распараллелена (средствами R). Время ~8 часов указано для исполнения на 4-х ядрах, так оно было бы раза в 3 дольше.
Группа «классических» аналитиков упорно продолжает работать...
Технические детали
- Для парсинга страниц и выбора необходимого контента использовались различные комбинации методик XPath+regexp.
- Весь код составил ~200 строк из которых 50% — комментарии и переносы длинных строк для соблюдения code conventions.
- Подключенный явными декларациями набор пакетов:
library(lubridate)
library(dplyr)
library(tidyr)
library(tibble)
library(readr)
library(stringi)
library(stringr)
library(jsonlite)
library(magrittr)
library(curl)
library(httr)
library(xml2)
library(rvest)
library(iterators)
library(foreach)
library(doParallel)
library(future)Case #2: Прогнозирование качества фабричной продукции
Постановка задачи также очень проста.
Есть технологическая линия по производству из сырья продукта. В ходе технологического процесса сырье подвергается различной физической обработке, а именно, пресс, формование, хим. обработка, нагрев… Метрики на отдельных процесса измеряются с разной периодичностью, и разными способами. Где-то автоматически, где-то, вручную, например, лабораторный контроль исходного сырья. Совокупно метрик ~50-60 шт. Длительность процесса составляет 1.5-2 часа.
Задача — получить выходную продукцию с заданными физическими параметрами.
Сложности возникают, когда опускаемся чуть ниже:
- Точной аналитической модели тех.процессов нет.
- Параметры сырья меняются от загрузки к загрузке.
- Поддерживается модель заказного производства, когда параметры выходного продукта должны меняться в соответствии с текущим заказом.
- «Эксперименты» по перестройке параметров технологической линии по принципу обратной связи оборачиваются бизнесу слишком дорогой ценой. За 1.5-2 часа полного цикла до выхода продукции будет переведена не одна тонна сырья. Если параметры линии выставлены неправильно — будет брак, заказ надо переделывать.
Необходимо правильно выставлять параметры линии сразу со старта производства заказа и корректировать их по мере тех. процесса для нивелирования возможных флуктуаций в процессе производства.
Что имели на входе:
- Описание технологического процесса.
- Excel «простыни» с элементами VBA автоматизации, содержащих значения параметров при выпуске того или иного заказа. Разные смены и разные фабрики — немного отличающийся стиль заполнения.
Сложная для обычных средств задача средствами R решилась в 2 шага:
- Адаптивный импорт excel данных в структурированное представление.
- Применение алгоритма RandomForest для построения прогнозной модели.
- Редукция списка параметров исходя из результатов прогонов RandomForest и общих физических соображений по техпроцессу.
Полученная точность прогнозирования параметров выходной продукции в размере 3-5% оказалась вполне достаточной и адекватной нормативам.
Для справедливости необходимо отметить, что это все было выполнено в режиме «proof-of-concept». После демонстрации решаемости «нерешаемой» задачи и чуть более детальной проработки решения акцент сместился в область улучшения процедур измерения технических параметров. Это как раз тот случай, когда оперативное применение R позволило расчистить сознание от вторичных цифровых задач и вернуться к первичным проблемам физического мира.
Технические детали
- Весь код составил ~150 строк из которых 30% — комментарии и переносы длинных строк для соблюдения code conventions.
- Подключенный явными декларациями набор пакетов:
library(dplyr)
library(lubridate)
library(ggplot2)
library(tidyr)
library(magrittr)
library(purrr)
library(stringi)
library(stringr)
library(tibble)
library(readxl)
library(iterators)
library(foreach)
library(doParallel)
library(zoo)
library(randomForest)Case #3: Сводная аналитика и верификация в разношерстной продуктивной среде
Постановка задачи:
- Есть сотни выгрузок из SAP в формате Excel по иерархическим объектам. Форматы выгрузок ориентированы на визуальное восприятие человеком и крайне неудобны для восприятия машиной.
- Есть Excel выгрузки из сторонних систем + данные ручного ввода\оцифровки.
- Есть данные в базах Access.
Совокупно может быть несколько сотен тысяч\миллионов записей по всем объектам, подлежащим анализу.
Необходимо:
- Проводить выверку данных в рамках отдельного отчета по кастомным многопараметрическим правилам.
- Проводить кросс-сверку данных из различных источников данных по кастомным многопараметрическим правилам. Результаты расхождений выдавать аналитикам.
- Ежемесячно готовить сводные аналитические отчеты на основе всего этого массива информации. Сотни страниц с различными графическими и табличными представлениями
- Предоставить инструменты аналитику для оперативной произвольной манипуляции с данными по заранее неизвестным правилам.
Предполагаемые пути решения до начала PoC на базе R:
- разработка на SAP (прогнозируемый срок исполнения 5-7 лет, не все требования легко закрываются);
- разработка на access (прогнозируемый срок исполнения 1-1.5 года, не все требования закрываются);
- разработка на чем-то еще (прогнозируемый срок исполнения ???).
Да, задача масштабная просто потому что много данных и отчетов, отнюдь не на 2 дня.
Для доказательства реализуемости провели за неделю «proof-of-concept» на базе R.
В рамках PoC охватили:
- Импорт excel данных с поддержкой «плавающего» формата данных
- Импорт access данных.
- Реализацию подмножества проверок (числовых, текстовых, комбинированных).
- Генерация графических\табличных представлений.
- Генерация html\doc представление с графикой, текстом, таблицами.
- Интерфейс аналитика для работы с данными
В целом, по результатам пилота было получено подтверждение технической реализуемости всех требований; обрисован потенциал по развитию; получены оценки по трудозатратам на реализацию с применением R. Оценки по сравнению с SAP ниже на порядок и более. Возможности по автоматизации и настройке многократно превышают все прочие решения.
Технические детали PoC
- Весь код составил ~500 строк из которых 20% — комментарии и переносы длинных строк для соблюдения code conventions.
- Время импорта массивов данных — секунды.
- Время исполнения проверок — секунды.
- Время генерации выходных отчетов (html\doc) — доли минут.
- Подключенный явными декларациями набор пакетов:
library(dplyr) library(lubridate) library(ggplot2) library(tidyr) library(magrittr) library(purrr) library(stringi) library(stringr) library(tibble) library(readxl) library(iterators) library(foreach) library(doParallel) library(zoo) library(gtable) library(grid) library(gridExtra) library(RColorBrewer) library(futile.logger)
Заключение
Факты есть факты. Можно в R верить, можно не верить; можно сомневаться в возможностях; можно по сто раз проверять и дожидаться, пока с трибун не возвестят, что действовать надо так… Но те, кто наберутся смелости и терпения и заменят старые подходы по обработке данных на платформу R получат многократную экономию и преимущества здесь и сейчас.
Предыдущий пост: «Применение R для подготовки и передачи «живой» аналитики другим бизнес-подразделениям»
Комментарии (54)
i_shutov
22.11.2016 20:08+2Это точно, обсуждали в комментариях к прошлым публикациям. Но я все равно предпочитаю ручками подгружать. А иногда и явно адресное пространство указывать. Не помню на чем, но наступил на грабли перекрывающихся имён. На чистой системе R стал ругаться на рабочий скрипт. Поскольку знал об этом, проблем не возникло, все бныстро локализовал и развёл, но новичка может смутить.
ikashnitsky
22.11.2016 20:41Ну если помнить об этих граблях, можно при необходимости писать полностью, типа
stats::filter()
tessob
22.11.2016 22:37-4Я правильно понимаю, что все кейсы — это плод фантазии автора и предметные вопросы не уместны? Просто все три кейса «слегка» оторваны от реальности.
i_shutov
22.11.2016 22:41Нет, неправильно.
Это конкретные кейсы конкретных людей, в т.ч. бывающих на хабре. Задавайте вопросы, что смогу — отвечу, что потребует раскрытия закрытой инфы, надеюсь ответят сами коллеги.
И привязано это к реальности ближе некуда. Фантазии — это работа социологов, пророчивших победу Клинтон.
tessob
23.11.2016 09:22-1По всем трем кейсам Вы не написали какую задачу решали и какого качества результат получили.
Что за отрасль во втором кейсе? У меня в голове не складывается двухчасовой производственный цикл, при котором успевают провести «пресс, формование, хим. обработка, нагрев» и при этом потребить «не одну тонну сырья».
Я правильно понимаю, что источником данных в третьем кейсе является ERP? Если так, то какие «данные из разных источников» Вы там нашли и что с чем сверяли? Просто интересно. Кроме того не понятно почему вместо целой кучи нативных OLAP и отчетных систем решили использовать R с интерфейсом через Excel.
Да, и фактов никаких в Вашем посте нет. Так что посыл в заключении слегка не корректный.i_shutov
23.11.2016 10:11+1Case #1 — выполненный в срок и с должным качеством аналитический отчет, предполагаемый к исполнению в рамках контракта.
Case #2 — как я писал, открыть детали по отрасли не могу. результат указал ниже — инструмент найден, а реальная задача переехала в область улучшения измерений.
Case #3 — все написано в тексте. SAP + Access + разные Excel с данными ручного ввода + в планах сканы отчетной кипы документов (их надо будет выверять на корректность распознавания через кросс-проверки).
А вопрос "Почему?" — не научный. "Потому что так сложилось". Это просто вот такая реальность с которой имеем дело. От нативных OLAP толку нет никакого, поскольку данные находятся в различных источниках, они грязные и разноформатные, а проверки не просто суммы, но и многоэтапный анализ, включая анализ текстов. Кросс-проверки различные, из элементарных, например, данные в двух разных источниках по одинаковым статьям должны совпадать как по названию, так и по совокупным суммам за заданный период, с учетом доп. данных из третьего источника, а также с учетом исключений, определяемых дополнительно…
А Вы знаете сколько будет стоить такая доработка руками САП-еров? (это их оценка 5-7 лет, но понятно, что они заняты и основными задачами).
Я здесь поделился задачами, которые трудны для обычных подходов (Excel\BI), но, как оказывается, легко решаются только средствами R, про который многие думают, что он применим только для стат.вычислений… Основная цель — показать, что есть такая тропка и ходить по ней можно. Кто хочет — может пойти, кто не хочет — насильно никто не тянет. Времени на убеждение сомневающихся у меня нет, а желающих пойти с каждой публикацией все больше.
tessob
23.11.2016 10:35Case #2. В таком случае, я позволю себе не поверить в достоверность данного кейса.
Case #3. К вашему сведению, SAP — это компания, которая выпускает огромный зоопарк различных продуктов. Именно по этой причине я и попросил уточнить какой из них Вы имеете в виду. И пожалуйста подробнее, что это за данные такие «данные находятся в различных источниках, они грязные и разноформатные». Кто их испачкал и чем?
Эта фраза вызывает у меня полнейший когнитивный диссонанс: «Кросс-проверки различные, из элементарных, например, данные в двух разных источниках по одинаковым статьям должны совпадать как по названию, так и по совокупным суммам за заданный период, с учетом доп. данных из третьего источника, а также с учетом исключений, определяемых дополнительно…»
Статьи чего? Что за разные источники? Это вообще какой хозяйственный процесс? Что вы сделать-то пытались?
Я знаю сколько стоят доработки в SAP.i_shutov
23.11.2016 10:49Case #2. Поскольку частные детали пока публично озвучить нельзя, то можете не верить. Реальность от этого не изменится.
Case #3. Общий вектор: оперативный анализ проектной деятельности большой компании + анализ проектных рисков. Анализ в разных плоскостях, в т.ч. и финансово учетной плоскости. Бумажные сметы обычно пачкают маслом. Фамилий испачкавших не знаю.
tessob
23.11.2016 11:01Case #3. Я так понимаю, что реальность мы снова не изменим.
В общем, как я в начале и написал, предметные вопросы оказались не уместны. ЧТД.i_shutov
23.11.2016 11:05Вы надеялись увидеть весь пакет исходных документов, сырья и бизнес-процессов? Конечно же этого не будет, можно было и не спрашивать.
tessob
23.11.2016 11:29Отнюдь. Просто весь Ваш пост выполнен в стиле: «Российские ученые разработали новое мощнейшее сверхсекретное оружие, основанное на принципиально новых физических принципах». Воспринимать это всерьез просто не возможно. Если к этому добавить, используемую Вами терминологию и расставляемые акценты, то картина становится еще более драматичной.
i_shutov
23.11.2016 11:41+1Пусть будет так.
Кстати, может у Вас есть задача, которую предположительно можно решить средствами R? Выложите на дропбокс все исходники и потроха, а сюда ссылку на них, сообща можно будет подумать над решением. Решенная задача будет служить лучшим подтверждением.
P.S. "невозможно" пишется слитно, а в описании стиля пропустили слово "опенсорсное" оружие.
Archi_Pro
23.11.2016 12:32По кейсу 3 очень живо себе представляю:
Склад работает на acces,
Бухгалтерия на SAP,
Управленческий учет в Exel.
Финансовый директор хочет иметь отчет какой то определенной формы где нажо свести данные из этих 3 источников + построить прогнозtessob
23.11.2016 13:12-1Мое воображение видимо уступает Вашему.
Если мы говорим про SAP ERP, то материальный учет там будет реализован в любом случае, т.к., согласно нормам БУ, учет материалов ведется в стоимостном и натуральном выражении. Соответственно, на правах абсурда, в Access можно вести только адресное хранение материалов, которое уже есть в стандартной функциональности ERP (WMS) и его достаточно просто активировать. Далее. Что вы понимаете под управленческим учетом? Если учет затрат, то в ERP это реализовано. Если что-то свое, то что?
Что касается построения прогноза, то что полезного вы можете спрогнозировать на основе бухгалтерии и запасов?
У вас точно есть прикладной опыт работы с ERP системами?
knagaev
23.11.2016 13:26+1Управленческий учёт — это совсем не учёт затрат :)
Он как раз и используется для оперативной оценки обстановки и прогнозов.tessob
23.11.2016 13:43-1Кто-то кроме Вас так считает?
https://en.wikipedia.org/wiki/Management_accounting
Посмотрите методологии. Costing — это учет затрат. В SAP ERP значительная часть этого реализуется в модуле CO.Archi_Pro
23.11.2016 14:03+1SAP — чудесная вещь, кто же спорит, но помимо бухгалтерского и складского учета существуют еще много всего забавного, например контроллинг.
Вот идея с контроллингом появилась с новым финдиром, сап внедряли при предыдущем, так и появился целый отдел с экселем. Или вот план движения денежных средств то же никто в сапе не делал, а исключительно в экселе причем у каждого департамента свой отдельный файлик заполненный с любовью и ошибками.tessob
23.11.2016 14:32Модуль СО из предыдущего поста — это и есть контроллинг. Контроллинг в SAP учитывает затраты и выручку. Ничего другого он не делает.
В здравом уме в SAP-CO учет движения денежных средств не делают, просто потому, что ДДС прямого отношения к затратам не имеет. Систему проектировали наркоманы, не иначе. Проблемы с файликами — это уже следствие другой, гораздо большей проблемы.Archi_Pro
23.11.2016 14:51Систему проектировали наркоманы, не иначе.
Я часто замечаю что ограничения навязанные технологиями проектирования БД, а так же логика людей с техническим образованием отличается от логики пользователей гуманитариев.
По поводу МВЗ вот есть МВЗ на каждую из 10ти машин и на эти мвз сыпятся затраты по десяткам договоров и различных работ, регламентные работы, техническое обслуживание, ремонты и т.д. А финансовый директор хочет сметы на конкретную работу или например посмотреть пропалты по конкретному договору, а с поставщиком заключено несколько договоров: на поставку, на ремонт, на обслуживание и в САПе они тупо висят все на поставщике. После чего делают выгрузку в эксель и руками сортируют, что к чему относится к какому договру, что уже дебиторка, а что аванс.tessob
23.11.2016 15:18Если нужно выделить отдельные работы внутри МВЗ, то можно создать «внутренние заказы» (как самый простой способ), учесть затрат на них, а в конце месяца рассчитать их на МВЗ. В результате все будет аккуратно.
Проплаты по конкретному договору в SAP в 90% случаев не посмотреть никак. Есть ряд причин. Регистрация платежа в системе связывает его с кредитором, но не договором. Привязать платеж к договору можно, но это не решит проблему с большими сметами, когда не понятно за какие позиции уже заплатили, а за какие нет. Это не проблема SAP, а просто другая философия. Половина мира так работает. Тут проблема скорее в том, что ваше руководство не готово пересмотреть подходы к управлению.
Ananiev_Genrih
23.11.2016 14:21Да, считает. Если бы в УУ оперировали только издержками, экономистам жилось бы куда проще))
Более того, УУ зачастую живет и прогнозами ибо ТОПам в принятии решений важен сценарный подходtessob
23.11.2016 15:02Я конечно извиняюсь, но действия экономистов, как и бухгалтеров, слабо связаны с успехами или неуспехами бизнеса. Просто потому, что они ни на что не влияют. И их беды и чаянья в реальности мало кого беспокоят. Эти люди сидят и выполняют механическую работу в которой нет места творчеству.
А ТОПам нужны планы, а не прогнозы. Их интересует то, что компания собирается предпринимать и какие результаты это принесет. Невозможно достоверно спрогнозировать вывод нового продукта, открытие нового рынка, смену ассортимента, т.к. в таких сценариях нет никаких исторических данных. Не к чему применять модели.
knagaev
23.11.2016 15:26Вот вы же сами и привели ссылку, по которой явно видно, что УУ (или MA, как угодно) является не просто Cost Accounting (см. картинку IFAC Definition of enterprise financial management)
Там стрелочка от Cost Accounting к Financial Accounting (грубо говоря, бухгалтерии).
А Managerial Accounting стоит на Cost Measurement (где Cost Accounting только одна из трёх составляющих) и Non-financial data capture.
Бизнес невозможно измерить только учётом затрат, это же очевидно.
А вы можете дать своё определение УУ?
Или вернее просто написать что вы понимаете под этим.
Может мы просто разговариваем в разных системах координат, и тогда обсуждать можно очень долго и безрезультатно.tessob
23.11.2016 15:37Ваши слова «Управленческий учёт — это совсем не учёт затрат»? Я просто привел ссылку указывающую на то, что фраза ошибочна.
У меня нет собственного определения УУ. По большей части для меня это синоним Cost Accounting.knagaev
23.11.2016 15:48+1Мои слова означали «между УУ и учётом затрат нельзя поставить знак равенства».
Можно ведь сказать «слон — это совсем не хобот и уши»?
Я так прореагировал, потому что насмотрелся на практике как многие «эффективные менеджеры» пытаются управлять предприятием, пользуясь бухгалтерскими данными (или Cost Accounting по вашему определению).
По второму пункту — если вы вводите собственные определения (не совпадающие с общепринятыми) и пользуетесь ими в полемике, то конструктивно обсудить что-либо с вами не получится.tessob
23.11.2016 15:58-1С чего Вы взяли, что ваша позиция общепринятая? Вы методы управленческого учета, по той ссылке, что я Вам дал, прочли? Там есть что-то кроме учета затрат?
knagaev
23.11.2016 16:20+1А кроме вопросов вы что-нибудь можете написать?
Но отвечу всё-таки, в конце концов, хабровчане читают, надеюсь, не впустую пишу.
С чего Вы взяли, что ваша позиция общепринятая?
Потому что довольно продолжительное время работал в этой сфере, обсуждал эти проблемы с другими профессионалами.
Вы методы управленческого учета, по той ссылке, что я Вам дал, прочли?
Да, я знаю их. А вы?
Там есть что-то кроме учета затрат?
Есть.
Чтобы не упрекнули меня в неправильной формулировке, вот прямая цитата по «вашей» ссылке
Tasks/services provided
Listed below are the primary tasks/services performed by management accountants. The degree of complexity relative to these activities are dependent on the experience level and abilities of any one individual.
Rate and volume analysis
Business metrics development
Price modeling
Product profitability
Geographic vs. industry or client segment reporting
Sales management scorecards
Cost analysis
Cost–benefit analysis
Cost-volume-profit analysis
Life cycle cost analysis
Client profitability analysis
IT cost transparency
Capital budgeting
Buy vs. lease analysis
Strategic planning
Strategic management advice
Internal financial presentation and communication
Sales forecasting
Financial forecasting
Annual budgeting
Cost allocation
Посчитайте сколько там задач подходит под учёт затрат и сколько нет.
Я вам тоже ссылку дам Управленческий учет
Почитайте на досуге, много интересного для себя откроете.
Смотреть на мир, ограничиваясь рамками SAP, не стоит — он более многообразен.
tessob
23.11.2016 16:57-1Потому что довольно продолжительное время работал в этой сфере, обсуждал эти проблемы с другими профессионалами.
Ойййёё… Хорошо, записывайте себе безоговорочную победу.knagaev
23.11.2016 16:59+1Смишно вы написали :)
Хотите, возьмите «победу» себе.
Только главная проблема не будет решена — не хотите за деревьями леса видеть.
Archi_Pro
23.11.2016 13:34Мое воображение не такое богатое к сожалению и базируется по большей части на производственном опыте.
Про склад и бухгалтерию — это я видел у одного ритейлера.
Про управленческий учет это на одном производственном предприятии где у меня был практический опыт работы в SAP R3 в качестве пользователя.
Например у нас на ремонте стояло несколько машин на заводе и со склада шло огромное количество ТМЦ на ремонт в качестве давальческого сырья заводу, а в плановом отделе люди вручную делали таблички для фин дира сколько всего ушло на конкретную машину.
Какие прогнозы? да в принципе, что фин диру будет угодно: динамику дебиторки, прогноз по выручке и это не говоря о прогнозе спроса на товары на складе.tessob
23.11.2016 14:03Понятно, что вопросы и претензии по технической реализации тут явно не к Вам, но для этих целей обычно используются сервисные/производственные заказы, которые связанны с машинами, либо машины заводятся как отдельные МВЗ/внутренние заказы и списание ТМЦ осуществляется на уже на них. В общем, с технической реализацией вам, похоже, не повезло. ;))
Давайте на чистоту. Для динамики дебиторки никакие хитромудрые средства не нужны. Там даже калькулятор не нужен. Прогноз по выручке и спросу можно делать вообще как угодно. На практике там довольно сложно ухудшить результат. Вы просто физически не затолкаете в модель все метрики, чтобы она учитывала в прогнозе Ваши планы. А без этого ценность таких прогнозов довольно низкая.Archi_Pro
23.11.2016 14:10да, Вы абсолютно правы во всем, и с тем что не повезло и стем что МВЗ.
МВЗ заводилось позже и списания ТМЦ происходили на несколько месяцев позже чем фактически были установлены на машины, когда бухгалтерия получала акт с завода.
На счет прогнозов по выручке и спросу я с Вами не соглашусь, прогноз спроса на ретроспективных данных штука нетривиальная, а вот штрафы за завышенные/заниженные показатели прогноза были весьма реальные.tessob
23.11.2016 14:45И вы реально строили прогноз на регрессионных моделях в R или подобных средствах? Какой подход вы использовали, если не секрет?
Просто я на практике всего дважды встречал применение более умного подхода, чем простое копирование предыдущего периода с умножением на какой-либо коэффициент. В одном случае это была линейная регрессия в матлабе, во втором временные ряды в Excel.
Можете не отвечать, но описанное Вами предприятие никак не связано с железными дорогами?Archi_Pro
23.11.2016 14:55Прогноз строил в R, прогноз показателей временного ряда по модели ARIMA.
Описанное мною предприятие занято грузовыми авиа перевозками.
i_shutov
22.11.2016 22:58И, поскольку это все настоящие кейсы, перед публикацией я получил согласие на размещение материалов у коллег. Если что-то огласить будет нельзя, увы, значит нельзя.
Archi_Pro
23.11.2016 12:35спасибо что делитесь с сообществом практическим опытом.
Не так давно стал интересоваться R и всегда с интересом читаю Ваши посты.
В данном случае очень заинтересовал кейс №3.
a_agarkov
22.11.2016 22:46Сase #2 напомнил эпизод "Как Яндекс металлургам помогал" канала Компьютерные науки. Они тоже в одном из приближений в решении задачи использовали Random Forests. В том случае, правда, понадобилось техническое решение, которое было бы более интерпретируемо, чем результаты вычислений при помощи RF.
i_shutov
22.11.2016 22:51И замечательно. Физические законы везде одинаковы, математика — язык физики, человечество тысячи лет шло к тому, чтобы абстрагироваться от частностей и находить общее, например, между пузырьками пива в стакане и полетом самолета через построение моделей на абстрактном языке математики. Только нас экзерсизы с цифрами не интересовали сами по себе, но как руководство к управлению физическими параметрами контролируемых объектов.
i_shutov
22.11.2016 22:55В отличие от нейронных сетей, RF очень хорошо сопрягается с качественной моделью физики технологического процесса. Аналитику построить трудно, но набор значимых критериев автоматически совпал с тем, что являлось значимым с точки зрения физики.
a_agarkov
23.11.2016 00:30Хорошо, когда специфика производства позволяет воспользоваться таким решением.
a_agarkov
23.11.2016 00:36А можете поподробнее рассказать, как делали параллелизацию web-запросов и многоядерной обработки? Кроме этого интересно было бы посмотреть, как Вы future используете.
i_shutov
23.11.2016 09:43+2Саму параллелизацию делали через
foreach, примерно так:
enreach_doc <- function(docID) { # формируем url запроса req_str1 <- "http://www_____/?beanMethod=getDocument&queryId=" req_str3 <- "&documId=" req_str4 <- "&checkBoxes=&fromUserId=54" # ............ ur1 <- str_c(req_str1, req_str2, req_str3, docID, req_str4, collapse = "") resp <- GET(ur1) resp_status <- resp$status_code # проводим обработку контента flog.info(paste0("Parsing documentId = ", docID, " HTTP Status Code = ", resp_status)) # ............ } # ----------------- nworkers <- detectCores() - 1 registerDoParallel(nworkers) getDoParWorkers() descriptions <- foreach(docID=iter(doc_registry$docID), .packages=c('xml2', 'rvest', 'futile.logger', 'stringi', 'stringr', 'jsonlite', 'tibble', 'magrittr', 'curl', 'httr'), .combine=rbind) %dopar% { enreach_doc(docID) } registerDoSEQ() # unregister-a-doparallel-cluster
Насчет
future— использовали только для одной микрозадачки, когда данные по документу надо было выцепить с двух страничек. Запустили это в параллель черезfuture, а потом собрали черезvalues().
Ничего серьезного, два подобных
future:
data_future <- future({ response <- GET("http://wwww.yyy.com") parse_X(content(response, as = "text")) }) %plan% multiprocess
Ananiev_Genrih
23.11.2016 09:40Илья, приветствую.
Как обычно — рад «вестям с полей», мало кто в рунете пишет про R в реалиях бизнес-процессов, все больше студенческие проекты и частные эксперименты.
По #1 так же пришлось парсить один ресурс под скачивание 46000 номенклатурных позиций для создания мастер-данных БД. К счастью то же обошлось без Селениум, и набор пакетов был скромнее ибо простой постраничный вывод (более 2000 страниц): обошелся только rvest +dplyr
По #2: не увидел в пакетах e1071 или caret. как тюнинговались mtry и ntrees? через tuneRF?i_shutov
23.11.2016 09:49Генрих, рад слышать.
Отвечаю честно. На практике все оказалось гораздо прозаичнее. Пока даже не стали тюнинговать.
Увидели, что задача потенциально решается на раз-два, а актуальная проблема скрыта в сборе данных, слишком редко и есть местами ручной ввод, а значит, человеческий фактор. Поэтому пока переключились на промышленный IoT, а это все отложили в виде пилотной модели в сторону.
Но это тоже неплохо, поскольку позволило вскрыть реально узкие места (а не надуманные) и сфокусироваться на важном.
K-D-K
23.11.2016 15:54+2По 3 кейсу, являюсь постановщиком задачи, могу прокоментировать пару моментов.
1. Предметная область — проектирование и строительство.
2. САП это конечно хорошо, хорошо для глобальных задач, а ещё лучше для германии… его «стандарты» незыблемы, а возможности и стоимость безграничны. А вот для текущих и повседневных задач запрягать САП со всеми его бесконечными консультантами, проектным офисом, Фэо, Фт, Рп, мрд, ПИ и ОП как-то не с руки, затраты в первую очередь по срокам не сопоставимы с требуемым результатом.
3. Задача банальна, есть отчёт который нужно проверить, есть различные учетные системы откуда можно взять информацию для поверки (статусы, контрольные суммы и прочая информация). Но:
— Разные платформы и степень детализации.
— Отчётов много, позиций тысячи.
— Человеческий фактор, ошибки могут быть везде.
— Необходимо отслеживать и учитывать изменения показателей во времени.tessob
23.11.2016 17:30Задача была просто проверить отчет!? Тогда вопрос, а зачем вы написали отчет, который нужно проверять какими-либо внешними средствами? Может стоило просто его переписать по-человечески?
Я то думал… О_оi_shutov
23.11.2016 17:56Смотрите, у Вас по тексту постоянно одни вопросы, а вопросы других участников Вы игнорируете. Может ответите?
Я, например, так и не увидел никакой реакции на мой вопрос: Кстати, может у Вас есть задача, которую предположительно можно решить средствами R? Выложите на дропбокс все исходники и потроха, а сюда ссылку на них, сообща можно будет подумать над решением.
Кстати, а что именно Вы думали? Поделитесь, вдруг окажется полезным.
Мы же здесь обмениваемся опытом и мнениями, что фактически является win-win взаимодействием.tessob
23.11.2016 18:17Задачи которые можно было бы решать в R:
1. Всегда успешно решается средствами машинного обучения — удаление/поиск дубликатов в справочниках материалов и контрагентов. Для многих крупных компаний это проблема, особенно, если НСИ ведут сами пользователи, а не отдельная группа.
2. Хорошо показал себя наивный байес при расследовании систематического воровства на складах. Байес, т.к. легко интерпретировать модели.
В остальном внятных реализаций, применимых к ERP, я не встречал. Маркетингом я не занимаюсь, возможно там картина лучше. Про ремонты и прогнозирование отказов лучше не начинайте. ;))
K-D-K
23.11.2016 17:40Для знакомства с возможностями R этой задачи достаточно. Цель была апробировать новый инструмент, а не оптимизировать текущие бизнес-процессы.
ikashnitsky
Большую часть подгружаемых пакетов можно вызвать одной строкой
library(tidyverse)Это прекрасный свежий пакет от Hadley/RStudio. Подробнее можно почитать в блоге RStudio, в репозитории github или в документации SO.