Pull to refresh

Comments 54

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

Ну если помнить об этих граблях, можно при необходимости писать полностью, типа stats::filter()

Ага, я про это и говорил.

Я правильно понимаю, что все кейсы — это плод фантазии автора и предметные вопросы не уместны? Просто все три кейса «слегка» оторваны от реальности.

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


И привязано это к реальности ближе некуда. Фантазии — это работа социологов, пророчивших победу Клинтон.

По всем трем кейсам Вы не написали какую задачу решали и какого качества результат получили.

Что за отрасль во втором кейсе? У меня в голове не складывается двухчасовой производственный цикл, при котором успевают провести «пресс, формование, хим. обработка, нагрев» и при этом потребить «не одну тонну сырья».

Я правильно понимаю, что источником данных в третьем кейсе является ERP? Если так, то какие «данные из разных источников» Вы там нашли и что с чем сверяли? Просто интересно. Кроме того не понятно почему вместо целой кучи нативных OLAP и отчетных систем решили использовать R с интерфейсом через Excel.

Да, и фактов никаких в Вашем посте нет. Так что посыл в заключении слегка не корректный.

Case #1 — выполненный в срок и с должным качеством аналитический отчет, предполагаемый к исполнению в рамках контракта.


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


Case #3 — все написано в тексте. SAP + Access + разные Excel с данными ручного ввода + в планах сканы отчетной кипы документов (их надо будет выверять на корректность распознавания через кросс-проверки).
А вопрос "Почему?" — не научный. "Потому что так сложилось". Это просто вот такая реальность с которой имеем дело. От нативных OLAP толку нет никакого, поскольку данные находятся в различных источниках, они грязные и разноформатные, а проверки не просто суммы, но и многоэтапный анализ, включая анализ текстов. Кросс-проверки различные, из элементарных, например, данные в двух разных источниках по одинаковым статьям должны совпадать как по названию, так и по совокупным суммам за заданный период, с учетом доп. данных из третьего источника, а также с учетом исключений, определяемых дополнительно…
А Вы знаете сколько будет стоить такая доработка руками САП-еров? (это их оценка 5-7 лет, но понятно, что они заняты и основными задачами).


Я здесь поделился задачами, которые трудны для обычных подходов (Excel\BI), но, как оказывается, легко решаются только средствами R, про который многие думают, что он применим только для стат.вычислений… Основная цель — показать, что есть такая тропка и ходить по ней можно. Кто хочет — может пойти, кто не хочет — насильно никто не тянет. Времени на убеждение сомневающихся у меня нет, а желающих пойти с каждой публикацией все больше.

Case #2. В таком случае, я позволю себе не поверить в достоверность данного кейса.

Case #3. К вашему сведению, SAP — это компания, которая выпускает огромный зоопарк различных продуктов. Именно по этой причине я и попросил уточнить какой из них Вы имеете в виду. И пожалуйста подробнее, что это за данные такие «данные находятся в различных источниках, они грязные и разноформатные». Кто их испачкал и чем?

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

Статьи чего? Что за разные источники? Это вообще какой хозяйственный процесс? Что вы сделать-то пытались?

Я знаю сколько стоят доработки в SAP.

Case #2. Поскольку частные детали пока публично озвучить нельзя, то можете не верить. Реальность от этого не изменится.


Case #3. Общий вектор: оперативный анализ проектной деятельности большой компании + анализ проектных рисков. Анализ в разных плоскостях, в т.ч. и финансово учетной плоскости. Бумажные сметы обычно пачкают маслом. Фамилий испачкавших не знаю.

Case #3. Я так понимаю, что реальность мы снова не изменим.

В общем, как я в начале и написал, предметные вопросы оказались не уместны. ЧТД.

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

Отнюдь. Просто весь Ваш пост выполнен в стиле: «Российские ученые разработали новое мощнейшее сверхсекретное оружие, основанное на принципиально новых физических принципах». Воспринимать это всерьез просто не возможно. Если к этому добавить, используемую Вами терминологию и расставляемые акценты, то картина становится еще более драматичной.

Пусть будет так.


Кстати, может у Вас есть задача, которую предположительно можно решить средствами R? Выложите на дропбокс все исходники и потроха, а сюда ссылку на них, сообща можно будет подумать над решением. Решенная задача будет служить лучшим подтверждением.


P.S. "невозможно" пишется слитно, а в описании стиля пропустили слово "опенсорсное" оружие.

По кейсу 3 очень живо себе представляю:
Склад работает на acces,
Бухгалтерия на SAP,
Управленческий учет в Exel.
Финансовый директор хочет иметь отчет какой то определенной формы где нажо свести данные из этих 3 источников + построить прогноз
Мое воображение видимо уступает Вашему.

Если мы говорим про SAP ERP, то материальный учет там будет реализован в любом случае, т.к., согласно нормам БУ, учет материалов ведется в стоимостном и натуральном выражении. Соответственно, на правах абсурда, в Access можно вести только адресное хранение материалов, которое уже есть в стандартной функциональности ERP (WMS) и его достаточно просто активировать. Далее. Что вы понимаете под управленческим учетом? Если учет затрат, то в ERP это реализовано. Если что-то свое, то что?

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

У вас точно есть прикладной опыт работы с ERP системами?
Управленческий учёт — это совсем не учёт затрат :)
Он как раз и используется для оперативной оценки обстановки и прогнозов.
Кто-то кроме Вас так считает?

https://en.wikipedia.org/wiki/Management_accounting
Посмотрите методологии. Costing — это учет затрат. В SAP ERP значительная часть этого реализуется в модуле CO.
SAP — чудесная вещь, кто же спорит, но помимо бухгалтерского и складского учета существуют еще много всего забавного, например контроллинг.
Вот идея с контроллингом появилась с новым финдиром, сап внедряли при предыдущем, так и появился целый отдел с экселем. Или вот план движения денежных средств то же никто в сапе не делал, а исключительно в экселе причем у каждого департамента свой отдельный файлик заполненный с любовью и ошибками.
Модуль СО из предыдущего поста — это и есть контроллинг. Контроллинг в SAP учитывает затраты и выручку. Ничего другого он не делает.

В здравом уме в SAP-CO учет движения денежных средств не делают, просто потому, что ДДС прямого отношения к затратам не имеет. Систему проектировали наркоманы, не иначе. Проблемы с файликами — это уже следствие другой, гораздо большей проблемы.
Систему проектировали наркоманы, не иначе.
Я часто замечаю что ограничения навязанные технологиями проектирования БД, а так же логика людей с техническим образованием отличается от логики пользователей гуманитариев.
По поводу МВЗ вот есть МВЗ на каждую из 10ти машин и на эти мвз сыпятся затраты по десяткам договоров и различных работ, регламентные работы, техническое обслуживание, ремонты и т.д. А финансовый директор хочет сметы на конкретную работу или например посмотреть пропалты по конкретному договору, а с поставщиком заключено несколько договоров: на поставку, на ремонт, на обслуживание и в САПе они тупо висят все на поставщике. После чего делают выгрузку в эксель и руками сортируют, что к чему относится к какому договру, что уже дебиторка, а что аванс.
Если нужно выделить отдельные работы внутри МВЗ, то можно создать «внутренние заказы» (как самый простой способ), учесть затрат на них, а в конце месяца рассчитать их на МВЗ. В результате все будет аккуратно.

Проплаты по конкретному договору в SAP в 90% случаев не посмотреть никак. Есть ряд причин. Регистрация платежа в системе связывает его с кредитором, но не договором. Привязать платеж к договору можно, но это не решит проблему с большими сметами, когда не понятно за какие позиции уже заплатили, а за какие нет. Это не проблема SAP, а просто другая философия. Половина мира так работает. Тут проблема скорее в том, что ваше руководство не готово пересмотреть подходы к управлению.
Да, считает. Если бы в УУ оперировали только издержками, экономистам жилось бы куда проще))
Более того, УУ зачастую живет и прогнозами ибо ТОПам в принятии решений важен сценарный подход
Я конечно извиняюсь, но действия экономистов, как и бухгалтеров, слабо связаны с успехами или неуспехами бизнеса. Просто потому, что они ни на что не влияют. И их беды и чаянья в реальности мало кого беспокоят. Эти люди сидят и выполняют механическую работу в которой нет места творчеству.

А ТОПам нужны планы, а не прогнозы. Их интересует то, что компания собирается предпринимать и какие результаты это принесет. Невозможно достоверно спрогнозировать вывод нового продукта, открытие нового рынка, смену ассортимента, т.к. в таких сценариях нет никаких исторических данных. Не к чему применять модели.
в сценарном подходе и не нужны исторические данные
Вот вы же сами и привели ссылку, по которой явно видно, что УУ (или MA, как угодно) является не просто Cost Accounting (см. картинку IFAC Definition of enterprise financial management)
Там стрелочка от 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 в качестве пользователя.
Например у нас на ремонте стояло несколько машин на заводе и со склада шло огромное количество ТМЦ на ремонт в качестве давальческого сырья заводу, а в плановом отделе люди вручную делали таблички для фин дира сколько всего ушло на конкретную машину.
Какие прогнозы? да в принципе, что фин диру будет угодно: динамику дебиторки, прогноз по выручке и это не говоря о прогнозе спроса на товары на складе.
Понятно, что вопросы и претензии по технической реализации тут явно не к Вам, но для этих целей обычно используются сервисные/производственные заказы, которые связанны с машинами, либо машины заводятся как отдельные МВЗ/внутренние заказы и списание ТМЦ осуществляется на уже на них. В общем, с технической реализацией вам, похоже, не повезло. ;))

Давайте на чистоту. Для динамики дебиторки никакие хитромудрые средства не нужны. Там даже калькулятор не нужен. Прогноз по выручке и спросу можно делать вообще как угодно. На практике там довольно сложно ухудшить результат. Вы просто физически не затолкаете в модель все метрики, чтобы она учитывала в прогнозе Ваши планы. А без этого ценность таких прогнозов довольно низкая.
да, Вы абсолютно правы во всем, и с тем что не повезло и стем что МВЗ.
МВЗ заводилось позже и списания ТМЦ происходили на несколько месяцев позже чем фактически были установлены на машины, когда бухгалтерия получала акт с завода.
На счет прогнозов по выручке и спросу я с Вами не соглашусь, прогноз спроса на ретроспективных данных штука нетривиальная, а вот штрафы за завышенные/заниженные показатели прогноза были весьма реальные.
И вы реально строили прогноз на регрессионных моделях в R или подобных средствах? Какой подход вы использовали, если не секрет?

Просто я на практике всего дважды встречал применение более умного подхода, чем простое копирование предыдущего периода с умножением на какой-либо коэффициент. В одном случае это была линейная регрессия в матлабе, во втором временные ряды в Excel.

Можете не отвечать, но описанное Вами предприятие никак не связано с железными дорогами?
Прогноз строил в R, прогноз показателей временного ряда по модели ARIMA.
Описанное мною предприятие занято грузовыми авиа перевозками.

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

спасибо что делитесь с сообществом практическим опытом.
Не так давно стал интересоваться R и всегда с интересом читаю Ваши посты.
В данном случае очень заинтересовал кейс №3.
Сase #2 напомнил эпизод "Как Яндекс металлургам помогал" канала Компьютерные науки. Они тоже в одном из приближений в решении задачи использовали Random Forests. В том случае, правда, понадобилось техническое решение, которое было бы более интерпретируемо, чем результаты вычислений при помощи RF.

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

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

Хорошо, когда специфика производства позволяет воспользоваться таким решением.
Снимаю шляпу! Никогда не мог понять как люди могут объять необъятное
А можете поподробнее рассказать, как делали параллелизацию web-запросов и многоядерной обработки? Кроме этого интересно было бы посмотреть, как Вы future используете.

Саму параллелизацию делали через 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, а это все отложили в виде пилотной модели в сторону.


Но это тоже неплохо, поскольку позволило вскрыть реально узкие места (а не надуманные) и сфокусироваться на важном.

По 3 кейсу, являюсь постановщиком задачи, могу прокоментировать пару моментов.
1. Предметная область — проектирование и строительство.
2. САП это конечно хорошо, хорошо для глобальных задач, а ещё лучше для германии… его «стандарты» незыблемы, а возможности и стоимость безграничны. А вот для текущих и повседневных задач запрягать САП со всеми его бесконечными консультантами, проектным офисом, Фэо, Фт, Рп, мрд, ПИ и ОП как-то не с руки, затраты в первую очередь по срокам не сопоставимы с требуемым результатом.
3. Задача банальна, есть отчёт который нужно проверить, есть различные учетные системы откуда можно взять информацию для поверки (статусы, контрольные суммы и прочая информация). Но:
— Разные платформы и степень детализации.
— Отчётов много, позиций тысячи.
— Человеческий фактор, ошибки могут быть везде.
— Необходимо отслеживать и учитывать изменения показателей во времени.
Задача была просто проверить отчет!? Тогда вопрос, а зачем вы написали отчет, который нужно проверять какими-либо внешними средствами? Может стоило просто его переписать по-человечески?

Я то думал… О_о

Смотрите, у Вас по тексту постоянно одни вопросы, а вопросы других участников Вы игнорируете. Может ответите?


Я, например, так и не увидел никакой реакции на мой вопрос: Кстати, может у Вас есть задача, которую предположительно можно решить средствами R? Выложите на дропбокс все исходники и потроха, а сюда ссылку на них, сообща можно будет подумать над решением.


Кстати, а что именно Вы думали? Поделитесь, вдруг окажется полезным.
Мы же здесь обмениваемся опытом и мнениями, что фактически является win-win взаимодействием.

Задачи которые можно было бы решать в R:
1. Всегда успешно решается средствами машинного обучения — удаление/поиск дубликатов в справочниках материалов и контрагентов. Для многих крупных компаний это проблема, особенно, если НСИ ведут сами пользователи, а не отдельная группа.
2. Хорошо показал себя наивный байес при расследовании систематического воровства на складах. Байес, т.к. легко интерпретировать модели.

В остальном внятных реализаций, применимых к ERP, я не встречал. Маркетингом я не занимаюсь, возможно там картина лучше. Про ремонты и прогнозирование отказов лучше не начинайте. ;))
Для знакомства с возможностями R этой задачи достаточно. Цель была апробировать новый инструмент, а не оптимизировать текущие бизнес-процессы.
Sign up to leave a comment.

Articles