Через 2-3 года мир тупо скатится в Великую депрессию 2.0. ИТ просто начинает выносить первыми т.к. 99% компаний/стартапов не могут жить без внешних заимствований или очередных вливаний венчурного капитала. С начала года уже уволено больше 50К человек. Гугл и Микрософт просто самые крупные и на слуху, но их вклад в «кровавую баню» меньше половины.
Например — устный счёт во «внутреннем диалоге» (про себя). Для этого не надо задействовать никаких сенсорных систем. В принципе внутренний диалог сам по себе последователен, а «последовательность» это про время.
Сообщение, приведенное автором статьи в качестве примера, дает дополнительную информацию возможному злоумышленнику, например при подборе параметров аутентификации или переборе зарегистрированных пользователей.
В Германии ставка синиор фрилансера ~600 в день. При указанной в статье оплате, любой работающий результат — это уже какое-то чудо. Учитывая то, что за отведенное время нужно еще: получить догступ ко всей среде, разобраться в предыдущим кришнакоде, написать свой кришнакод, как-то все это протестировать, согласовать и задеплоить.
Вот ссылка на функциональный объем: help.sap.com/doc/6a2cd93857fd4973baa558931701afcd/1.0.3/en-US/index.html
Стоимость лицензии (одной) ~ $20'000. Минимальный пакет лицензий ~ 5 штук. Это в год, если что. Сравнение проводили ASUG (Americas' SAP Users' Group) год назад, но никаких преимуществ они не обнаружили. Увы.
Вообще SAP HANA на практике ухудшает производительность SAP, в сравнении с Oracle/DB2, а не улучшает ее. Но это уже другая история. ;))
Занимался подобной задачей некоторое время назад. Алгоритм Норвига удалось ускорить без потери качества оперевшись на предположении, что люди чаще совершают опечатки нажимая на соседние клавиши.
Суррогаты в большинстве случаев являются следствием того, что пациент приходит к доктору ужу со своими таблетками, просто подписать рецепт. Учитывая, что в отличии от медицины, в бизнесе каждая болячка уникальна, докторам просто лень углубляться в исследование проблемы, проще подписать и забыть «как страшный сон». В любом случае возникает паритет интересов — пациенты, получают то, что просят. Пускай даже то, что они просят — это не то, что им нужно.
В крупных транснациональных компаниях (100К+ сотрудников), там между пациентом и доктором будет еще прослойка из аналитика, бизнес консультанта, деливери-менеджера и прочей нечисти. Причем, как правило, данная прослойка не владеет ни проблематикой бизнеса, ни пониманием возможных путей технической реализации. В итоге, можно наблюдать как в тратятся миллионы евро на разработку целого вороха ERP/CRM/MES систем, а когда приходишь к пользователям, то все сидят в Excel. Там процесс создания суррогатов — это уже процесс сам в себе.
Кейс теоретический? Просто проблема выглядит очень странно через призму опыта работы в ритейлерах. Задача ритейлера «снимать» просрочку с реализации (убирать с полок), а не планировать спрос/потребление. Просто ритейл принимает товары на консигнацию. Кроме того, Вы как-то очень бодренько пробежались мимо вопроса выравнивания системы с «физикой». А это важно, т.к. данные в учетной системе — одна большая фикция между инвентаризациями.
Задачи которые можно было бы решать в R:
1. Всегда успешно решается средствами машинного обучения — удаление/поиск дубликатов в справочниках материалов и контрагентов. Для многих крупных компаний это проблема, особенно, если НСИ ведут сами пользователи, а не отдельная группа.
2. Хорошо показал себя наивный байес при расследовании систематического воровства на складах. Байес, т.к. легко интерпретировать модели.
В остальном внятных реализаций, применимых к ERP, я не встречал. Маркетингом я не занимаюсь, возможно там картина лучше. Про ремонты и прогнозирование отказов лучше не начинайте. ;))
Задача была просто проверить отчет!? Тогда вопрос, а зачем вы написали отчет, который нужно проверять какими-либо внешними средствами? Может стоило просто его переписать по-человечески?
С чего Вы взяли, что ваша позиция общепринятая? Вы методы управленческого учета, по той ссылке, что я Вам дал, прочли? Там есть что-то кроме учета затрат?
Если нужно выделить отдельные работы внутри МВЗ, то можно создать «внутренние заказы» (как самый простой способ), учесть затрат на них, а в конце месяца рассчитать их на МВЗ. В результате все будет аккуратно.
Проплаты по конкретному договору в SAP в 90% случаев не посмотреть никак. Есть ряд причин. Регистрация платежа в системе связывает его с кредитором, но не договором. Привязать платеж к договору можно, но это не решит проблему с большими сметами, когда не понятно за какие позиции уже заплатили, а за какие нет. Это не проблема SAP, а просто другая философия. Половина мира так работает. Тут проблема скорее в том, что ваше руководство не готово пересмотреть подходы к управлению.
Я конечно извиняюсь, но действия экономистов, как и бухгалтеров, слабо связаны с успехами или неуспехами бизнеса. Просто потому, что они ни на что не влияют. И их беды и чаянья в реальности мало кого беспокоят. Эти люди сидят и выполняют механическую работу в которой нет места творчеству.
А ТОПам нужны планы, а не прогнозы. Их интересует то, что компания собирается предпринимать и какие результаты это принесет. Невозможно достоверно спрогнозировать вывод нового продукта, открытие нового рынка, смену ассортимента, т.к. в таких сценариях нет никаких исторических данных. Не к чему применять модели.
И вы реально строили прогноз на регрессионных моделях в R или подобных средствах? Какой подход вы использовали, если не секрет?
Просто я на практике всего дважды встречал применение более умного подхода, чем простое копирование предыдущего периода с умножением на какой-либо коэффициент. В одном случае это была линейная регрессия в матлабе, во втором временные ряды в Excel.
Можете не отвечать, но описанное Вами предприятие никак не связано с железными дорогами?
Модуль СО из предыдущего поста — это и есть контроллинг. Контроллинг в SAP учитывает затраты и выручку. Ничего другого он не делает.
В здравом уме в SAP-CO учет движения денежных средств не делают, просто потому, что ДДС прямого отношения к затратам не имеет. Систему проектировали наркоманы, не иначе. Проблемы с файликами — это уже следствие другой, гораздо большей проблемы.
Понятно, что вопросы и претензии по технической реализации тут явно не к Вам, но для этих целей обычно используются сервисные/производственные заказы, которые связанны с машинами, либо машины заводятся как отдельные МВЗ/внутренние заказы и списание ТМЦ осуществляется на уже на них. В общем, с технической реализацией вам, похоже, не повезло. ;))
Давайте на чистоту. Для динамики дебиторки никакие хитромудрые средства не нужны. Там даже калькулятор не нужен. Прогноз по выручке и спросу можно делать вообще как угодно. На практике там довольно сложно ухудшить результат. Вы просто физически не затолкаете в модель все метрики, чтобы она учитывала в прогнозе Ваши планы. А без этого ценность таких прогнозов довольно низкая.
https://en.wikipedia.org/wiki/Management_accounting
Посмотрите методологии. Costing — это учет затрат. В SAP ERP значительная часть этого реализуется в модуле CO.
Через 2-3 года мир тупо скатится в Великую депрессию 2.0. ИТ просто начинает выносить первыми т.к. 99% компаний/стартапов не могут жить без внешних заимствований или очередных вливаний венчурного капитала. С начала года уже уволено больше 50К человек. Гугл и Микрософт просто самые крупные и на слуху, но их вклад в «кровавую баню» меньше половины.
Например — устный счёт во «внутреннем диалоге» (про себя). Для этого не надо задействовать никаких сенсорных систем. В принципе внутренний диалог сам по себе последователен, а «последовательность» это про время.
Сообщение, приведенное автором статьи в качестве примера, дает дополнительную информацию возможному злоумышленнику, например при подборе параметров аутентификации или переборе зарегистрированных пользователей.
За такие дегенеративные сообщения об ошибках надо выкидывать из профессии!
Стоимость лицензии (одной) ~ $20'000. Минимальный пакет лицензий ~ 5 штук. Это в год, если что. Сравнение проводили ASUG (Americas' SAP Users' Group) год назад, но никаких преимуществ они не обнаружили. Увы.
Вообще SAP HANA на практике ухудшает производительность SAP, в сравнении с Oracle/DB2, а не улучшает ее. Но это уже другая история. ;))
В крупных транснациональных компаниях (100К+ сотрудников), там между пациентом и доктором будет еще прослойка из аналитика, бизнес консультанта, деливери-менеджера и прочей нечисти. Причем, как правило, данная прослойка не владеет ни проблематикой бизнеса, ни пониманием возможных путей технической реализации. В итоге, можно наблюдать как в тратятся миллионы евро на разработку целого вороха ERP/CRM/MES систем, а когда приходишь к пользователям, то все сидят в Excel. Там процесс создания суррогатов — это уже процесс сам в себе.
1. Всегда успешно решается средствами машинного обучения — удаление/поиск дубликатов в справочниках материалов и контрагентов. Для многих крупных компаний это проблема, особенно, если НСИ ведут сами пользователи, а не отдельная группа.
2. Хорошо показал себя наивный байес при расследовании систематического воровства на складах. Байес, т.к. легко интерпретировать модели.
В остальном внятных реализаций, применимых к ERP, я не встречал. Маркетингом я не занимаюсь, возможно там картина лучше. Про ремонты и прогнозирование отказов лучше не начинайте. ;))
Я то думал… О_о
Ойййёё… Хорошо, записывайте себе безоговорочную победу.
У меня нет собственного определения УУ. По большей части для меня это синоним Cost Accounting.
Проплаты по конкретному договору в SAP в 90% случаев не посмотреть никак. Есть ряд причин. Регистрация платежа в системе связывает его с кредитором, но не договором. Привязать платеж к договору можно, но это не решит проблему с большими сметами, когда не понятно за какие позиции уже заплатили, а за какие нет. Это не проблема SAP, а просто другая философия. Половина мира так работает. Тут проблема скорее в том, что ваше руководство не готово пересмотреть подходы к управлению.
А ТОПам нужны планы, а не прогнозы. Их интересует то, что компания собирается предпринимать и какие результаты это принесет. Невозможно достоверно спрогнозировать вывод нового продукта, открытие нового рынка, смену ассортимента, т.к. в таких сценариях нет никаких исторических данных. Не к чему применять модели.
Просто я на практике всего дважды встречал применение более умного подхода, чем простое копирование предыдущего периода с умножением на какой-либо коэффициент. В одном случае это была линейная регрессия в матлабе, во втором временные ряды в Excel.
Можете не отвечать, но описанное Вами предприятие никак не связано с железными дорогами?
В здравом уме в SAP-CO учет движения денежных средств не делают, просто потому, что ДДС прямого отношения к затратам не имеет. Систему проектировали наркоманы, не иначе. Проблемы с файликами — это уже следствие другой, гораздо большей проблемы.
Давайте на чистоту. Для динамики дебиторки никакие хитромудрые средства не нужны. Там даже калькулятор не нужен. Прогноз по выручке и спросу можно делать вообще как угодно. На практике там довольно сложно ухудшить результат. Вы просто физически не затолкаете в модель все метрики, чтобы она учитывала в прогнозе Ваши планы. А без этого ценность таких прогнозов довольно низкая.
https://en.wikipedia.org/wiki/Management_accounting
Посмотрите методологии. Costing — это учет затрат. В SAP ERP значительная часть этого реализуется в модуле CO.