Отчетность

Привет, Хабр! Меня зовут Станислав Маскайкин, я архитектор аналитических систем ВТБ. Сегодня я расскажу о том, почему мы перевели нашу систему подготовки отчётности с Oracle SuperCluster на российскую Arenadata DB. Как мы выбирали решение, почему не взяли чистый опенсорс, а также о некоторых результатах такой миграции под катом.

Зачем нужен был переход?

Несколько лет назад банк ВТБ объединился с Банком Москвы и ВТБ 24. Каждый из банков имел собственную ИТ-инфраструктуру с отдельным аналитическим контуром. После объединения получилось, что в банке одновременно существуют три разных ИТ ландшафта.

Само по себе владение тремя разными системами это тройные затраты на инфраструктуру, поддержку и развитие. Но в нашем случае было ещё несколько факторов.

С точки зрения законодательства любой банк должен регулярно сдавать отчётность проверяющим органам. После объединения эту отчётность мы должны были сдавать уже по единому ВТБ. Имея три разрозненные системы, решать эту задачу можно было разве что вручную.

Исторически ВТБ24 был ориентирован на работу с физическими лицами, ВТБ на работу с юридическими лицами, а Банк Москвы на работу и с первыми, и со вторыми.

На момент объединения этих банков обязательная отчётность формировалась в следующих системах:

1. Единое хранилище данных (ЕХД) хранилище данных Банка Москвы, реализованное на SuperCluster M8 и ETL-инструменте Informatica Power Center.

2. Система подготовки отчётности хранилище данных ВТБ24, реализованное на Oracle SuperCluster M8 с программным обеспечением Diasoft Flextera BI. Данные для этой системы готовились в другом хранилище корпоративном хранилище данных (КХД), реализованном на СУБД Teradata и ETL-инструменте SAS Data Integration. КХД, в свою очередь, получало данные из оперативного хранилища данных, реализованного на Oracle SuperCluster M8. А туда они реплицировались из автоматизированных банковских систем при помощи инструмента Oracle Golden Gate.

3. Корпоративное информационное хранилище хранилище данных ВТБ, реализованное на Oracle Exadata X8-2 и ETL-инструменте Informatica Power Center.

Чтобы не формировать обязательную отчётность по объединённому ВТБ в ручном режиме, были созданы интеграции между хранилищами данных.

Это привело к ещё двум большим проблемам:

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

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

2. Из-за большого количества расчётов в хранилищах и копирования данных выросло количество инцидентов с качеством этих данных, что тоже очень сильно влияет на сроки предоставление отчётности.

Ещё один момент: многие компоненты нашей инфраструктуры, такие как Oracle SuperCluster, на котором у нас реализована большая часть аналитического ландшафта, попали под End of life. Они были сняты с поддержки производителем и больше не развивались, т.е. обновление необходимо было в любом случае.

Проблема окончания поддержки коснулась не только системы подготовки отчётности, но и озера данных на платформе Oracle Big Data Appliance. К тому моменту а происходило все в 20182019 годах сотрудники ВТБ уже в полной мере оценили data-driven подход и потребляли достаточно много данных. Поэтому с точки зрения бизнеса банка система была критичной. Т.е. перед нами стояла более глобальная задача масштабов всей инфраструктуры.

Параллельно в объединённом ВТБ началась масштабная цифровая трансформация, охватившая все уровни IT, начиная от создания новых ЦОДов и объединения сетей, и заканчивая унификацией автоматизированных банковских систем и созданием омниканальной платформы для фронтальных решений. Всё это кардинально меняло внутренний IT-ландшафт банка.

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

Логичная идея создание единого аналитического контура, в рамках которого все данные будут находиться в едином хранилище данных и доступны для всех пользователей в удобном виде. Это привело нас к решению о построении платформы данных ВТБ.

Что такое платформа данных? Для себя мы определили её так: это набор сквозных интегрированных технологических решений (технологическое ядро), которые являются основой для разработки и функционирования сервисов по работе с данными банка ВТБ.

Главная часть платформы данных технологическое ядро. Это системные компоненты, которые переиспользуются на всех уровнях платформы данных.

Мы выделили 6 компонентов технологического ядра:

1. Управление данными.

2. Управление качеством данных.

3. Управление доступом.

4. Аналитические справочники.

5. Корректировки.

6. ETL Framework.

Концептуальная архитектура платформы данных выглядит следующим образом:

Ядром платформы данных является СУБД, на которой реализовывается хранилище данных. Далее расскажу об этом подробнее.

Выбор новой платформы

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

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

Мы рассматривали всех крупнейших производителей подобных решений: Oracle Exadata, Teradata, Huawei. Оценили отечественные разработки практически все, что есть на рынке. Нам показался интересным опенсорс, тем более для банка это не первый заход в тему открытого исходного кода.

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

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

• функциональность

• качество поддержки

• отсутствие санкционных рисков

• возможность гибкого масштабирования

• надёжность

• безопасность

• наличие Road Map развития платформы и возможность на него влиять

• стоимость владения совокупные затраты на программно-аппаратный комплекс на горизонте 10 лет (TCO5).

Если взять последний критерий, то даже с учётом стоимости всех контуров Arenadata DB и самого проекта миграции мы получали существенную экономию на фоне Oracle SuperCluster.

В итоге по совокупности факторов мы выбрали Arenadata DB.

Тестирование платформы

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

В итоге нами были проведены следующие проверки.

• Функциональное тестирование:

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

• Отказоустойчивость и отключение компонентов:

• Отключение дисковых устройств на уровне БД для проверки стабильности работы кластера.

• Отключение питания одного блока питания на серверах для проверки стабильности работы кластера.

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

• Совместимость со средствами резервного копирования банка:

  • Проведение цикла резервного копирования и восстановления БД на СРК Veritas Netbackup:

    • Полное резервное копирование БД

    • Инкрементальное резервное копирование БД

    • Восстановление БД

• Управление и качество работы системы:

  • Перезагрузка кластера: фиксация успешного выполнения процедуры перезагрузки.

  • Мониторинг и управление: субъективная балльная оценка от 0 до 5.

  • Генерация тестового отчёта: прогон запроса изсистемы подготовки отчётности в Arenadata DB для анализа качества результата генерируемого отчёта результаты выполнения отчёта должны быть идентичны.

• Нагрузочное тестирование:

  • Скорость загрузки данных

• Интеграционное тестирование:

  • Интеграция с ПО Infomatica Power Center

  • Интеграция с Oracle BI

  • Интеграция с QlikView 12.

Результаты тестирования

В ходе тестирования кластера Arenadata DB показал высокую производительность как на синтетических тестах, так и на реальных нагрузках.

Ниже приведено сравнение скорости выполнения запросов по сравнению с текущим Oracle Super Cluster T5-8.

Тестирование проводил системный интегратор IBS Platformix.

Кластер показал высокую скорость загрузки данных через ETL-инструмент Informatica Power Center: 200 Мбит/с.

В ходе тестирования была также осуществлена интеграция с основными BI-инструментами, используемыми в Банке ВТБ (Oracle BI и QlikView), и протестирован их функционал.

В QlikView на простейших SQL-запросах протестированы соединение с БД и выборка данных с последующей загрузкой в модель BI-инструмента.

Результаты выполнения представлены в таблице ниже.

При выполнении тестов была замечена особенность: получение первых строк данных из БД происходило с задержкой примерно в 23 секунды. После этого скорость выборки данных из БД и их доставки в QlikView становилась очень высокой.

Предположительно данная особенность связана c неоптимальной настройкой коннектора.

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

Благодарю Дениса Степанова и Никиту Клименко, экспертов IBS Platformix, за предоставленные результаты тестирования.

Сбор отчётности как пилот

Наша цель это миграция на Arenadata DB всех существующих хранилищ банка ВТБ.

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

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

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

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

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

Помимо экономии на стоимости владения, мы получили эффект от увеличения скорости расчета ряда форм в разы. Это дает нам более высокую доступность данных - по нашим оценкам в два раза.

Поскольку мы уже видим результаты и детали взаимодействия, около полугода назад стартовал наш основной проект - миграция на продукты Arenadata центрального единого хранилища данных и озера данных. Помимо Arenadata DB, мы используем Arenadata Streaming на базе Apache Kafka и Arenadata Hadoop на базе Apache Hadoop. В ближайшее время первые результаты пойдут в продакшен.

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

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

Как выбирали систему построения отчетности

Создавать модуль построения отчетов в платформе задача нетривиальная и дорогостоящая, поэтому возникла необходимость поиска подходящего инструментария для построения отчетов. Главными нашими критериями были:

• Бесплатное использование ПО в коммерческих проектах с открытым исходным кодом

• Инструмент для построения данных должен работать с основными форматами источников данных, а так же напрямую БД.

• Использование языка Java для построения отчетов

• ПО должно быть поддерживаемым и обновляемым c поддержкой обратной совместимости

• Редактор построения отчетов должен быть удобным и понятным

• Инструмент должен позволять создавать шаблоны отчетов всех основных форматов: excel, csv, pdf, html, и т.д

• Богатые возможности визуализации и построения дашбордов.

Мы провели исследование части наиболее известных open-source систем построения отчетов, и результаты нашего исследование мы собрали в таблицу, которой хотим поделиться.

Как видно из нашего небольшого исследования, наиболее подходящим инструментом для нас стал JasperReports. В пользу этого open-source инструмента говорит наличие весьма удобного визуального редактора проектирования отчетов, богатого набора визуализаций, включая кросстаблицы, а самое главное - наличие REST API. Проектирование макетов отчетов в JasperReports не требует особых глубоких знаний, а результаты проекта сохраняются в xml-формат. Так же мы ориентируемся на опыт коллег, например, наши партнеры КРОК в своей статьеhttp://personeltest.ru/aways/habr.com/ru/company/croc/blog/244085/рекомендуют использовать Jasper. JasperSoft наибольшим образом подходит для построения фиксированной отчетности. Интересны любой компании, которой необходимы инструменты анализа данных. Конечно, у jasper есть определенные проблемы, когда требуется сделать гибкий шаблон, например, когда необходимо сделать гибкий вывод полей в таблице, но в нашей практике мы сталкиваемся как правило с фиксированными отчетами, которые обозначает заказчик.

Взаимодействие клиент-сервер с Jasper reports

Мы полагаем, что может быть интересным то, как именно мы встраиваем jasper отчеты непосредственно в платформу без лишних запросов к Jasper Server. JasperReports Server это основной компонент системы. Его задача - хранить отчеты, которые будут встраиваться в платформу, а так же предоставлять возможность просмотра отчетов напрямую через специальный интерфейс. Вот пример как это выглядит в платформе

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

Для того, чтобы получить отчет необходима авторизация в Jasper Server. Авторизация происходит путем передачи пары логин/пароль, а в ответ Jasper создает сессию и сохраняет session_id в куках. В обычном случае для того, чтобы напрямую взаимодействовать с JasperServer из JavaScript, нам необходимо авторизоваться, получить session_id из куки и запросить сам отчет. Однако на практике мы столкнулись с проблемой, что в случае использования кластера серверов с дублированием Jasper на всех инстансах, jasper отчеты то доступны, то недоступны для пользователя. Проблема заключается в том, что балансировщик, получив запрос от клиента, запрашивает ответ с разных JasperServer, но использует session_id только одного инстанса . То есть мы авторизовались в JasperServer на первом инстансе, получили от него session_id, затем c этим же session_id мы идем на другой инстанс и получаем ошибку доступа с сообщением Авторизуйтесь на JasperServer. Для решения этой задачи мы используем специальный проксировщик, который по сути является расширением бэкэнда платформы и устанавливается на все ноды кластера.Так как проксировщик установлен на том же сервере, что и Jasper server, ему нет необходимости обращаться по IP к ноде, а достаточно обратиться по localhost. Таким образом, балансировщик, передавая запрос от клиента на ту или иную ноду, запрашивает у проксировщика авторизацию уже на месте и гарантировано Jasper Server вернет ответ. Ниже представлен код проксировщика.

public Response getJasperReport(@QueryParam("url") String url) throws UnsupportedEncodingException {    url = url.replaceAll(";;", "&").replaceAll(" ","%20").replaceAll("\"","%22");     Client client = ClientBuilder.newClient();    Response authResponse = client            .target(jasperUrlLogin)            .queryParam("j_username", jasperLogin)            .queryParam("j_password", jasperPassword)            .request()            .header("Content-Type", "application/x-www-form-urlencoded")            .header("charset", "utf-8")            .post(Entity.json(""));    NewCookie sessionIdCookie = null;    if (authResponse.getStatus() == 200) {        Map<String, NewCookie> cookies = authResponse.getCookies();        sessionIdCookie = cookies.get("JSESSIONID");    } else {        LOGGER.warn("Cant auth JasperServer");        return null;    }     String requestUrl = jasperReportUrl + url;     Response response = client            .target(requestUrl)            .request()            .cookie(sessionIdCookie)            .header("Content-Type", "text/html")            .get();    return response;}

Проксировщик получает на вход некий URL отчета, который собирается из параметров на клиенте. По этому URL происходит авторизация в jasperServer, далее проксировщик достает из куки session_id и уже по нему запрашивает ответ непосредственно самого отчета. Ответ от jasper приходит виде html-страницы. Именно эту html-страницу мы передаем в iframe для отрисовки на клиенте, а не url, как это обычно бывает. Таким образом мы один раз запрашиваем отчет, далее вся работа с ним идет уже непосредственно на клиенте платформы.

Создаем Iframe

{    xtype: 'component',    margin: '20 0 0 0',    reference: 'report',    maxWidth: 1200,    height:485,    autoEl: {        tag: 'iframe',        src: '',        frameBorder: 0,        marginWidth: 0,    },    listeners: {        load: {            element: 'el',            fn: function () {                var panel = this.getParent().component;                panel.setLoading(false, panel.body);            }        }    }}

Подкладываем html страницу от Jasper Server

generateReport: function () {        var report_url = this.generateReportUrl('html');        if (report_url) {            var panel = this.view;            panel.setLoading(true, panel.body);            this.getHtmlAndUpdateReport(report_url);        }    }

generateReportUrl - метод, который генерирует URL с нужными параметрами для отчета и session_id.

Cоздание отчета в JasperReports

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

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

Начало структуры файла: пример параметров отчета

<?xml version="1.0" encoding="UTF-8"?><!-- Created with Jaspersoft Studio version 6.9.0.final using JasperReports Library version 6.9.0-cb8f9004be492ccc537180b49c026951f4220bf3  --><jasperReport xmlns:xsi="http://personeltest.ru/away/www.w3.org/2001/XMLSchema-instance" xmlns="http://personeltest.ru/away/jasperreports.sourceforge.net/jasperreports" xsi:schemaLocation="http://personeltest.ru/away/jasperreports.sourceforge.net/jasperreports http://jasperreports.sourceforge.net/xsd/jasperreport.xsd" name="pubsub_diagram" pageWidth="1150" pageHeight="550" columnWidth="555" leftMargin="20" rightMargin="20" topMargin="20" bottomMargin="20" uuid="e8ef4a20-ab26-44c0-8b4d-316411f7d350">    <property name="com.jaspersoft.studio.data.defaultdataadapter" value="postgres_local.xml"/>    <property name="net.sf.jasperreports.export.xls.ignore.graphics" value="false"/>    <parameter name="date_from_param" class="java.lang.String"/>    <parameter name="date_to_param" class="java.lang.String"/>    <parameter name="systems_param" class="java.util.Collection"/>    <parameter name="status_param" class="java.util.Collection"/>    <parameter name="entities_param" class="java.util.Collection"/>    <parameter name="count_details_param" class="java.lang.Integer"/>    <parameter name="group_param" class="java.lang.String"/>

Далее предположим, что источником данных является во второй части после параметров пишем SQL-запрос

 <queryString>        <![CDATA[SELECT * FROM (Cnjbn with main_table AS(SELECT T3.status as status, count(T3.id) as count_status, (count(T3.id) / (to_date($P{date_to_param}, 'DD_MM_YYYY') - to_date($P{date_from_param}, 'DD_MM_YYYY') + 1)) as avg_count_status  FROM(SELECT T1.id,T2.status    FROM public.history     AS T1LEFT JOIN(SELECT DISTINCT ON (history_id) history_id, status FROM public.trackWHERE createdate >= to_date($P{date_from_param}, 'DD_MM_YYYY')    AND DATE(createdate) <= to_date($P{date_to_param}, 'DD_MM_YYYY')ORDER BY history_id, createdate DESC NULLS LAST) AS T2ON T1.id = T2.history_idWHERE T2.status IS NOT NULLAND $X{IN,T1.unidatasourcesystem, systems_param} AND $X{IN,T1.entity, entities_param}AND T1.createdate >= to_date($P{date_from_param}, 'DD_MM_YYYY')AND DATE(T1.createdate) <= to_date($P{date_to_param}, 'DD_MM_YYYY')AND $X{IN,T2.status, status_param}) AS T3GROUP BY T3.status)SELECT main_table.*, round((count_status * 100) / (SELECT SUM(count_status) FROM main_table), 2) AS percent_status FROM main_table) AS t_result order by status]]>    </queryString>

Стоит обратить внимание, что в запросе мы используем параметры $P{date_to_param}, которые динамически приходят от клиента, что так же является фишкой Jasper.

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

<columnHeader>    <band height="35">        <staticText>            <reportElement x="0" y="0" width="150" height="30" uuid="1972f653-13ec-41b8-987a-a1f25940e053"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[Статус]]></text>        </staticText>        <staticText>            <reportElement x="150" y="0" width="150" height="30" uuid="bde4e86c-d3d8-4538-a278-44eae4cda528"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[Количество сообщений]]></text>        </staticText>        <staticText>            <reportElement x="300" y="0" width="160" height="30" uuid="ab26081d-2c0b-45b3-8c43-5707e2b555e7"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[Среднее в день]]></text>        </staticText>    </band></columnHeader><detail>    <band height="35" splitType="Stretch">        <textField>            <reportElement x="0" y="0" width="150" height="30" uuid="ea66974c-f627-4096-86c3-fc0f921a88d2"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$F{status}]]></textFieldExpression>        </textField>        <textField>            <reportElement x="150" y="0" width="150" height="30" uuid="a820021d-95d6-4ee5-a5a4-887aca484efb"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$F{count_status}]]></textFieldExpression>        </textField>        <textField>            <reportElement x="300" y="0" width="160" height="30" uuid="e7927fa9-5b8f-43ff-bea7-1d74d8a3ce27"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$F{avg_count_status}]]></textFieldExpression>        </textField>    </band></detail><summary>    <band height="370">        <staticText>            <reportElement x="0" y="0" width="150" height="30" uuid="d93b83c8-b168-4766-91d8-b9545e3239a7"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[ИТОГО]]></text>        </staticText>        <textField>            <reportElement x="150" y="0" width="150" height="30" uuid="6e306a81-3522-437d-a973-0dcf8646aa5f"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$V{sum_status}]]></textFieldExpression>        </textField>        <textField>            <reportElement x="300" y="0" width="160" height="30" uuid="67d24b52-4d3e-47ae-a35d-dc98a9b230f5"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$V{sum_avg_count_status}]]></textFieldExpression>        </textField>        <pieChart>            <chart evaluationTime="Report">                <reportElement x="0" y="40" width="400" height="320" uuid="bf9f29b3-51c1-472d-822b-e7e4b20fa160"/>                <chartTitle/>                <chartSubtitle/>                <chartLegend/>            </chart>            <pieDataset>                <keyExpression><![CDATA[$F{status}]]></keyExpression>                <valueExpression><![CDATA[$F{count_status}]]></valueExpression>                <labelExpression><![CDATA["" + $F{percent_status} + "% " + $F{status}]]></labelExpression>            </pieDataset>            <piePlot>                <plot>                    <seriesColor seriesOrder="0" color="#33F54A"/>                    <seriesColor seriesOrder="1" color="#EB73C1"/>                    <seriesColor seriesOrder="2" color="#433DF2"/>                    <seriesColor seriesOrder="3" color="#FAEC52"/>                    <seriesColor seriesOrder="4" color="#FFC342"/>                    <seriesColor seriesOrder="5" color="#D9D2D8"/>                    <seriesColor seriesOrder="6" color="#DE522F"/>                </plot>                <itemLabel/>            </piePlot>        </pieChart>    </band></summary>

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

<subreport>    <reportElement x="460" y="40" width="650" height="320" uuid="e0d58e35-b1da-4bcc-9978-fbda3028ff5a"/>    <subreportParameter name="date_from_param">        <subreportParameterExpression><![CDATA[$P{date_from_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="date_to_param">        <subreportParameterExpression><![CDATA[$P{date_to_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="systems_param">        <subreportParameterExpression><![CDATA[$P{systems_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="status_param">        <subreportParameterExpression><![CDATA[$P{status_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="entities_param">        <subreportParameterExpression><![CDATA[$P{entities_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="group_param">        <subreportParameterExpression><![CDATA[$P{group_param}]]></subreportParameterExpression>    </subreportParameter>    <connectionExpression><![CDATA[$P{REPORT_CONNECTION}]]></connectionExpression>    <subreportExpression><![CDATA["repo:pubsub_grapf.jrxml"]]></subreportExpression></subreport>

Ключевым вопросом в построении отчета является передача параметров (фильтров) отчета от клиента на сервер. Для того, чтобы не отправлять пользователя на JasperServer и все параметры отчета заполнять в платформе удобным способом, Jasper предлагает использовать собственный REST API. Наличие такого мощного API было решающим аргументом в сторону выбора JasperSoftдля автоматизации отчетности. Вместо того, чтобы создавать ресурсы и заполнять параметры в среде Jasper Server мы просто воспользуемся методами, которое предоставляет нам API и передадим параметры GET-запросом от клиента. API jasper позволяет не только параметризировать данные, используемые в отчетах, но и сами отчеты, что позволяет очень гибко отображать нужные дашборды

Итого

Резюмируя все выше описанное мы рекомендуем к использованию JasperSoft когда есть потребность в создании гибких отчетов согласно шаблонам заказчика. Для этого Jasper предоставляет весь необходимый инструментарий, а работать в ним достаточно просто и удобно.

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

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

В типовом функционале ERP существует ряд ограничений:

• Отсутствуют инструменты по инвентаризации ТМЦ в эксплуатации, что для крупных компаний является обязательной процедурой.

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

• Нет единого отчета, который бы аккумулировал в себе все сводные данные по учету спецодежды.

Количественные и суммовые данные разбросаны по нескольким отчетам. Например, чтобы получить информацию о количестве и стоимости ТМЦ в эксплуатации, нужно сформировать ОСВ (оборотно-сальдовую ведомость) по счету и типовой отчет "ТМЦ в эксплуатации", а затем сопоставить данные отчета в единый. При больших объемах данных такой процесс, естественно, усложняет работу пользователям и влияет на рост количества ошибок.

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

• Не отражается движение спецодежды по счетам МЦ и 10.11 в рамках одного месяца, если она была передана в эксплуатацию в этом же месяце.

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

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

• Расчет остаточной стоимости ТМЦ, стоимость которых была погашена при передаче в эксплуатацию.

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

Сейчас в типовой системе 1С:ERP вся спецодежда и спецоснастка (согласно ФСБУ 5), которая передается в эксплуатацию, списывается на расходы сразу, независимо от срока службы. Проблема заключается в том, что при полном списании, когда не учитывается реальный срок службы спецодежды (в учете 2021 в системе не заложены такие документы), нельзя автоматически рассчитать остаточную стоимость, которая важна для формирования возврата средств за спецодежду и финансового результата при реализации.

Может ли автоматизация процессов в 1С решить насущные проблемы учета?

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

Рассматривая данные цели в разрезе учета спецодежды в 1С:ERP, для их достижения необходима автоматизация учета ТМЦ. Для решения вопроса оперативности, полноты и достоверности данных о ТМЦ в эксплуатации был разработан отчет "ТМЦ в эксплуатации" на базе типового отчета 1С:ERP.

Данный отчет позволяет:

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

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

• увидеть суммовые показатели по перемещениям и списаниям ТМЦ в том периоде, в котором они отражены по документам, независимо от даты передачи их в эксплуатацию;

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

Важный момент: отчет подключается к 1С как внешний инструмент и не рушит текущие процессы системы, в которой работает компания.

Разбираемся с инвентаризацией

Чуть выше мы говорили о том, что 1С:ERP в принципе нет документов по инвентаризации. Но данный процесс нельзя обходить стороной. Удачной альтернативой ручному труду будет является проведение доработки самой системы 1С, учитывая нюансы самой компании, так как тут все индивидуально.

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

Документ "Инвентаризационная ведомость для ТМЦ в эксплуатации" заполняется автоматически по данным забалансового счета МЦ по сумме и количеству с учетом данных оперативного контура, что позволяет получать актуальные данные после проведения документов перемещения и списания, независимо от формирования проводок в БУ. При этом в документе есть возможность формирования печатных форм ИНВ-3 и ИНВЕ-19.

Автоматическое заполнение реквизитов в документах по учету ТМЦ в эксплуатации

В рамках разработки отчета были доработаны механизмы, позволяющие автоматизировать:

• заполнение стоимости ТМЦ при возврате из эксплуатации, если на момент возврата не вышел срок службы или в принципе есть остаточная стоимость на счете 10.11;

• заполнение реквизитов Физическое лицо получатель при перемещении.

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

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

Если у вас появятся вопросы - оставляйте заявку, мы подробно проконсультируем по функционалу!

Привет, Хабр! Меня зовут Владимир, я бизнес-аналитик в офисе данных Ростелекома и занимаюсь развитием отчётности. Компания делает ставку на развитие data-driven культуры. Спрос на данные и аналитику со стороны бизнеса растёт, и соответственно развивается экосистема управления данными, в том числе организационная структура и бизнес-процессы.

К концу 2019 года объём задач отчётности очень сильно вырос и это стало своеобразным нагрузочным тестированием для наших процессов. Стало понятно, что работать по-старому и соблюдать SLA нам становится все сложнее. Были нужны новые правила игры, соблюдение которых сделает управление типовыми задачами проще, планирование более предсказуемым, а выполнение обязательств реалистичным даже в условиях, когда рост команды сильно ограничен, а рост количества заявок безграничен.

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

Введение

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

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

Ситуация

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

В корпоративном центре Ростелекома все профильные направления, работающие с отчётностью, объединены в Офис Данных. Это более двух сотен сотрудников в Москве и регионах, которые занимаются развитием платформы управления данными, работают в направлении глубокого анализа и развитии аналитической отчётности.

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

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

Обычно в работе у фронт-менеджера есть 10-12 задач, с каждой задачей на различных этапах может работать от 2 до 5 человек. Длительность таких задач от нескольких недель до полугода (это очень грубая оценка, чтобы показать масштабы). По каждой доработке требуется создать артефакты: комплект документов, которые будут использоваться сопровождением для работы над инцидентами, и отчётность в JIRA по объёмам трудозатрат, срокам работ и загруженности ресурсов, которая позволяет анализировать эффективность процессов.

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

Поиск решения

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

Мы поняли, что в нашем случае многие классические компетенции руководителя проектов окажутся невостребованными: например, не требуется управлять бюджетом или поставщиками, проекты будут выполняться по одному и тому же регламенту, а предметная область всегда будет ограничена отчётностью для конкретного бизнес-сегмента. Задачи чаще всего типовые, но требуют погружения в предметную область, понимания процесса разработки и содержания работ на всех этапах.

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

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

• погружены в предметную область, как никто другой;

• участвуют в выполнении задачи на всех этапах;

• выполняют интегрирующую роль для команды.

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

Реализация

Дальше мы проектировали и документально оформляли процесс, совмещали с уже существующими операционными процессами, о некоторых из которых уже рассказывали мои коллеги (статьи на Хабре: раз, два). В общем процесс разработки приобрел вид:

Документацию составили в формате методики управления, скорее даже инструкции. Где-то брали собственные наработки, где-то транслировали рекомендации PMBoK на наше организационное окружение. Писали так, чтобы документа было достаточно для выполнения роли РП, и чтобы его мог использовать человек без опыта проектного управления.

Затем, дополнив документ всей сопутствующей мишурой вроде шаблонов, провели обучение и в начале 2020 года запустили процесс в пилотном режиме. Работа ещё не завершена, по части согласованности процессов ещё многое нужно сделать, но определенные выводы уже можно сделать.

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

К плюсам принятого решения можно отнести:

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

2. На коммуникации внутри команды времени тратим не больше, чем тратили раньше;

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

Трудности:

1. Есть нестыковки с операционными процессами, особенно в нетиповых ситуациях, но это ожидаемо продолжаем шлифовать;

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

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

аналитика даёт больше плюсов, чем создает неудобств.

Вместо эпилога

Минуточку, управление работами по задаче Вы там что, открыли для себя дверь роль менеджера проекта и повесили на бизнес-аналитика?. Короткий ответ Да, ответ по существу длиннее Сначала мы оценили все, что нам нужно от роли, упростили её соответственно задачам и подготовили всё необходимое, чтобы даже начинающий РП мог её выполнять.

Важнее не название роли, а наполнение. Называть можно как кому привычнее Руководителем проекта, тех. лидом или как-то ещё это вопрос удобства и выбранного глоссария.

P.S. Только не миниРП, пожалуйста :)