Бюджетирование: перспективы развития. И есть ли они?

[vo]

Набросал тут, что на мой взгляд не хватает в модуле управление бюджетами Галактики.
Дополнение и обсуждение приветствуется!

1. Нужен механизм моделирования бизнес-процессов со следующими атрибутами
1.1. Возможность удобного построения модели бизнес-процесса бюджетирования (возможно, визуальная форма)
1.2. Должны удобно определяться роли участников процесса бюджетирования, удобно закреплять пользователей за ролями, также операции бюджетирования – за ролями.
1.3. У каждой работы/операции/функции должны быть определены сроки ее начала и окончания;
1.4. У каждой работы/операции/функции должна быть возможность описать необходимый минимум/необходимый набор входящей информации (перечень бюджетов определенного типа определенных центров ответственности в определенном статусе);
1.5. Рабочее место пользователя, в котором видно какие бюджеты он должен заполнить и в какие сроки.
1.6. Поддержка процессов. Параллельно может идти процесс «Планирование первой версии годового бюджета не следующий год» и «Корректировка квартального бюджета на квартал». Потоки документов и работ должны контекстно относиться к процессам. Пользователь должен иметь возможность переключаться между процессами, видеть только документы определенного процесса или всех.
1.7. Права пользователей, пользователи, роли должны определяться в одном месте, а не во многих, как сейчас реализовано, что-то в настройках,

2. Изменить понятие «бюджет»
2.1. В текущей версии реализации понятие «бюджет» определяется совокупностью понятий «Центр ответственности» + «Период», дальше – есть некоторая детализация этого понятия по «Версии» и «Стадии». В рамках этого понятия располагается все множество бюджетов для данного ЦО и Периода, т.е. бюджет доходов и расходов, бюджет движения денежных средств и др. (такой бюджет я называю его «свалка данных»). В моём понимании и в понимании литературных источников «бюджет» – более мелкое понятие, т.е. бюджет доходов и расходов, бюджет движения денежных средств и др. – это разные бюджеты.
2.2. Бюджет должен быть документом, а не массивом рассчитываемых данных. То что бюджет – документ, должно выражаться в том что у него есть «Шапка», статусы, защита от изменения данных, в документе «бюджет» должно быть четко определено, какого же уровня данные он регламентирует.
2.2.1. Дело в том, что сейчас, поскольку как для просмотра, так и для ввода бюджетов используются типовые формы, возникает непонимание, где же детальный уровень собственно данных (по сути форма ввода), а где их агрегированное или иное представление (по сути отчет).
2.2.2. Система статусов должна также защищать бюджет от изменения данных в определенных статусах.
2.2.3. «В документе «бюджет» должно быть четко определено, какого же уровня данные он регламентирует» означает, что могут быть и более детальные данные, но они могут быть, например, вспомогательными или информативными, они могут быть обязательными но для более низких ЦО, а данный конкретный бюджет должен определять возможно более обобщенные данные для более высокого ЦО, но при этом не складываться из подчиненных автоматически, а в некоторых случаях работать наоборот: зарезали в более высоком бюджете сумму – посмотрели что в эту сумму складывалось из более мелких бюджетов – довели ответственным за эти бюджеты обязанность урезать некоторые суммы.
Вообще говоря, нужно очень хорошо и глубоко продумать возможные взаимоотношения между вышестоящими и нижестоящими бюджетами.
2.2.4. Нужна история изменений по отдельным суммам бюджета.
2.2.5. Должны быть общие и частные копии одного и того же бюджета. Частные копии – только для составителя или его группы.
2.3. Установка прав на бюджеты: для всех, для одного пользователя, для всей роли. Права должны определяться не только в конкретном экземпляре бюджета, а также на абстрактное описание бюджета: например все бюджеты данного типа для данного ЦО для периода определенного типа.
2.4. Должна быть возможность в основу бюджета класть «статью бюджета» (имеется в виду не обязательно аналитику «Статьи бюджета», а статью бюджета – как понятие, возможно это пользовательская аналитика). Статья бюджета в его основании – это особенность таких бюджетов как БДР, БДДС, Бюджет кап.вложений и т.д., по сути всех бюджетов, кроме операционных.
2.5. Должна быть «Изменяемость состава статей бюджета» от периода к периоду, при этом нужно не утратить сопоставимость данных. Например, была структура статей, в новом году добавили 5% статей, и убрали 5% старых статей. (В настоящее время нужно сделать 2 «типовые формы» с конкретным указанием статей, однако они никак не привязаны к периодам бюджета; нужна такая привязка. Нужно также, чтобы эти две «формы бюджета» при выводе сравнительного отчета объединяли оба множества статей).

3. Реализовать документ «бюджетная заявка». Некоторые особенности данного документа:
3.1. До настоящего времени рабочее место первоначального планировщика данных бюджета не автоматизировано.
Его рабочее место должно выглядеть следующим образом:
Рамками для планировщика являются те статьи бюджета, которые ему выделены: возможно, они уже с лимитирующими данными, а, возможно, они вычисляются как агрегат данных, введенных планировщиком.
Планировщик должен иметь возможность свободно дополнять более детальные данные к лимитирующим статьям, т.е. есть «например» статья «электроэнергия» допустим моделью определено, что она может быть детализирована планировщиком по подразделениям предприятия. Планировщик садится и свободно добавляет/удаляет строки в детализацию к этой статье, и вводит в них данные (В настоящее время для этого нужно: выйти из формы редактирования, добавить аналитику, добавить аналитику бюджетирования, добавить аналитику бюджетирования в типовую форму, перестроить типовую форму, зайти в бюджет, продолжить ввод данных).
3.2. Ввести понятие «прототипы договоров».
Чтобы не засорять каталог договоров «планами», которые возможно не сбудутся, или будут другие поставщики и т.д., не мешать юр.отделу работать с реальными договорами, нужно предоставить планировщикам на этапе планирования делать прототипы договоров, если «живых» договоров для планирования некоторых затрат на данный момент нет. У прототипа может не быть всех необходимых реквизитов.
В дальнейшем при заключении договора «прототип договора» должен подмениться реальным договором.
3.3. Возможно, также нужно понятие «прототипы контрагентов».
3.4. Как возможность, рассмотреть вариант интеграции форм ввода бюджетных заявок с MS Excel, поскольку этот инструмент привычен для всех экономистов и финансистов, и позволяет делать вспомогательные вычисления за пределами формы ввода прямо на листе (мне понравилось, как это сделано в продукте Profix).

4. Решить извечное противоречие: что класть в основу бюджета справочник «Статей бюджета» или любой другой справочник аналитики.
4.1. Противоречие наиболее наглядно видно на следующем примере:
Статьи БДДС и БДР очень похожи, отличаются по составу примерно на 20%. В части, в которой они пересекаются, зачастую, планирование БДДС делается следующим образом: планируются затраты/закупки (для некоторых это одно и то же), т.е. БДР, а сверху на эти данные накладываются «условия взаиморасчетов» (где-то предоплата, где-то постоплата), и в результате получается БДДС.
1) Если попытаться сделать это на «статьях бюжетирования», то придется сделать две почти одинаковые ветки статей, ввести для всех них аббревиатуры, написать множество однотипных формул. При этом при необходимости детализировать одну из статей по какой-то одной аналитике, а другую – по другой, можно сделать это без проблем.
2) Если попытаться сделать это на «аналитике», прикрепленной к одной «статье бюджетирования» – для БДР и одной – для БДДС, то достаточно один раз ввести иерархию, составить их нее два бюджета, опустив ненужные элементы для того или иного бюджета, и написать одну формулу между статьями. При этом при необходимости детализировать одну из «статей (реализованную как элемент аналитики)» по какой-то одной аналитике, а другую – по другой, нельзя!
Правда к варианту 1) сейчас есть некоторое упрощение связанное с тем, что можно воспользоваться не формулами, а алгоритмами бюджетирования, при этом нет необходимости рутинной работы с написанием формул, но нужно будет построить каталог соответствия между статьями одного бюджета и второго.
Тем не менее, в описании типового проекта внедрения должно быть решено это противоречие, чтобы внедренцу было понятно, что ставить во основу бюджета.

5. Поддержка «ювелирной» корректировки бюджетов.
5.1. Нужна система так называемых мной «неформализованных функциональных связей». Допустим, мы знаем, что сумма выплат за материалы связана с суммой закупаемых материалов в этом периоде, но не можем описать точную функциональную зависимость между результирующим показателем «выплаты» и исходным «закупки». Мы должны иметь возможность указать, что эти два показателя связаны функционально не указывая функции. При этом:
5.1.1. При изменении аргумента, по функции должны выставляться сигналы, что ее значение нужно откорректировать.
5.1.2. При заблокированности/утвержденности бюджета-функции, должно запрещаться редактирование бюджета аргумента.

6. Реализовать механизм контроля первичных документов на соответствие лимитным планам мимо функционала «Платежного календаря» для тех, кто не хочет вести платежный календарь, но хочет контролировать бюджет по месяцу (есть наработки по ТЗ – приложено).

7. Печатные формы содержат в себе какие-то непонятные ограничения.
7.1. Сейчас есть форма «Анализ бюджетов», которую также можно распечатать. В форму заложены некие непонятные ограничения типа:
7.1.1. По горизонтальной оси – только одна аналитика.
7.1.2. Ограниченное использование аналитики «Периоды» (не помню уже точно, есть ли такое, давно дело было).
7.2. Форма редактирования бюджета, которую тоже можно распечатать, тоже содержит ряд ограничений, причем банальных.

Поэтому инструменты вроде есть, даже два, а решить задачи не удается.

[poneatovski]

Если говорить о том, чего не хватает модулю "Управление бюджетом" в первую очередь, так это БЫСТРОДЕЙСТВИЯ при построении бюджета по типовой форме!!!
У меня сложилось впечатление, что поставлена задача внести существенные изменения в этот модуль. Это так?

[vo]

Эх, если бы это было так!!!
Это лишь хотелки, которые я сформулировал, и учитывая, что в компании они не были употреблены по назначению, употребил их сам на данном форуме... Этими действиями я пытаюсь сдвинуть дело с мертвой точки - на данный момент это единственный доступный мне инструмент.

[kroxa]

Эх, если бы это было так!!!

На самом деле, развитие решений для бюджетирования одно из приоритетных направлений развития.
однако из-за организационно-кадровых вопросов сейчас данный процесс несколько тормозится, но усилия прикладываются. самое главное есть воля руководства!
конечно не все и сразу, но многое уже делаем или проектируем:) причем это будут решения как "внутри" Галактика ERP, так и сторонние.
постараемся в ближайшее время опубликовать некие планы и этапы

[stix]

vo
Собрать и формализовать предложения немалый труд. Только напрасный. На этом форуме предложения никому не нужны. Разбейте предложения по приоритетам на не очень большие задачи и пишите в ПИР. Что-то отметут, что-то уйдет в вечность финансирования, но что-то могут и сделать. Именно такой стратегии и придерживается наше предприятие. Опыт показал, что это наиболее действенное при работе с Галактикой. Удачи
kroxa
По сводным таблицам уже есть какое-то решение?

[kroxa]

по сводным таблицам - идет разработка (анализ и проектирование). точные сроки и текущее состояние может рассказать Федор. выбрали компонент radar-soft .net, он будет интегрирован, пока ТЗ/ТП не готово, идет анализ вариантов реализации. кроме этого проводится встраивание еще одного удивительного контрола pivotviewer, который будет доступен прежде всего для персонала, но возможно применять и для склада, прайс-листа и пр.

если возвратится к предложениям Володи, то практически все пункты уже были приняты к реализации и их обсуждали. другое дело, что пока мало сделано. но по мере производства любые нововведения будут проходить "проверку проектных решений" с заявителем функционала, ведь не для себя же мы их делаем. Но, согласен с рекомендацией про ПИР, мелкие/косметические предложения лучше/нужно занести в ПИР, там они хотя бы не потеряются и не забудутся. (например, проблема DOLAP в Галактика ERP есть в ПИРе с 1999г./:-)

[vo]

Разбейте предложения по приоритетам на не очень большие задачи и пишите в ПИР...

1. Проблема в том, что в написанном мной, как мне кажется речь идет о крупных проблемах, которые заведомо уходят в finance и никогда не будут сделаны без особого проекта.
2. Эти предложения уже были направлены всем, кому только можно в ИП "Топ Софт". Форум - последнее место, где они были представлены.
3. При публикации этого материала, мной преследовалась цель предать свои предложения общественной оценке той аудиторией, которая не смотря ни на что использует галактическое бюджетирование или не использует его, но знакомо с его проблемами. Разделяете ли Вы предложенное мной?

На самом деле, развитие решений для бюджетирования одно из приоритетных направлений развития...

Это реально не чувствуется на практике...

[stix]

vo
Модуль бюджетирования у нас используется, но занимается им другой человек (могу дать координаты). К нам даже разработчики из Минска приезжали по доработкам этого модуля.
Аналогичная ситуация с доработками у нас была при внедрении ТОРО - мы тоже писали предложения и замечания нашему ПНР. Правили только критические ошибки. Остальное переводили почему-то в эргономику и забивали на это дело. Итог печальный - ТОРО внедрили, но никто им не пользуется. Сказали что виноваты мы сами, мол недостаточно подготовлены для такой системы. В Галактике отчего-то решили что люди для системы, но никак не наоборот. Проблема еще в том, что нет нормального комьюнити, где пользователи и администраторы могли бы высказаться конструктивно, проголосовать за то или иное решение, внести предложение. Начинаешь критиковать как тут же пишут злобные сообщения в личку, удаляют посты, вместо того чтобы как-то попытаться исправить ситуацию. Находишь баг, оказывается специфическим поведением, или вообще фичей, один раз даже документацию исправили под функционал, потому что было расхождение с действительностью. Проблема даже не в бюджете - в любом модуле аналогичная ситуация, проблема в нежелании развивать продукт.
P.S. Вы же вроде в Галактике работаете? Удивлен, что на вам тоже приходится все с боем проталкивать, думал только у заказчиков такие проблемы. Грустно все это.
P.P.S. Интересно как долго провисит этот пост

[ilshat]

[
Аналогичная ситуация с доработками у нас была при внедрении ТОРО

Мы щас тоже внедряем его... А что вообще доработали вам? Ато у нас "хотелок" вагоны.

p.s. Про бюджетирование даже высказаться не могу т.к. мы не стали его брать. У нас своё самописное, простое и эффективное :)
p.s. to stix - про ТОРО если не сложно можно в личку... ато тут не та тема как бы...

[stix]

ilshat
Ну что сказать - вы попали. Мы хотели даже отказаться от внедрения, но было уже поздно, да и денег много отвалили. Я тут как-то писал о части недостатков этой системы, но сообщение быстро стерли, а мне в личку стал писать какой-то чудак, грозился кому-то там пожаловаться, сетовал на мое недостойное поведение, об остальном в личку напишу

[vo]

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

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

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

Не все приходится проталкивать с боем. Я работаю еще и с модулем Автотранспорт. Там - все намного проще. Но это не касается "Управления бюджетами", там ситуация вошла в равновесно-застойное состояние и столкнуть ее с этого места не дает порочный круг: продукт, на мой взгляд, сильно недоработан, позволяет выполнять только функции сбора факта и сопоставления план-факт, т.е. для планирования в готовом виде его использоваться нельзя. Для того, чтобы полноценно его внедрять, его нужно сильно доработать. Доработки у нас делаются с основном только за деньги. Т.е. нужно закладывать в потенциальный проект внедрения существенные суммы на доработку модуля, что делает неэффективным либо внедрение, т.к. на ПНР ничего не останется, либо сумма контракта становится неэффективной для заказчика. Но самое страшное - никто не хочет связываться с неготовым продуктом, т.к. риски не получить то, что хочешь велики. Поэтому модуль мало кто берет. А раз мало клиентов, то и мало финансов на его развитие. В итоге круг замкнулся...

[kroxa]

Аналогичная ситуация с доработками у нас была при внедрении ТОРО - мы тоже писали предложения и замечания нашему ПНР. Правили только критические ошибки. Остальное переводили почему-то в эргономику и забивали на это дело.

статистика из ПИР-а СЗМН-ТОРО 111 проблем, из них в статусе "отложена до финансирования" 17 (из них 8 после 03.2010) остальные устранены/реализованы. Я не в теме этого проекта, но ведь статистика нормальна, при внедрении системы осталось 15% пожеланий (явно не ошибки: расписание/календарь, гант и т.п.). Мне кажется "хотелки" выполняются платно в любой системе и любым вендером.
На этом обсуждение ТОРО в этой ветке предлагаю закрыть.
к теме это вообще не относится, потому, что даже если рассматривать перспективы развития направления "ТОРО", - то тут как раз наоборот, работы ведутся и интенсивно! а рассчитывать, что существенные нововведения реализуемые отделом разработки в рамках новой версии в период уже выполняемого внедрения текущей версии мне кажется никогда не стоит.

[stix]

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

[vo]

stix, предлагаю перевести обсуждение ТОРО в другую ветку.

[kroxa]

с модулем Автотранспорт. Там - все намного проще. <SKIP> В итоге круг замкнулся...

Володя не горячись:) конечно начали очень активно этот год, провели несколько совещаний (включая специалистов ПНР и тебя тоже), собрали Все пожелания, предложения. Обработали, сформировали направления развития, наметили этапы и это все было в начале года.... НО оказалось, что свободных ресурсов в группе "бюджет" очень мало.
Может поэтому такое впечатление "застоя".
только сейчас получаем некие возможности вести разработки развития (а не заказных), к сожалению на подготовку грамотного прикладного разработчика тратится не менее 6 месяцев.