s_ustinovflytier,
вы описали очень частую ошибку в методологии бюджетирования.....

Вернулся из раздумий.

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

Это была часть, где «я со всем согласная». А теперь сразу попробую оправдаться и чуть чуть поспорить.

Во первых (это части именно оправдания), у нас роль аппрува заказа фактически исполняет заполнение/корректировка и утверждение/фиксирование бддс очередного месяца. Да, то не так красиво и правильно, как Вы описали в примере, однако это вполне обеспечивает соблюдение шага контроль «до возникновения обязательств».

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

Обязательства, не имеющие конкретной суммы в конкретный срок. Да, мы имеем необходиомсть в сделке по привлечению интернет траффика по определенной CPA. Да мы аппрувим такую сделку (вернее 100 таких сделок) на общий бюджет на квартал. Но мы не знаем сколько конкретно результата нам принесет каждый из этих поставщиков за определенный период времени (и они не знают, и вообще это можно узнать только по факту, причем реал тайм статистики нет). Таким образом, контролировать расходование средств на эту статью необходимо именно по ДДС. Закладываем небольшой запас (занижаем стоимость статьи в ДДС), и как только появляется его превышение собираемся и решаем как быть (уменьшить/остановить рекламный траффик, перераспределить бюджет или что то еще).

Кстати, интеграторы (к которым, как я понимаю Вы принадлежите) то же являются отличным примером не прогнозируемых расходов.

Идем дальше.

Кассовый разрыв. Про это уже написали выше, но Вы не согласились. Создается такое ощущение, что мы работаем в идеальных бизнесах. Если у Вас так - я очень рад. Но у нас - не так. И кассовый разрыв может случиться. Например, если мы заапрувили покупку услуг с условием оплаты в течение 5 дней после поставки этих услуг. Спланировали ДДС по этому ордеру скажем на май. А поставщик извернулся и поставил услуги быстрее - в апреле. И, если мы не контролируем расходование средств на уровне платежей - здравствуй кассовый разрыв.

Вообще с фразой «когда фирма УЖЕ получила товары или услуги и обязана их оплатить - и что тут можно контролировать?» я не согласен. Контролировать можно. Например срок оплаты. Задержку платежей, кредиторскую задолженность и просто реструктуризацию отношений никто не отменял. Если же кто то считает, что таких ситуаций (когда должны заплатить, но платить нельзя) не бывает, то он не вел бизнес в России (и в Украине думаю то же).


Я могу привести еще достаточно примеров, почему контроль исполнения БДДС непосредственно в процессе платежей необходим (например банальное воровство - один мой партнер случайно поймал главбуха на завышении зарплаты). Но в этом нет смысла, описанных примеров достаточно:

Резюмирую - бизнесу, в котором я работаю, контроль БДДС на уровне платежей нужен. И думаю, что любому другому бизнесу он будет не лишним. Но так же я соглашусь с тем, что мне необходимо развить методологию и инструмент для контроля закупок не на уровне планирования в ДДС, а выделив в одтельный процесс. А он уже будет частично формировать БДДС. Еще раз спасибо за науку в этом вопросе.

P.S. Вот только вместо сокращения требований к продукту они разрастаются.

P.P.S. «… этот велосипед не надо изобретать самому, он работает из коробки. Все решается с помощью настроек.» Из коробки - это когда ты вызял и работаешь. А решается с помощью настроек - это уже конструктор, а не коробка.

iscrafmflytierаппрувим
это по-русски грамотно "утверждаем"? Или какое-то другое действие?

Утверждаем, одобряем. От англ. approve.

s_ustinovflytierОбязательства, не имеющие конкретной суммы в конкретный срок. Да, мы имеем необходиомсть в сделке по привлечению интернет траффика по определенной CPA. Да мы аппрувим такую сделку (вернее 100 таких сделок) на общий бюджет на квартал. Но мы не знаем сколько конкретно результата нам принесет каждый из этих поставщиков за определенный период времени (и они не знают, и вообще это можно узнать только по факту, причем реал тайм статистики нет). Таким образом, контролировать расходование средств на эту статью необходимо именно по ДДС. Закладываем небольшой запас (занижаем стоимость статьи в ДДС), и как только появляется его превышение собираемся и решаем как быть (уменьшить/остановить рекламный траффик, перераспределить бюджет или что то еще).

вот как у вас получился вывод, что именно по ДДС?

очень похоже, что у вас просто "замылился" взгляд.

конкретно по описанной ситуации:
насколько я знаю, большинство рекламных площадок позволяют покупать показы на определенную сумму или как то ее ограничивать.
а если суммы мелкие (не страшно небольшое превышение сознательно заниженного бюджета, как вы описали) - просто ведем учет постфактум - делаем заказа на закупку (PO) на основе выставленных поставщиками счетов - получаем тот же самый результат, который вы описали

Возможно и замылился, отрицать не буду. Но я этого не чувствую.

Что касается закупки с ограничением - не всегда это возможно и не всегда это допустимо с точки зрения бизнеса. Часто нужно именно в момент консолидирования возникшей задолженности принимать решение о продлении, приостановки или изменения потока траффика. Если коротко, то это потому, что рост эффективности траффика инертен.

Кроме этого я писал, что бюджет на много площадок - один общий. Мы не знаем заранее кто сколько траффика нам сможет поставить. И делить договора (заказы) на кусочки, соответствующие бюджетным периодам (ну или одобрять заказ по частям) неудобно именно из за этого.

Что же касается ведения учета постфактум, то, простите, мы не получаем ни планирования бддс, ни его контроля. Не дело это.

s_ustinovпро кассовые разрывы я уже писал.
все, что вы пишите, к бюджетированию отношения не имеет.

в заказе вбивается график платежей и сумма. после чего заказ утверждается и просто так, без повторного утверждения, изменить ничего нельзя.
а при вводе платежей система контролирует, что суммы и сроки совпадают с утвержденными в заказе. если не совпадают - дополнительное согласование и утверждение.
на самом деле схема сложнее - один заказ может иметь несколько инвойсов, а у каждого инвойса может быть несколько платежей. но общий принцип сохраняется - в самом начале утверждаем ЗАКУПКУ (что, у кого и за какую сумму покупаем и сколько и когда за это заплатим), а последующие документы, если они укладываются в утвержденные сроки и суммы, идут без дополнительного контроля соответствия бюджетам. разумеется, могут быть другие контроли, но это уже не бюджетирование.

например, то же воровство. мне рассказывали ситуацию, когда, чтобы удержаться в бюджете ДДС, директор филиала допустил большой рост кредиторки перед поставщиками и по зарплате, и когда все всплыло - были большие проблемы. а по БДДС все было хорошо

Ну это смотря как Вы понимаете бюджетирование. Если понимать его так, как учат в ВУЗе, то относится - бюджетирование это контроль и управление финансовыми потоками бизнеса. И ситуации, которые я (и не только я) привел в пример, напрямую относятся к области бюджетирования.

Теперь про ордер, к которому привязаны инвойсы, к которым привязаны платежи. Это отличный пример и я не отказываюсь от того, что такой подход нужен. Но он нужен не для контроля финансовых потоков, а для контроля соблюдения стратегических целей компании И (!) формирования БДДС.

Контролировать финансовые потоки по ордерам, таким образом, как Вы рассказали, мы не можем. Просто потому, что мы не знаем дат, когда нужно будет платить. Ну не всегда конечно, но где то 30% наших затрат проходят по такого рода заказам. Нет четких дат и сумм оплаты. Есть только бюджетный промежуток и общая сумма.

Еще раз скажу - да, я согласен, что контролировать возникновение задолженности по этим ордерам нужно. Но так же необходимо контролировать погашение этой задолженности с точки зрения БДДС.


В пример с воровством - это значит, что у них не было нормального исполнения стратегического бюджета (скорее всего БДДС не был на него завязан). Там бы падение затрат на поставщиков и зарплаты были бы видны с первого взгляда.

iscrafmСудя по всему к вас простое определение лимитов и их контроль

У нас бюджетирование, что бы ни вкладывалось в это понятие. В данном конкретном случае возможно Вы правы.


iscrafms_ustinovИспользование стандартного (реализованного в нормальных тиражных ERP системах, про УПП и тп не говорим) способа дает или лучший, или такой же результат , как и прочие, самостоятельно придуманные схемы бюджетирования, но обходится ДЕШЕВЛЕ - настроить готовый и оттестированный в тысячах внедрений софт намного дешевле, чем придумать, написать ТЗ и воплотить в работающий код свою схему.
Вы явно не совсем понимаете в том, как создаются системы, сколько это стоит и т.п. Не комментируйте лучше не знакомые темы. В вопросах финансовой теории и проводок нормально получается. Но в вопросы системного анализа лучше не вмешиваться.

Что то Вы жестко как то. Считаю, что s_ustinov имеет право на такую точку зрения и не вижу причин, почему ему ее не высказать. Мы же все люди, так? Имеем право на позицию и на ошибку :).

s_ustinovflytier, я прекрасно знаю, что примерно таким способом, как вы делаете, можно получить удовлетворительные результаты. вопрос ведь не в этом.

Что главное в системе бюджетирования? чтобы она решала поставленные задачи и при этом стоила как можно меньше (меньше ошибок, меньше стоимость ПО, меньше трудозатраты и тп).

Использование стандартного (реализованного в нормальных тиражных ERP системах, про УПП и тп не говорим) способа дает или лучший, или такой же результат , как и прочие, самостоятельно придуманные схемы бюджетирования, но обходится ДЕШЕВЛЕ - настроить готовый и оттестированный в тысячах внедрений софт намного дешевле, чем придумать, написать ТЗ и воплотить в работающий код свою схему.

Ну вот мы и подошли к вопросу "нормальных ERP систем". Я в общем то и не спорю. Хотя бы потому, что нормальные ERP системы на половину predefined, а на другую половину - программируемые СУБД. Конечно в них можно реализовать все. Вопрос сколько денег, времени, других затрат предприятия это будет стоить.

s_ustinov, я же не спорю, что я иду по сложному пути. Скорее я являюсь заложником обычных обстоятельств - как задешево получить хорошо. А у нас даже УПП дешево не бывает.

s_ustinovЕсли не согласны с этим выводом, приведите несколько примеров (конкретных ситуаций), где ваш подход даст лучший результат, чем стандартный. еще никто мне привести такого примера не смог, но вдруг у вас такие примеры есть?

Это не честный вопрос, потому, что на него Вы всегда сможете ответить, что "и это я то же настрою в этой или этой ERP". Я сам такой был, знаю :).

Но я могу сказать другое. Два примера (не раскрою названия компаний, потому, что не согласовывал с ними это):

Крупная интернет компания, до относительно недавнего времени, когда они внедрили SAP, работала на своих продуктах. И только внедрение продукта этого уровня позволило им реализовать необходимое. Более дешевые не справлялись. А вот свои "тулзы" справлялись.

Другая крупная компания. Торговая. Успешная, уверяю вас. После нескольких неудачных внедрений разных ERP систем (от разных интеграторов) отказалась от этой идеи и разработала собственную систему бюджетирования, логистики и статистического анализа. Пока не меняла.

Я не говорю, что это повсеместно. Что это правило и что ERP это плохо. Нет вовсе. Но такие ситуации бывают и заставляют 7 раз отмерить, до того, как резать.

s_ustinovа список требований у вас растет по той причине, что вы начинаете задумываться о функционале ЕРП системы, где бюджетирование - только очень маленькая часть.

Тут Вы безусловно правы. Вообще то я как раз думал о варианте скорее УПП :) Так что хотя бы один миф Вы точно развеяли, спасибо :)

s_ustinov,

Я тут на днях встречался со старой знакомой, главбухом крупного предприятия. И она мне рассказала о их опыте подбора систем и в частности причинах, почему они отказались от внедрения SAP.

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

Вопрос к Вам, а в каких ERP системах, которые Вы бы рекомендовали, это возможно?

LSVflytierВопрос к Вам, а в каких ERP системах, которые Вы бы рекомендовали, это возможно?Штатно - во многих нет (удивлены?).
Но есть нештатные доработки.

Ну я не то, чтобы удивлен, логику подхода то я понимаю. Но так же я понимаю бухгалтеров, у которых закрытие/перезакрытие месяца на предприятии рамеров 3000 сотрудников генерит миллионы бухгалтерский проводок. И это приводит систему к ситуации, когда человек в этом массиве разобраться не в состоянии.

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