«Что Вы сможете выжать из Вашей Скалы с помощью новых технологий?» или «Почему мы выбрали в качестве инструмента построения системы корпоративной отчетности MS SQL Server Reporting Services?» — О системах планирования ресурсов предприятия Scala, iScala

	«До середины 2005 года у нас не существовало единого инструмента построения централизованной системы корпоративной отчетности. Сотрудники вынуждены были использовать отдельные отчеты, разработанные в приложениях Microsoft Access и Microsoft Excel, а также отчеты, встроенные в другие бизнес-приложения. Кроме того, в ограниченном объеме использовались отчеты, созданные в среде Crystal Reports.» Алексей Вишняков эксперт по ИТ, руководитель группы бизнес-приложений ООО «СоюзБалтКомплект» в 2005-2007 годах
Говоря об отчетах, встроенных в бизнес приложения, Алексей Вишняков прежде всего имел в виду стандартные отчеты ERP системы Скала, а также используемых на тот момент старых бухгалтерских программ.
	Не особо вдаваясь в подробности и не обсуждая преимуществ и недостатков такого подхода, замечу, что наша информационная система в настоящий момент находится в состоянии постоянного изменения и построена по принципу звезды, когда одна из программ (в нашем случае это iScala 2.2) является ядром, а остальные — программами-спутниками.
Как и любая другая ERP система, Scala имеет несколько типов вывода информации: Документы (счета-фактуры, накладные, акты, приказы и т.п.) Запросы (информация выводимая только на экран без возможности ее распечатки) Отчеты В свою очередь отчеты можно разделить на несколько уровней: Стандартные отчеты. В них информация выдается «как есть» без какой либо реальной возможности изменить внешний вид выдаваемого отчета. Все искусство получения требуемой информации в таких отчетах заключается в умении оперировать входными параметрами, накладывающими ограничения на размер выборки данных и последовательности их группировки/сортировки. Такие отчеты могут либо «подходить», либо «не подходить». Разумеется, существует и вариант «подходить частично», когда пользователь вынужден мириться с тем, что отчет выглядит не так как хотелось бы, но выдает информацию, которая пользователю необходима. Отчеты, частично настраиваемые пользователем. В Скале к таким относятся отчеты модуля «Статистика», а также встроенный генератор отчетов модуля «Главная Книга». Почему я говорю «частично»? Потому что набор данных ограничен, логика вывода уже запрограммирована в системе и пользователь не имеет полной свободы выбора данных и изменения внешнего вида отчета. Внешние генераторы отчетов, «заточенные» под систему. Обычно это отдельные продукты компании разработчика продукта, отдельных консультантов, осуществляющих внедрение или продукты третьих сторон. Эти генераторы отчетов ориентированы на конечного пользователя и/или на промежуточный слой ИТ специалистов, не имеющих доскональных знаний базы данных системы. Разумеется, в них «зашита» определенная логика и они тоже имеют определенные ограничения. «Внешние» отчеты. С помощью любой системы доступа к данным можно построить так называемые «внешние отчеты». Эти отчеты могут быть любыми. Возможность создания того или иного внешнего отчета ограничивается только наличием и качеством самих данных, однако требует от того, кто разрабатывает отчет, хорошего знания как функциональности системы, так и ее базы данных. Если взглянуть на вышеперечисленные «уровни отчетности», то можно обратить внимание на то, что условно первые 2 из них являются «внутренними», а вторые 2 — «внешними». Это означает, что для получения первых Вы обязательно должны войти в систему (а, следовательно, занять в ней рабочее место), тогда как для получения вторых Вы должны обладать необходимыми правами доступа, но в систему можете не входить, и, более того, даже не знать как выглядит в ней рабочее место. С учетом того, что рабочее место в ERP системе может стоить многие тысячи УЕ, возникает много интересных мыслей… Именно эти мысли и стали приходить нам в голову, когда мы столкнулись с проблемой острой нехватки рабочих мест в Скале (на тот момент мы имели лицензию на 30 одновременно работающих пользователей).
Решение, которое было нами принято, оказалось довольно простым и логичным: Разделение пользователей по принципу «Ввод/Получение» информации.
	Отчётность – оболочка, обволакивающая ядро системы, как атмосфера для планеты. Производителей информации (тех, кто выполняет действия по ее первичному вводу или изменению, преобразованию) существенно меньше, чем потребителей
Отчетность – вершина айсберга! Наши требования: единое место хранения легкость создания легкость распространения возможность получения отчета по подписке распределение прав доступа по группам пользователей единый механизм возможность использования с удаленных рабочих мест возможность анализа востребованности отчета возможность интеграции данных из различных источников в один отчет отчет, выполняющий действие
	«Выбирая системы разработки и распространения отчетов, мы сравнивали возможности ряда существующих систем. Окончательное решение принималось по критерию оптимальная функциональность-стоимость.» Алексей Вишняков эксперт по ИТ, руководитель группы бизнес-приложений ООО «СоюзБалтКомплект» в 2005-2007 годах
Одним из существенных факторов при выборе системы построения отчетов стало использование в нашей компании СУБД Microsoft SQL Server, т.к. на основе этого продукта работает ERP-система iScala 2.2. Алексей Вишняков проделал колоссальную работу, знакомясь и сравнивая такие системы построения отчетов, как Microsoft SQL Server 2000 Reporting Services, Business Objects Reporting Solution (Crystal Reports и Crystal Enterprise), iScala Business Intelligence Server, Active Reports.NET, средство построения отчетов IntelliVIEW и веб-платформа Synaptrics. При анализе сравнивались как возможности систем, так и стоимость внедрения и поддержки решений.
	По сумме показателей наиболее привлекательным для компании оказалось решение на основе Microsoft SQL Server 2000 Reporting Services. Следует особо подчеркнуть, что пользователям Microsoft SQL Server 2000 покупать компонент Reporting Services не требуется. Вы можете получить его бесплатно у Вашего поставщика, у которого Вы покупали лицензию на сам Microsoft SQL Server 2000. В Microsoft SQL Server 2005 этот сервис уже встроен изначально. Microsoft SQL Server Server Reporting Services удовлетворил все вышеперечисленные требования. Ниже я постараюсь привести практические примеры этого. Фактически мы явились пионерами использования новой технологии, внедрив сначала Microsoft SQL Server 2000 Reporting Services (о чем и написано на сайте Microsoft), а с выходом Microsoft SQL Server 2005 перешли на него. Продукт развивается, а наш опыт работы с этой технологией на настоящий момент приближается к 2 годам. Надеюсь, в настоящей статье Вы получите представление о том, что можно получить из Скалы с использованием этой технологии.
Итак, давайте рассмотрим каждый из пунктов наших требований, которые мы сформулировали при выборе системы для создания на её основе нашего «Центра отчетов». Единое место хранения Ну, тут и обсуждать нечего. Естественно, всё хранится в базе данных MS SQL Server. Лёгкость создания Чтобы проиллюстрировать это, обратимся к отчету о создании новых отчетов: Как видите, за последние 2 недели было создано 10 новых отчетов, т.е. в среднем по одному отчету за рабочий день. Разумеется, чтобы получить более адекватную статистику нужна большая временная выборка, я привожу пример с двухнедельной выборкой исключительно из соображений более красивой диаграммы. Кстати, желтым фоном выделены выходные дни. Лёгкость распространения Другие внешние отчеты требуют иметь на компьютере пользователя «программу-запускалку» или, как минимум просмотровщик отчетов. Т.е. если отчет сделан в Access’е, пользователь должен иметь Access, если на Crystal’е, нужны установленные компонентны Crystal. А здесь ничего дополнительного не требуется, только Internet Explorer, который по определению имеется на компьютерах пользователей, работающих под управлением ОС Windows (а эта ОС тоже по определению имеется на компьютере, раз мы ведем речь о том, что в компании используется ERP система iScala). Возможность получения отчета по подписке Сколько угодно! Чтобы проиллюстрировать это, обратимся к отчету «Контрольный журнал», который запускается автоматически в 23:30 каждый день и присылается в виде сообщения бухгалтеру, контролирующему процесс изменения картотеки запасов, покупателей, поставщиков и т.д.: Распределение прав доступа по группам пользователей Тут и комментировать нечего, просто посмотрите на картинку: То есть Вы просто складываете ярлыки на отчеты в определенные папки и даёте на эти папки права соответствующей группе. И всё! Единый механизм Говоря о едином механизме, я в первую очередь подразумеваю то, что нет разношёрстных отчетов, например, у одного пользователя отчеты написаны на Access’е, у другого — на Crystal’е, у третьего — на Delphi, у четвертого — ещё на чём-то. Таким образом, поддержка этого разношёрстного «зверинца» требует специалистов разных профилей, а компоненты, разработанные в одной среде — не могут быть использованы в другой. Возможность использования с удаленных рабочих мест Так это же «тонкий клиент»! На выходе сервера отчетности — html страница. У нас отчётами пользуются сотрудники трёх офисов, один из которых находится на расстоянии 65 км. Помимо пользователей внутри сети, отчетность можно открыть «наружу» (при решении всех необходимых вопросов, связанных с безопасностью, разумеется. Здесь может использоваться интеграция с SharePoint’ом) Возможность анализа востребованности отчета Здесь следует вернуться к вопросу единого места хранения. Ведь все отчеты и информация об их вызове хранится на SQL Server’е! И следовательно, по этой информации также можно строить отчеты, например, такие: «График количества обращений к Центру отчетности по дням»: или «Полный список отчетов по востребованности»: или «Статистика по пользователям»: или «Статистика количества папок, отчетов, ярлыков и других файлов «Центра отчетности»»: Возможность интеграции данных из различных источников в один отчет Мы используем запросы к различным базам данных на различных серверах. Кроме этого, можно обращаться к разным типам хранимых данных, так, например, телефонный справочник у нас — тоже отчет, запрашивающий информацию из учетной записи пользователя компьютерной сети. Есть отчеты, где данные запрашиваются из таблиц .dbf файлов. Отчет, выполняющий действие Эта тема тесно связана с темой единого механизма. Оказалось очень удобным не создавать отдельный интерфейс для запуска разнообразных утилит для копирования, пересылки и изменения данных, а использовать механизм отчета для запуска хранимой процедуры. Например, мы это делаем при пересылке данных на удаленный сервер (для последующего их использования в локальной программе планирования производства). Перед отправкой данных распечатывается отчет, проверяющий наличие необходимого количества пластика для изготовления заказываемых изделий. Если хотя бы для одной позиции в заказе нет необходимого количества пластика, ничего не происходит. Продавец обсуждает ситуацию с покупателем, в заказ вносятся изменения или его выполнение откладывается. Если же пластика достаточно для изготовления всего того, что заказано, внизу появляется ссылка, нажав на которую, пользователь запускает механизм инициализации передачи данных: Документы Скалы Отдельно следует сказать о печати документов в Скале. Честно говоря, это всегда было узким местом. Та технология, что используется для печати документов, даже с учетом всевозможных её модификаций, есть вещь раритетная. Повторюсь, это, как и отчетность, раньше было узким местом Скалы. Было. Но не сейчас. Технология Microsoft SQL Server 2005 Reporting Services это узкое место оставило в прошлом. Все документы нами тоже реализованы на новой технологии, причем, их вариантов мы сейчас имеем гораздо больше, чем предусмотрено в Скале стандартно, в качестве примера могу привести список подборки для нескольких заказов, что в Скале «штатно» не предусмотрено: Другие образцы отчетов и документов Вы можете посмотреть здесь. Так почему же мы приняли решение об отказе от использования стандартных отчетов и документов iScala и выбрали в качестве инструмента построения системы корпоративной отчетности MS SQL Server Reporting Services? Думаю, теперь Вы сможете сами ответить на этот вопрос «на раз, два, три». Замечу только, что раз получилось у нас, получится и у Вас. Это зависит только от Вашей воли и желания, а сколько-нибудь серьезных технических препятствий не существует. А теперь попытаемся ответить на следующий вопрос: Что Вы можете получить, заменив стандартные отчеты и документы Scala отчетами, построенными на технологии MS SQL Server Reporting Services? Экономию рабочих мест Scala за счет пользователей, которые не вводят в нее информацию, а только потребляют ее в виде отчетов, т.к. им больше не надо будет входить в Скалу и занимать в ней рабочее место. Более удобные для пользователя отчеты, которые будут выдавать именно ту информацию, которая ему нужна и именно в том виде, который необходим. В отличие от стандартных отчетов Scala Вы также сможете создавать отчеты, объединяющие данные из различных источников Удобную *единую* технологию управления созданием, размещением, распределением прав доступа, доставкой отчётов и, как следствие, отсутствие необходимости поддерживать различные технологии в случае использования отчетов, реализованных в разных системах их создания. Возможность запуска отчета по расписанию. Результат может складываться в виде «слепка» на момент запуска в отдельную папку, либо присылаться в виде сообщения в Ваш почтовый ящик. Возможность доступа к отчетам через Интранет и/или Интернет. Для просмотра отчета не требуется наличие на компьютере пользователя никаких дополнительных компонентов, только Internet Explorer Современную технологию создания отчетов, позволяющую использовать весь набор средств, таких, как условное форматирование, возможность из одного отчета «проваливаться» или, наоборот, «подниматься» на другой уровень подробности (так называемые drill down и drill up) и многое другое. Возможность использования отчетов как средства, позволяющего не только просмотреть информацию, но и запустить какой-нибудь механизм, например, инициировать процесс передачи данных в другую систему. Возможность анализа востребованности отчетов, т.е.: кто, когда, какой отчет использовал; какие отчеты используются чаще других; кто из пользователей является «чемпионом» по просмотру отчетов; кто из пользователей, напротив, добивался от отдела ИТ создания какого-то сложного отчета, но просмотрел его всего один раз. Возможность создавать документы, не предусмотренные в Скале стандартно. Алексей Васильев. Март-Апрель-Май 2007 г.