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

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

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

  1. Нужны ли консультанты или делать своими силами? 
  2. Что делать своими силами, а что силами привлеченных консультантов?
  3. Какие существуют проблемы на этапе подготовки Технического задания (ТЗ)

Начнем с того, что: 

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

Что нужно понимать: 

  1. Автоматизированная система (АС) самостоятельно не создает объекты, допускающие применение объективных средств, критериев и оценки соответствия функциональным требованиям. 
  2. Объекты системы трансформируют представления Заказчика о будущей системе, изложенные в ТЗ, оценка которых может быть только субъективной. 
  3. Для обеспечения эффективности процесса разработки АС требуется, чтобы ТЗ содержало окончательные требования о соответствии результата ожиданиям Заказчика. 
  4. Однозначность и первоначальность ТЗ еще более увеличивает его роль в процессе разработки АС.
  5. ТЗ является не только исходной и согласованной Заказчиком и Разработчиком моделью АС. ТЗ - это еще и единственная полная модель АС, поскольку кроме ТЗ более нет меры оценки различных свойств АС.
  6. Поскольку только ТЗ включает окончательные требования к функционированию системы, исключается возможность использования иных, кроме изложенных в ТЗ, критериев приемки.

Таким образом, роль ТЗ просто невозможно переоценить. Существуют выведенные практикой нормативы: качество ТЗ на 90% определяет успех разработки АС. Говоря простым языком - что задумали, то и сделали. 
Общение Разработчика и Заказчика на этом этапе - наиболее важно для проекта автоматизации. Но существует сложность в прогнозировании возможных проблем, возникающих при подготовке ТЗ. Иногда Заказчик стремится изменить сроки или порядок работ - конечно же, всё это сказывается как на длительности, так и на стоимости проекта. И чем масштабнее проект, тем больше может быть разница между первоначальными договоренностями и изменениями, возникшими на этапе написания ТЗ. 
Чтобы свести к минимуму возникновение подобных проблем ТЗ должно составляться специалистами, говорящими на одном языке с разработчиками, то есть владеть основами построения автоматизированных систем и обладать глубокими знаниями предметной области автоматизации (раздела учета компании). 
Из наиболее распространенных проблем возникающих при разработке ТЗ можно выделить следующие: