Вступительное слово
Добрый день! Меня зовут Воронин Николай, я занимаюсь автоматизацией систем отчётности и анализа в ПГК Диджитал.
Моя статья является структурированием личного опыта, полученного в конкретных условиях, он не претендует на статус best‑practice, допускает ситуации, в которых могут существовать более эффективные решения или проблема не стоит в целом.
Мета‑ориентирование — это общее название, в рамках статьи, для совокупности навыков и подходов, облегчающих понимание частных алгоритмов и потоков данных в большой системе со сложными связями между множеством объектов.
В моём случае речь пойдёт о комплексе нескольких BI систем, существующих параллельно, но сложности вполне могут возникать и в рамках одной, достаточно массивной системы отчётности.
Суть проблемы
В двух словах: проблема возникает, когда количество объектов и связей между ними начинает ощутимо превышать то, что можно удержать в голове, либо требуется переключиться на новый блок (например, если отвечавший за него коллега ушёл в отпуск или уволился), либо это новое место работы.
Моя зона ответственности включает работу в новой корпоративной системе автоматизации отчётности. Так же в формате поддержки и минимального развития есть старая система — Cognos BI, на которой работает некоторое количество исторических отчётов и рассылок. Отдельным блоком можно выделить слой интеграции старой и новой системы отчётности и слой экспорта для дополнительных аналитических инструментов.
Общее количество информационных объектов исчисляется тысячами, между ними передаются данные, реализуется различная бизнес логика, расчёты могут быть в самых разных местах. Когда поступает задача доработать, например, отчёт в новом незнакомом блоке, изучение того, что и как считается, откуда приходит, куда уходит, на что ещё может повлиять доработка — всё это может занять больше времени, чем сама доработка. Также велик риск что‑то упустить и повлиять на то, что затронуто быть не должно.
Информационный хаос — новая реальность
Возможно слово «хаос» излишне экспрессивно для описания ситуации, тем не менее, объективные причины, блокирующие возможность всё структурировать, упорядочить, унифицировать, задокументировать и поддерживать, на мой взгляд, существуют.
Первый фактор хаоса — изменчивость ситуации в процессе внедрения.
Внедрение и развитие массивных систем не бывает одномоментным, в процессе могут меняться отдельные разработчики (даже целые команды), внешние условия, что может повлечь пересмотр алгоритмов и увеличить время, может поменяться ситуация с бюджетом, и от чего‑то придётся отказываться. В моём понимании, чем больше внедряемая система, тем наивнее полагать, что можно её полностью заранее продумать и сразу получить удовлетворяющий всем потребностям и реалиям результат. На это хочется рассчитывать, но не стоит ожидать, что так будет.
Второй фактор хаоса — расхождения в восприятии реальности.
Бизнес должен ставить задачу разработчикам, объяснять, что должно получиться. В начале работы от заказчика зачастую тяжело получить нужную информацию в полном объёме, потому что для заказчика многие вещи очевидны и ему кажется, что всё это известно разработчику. Надо понимать, что программисты (если не углубляться в классификацию специализаций) и бизнес‑специалисты мыслят в разных плоскостях. Например, разработчик воспринимает данные, как набор строк в таблицах, однозначно связанных по каким‑то ключам, ограниченных фильтрами до определённой степени детализации. Для бизнес‑специалиста — это будет поток документов, выборка которого обусловлена прикладным знанием особенностей договоров и участвующих контрагентов. Логика связей может отличаться в зависимости от типов договоров, хотя на уровне данных всё это лежит в одних и тех же структурах. По такой же логике, как и с первым фактором, в силу растянутости процесса внедрения, развития и поддержки, вовлечённые в проект люди могут меняться и на стороне заказчика. В результате необходима итеративная отладка после первоначальной реализации, в рамках которой копятся отклонения от начальной задумки, и могут появляться так называемые костыли.
Третий фактор хаоса — желания против ограничений.
У проектов есть лимиты — это сроки, бюджеты и мощности (физические ограничения железа). Что‑то хотя бы частично рабочее должно появиться к определённому сроку, компании необходимо начать этим пользоваться и ждать вечно она не может. Бюджет так же ограничен и в него включён максимум прикладного функционала. Минимальный приоритет — это та часть, которой не будет пользоваться бизнес. То есть какие‑то встроенные системы мониторинга и техническая документация наверняка будут делаться по остаточному признаку и по факту могут не соответствовать финальной версии реализации. Заказчику важно увидеть рабочую форму, которая делает то, что он хотел, и уже менее важно увидеть, что все поля этой формы описаны на всех этапах её формирования в документе. А, например, существование монитора, фиксирующего странное поведение — уже совсем вторично, потому что у конкретного специалиста от бизнеса есть свои прямые обязанности и на участие в ИТ‑проекте ему и так приходится тратить дополнительное время. Разработчик также стремится в первую очередь реализовать правильно выглядящую верхушку, которую будет принимать заказчик, рассчитывая заняться её описанием и отладкой на заключительном этапе. Некрасивое рабочее решение однозначно предпочтительнее красивого, но неправильного — это простой здравый смысл. Как итог — лимиты могут и, скорее всего, буду достигнут раньше, чем удастся выровнять, оптимизировать и подробно описать всю систему.
С этим всем приходится иметь дело, даже если нет вопросов к добросовестности обеих сторон.
Классическая документация
В ПГК Диджитал используется классическое документирование, ведутся документы функциональных спецификаций, описания алгоритмов, бизнес‑логики. В целом это правильно, так как документация служит не только целям быстрого поиска информации. Но в контексте быстрой навигации в алгоритмах, на мой взгляд, полноценное документирование не будет решением проблемы.
Во‑первых, её написание действительно может ощутимо удорожить проект: подробное описание всех объектов, их логики и связей, поддержание документации в актуальном состоянии — это большие трудозатраты. У документирования есть другое прикладное назначение, например, решение возникающих споров о соответствии реализации поставленной задаче. В целом мало кто готов закладывать бюджет на треть больше, ради дополнительных текстовых документов.
Во‑вторых, это будет очень большой объём документов, а тексты — это «аналоговая» информация, которую надо воспринимать последовательно. Частично ситуацию улучшает что‑то типа Confluence, при условии, что документы нормально размечены, в них проставлены ссылки друг на друга, метки и т. п. Но изучение какого‑либо процесса по таким документам будет по трудозатратам соизмеримо с прямым изучением логики непосредственно в системе.
Автодокументирование
Многие системы в той или иной степени обладают встроенными инструментами, способными формировать таблицы на основе своих метаданных, где будут отображены связи между объектами, свойства объектов и дополнительная информация. Есть полноценные сторонние решения. Есть возможность собственной реализации. Но если мы находимся в ситуации нескольких систем, встроенные инструменты не в состоянии показать полный маршрут. Сторонние решения или собственные разработки — это большие траты и долгая разработка, плюс трудозатраты на поддержание.
Мета-навигация
В моём случае это своеобразный гибридный подход, совмещающий имеющуюся документацию, встроенные инструменты, вспомогательные скрипты и местами ИИ. Основная суть подхода – таргетно добыть информацию по конкретной теме, с которой сейчас ведётся работа. Классическая документация здесь нужна, чтобы сориентироваться по общим вопросам. Например, такая банальная вещь, как физическое название нужного отчёта в системе или его верхнеуровневых объектов. Далее, если, требуется внести изменение в расчёт конкретного показателя, мы можем рассмотреть только его, а не полное описание всего отчёта: здесь как раз можно применять разные способы автоматизации, упрощающие работу.
У меня есть несколько кейсов, которые я рассмотрю отдельно.
Сквозной поток данных
В системе автоматизации отчётности и анализа есть встроенный механизм, показывающий зависимости конкретного объекта. Пользуясь им, можно пройти от самого верха (верхнеуровневые виртуальные объекты), до самого низа (источники данных), правда, это займёт какое‑то время. Однако, если где‑то в середине потока данных будет переход на уровень базы данных и обратно — получится разрыв, через который этот инструмент смотреть не может.
Я реализовал цепочку расчётов, которая собирает информацию по объектам, унифицирует её и формирует огромную таблицу вида Source‑Target. Первым шагом отдельно собираются данные по объектам типа HCPR, IOBJ и ADSO, CV (графические) и CV и TF (скриптовые), данные из трансформаций. Далее полученный результат обогащается, чистится и передаётся в финальную ADSO. Её данные могут быть использованы и селектом в базу данных, и как источник для отчёта bex или webi, чтобы получить табличку в нужном виде. Так же я сделал дополнительный интерфейс на web‑hana, который отображает схему со связями по перечню объектов и позволяет немного в ней поразбираться.
Основные ответы, которые даёт инструмент:
Что используется для этого объекта
Где используется этот объект
По всей системе с учётом переходов между слоями.
Есть и недостатки. К сожалению, руки не дошли добавить парсинг ABAP‑рутин, из‑за чего часть связей выпадает. Из анализа упущены Open ODS View и объекты OpenHub. Также на этом этапе инструмент работает только с объектами, но не содержит информации о полях этих объектов. Тем не менее задача понять, на что может повлиять изменение объекта, или какие у него в самом низу datasource, периодически возникает.
Схема построена на данных системных объектов:
SAPABAP1.RSDAREAT — инфообласти
SYSREPO.ACTIVE_OBJECT ‑CV и TF
SAPABAP1.RSOHCPR — композитные провайдеры
SAPABAP1.RSOADSO — ADSO
SAPABAP1.RSDIOBJ — признаки и показатели
SAPABAP1.ROOSOURCE, SAPABAP1.RSLOGSYSDB, SAPABAP1.DBCON — источники данных
SAPABAP1.RSTRAN — трансформации с входящим и исходящим объектом (но без учёта рутин)
Удобочитаемые таблицы для композитных провайдеров — слой виртуальных объектов в системе автоматизации отчётности и анализа
В композитных провайдерах довольно просто можно найти, какое выходное поле получилось из какого входящего. Но если требуется сопоставить 100+ полей, переход между вкладками с копированием названий в поля поиска может отнять много времени, и из-за своей монотонности повысить риск ошибки.
Для разбора также можно воспользоваться таблицей SAPABAP1.RSOHCPR. В ней в том числе содержится xml со структурой композита. В моём случае я получаю результат прямым селектом и парсингом, выделяющим ключевые xml-теги и раскидывающим по полям их значения.
На выходе получаю примерно вот такую таблицу, с которой уже гораздо проще работать. При необходимости, её можно дополнить содержащейся в XML информацией.
Упрощение восприятия логики и связей в графических CV
По аналогии с композитными провайдерами, из SYSREPO.ACTIVE_OBJECT можно получить xml графической CV. Логика в ней может быть значительно сложнее, так что простой таблицей тут не обойтись. Ещё один инструмент упрощающий жизнь лично мне — это html+js. Выкачанный xml CV я сохраняю в виде файла, рядом кладу js библиотеку, разбирающую его в json и вызывающую эту библиотеку html‑форму, в которой отрисовывается перечень блоков с основной информацией по полям каждого шага формирования CV, а также формулы и ссылки внутри формы на источники. Примерно вот такой вид выходит (по табличке на все ноды CV с формулами и ссылками на предшествующие ноды и их поля):
Можно вместо развёрнутой формы сделать интерфейс, который будет собирать сквозной расчёт.
Прочие кейсы
По похожей логике делал парсинг Больших Пакетов в Oracle с парсингом их кода для поиска — какая процедуры из каких таблиц берёт данные и в каких таблицах данные меняет
Выгружал фрагменты отчётов и моделей метаданных Cognos BI (правда, довольно старой версии 10.2.2). И то и другое можно получить в виде xml, либо сформировать отчёт, скопировать html получившейся страницы и сметчить по названиям, и также собрать таблицу непосредственной связи полей отчёта, объектов модели и таблиц базы данных, либо процедур. В данном случае скрипт обращения к БД можно получить напрямую из отчёта, но не всегда однозначно понятно, откуда какие пришли фильтры и расчёты.
ИИ
Сейчас одним из инструментов, позволяющих снизить собственные трудозатраты, являются ИИ. Наиболее простые и удобные — DeepSeek и ChatGpt.
Важно учитывать требования компании к конфиденциальности, т.к. при работе со сторонними нейросетями — вы по сути передаёте в них внутренние данные. Что бы не возникало проблем, я выполняю некоторую предварительную подготовку.
Формулирую задачу абстрактно, стараюсь даже не указывать конкретную область применения, для алгоритма она не важна.
Не использую реальные данные. В той же нейросети можно сгенерировать абстрактный пример, указав перечень вариантов, которые в нём должны присутствовать (например, в столбце могут быть пустые строки, null, цифры и латинские буквы — нужно ~50 строк с разными комбинациями этих вариантов разной длины).
Не использую оригинальные названия объектов, если это не абстрактные кодовые названия не несущие смысловой нагрузки, типа XBTkk015.
Смотрю по ситуации, есть ли нюансы. Если есть сомнения — не пользуюсь ИИ.
Они подходят для выполнения рутинных задач, могут сгенерить код, который будет разбирать xml, расскажут, что в этом xml есть, и спросят, как его организовать, чтобы удобно было смотреть. Иногда есть задача сделать огромный select из большой таблицы с какими‑то дополнительными правилами. Например, была задача сверки изменений после активации ADSO, т.к. было подозрение, что не все данные реально изменились, либо в каких‑то признаках присутствует «рулетка» и в целом имеется избыточность. Также надо было проверить фактическую глубину изменений задним числом от общей массы. По сути требовалось сделать построчное сравнение каждого поля. Для удобства все их надо было перевести в один формат, показателям отрезать минусы (чтобы сторнировки с минусом не считались новыми значениями). В общем примерно 700 раз надо было написать почти одну и туже формулу, при этом учитывая особенности конкретного поля. Такую задачу тоже можно закинуть ИИ, чётко описав правила (здесь был нюанс в том, чтобы уговорить его сделать это именно со всеми 700 полями, а не просто парочку для примера). Иногда бывает удобно, если нет кода, а есть только его картинка, сэкономить время на переписывании руками — картинки с текстом анализируются очень хорошо. Если список таких столбцов и типов есть, вполне можно обойтись формулой ексель, скопировав туда таблицу с этим списком. Условно вот так: =СЦЕПИТЬ(“select ”;ЕСЛИ(A1=”NUMBER”;СЦЕПИТЬ(“to_char(“;A2;”)”);СЦЕПИТЬ(“’”;A2;”’”));” c1 from dummy union all”), протянуть по всем строкам, скопировать обратно в инструмент работы с БД, убрать union в последней строке и выполнить.
Результаты анализа, полученные с использованием Deeepseek и других нейросетей, никогда не используются в исходном виде. Они в обязательном порядке валидируются, трансформируются и дополняются внутренними знаниями и экспертизой аналитика, что позволяет учесть контекст и специфику задачи. Только после этого финальные выводы применяются на практике, что гарантирует их качество, точность и соответствие поставленным целям.
Конечно, есть и подводные камни
Ещё раз: важно понимать, что, не смотря на заявления о конфиденциальности чатов с нейросетью, и то что вводимая информация и ответы сети максимум будут использоваться для обучения новых моделей в закрытую, совершенно точно не стоит закидывать в неё секретную информацию, персональные данные и т.п.
ИИ иногда «устают»: если чат с отладкой скрипта затянулся, начинает расти риск ошибки. Встроенного механизма у ИИ, основанного на больших языковых моделях, для оценки правильности своих ответов попросту нет. Поэтому имеет смысл периодически вкидывать простые проверки и критично вникать в полученный результат.
Так как в данной статьей речь идёт об упрощении работы, ИИ стоит использовать для простых атомарных задач. Сложное и комплексное решение получить с помощью ИИ можно, но это потребует довольно много времени на отладку и уточнения.
Общий вывод такой:
Классическая документация при её наличии хорошо помогает определиться с отправной точкой, системные таблицы и метаданные по объектам позволяют перевести анализ в формат рутинной задачи и автоматизировать её, связка html+js без дополнительных компиляторов и специального ПО позволяют на ходу собрать простенький интерфейс для удобного и структурированного отображения результатов такого анализа, что позволит дальше задавать уже осмысленные вопросы касательно нюансов, ответы на которые можно найти либо вернувшись к классической документации уже с пониманием, что там искать, либо у бизнес-специалистов, либо хотя бы, будет понятно, где копать.