Комбинированная стратегия автоматизации учетных и управленческих функций на основе 1C
22 ноября 2007
Рубрика: Обзоры и мнения.
Автор: Владимир Милохов.

pic

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

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

Известно, что программы бухгалтерского учета версий 7.7 и 8 фирмы «1С» обладают всеми функциональными возможностями бухгалтерского учета, в том числе и на международном уровне. Однако в Узбекистане мы используем только платформу 1C, а конфигурацию каждая фирма, участвующая в процессах внедрения «1С:Предприятие», разрабатывает самостоятельно в связи с тем, что каждая конфигурация должна строиться на базе существующего национального законодательства и автоматизации конкретных функций, потребных в соответствии со спецификой каждой организации индивидуально. Каждая фирма постепенно дополняет свою типовую конфигурацию новыми функциями по мере приобретения опыта внедрения. Но на базе платформы специалист-программист может наращивать конфигурацию как учетных функций, так и управленческих, к которым могут относиться, например, бюджетирование предприятия, планирование бюджетами подразделений и производством, сбытом и запасами, работой вспомогательных служб и т.д. Для этого специалист-программист использует конструктор, заложенный в самой структуре платформы.

Однако ценность такого программного обеспечения заключается в том, что настраивать аналитику может сам оператор, не прибегая к помощи программиста. Сейчас на российском, и в частности на узбекистанском рынке, есть только один программный продукт (ПП), в котором процесс настройки максимально автоматизирован, — это «1С:Предприятие», обладающее гибкими механизмами конфигурирования. Причем линейка ПП «1С:Предприятие 8» имеет большие возможности, чем линейка ПП «1С:Предприятие 7.7», и линейка «1С:Предприятие 8» является заменой линейки «1С:Предприятия 7.7» .

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

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

Сейчас на рынке компьютерных программ действительно существует достаточно много как зарубежных, так и отечественных систем. Естественно, большинство разработчиков заявляет, что их программный продукт содержит в себе конструктор, с помощью которого можно сделать все необходимые настройки для любой компании. На самом деле в таком утверждении гораздо более смелое утверждение. Речь идет о возможности существования универсального конструктора, который поможет настроить программный продукт на модель бюджетирования любой компании, причем как в части учета, так и в части планирования бюджетов. Конечно же, это звучит заманчиво! Но действительно ли возможно существование такого универсального конструктора, используя который, можно настроить программный продукт на любую модель? Да, возможно! Таким конструктором по приемлемой цене (программный продукт «Оракл» стоит сотню тысяч долларов США) обладает пока только система «1С:Предприятие». Ведь для того чтобы ответить на такой вопрос, нужно заглянуть внутрь такого конструктора и понять, каким образом устроен конструктор. Ведь сам конструктор тоже строится на основе определенной модели. Например, типовой финансовой модели бюджетирования тоже не существует, но отсюда пока не следует, что не может существовать типовой конструктор («зашитый» в программном продукте) для построения уникальных финансовых моделей бюджетирования для каждой компании.

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

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

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

Поэтому особенно важно перед автоматизацией уже иметь модель бюджетирования, роль которой, как правило, выполняет уже существующая система, выполняющаяся в ручном режиме, то есть система «как есть».

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

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

Информационное поле планирования состоит из:
• системы норм и нормативов
• системы ограничений (лимитов)
• ограничивающих факторов («узкие места»)
• гипотез и предложений.

pic

То есть плановые отчеты нельзя формировать независимо друг от друга. В этом как раз и заключается основная сложность создания универсального конструктора для настройки модели планирования в любой компании. Ведь у каждой компании своя модель планирования, то есть свой набор бюджетов и своя методика заполнения статей этих бюджетов. Причем определенные статьи разных бюджетов между собой взаимосвязаны. Причем сами эти связи у каждой компании могут быть разные. Даже у одной и той же компании эти связи меняются во времени. Таким образом, учесть все возможные варианты в методике планирования гораздо сложнее, чем в методике учета, а значит, и создать такой универсальный конструктор планирования по аналогии с конструктором учета практически невозможно. Поэтому, когда разработчики софта утверждают, что у них есть универсальный конструктор для настройки модели планирования, они, мягко выражаясь, очень сильно преувеличивают возможности их программного продукта, кроме ПП «1С:Предприятие». Главная проблема заключается в том, что заказчик зачастую не имеет четкого представления о том, что ему, собственно говоря, нужно, а поэтому не может сформулировать цель. Компания не может поставить четкую задачу. Этим пользуются некоторые внедряющие фирмы, когда занимаются «впариванием» своих программных продуктов.

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

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

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

pic

То есть плановые отчеты нельзя формировать независимо друг от друга. В этом как раз и заключается основная сложность создания универсального конструктора для настройки модели планирования в любой компании. Ведь у каждой компании своя модель планирования, то есть свой набор бюджетов и своя методика заполнения статей этих бюджетов. Причем определенные статьи разных бюджетов между собой взаимосвязаны. Причем сами эти связи у каждой компании могут быть разные. Даже у одной и той же компании эти связи меняются во времени. Таким образом, учесть все возможные варианты в методике планирования гораздо сложнее, чем в методике учета, а значит, и создать такой универсальный конструктор планирования по аналогии с конструктором учета практически невозможно. Поэтому, когда разработчики софта утверждают, что у них есть универсальный конструктор для настройки модели планирования, они, мягко выражаясь, очень сильно преувеличивают возможности их программного продукта, кроме ПП «1С:Предприятие». Главная проблема заключается в том, что заказчик зачастую не имеет четкого представления о том, что ему, собственно говоря, нужно, а поэтому не может сформулировать цель. Компания не может поставить четкую задачу. Этим пользуются некоторые внедряющие фирмы, когда занимаются «впариванием» своих программных продуктов.

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

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

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

Автоматизация управленческого учета
Эта задача решается легче, чем автоматизация планирования. Для того, чтобы автоматизировать получение фактической информации, необходимо внедрить четкий регламент сбора первичных документов и ввода их в информационную систему. Причем этот ввод должен осуществляться в соответствии с требуемой аналитикой. Набор этих аналитик, используемых в учете операций, может быть свой в зависимости от операций. После ввода данных для получения нужных форм управленческого отчета останется только нажать кнопку, чтобы программа по заранее определенному алгоритму смогла «выдернуть» нужные значения из журнала проводок в соответствии с выбранным периодом отчетности. Удобство учетной модели заключается в том, что сама учетная модель универсальна для любых операций. Ведь каждую операцию можно расписать по дебету и кредиту определенных счетов из плана счетов, затем определить для них соответствующие значения аналитических признаков, выбрав нужные элементы справочников (в зависимости от типа операции). Получается, что из одного и того же массива данных (журнал проводок) можно формировать различные отчеты. Если при разработке программы компания что-то не учла, то особых проблем не возникнет. Нужно будет просто изменить методику получения отчета и получить отчет в другом формате. Никаких изменений в журнале проводок делать не нужно. Таким образом, получается, что отладку методики учета и ее автоматизацию производить гораздо легче, чем в случае с моделью планирования. Мастер отчетов в программе является достаточно гибким инструментом настройки и позволяет сделать практически любой классический отчет, состоящий из колонок с периодами. Еще одним существенным преимуществом является то, что для настройки отчета не требуется программист. Это значит, что специалист по управленческому учету при отладке форматов отчетности может без помощи программистов «поиграться» с учетной моделью и получить требуемый результат. То есть можно задать форматы отчетов, методику их заполнения и осуществить необходимые настройки программного продукта с использованием специального мастера отчетов. К сожалению, на практике часто бывает так, что даже после тщательной проработки форматов отчетов и после введения их в эксплуатацию они претерпевают изменения. Если для автоматизации учета компания использует достаточно жесткую систему, то понятно, что любое изменение в форматах отчетности может потребовать перенастройку системы. И такие перенастройки связаны с тем, что программистам часто приходится переписывать программный модуль. Наверное, не стоит говорить о том, что будет увеличиваться количество ненормативной лексики, используемой программистами при очередных запросах бухгалтеров по изменению форматов отчетности. Использование же специализированного мастера отчетов позволяет избежать всех этих временных затрат и скандалов между бухгалтерами и программистами. Специалисты отчетов могут вполне автономно заниматься поиском нужных форматов отчетности, не дергая каждый раз программистов и не создавая им дополнительной работы.

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

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

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

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

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

Создание единой автоматизированной системы бюджетирования
На самом деле, конечно же, при разработке программного модуля для автоматизации модели планирования и учета нужно сразу стараться делать интегрированную систему, а не два отдельных программных продукта. Поэтому данный этап начинается не после завершения этапа автоматизации модели планирования, а параллельно с этим этапом.
Несмотря на это, не нужно забывать об одном из основных минусов такой комбинированной стратегии автоматизации бюджетирования. Используя такую стратегию, необходимо обеспечить четкую координацию работ по настройке программного модуля по управленческому учету и созданию программного модуля для автоматизации модели планирования. Возможно, при автоматизации модели планирования придется частично переделать программный модуль по управленческому учету, то есть вернуться к первоначальному этапу. Поэтому на практике может и не получиться такой четкой линейной последовательности действий.
Резюме — комбинированная стратегия автоматизации финансовой модели бюджетирования позволит компании с минимальными потерями заполучить программный продукт системы «1С:Предприятие 8», обладающий вышеописанными свойствами и позволяющий подготовить бюджеты и отчеты об их исполнении. Только здесь еще раз нужно напомнить о том, что наличие разработанной и даже автоматизированной финансовой модели не гарантирует на 100%, что она будет эффективно работать в компании. Не нужно забывать о том, что без сотрудников компании эта модель работать не будет. Поэтому нужно еще обучить всех участников процесса бюджетирования тому, как нужно пользоваться финансовой моделью, причем уже в автоматизированном виде.

Orphus system
В Telegram
В Одноклассники
ВКонтакте