ВНЕДРЕНИЕ 1С:ERP и 1С:Управление холдингом     Главная     Проекты, результаты     Консультации (Новый раздел!!)     Обратная связь. Отзывы, рекомендации    
 












УТ 8.2 & УПП : Управленческий & Торговый учет

  • Архив

    «   Апрель 2018   »
    Пн Вт Ср Чт Пт Сб Вс
                1
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23 24 25 26 27 28 29
    30            

Как сэкономить 2 млн. руб. или 20 секретов внедрения проектов "1C"


В данной статье я поделюсь опытом «как сэкономить до 30%» от стоимости проекта внедрения 1С.

Те, кто занимался этими вопросом, знают: сейчас стоимость проекта для предприятия среднего бизнеса составляет около 6 млн. руб.
Таким образом, снизив стоимость на 30% процентов, экономия получается - 2 млн. руб.
Ощутимая цифра. Особенно в условиях экономического кризиса, когда деньги «заметно дорожают».

- Так за счет чего же можно сократить затраты на 30% ?

- Можно ли добиться этого, не затягивая сроки и без потери качества работ ?

- Да, можно. Если следовать проектной технологии и знать некоторые ее секреты.. Надеюсь, что данная статья + мой опыт помогут вам сэкономить до 2 млн. руб. на проектах внедрения 1С.
Контактная информация: +7 (916) 304-16-80, accountit@mail.ru

1. Проектная команда
  • Назначение ген. заказчика
Первое, что необходимо, это – назначение ген. заказчика по проекту.

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

Т.е, например:
  • интерес клиентского отдела - максимально быстро и просто выписывать документы покупателям;
  • интерес бухгалтерии – полно, подробно оформлять и учитываться хоз. операции в соответствии с требованиями ПБУ;
  • интерес финансово-экономической службы – получение аналитической отчетности в соответствии с требованиями руководства, определение маржи, планирование, план-фактный анализ.
Всегда нужно помнить, что «1С» (в первую очередь) эффективна для решения учетно-аналитических задач. И еще более эффективна, для автоматизации регламентированного учета..
  • Т.е если, например, ген. заказчиком вашего проекта выбран главный бухгалтер – это хорошая (понятная) перспектива;
  • Если в рамках вашего проекта автоматизируется внутрифирменный учет (и он отличен от регламентированного), то лучшим заказчиком будет финансовый директор. Чаще всего, фин. дир - влиятельный (коммуникация, интересы руководства) и понимающий «1С» сотрудник. Т.е это - хорошая, понятная перспектива.
  • Если же ген. заказчиком проекта (именно главным..) назначен, например, начальник планового отдела, начальник производства, руководитель по логистике, директор по IT и т.д – то это (скорее) «плохой знак».

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

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

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

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

2. Решить – «делаем все сами». Cоздать IT-отдел, взять 1с программистов… И ждать результат.
Эффективной стратегией является сочетание привлеченных ресурсов и ресурсов собственных.

Логику здесь можно пояснить примерно так: есть сдельная форма оплаты труда, и есть окладная. И прим этом, эффективны сдельно-премиальные и окладно-премиальные.

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

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

Для этих целей, на проекте и необходим руководитель проекта.

Если на вашем предприятии есть руководитель по направлению «1с», или этим занимается (и разбирается в этих вопросах!) IT-директор, то руководителем проекта нужно назначать его.

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

Необходимость уделять много времени и усилий проекту – это относится и к руководителю по 1с / IT-директору тоже. Кроме того, необходимо будет хорошо ( :-) ) разбираться в той программе 1С, которая запланирована в основе проекта.

Итого: что бы повысить качество работы над проектом, работать без ущерба текущему процессу (задачам), лучше всего привлечь в проектную команду эксперта по 1с (программиста-аналитика). Такой специалист сможет решать следующие важные задачи:
  • Экспертиза решений, предлагаемых франчайзи, фрилансерами и т.д;
  • Оценка трудозатрат, контроль качества выполнения работ, отстаивание интересов компании в части принимаемых технических решений;
  • Разбор сложный ситуаций, поиск решений, консультирование по 1с при внедрении;
  • Стабильность команды, уход из проекта
Как показывает практика, большой (в т.ч. финансовый) ущерб может принести уход/смена ген. заказчика, руководителя проекта, основных подрядчиков и экспертов.

Причины ухода с проекта бывают разные, но чаще всего они объективные. Т.е те, которые произошли из-за компании-заказчика.
  • Затягивание по срокам проекта;
  • «Уход» от проектной технологии. Пересмотр, не конкретность принимаемых решений;
  • Не качественное/не компетентное руководство.
Обо всем этом нужно помнить, что бы «не потерять» проектную команду.

2. Проектный офис
  • Коммуникации
Главное, без чего проектная команда не сможет эффективно работать, это – коммуникации. От качества коммуникаций напрямую зависит качество проекта.
И как показывает практика большинства успешных проектов, лучшим способом организации работы является - «проектный офис».
Тем более это важно, когда в проектную команду входят как сотрудники компании подрядчика, привлеченные специалисты, так и штатные сотрудники.

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

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

Для этого, целесообразно подготовит соглашение о кодировании, доводить его до всех программистов и требовать его исполнения.
Аналогичная ситуация, например, с работой аналитиков и способами описания ими бизнес-процессов. Можно привести и др. примеры.
  • Приоритет содержания над формой
Прием (и исполнение) соглашений, регламентов взаимодействия повышает качество работы проектной команды. Однако «увлекаться» регламентированием не следует.

Бесполезно (и даже вредно) усложнять, «заорганизовывать» коммуникации. Сложные, многоступенчатые регламенты не будут исполняться, и будут, скорее, мешать работе.

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

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

Руководство проекта обязательно должно вести календарный план и актуализировать его по факту выполнения задач. Т.е. нужно «расписать» этапы проекта, далее задачи укрупнено, далее детально и т.д.

Нужно так продумывать последовательность выполнения работ, что бы «распараллеливать» задачи и иметь «маневр» для корректировок плана, что бы избегать простоя (из-за отклонения по срокам связанных задач).
Другими словами, нужно задействовать программу MS Project и постоянно работать с ней.
  • Оценки, резервы, торги
Что бы запланировать задачу по срокам, нужно оценить ее трудоемкость.
Если вы будете работать с подрядчиками-франчайзи, то обычно процесс оценки трудоемкости (а следовательно, и цена работы) у них отлажен.

Т.е опытный специалист всегда постарается заложить возможные риски по выполнению задачи в ее оценку. Заложить риски – это нормально. Вопрос в том, сколько процентов «в плюс» закладывается.
Нормальная практика + 20 %. Малоопытный специалист может заложить цифру, сильно отличную от этой. Причем для проекта это плохо и в случае завышения (удорожание) и в случае занижения оценки. (сбиваются сроки выполнения)

Менеджер проекта (со стороны франчайзи) так же вполне может перестраховаться или просто необоснованно завысить бюджет. Тем более, если он мотивирован на это экономически.

Так каким же образом проконтролировать оценки, согласовать их c подрядчиками и уменьшить ? (торг :-) ).

Для этого, так же эффективно привлечь эксперта по 1С. Программиста-аналитика независимого от исполнителей. Он сможет дать свою оценку и аргументировать ее для подрядчиков.

Практика показывает: часто стоимость работы можно сокращать на 25-30 %.
  • Deadline;
Крайний срок завершения работы (deadline) – важнейший регулятор, который отличает проектный подход от процесса автоматизации с неясными бюджетами и сроками.

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

Это можно сравнить с ремонтом в квартире. Как говорится: ремонт нельзя завершить, его можно только остановить.

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

Теперь, пора подвести некоторые важные итоги. Мы рассмотрели 3 критерия,
гарантирующих выполнение проекта:
  • Создание проектной команды;
  • Организация эффективной работы в проектной команде;
  • Управление сроками выполнения работ.
Иными словами, во всех реализованных (живых) проектах эти критерии были выполнены. И выполнение этих критериев в принципе достаточно, для завершения проекта.
В тех же проектах, в которых хотя бы один из них не был выполнен - такие проекты потерпели неудачу.

И так, будет считать, что все необходимые и достаточные условия для проекта - созданы.
Однако, наша задача глубже, сложнее – сократить (оптимизировать) затраты на проект, при этом не ухудшив его качество, и не растянув сроки.

Как это сделать?

Для этого существуют свои «секреты». Рассмотрим их, начиная с очень важного этапа – «Подготовка к проекту».

4. Подготовка к проекту
  • Что бы «говорить на одном языке»
С разных сторон участники проекта должны «говорить на одном языке», что бы понимать друг друга. А иначе очень затруднительно будет, например, донести свою мысль, понимание проблемы на совместном совещании. Трудно будет понимать, согласовывать проектную документацию и т.д.

«Корень» проблемы не понимания» (а точнее – очень разного понимания вопросов) – большие различия участников (проектной команды) в отношении средства и предмета автоматизации.

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

Штатные сотрудники вашего предприятия, наоборот, знают процессы и особенности «изнутри». А вот средством автоматизации и продвинутыми технологиями, скорее всего не владеют.

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

Со стороны предприятия так же выгодно задействовать эксперта по 1С (программиста-аналитика). Изначально владея средством автоматизации, он сможет и другим вашим сотрудникам помочь разобраться, освоить возможности программы.

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

Для технических специалистов - с текущей ИС и организацией ИТ-инфраструктуры.

Затраты (в размере 30 часов на/чел.) обязательно «окупятся», а затем принесут еще экономию бюджету, так как качество работы участника проекта повысится ~ в 1.5 – 2 раза. А относительно трудозатрат на большом проекте – это большая экономия.
  • Функциональное моделирование и перенос данных;
Основа нормального технического задания – это тех. требования. В свою очередь требования нужно:
  • Выявить;
  • Оценить их значимость, возможности реализации, рассмотреть альтернативы и обходные варианты;
  • Принять требования, расставить приоритеты / либо отклонить и в тех. задание не включать.
В случае проектов 1С дополнительной сложностью является то, что требования должны быть «переложены» на возможности программы (обычно, в основе - типовая конфигурация 1С) и нужно «отталкиваться» от этого.
Т.е нужно смоделировать «что будет» (с использованием типового решения) и что нужно будет еще сделать/переделать и пр, что бы удовлетворить требования к системе со стороны заказчика.

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

- Хлопотное, получается, дело.. Так ?

- Да.
- А можно ли не тратить время финансиста, бухгалтера, логиста и т.д. и не проводить функциональное моделирование ?

Можно, но в этом случае система будет проектироваться только исходя из представлений автора тех. задания. И вероятнее всего:
  • Либо будут упущения, искажения в понимании бизнес-процессов и то, «как их целесообразно автоматизировать»;
  • Либо будут упущения в части использования функционала программы (конфигурации 1С); будут предложены не рациональные, ошибочные пути решения.
Для компании выгодно, что бы в процессе функционального моделирования, на стороне заказчика выступал эксперт по 1С. Это обеспечит активное участие со стороны заказчика, и при этом повысит качество рассмотрения функциональных моделей, заставит рассмотреть и альтернативные варианты.

Одновременно с функциональным моделированием нужно задумываться над задачей переноса, ввода первоначальных данных. Эти задача (если еe не обдумать изначально) может принести большие проблемы проекту, его START UP. И как следствие – в дальнейшем возникнет ощутимое увеличение затрат.
Хорошей практикой является предварительный (так сказать «ознакомительный») перенос данных уже на этапе функционального моделирования.
Это будет очень полезно и для заполнения «модельной базы» данными, которые будут понятны для пользователя.
  • Этап №0 (фундамент проекта);
Подведем итоги... Для того, что бы:
  • повысить качество работы проектной команды;
  • суметь найти лучшие (компактные, рациональные) проектные решения;
  • хорошо подготовится к этапу переноса и START UP
- для этого нужно заложить крепкий фундамент проекта. А для этого и существует этап №0 «Подготовка к проекту».

Кроме функционального моделирования на этом этапе, обычно, выполняют предпроектное обследование бизнес-процессов и ИС заказчика.
Перечислю весь перечень задач, которые, обычно, выполняются на этом этапе:
  • (1) Поднятие компетенций участников проектной команды;
  • (2) Интервьюирование ключевых сотрудников со стороны заказчика по бизнес-процессам. Описание бизнес-процессов «Как есть». Фиксирование пожеланий «Как будет»;
  • (3) Ознакомительный перенос данных и подготовка информационных базы для функционального моделирования;
  • (4) Проведение функционального моделирования, фиксирование функциональных требований;
  • (5) Согласование основных настроек будущей ИС: учетная политика, состав основных справочных данных (подразделения, статьи затрат, номенклатурные группы, счета учета и т.д.).
Как показывает практика, хорошая подготовка к проекту – главный инструмент для снижения затрат бюджета и повышения качества проекта в целом.

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

- О чем еще пора задуматься? О производительности вашей материальной части (сервера и сеть). И особенно важно это для внедрения таких ресурсоемких программ, как УПП.
Практика показывается, что очень часто проект просто «встает» на этапе START UP, потому что о производительности оборудования попросту не побеспокоились.
- Работать невозможно, восьмерка «виснет». «Семерка» - работала быстрее!!
Что бы не «упереться» в производительность, необходимо рассчитать характеристики и подобрать оборудование (сервера), которые «потянут» работу вашей ИБ 1С.

И первое, что целесообразно сразу сделать – это оценить производительность имеющегося у вас оборудования.
Для этого, я рекомендую использовать нагрузочный тест Гилева. Это замечательный, признанный многими инструмент:



Если вы получите результат замера < 25, то это явное свидетельство низкой производительности.
Для УПП, например, приемлемый показатель минимум 35-40.
  • Расчет характеристик сервера и подбор оборудования
Основная характеристика, которую нужно учитывать при подборе оборудования – это планируемое количество одновременных пользовательских сеансов.
  • Расчет необходимой оперативной памяти на сервере рассчитывается «от количества пользователей», примерно так:

    Объем_ОЗУ = 240 мб * Колво_Пользователей + 2 Гб (для ОС) + 4 Гб (для SQL) + 4 Гб (для сервера 1С:Предприятия).

    Необходимый объем на 1-го пользователя может варироваться от 100 до 240 Мб для разных конфигураций.
  • Расчет необходимого количество ядер процессора так же рассчитывается относительно количество пользователей (максимум – 8 пользователей на 1 ядро).

    Т.е КолвоЯдерПроцессора = Колво_Пользователей/8 + 1 ядро (для сервера 1С Предприятия) + 1 ядро (для MS SQL);
К примеру, для сервера 1С со всем пакетом ПО, 50 терминальными пользователями в конфигурации «Управление Торговым Предприятием», и базой данных в 8GB оптимальной будет вычислительная мощность двух процессоров Intel Xeon E5-2650 (8 ядер, 16 потоков, 2.0 GHz). Оперативной памяти понадобится минимум 2 (ОС) + 4(SQL) + 4(1C-сервер) + 8 (160 «УТП» * 50 пользователей) = 18GB, а лучше 24-32GB(6-8 каналов DIMM по 4GB).

Для организации быстрой и надежной работы с данными, на сервере нужно организовать RAID-массив.
  • Что бы не наступить на известные грабли..
Приведу некоторые распространенные ошибки, из-за которых чаще всего страдает производительность:
  • Размещение на одном сервере терминала и сервера базы данных;
    • Нужно: терминал + сервер 1с на одном сервере. БД – на другом.

  • Cлабая дисковая подсистема
    • Нужно создать RAID (если он отсутствует), увеличить кол-во дисков, использовать высокоскоростные диски.

  • Низкая скорость передачи данных между MS SQL сервером, сервиром 1с предприятии, терминальным сервером.

    • Лучше всего, все разместить на одном физическом сервере (т.е использовать виртуализацию). В этом случает Ethernet-соединений между серверами не будет вообще.
    • Или использовать высокоскоростные Ethernet-соединения (10Gb Ethernet)

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

6. Лишнего не надо..
  • Реализм
Практика показывает, что до 20% функциональности разрабатываемой/дорабатываемой по тех. заданиям, при внедрении и дальнейшей работе – не используется.
Есть полезное правило: если некая программа есть, но она ни кем не используется, то значит - нет такой программы.

Что бы зря не работать (и не платить в «пустую») нужно руководствоваться реализмом, помнить об основных этапах становления ИС: документ – учет – планирование.
Т.е первое - обеспечиваем отражение в программе хоз. операций, бизнес-процессов и пр. документов. При этом, реализуем основные требования к учету. Это - главное.
Про задачи планирования помним и стремимся «приблизиться» к ним.

Таким образом, очень полезно провести независимый (от разработчиков ТЗ) аудит тех. заданий. Для того, что бы оценить «жизнеспособность» того, что предлагается реализовать, нужен опыт. Эту работу сможет провести эксперт по 1с (программист-аналитик).
  • Оптом не дешевле, лицензии, прочий софт
Как известно программы «1С» можно купить только через франчайзи.
И если, например, вы объявляете, что у вас сейчас 1 филиал, но скоро планируется открытие еще 3, то менеджер по продажам 1С обязательно посчитает кол-во программ (лицензий) для 4-х филиалов.
И это нормально. Работа у него такая. :-)

А ваша задачи – иная, оптимизировать затраты.

И нужно понимать, что в большинстве случаев, для лицензий 1С правило «оптом дешевле» не срабатывает. Т.е можно купить лицензий по минимуму, и при необходимости уже докупать пакетами по 5/10/20 лицензий и т.д.

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

Сложится может по разному..

Для целей подготовки, разработки, тестирования, переноса данных, обучения – достаточно минимального количества лицензий.
  • Торговое оборудование
Если в рамках проекта запланировано использование торгового оборудования, то также не стоит сразу его «массово» закупать.
Но тут ситуация несколько иная, чем с лицензиями. Оптом - будет дешевле, однако, советую - не торопится покупать сразу.

Дело вот в чем. Что бы ясно понять, что данная модель оборудования вам подходит, нужно поработать с ним.
И делать это (обязательно) нужно «в связке» с вашей ИС.
Тогда станут понятны нюансы.
Например, возможно, что оборудование-то неплохое, однако в связке с вашей программой работать с ним – неудобно и т.д. Т.е нюансов может быть много и задача подбора торгового оборудования – отдельная.

Кстати характерно, что цены на торговое оборудование в Китае (если закупать там), намного ниже, чем покупать в РФ.
Т.е можно самостоятельно подобрать оборудование и подключить его к вашей 1С. В этом вам так же сможет помочь эксперт по 1С.

7. Руководство проектом
  • интеллигентная твердость
Что бы настроить эффективную работу в проектной команде, что бы поддерживать качество и не растерять команду, руководителю проекта нужно проявлять такое качество, как интеллигентная твердость.

Т.е. просто проявлять твердость, настырность и все.. – это не правильно. Это - не бригадой строителей руководить.

С другой стороны, нужно проявлять требовательность, но делать это интеллигенто.
  • cамодисциплина
Часто так бывает, что руководить проектом берется некий «очень занятой человек».
Например, финансовый директор, заместитель управляющего компании и т.д.
Он очень загружен основной/прочей работой и времени на проект у него попросту нет.
Например, он в срок не успевает согласовать проектные документы, разобраться в проблеме, принять решение, изучить 1С и т.д.

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

Т.е принимать решения (и отвечать за них) должны специалисты.
Нормальный специалист ощущает доверие со стороны руководителя и ценит это.

Принятие сложных, спорных решений – одна из главных задач руководителя.

Очень распространена практика, когда руководитель «тянет» с принятием таких решений, то говорит «да», то – «нет», меняет свою позицию… А потом (в случае неудачи) «кивает» на подчиненного.
Это – плохая практика, которая расшатывает проектную команду.

Руководитель должен поступать так: сначала выслушать различные/спорные мнения, а затем, уже самостоятельно принять решение и отстаивать его выполнение.

8. Мотивация
  • Пряник и кнут
Рассмотрим (в двух словах) характерную ситуацию: руководство компании, главный бухгалтер и начальник IT задумали переход на новую 1С. У каждого – своя мотивация, свой интерес на этот счет.
Однако, втроем проект не реализуешь, и следовательно:
  • Для создания проекта нужно мотивация проектной команды;
  • Для внедрения – мотивация всех, в т.ч. и работников компании.
Предположим, что проектная команда собрана, в ней – профессионалы, работают с нормальными задачами за достойные деньги. В конце концов, проекты – это их работа.
А вот что касается работников компании на этапе внедрения, то зачем им нужен этот переход на новую 1С ?
У них и так «много своей работы», а тут нужно еще изучать новую программу. Да еще и участвовать в ее отладке?

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

Для мотивирования существуют как финансовые, так и иные «рычаги». Рассмотрим эти возможности - начнем с финансовых. Т.е «кнут» и «пряник».
  • В качестве «пряника» хорошо срабатывает премия за успешное участие в проекте внедрения;
  • В качестве «кнута» - пониженные оценки эффективности работы сотрудника. И как следствие отсутствие (или понижение) материальных и карьерных благ.
  • Интерес
Теперь рассмотрим «нематериальные» рычаги стимулирования. Они есть и ими нужно умело пользоваться. Хотя, конечно, все зависит от индивидуальности человека и не для всех это сработает.

И тем не менее… Освоение новой программы может восприниматься не только как обременительное, но и как интересное занятие:
  • Становиться меньше рутинной, скучной работы. Появляется что-то «свежее», в более «продвинутой» программе;
  • Знание «новой» программы пригодится не только на данном рабочем месте, но и будет плюсом при переходе на другую работу.
  • Энтузиазм
Ощущение того, что у тебя получается (начало получаться), что ты осваиваешь что-то новое, что ты начинаешь в этом разбираться - все это вызывает энтузиазм.
Очень эффективно, например, провести предпроектное обучение по 1С ключевых сотрудникам заказчика.
В случае успешного ознакомление с программой, понимания ее сильных сторон, возможностей, у заказчика возникает уверенность и энтузиазм в работе над проектом.

9. Start UP

Самый напряженный и непростой этап на проекте – это START UP.
Что бы пояснить эту мысль подойдет, пожалуй, такая цитата:

Всякая революция лишь тогда чего-нибудь стоит, если она умеет защищаться (В.И. Ленин)
Далее приведу ряд советов, что бы пройти этот этап с наименьшими потерями и добиться результатов.
  • Перенос данных
Перенос данных, пожалуй, можно сравнить с квартирным переездом…
Нужно продумывать детали, рассчитывать… Однако, «гладко» все никогда не пойдет. И часть вещей придется оставить за пределами новой квартиры.

Практика показывает, что срабатывают следующие правила:

1. Перенос данных должен быть простым. Закладывать сложные схемы, тратить много времени на их реализацию – не эффективно. В ограниченных временных условиях (во время переезда жить на улице не хочется J ) сложные схемы не сработают.

2. Придется проверять и «крыжить» данные (кто не знает, что такое «крыжить» – выясните у бухгалтера). Нужно заранее сформировать спецбригаду под эту работу и оснастить ее необходимым инструментарием (универсальные обработки 1С и т.д.)

3. Назначить deadline и … глубоко вдохнуть.
  • Обучение сотрудников, консультирование, разбор полетов
Что бы сотрудники смогли более-менее разумно начать работать в программе, их надо этой новой программе обучить. Приведу несколько советов, как это делается:
  • Обучение должно происходить непосредственно (за день-два) перед намеченным сроком начала работы в программе. Ошибочно проводить обучение заранее – все забудут, чему их учили. Т.е – попусту потраченное время.
  • Нужно проводить обучение в офисе заказчика, группируя сотрудников по отделам.

Например, собирают менеджеров клиентского отдела перед большим экраном.. И девушка (консультант по 1С) показывает им на экране «как оформлять заказы клиентов», отвечает на вопросы приятным голосом.

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

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

Очень хорошо, если какие-то инструкции есть в вашей конфигурации в виде хелпов к объектам. Пускай - даже кратенько.

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

START UP – напряженный момент, когда одного консультанта на всех не хватает. На этот этап стоит привлечь дополнительные ресурсы.

И вот, программа заработала и … посыпались ошибки. :-(

А куда же без них
?

Здесь стоит привести еще одну цитату:

Правопорядок в стране определяется не наличием воров, а умением властей их обезвреживать! (Глеб Жеглов).
Т.е основная задача – оперативно реагировать, выявлять причины ошибок и исправлять их. Приведу пару советов по организации данного процесса. Основной момент – нужно централизовать прием и диагностику ошибок.
  • Нужно организовать линию тех. поддержки. Все ошибки должны отправляться на тех. поддержку. Там – регистрироваться, расставляться приоритеты (по важности) и сроки исправления.
  • Аналитики, проектировщики, ведущие программисты должны получать информацию об ошибках, определять способы их исправления и ответственных за это.
  • Нужно стараться обеспечивать исправление ошибок таким образом, что «лишний раз не дергать» всех пользователей и «не выгонять» их из базы.

Т.е хорошая практика, это когда для исправления ошибки программисту достаточно внести некие изменения во внешнюю обработку, и все.
  • Корректировка тех. задания, новые задачи;
К сожалению, на всех проектах встречаются не только ошибки/недочеты реализации, но и более серьезные вещи. Т.е – ошибки проектирования.

Еще начиная с этапа №0 нужно стремиться минимизировать такие ошибки, но все равно они будут.
И если такая ошибка выявлена, то (по существу) речь будет идти не об ее исправлении, а о корректировке тех. задания, переделке того, что сделано, новых задачах, подпроектах и т.п.

Этой ситуацией, всегда недовольны обе стороны – и заказчик (он недоволен, почему не сделали.. :-( ) и подрядчик (почему так объяснили, почему подписали ТЗ..).
И далее, всегда возникает спорный вопрос: кто будет нести издержки по исправлению таких ошибок:
  • Заказчик будет настаивать, что это «косяк» подрядчика и исправление - за его счет;
  • Подрядчик будет настаивать, что это «доп. работа» и оплатить ее должен заказчик.
Для урегулирования острых, не простых ситуаций хорошо подходит вариант «50 % на 50%». Т.е «косяк» признается двухсторонним и издержки на его исправление стороны делят пополам.

10. Этапы становление ИС
  • Документ – Учет – Планирование
Допустим, что проект таки прошел точку START UP. Пользователи вводят в базу документы, выдают документы контрагентам, оформляют другие операции.

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

И если вдруг выясняется, что возникают «дырки», какие-то механизмы «работает криво» или вообще «отвалились», то нужно срочно исправлять ситуацию.
Надо понимать, что с каждым днем восстановить учет, исправить ситуацию будет все сложнее и сложнее.

Все основные учетные механизмы:
  • ТМЦ на складах;
  • Взаиморасчеты с контрагентами;
  • Выручка;
  • Себестоимость;
  • Доходы и расходы;
следует поддерживать в актуальном состоянии сразу.

Двигаемся дальше и, предположим, что с учетом вы справились. Что дальше ?
Далее, нужно налаживать планирование.
Обычно, это задачи:
  • Оперативного планирования денежных средств;
  • Планирования продаж, управление заказами клиентов;
  • Планирования закупок, обеспечения. Управления заказами поставщиков;
Ну а после этого, уже можно переходить к задачам долгосрочного планирования (бюджетирования).
  • Ограничения доступа, персонализация интрефейсов, АРМ
Параллельно с налаживанием учета, чаще всего приходятся решать задачи «точечного» ограничения доступа пользователей и настройку их интерфейсов. Обычно, руководство подразделений активно ставит такие задачи по ходу первичного внедрения.
Прописывая «точечные» ограничения и настраивая интерфейсы (кто из пользователей может увидеть/изменить такой-то реквизит, как определить «чужие» данные, кто может чужие данные изменить и т.д.) де-факто налаживаются, утверждаются регламенты работы подразделений с документами и прочими данными.

Ну и наконец, сами пользователи начинают процесс «юзабилити». Т.е инициируют задачи по созданию для них АРМ (автоматизированных рабочих мест), т.е. что бы было все «под рукой», ничего лишнего, и что бы «не лазить в отчеты».
  • От внедрения к сопровождению
Ну что, пора завершать повествование. :- ) Представим, что наше внедрение подходит к концу и с задачами мы справились.
Что дальше ?

А дальше – новый этап, который называется сопровождение.
Необходимо будет развивать функциональность программы под новые требования бизнеса, создавать новые отчеты, настраивать более удобные АРМ пользователей, интегрировать 1с с другими программами и пр.

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

Платежный календарь в 1с 8.2, 1с казначейство и бюджетирование, оперативное планирование денежных средств.


1. Введение

Планирование денежных средств - одна из главных задач управленческого учета в отличии от учета бухгалтерского.

Конечно, между УУ и БУ есть и другие существенные различие (разные требования к аналитике, к оценке и переоценке активов/обязательств, необходимость создания резервов и т.д.), но необходимость решать задачи планирования – это самая сложная из них.
Сложность планирования заключается не только в подготовке плана (его расчету, формированию по разным сценариям), но необходимо еще:
  • Выполнять перепланирование;
  • Актуализировать планы, переносить корректировки на следующие периоды;
  • Проводить план - фактный анализ.
Следует признать, что на большинстве предприятий (использующих для автоматизации «1С») планирование в программе не ведется.
«Нам бы учет наладить..» - так рассуждают многие.

Учет нужно наладить, да, но не в ущерб планированию.
Конечно же, планированием все равно занимаются (но не в «1С», а XLS). И самую первую, основную задачу (которую и стараются решить) – это планирование денежных средств.

Планирование денежных средств (далее д/c) разделяется на :

  • (1) Стратегическое (бюджетирование);
  • (2) Оперативное.
И если бюджетирование (конечно, при подходе к планированию «сверху-вниз»), можно осуществлять с помощью XLS, то выполнять оперативное планирование – нельзя.
Суть в том, что с таблицами бюджетов чаще всего работают минимум пользователей (1-2 человека). Для большинства предприятий количество статей бюджетирования и пр. аналитик – их не так много. Т.е все можно обработать «ручками» в XLS.

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

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


Еще важным отличием оперативного планирования от бюджетирования является то, что оно чаще идет «с низу – вверх». Т.е от «Заявок на расход д/c», которые все время оформляют работники подразделений.

И эти заявки, соответственно, нужно вовремя обрабатывать, принимать / отклонять, «ставить в план» и оплачивать.

Итого: оперативное планирование д/с - это самая первая из задач планирования, которая должна быть автоматизирована в «1С» у любого предприятия.

И в результате планирования, финансовый департамент / казначейство должны «видеть» в системе:
  • Когда, кому, c какого расчетного счета/кассы, на какую сумму нужно оплатить;
  • Какой остаток д/c будет на «такую-то» дату c учетом текущих остатков, запланированных расходов и поступлений д/c. Нужно избегать т.н. «кассовых разрывов».

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

    Т.е возникает необходимость работать с календарем расчетов.
Цель данной статьи – рассказать о возможностях автоматизации оперативного планирования д/c. При этом, будет проведен сравнительный анализ 3-х разных тиражных конфигураций (две – типовые от «1С», одна - специализированная от компании wiseadvice).

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

2. Возможности УПП 1.3


На данный момент фирма «1С» еще не выпустила долгожданную, новую редакцию УПП (ред 2). И по этому, будем ориентироваться на то, что доступно - соответствующие подсистемы УПП 1.3:




Нужно отменить, что подсистема «ЗаявкиНаРасходДенежныхСредств» обновлялась в конфигурации относительно не давно (2011 г). И как следствие, в режиме управляемого интерфейса, в панели разделов появился пункт «Заявки на расходование д/с/».




Если попробовать в типовой конфигурации, в файловом режиме, открыть форму документа «Заявка на расход д/с» (она же, ЗРДС), то сразу возникает ошибка по переменной «глОбщиеЗначения» из общего модуля «РаботаСОбщимиПеременными».

Такого рода ошибки можно будет исправить, однако, как говорится: «осадочек остался». Т.е «шероховатостей» в подсистеме ЗРДС УПП – хватает.
Возможность через WEB-браузер оформить документ ЗРДС является полезной, но при этом на практике придется хорошенько задуматься над упрощением и эргономикой типовой формы документа . Особенно это будет важно для мобильных устройств.

А вот что касается платежного календаря, то в режиме тонкого клиента, удаленно через WEB-браузер и т.д. воспользоваться им не получится. Причина в том, что подсистема «Управление денежными средствами» давно не обновлялась и, в частности, отчет «Платежный календарь» построен не на системе компоновки данных. А следовательно, у этого отчета нет возможности использования в тонких клиентах, нет возможности создавать для него произвольные настройки.

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

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

  • Согласование – это подтверждение необходимости оплатить заявку. Обычно, согласование должно проходить через начальников подразделений, руководителей и других ответственных лиц компании.
  • Утверждение – это завершающее подтверждение (со стороны казначея) того, что заявка будет оплачена. При этом обязательно должна быть определена дата платежа, расчетный счет/касса с которой будет осуществлена оплата. Таким образом, платеж попадает в оперативный план (платежный календарь).
Нужно отменить, что ряд моментов типовой функциональности УПП не обеспечивают того, что требуется при реальном внедрении подсистемы.
Об этих «моментах» я напишу позже, а пока рассмотрим какую функциональность предоставляет типовая конфигурация.
  1. Включить использование механизма согласования заявок можно отдельно, по каждой организации.


  • Предусмотрена настройка последовательности прохождения заявки по маршрутам, иерархия маршрутов.
  1. При этом нужно отметить, что иерархия в справочнике подразделения не учитывается в механизмах маршрутизации заявки.
  2. Так же нужно отменить, что согласование и утверждение технически построено без применения механизма бизнес-процессов.



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



  • Для каждого подразделения можно назначить соответствующую точку маршрута согласования. Суть в этом такая: при оформлении заявки (ЗРДС) обязательно должно быть указано ЦФО (подразделение). И в зависимости от указанного подразделения, УПП «находит» соответствующую ему точку согласования и «отправляет» заявку на согласование в эту точку.



Так же в настройке маршрута согласования допустимо не указать подразделение. В этом случает, такая точка согласования будет «применятся» для всех ЦФО, для которых конкретно не указана соответствующая точка маршрута.
  1. Само согласование выполняется с помощью специальной обработки «Согласование заявок»





  1. Анализ запланированного наличия денежных средств, графика платежей и отслеживания кассовых разрывов выполняется в отчете «Платежный календарь».



Помимо планируемого расхода д/c (ЗРДС) можно учитывать и планируемое поступление д/c. Для этих целей предусмотрено оформление специального документа «Планируемое поступление д/c».




Нужно отметь, что документе «Планируемое поступление д/c» хотя и есть состояния (подготовлен, согласован и т.д), но возможность согласовать этот документ (так же как ЗРДС) отсутствует. Т.е изменение статусов документа возможно только в режиме «ручного управления».

И еще в УПП есть возможность учитывать планируемое поступление д/с от покупателей без оформления документов «Планируемое поступление д/с».

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



  1. Помимо отчета «Платежный календарь» предусмотрен отчет «Анализ доступности денежных средств».




При этом предусмотрена возможность резервировать д/c (по заявкам на расход) или размещать заявки в счет запланированных поступлений.




Так же есть функционал закрытия ЗРДС и планируемых поступления д/c. Для этих целей, в режиме «обычного клиента» предусмотрены документы «Закрытие заявок на расходование/поступление д/c».

Однако, данная функциональность так же не поддерживается в режиме тонкого/web-клиента.
Здесь нужно понимать, что методика «жесткого резервирования» сильно завязана на хронологию ввода документов, и это затрудняет корректировки и перепланирование.

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


    В УПП предусмотрены отчеты «Дебиторская задолженность по срокам/по интервалам».







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

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





Итак, функциональные возможность УПП рассмотрели и теперь я перечислю те моменты типовой конфигурации, которые на практике, на проектах, приходится дорабатывать:
  1. По документу «Заявка на расходование д/c»:

    1. В документе можно указать «Подразделение» (кстати, в конфигурации оно обозначено как ЦФО – центр финансовой ответственности). Но вполне возможна ситуация, когда заявка оформляется от одного подразделения (ЦФО), и при этом затраты нужно будет далее отнести/распределить на другое/другие подразделения (ЦФУ – центры финансового управления).

      Возможность указывать ЦФУ и т.д. – отсутствует.
    2. Оформить заявку можно только в валюте взаиморасчетов. При этом счет поставщика может быть выставлен в любой валюте. Использовать для этих договор контрагента с признаком «расчеты в условных единицах» не всегда удобно и возможно.

      Возможность оформить заявку в произвольной валюте, c дальнейшим пересчетом платежа по курсу и т.д. – отсутствует.
    3. «Управлять» выбором маршрута согласования заявки можно только по средствам установки (при первоначальном вводе документа) подразделения. Но практике, могут требоваться «отклонения» от обычных маршрутов, переадресация в (определенных случаях) заявки на других ответственных лиц и т.д.

      Возможность изменять маршрут, перенаправлять заявку на другие маршруты – отсутствует.


    1. Отсутствует возможность запланировать перемещение д/c между расчетными счетами, cо счета в кассу и прочее.

  1. Процесс согласования:

    1. Существует возможность согласовывать ЗРДС, но отсутствует возможность согласовывать планируемое поступление д/с.
    2. На практике возникает необходимость выполнять согласование за других сотрудников. При этом, в системе нужно фиксировать еще и информацию о том «кто и за кого выполнил согласование».

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

      Резюмируя - возможность согласовывать за другого исполнителя, возможность указать кто и за кого имеет право согласовывать – отсутствует.
    3. В процессе согласования заявок, когда заявка переходит на согласование следующему по маршруту, востребована функциональность автоматического информирования (по e-mail) следующего исполнителя, а так же автора заявки.
    4. Если автор заявки уже является ответственным за согласование/утверждение (на любом из этапом маршрута!), то вполне логично что бы программа автоматически «сокращала» маршрут, переадресую заявку на наиболее высокий, доступный уровень. Однако, в УПП это не предусмотрено.

  1. Отчеты, права доступа.

    1. Востребована возможность ограничения доступа к заявкам только по доступным авторам / исполнителям (согласователям); по доступным пользователю подразделениям.
    2. Отсутствует отчетность по контролю (по дням и интервалам) фактической и запланированной задолженности. Это актуально и для покупателей и для поставщиков.
    3. Отчетность и часть функционала не пригодны для работы в режиме тонкого/web-клиента.

  2. Учет по регулярным соглашениям, договорам.

    1. Часто встречаются ситуации, когда необходимо регулярно осуществлять оплату поставщикам. Например, арендные платежи и т.д.

      В УПП не автоматизировано отражение в платежном календаре и т.п. этих предстоящих расходов. Т.е необходимо в режиме ручного управления отслеживать такие платежи и оформлять заявки на платеж, что неудобно и трудоемко.
    2. В договорах с покупателями, c поставщиками могут быть прописаны условия по проценту предоплаты, по срокам оплаты и т.д.

      В УПП не автоматизирован учет всей этой информации и (как следствие) автоматическое отражение ее в платежном календаре.


3. Возможности УТ 11.1

C выходом новой конфигурации «Управление торговлей ред.11» появилось много новых, полезных возможностей по задачам оперативного планирования и контроля финансов.
Пожалуй, наиболее существенно в этой части в УТ11 (по сравнению с УПП 1.3) – это механизм учета графика платежей. Этот механизм как раз «закрывает» то, чего сильно не хватало – автоматизация планирования/учета по регулярным соглашениям, договорам.

Таким образом, в УТ11 можно вообще не оформлять (если нет необходимости, конечно) документы планирования расхода и поступления д/c, и при этом, платежный календарь будет нормально формироваться.



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





Функциональность отчета сильно расширилась (по сравнению с УПП 1.3) за счет использования системы компоновки данных. Теперь, отчет можно формировать в тонком/web-клиенте, сохранять в базе и назначать разным пользователям нужные им настройки.

Кроме планирования расхода и поступления д/с в УТ11 появилась функциональность планирования перемещения д/c. Для этих целей можно оформлять документы «Распоряжение на перемещение д/c».

По сравнению с УПП 1.3 для документа «Заявка на расходование д/c» увеличилось количество учитываемых видов хозяйственных операций:



Появилась возможность утверждать как документы «Заявка на расходование д/c», так и другие распоряжения:



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




К сожалению, в УТ11 (как и ранее) не предусмотрена возможность анализа календаря задолженности по поставщикам. Однако, доработать УТ11 по данной задаче вполне возможно.

Резюмируя: новые методологические решения «1С» вместе с возможностями платформы 8.2 предоставляют хорошую базу для автоматизации задач оперативного планирования и контроля д/c.

Но вместе с тем надо понимать, что конфигурация УТ11 не является полноценным, готовым решением для автоматизации казначейства и планирования д/c.
  • Во-первых, в УТ11 в очень упрощенном виде реализован механизм согласования/утверждения заявок на расход и др. документов планирования д/c. Т.е нет механизмов маршрутизации, процесс утверждения заявок сведен к простой установки статусов.
  • Во-вторых, в УТ11 нет подсистемы бюджетирования и (как следствие) нет функционала контроля заявки по запланированным бюджетам.

4. Возможности WA: Финансист

Исторически конфигурация «WA:Финансист» была разработана на базе продукта «Управление казначейством».

И при этом, в новое решение «Финансист» от компании WiseAdvice входят еще:
  • Подсистема бюджетного планирования;
  • Подсистема управления договорами;
  • Подсистема формирования и учета фактических платежей;
  • Гибкий, настраиваемый механизм формирования/заполнения документов на основе шаблонов;
  • Гибкая, настраиваемая подсистема интеграции с клиент-банком.
Рассмотрим основные функциональные возможности «WA:Финансист» в части казначейства - от учета условий по договорам до формирования платежного календаря.
  1. В разделе нормативно-справочной информации для договора предусмотрена возможность фиксации различных условий выполнения и графика платежей.

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


  2. По данным графика платежей предусмотрен механизм автоматического формирования документов казначейства (заявка на расход д/c, планируемое поступление д/c).

    При этом для автоматизации заполнения могут использоваться настраиваемые шаблоны документов.


  3. Механизм шаблонов является очень функциональным и позволяет настроить правила автозаполнения (формирования) документов по указанным правилам, параметрам.



  4. В подсистеме оперативного планирования предусмотрены различные виды документов.



  1. Журнал «Заявок на расход д/c» имеет эргономичную форму. Статусы документов учитываются автоматически, предусмотрена их цветовая идентификация.


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

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



  1. Конфигурация «WA:Финансист» позволяет настраивать условия маршрутизации: практически любой сложности, параметрические (в УПП – только настройки для выбранного ЦФО).



    Технически, маршрутизация построена с использованием механизма бизнес-процессов.




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




  1. Предусмотрена функциональная, удобная форма для обработки заявки казначеем / финансовым контролером.



  1. В процессе утверждения заявки можно не только согласовать/отклонить документ (как это сделано в УПП), но доступны и другие функции: например, отправить документ на доработку, либо запросить доп. информацию.

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

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

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

    Основной «изюминкой» «Платежного календаря WA:Финансист» (в отличии от других конфигураций по казначейству) является возможность визуального, т.е. прямо в форме отчета «перетаскивания» остатков д/c между датами и местами учета.

    Т.е. отчет «Платежный календарь» становиться непосредственно инструментом выполнения корректировок и оптимизации финансового плана.

    Таким образом, процесс выравнивания финансовых активов, закрытия кассовых разрывов и т.д. становится визуальным и интуитивно понятным.

    А после того, как выравнивание фин. активов завершено, по кнопке «Применить изменения» автоматически вносятся все необходимые изменения в документы оперативного планирования д/c.





5. Итоги




Выводы :

  1. Для автоматизации работы финансовых департаментов, казначейств, организаций со сложной орг. структурой наиболее подходящим решением является «WA:Финансист».

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

    Преимуществом решения «WA:Финансист» является развитая функциональность и большое количество механизмов настроек программы. Таким образом, внедрение этого решения возможно в короткие сроки (т.н. «коробочное внедрение»), без доп. разработок, программирования и т.д.

    Так как в решении заложены механизмы двухстороннего обмена со всеми основными типовыми конфигурациями, то интеграция в имеющуюся структуру (обмен данными с базами УТ, УПП, Комплексная, Бух) будет не сложной.
  2. Для автоматизации фин.департамента / казначейства в рамках проекта комплексной автоматизации лучше всего подойдем решение на базе УПП.

    При этом нужно понимать, функциональность УПП потребует доработок.

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

    Таким образом, внедрение УПП по этим задачам следует выполнять только в рамках проекта автоматизации.
  3. Для крупных организаций, для автоматизации департамента казначейства УТ11 не подходит.

    В данном решении, во-первых, отсутствуют механизмы согласования/утверждения документов планирования.

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

    Однако, УТ11 отлично подойдет для автоматизации (в т.ч. оперативного планирования д/c) небольших фин. отделов компаний.
Фото:

Управленческий учет в УПП (управленческий учет 1с 8; 1с затраты; учет затрат в 1с; распределение затрат 1с)


1. Предисловие

Цель данной статьи – помочь найти рациональные пути решения задач т.н. «управленческого учета» (далее УУ) средствами программы «УПП».

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

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

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

К сожалению, очень многие допускают такие ошибки проектирования. И, пожалуй, среди всех контуров учета, которые мучительно и долго (а следовательно - дорого) «переписываются» «лидирует» (в большинстве случаев) УУ.

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


И еще (обращаю ваше внимание), если у вас ранее не было опыта в решении задач автоматизации УУ, то в статье есть раздел №2, который поможет вам быстрее «войти в курс дела».
Раздел №2 поможет раскрыть понятия УУ, что бы было проще понять суть задач УУ и не упустить важные моменты при проектировании информационной системы.

2. Управленческий учет - это..

Все (с разных сторон) говорят про «УУ» и понятие УУ сильно «перегружено». Кто-то (например) полагает, что задача УУ - это расчет прибыли от продаж товаров и расчет долгов контрагентов; для кого-то УУ – это планирование платежей; для кого-то - формирование бюджетов и т.д…

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

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

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

Здесь главное условие - предоставить все необходимые (для УУ) данные «в срок» (обычно, до конца текущего месяца).

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

Далее, (для понимания задач УУ), я приведу ряд «распространенных понятий» о том «что такое УУ». Каждое такое понятие «от части» справедливо, «отчасти» – нет.

Я прокомментирую данные понятия и (в итоге), сформулирую «практическое» понятие УУ и задачу «миниум» его реализации.

------------------
(1) УУ - это более детальный и точный учет, чем бухгалтерский…

Это может быть так, но далеко не всегда. Подсистема регламентного учета УПП является мощным инструментом, который позволяет вести учет как на плане счетов, так и дополнительный (т.е. более детальный) учет на регистрах учета (например – регистры учета НДС). Так же на плане счетов «Хозрасчетный» предусмотрена возможность использования различных аналитик . И в т.ч. УПП обеспечивает возможность добавлять свои аналитики (субконто).

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

Например, ваша компания давно работает с контрагентом. Владелец компании-контрагента все это время не менялся, а вот «вывески», юр. адреса и название – менялись. Таким образом, бухгалтера внесли в базу нескольких контрагентов, хотя для целей УУ (по сути дела) это один контрагент (одна фирма). Отклонение бухгалтерского учета от «реальности» в этом случае очевидна.


.. И тем не менее , вариант с «Бухгалтерским управленческим учетом» – самый короткий путь к достижению цели. И так, где это возможно, я рекомендую в УПП именно этот путь.

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

(2) УУ – это «реальный учет», а бухгалтерский – это «белый» (фискальный) учет.

Опять-таки - далеко не всегда. Часть компаний (например, многие западные) работают «по белому» и вполне могут вести «Бухгалтерский управленческий учет».

Но даже если часть данных не должна отражаться в БУ (а должна только во внутреннем учете!), то технически в УПП, например, есть такой вариант:

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


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

(3) УУ показывает текущие (актуальные) данные; он «оперативнее» чем бухгалтерский учет.

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

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

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

Однако, возможна и другая ситуация (пример), когда входящие услуги оплачены и фактически оказаны фирмой-контрагентом, однако акт выполненных работ своевременно предоставлен контрагентом не был. И в результате, в бухгалтерском учете поступление услуг оказывается «не оформленным» (и по бухгалтерскому учету числиться дебиторская задолженность), а по УУ ее быть не должно.


И наконец, еще одно распространенное отличие УУ и бухгалтерского учета: закрытие периода по УУ требуется выполнять раньше (в начале нового месяца, не позднее 10 числа), чем по РУ.


По этой причине потребуется согласовывать сроки формирования бух. данных и дальнейшее «закрытие от изменения» данных выбранного периода .

(4) УУ позволяет выполнять планирование, а бухгалтерский ориентирован только на прошлое, т.е на фиксацию свершившихся фактов хоз. деятельности.

С этим стоит согласиться: в подсистеме регламентного учета УПП не предусмотрены, например, механизмы планирования или бюджетирования.


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

  1. План-фактный анализ;
  2. Актуализация планов и бюджетов (коррекция их «до факта»).


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

А далее, уже в рамках УПП (средствами «1С») формируют план-фактный анализ и выполняют актуализацию планов .

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

После того, как приведены все эти примеры, я наконец таки, сформулирую свою формулировку: «что такое управленческий учета в УПП»:


УУ в УПП – это набор механизмов и методик их использования для формирования отчетности, предназначенной для целей текущего (и прогнозирования в «обозримом» будущем ) финансового состояния компании.

В итоге (заинтересованных лиц) всегда интересуют следующие отчеты:
  1. Отчет о доходах и расходах;
  2. Отчет о движении денежных средств;
  3. Управленческий баланс;
Т.е как бы "иначе" не была для вас «озвучена задача автоматизации управленческого учета в «1С», в итоге вы должны понимать : «нужно готовиться к предоставлению вот этих отчетов».
Если же подойти к этому вопросу еще более практически (что в первую очередь необходимо примерно 80% компаний), то это пункт 1. Т.е «Отчет о доходах и расходах».

Собственно, автоматизированное формирование этого отчета и есть «задача миниум» УУ.
А техническая задача автоматизации «1С» УПП – обеспечить его формирование.

3. Базовые задачи и известные трудности их решения.

Так в чем же «известные трудности» реализации УУ в УПП, раз «на выходе» (см. задачу миниум) достаточно получить отчет, схожий с формой № 2 (отчет о прибылях и убытках) стандартного бухгалтерского баланса ?


А для других отчетов («Отчета о движении денежных средств» и «Баланса») так же есть бухгалтерские аналоги : форма №4 (движение ден. средств) и форма №1 (бух. баланс) ?

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

  • Отчет о доходах и расходах УУ (в отличии от регл. учета) должен формироваться «в разрезе» центров затрат (другое распространенное название – ЦФО : центр фин. ответственности).
Т.е в отличии от регл. учета здесь нужно «раскрыть» доходы и расходы «по подразделениям» (это уже в терминах УПП). Иными словами, нужно показать : какие подразделения работают более эффективно (приносят дохода больше, затрат потребляют меньше и т.д).

В регл. учете детализация «до подразделений» не предусматривается. Однако стоит заметить, что в конфигурации «Бухгалтерия предприятия корп . 2» «подразделение» стало измерением учета (хотя и не балансовым). Т.е можно сказать что «Бухгалтерский управленческий учет в «1С» тоже «двигается» в этом направлении. Однако, подсистемы регламентного учета конфигурации УПП это пока «не касается».

  • Отчет о движении денежных средств (в отличии от регл. учета) то же должен формироваться «в разрезе» центров затрат.
Т.е в отличии от регл. учета движения д/с (например входящие и исходящие платежи) нужно обязательно «привязывать» не только к статьям движения денежных средств, но и к местам возникновения затрат (далее МВЗ). Т.е платежи уже не могут быть «просто по организации в целом», а должны быть привязаны МВЗ.

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

Именно в распределении расходов и затрат (в том числе долями или иными способами) состоит одна из наиболее распространенных задач автоматизации УУ.

  • Управленческий баланс - более сложная задача автоматизации, чем (1) и (2).

Во-первых, потому что для решения задач (1) и (2) требуется обеспечить учет оборотных показателей. А для задачи (3) (кроме «оборотных») нужно ввести и учитывать еще и остатки.

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

Конечно, если у вашей компании сейчас одно единственное направление деятельности (например «общественное питание»), то разделять баланса «по направлениям деятельности» не понадобится.

Однако, если собственник бизнеса (например, завтра) решит развивать новое направление бизнеса (допустим, розничная торговля продуктами питания), то от вас, скорее всего, потребуют «обеспечить формирование упр. Баланса» в разрезе направлений: общественное питание / розничная торговля продуктами.

Для разделения учета по «направлениям деятельности» в УПП можно использовать «номенклатурные группы». Например, «общественное питание», «розничные товары».

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

  • Пример «A»:

В состав компании входит IT-отдел, который оказывает услуги по обслуживанию оборудования и программ. Потребителем услуг выступает бухгалтерия и отдел продаж. При этом, IT-отдел является отдельной организацией « A», выделенной на отдельный баланс.

В конце каждого месяца от имени этой отдельной организации «А» ( IT- отдел) выставляется на другую организацию «Б» акт выполненных работ.

Акты выполненных работ (как и полагается) вводятся в программу «УПП», и при этом в регламентном учете возникают доходы по организации « A» и расходы по организации «Б».

Однако, у этих организации один собственник и (следовательно) для целей УУ таких «доходов» и «расходов» возникать не должно (все это происходит внутри единой компании).

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

И более того, расходы IT-отдела (например, зарплату работников) справедливо (и правильно) с позиции УУ каким-то образом распределить между «бухгалтерией» и «отделом продаж».

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



  • Пример « B»:

Товародвижение в компании происходит таким образом, что товар проходит по «цепочке поставок» через несколько отделов.

Например, сначала проходит «оптовый отдел», далее попадает в «региональный распределительный центр», далее в «розничное торговое подразделение» (магазин).

Допустим:

  1. Все указанные подразделения входят в состав одной организации; имеют одного собственника.

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

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


Т.е сложность состоит в том, что по фату движения товара в программе оформлялись межскладские перемещения.

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



  • Пример «C»:

Компания закупает товар у иностранного поставщика. Для доставки и «растаможки» товара она пользуется услугами внешних контрагентов, которые оказывают фрахтовые и брокерские услуги.

Доставку товаров (с центрального распределительного склада в регионы) осуществляет внешний контрагент (транспортный агент).

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

В некоторых случаях, доставка товара осуществляется «за счет покупателя». В таких случаях услуги по доставке «перевыставляются» на самого покупателя.

Для целей УУ необходимо раскрыть (в отчете по анализу продаж товара) себестоимость товара:

  • Стоимость поставщика (сумма);

  • Доп. расходы фрахтовые (сумма);

  • Доп. расходы брокерские (сумма);

  • Доп. расходы транспортного агента (сумма);

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

  • Во первых, доп. расходы могут возникать в разные моменты, а не только при поступлении товара.

И если использовать типовой документ «Поступление доп. расходов», то не ясно «какую партию» (приходный документ) выбирать, если например доп. расходы возникают «при перемещение товара со склада на склад».

  • Во вторых, необходимо «раскрыть» себестоимость проданного товара.

Например, отчет «Валовая прибыль» удобно использовать для анализа продаж, однако этот отчет показывает с/с товара, в которую уже входят все «нулевые затраты». А требуется раскрыть эту с/с по составляющим.

  • В третьих, если мы отказываемся вести партионный учет (выбираем в УПП вариант расширенной аналитики учета затрат, далее РАУЗ) то совсем не очевидно «как разделить доп. расходы» между проданным и оставшимся товарам.

К тому же замечу, что в режиме работы с РАУЗ, документ «Поступление доп. расходов» все равно требует от пользователя указать ему документ прихода.

  • В четвертых, распространенная трудность - распределение доп. расходов по поставке товара.

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

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


  • Пример « D»:

Компания регулярно пользуется услугами сервисных компаний. C некоторыми компаниями (контрагентами) оплата осуществляется после оказания услуг (предоставления актов выполненных работ).

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

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

Но в соответствии с установленной учетной политикой (предположим такое) в УУ доходы и расходы нужно определять не в момент начисления, а по оплате. И следовательно, в УУ авансовый платеж нужно рассматривать как расход.

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

Итого:

На основе приведенных примеров (а это примеры из практики) очевидно, что оценка доходов и расходов; учет и перераспределение расходов – все это не простые задачи. Собственно говоря, решение подобных задач – это и есть наиболее частные задачи реализации УУ.

4. Примеры реальных проектов по УУ. Примеры их решения в УПП.

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

Здесь же я обозначу возможные пути их решения ; раскрою собственное понимание «как это лучше сделать».

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



  • МВЗ (место возникновения затрат) – элементы справочника «Подразделения»
  • Проекты – элементы справочника проекты.
  • Каскадное перераспределение затрат (с подразделения на подразделения) можно обеспечить, используя документ «Отчет производства за смену» (далее ОПЗС).

    Таким способом, ОПЗС будет фиксировать исходящие затраты «от одного подразделения на другое».

    В ОПЗС это можно искусственно сделать через выпуск «внутрифирменных услуг»

    В этом случае направление выпуска будет – «в затраты». Удобно использовать направление «список» ; т.е распределять затрату на несколько подразделений, указывая при этом базу распределения.

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

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

    б) Проекты используются для контроля (над возможным превышением) текущих затрат по указанной статье бюджета и его плановой сумме.
____________________
___________________________________________________
Необходимо обеспечить
распределение затрат IT-отдела (зарплата сотрудников и пр.) на обслуживание программ и компьютерной техники других отделов компании (отдела продаж и отдела закупок).


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

Для каждого подразделения рассчитывается величина
(сумма), равная Колво_Документов*Плановая_Цена_Ед;
Пропорционально этим суммам должны распределяться затраты.

  • Для ежемесячной установки долей распределения можно использовать типовой документ «Установка базы распределения затрат».

    При этом нужно доработать УПП: обеcпечить автоматических расчет и заполнение документа (по данным о фактическом количестве оформленных документов и плановых ценах за единицу).
____________________
___________________________________________________
Необходимо создать отчет
для сравнения затрат по
бухгалтерскому и управленческому
учету.

  • Сопоставление затрат можно выполнять по статьям, при условии что перечень этих статей (справочник «Статьи затрат» и справочник «Прочие доходы и расходы») общий для бухгалтерского учета и УУ.
_______________________________
________________________________________________
Необходимо упростить работу
«по контролю» за входящими
и исходящими затратами
(центрами затрат).
«Ответственный» должен
иметь возможность «видеть»
(в виде отчета) все входящие/
исходящие затраты относительно своего центра.

  • Данный отчет можно реализовать в виде “шахматной ведомости», показывая входящие затраты (по подразделениям и статьям) и исходящие, т.е корреспондирующие затраты (по подразделениям и статьям).
_______________________________
________________________________________________
Необходимо обеспечить в УУ
учет основных средств и
начисление амортизации.
В УПП необходимо учитывать следующее:

a) Первоначальная стоимость
основного средства в УУ и
регл. учете могут отличаться.

b) В управленческом учете
амортизация начисляется только линейным способом.

c) В УУ амортизация
должна продолжать начисляться
и после окончания срока
полезного использования
(пока основное средство
«не числится списанным»)

  • Для целей УУ можно доработать типовой механизм учета о/с в упр. учете УПП.
_______________________________
___________________________________________________
Для целей УУ необходимо
обеспечить установку аналитик
учета затрат (центр затрат,
проект, статья) так,
что бы по факту возникновения
затраты была возможность автоматически отнести (в программе) затраты на эти аналитики.

  • Ввод центров затрат, проектов, долей распределения, статей удобно предусмотреть в документе «Заявка на расходование д/с».

    Т.е «тот кто инициирует заявку» - сразу и отвечает за правильную аналитику учета.
_______________________________
________________________________________________
Для целей УУ необходимо
относить к расходам, связанным
с продажей товаров клиентам
(«нулевым расходам») следующие расходы:


(1) Доставке товаров
на склады компании;
(038 группа (увеличивает с/с);

(2) Внутрифирменное
межскладское перемещение
со склада (Москва) в филиалы ;
(026) группа (увеличивают с/с);


(3) Доставке товаров клиенту
со складов компании;

(014 группа; относится
на выручку и увеличивают
выручку

(перевыставляются клиентам);


(4) Списание рекламных
Материалов
(их передают клиентам);
(041) группа;
увеличивают с/с;


(5) Продаже покупателю
на сумму бонуса (скидки);
(013) группа;

уменьшают выручку

  • Пути решения зависят от выбора методики расчета с/с (т.е выбор варианта: РАУЗ или партионный учет).
    В случае с партионным учетом проще обеспечить соотнесение расходов и проданного товара (по партии).
  • Вариант РАУЗ имеет много своих преимуществ (перед партионным учетом). Однако весьма неочевидно «каким образом соотнести нулевые расходы на проданный товар и на остальной товар».
_______________________________
___________________________________________________
В учетной политике компании (по УУ)
суммы реализации товаров учитываются
без выделения НДС (то есть в т.ч. НДС).

Учет НДС и расчет сумм НДС
(к уплате в бюджет) осуществляется в 1С:Бухгалтерии.

УУ ведется в УПП.
В отчете о доходах и расходах
нужно отражать расходы на уплату НДС.

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



  • Затраты по уплате налогов можно фиксировать в УПП, например, по МВЗ «Уплата налогов», по статье «НДС к уплате».

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

    Т.е, предварительно нужно создать в базе вид распределения:
    • Название - «Распределение НДС»
    • Способ распределения - «При проведении документов».


Далее, необходимо автоматизировать расчет базы перераспределение затрат.

Для фиксирования в программе базы будем использовать документ «Распределение по проектам».


  • Расчет базы и распределение затрат можно реализовать и непосредственно при формировании отчета по доходам и расходам. Однако, это не лучший вариант по производительности. И еще, результаты распределения не будут зафиксированы в учете.
_______________________________
___________________________________________________
Необходимо обеспечить возможность
оперативного анализа (обороты и остатки) «денежного потока» по подразделениям.


Учет доходов по внутрифирменным
кредитам:
  • Необходимо распределить сумму (процент, начисленный за использование кредита) между подразделениями, по которым (за указанный период) был перерасход денежного потока;

  • База распределения должна учитывать суммы перерасхода денежного потока и количество дней перерасхода;
Учет денежного потока в УПП можно вести на регистре «Движения денежных средств».

Движение денежных средств можно вести в разрезе проектов. Как вариант, можно завести виртуальные «проекты», соответствующие подразделениям из справочника подразделения.

Таким (искусственным) способом можно добиться разделения денежных потоков.

Если нужно распределить один платежный документ (движение денежных средств) по нескольким подразделениям, то можно использовать «виды распределения по проектам».


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

Для распределения затрат (начисленных за использование кредита) можно использовать «виды распределения по проектам».



На этом, все.

.$.
Открыть

    © 2011 Горский Михаил.