Сегодня я расскажу о том, как правильно работать с отчётами и о том, какой это замечательный источник функциональных требований (и даже проектных решений) при разработке информационных систем.
Попутно рассмотрим типовые ошибки при проектировании отчётов, причины их появления и инструменты предотвращения.
Для начала определимся, что такое отчёт и каково его основное предназначение.
Отчёт — структурированное отображение информации, формируемое на основе данных, хранящихся в информационной системе (ИС), и предоставляемое по запросу пользователя системы.
Основное предназначение отчёта (как и учётных ИС в целом) — предоставлять информацию, на основе которой люди могли бы принимать управленческие решения.
Как создается отчёт
При создании отчёта этапы проектирования и разработки последовательно сменяют друг друга.
На этапе проектирования отчёта системный аналитик:
- Определяет по техническому заданию (ТЗ) показатели, которые должны выводиться в отчёт
- Создаёт прототип для формы вывода отчёта и согласовывает его с заинтересованными лицами
- Описывает последовательность и формулы для расчёта показателей в отчёте
- Связывает показатели, выводимые в отчёт, с атрибутами модели данных
- Оформляет постановку на реализацию отчёта
- Берёт постановку на реализацию отчёта в работу
- Верстает форму для вывода отчёта на экран (или печатную форму отчёта)
- Создаёт SQL-запросы для выборки нужных данных из базы данных (БД)
- Реализует расчётные процедуры с полученными данными
- Выводит полученные результаты в форму вывода
- И наступает всеобщее счастье! Даже скучно…
Казалось бы, если работа аналитика и разработчика чётко регламентирована инженерией требований, что может пойти не так?
Да что угодно, в чём я имел возможность лично убедиться, потому что…
Из предисловия к первому изданию книги
Четыре типа проблемных ситуаций с отчётами
Как-то раз меня пригласили в качестве аналитика на этап технического проектирования очень большого проекта. Это был проект автоматизации учёта и отслеживания движения транспортных средств (ТС) одного из крупнейших регионов России.
Мне пришлось написать более двухсот постановок на отчёты, но оказалось, что примерно в 20% случаев из 100 невозможно получить из системы данные для отчёта, основываясь на том, как она спроектирована и реализуется.
Проанализировав и сгруппировав все проблемные ситуации, я выделил 4 типа ошибок в отчётах:
1. Данные для получения отчётов в системе в принципе не предусмотрены
2. Данные присутствуют, но нет ясности, эти ли данные нужны для формирования отчёта, и не понятно как это проверить
3. Данные есть, но их так много, что попытка провести выборку и расчёт для получения отчёта приводит к многочасовым расчётам или зависанию системы
4. Данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным
Поговорим о том, почему это случается и как это предотвратить.
Подписаться на рассылку
Подпишитесь на рассылку, чтобы получать от нас полезные материалы и оставаться на связи
«Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности»
Ситуация 1: в системе не предусмотрено хранение нужных нам данных
Причины, по которым возникла ситуация:
В ТЗ не были указаны требования к автоматизации процессов по внесению исходных данных, на основании которых формируется отчётность, то есть была нарушена методология разработки ТЗ.
Последствия для проекта:
Дополнительные денежные и временные затраты на доработку ИС, чтобы нужные для отчета данные все-таки поступали в систему.
Кто виноват:
Тот, кто разрабатывал ТЗ, если он недостаточно квалифицирован, и/или тот, кто дал команду нарушить методологию разработки ТЗ. Как правило, нарушение методологии встречается часто на таких проектах, где ТЗ служит основанием для участия в конкурсе. Из экономии времени отчётами пренебрегают как тем, что всегда можно получить из системы и согласовать с заказчиком позже.
Как это предотвратить:
Соблюдать методологию разработки ТЗ и использовать отчёты, которые нужны пользователям, как источник требований к проектированию ИС.
Когда вы разрабатываете ТЗ как аналитик, ни в коем случае не поддавайтесь на уговоры (за исключением письменного приказа!), когда руководитель проекта, начальство, заказчик предлагают или требуют отложить отчёты на потом, когда система уже будет разработана.
Помните, ответственность на проекте за формирование ТЗ и полноту требований несёт аналитик, и в конечном счёте виноваты будете именно вы!
Системный анализ и Разработка требований в ИТ-проектах
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Отчёты как источник требований
Чтобы отчёты стали тем замечательным источником выявления функциональных требований (ФТ) к системе, о котором я говорил, работа с ними должна начинаться как можно раньше.
Этап обследования организации
На этапе сбора бизнес- и пользовательских требований у заинтересованных лиц необходимо выяснить:
Собрать имеющуюся нормативную документацию по работе с отчётами. Если вы работаете с госструктурами различных уровней, отчёты в таких системах зачастую формируются для передачи на уровень выше. При этом часть отчётов содержится в нормативной документации и, как правило, там прописана не только структура отчётов, но и вся информация о последовательности расчётов в них.
Этап формирования концепции ИС
На этом этапе нужно:
- Определить, какие отчёты будут реализованы в ИС и согласовать их с заказчиком как концепцию
- Проверить, что среди пользователей ИС есть потребители этих отчётов
- Проверить, что есть поставщики данных в ИС для проектирования реализуемых отчётов
- Проверить, что процессы поставки данных подлежат включению в состав ИС
Допустим, у нас есть система мониторинга использования автотранспорта и есть выделенные на этапе начального формирования концепции пользователи системы, которые могут быть как людьми, так и другими ИС.
Рассмотрим для примера отчёт об опозданиях на маршрутах.
Контекстная диаграмма с данными для отчёта об опозданиях на маршрутах (синий квадрат)
Потребителем этого отчёта является пользователь с ролью «Диспетчер».
Для формирования отчёта понадобятся данные о водителях, об автобусах, о маршруте и данные о назначениях на маршрут транспортных средств (ТС). Кроме того, понадобятся данные устройств телематики, которые определяют время прохождения ТС контрольных точек. Представляя структуру отчёта, которая была собрана на этапе предпроектного обследования, мы понимаем, что отчёт сформируется, так как все нужные для него данные у нас в системе есть.
Рассмотрим ещё один пример. Пользователь «Менеджер по автотранспорту» по условиям ТЗ должен иметь возможность получать отчёт о рентабельности маршрутов.
Контекстная диаграмма с данными для отчёта о рентабельности маршрутов (зелёный квадрат)
Посмотрим, какие данные для этого нужны. У нас есть назначенные маршруты, есть данные о водителях и автобусах, поступающие из системы учёта кадров и системы учёта автотранспорта, и данные о платежах, которые поступают из системы платежей. Все эти данные в нашу систему поступают, а значит проблем с формированием отчёта не возникнет.
И рассмотрим третий пример. Тому же менеджеру по автотранспорту, чтобы принимать управленческие решения (например, сколько докупить автобусов), необходимо получать отчёт о простоях и ремонтах автотранспорта.
Контекстная диаграмма с данными для отчёта о простоях и ремонтах ТС (красный квадрат)
Для отчёта необходимы данные о ТС (они есть), но также нужны данные о ТС, которые находятся в ремонте, а эту информацию в систему никто не поставляет! Процесса поставки данных нет: его забыли указать при формировании ТЗ.
Если присмотреться внимательно, то эти же данные нужны нам и для формирования других отчётов, потому что, чтобы ТС можно было назначить на маршрут, оно не должно находиться в ремонте. Этого не обнаружили, когда формировались функции системы, которые отвечают за поставку, потому что в реальности работы данного АТП это всё было отражено административно: диспетчеру «на бумажке» подавались сведения о том, что такие-то автобусы находятся в ремонте и их нельзя ставить на маршруты, и он их просто не выбирал.
Соответственно, мы не только не получили такие отчёты, мы упустили целый набор либо технических интерфейсов обмена данными с другими системами, где они будут храниться, либо интерфейсов взаимодействия с пользователями, чтобы эти данные поступали.
Если бы мы на данном этапе построили контекстную диаграмму для системы, то сразу же выяснили, что для механика необходим графический интерфейс, который бы подавал данные о ТС на ремонте, и система автоматически не давала бы диспетчеру их назначить на маршрут. Кроме того, данные о ремонте сохранялись бы в системе, использовались при формировании отчета и помогали принимать текущие управленческие решения. Но, так как это процесс поставки данных был упущен, ситуация обнаружилась, только когда писалась постановка на отчёт, что привело к задержке выпуска системы.
Источник: systems.education
Руководство по использованию шаблона требований
Для того, чтобы правильно создать документ с описанием бизнес-требований, пожалуйста, придерживайтесь следующих принципов данного руководства. После завершения написания документа , удалите данный раздел.
Требование — это задокументированное условие или возможность продукта, сервиса или системы, которые должны соответствовать задачам проекта. Управление требованиями представляет собой семантический подход к выявлению, организации и документированию требований продукта, сервиса или системы. Документ с описанием бизнес-требований служит базовой линией проекта, которая поясняет, в бизнес-терминах, что необходимо сделать на этапе проектирования в проекте.
Так как требования являются динамичными, то документ с бизнес-требованиями является постепенно изменяющимся документом, целью которого является записывать то, что известно на данный момент, а затем используя эти записи строить документ дальше по ходу развития проекта. Именно из этого документа появляется более конкретная проектная документация, которая формируется на основе потребностей проекта и других взаимодополняющих методологий.
Владение документом
Бизнес -анализ и руководители проекта работают с бизнес-спонсором и любыми другими необходимыми бизнес или техническими лидерами на проекте в рамках формирования документа с бизнес-требованиями.
Когда документ формируется
Формирование документ с описанием бизнес-требований запускается во время начальной стадии выполнения проекта, который предшествует стадии проектирования в жизненном цикле управления проектами.
Определение бизнес-требований является обязательным этапом во всех проектах.
Template Completion
Note: Text within brackets need to be replaced with project-specific information.
Сбор требований непростой процесс, как это может показаться изначально. Это достаточно сложная задача, поскольку требования:
- не всегда очевидны;
- могут поступать из многочисленных и разнообразных источников;
- нуждаются в управлении кросс-функциональными группами людей;
- могут вызывать сложности при формулировании в ходе написании документации;
- могут формулироваться на разных уровнях детализации.
Для проекта, который представляет собой усовершенствование существующего продукта, сервиса или системы, команда проекта проводит обзор существующих документов; поэтому документ с бизнес-требованиями, как правило, является более кратким. Тем не менее, проект, в ходе которого должен быть разработан новый продукт, услуга или система, как правило, будет содержать более детальный документ.
- Не включайте раздел руководства к шаблону в итоговый документ. Введите информацию о проекте в заголовке страницы, нижние колонтитулы, титульный лист, участников по разработке документа, а также заполните информацию по контролю версий.
- Заполните документ, используя вспомогательную информацию в .
- Для небольших проектов можно объединить все разделы требований в одну таблицу, добавив столбец «Тип требования».
- Если некоторые требования не применяются в вашем проекте, то не удаляйте его, а пометьте его как «Не применяется» и укажите краткое пояснение, почему в текущем проекте данное требование не актуально.
- Если на проекте имеются дополнительные требования, то ими нужно дополнить раздел 5. Можно создать отдельную таблицу для помощи в выявлении, определении и отслеживании требований. Обратите внимание, что если новое требование идентифицируется после того, как утвержден документ с бизнес-требованиями, то новое требование необходимо внести в раздел 10.1 Дополнения (новые требования).
- После того, как были внесены изменения в документ, и вы готовы его завершить, убедитесь, что Вы обновили оглавление документа.
- Составьте карту рассмотрения документа и его утверждений теми лицами, которые были определены в разделе с заинтересованными сторонами.
- Из-за того, что документ с бизнес-требованиями является динамичным, после того, как менеджер проекта получает согласованный документ, все дополнительные, измененные или отмененные требования вносятся в 10 раздел.
- Если вносятся изменения в документ, то необходимо обновить раздел с историей обновлений документа.
- Документ с описанием бизнес-требований будет храниться вместе с другими документами проекта и поддерживаться в соответствии с политикой хранения документов.
Расширение прав и возможностей. Масштабируемость.
Данный шаблон предоставляется в качестве ориентира для сбора базовой информации, необходимой для успешного формирования документа с описанием бизнес-требований. Руководители проекта имеют право использовать этот шаблон по мере необходимости для сбора каких-либо конкретных требований предполагаемого проекта. Количество деталей, которые содержит документ, зависит от размера и сложности проекта. В зависимости от проекта или потребностей бизнеса, требования могут быть добавлены, но не могут быть удалены.
Читать: Шпаргалка бизнес-аналитика. Бизнес-требования
Информация по документу и согласование документа
Источник: www.antonpiskun.pro
Управленческая отчетность: назначение, виды, примеры
14 января 2020
Управленческая отчетность: назначение, виды, примеры
Опытный финансовый аналитик, бизнес-консультант, на экспертном уровне владеющий МСФО, имеет диплом DipIFR, более 10 лет руководящей работы. Возглавляла финансовые подразделения компаний с миллиардным оборотом и штатной численностью более тысячи сотрудников. Успешно с нуля внедряла управленческий учет на базе «1С:Управление производственным предприятием», осуществляла трансляцию РСБУ – МСФО, финансовый контроль (P» cellspacing=»0″ cellpadding=»0″>
Из полезной дополнительной информации по нему могу добавить, что сформировать его можно не только вручную в Excel, но и напрямую из «1С», используя аналитики программы «Статьи доходов и расходов» и панель «Финансовый результат и контроллинг». Вам достаточно настроить справочник статей доходов и расходов, организовать внесение первичной информации в соответствии с этим справочником, и на выходе вы получите всегда актуальный, автоматизированный отчет без дополнительных усилий на подсчет и сведение данных.
Отчеты по структуре себестоимости
С этой группой отчетов уже интереснее, так как, обладая широким продуктовым портфелем, финансист и топ-менеджер должны понимать, что происходит на стадии формирования себестоимости по каждому производимому продукту, по каким продуктам маржинальность выше, по каким ниже и почему.
Для этого минимум, который должен соблюдаться при введении первичной документации – разделение ее на продукты, а при настройке закрытия – распределение общих статей затрат (аренды, амортизации, заработной платы и т.д.) пропорционально выбранной базе распределения. В общем, ничего нового в ведение бухгалтерии управленческий учет не привнесет.
Механизм формирования себестоимости единицы произведенной продукции и так ведется аналогичным образом, весь вопрос в детализации единицы произведенной продукции. Например, если предприятие производит игрушки, то одна игрушка уже сейчас является единицей произведенной продукции и учет ведется по ней. Но если предприятие работает по договорам подряда, то учет нужно вести по каждому из договоров и дополнительных соглашений, а например, не по одному договору в целом. Тогда вы без проблем сможете отследить себестоимость и сделать анализ маржинальности производимой продукции.
Форма отчета по себестоимости может быть любой, удобной для конкретной отрасли, например такой, как в таблице 2.
Таблица 2. Форма отчета по себестоимости (фрагмент)
| Статьи доходов и расходов | Продукт 1 | Продукт 2 | Продукт 3 |
| ДОХОДЫ | |||
| Выручка от операционнной деятельности | |||
| РАСХОДЫ | |||
| Сырье и материалы | |||
| Сырье 1 | |||
| Сырье 2 | |||
| Сырье 3 | |||
| Сырье 4 | |||
| ФОТ | |||
| Окладная часть | |||
| Премиальная часть | |||
| Социальные взносы | |||
| Аренда | |||
| Прочие расходы | |||
| … | |||
| … | |||
| … | |||
| Амортизация | |||
| ВАЛОВАЯ ПРИБЫЛЬ | |||
| % |
Так же, как и отчет по доходам и расходам, отчеты по структуре себестоимости можно формировать из 1С. Самым простым по настройке является отчет «Валовая прибыль», стандартный отчет во многих программных решениях 1С. Детализировав его по статьям расходов, вы получите действенный инструмент анализа себестоимости, который еще и позволяет «проваливаться» вглубь расходов, детализировав их до Документа-регистратора.
Отчеты по отдельным разделам расходов
Такие отчеты используют реже, поэтому уделим им меньше внимания. Однако одним из них, отчетом по фонду оплаты труда, многие пользуются только исходя из распределения сотрудников по регламентированным отделам: производство, продажи, бухгалтерия и так далее.
Гораздо же интереснее и информативнее смотреть отчет по ФОТ исходя из управленческих подразделений (или ЦФО), особенно сравнивая его с выручкой по тому или иному ЦФО, например, такой, как в таблице 3.
Таблица 3. Отчет по ФОТ по ЦФО
Статьи доходов и расходов
Окладная часть
Премиальная часть
Социальные взносы
СПРАВОЧНО
Выручка
Источник: upr.ru
