Меню

Полный каталог всех важных документов

Как подготовиться к автоматизации бюджетирования?!

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

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

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

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

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

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

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

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

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

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

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


  • Недостаточность и неполнота первичной информации для ТЗ (документы и регламенты компании, формы первичных документов и отчетов, методики расчетов и анализа и прочее). 
  • Недостаточно квалифицированные кадры, выделенные со стороны Заказчика для участия в подготовке ТЗ. 
  • Отсутствие вовлеченности персонала Заказчика в процесс подготовки ТЗ. 
  • Продолжительные согласования ТЗ заинтересованными участниками процесса автоматизации. 
  • Изменение состава требований к функционалу АС на этапе написания ТЗ. 
  • Смена участников проекта. 
  • Неверный подход к описательной части ТЗ. 
  • Неоднозначность трактовки положений ТЗ участниками проекта со стороны Заказчика и Разработчика.

Чтобы избежать эти проблемы и дать инструменты контроля над проектом необходимо: 

  • Выделять квалифицированный персонал для участия в разработке ТЗ. 
  • Установить жесткие временные рамки согласований положений ТЗ, закрепленные проектными документами (напр. устав проекта) и внутренними распорядительными документами Заказчика. 
  • Четко определить трактовки терминов и определений, используемых в ТЗ. 
  • Четко придерживаться в ТЗ границ и целей проекта, определенных на стадии предпроектной подготовки, не изменять состав требований к АС. 
  • Задукоментировать и окончательно уствердить требования к АС, которые исключат вопросы "А мы думали, что будет не так", "Давайте сделаем по-другому", "А давайте ещё кое-что сделаем". 
  • Создать инструмент технического контроля реализации архитектуры и функциональности будущей системы для Заказчика и Разработчика, который поможет избежать вопросов типа "А на какой стадии у нас проект?", "Что ещё надо в системе сделать?".
  • Создать точные однозначно трактуемые указания для команды проекта, оптимизировать временные и материальные затраты на менеджмент во время реализации проекта. 
  • На этапе ТЗ выяснить и утвердить методы решения нестандартных задач и используемые технологии (уменьшение количества промежуточных согласований, разделение аналитических работ и производства).

Как выбрать платформу, ПО, какие существуют решения на рынке, нужно ли брать готовое или "писать под себя"?!

Выбор системы для автоматизации процесса бюджетирования определен несколькими факторами. Прежде всего - функциональность такой системы, стоимость и трудозатраты по внедрению такой системы. Однако объективно оценить преимущества той или иной системы очень сложно, потому что, несмотря на достаточно агрессивную маркетинговую компанию многих раздатчиков, информативность, предлагаемых ими материалов не высока. Обычно акцент ставиться либо на невысокую стоимость, что характерно для отечественных разработчиков, либо на перечислении наименований компаний, где система уже внедрена. И в том и другом случаях, как правило, нет возможности получить информацию о том, какой функциональностью обладает система.

x

На нашем сайте используются файлы cookie. Файлы cookie используются для улучшения функциональности и удобства использования сайта, а также в рекламных и аналитических целях. Продолжая использовать сайт Вы предоставляете согласие c Соглашением обработки персональных данных.