Комментарии 54
Технические детали
Большую часть подгружаемых пакетов можно вызвать одной строкой
library(tidyverse)
Это прекрасный свежий пакет от Hadley/RStudio. Подробнее можно почитать в блоге RStudio, в репозитории github или в документации SO.
Это точно, обсуждали в комментариях к прошлым публикациям. Но я все равно предпочитаю ручками подгружать. А иногда и явно адресное пространство указывать. Не помню на чем, но наступил на грабли перекрывающихся имён. На чистой системе R стал ругаться на рабочий скрипт. Поскольку знал об этом, проблем не возникло, все бныстро локализовал и развёл, но новичка может смутить.
Нет, неправильно.
Это конкретные кейсы конкретных людей, в т.ч. бывающих на хабре. Задавайте вопросы, что смогу — отвечу, что потребует раскрытия закрытой инфы, надеюсь ответят сами коллеги.
И привязано это к реальности ближе некуда. Фантазии — это работа социологов, пророчивших победу Клинтон.
Что за отрасль во втором кейсе? У меня в голове не складывается двухчасовой производственный цикл, при котором успевают провести «пресс, формование, хим. обработка, нагрев» и при этом потребить «не одну тонну сырья».
Я правильно понимаю, что источником данных в третьем кейсе является ERP? Если так, то какие «данные из разных источников» Вы там нашли и что с чем сверяли? Просто интересно. Кроме того не понятно почему вместо целой кучи нативных OLAP и отчетных систем решили использовать R с интерфейсом через Excel.
Да, и фактов никаких в Вашем посте нет. Так что посыл в заключении слегка не корректный.
Case #1 — выполненный в срок и с должным качеством аналитический отчет, предполагаемый к исполнению в рамках контракта.
Case #2 — как я писал, открыть детали по отрасли не могу. результат указал ниже — инструмент найден, а реальная задача переехала в область улучшения измерений.
Case #3 — все написано в тексте. SAP + Access + разные Excel с данными ручного ввода + в планах сканы отчетной кипы документов (их надо будет выверять на корректность распознавания через кросс-проверки).
А вопрос "Почему?" — не научный. "Потому что так сложилось". Это просто вот такая реальность с которой имеем дело. От нативных OLAP толку нет никакого, поскольку данные находятся в различных источниках, они грязные и разноформатные, а проверки не просто суммы, но и многоэтапный анализ, включая анализ текстов. Кросс-проверки различные, из элементарных, например, данные в двух разных источниках по одинаковым статьям должны совпадать как по названию, так и по совокупным суммам за заданный период, с учетом доп. данных из третьего источника, а также с учетом исключений, определяемых дополнительно…
А Вы знаете сколько будет стоить такая доработка руками САП-еров? (это их оценка 5-7 лет, но понятно, что они заняты и основными задачами).
Я здесь поделился задачами, которые трудны для обычных подходов (Excel\BI), но, как оказывается, легко решаются только средствами R, про который многие думают, что он применим только для стат.вычислений… Основная цель — показать, что есть такая тропка и ходить по ней можно. Кто хочет — может пойти, кто не хочет — насильно никто не тянет. Времени на убеждение сомневающихся у меня нет, а желающих пойти с каждой публикацией все больше.
Case #3. К вашему сведению, SAP — это компания, которая выпускает огромный зоопарк различных продуктов. Именно по этой причине я и попросил уточнить какой из них Вы имеете в виду. И пожалуйста подробнее, что это за данные такие «данные находятся в различных источниках, они грязные и разноформатные». Кто их испачкал и чем?
Эта фраза вызывает у меня полнейший когнитивный диссонанс: «Кросс-проверки различные, из элементарных, например, данные в двух разных источниках по одинаковым статьям должны совпадать как по названию, так и по совокупным суммам за заданный период, с учетом доп. данных из третьего источника, а также с учетом исключений, определяемых дополнительно…»
Статьи чего? Что за разные источники? Это вообще какой хозяйственный процесс? Что вы сделать-то пытались?
Я знаю сколько стоят доработки в SAP.
Case #2. Поскольку частные детали пока публично озвучить нельзя, то можете не верить. Реальность от этого не изменится.
Case #3. Общий вектор: оперативный анализ проектной деятельности большой компании + анализ проектных рисков. Анализ в разных плоскостях, в т.ч. и финансово учетной плоскости. Бумажные сметы обычно пачкают маслом. Фамилий испачкавших не знаю.
В общем, как я в начале и написал, предметные вопросы оказались не уместны. ЧТД.
Вы надеялись увидеть весь пакет исходных документов, сырья и бизнес-процессов? Конечно же этого не будет, можно было и не спрашивать.
Пусть будет так.
Кстати, может у Вас есть задача, которую предположительно можно решить средствами R? Выложите на дропбокс все исходники и потроха, а сюда ссылку на них, сообща можно будет подумать над решением. Решенная задача будет служить лучшим подтверждением.
P.S. "невозможно" пишется слитно, а в описании стиля пропустили слово "опенсорсное" оружие.
Склад работает на acces,
Бухгалтерия на SAP,
Управленческий учет в Exel.
Финансовый директор хочет иметь отчет какой то определенной формы где нажо свести данные из этих 3 источников + построить прогноз
Если мы говорим про SAP ERP, то материальный учет там будет реализован в любом случае, т.к., согласно нормам БУ, учет материалов ведется в стоимостном и натуральном выражении. Соответственно, на правах абсурда, в Access можно вести только адресное хранение материалов, которое уже есть в стандартной функциональности ERP (WMS) и его достаточно просто активировать. Далее. Что вы понимаете под управленческим учетом? Если учет затрат, то в ERP это реализовано. Если что-то свое, то что?
Что касается построения прогноза, то что полезного вы можете спрогнозировать на основе бухгалтерии и запасов?
У вас точно есть прикладной опыт работы с ERP системами?
Он как раз и используется для оперативной оценки обстановки и прогнозов.
https://en.wikipedia.org/wiki/Management_accounting
Посмотрите методологии. Costing — это учет затрат. В SAP ERP значительная часть этого реализуется в модуле CO.
Вот идея с контроллингом появилась с новым финдиром, сап внедряли при предыдущем, так и появился целый отдел с экселем. Или вот план движения денежных средств то же никто в сапе не делал, а исключительно в экселе причем у каждого департамента свой отдельный файлик заполненный с любовью и ошибками.
В здравом уме в SAP-CO учет движения денежных средств не делают, просто потому, что ДДС прямого отношения к затратам не имеет. Систему проектировали наркоманы, не иначе. Проблемы с файликами — это уже следствие другой, гораздо большей проблемы.
Я часто замечаю что ограничения навязанные технологиями проектирования БД, а так же логика людей с техническим образованием отличается от логики пользователей гуманитариев.
По поводу МВЗ вот есть МВЗ на каждую из 10ти машин и на эти мвз сыпятся затраты по десяткам договоров и различных работ, регламентные работы, техническое обслуживание, ремонты и т.д. А финансовый директор хочет сметы на конкретную работу или например посмотреть пропалты по конкретному договору, а с поставщиком заключено несколько договоров: на поставку, на ремонт, на обслуживание и в САПе они тупо висят все на поставщике. После чего делают выгрузку в эксель и руками сортируют, что к чему относится к какому договру, что уже дебиторка, а что аванс.
Проплаты по конкретному договору в SAP в 90% случаев не посмотреть никак. Есть ряд причин. Регистрация платежа в системе связывает его с кредитором, но не договором. Привязать платеж к договору можно, но это не решит проблему с большими сметами, когда не понятно за какие позиции уже заплатили, а за какие нет. Это не проблема SAP, а просто другая философия. Половина мира так работает. Тут проблема скорее в том, что ваше руководство не готово пересмотреть подходы к управлению.
Более того, УУ зачастую живет и прогнозами ибо ТОПам в принятии решений важен сценарный подход
А ТОПам нужны планы, а не прогнозы. Их интересует то, что компания собирается предпринимать и какие результаты это принесет. Невозможно достоверно спрогнозировать вывод нового продукта, открытие нового рынка, смену ассортимента, т.к. в таких сценариях нет никаких исторических данных. Не к чему применять модели.
Там стрелочка от Cost Accounting к Financial Accounting (грубо говоря, бухгалтерии).
А Managerial Accounting стоит на Cost Measurement (где Cost Accounting только одна из трёх составляющих) и Non-financial data capture.
Бизнес невозможно измерить только учётом затрат, это же очевидно.
А вы можете дать своё определение УУ?
Или вернее просто написать что вы понимаете под этим.
Может мы просто разговариваем в разных системах координат, и тогда обсуждать можно очень долго и безрезультатно.
У меня нет собственного определения УУ. По большей части для меня это синоним Cost Accounting.
Можно ведь сказать «слон — это совсем не хобот и уши»?
Я так прореагировал, потому что насмотрелся на практике как многие «эффективные менеджеры» пытаются управлять предприятием, пользуясь бухгалтерскими данными (или Cost Accounting по вашему определению).
По второму пункту — если вы вводите собственные определения (не совпадающие с общепринятыми) и пользуетесь ими в полемике, то конструктивно обсудить что-либо с вами не получится.
Но отвечу всё-таки, в конце концов, хабровчане читают, надеюсь, не впустую пишу.
С чего Вы взяли, что ваша позиция общепринятая?
Потому что довольно продолжительное время работал в этой сфере, обсуждал эти проблемы с другими профессионалами.
Вы методы управленческого учета, по той ссылке, что я Вам дал, прочли?
Да, я знаю их. А вы?
Там есть что-то кроме учета затрат?
Есть.
Чтобы не упрекнули меня в неправильной формулировке, вот прямая цитата по «вашей» ссылке
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, не стоит — он более многообразен.
Про склад и бухгалтерию — это я видел у одного ритейлера.
Про управленческий учет это на одном производственном предприятии где у меня был практический опыт работы в SAP R3 в качестве пользователя.
Например у нас на ремонте стояло несколько машин на заводе и со склада шло огромное количество ТМЦ на ремонт в качестве давальческого сырья заводу, а в плановом отделе люди вручную делали таблички для фин дира сколько всего ушло на конкретную машину.
Какие прогнозы? да в принципе, что фин диру будет угодно: динамику дебиторки, прогноз по выручке и это не говоря о прогнозе спроса на товары на складе.
Давайте на чистоту. Для динамики дебиторки никакие хитромудрые средства не нужны. Там даже калькулятор не нужен. Прогноз по выручке и спросу можно делать вообще как угодно. На практике там довольно сложно ухудшить результат. Вы просто физически не затолкаете в модель все метрики, чтобы она учитывала в прогнозе Ваши планы. А без этого ценность таких прогнозов довольно низкая.
МВЗ заводилось позже и списания ТМЦ происходили на несколько месяцев позже чем фактически были установлены на машины, когда бухгалтерия получала акт с завода.
На счет прогнозов по выручке и спросу я с Вами не соглашусь, прогноз спроса на ретроспективных данных штука нетривиальная, а вот штрафы за завышенные/заниженные показатели прогноза были весьма реальные.
Просто я на практике всего дважды встречал применение более умного подхода, чем простое копирование предыдущего периода с умножением на какой-либо коэффициент. В одном случае это была линейная регрессия в матлабе, во втором временные ряды в Excel.
Можете не отвечать, но описанное Вами предприятие никак не связано с железными дорогами?
И, поскольку это все настоящие кейсы, перед публикацией я получил согласие на размещение материалов у коллег. Если что-то огласить будет нельзя, увы, значит нельзя.
И замечательно. Физические законы везде одинаковы, математика — язык физики, человечество тысячи лет шло к тому, чтобы абстрагироваться от частностей и находить общее, например, между пузырьками пива в стакане и полетом самолета через построение моделей на абстрактном языке математики. Только нас экзерсизы с цифрами не интересовали сами по себе, но как руководство к управлению физическими параметрами контролируемых объектов.
В отличие от нейронных сетей, RF очень хорошо сопрягается с качественной моделью физики технологического процесса. Аналитику построить трудно, но набор значимых критериев автоматически совпал с тем, что являлось значимым с точки зрения физики.
Саму параллелизацию делали через 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
Как обычно — рад «вестям с полей», мало кто в рунете пишет про R в реалиях бизнес-процессов, все больше студенческие проекты и частные эксперименты.
По #1 так же пришлось парсить один ресурс под скачивание 46000 номенклатурных позиций для создания мастер-данных БД. К счастью то же обошлось без Селениум, и набор пакетов был скромнее ибо простой постраничный вывод (более 2000 страниц): обошелся только rvest +dplyr
По #2: не увидел в пакетах e1071 или caret. как тюнинговались mtry и ntrees? через tuneRF?
Генрих, рад слышать.
Отвечаю честно. На практике все оказалось гораздо прозаичнее. Пока даже не стали тюнинговать.
Увидели, что задача потенциально решается на раз-два, а актуальная проблема скрыта в сборе данных, слишком редко и есть местами ручной ввод, а значит, человеческий фактор. Поэтому пока переключились на промышленный IoT, а это все отложили в виде пилотной модели в сторону.
Но это тоже неплохо, поскольку позволило вскрыть реально узкие места (а не надуманные) и сфокусироваться на важном.
1. Предметная область — проектирование и строительство.
2. САП это конечно хорошо, хорошо для глобальных задач, а ещё лучше для германии… его «стандарты» незыблемы, а возможности и стоимость безграничны. А вот для текущих и повседневных задач запрягать САП со всеми его бесконечными консультантами, проектным офисом, Фэо, Фт, Рп, мрд, ПИ и ОП как-то не с руки, затраты в первую очередь по срокам не сопоставимы с требуемым результатом.
3. Задача банальна, есть отчёт который нужно проверить, есть различные учетные системы откуда можно взять информацию для поверки (статусы, контрольные суммы и прочая информация). Но:
— Разные платформы и степень детализации.
— Отчётов много, позиций тысячи.
— Человеческий фактор, ошибки могут быть везде.
— Необходимо отслеживать и учитывать изменения показателей во времени.
Я то думал… О_о
Смотрите, у Вас по тексту постоянно одни вопросы, а вопросы других участников Вы игнорируете. Может ответите?
Я, например, так и не увидел никакой реакции на мой вопрос: Кстати, может у Вас есть задача, которую предположительно можно решить средствами R? Выложите на дропбокс все исходники и потроха, а сюда ссылку на них, сообща можно будет подумать над решением.
Кстати, а что именно Вы думали? Поделитесь, вдруг окажется полезным.
Мы же здесь обмениваемся опытом и мнениями, что фактически является win-win взаимодействием.
1. Всегда успешно решается средствами машинного обучения — удаление/поиск дубликатов в справочниках материалов и контрагентов. Для многих крупных компаний это проблема, особенно, если НСИ ведут сами пользователи, а не отдельная группа.
2. Хорошо показал себя наивный байес при расследовании систематического воровства на складах. Байес, т.к. легко интерпретировать модели.
В остальном внятных реализаций, применимых к ERP, я не встречал. Маркетингом я не занимаюсь, возможно там картина лучше. Про ремонты и прогнозирование отказов лучше не начинайте. ;))
Еще примеры использования R для решения практических бизнес-задач