Чи варто додати спеціальну звітність до додатку?


16

У нас є додаток, який збирає багато даних і містить звіт про нього. Перша ітерація - інтеграція Crystal Reports, яка працювала чудово. Створіть звіт у дизайнері Crystal Report, а потім імпортуйте файл RPT у додаток. Це добре працювало, але користувачам потрібен додаток для запуску звіту, а додатково користувачі не могли створити звіт. Ми додали фільтри, сортувальники та групування, щоб файл RPT був налаштований, але вони не змогли створити його з нуля.

Другим завданням було веб-рішення, що використовувало SSRS, SSAS та інструмент для створення звітів від Microsoft. Це вимагало певної роботи з базою даних та певної роботи, щоб підняти куби та працювати зі схеми OLTP, але, врешті-решт, створити звіти про зібрання було набагато простіше. Однак нам все одно доводиться створювати звіти за допомогою інструмента конструктора звітів, публікувати їх потім тощо. Ми також додавали фільтри, сортувальники та групувачі, щоб зробити їх "настроюваними".

В обох цих сценаріях ми маємо від 30 до 50 звітів із вікон, створених за час.

Зараз існує певна дискусія щодо додавання спеціальних звітів, щоб користувачі могли створювати звіт з нуля з початку. Зараз наша модель даних дуже складна і потребує хороших робочих знань про неї, щоб мати сенс. Щоб зробити це як мінімум, знадобиться велика кількість роботи, щоб перетворити модель даних у схему, яка є "більш доповідною" та легшою для розуміння. Я не думаю, що наша програма підходить для спеціальної звітності (не варто докладати зусиль).

Хтось мав успіх у наданні спеціальних звітів? Який набір інструментів ви використовували? Чи вплинуло це на успіх вашої заявки?

Відповіді:


13

Існує певна небезпека, пов'язана з тимчасовою звітністю.

  1. Звіти, як правило, поширюються в результаті комбінаторного вибуху.

  2. будь-який створений звіт має деяку вбудовану легітимність, оскільки, ну, це друкований звіт, тому інформація повинна бути дійсною.

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

  4. Справа не лише у наданні людям можливості звітування. Йдеться також про управління документами: що таке політика збереження та знищення таких документів? Які вимоги щодо подачі та зберігання?

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

У деяких випадках додавання ретельно підібраної настройки до існуючих звітів (наприклад, невелика кількість параметрів, налаштованих користувачем) може зменшити потребу в користувальницькому інструменті звітування. Також зауважте, що якщо мова йде про проведення досліджень на базі даних OLAP, потрібна більша гнучкість звітування, ніж якщо ви повідомляєте про звичайну транзакційну систему.


2
+1 для ретельного обмеження структури та обсягу. Легко перейти за борт і створити монстра.
GrandmasterB

Ця дискусія виникла в моєму кабінеті нещодавно, і я маю багато тих же почуттів, але їх важко обґрунтувати. Я не думаю, що ви десь знаєте, щоб отримати глибоку обробку цього питання? Наприклад, як виглядає добре визначення звіту та / або політика утримання?
Aaronaught

@Aaronaught: Ви починаєте з легальних мандатів на ведення діловодства і працюєте назад звідти. Наприклад, у більшості (розумних) організацій існує політика щодо збереження електронної пошти, оскільки якщо ви тримаєте їх занадто довго або недостатньо довго, компанія може зазнати юридичної відповідальності. Записи, що стосуються таких речей, як гарантії та податки, є дуже чіткими; інших видів записів, не так багато.
Роберт Харві

А як щодо частини збільшення навантаження на відміну від його зменшення - як би ви пояснили / обґрунтували це, скажімо, керівництву організацій або генеральним директором?
Aaronaught

@Aaronaught: Як ви, напевно, вже зрозуміли, спеціальні засоби звітності не є срібною кулею; вони забезпечують деяку ступінь спрощення в процесі, але люди, які не можуть думати з точки зору наборів та приєднань (тобто SQL), також, схоже, мають труднощі з використанням своїх комп'ютерів для більш звичних речей. Тож ваша підтримка просто переходить від написання спеціальних звітів (які створюють корпоративні активи, які можна багаторазово використовувати) до допомоги неофітам у написанні власних звітів про клієнтів (які є всеоднозначними зусиллями).
Роберт Харві

7

Я бачив багато дорогих невдач. Я багато років на цьому вітряному млині мав ділових партнерів. Їх труднощами було їх наполягання на тому, щоб "нетехнічні" люди могли створювати звіти. Ми побудували ряд рішень, які люди змогли навчитися та використовувати з різною мірою успіху. Як і ви, ми почали з параметризованих звітів із консервів.

Тоді ми створили спосіб збереження наборів параметрів та асоціювання їх з різними шаблонами «формату», що по суті дозволяє вам змішувати та співставляти свої консервовані звіти та публікувати їх іншим людям. Це було насправді найефективнішою річчю, яку ми коли-небудь робили, вважаючи, що це було два тижні часу розробки (поверх основної параметризованої системи звітів із консервів), і вони використовували це з певним успіхом протягом багатьох років. Це був дуже простий інтерфейс користувача, але все ж деякі користувачі не могли створити власні звіти, вони просто не могли розробити, якими мають бути критерії. Але оскільки кожен міг скласти звіт і поділитися ним з кимось іншим, він міг просто змусити колегу скласти звіт, замість того, щоб їхати до якоїсь команди МІС і стояти в черзі.

Ми продовжували намагатися покращити це, хоча і витратили сотні тисяч доларів. Crystal Decisions мав досить вигадливий набір інструментів як доповнення до їхнього корпоративного продукту із кристалів. Це була версія 9 або 10. Її давно перейменовано, перейменовано на Business Objects, але я думаю, що все ще існує версія. Це було досить дорого, і він дав вам повний веб-дизайнер для створення майже будь-якого формату звіту. Він також мав зразок програми, яка була більше майстром, який переглянув вас, змінивши існуючий звіт. Ми мали успіх із ідеєю "зберегти та поділитися параметризованим шаблоном", тому це сподобалось нам, оскільки вона зробила крок далі. Добре довга історія, ми насправді не виконали її. Я думаю, що з інструментом все в порядку, але те, що ми намагалися зробити, було просто занадто заплутаним і неправильним для роботи.

Весь цей час бізнес мусив утримувати штат розробників MIS, які велику кількість своїх спеціальних звітів. Найкраще, що вони коли-небудь виходили з наших матеріалів, - це трохи більш гнучка звітність в консервах, що найкращим чином дозволило швидше розробити новий звіт про консервування за умови, що був ще один існуючий звіт, який був дещо схожим. Якщо ви хотіли якось інтегрувати нове джерело даних, забудьте його. І здебільшого, це те, що MIS зробило для них, було інтегрувати все більше та більше джерел даних у неохайний, але дуже швидкий ринок.

Врешті вони почали активно використовувати Business Objects - настільну версію BI-інструменту. Це дозволяє інтегрувати локальні дані з даними, про які ви дізналися в онлайн-каталозі метаданих. Таким чином, ви могли робити як реальні виробничі речі для мас, так і члени та менеджери могли тримати стискання різних наборів даних, до яких їх привели дослідження. Набір навичок став ще більш рідкісним, це, звичайно, не те, що хто-небудь міг підібрати і зробити. Тим не менш, вони змогли отримати набагато більше людей, які використовують це ефективно, ніж вони могли собі дозволити найняти людей, відданих МІС. Хоча співробітники MIS ніколи не скорочувались, що дуже важливо.

Моє власне враження від цієї загальної проблеми полягає в тому, що ви повинні бути готові значно інвестувати в розвиток навичок для людей, які ви уявляєте, що користуєтеся цим інструментом, і ви повинні прийняти, що не весь ваш персонал збирається коли-небудь туди потрапити. І якщо вони не зможуть витратити пару тижнів на вивчення BI-платформи, вони ніколи не зможуть максимально використати будь-який інструмент, який ви їм надаєте. Деякі люди з будь-якої причини просто ніколи не отримують базових ідей, таких як зовнішні приєднання. Величезні класи проблемних наборів ніколи не піддаються їх вирішенню будь-яким інструментом, оскільки вони не заглиблюються в нього достатньо, щоб зрозуміти на концептуальному рівні, що вони насправді намагаються попросити зробити комп'ютер. Це не означає, що вони "не можуть" цього навчитися, просто багато з них ніколи не будуть.


5

Зараз ми стикаємося з цією ситуацією. На даний момент замість спеціального інтерфейсу звітування ми проводимо пробну версію за допомогою Excel та Power Pivot. Ми інтегрували його в панель інструментів Excel і дозволяємо користувачам імпортувати дані безпосередньо в них і створювати звіти за допомогою цього. Ми з'ясували, що багато з цих спеціальних звітів - там, де потрібно, у певний час, щоб відповісти на певне запитання.

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

До речі, якщо ви хочете поговорити про деякі деталі реалізації, дайте мені знати.


+1, офіс багато в чому є найвищою платформою для звітування
Wyatt Barnett

2

За аналогічним сценарієм проекту, яким я керую, ми запропонували замовнику додати сховище даних із рішенням OLAP. Для зменшення витрат ми вибрали PostgreSQL як базу даних DWH та Pentaho Enterprise як інструмент аналізу BI / OLAP - ми вибрали платну версію, оскільки інструмент OLAP набагато зручніший для користувачів.

Як ви вже сказали, вам потрібно зробити свій аналіз, щоб розробити модель даних, яка підходить для потреб користувачів. Від вимог до розгортання нам знадобилося три місяці, і спочатку були виправлені деякі проблеми, але врешті-решт клієнт дуже задоволений результатами. Зараз користувачі створюють власний аналіз та інколи використовують їх як звіти (експортуючи їх у PDF). Існує також функція, яка дозволяє створювати досить прості спеціальні звіти, але принаймні поки що інструменту аналізу більш ніж достатньо для їх потреб.


2

Чим ширше домен і розмір компаній, яких ви маєте як клієнтів, вони схиляються до налаштування, інтеграції даних та спеціальних звітів. Це зійде до вартості.

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

Для звітування це створює можливість стягнути плату за додаткове навчання. Спеціальна звітність може мати додаткову плату.

Ваша робота як розробника стане жорсткішою. Більшість місць, у яких я коли-небудь працював, мали програмне забезпечення сторонніх розробників. Для деяких це було легко, оскільки вони мали прості структури даних. Більші / складніші потребували спеціальної звітності, оскільки саме так вони ведуть свій бізнес. Якби вони хотіли робити те саме, що і всі інші, вони б не найняли мене. Мені довелося поставити кілька запитань DevExpress Reporting на ТА.

Це з продажу та маркетингу, щоб зрозуміти, чи є в цьому потреба. Не "Спеціальне звітування було б крутим", але "я б придбав ваше програмне забезпечення, оскільки воно має спеціальну звітність". Потрібно просто довести до відома всі необхідні технічні вкладення.


2

Моє рішення - змусити вашу програму генерувати основні електронні таблиці та дозволити користувачам грати з Access, поки вони не побачать, що хочуть.

Більш складним підходом було б написання програми доступу / vbscript для "оновлення" базових даних, щоб користувачі могли повторно використовувати там налаштування.


1

Я зробив пару за ці роки. Як ви вже говорили, з базами даних, які покладаються на певні доменні знання, це може стати дуже складним. Як такий я (або команда, в якій я був) розробляв їх, не використовуючи інструменту звітності. З ними відверто було занадто багато проблем, намагаючись вкласти в них всю необхідну логіку. Ви закінчуєте боротьбу з ними стільки, скільки вони допомагають.

Користувачам дуже подобається робити власні звіти, тому я б сказав, що це, безумовно, варто, якщо у вас є час на розробку такої системи.


1

Коротка відповідь - це може бути.

Я працював у компанії в середині 90-х, яка розробляла програмне забезпечення, яке робить саме те, про що вони просять. У нас був хороший ринок фармацевтичної галузі, де клінічні випробування означали безліч запитів і звітів - настільки, що вирізати середніх ІС-сенсів мало сенс.

Цю компанію проковтнув інший, який, в свою чергу, проковтнув інший, який не знав і не цікавився, що робити з продуктом.

Тим не менш, (оксиморонний) світ Business Intelligence частково покладається на те, що дозволяє кінцевим користувачам можливість визначати або принаймні уточнювати запити до систем даних. Існують інструменти, щоб зробити це дещо простішим для користувача. Бізнес-об’єкти (зараз частина SAP) були королем у цій царині. Потім вони придбали Crystal. Тоді SAP їх придбав. Їх поточною пропозицією в цій царині є SAP Crystal Interactive Analysis.

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


1

Я працюю в урядовій ІТ-системі, яка має спеціальні та консервовані вимоги до звітування. Крім того, користувачі хотіли спеціального рішення щодо звітування, яке відчувало себе "вбудованим" у існуючі додатки, надало можливість детального перегляду інформації запису, що стоїть за результатами звіту, і надала повну доступ до запиту до бази даних. Цільовими продуктами звіту зазвичай були лише веб-сторінка або MS Excel. Безпека хотіла, щоб звіти інтегрувалися з існуючими засобами безпеки JEE.

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

Деякі проблеми у нас були подібними, згаданими іншими:

  • Нездатність користувачів зрозуміти модель моделей - зокрема, користувачі регулярно створюють перехресні продукти через інструмент і плутаються у висновку.
  • Немає можливості відображати результати на карті, хоча значна частина даних має просторові атрибути.
  • Неможливо зробити закладку та повернутися до вибору спеціальних звітів (це був недолік в оригінальній конструкції інструменту).

Зараз ми оцінюємо Pull Reports, щоб визначити, чи може вони вирішити ці проблеми. Нам подобається, як спеціальний інтерфейс надає користувачам спрощену візуальну модель даних разом із текстовими описами таблиць та стовпців. Той факт, що вибір фільтра користувача вбудований у вихідний звіт, зменшує занепокоєння тим, що результати будуть неправильно інтерпретовані.

Що стосується того, чи все це "варте того": у нашому випадку спеціальна звітність була дешевшою та простішою в управлінні, ніж технічний персонал, який керує розповсюдженням звітів із консервів. Однак це питання є суперечливим, оскільки консервовані звіти - як із нашим інструментом власного звітування, так і з Pull Reports - зазвичай складаються поверх механізму запитів / звітів спеціального звіту. Значить, консервовані звіти - це лише спеціальні звіти з попередньо налаштованими налаштуваннями.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.