Отчёты как источник функциональных требований и проектных решений
Сегодня я расскажу о том, как правильно работать с отчётами и о том, какой это замечательный источник функциональных требований (и даже проектных решений) при разработке информационных систем.
Попутно рассмотрим типовые ошибки при проектировании отчётов, причины их появления и инструменты предотвращения.
Для начала определимся, что такое отчёт и каково его основное предназначение.
Отчёт — структурированное отображение информации, формируемое на основе данных, хранящихся в информационной системе (ИС), и предоставляемое по запросу пользователя системы.
Основное предназначение отчёта (как и учётных ИС в целом) — предоставлять информацию, на основе которой люди могли бы принимать управленческие решения.
При создании отчёта этапы проектирования и разработки последовательно сменяют друг друга.
На этапе проектирования отчёта системный аналитик:
- Определяет по техническому заданию (ТЗ) показатели, которые должны выводиться в отчёт
- Создаёт прототип для формы вывода отчёта и согласовывает его с заинтересованными лицами
- Описывает последовательность и формулы для расчёта показателей в отчёте
- Связывает показатели, выводимые в отчёт, с атрибутами модели данных
- Оформляет постановку на реализацию отчёта
На этапе реализации отчёта разработчик:
- Берёт постановку на реализацию отчёта в работу
- Верстает форму для вывода отчёта на экран (или печатную форму отчёта)
- Создаёт SQL-запросы для выборки нужных данных из базы данных (БД)
- Реализует расчётные процедуры с полученными данными
- Выводит полученные результаты в форму вывода
- И наступает всеобщее счастье! Даже скучно…
Казалось бы, если работа аналитика и разработчика чётко регламентирована инженерией требований, что может пойти не так?
Да что угодно, в чём я имел возможность лично убедиться, потому что…
Из предисловия к первому изданию книги
Четыре типа проблемных ситуаций с отчётами
Как-то раз меня пригласили в качестве аналитика на этап технического проектирования очень большого проекта. Это был проект автоматизации учёта и отслеживания движения транспортных средств (ТС) одного из крупнейших регионов России.
Мне пришлось написать более двухсот постановок на отчёты, но оказалось, что примерно в 20% случаев из 100 невозможно получить из системы данные для отчёта, основываясь на том, как она спроектирована и реализуется.
Проанализировав и сгруппировав все проблемные ситуации, я выделил 4 типа ошибок в отчётах:
1. Данные для получения отчётов в системе в принципе не предусмотрены
2. Данные присутствуют, но нет ясности, эти ли данные нужны для формирования отчёта, и не понятно как это проверить
3. Данные есть, но их так много, что попытка провести выборку и расчёт для получения отчёта приводит к многочасовым расчётам или зависанию системы
4. Данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным
Поговорим о том, почему это случается и как это предотвратить.
Ситуация 1: в системе не предусмотрено хранение нужных нам данных
Причины, по которым возникла ситуация:
В ТЗ не были указаны требования к автоматизации процессов по внесению исходных данных, на основании которых формируется отчётность, то есть была нарушена методология разработки ТЗ.
Последствия для проекта:
Дополнительные денежные и временные затраты на доработку ИС, чтобы нужные для отчета данные все-таки поступали в систему.
Кто виноват:
Тот, кто разрабатывал ТЗ, если он недостаточно квалифицирован, и/или тот, кто дал команду нарушить методологию разработки ТЗ. Как правило, нарушение методологии встречается часто на таких проектах, где ТЗ служит основанием для участия в конкурсе. Из экономии времени отчётами пренебрегают как тем, что всегда можно получить из системы и согласовать с заказчиком позже.
Как это предотвратить:
Соблюдать методологию разработки ТЗ и использовать отчёты, которые нужны пользователям, как источник требований к проектированию ИС.
“
Когда вы разрабатываете ТЗ как аналитик, ни в коем случае не поддавайтесь на уговоры (за исключением письменного приказа!), когда руководитель проекта, начальство, заказчик предлагают или требуют отложить отчёты на потом, когда система уже будет разработана.
Помните, ответственность на проекте за формирование ТЗ и полноту требований несёт аналитик, и в конечном счёте виноваты будете именно вы!
Системный анализ и Разработка требований в ИТ-проектах
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Отчёты как источник требований
Чтобы отчёты стали тем замечательным источником выявления функциональных требований (ФТ) к системе, о котором я говорил, работа с ними должна начинаться как можно раньше.
Этап обследования организации
На этапе сбора бизнес- и пользовательских требований у заинтересованных лиц необходимо выяснить:
- Какие формы отчётности существуют в компании сейчас
- Кто их формирует и на основании каких данных
- Кто является потребителем отчётов
- Какие отчёты могут понадобиться в будущем (их возможное содержание и структура)
Обязательно собрать все образцы используемых на данный момент отчётов, желательно, заполненные реальными данными. Эти данные пригодятся позднее в качестве тестовых примеров, когда будете проверять, правильно ли формируются отчёты.
Собрать имеющуюся нормативную документацию по работе с отчётами. Если вы работаете с госструктурами различных уровней, отчёты в таких системах зачастую формируются для передачи на уровень выше. При этом часть отчётов содержится в нормативной документации и, как правило, там прописана не только структура отчётов, но и вся информация о последовательности расчётов в них.
Этап формирования концепции ИС
- Определить, какие отчёты будут реализованы в ИС и согласовать их с заказчиком как концепцию
- Проверить, что среди пользователей ИС есть потребители этих отчётов
- Проверить, что есть поставщики данных в ИС для проектирования реализуемых отчётов
- Проверить, что процессы поставки данных подлежат включению в состав ИС
Самый лучший инструмент для проверки полноты данных, о котором мы говорим на курсах в школе systems. education, это контекстная диаграмма.
Допустим, у нас есть система мониторинга использования автотранспорта и есть выделенные на этапе начального формирования концепции пользователи системы, которые могут быть как людьми, так и другими ИС.
Рассмотрим для примера отчёт об опозданиях на маршрутах.
Контекстная диаграмма с данными для отчёта об опозданиях на маршрутах (синий квадрат)
Потребителем этого отчёта является пользователь с ролью «Диспетчер».
Для формирования отчёта понадобятся данные о водителях, об автобусах, о маршруте и данные о назначениях на маршрут транспортных средств (ТС). Кроме того, понадобятся данные устройств телематики, которые определяют время прохождения ТС контрольных точек. Представляя структуру отчёта, которая была собрана на этапе предпроектного обследования, мы понимаем, что отчёт сформируется, так как все нужные для него данные у нас в системе есть.
Рассмотрим ещё один пример. Пользователь «Менеджер по автотранспорту» по условиям ТЗ должен иметь возможность получать отчёт о рентабельности маршрутов.
Контекстная диаграмма с данными для отчёта о рентабельности маршрутов (зелёный квадрат)
Посмотрим, какие данные для этого нужны. У нас есть назначенные маршруты, есть данные о водителях и автобусах, поступающие из системы учёта кадров и системы учёта автотранспорта, и данные о платежах, которые поступают из системы платежей. Все эти данные в нашу систему поступают, а значит проблем с формированием отчёта не возникнет.
И рассмотрим третий пример. Тому же менеджеру по автотранспорту, чтобы принимать управленческие решения (например, сколько докупить автобусов), необходимо получать отчёт о простоях и ремонтах автотранспорта.
Контекстная диаграмма с данными для отчёта о простоях и ремонтах ТС (красный квадрат)
Для отчёта необходимы данные о ТС (они есть), но также нужны данные о ТС, которые находятся в ремонте, а эту информацию в систему никто не поставляет! Процесса поставки данных нет: его забыли указать при формировании ТЗ.
Если присмотреться внимательно, то эти же данные нужны нам и для формирования других отчётов, потому что, чтобы ТС можно было назначить на маршрут, оно не должно находиться в ремонте. Этого не обнаружили, когда формировались функции системы, которые отвечают за поставку, потому что в реальности работы данного АТП это всё было отражено административно: диспетчеру «на бумажке» подавались сведения о том, что такие-то автобусы находятся в ремонте и их нельзя ставить на маршруты, и он их просто не выбирал.
Соответственно, мы не только не получили такие отчёты, мы упустили целый набор либо технических интерфейсов обмена данными с другими системами, где они будут храниться, либо интерфейсов взаимодействия с пользователями, чтобы эти данные поступали.
Если бы мы на данном этапе построили контекстную диаграмму для системы, то сразу же выяснили, что для механика необходим графический интерфейс, который бы подавал данные о ТС на ремонте, и система автоматически не давала бы диспетчеру их назначить на маршрут. Кроме того, данные о ремонте сохранялись бы в системе, использовались при формировании отчета и помогали принимать текущие управленческие решения. Но, так как это процесс поставки данных был упущен, ситуация обнаружилась, только когда писалась постановка на отчёт, что привело к задержке выпуска системы.
Этап разработки технического задания
На этапе разработки ТЗ нам нужно сформировать функциональные и нефункциональные требования (НФТ) к отчётам.
ФТ формируются в виде классических атомарных ФТ, либо в виде юскейсов функционального уровня.
“
Например, система должна позволять пользователю с ролью «Кассир», «Администратор кассы» просматривать отчёт «Кассовый отчёт» с набором полей:
- Дата рабочего дня
- Номер рабочей смены
- Дата открытия рабочей смены
- Дата закрытия рабочей смены
- …
В НФТ мы формируем требования к качеству или доступности формирования отчёта (скорость формирования отчёта, количество одновременно работающих с отчётами пользователей и т. п.)
Например, скорость формирования отчётов не должна превышать 1 секунду в 80% случаев.
Ситуация 2: данные присутствуют, но нет ясности, те ли это данные и как это проверить
Причины, по которым возникла ситуация:
- В ТЗ отсутствует или плохо описана концептуальная модель данных (КМД)
- Модель предметной области плохо задокументирована
Последствия для проекта:
Дополнительные временные затраты аналитика и привлекаемых экспертов на доработку и/или документирование КМД.
Кто виноват:
Тот, кто разрабатывал и описывал концептуальную модель данных для проекта.
Как предотвратить:
- Всегда разрабатывать КМД как составную часть ТЗ
- Тщательно документировать КМД
В моем проекте для части отчётов было невозможно сформировать постановки на разработку отчетов, потому что я не понимал, какие данные из модели нужно брать, чтобы эти отчёты формировались. При этом концептуальная модель данных была зафиксирована в виде модели в Enterprise Architect (EA), но в ней были описаны только классы и атрибуты, а их значения — не были. Даже эксперты в предметной области не могли мне объяснить, что это значит, исходя только из названий в модели.
Как правильно документировать данные
Давайте сравним описание данных, каким оно было оставлено моим предшественником (слева) и каким его предлагаю делать я (справа).
Пример описания сущности с пояснениями
Попробуйте понять без пояснения, что «Время: int» это «Время движения от предыдущего Объекта движения. Плановый показатель». И даже эксперт предметной области в этом не поможет: это служебный (технический) атрибут, предназначенный для работы системы, и он появился только в момент автоматизации.
Я призываю вас подробно комментировать не только назначение сущностей в модели данных, но и все выявленные атрибуты. Любите себя и тех, для кого вы разрабатываете модель требований, частью которой является модель данных. Время, потраченное на документирование предметной области, позволит существенно сэкономить время и вам, и другим потребителям вашей документации.
Ситуация 3: данных так много, что технических возможностей системы не хватает для их обработки
Мне было необходимо построить ряд отчётов о завершенности рейсов.
Рейс считался завершённым, если более 80% остановок были пройдены вовремя. Все данные хранились в системе телематики. Данные в систему телематики (с устройств, установленных на автобусе) собирались раз в несколько секунд или даже в секунду, то есть система телематики хранила огромные объемы данных.
Отчёты о завершённости маршрутов, как правило, строили помесячно, поквартально и ежегодно.
Чтобы построить отчёт о завершённости маршрута, нужно было выполнить ряд последовательных шагов:
- Сравнить данные координат остановки
- Сравнить, был ли на данном устройстве в тот день назначенный на рейс автобус
- собрать это по данным всего предприятия, в котором несколько сотен ТС, за определённый период.
Спроектированная архитектором система обращалась напрямую к БД хранения телематических данных, при обработке этих данных зависала как сама БД, так и система построения отчётов, и в итоге всё падало.
Причины, по которым возникла ситуация:
- Особенность технической реализации информационной системы
- Неправильная оценка объема обрабатываемых данных
Последствия для проекта:
дополнительные временные затраты на разработку технического решения и возможное увеличение стоимости технической составляющей системы.
Кто виноват:
Архитектор
Как предотвратить:
Необходимы правильные проектные решения со стороны архитектора на этапе эскизного проекта.
Что может предложить системный аналитик
Когда нет возможности без сдвига сроков сдачи проекта применить технические средства, приходится решать проблему аналитическим способом: путем изменения логики работы.
Рассмотрим часть модели, в которую были внесены изменения для построения отчета о завершенности маршрута транспортного средства.
Пример проектного решения для упрощения получения отчёта на больших данных
Итак, мы внесли изменения в логику работы системы. Теперь расчет того, успешен ли рейс, производился сразу после завершения рейса, а не в момент формирования отчёта. Признак успешного завершения мы хранили в базе данных. Для кого-то такое решение может показаться спорным и не очень изящным, но именно оно было применено в нашем случае, и проблемы с построением отчетов из-за недостаточной мощности были решены.
Нам не пришлось тратить деньги на сложные программные продукты, которые бы могли это решить, а также время на то, чтобы их разработать и внедрить. Мы обошлись теми техническими возможностями хранения и обработки данных, которые на тот момент были.
И хотя эта ситуация довольно нетипична для работы аналитика, если вы когда-нибудь столкнетесь с подобной проблемой в отчётах, обрабатывающих большой объём данных, знание о возможности хранения промежуточных данных может вам пригодиться.
Ситуация 4: данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным
Это самая простая ситуация, которая случается буквально у всех аналитиков, которые работают с отчётами.
Причины, по которым возникла ситуация:
Ошибки при разработке постановок на реализацию отчёта и/или ошибки при реализации отчёта в коде.
Кто виноват:
Тот, кто разрабатывал и/или реализовывал отчёт.
Последствия для проекта:
Дополнительные затраты на доработку и/или реализацию отчёта в ИС. Если такие отчёты попали в релиз, это вызывает недовольство пользователей и заказчика.
Как предотвратить:
Предоставьте тестировщикам для проверки правильности результатов отчёта реальные тестовые примеры, согласованные с экспертами.
Системный анализ и Разработка требований в ИТ-проектах
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Мы поговорили о том, какие ошибки при проектировании отчётов могут встречаться на проектах, а также обсудили, как аналитик может позаботиться о предотвращении этих ошибок. Давайте кратко резюмируем основные мысли статьи:
- Отчёты — замечательный источник требований к проектируемой ИС, и чем раньше вы начнете с ним работать (в идеале — на этапе предварительного обследования и концепции), тем больше вероятности избежать дорогостоящих ошибок. Кроме того, отчеты — важнейший инструмент принятия решений для бизнеса заказчика.
- Документируйте аналитические артефакты как можно более полно. Делайте это и на этапе предварительного обследования, и на этапе формирования концепции ИС, и тем более на этапе разработки ТЗ. Максимально подробное документирование — залог того, что при разработке и сопровождении ИС будет меньше проблем с построением отчетов.
- Проверка отчётов на реальных тестовых примерах — залог хороших отношений с заказчиком и участниками команды разработки.
- Соблюдайте методологию разработки ИС — и будет вам счастье!
Error get alias
Как классифицируют управленческие отчеты компании?
Как обеспечить прозрачность и взаимосвязь данных разных групп управленческих отчетов?
Как определить, какие именно операционные управленческие отчеты нужны в конкретной компании?
Какие показатели должны содержать основные операционные управленческие отчеты производственной компании?
На основе данных управленческой отчетности принимаются оперативные решения по текущим операционным вопросам, поэтому в управленческие отчеты включают не только количественные и финансовые показатели, но и производственные, ценовые, маркетинговые, эффективности и т. д.
Рассмотрим основные формы управленческой отчетности, на базе которых любое предприятие может создать собственные формы отчетов, учитывая специфику своей деятельности.
Как классифицируются и какие данные содержат управленческие отчеты
Деятельность предприятия состоит из различных бизнес-процессов (основных, сопутствующих, обеспечивающих, процессов управления и развития), и для эффективного управления этой деятельностью руководству и менеджменту компании необходима актуальная информация о функционировании каждого из этих процессов. Система управленческой отчетности содержит в себе большое количество разноплановых отчетов, которые можно классифицировать на следующие основные группы:
Исходя из рассмотренной нами классификации управленческой отчетности коммерческих предприятий мы можем сделать вывод о том, что основная группа — периодические отчеты. Они нужны широкому кругу пользователей и используются чаще по сравнению с другими группами отчетов.
Как взаимосвязаны данные управленческих отчетов
В свою очередь все периодические отчеты можно разделить на несколько групп:
• операционные отчеты о деятельности компании;
• сводные финансовые отчеты компании;
• отчеты о финансировании деятельности компании.
Показатели этих групп отчетов взаимосвязаны (см. табл. 1).
Из табл. 1 ясно видно, данные каких операционных отчетов и отчетов о финансировании деятельности компании должны соответствовать данным сводных финансовых отчетов — Отчета о прибылях и убытках (ОПиУ), Отчета о движении денежных средств (ОДДС) и управленческого баланса.
Сводные финансовые отчеты и отчеты о финансировании деятельности компании, безусловно, являются основными управленческими отчетами. Но, во-первых, их формы достаточно типичны и во многом аналогичны соответствующим финансовым отчетам, а во-вторых, они формируются не чаще чем раз в месяц и не используются для текущего управления бизнесом.
Поэтому далее я предлагаю рассмотреть вопрос о том, как определить наиболее приоритетные и востребованные из операционных управленческих отчетов, на основе данных которых и осуществляется принятие текущих управленческих решений по различным аспектам деятельности компании.
Как определить, какие именно основные операционные отчеты нужны компании
Востребованность тех или иных операционных отчетов зависит от специфики бизнеса каждой конкретной компании. И чтобы понять, какие из отчетов являются основными для конкретной компании, составим аналитическую таблицу, в которой по строкам расположены виды отчетов, а по столбцам указаны группы пользователей этой отчетности (табл. 2).
В таблице группы пользователей обозначены так:
СБ — собственники бизнеса;
РК — руководство компании;
ТМ — топ-менеджеры;
РП — руководители подразделений.
В ячейках на пересечении строк и столбцов указана периодичность востребованности отчетов у разных групп пользователей:
• Д — день;
• Н — неделя;
• М — месяц.
Если проанализировать полученные нами данные табл. 2, то можно сделать вывод о том, что для конкретной компании основными операционными управленческими отчетами являются:
• Отчет о продажах;
• Отчет о возвратах продукции;
• Отчет по производству продукции;
• Отчет о запасах ТМЦ;
• Отчет об операционных затратах;
Как отразить в отчетности финансовую структуру компании
Чтобы управленческая отчетность была эффективной, важно, чтобы группировка ее показателей соответствовала финансовой структуре бизнеса компании.
Возьмем, к примеру, производственную компанию «Онега», которая выпускает продукцию трех направлений: напитки, мясопродукты и кондитерские изделия.
Кроме этого, у компании есть сеть розничных магазинов, в которых помимо собственной продукции реализуются покупные товары других производителей.
В управленческом учете эти четыре направления выделены в обособленные учетные центры, на которые разносятся данные о реализации продукции, себестоимости ее реализации, а также о логистических и коммерческих расходах.
Данные об управленческих расходах, а также о прочих доходах и расходах учитываются в целом по компании. Структура показателей Отчета о прибылях и убытках компании «Онега» представлена в табл. 3.
Как формировать основные управленческие отчеты
Рассмотрим примеры формирования основных управленческих отчетов компании. Самым востребованным управленческим отчетом является отчет о реализации продукции. С него и начнем.
Отчет о реализации продукции
В коммерческой службе используются различные оперативные и аналитические отчеты по продажам. На основе данных этих отчетов принимаются оперативные управленческие решения.
Для периодического отчета о продажах не нужна значительная детализация данных. В этот отчет достаточно вывести информацию:
• о реализации продукции в аналитике по направлениям продукции и группам покупателей;
• о себестоимости реализованной продукции;
• о валовом доходе от реализации в аналогичной детализации.
Для большей информативности отчета можно включить в него еще показатели рентабельности продаж, чтобы пользователи могли сразу оценить выгодность реализации как по направлениям продукции, так и по группам покупателей компании.
Примерная форма отчета о продажах предприятия «Онега» показана в табл. 4.
Отчет о возвратах продукции покупателями
Для производственных предприятий с многономенклатурным выпуском продукции также важен отчет о возвратах продукции покупателями.
Для того чтобы эффективно управлять возвратами, недостаточно видеть данные по видам продукции и группам покупателей — важно получать информацию о причинах, по которым покупатели вернули продукцию. Поэтому в управленческом учете компании нужно предусмотреть аналитику по причинам возвратов, и тогда этот управленческий отчет можно будет формировать в следующем виде (табл. 5).
Отчет о выпуске продукции
Еще один основной управленческий отчет — отчет о выпуске продукции. Он содержит не только данные о количестве выпущенной продукции и сумме затрат на ее выпуск, но и детальную информацию о структуре себестоимости продукции.
Пример отчета о выпуске готовой продукции (ГП), в котором ее себестоимость раскладывается на три составные части — сырьевые затраты, прямые производственные и косвенные производственные затраты, приведен в табл. 6.
Обратите внимание!
В приведенной форме выпуск продукции детализируется не только по ее видам, но и по номенклатурным группам внутри каждого вида. Это сделано опять же для того, чтобы повысить эффективность предоставляемой управленческой информации и пользователи сразу могли оценить ресурсоемкость выпуска разной номенклатуры готовой продукции.
Отчет о запасах товарно-материальных ценностей
Управленческий отчет о запасах ТМЦ содержит информацию как о запасах компании на начало и конец отчетного периода, так и о поступлении и выбытии запасов в течении этого периода. А поскольку данные запасы в любой компании достаточно разноплановы, то и информация в отчете должна быть сгруппирована по видам ТМЦ.
Кроме этого, чтобы повысить эффективность управления запасами, не лишним будет включить в отчет величину неликвидной части ТМЦ, находящихся на складах компании.
Пример ежемесячного отчета о запасах ТМЦ показан в табл. 7.
Отчет об операционных расходах предприятия
Когда речь идет об основных управленческих отчетах, нельзя обойти вниманием отчет об операционных затратах предприятия, так как они значительно влияют на величину прибыли от хозяйственной деятельности компании. К тому же контроль операционных затрат — одна из важнейших задач финансовой службы любой компании.
Обратите внимание!
Показатели отчета об операционных затратах должны быть идентичны показателям сводного отчета о прибылях и убытках.
Поэтому в операционном отчете предусматриваем столбцы по трем направлениям затрат:
• логистические;
• коммерческие;
• управленческие.
А по строкам отчета выведем детальную информацию по группам и статьям затрат, чтобы пользователи отчета смогли сразу увидеть, по каким направлениям и на какие цели были израсходованы ресурсы компании за отчетный период.
В таблице 8 представлен пример управленческого отчета об операционных расходах в группировке по направлениям расходов и статьям затрат.
Резюме
• Все управленческие отчеты могут быть сгруппированы на оперативные, периодические и аналитические.
• Периодические управленческие отчеты классифицируются на операционные, сводные финансовые и отчеты о финансировании деятельности компании.
• Система управленческой отчетности любой компании должна быть настроена таким образом, чтобы показатели отчетов соответствовали финансовой структуре и обеспечивали возможность увидеть взаимосвязь между данными сводных и операционных управленческих отчетов;
• Для того чтобы понять, какие из управленческих операционных отчетов наиболее востребованы в компании, достаточно проанализировать перечень отчетности на предмет периодичности их представления и круга пользователей.
Материал публикуется частично. Полностью его можно прочитать в журнале «Справочник экономиста» № 1, 2022.
Этапы формирования и составления управленческой отчетности
- Диагностика существующей системы управления
- Создание методологии управленческой отчетности
- Проектирование и утверждение финансовой структуры компании
- Формирование бюджетной модели
- Утверждение бюджетной политики
- Аудит учетных систем
- Автоматизация
Важные аспекты при составлении управленческой отчетности: формы и примеры. Управленческая отчетность — это один из важнейших источников получения информации о результатах деятельности компании, на основе совокупности финансовых, сбытовых, маркетинговых, производственных и прочих показателей.
Информация в управленческой отчетности должна быть экономически интересна и активно использоваться руководителями, учредителями и собственниками бизнеса. Раскрытые в управленческой отчетности данные необходимы для анализа всей деятельности. Это помогает вовремя выявить причины возможных отклонений от параметров, которые заданы стратегией бизнеса, а также показать резервы (финансовые, материальные, трудовые, и пр.), которые до этого времени не использовались компанией.
Ниже представлены 7 этапов формирования и составления управленческой отчетности.
Шаг 1. Диагностика существующей системы управления в компании
Данный этап необходим для анализа организационной структуры компании, определяется формат моделирования процессов. При наличии у компании схем бизнес-процессов и их описания, проводится анализ данных документов, и выявляются основные проблемные зоны, требующие оптимизации.
| Цели диагностики | Поиск системных подходов к увеличению эффективности управленческой отчетности |
|---|---|
| Классификация и анализ существующих форм отчетности |
|
| Повышение качества и уменьшение сроков получения выходной аналитической информации, необходимой для принятия качественных управленческих решений. | Аналитические отчеты имеют высокую ценность тогда, когда могут быть получены в короткие сроки и содержат информацию в виде, который максимально отвечает потребностям сотрудника, который принимает решения на основе данного отчета. |
| Повышение достоверности хранимой информации. | Для принятия решений необходимо полагаться только на достоверную информацию. Не всегда можно понять, насколько информация, которая представлена в отчётах достоверна; соответственно повышается риск принятия некачественных решений. С другой стороны, если сотрудник не несет служебной ответственности за достоверность введенной информации, то с очень большой степенью вероятности он не будет относиться к информации с должной аккуратностью. |
| Повышение аналитической ценности информации. | Несистемный подход к вводу и хранению информации приводит к тому, что, несмотря на то, что в базу данных введено большие объемы информации, представить эту информацию в виде отчетов практически невозможно. Под не системностью здесь понимается ввод информации сотрудниками без разработки общих правил, что приводит к ситуации, когда по смыслу одинаковая информация представлена для разных сотрудников в отличном друг от друга виде. |
| Исключение противоречивости и рассогласованности информации | В случае нечеткой определенности в вопросе разделения между сотрудниками обязанностями и правами по вводу информации зачастую происходит многократный ввод одной и той же информации в разных подразделениях компании. В совокупности с несистемным подходом факт дублирования информации бывает даже невозможно определить. Подобное дублирование приводит к невозможности получить полный отчет в разрезе введенной информации. |
| Повышение предсказуемости получения определенного результата | Принятия решений практически всегда основано на оценке информации по прошедшим периодам. Но зачастую бывает, что нужная информация просто никогда не вводилась. В большинстве случаев недостающую информацию хранить не представляло бы никакой сложности, если бы кто-то заранее предположил то, что она когда-нибудь понадобится. |
| Результат | На основе диагностики и принятых решений дорабатываются должностные инструкции, производится реинжиниринг существующих бизнес процессов, исключаются формы отчетности, которые не несут информации для анализа данных, вводятся показатели KPI, адаптируются учетные систем для получения фактических данных, фиксируются состав и сроки представления управленческой отчетности. |
Шаг 2. Создание методологии управленческой отчетности
Данный этап необходим для делегирования полномочий в части составления операционных бюджетов и определения ответственности, конкретных центров финансовой ответственности (ЦФО) за составление тех или иных бюджетных планов (сегментов управленческой отчетности).
Рисунок 1. Последовательность этапов построения методологии управленческой отчетности.
Цели и задачи, решаемые в результате внедрения управленческой отчетности в компании:
- Установление и достижение конкретных ключевых показателей эффективности (KPI);
- Выявление «слабых» звеньев в организационной структуре компании;
- Повышение системы контроля результатов деятельности;
- Обеспечение прозрачности денежных потоков;
- Усиление платежной дисциплины;
- Разработка системы мотивации сотрудников;
- Оперативное реагирование на изменение: конъюнктуры рынка, каналов сбыта и т.д.;
- Выявление внутренних ресурсов компании;
- Оценка рисков и т.д.
Состав управленческих отчетов зависит в первую очередь от характера деятельности компании. Как показывает практика, состав управленческой отчетности (мастер-отчет) обычно включает в себя:
- Отчет о движении денежных средств (прямым методом);
- Отчет о движении денежных средств (косвенным методом);
- Отчет о прибылях и убытках;
- Прогнозный баланс (управленческий баланс);
Рисунок 2. Пример структуры управленческой отчетности.
Рисунок 3. Связь классификатора управленческих отчетов и объектов управленческого учета.
Консолидация бюджетов
Формирование консолидированной управленческой отчетности представляет собой довольно трудоемкий процесс. Консолидированная финансовая управленческая отчетность рассматривает группу взаимосвязанных организаций, как единое целое. Активы, обязательства, доходы и расходы объединяются в общую систему управленческих отчетов. Такая отчетность характеризует имущественное и финансовое положение всей группы компаний на отчетную дату, а также финансовые результаты ее деятельности за отчетный период. Если холдинг состоит из компаний, которые между собой никак не связаны на операционном уровне, то задача консолидации управленческой отчетности решается достаточно просто. Если же между компаниями холдинга осуществляются хозяйственные операции, то в этом случае не все так очевидно, ведь нужно будет исключить взаимные операции, чтобы на уровне холдинга в консолидированной отчетности не исказить данные о доходах и расходах, активах и обязательствах. В бюджетной политике компании необходимо закрепить правила и принципы элиминации ВГО.
Поэтому целесообразнее использовать информационные системы. Для этих целей можно применить систему «WA: Финансист». Система позволяет производить элиминирование внутрифирменных оборотов на уровне проведения первичных документов и быстро получать корректную информацию, что упрощает и ускоряет процесс формирования управленческой отчетности, минимизирует ошибки, связанные с человеческим фактором. При этом сверка внутригрупповых оборотов, их элиминация, выполнение корректирующих проводок и других операций осуществляются в автоматическом режиме.
Пример управленческой отчетности: Компания А владеет компанией Б на 100%. Компания А продала товар на сумму 1500 рублей. Покупка данного товара обошлась компании А в 1000 рублей. Компания Б оплату за поставленный товар произвела в полном объеме. На конец отчетного периода компания Б не продала товар и он числится у нее в составе отчетности.
В результате консолидации необходимо исключить прибыль (500 рублей), которую компания еще не получила и уменьшить стоимость запасов (500 рублей).
Чтобы исключить ВГО и прибыль, которую компания Б еще не заработала. Необходимо сделать корректировки.
Результат консолидации управленческой отчетности
Рисунок 4. Прогнозный баланс (управленческий баланс).
Определение ключевых показателей эффективности (KPI – Key performance indicators)
Введение ключевых контрольных показателей позволяет управлять центрами финансовой ответственности, устанавливая лимиты, нормативные значения или предельные границы принимаемых показателей. Набор показателей эффективности отдельных ЦФО существенно зависит от роли этого центра ответственности в системе управления и от выполняемых функций. Значения показателей устанавливаются с учетом стратегических планов компании, развития отдельных направлений бизнеса. Система показателей может принимать иерархическую структуру, как для компании в целом, так и с детализацией до каждого центра финансовой ответственности. После детализации KPI верхнего уровня и передачи их на уровни ЦФО и сотрудников к ним можно привязать вознаграждение персонала и т.д.
Рисунок 5. Пример использования ключевых показателей компании.
Контроль и анализ управленческой отчетности и исполнения
Для исполнения бюджетов, входящих в состав управленческой отчетности можно выделить три направления контроля:
- предварительный;
- текущий (оперативный);
- заключительный.
Цель предварительного контроля — это профилактика потенциальных нарушений бюджета, иначе говоря, предупреждение необоснованных расходов. Он проводится до совершения хозяйственных операций. Наиболее распространенная форма такого контроля — согласование заявок (например, на оплату или отгрузку товаров со склада).
Текущий контроль исполнения бюджета подразумевает регулярный мониторинг деятельности центров финансовой ответственности для выявления отклонений фактических показателей их деятельности от запланированных. Проводится ежедневно или еженедельно по оперативной отчетности.
Заключительный контроль исполнения бюджета — не что иное, как анализ выполнения планов после закрытия периода, оценка финансово-хозяйственной деятельности компании в целом и по объектам управленческого учета.
В процессе исполнения бюджетов важно выявлять отклонения на самых ранних этапах. Определить, какие методы предварительного и текущего контроля бюджета можно использовать в компании. Например, ввести процедуры согласования заявок на платеж или отпуск материалов со склада. Это позволит избежать неоправданных расходов, предупредить неисполнение бюджета и заранее принять меры. Обязательно регламентируйте процедуры контроля. Создайте отдельный регламент бюджетного контроля. Опишите в нем виды и этапы проверок, их периодичность, порядок пересмотра бюджетов, ключевые показатели и диапазоны их отклонений. Это сделает процесс контроля прозрачным и понятным, повысит исполнительскую дисциплину в компании.
Рисунок 6. Контроль исполнения плановых показателей управленческой отчетности.
Шаг 3. Проектирование и утверждение финансовой структуры компании
Этот этап включает в себя работы по формированию классификаторов бюджетов и бюджетных статей, разработке совокупности операционных бюджетов, статей планирования и их взаимосвязей между собой, наложению видов бюджетов на организационные звенья структуры управления компанией.
На основе организационной структуры компании разрабатывается финансовая структура. В рамках этой работы из организационных звеньев (подразделений) формируются центры финансовой ответственности (ЦФО) и строится модель финансовой структуры. Главная задача построения финансовой структуры предприятия — получить ответ на вопрос, кто и какие бюджеты на предприятии должен составлять. Правильно построенная финансовая структура предприятия позволяет увидеть «ключевые точки», в которых будет формироваться, учитываться и, скорее всего, перераспределяться прибыль, а также осуществляться контроль за расходами и доходами компании.
Центр финансовой ответственности (ЦФО) – объект финансовой структуры компании, который несет ответственность за все финансовые результаты: выручку, прибыль (убытки), затраты. Конечная цель любого ЦФО – максимизация прибыли. Для каждого ЦФО составляются все три основных бюджета: бюджет доходов и расходов, бюджет движения денежных средств и прогнозный баланс (управленческий баланс).Как правило, в качестве ЦФО выступают отдельные организации; дочерние фирмы холдингов; обособленные подразделения, представительства и филиалы крупных компаний; регионально или технологически обособленные виды деятельности (бизнесы) многопрофильных компаний.
Центр финансового учета (ЦФУ) – объект финансовой структуры компании, отвечающий только за некоторые финансовые показатели, например за доходы и часть затрат. Для ЦФУ составляются бюджет доходов и расходов или некоторые частные и функциональные бюджеты (бюджет трудовых затрат, бюджет продаж).В качестве ЦФУ могут выступать основные производственные цеха, участвующие в единых технологических цепочках на предприятиях с последовательным или непрерывным технологическим циклом; производственные (сборочные) цеха; сбытовые службы и подразделения. Центры финансового учета могут иметь узкую направленность:
- центр маржинальной прибыли (профит-центр) – структурное подразделение или группа подразделений, деятельность которых непосредственно связана с реализацией одного или нескольких бизнес-проектов фирмы, обеспечивающих получение и учет прибыли;
- центр доходов – структурное подразделение или группа подразделений, деятельность которых направлена на получение дохода и не предусматривает учет прибыли (например, служба сбыта);
- центр инвестиций (венчур-центр) – структурное подразделение или группа подразделений, которые непосредственно связаны с организацией новых бизнес — проектов, прибыль от которых ожидается в будущем.
- центр затрат – объект финансовой структуры предприятия, который отвечает только за расходы. Причем не за все расходы, а за так называемые регулируемые расходы, расходование и экономию которых руководство ЦЗ может контролировать. Это подразделения, обслуживающие основные бизнес-процессы. Для ЦЗ составляются лишь некоторые вспомогательные бюджеты. В качестве ЦЗ могут выступать вспомогательные службы предприятия (хозяйственный отдел, служба охраны, администрация). Центр затрат может также именоваться МВЗ (место возникновения затрат).
Рисунок 7. Проектирование финансовой структуры компании.
Шаг 4. Формирование бюджетной модели
Не существует каких-либо жестких требований по разработке классификатора внутренней управленческой отчетности. Так же как нет двух абсолютно одинаковых компаний, точно также нет одинаковых бюджетных структур. В отличие от формализованной финансовой отчетности: отчета о прибылях и убытках или бухгалтерского баланса, управленческая отчетность не имеет стандартизированной формы, которая должна строго соблюдаться. Структура внутренней управленческой отчетности зависит от специфики компании, принятой в компании бюджетной политики, пожеланий руководства по степени детализации статей для анализа и т.д. Можно лишь дать общие рекомендации, как составить оптимальную структуру управленческой отчетности.
Структура управленческой отчетности должна соответствовать структуре повседневной деятельности компании. Смотрите также «Классификация затрат в управленческом учете»
Рисунок 8. Схема взаимодействия бюджетных форм на примере простейшей бюджетной модели.
Классификация статей на примере Отчета о движении денежных средств
Рисунок 9. Исполнение бюджета движения денежных средств (CF (БДДС)).
Шаг 5. Утверждение бюджетной политики и разработка регламента
Бюджетная политика формируется с целью выработки и закрепления принципов формирования и консолидации показателей данных статей и методов их оценки. Сюда включаются: определение временного периода, процедуры планирования, форматы бюджетов, программа действий каждого из участников процесса. После разработки бюджетной модели, необходимо переходить к регламентации бюджетного процесса.
Нужно определить какие бюджеты, и в какой последовательности формируются в компании. Для каждого бюджета необходимо выделить ответственного за подготовку (конкретный сотрудник, ЦФО) и ответственного за исполнение бюджета (руководитель направления, руководитель ЦФО), установить лимиты, нормативные значения или предельные границы показателей эффективности ЦФО. Обязательно следует сформировать бюджетный комитет -это орган, создаваемый для целей управления бюджетным процессом, контроля его исполнения и приятия решений.
Далее остается переложить фазы планирования, выполнения и завершения на календарный план. Сформированный план — график будет являться регламентом бюджетирования предприятия.
Рисунок 10. Фазы планирования бюджетирования предприятия.
Шаг 6. Аудит учетных систем
На этапе разработки и утверждении состава управленческой отчетности компании также необходимо учесть, что классификатор бюджетных статей должен быть достаточно детализированным для обеспечения Вас полезной информацией о доходах и расходах компании. При этом нужно понимать, что чем больше уровней детализации будет выделено, тем больше времени и трудозатрат потребуется для составления управленческой отчетности, бюджетов и отчетов, но тем более подробную аналитику можно получить.
Также необходимо учесть, что в результате разработки методологии управленческой отчетности может потребоваться и адаптация учетных систем, т.к. для анализа исполнения бюджетов плановые показатели должны будут сопоставляться с имеющейся фактической информацией.
Шаг 7. Автоматизация
Этот этап включает в себя работы по выбору программного продукта, создание технического задания, внедрение и сопровождение системы.
Дата последнего обновления: 25.08.2016 16:07
Смотрите также «Обязанности финансового менеджера»