Этот текст навеян участием при внедрении системы корпоративной отчётности, данные для которой собирались в хранилище из нескольких разнородных самописных систем – от Excel и пачки DBF в папке до СУБД и какого-то подобия веб-сервисов. Заказчик выбрал подходящие инструменты класса BI, сказал какую СУБД использовать, спросил по своим подразделениям “Какие отчёты нужны?” и сказал “Вперёд!”.

Самое главное предупреждение: при внедрении системы отчётности обязательно требуйте не только полный список отчётов, но и все формуляры — их желательно получить с данными, так как пустографки не всегда могут дать полной картины трагедии. И формуляры необходимо видеть до утверждения объёма работ.

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

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

 

 

1. Соблюдение формы

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

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

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

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

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

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

2. В том числе

Если в строке требуемого отчёта есть такая штуковина “в том числе” (в середине таблицы, выше итогов), то следует начать нервничать.

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

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

Единственно верным способом решения является отказ от “в том числе” вообще. Все измерения должны быть аддитивными и (при необходимости) иерархическими. Пользователи после того же Экселя и печатных форм не имеют привычку к “drill-down”(развёртка, проваливание) – эту привычку надо прививать и разумно использовать, если средство позволяет.

Вот выходы разной степени паршивости от случая к случаю:

— отказаться от табличной формы и делать отчёт построчно/поколоночно

— под каждую такую форму вести таблицу соответствия по принципу “многие-ко-многим”

— клеить строки “в том числе” через UNION или подобную функциональность

3. Сверка

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

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

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

Доведение чисел до стопроцентного соответствия может занять много человеко-дней. А есть ли в этом сакральный смысл – ответ на этот вопрос даст менеджерский состав.

При этом всём заказчик (иногда и не осознано) может делать подмену понятий – исходный отчёт считается “правильным”, хотя, возможно, подтвердить цифры отчёта выкладками никто не в состоянии.

4. Косметика

Система отчётов охватывает несколько департаментов. В каждом департаменте есть свои “дизайнеры”. Понятное дело, что желательно использование общих подходов к оформлению: шапки, центрирование, шрифт и тому подобные штучки.

Фильтры и параметры запроса должны однообразно запрашиваться и всегда явно отражаться в самой отчётности.

Реальные проблемы могут возникнуть не совсем при просмотре отчётов, а после экспорта в Excel и попыток печати таких отчётов на принтере, или при экспорте в формат PDF. По специфике используемых средств разбиение на страницы может не совпасть с ожиданиями пользователя.

Отдельного рассмотрения заслуживает привычка экспорта в Excel проводить распределение по колонкам и столбцам “на лету”. Это означает, что незначительная передвижка элемента заголовка может вызвать перемещение определённой колонки из физического адреса K на физический адрес L.

Это значит, что пользователь не сможет хитрыми формулами и ссылками Excel “привычным методом” использовать ваш сгенерированный отчёт. А заставить средство экспортировать колонки всегда одинаково – задача сомнительная и сложная.

5. Повторения

Заказчик убеждён, что если у него есть 14 филиалов и старая отчётность выполнена в Excel с 14 вкладками по каждому филиалу плюс одна вкладка “по всем”, то и новая отчётность должна быть выполнена таким же образом.

Приходится делать одну вкладку, потом копировать вкладку 14 раз, присвоить им “правильные” имена, затем ставить на них фильтр по соответствующему филиалу.

В данном случае глубоких последствий особых нет:

— дурная привычка неправильно использовать инструмент

— минимальные изменения дизайна влекут за собой кучу человеко-минут для выравнивания всех вкладок

Правильные выходы по необходимости:

— следует делать филиал параметром отчёта и, соответственно, параметром запроса к СУБД

— следует сделать “быстрый фильтр” на экране отчёта, чтобы переключаться между филиалами

6. Справочники

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

Неправильные выходы:

— использование условий для получения названий из кодов

— превращение pivot-отчёта в обычную горизонтальную таблицу, использование условий для их заполнения

Правильные выходы:

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

Грабли могут встретиться самые разные, даже изначальная декларация намерений заказчика гармонизировать собственный аппарат НСИ может встретить серьёзные преграды. Например: “По поводу отчёта номер 35 — мы вам вчера скинули Эксель, где приводится новая группировка товаров”.

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

7. Неявная сортировка

Заказчик считает, что его способ сортировки строк в отчёте является единственно верным, а явного указания на принцип сортировки отсутствует или он технически сложно реализуемо. Предполагаю, что такая сортировка складывается или исторически (новые продукты добавляются вниз) или по приоритетам (позиции, имеющие более высокий авторитет).

Проблемы натуральной и текстовой сортировки решаются проще. Текстовая сортировка даёт последовательность  1-11-2-20-21-22-3-9. Изменяем тип на числовой или добавляем лидирующие нули.

Выходы средней паршивости:

— использование ручной сортировки в формуляре отчёта

— использование хитрых вычисляемых на лету формул

— добавление в справочник дополнительного поля “Порядок сортировки” и заставить клиента дополнительно вести его

Правильные выходы:

— соглашение о другом порядке сортировки, и крайне желательно по таким полям, которые выводятся в самом отчёте

— проведение типизации

Удивительно, но не все средства позволяют проводить сортировку по полям, отсутствующим в таблице отчёта.

Человеческий фактор сложности поиска глазами по сортированному списку – очень немаловажен. Вот попробуйте отыскать себя среди множества фамилий, отсортированных по скрытому табельному номеру – и вы почувствуете разницу – искать себя в алфавитном списке гораздо проще. Предсказуемость восприятия отчёта тоже имеет значение – существует привычка ожидать сортировку по первым колонкам отчёта.

 

8. Нулевые строки

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

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

Плохие выходы:

— хитрым способом переводить запросы на OUTER JOIN, что может быть неприемлемо на используемой платформе

— переводить pivot-таблицы в обыкновенные, заполнять показатели по условию

Выходы по принципу “наименьшее зло”:

— по расписанию генерировать нулевые строки по всем требуемым измерениям

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

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

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

 

9. Специализация

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

Есть 3 условных фазы – ETL, Семантика, Формуляр.

Есть 5 условных направлений – деньги, склад, кадры, документооборот, основные средства.

Таким образом, есть 15 вакансий. Если один специалист ввиду объективных обстоятельств (небольшой фронт работ) может справиться с несколькими направлениями – отлично. Этапы чистого ETL и Семантики вполне могут иметь более низкие трудозатраты, так как из одной области можно получить несколько отчётов различной сложности.

Совмещать разные фазы в одном лице – сложнее, на мой взгляд.

 

10. Многовкладочность

Бывает и так, что в реестре отчётов есть одна строка, а в формуляре это жестокий Эксель со множеством независимых или слабозависимых вкладок.

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

Правильные выходы:

— разделение отчёта на несколько отчётов

— отказ от вкладок с данными, которые можно получить из других вкладок

— параметризация отчёта

— оптимизация самого макета

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

 

11. Разнородность источников

Формуляр отчёта может быть совсем небольшим – всего лишь пятнадцать строк и одна колонка.

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

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

Вообще идеологически разнородность следует выводить из системы отчётности, а такую штуку как “много разных ключевых показателей на одном экране” следует делать через дашборды или KPI, то есть через соответствующий инструмент.

12. Разнородность данных

Идеологически неправильна структура, в которой перевёрнуты колонки и столбцы. Для примера можно привести таблицу, в которой есть три колонки – Показатель, Значение показателя для продукта А, Значение для продукта Б.

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

Системе в семантическом слое сложно объяснить, что колонку ЗначениеПоказателя можно и нужно складывать в разрезе Месяц, но нельзя складывать в разрезе КодПоказателя. И поэтому в отчёте легко получить “глупые” числа. Складывать же продукты А и Б можно только вручную, так как для колонок использовать функции вроде SUM – нельзя.

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

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

 

PS. Проблемы семантики или ETL здесь не рассматриваются, так как эту внутреннюю кухню мало кто видит, а заказчика интересует только пакет отчётов.

PPS. Реальные примеры отчётов и само выбранное средство сознательно выведены за рамки статьи.