Comments 10
Учет и планирование отличаются не только направлением трансформации данных (снизу-вверх или сверху-вниз), но и рядом других, в том числе:
1. Принципом отнесения данных к первичным (вводимым руками) или расчетным (вычисляемых компьютером). В учете первичными данными выступают преимущественно абсолютные значения показателей (количество потребляемых ресурсов, суммы продаж, суммы процентов по кредитам и т.п.), а в планировании — преимущественно относительные (нормы расхода потребляемых ресурсов, цены продаж, процентные ставки по кредитам т.п.).
2. Учет всегда оперирует фактической информацией, которая является максимально полной и достоверной. При этом план всегда оперирует будущей информацией, которая по определению всегда недостоверна и фрагментарна.
3. Уровень детализации в учете и планировании определяется возможностью контроля руководителей организации за качеством управленческой информации. В учете, который оперирует фактической информацией, возможен контроль на уровне каждой хозяйственной операции, оформляемой первичным документом. В планировании, оперирующим информацией о будущем, контроль возможен только на уровне укрупненных статей, так как излишняя детализация планов лишь повышает степень их неопределенности.
4. В учете в подавляющем большинстве случаев используются последовательные расчеты вычисляемых показателей. В планировании зачастую невозможно обойтись без рекурсивных расчетов.
5. Учет представляет собой строго регламентированный процесс, регулируемый нормативными актами начиная с федеральных законов и заканчивая внутриведомственными инструкциями и стандартами. Для планирования отсутствует какая-либо регламентация со стороны государственных органов (за исключением государственных учреждений в рамках бюджетного процесса), в внутри организации процесс планирования в гораздо большей степени регулируется сложившимися практиками, чем внутренними нормативными актами.
6. Учет представляет собой периодически повторяющийся и практически не меняющийся со временем процесс с временным лагом в один месяц. Планирование больше всего похоже на проект, который выполняется один раз в год (для годового планирования) каждый раз в новых условиях (факторов внешней среды) и с новыми критериями эффективности (целями высшего руководства).
7. Учет в средних и крупных организациях, как правило, разделен на несколько однотипных процессов (материальный учет, финансовый учет, кадровый учет, учет основных фондов, налоговый учет и т.п.), который ведется узкоспециализированными сотрудниками (кадровик может не разбираться в налоговом учете и наоборот). В планировании работы в рамках всех процессов выполняется одними и теми же сотрудниками, обладающими знаниями по всем планируемым процессам организации. Малые предприятия несколько выпадают из данной классификации — в них обычно весь учет ведет один главный бухгалтер, а планирование как таковое вовсе отсутствует.
Указанные факторы, несмотря на довольно большое сходство итоговых документов в учете и планировании, приводят к невозможности использования учетных программных продуктов в процессах планирования. А где это делается, там эффективность планирования в лучшем случае стремится к нулю, а в худшем — вводит в заблуждение руководство организации об экономической эффективности их собственных планов. По этой причине подавляющее большинство организаций для планирования используют MS Excel, даже при наличии у них эффективной автоматизированной системы учета.
В качестве представителя не указанного в статье класса систем, предназначенных для автоматизации системы бюджетирования и управленческого учета, можно привести платформу экономического моделирования JetCalc. На Хабре опубликованы следующие статьи про JetCalc:
1. Последовательность шагов по организации управленческого учета на платформе JetCalc.
2. Есть ли альтернатива Excel в сфере бюджетирования и бизнес-аналитики.
1. Принципом отнесения данных к первичным (вводимым руками) или расчетным (вычисляемых компьютером). В учете первичными данными выступают преимущественно абсолютные значения показателей (количество потребляемых ресурсов, суммы продаж, суммы процентов по кредитам и т.п.), а в планировании — преимущественно относительные (нормы расхода потребляемых ресурсов, цены продаж, процентные ставки по кредитам т.п.).
2. Учет всегда оперирует фактической информацией, которая является максимально полной и достоверной. При этом план всегда оперирует будущей информацией, которая по определению всегда недостоверна и фрагментарна.
3. Уровень детализации в учете и планировании определяется возможностью контроля руководителей организации за качеством управленческой информации. В учете, который оперирует фактической информацией, возможен контроль на уровне каждой хозяйственной операции, оформляемой первичным документом. В планировании, оперирующим информацией о будущем, контроль возможен только на уровне укрупненных статей, так как излишняя детализация планов лишь повышает степень их неопределенности.
4. В учете в подавляющем большинстве случаев используются последовательные расчеты вычисляемых показателей. В планировании зачастую невозможно обойтись без рекурсивных расчетов.
5. Учет представляет собой строго регламентированный процесс, регулируемый нормативными актами начиная с федеральных законов и заканчивая внутриведомственными инструкциями и стандартами. Для планирования отсутствует какая-либо регламентация со стороны государственных органов (за исключением государственных учреждений в рамках бюджетного процесса), в внутри организации процесс планирования в гораздо большей степени регулируется сложившимися практиками, чем внутренними нормативными актами.
6. Учет представляет собой периодически повторяющийся и практически не меняющийся со временем процесс с временным лагом в один месяц. Планирование больше всего похоже на проект, который выполняется один раз в год (для годового планирования) каждый раз в новых условиях (факторов внешней среды) и с новыми критериями эффективности (целями высшего руководства).
7. Учет в средних и крупных организациях, как правило, разделен на несколько однотипных процессов (материальный учет, финансовый учет, кадровый учет, учет основных фондов, налоговый учет и т.п.), который ведется узкоспециализированными сотрудниками (кадровик может не разбираться в налоговом учете и наоборот). В планировании работы в рамках всех процессов выполняется одними и теми же сотрудниками, обладающими знаниями по всем планируемым процессам организации. Малые предприятия несколько выпадают из данной классификации — в них обычно весь учет ведет один главный бухгалтер, а планирование как таковое вовсе отсутствует.
Указанные факторы, несмотря на довольно большое сходство итоговых документов в учете и планировании, приводят к невозможности использования учетных программных продуктов в процессах планирования. А где это делается, там эффективность планирования в лучшем случае стремится к нулю, а в худшем — вводит в заблуждение руководство организации об экономической эффективности их собственных планов. По этой причине подавляющее большинство организаций для планирования используют MS Excel, даже при наличии у них эффективной автоматизированной системы учета.
В качестве представителя не указанного в статье класса систем, предназначенных для автоматизации системы бюджетирования и управленческого учета, можно привести платформу экономического моделирования JetCalc. На Хабре опубликованы следующие статьи про JetCalc:
1. Последовательность шагов по организации управленческого учета на платформе JetCalc.
2. Есть ли альтернатива Excel в сфере бюджетирования и бизнес-аналитики.
leossnet
Планируются часто и абсолютные показатели, и относительные.
И вычисления в планах действительно идут и снизу вверх (от детальных к сводным), и сверху вниз (от итоговых к детальных), и по кругу.
Хороший вопрос, который, если получится, я рассмотрю в будущих публикациях. Сейчас в реал-таймовых ERP-системах очень важна информация, которая находится на границе между планом и фактом.
И учет может быть управленческим, и планирование может быть государственным или регламентированным управляющей компанией. Здесь большой разницы нет.
Тем не менее, планы могут ходить «по кругу» между отделами, и отделы могут корректировать только свою часть, не разбираясь в других разделах.
1. Принципом отнесения данных к первичным (вводимым руками) или расчетным (вычисляемых компьютером). В учете первичными данными выступают преимущественно абсолютные значения показателей (количество потребляемых ресурсов, суммы продаж, суммы процентов по кредитам и т.п.), а в планировании — преимущественно относительные (нормы расхода потребляемых ресурсов, цены продаж, процентные ставки по кредитам т.п.).
Планируются часто и абсолютные показатели, и относительные.
И вычисления в планах действительно идут и снизу вверх (от детальных к сводным), и сверху вниз (от итоговых к детальных), и по кругу.
Хотя вот Вы про это и пишете:
4. В учете в подавляющем большинстве случаев используются последовательные расчеты вычисляемых показателей. В планировании зачастую невозможно обойтись без рекурсивных расчетов.
2. Учет всегда оперирует фактической информацией, которая является максимально полной и достоверной. При этом план всегда оперирует будущей информацией, которая по определению всегда недостоверна и фрагментарна.
Хороший вопрос, который, если получится, я рассмотрю в будущих публикациях. Сейчас в реал-таймовых ERP-системах очень важна информация, которая находится на границе между планом и фактом.
5. Учет представляет собой строго регламентированный процесс, регулируемый нормативными актами начиная с федеральных законов и заканчивая внутриведомственными инструкциями и стандартами. Для планирования отсутствует какая-либо регламентация со стороны государственных органов (за исключением государственных учреждений в рамках бюджетного процесса), в внутри организации процесс планирования в гораздо большей степени регулируется сложившимися практиками, чем внутренними нормативными актами.
И учет может быть управленческим, и планирование может быть государственным или регламентированным управляющей компанией. Здесь большой разницы нет.
В планировании работы в рамках всех процессов выполняется одними и теми же сотрудниками, обладающими знаниями по всем планируемым процессам организации.
Тем не менее, планы могут ходить «по кругу» между отделами, и отделы могут корректировать только свою часть, не разбираясь в других разделах.
Ок. Поясню свои тезисы. В учете за счет того, что руками вводятся преимущественно абсолютные показатели, а относительные рассчитываются, можно использовать относительно простые схемы базы данных, а вычисления выполнять прямо в самой базе данных простыми sql-запросами. Например, при сохранении данных счет-фактуры в базу данных заносятся показатели выручки на весь объем, даже если в базе данных есть прейскурант цен и количество в натуральных единицах. В результате сразу после ввода данных счета-фактуры можно сформировать свод по реализации, в котором уже расчетным путем получить средние цены в различных разрезах. Это становится возможным, так как после заключения договора и отгрузки продукции ни цена, ни объем этой отгрузки не меняются.
В планировании все наоборот. И цена, и количество являются переменными величинами, которые могут постоянной пересчитываться вплоть до утверждения плана в окончательной редакции. При этом ни количество, ни цена не могут быть быть агрегированы в лоб, так как цена является средневзвешенной величиной, а количество может иметь разную размерность, а потому сумма количеств в большинстве случаев является бессмысленной величиной (например, сложение метров и килограммов). В результате для расчета плановой суммы продаж, равной произведению количества на цену, нужно для каждой позиции предварительно рассчитать это произведение, и лишь затем производить расчет общего итога. А так как и цены, и количества продукции могут быть изменены в любой момент, то такие расчеты должны производится в режиме реального времени. То есть следствием такой схемы расчета является гораздо более высокая сложность и ресурсоемкость плановых расчетов по сравнению с фактическими при агрегации даже обычных стоимостных показателей.
Что касается расчета плана сверху-вниз, то если на каком-то уровне такая схема не превращается в планирование снизу-вверх на основании норм и цен, а представляет собой лишь подгонку детализирующих лимитов под спущенные сверху сводные лимиты, то такое планирование является обычной профанацией. Поэтому такую схему нет никакого смысла рассматривать всерьез. Ведь в процессе планирования важно не только рассчитать сводные финансовые результаты, но и понять влияние на эти сводные результаты отдельных факторов, которыми как раз и выступают удельные нормы расхода, ставки, цены, различные нормативные коэффициенты и т.п. Влияние таких факторов на сводные результаты определяется путем проведения факторного анализа, выполняемого, например, методом цепной подстановки.
Что касается уровня регламентации, то здесь важно то, что нормативная база представляет собой по своей сути качественное техническое задание, содержащие в себе не только конечные формы отчетности, но и детальную регламентацию различных учетных процессов. В такой ситуации любой разработчик способен разработать программное обеспечение для бухучета, даже особо не разбираясь в его специфике.
В процессе же планирования, в котором вся исходная нормативная база и алгоритмы расчета целиком и полностью завязаны на технологические особенности организации, для разработки качественного программного обеспечения для стороннего разработчика практически нет качественных источников информации для разработки технического задания. Поэтому сегодя любой программный продукт для планирования представляет собой либо универсальную электронную таблицу типа Excel, либо некоторый полуфабрикат, который требует доработки под специфику организации с помощью консультантов за довольно большие деньги. Плюс доработка такой специфики осуществляется с использованием языков программирования, которые не доступны для самостоятельного освоения большинством экономистов-плановиков.
На тему того, что информация в процессе планирования ходит по кругу между отделами, Вы не только не опровергли мой тезис, но и сформулировали дополнительное отличие учета от планирования. Которое заключается в том, что при учете сотрудники функциональных службы в рамках учета лишь однократно вводят информацию, за которую несут ответственность (например, заполняют фактурную часть счета-фактуры). Бухгалтерия же после этого заполняет недостающие атрибуты первичных документов. При планировании службы не просто вводят информацию, которую затем используют плановики, но и периодически ее уточняют и дополняют, причем зачастую письменно обосновывая необходимость тех или иных изменений. В результате плановики не просто обсчитывают экономические показатели по всем процессам предприятия, но и интенсивно взаимодействуют с отделами-поставщиками исходных данных для плановых расчетов.
В планировании все наоборот. И цена, и количество являются переменными величинами, которые могут постоянной пересчитываться вплоть до утверждения плана в окончательной редакции. При этом ни количество, ни цена не могут быть быть агрегированы в лоб, так как цена является средневзвешенной величиной, а количество может иметь разную размерность, а потому сумма количеств в большинстве случаев является бессмысленной величиной (например, сложение метров и килограммов). В результате для расчета плановой суммы продаж, равной произведению количества на цену, нужно для каждой позиции предварительно рассчитать это произведение, и лишь затем производить расчет общего итога. А так как и цены, и количества продукции могут быть изменены в любой момент, то такие расчеты должны производится в режиме реального времени. То есть следствием такой схемы расчета является гораздо более высокая сложность и ресурсоемкость плановых расчетов по сравнению с фактическими при агрегации даже обычных стоимостных показателей.
Что касается расчета плана сверху-вниз, то если на каком-то уровне такая схема не превращается в планирование снизу-вверх на основании норм и цен, а представляет собой лишь подгонку детализирующих лимитов под спущенные сверху сводные лимиты, то такое планирование является обычной профанацией. Поэтому такую схему нет никакого смысла рассматривать всерьез. Ведь в процессе планирования важно не только рассчитать сводные финансовые результаты, но и понять влияние на эти сводные результаты отдельных факторов, которыми как раз и выступают удельные нормы расхода, ставки, цены, различные нормативные коэффициенты и т.п. Влияние таких факторов на сводные результаты определяется путем проведения факторного анализа, выполняемого, например, методом цепной подстановки.
Что касается уровня регламентации, то здесь важно то, что нормативная база представляет собой по своей сути качественное техническое задание, содержащие в себе не только конечные формы отчетности, но и детальную регламентацию различных учетных процессов. В такой ситуации любой разработчик способен разработать программное обеспечение для бухучета, даже особо не разбираясь в его специфике.
В процессе же планирования, в котором вся исходная нормативная база и алгоритмы расчета целиком и полностью завязаны на технологические особенности организации, для разработки качественного программного обеспечения для стороннего разработчика практически нет качественных источников информации для разработки технического задания. Поэтому сегодя любой программный продукт для планирования представляет собой либо универсальную электронную таблицу типа Excel, либо некоторый полуфабрикат, который требует доработки под специфику организации с помощью консультантов за довольно большие деньги. Плюс доработка такой специфики осуществляется с использованием языков программирования, которые не доступны для самостоятельного освоения большинством экономистов-плановиков.
На тему того, что информация в процессе планирования ходит по кругу между отделами, Вы не только не опровергли мой тезис, но и сформулировали дополнительное отличие учета от планирования. Которое заключается в том, что при учете сотрудники функциональных службы в рамках учета лишь однократно вводят информацию, за которую несут ответственность (например, заполняют фактурную часть счета-фактуры). Бухгалтерия же после этого заполняет недостающие атрибуты первичных документов. При планировании службы не просто вводят информацию, которую затем используют плановики, но и периодически ее уточняют и дополняют, причем зачастую письменно обосновывая необходимость тех или иных изменений. В результате плановики не просто обсчитывают экономические показатели по всем процессам предприятия, но и интенсивно взаимодействуют с отделами-поставщиками исходных данных для плановых расчетов.
leossnet
Это все про расчеты «по кругу», мы про них уже поговорили.
Если Вы считаете, что планирование «сверху вниз» не должно существовать — это отдельная тема для разговора.
Если коротко и без максимализма: разобраться с методикой планирования немного сложнее, чем с учетом. Так?
Да, но это все по сути про рекурсивность расчетов «снизу-вверх/сверху-вниз».
То есть следствием такой схемы расчета является гораздо более высокая сложность и ресурсоемкость плановых расчетов по сравнению с фактическими при агрегации даже обычных стоимостных показателей.
Это все про расчеты «по кругу», мы про них уже поговорили.
Что касается расчета плана сверху-вниз, то если на каком-то уровне такая схема не превращается в планирование снизу-вверх на основании норм и цен, а представляет собой лишь подгонку детализирующих лимитов под спущенные сверху сводные лимиты, то такое планирование является обычной профанацией. Поэтому такую схему нет никакого смысла рассматривать всерьез
Если Вы считаете, что планирование «сверху вниз» не должно существовать — это отдельная тема для разговора.
В процессе же планирования, в котором вся исходная нормативная база и алгоритмы расчета целиком и полностью завязаны на технологические особенности организации, для разработки качественного программного обеспечения для стороннего разработчика практически нет качественных источников информации для разработки технического задания.
Если коротко и без максимализма: разобраться с методикой планирования немного сложнее, чем с учетом. Так?
При планировании службы не просто вводят информацию, которую затем используют плановики, но и периодически ее уточняют и дополняют, причем зачастую письменно обосновывая необходимость тех или иных изменений. В результате плановики не просто обсчитывают экономические показатели по всем процессам предприятия, но и интенсивно взаимодействуют с отделами-поставщиками исходных данных для плановых расчетов.
Да, но это все по сути про рекурсивность расчетов «снизу-вверх/сверху-вниз».
Спасибо за статью. Плюсы-минусы bottom-up и top-down планирования еще хорошо разобраны в курсе "Budgeting essentials" на курсере, рекомендую интересующимся — https://www.coursera.org/learn/budgeting-essentials-development
Хочу отметить, что помимо БИТ: Финанс есть и другие российские платформы, более близкие к Hyperion/Cognos по идеологии, например, ПланФакт для SMB или Visiology для крупных компаний.
Спасибо за статью, жду продолжения
Спасибо что уделили внимание нашему продукту БИТ.ФИНАНС. У меня есть несколько уточнений по описанию продукта, так как я являюсь автором его.
утверждение интересное, мы действительно начинали с того что в 1С БП интегрировали модули бюджетирования УПП, но этот путь был совсем «трудный». Сейчас вспоминая задачи, которые мы реализовывали на проектах УПП за 1 год, возможно запустить на БИТ.ФИНАНС за 1-2 недели.
тут корректен тезис что продукт основан не «на методологии УПП», а на видении клиентов на данный процесс.
тут да, но главный момент Вы не указали что в РФ бухгалтерский учет (а это единые справочники, факт и т.д.) ведут в 1С БП 80-90% предприятий и продукт интегрируется в существующие процессы. На текущей момент у нас 70% клиентов используют единые поставки с решениями 1С БП и 1С БП КОРП.
нет в упп факт получается в офф лайне документом «Отражение факта» (при получении факта за 1 месяц на среднем предприятии может завершится с ошибкой SQL), это означает что все данный по факту «сваливаются в общий котел» и при формировании отчетов по факту невозможно понять источник данный данных/первичный документ.
В БИТ.ФИНАНС факт отражается в он-лайне, что означает что в отчетах план-факт данные отражается в момент первичной операции по БУ и возможно непосредственно перейти в отчете до данной операции, набор инструментов по мэпингу крайне отличается, это большая тема для обсуждения.
Я понимаю, что сложно сравнивать системы уровня БИТ.ФИНАНС с единой системой БУ, Казначейства, Бюджетирования, Управления договорами, MDM, МСФО и Консолидации и облачными решениями от Anaplan, Oracle и т.д. но все таки необходимо упомянуть что например Anaplan решает только одну конкретную задачу(решает ее хорошо) и появляется отдельный класс новых задач при внедрении таких систем, такие как синхронизация НСИ, сверка данных по факту и т.д.
Резюме, если есть желание корректно выполнить описание продукта я открыт для диалога
«Бит.Финанс основан на методологии бюджетирования УПП»
утверждение интересное, мы действительно начинали с того что в 1С БП интегрировали модули бюджетирования УПП, но этот путь был совсем «трудный». Сейчас вспоминая задачи, которые мы реализовывали на проектах УПП за 1 год, возможно запустить на БИТ.ФИНАНС за 1-2 недели.
тут корректен тезис что продукт основан не «на методологии УПП», а на видении клиентов на данный процесс.
«реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из разных внешних источников).»
тут да, но главный момент Вы не указали что в РФ бухгалтерский учет (а это единые справочники, факт и т.д.) ведут в 1С БП 80-90% предприятий и продукт интегрируется в существующие процессы. На текущей момент у нас 70% клиентов используют единые поставки с решениями 1С БП и 1С БП КОРП.
«Mapping – как в УПП. На среднем уровне.»
нет в упп факт получается в офф лайне документом «Отражение факта» (при получении факта за 1 месяц на среднем предприятии может завершится с ошибкой SQL), это означает что все данный по факту «сваливаются в общий котел» и при формировании отчетов по факту невозможно понять источник данный данных/первичный документ.
В БИТ.ФИНАНС факт отражается в он-лайне, что означает что в отчетах план-факт данные отражается в момент первичной операции по БУ и возможно непосредственно перейти в отчете до данной операции, набор инструментов по мэпингу крайне отличается, это большая тема для обсуждения.
Я понимаю, что сложно сравнивать системы уровня БИТ.ФИНАНС с единой системой БУ, Казначейства, Бюджетирования, Управления договорами, MDM, МСФО и Консолидации и облачными решениями от Anaplan, Oracle и т.д. но все таки необходимо упомянуть что например Anaplan решает только одну конкретную задачу(решает ее хорошо) и появляется отдельный класс новых задач при внедрении таких систем, такие как синхронизация НСИ, сверка данных по факту и т.д.
Резюме, если есть желание корректно выполнить описание продукта я открыт для диалога
Будьте добры, уберите тэг «Функциональное программирование». В этом обзоре финансового ПО нет ни строчки про Haskell, LISP или Ocaml.
Sign up to leave a comment.
Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (BI / ERP / EPM)