На одном из последних моих собеседований с потенциальным работодателем был задан вопрос, который стал уже вполне шаблонным, и ссылка на него есть в очень многих описаниях вакансий для программистов-разработчиков 1С. Это вопрос о СКД.
Это большой раздел знаний (квалификации) специалиста, и можно долгое время открывать что-то новое в этом инструменте. Инструмент мощный - слов нет. К сожалению... Почему "к сожалению"? А вот сейчас расскажу, как я это вижу.
Я несколько раз слышал на собеседованиях при вопросе о СКД некое пояснение, что "у нас есть отчеты на 25, 40, 60 и т.д. колонок...". И звучит это как некий предмет профессиональной гордости, в стиле "вот с какой сложной кракозяброй мы могём и должны справляться....". Сразу скажу, что пиитета к таким творениям не испытываю ни разу и от слова "совсем" (ниже напишу - почему). Далее, мне задается вопрос - "смогу ли я совершить аналогичный творческий подвиг и если <ДА>, то когда я в последний раз таковой совершил и в какой сфере (отрасли, разделе учета) это происходило?". А я с прошлого тысячелетия старался не рисовать отчетов больше, чем на 5 колонок. В этот момент у собеседующих сторон наступало непонимание.
На мой взгляд, под словом "отчет" уже давно понимается любая печатная форма. При этом активно обсуждается вопрос "КАК". Обсуждается инструмент, а в настоящее время, применительно к отчетам, инструментом служит СКД, отсюда такой интерес к нему (к СКД). И совсем редко обсуждается вопрос - "ЗАЧЕМ". А действительно, зачем нужны отчеты? Вопрос , кстати, не смешной. У печатных форм под общим названием "отчеты" задач, как минимум, две.
Первая, почти уже забытая, задача печатной формы - это её служба в качестве "твердой копии" (если кто-то еще помнит значение этого термина). Период, когда копьютеры были слабенькими, а серверов с многократным резервированием информации не было, единственным способом восстановления учета при очередном аппаратном или программном крахе был именно набор бумажных отчетов. По сути, такие отчеты фиксировали на бумаге некое состояние учета, этот ворох бумаг так и назывался - "твердая копия". С этими отчетами работа, как таковая, не предполагалась. Это был "аварийный спасательный круг", способ вернуться к какой-то отправной точке учета, а печатная форма являла собой содержимое неких регистров учета (регистров не в программистском, а в бухгалтерском понимании!) Этими "отчетами" были мемориальные или журнальные ордеры, "шахматка", оборотно-сальдовый баланс ("главная книга"), оборотно-сальдовые ведомости складов и т.п. Да, такие "твердые копии" представляли из себя вполне обширные "бумажные простыни". Я начинал свою программистскую деятельность с автоматизации бюджетного бухучета. И помню, как для разворачивания некоторых таких "отчетов" приходилось сдвигать столы - вместе. Потом по этой "простыне" ползали, как по бильярду и ставили цветные маркеры и прочие "шифровки". И как мне кажется, именно в тот момент сформировалась привычка работать с такими вот "штабными картами", на которых было так интересно раскрашивать клеточки, располагать игрушечные кораблики, танки, и еще место для чайного сервиза оставалось.
Зафиксирую сказанное. Это была неизбежная, на тот момент развития компьютерной техники, технология работы с информацией, когда маломощные вычислительные средства вынуждали сохранять рудименты и артефакты ручной технологии учета. И этим рудиментом как раз и были огромные многоколоночные и мультистрочные бумажные табулеграмы. И вынужденная работа с ними была тем еще "удовольствием".
Вторая задача отчетов, самая вроде бы, основная. Предоставить информацию, первичную или уже как-то обсчитанную, обобщенную - не суть. Такой отчет содержит некий набор показателей, выдаваемых пользователю для какого-то анализа (анализа несложного и быстрого!) и последующего принятия каких-то действий. Как правило, это действия управленческого характера. И вот тут, как мне кажется, начинается самое интересное.
Способность воспринимать информацию через любые рецепторы называют "когнитивные функции". В нашем случае речь идет сугубо о зрении человека. То есть, человек изначально ограничен своими физиологическими возможностями, если только не принимать в расчет отдельных уникумов ,которые число "Пи" до пятидесятого порядка запоминают. В Интернете масса забавных тестов на предмет когнитивных способностей человека (для поверки или тренировки). Например, сколько трехзначных цифр запомнит человек за три секунды и т.п. И вот такой обычный человек разворачивает перед собой отчет на тридцать колонок и двести (две тысячи!) строк.... И на какой по счету строке или колонке он забудет значение, указанное в первой? Какое прикладное значение имеет такой отчет, кроме впечатляющего оформления и размера?
Открывая любой отчет, человек входит в некий контекст. В этом контексте есть некая "формула" (сопоставимость, входимость) показателей. Собственно, для анализа расчетов по такой "формуле" и формируется отчет. Поэтому сложность "формулы" и количество (размер массива) показателей должен умещаться в физиологические возможности человека. В противном случае этот отчет не имеет прикладного применения или его использование автоматически переводит сотрудника в режим "ручного труда", когда он будет водить пальцем по строкам и колонкам и "довычислять то, что не доделал" компьютер. А зачем нам тогда компьютер? Если у кого-то возникнет мысль о том, что "бывают же отчеты без формулы", то есть аналогия - пищевые отходы в таком случае тоже можно назвать "салатом" по причине большого числа ингредиентов. Мешанина цифирей это не есть отчет. А у отчета обязано быть прикладное применение. Формировать кучу форм для "чисто посмотреть" занятие беспредметное и малопродуктивное и лишний расход бумаги и ресурса принтеров.
Человеку гораздо проще иметь дело с набором отчетов (справок) с несложным контекстом, простой формулой, содержащей минимальное число показателей. Такой набор будет связан между собой единым объектом (субъектом), по значению которого будет получаться весь набор отчетов.
Для примера возьмем работу с тем, что принято называть "долгами".
Самое несуразное, что здесь можно сделать - это слепить некий монстр-отчет, в котором развернуть всю историю грехопадения каждого контрагента. "Полотно" получится внушительное, раскрашенное во все цвета радуги, что говорится "шефу понравится"! А как быть с прикладным значением поданной информации? Так оно точно не стоит затраченных программистом усилий. Нет такой формы и методики работы с "долгами", как работа с массивом. Причина простая - Гражданский и Арбитражный кодексы просто не предусматривают таких процессуальных действий. А в организации есть (должно быть!) понятие контроля за общим размером задолженностей (неважно, кто должен - покупатели, поставщики, подотчетники и т.п.). И это очень несложный отчет. Допустим, формируется справка с указанием значения общей суммы задолженности (например, покупателей) на каждое первое число месяца, заодно формируется графическое представление - "кривая ростов и уменьшений" общей суммы задолженности. Такой отчет формируется моментально и так же быстро анализируется, без применения калькуляторов и таблицей Эксель. И если не брать в расчет функционал по автоматическому формированию и массовой рассылке уведомлений о наличии задолженности, то вся следующая работа по долгам производится исключительно посубъектно, применительно к каждому контрагенту. Допустим, в юридическом отделе организации работает три специалиста, каждый из которых может вести до пяти дел по принудительному взысканию (арбитраж или общая юрисдикция). Стало быть, формировать гигантский свиток из сотен или тысяч строк - нет смысла. Организацию интересуют не более пятнадцати конрагентов, до остальных сразу просто не "дойдут руки". Нужна ли многоколоночная таблица для такой ведомости даже для пятнадцати строк? Я бы сказал, что тоже не нужна. Определившись с "контингентом", по которому будет производится работа, вся следующая информация будет получаться в контексте каждого контрагента. Это будут не групповой отчет по массиву контрагентов, это будет "именная справка", вернее, набор справок. Каждая из таких справок будет иметь свой контекст формируемых показателей. Это может быть контекст дат возникновения задолженностей, контекст договоров, контекст первичных документов. Это то, что принято называть "предоставление информации в разрезе....". Специалист будет работать гораздо продуктивнее, быстро переключаясь в рамкох одного субъекта (объекта) между несколькими экранными формами (между контектстами), чем получить на экране (на бумаге) сложную сетку, по которой надо долго водить карандашом.
Можно резюмировать. Я считаю, что создавать отчеты имеет смысл в том случае, если у отчета есть прикладное прагматичное применение. Формировать отчет по принципу "нам чисто посмотреть" - непродуктивно. Ну, увидел - и? Дальше - что? Создание мега-отчетов "по заказу шефа" с техзаданием, а ля "я хочу увидет все!" - тогда мои соболезнования вам и пожелания быстрой смены такого шефа. Вот, увидел шеф перечень своих должников на двустах страницах, ужаснулся, схватился за сердце, всех обматерил и пошел коньяком лечиться? Дальше эта стопка бумаги полетела в корзину, ибо практического прикладного применения у этого "информационного комбикорма" - нет. Несуразно формировать отчеты, превышающие по своему содержимому, физиологические способности человека. Для оспаривающих предложу простой тест - сформируйте какой-нить монстр-отчет, хотя бы 500 х 40 (строк и колонок). Вдумчиво на него смотрите пять минут, а потом за те же пять минут дайте доклад по увиденному. С обязательным указанием действий, которые собираетесь предпринять по результатам информации, содержащейся в этом отчете. А вдруг, вы - гений??)
СКД это тот случай, когда возможности разработчиков на много порядков опережают потребности пользователей, повторяюсь - реальные потребности! А разработчиков поневоле тянет на творчество) Создать что-то такое-эдакое, многогранное и разноцветное - а пусть обмирают от удивления!
В огромном числе вакансий для соискателей сообщается, что одной из их рабочих нагрузок станет "разработка отчетов". Я уже описал примерный режим работы с задолженностями. Для того, чтобы появилась объективная потребность в сильном (или регулярном) изменении таких отчетов, надо чтобы изменилась сама методика работы профильных специалистов (потребителей информации отчетов), чтобы им понадобился новый "разрез предоставления информации", например. Но такого же не происходит совсем уж часто! Так от кого исходит этот "отчетный зуд"? Увы, но я часто вижу дремучую некомпетентность менеджмента, который банально не знает - какие показатели в каких случаях ему надо контролировать и, сидя в Экселе, одну за одной "рождает" таблички, в которых, по его представлению, ему сразу "станет все понятно". И с этим табличками, как со скрижалями, он отправляется к пограммистам, в ожидании от них - чуда, а те и рады стараться....
