Czy dodanie raportów Ad Hoc do aplikacji jest warte wysiłku?

Mamy aplikację, która zbiera wiele danych i ma wbudowane raporty. Pierwszą iteracją była integracja Crystal Reports, która działała dobrze. Utwórz raport w projektancie Crystal Report, a następnie zaimportuj plik RPT do aplikacji. Działało to dobrze, ale użytkownicy potrzebowali aplikacji do uruchomienia raportu, a ponadto użytkownicy nie mogli utworzyć raportu. Dodaliśmy filtry, sortery i grupy, aby plik RPT można było dostosować, ale nie można go utworzyć od zera.

Drugą interakcją było internetowe rozwiązanie wykorzystujące SSRS, SSAS i narzędzie do tworzenia raportów firmy Microsoft. Wymagało to trochę pracy z bazą danych i trochę pracy, aby uruchomić moduły ze schematu OLTP, ale w końcu znacznie łatwiej było tworzyć raporty zestawień. Nadal jednak musimy tworzyć raporty za pomocą narzędzia do tworzenia raportów, publikować, a następnie publikować itp. Dodaliśmy również filtry, sortery i narzędzia do grupowania, aby umożliwić „dostosowanie”.

W obu tych scenariuszach mamy około 30 do 50 gotowych raportów tworzonych w czasie.

Teraz trwa dyskusja na temat dodawania raportów ad hoc, aby użytkownicy mogli tworzyć raporty od zera w locie. Teraz nasz model danych jest bardzo złożony i wymaga dobrej wiedzy praktycznej, aby go zrozumieć. Wykonanie tego co najmniej wymagałoby sporo pracy, aby model danych stał się schematem, który jest „bardziej raportowalny” i łatwiejszy do zrozumienia. Nie sądzę, że nasza aplikacja nadaje się do raportowania ad hoc (nie warte wysiłku).

Czy ktoś miał jakieś sukcesy w dostarczaniu raportów ad hoc? Z jakiego zestawu narzędzi korzystałeś? Czy wpłynęło to na sukces Twojej aplikacji?

Zgłaszanie ad-hoc wiąże się z pewnymi zagrożeniami.

1. Raporty mają tendencję do rozprzestrzeniania się w wyniku eksplozji kombinatorycznej.

2. każdy tak utworzony raport ma pewną wbudowaną zasadność, ponieważ, cóż, jest to wydrukowany raport, więc informacje muszą być prawidłowe.

3. Może się wydawać, że dostarczanie raportów w ten sposób zmniejsza obciążenie związane z obsługą nowych raportów, ale w rzeczywistości zwiększa je.

4. Nie chodzi tylko o umożliwienie ludziom raportowania. Dotyczy to również zarządzania dokumentami: jakie są zasady przechowywania i niszczenia takich dokumentów? Jakie są wymagania dotyczące przechowywania i przechowywania?

Z tych wszystkich powodów uważam, że jeśli dostarczane jest niestandardowe narzędzie do raportowania, jego zakres musi być ograniczony; starannie skonstruowane, aby nie wytwarzać nadmiernych, nieuzasadnionych i nieobsługiwanych artefaktów; i poparte polityką, która wyraźnie określa, jakie rodzaje raportów można generować dynamicznie, a które raporty muszą być definiowane i formalnie tworzone.

W niektórych przypadkach dodanie starannie wybranych dostosowań do istniejących raportów (na przykład niewielkiej liczby parametrów konfigurowanych przez użytkownika) może zmniejszyć potrzebę korzystania z niestandardowego narzędzia do raportowania. Pamiętaj też, że jeśli chodzi o przeprowadzenie badań w bazie danych OLAP, potrzebna jest większa elastyczność raportowania niż w przypadku zwykłego systemu transakcyjnego.

Widziałem wiele kosztownych awarii. Przez lata miałem w tym wiatraku partnera biznesowego. Ich trudność polegała na tym, że nalegali, aby „nietechniczni” ludzie mogli tworzyć raporty. Stworzyliśmy szereg rozwiązań, których ludzie mogli się nauczyć i korzystać z różnym powodzeniem. Podobnie jak Ty, zaczęliśmy od sparametryzowanych raportów w puszkach.

Następnie stworzyliśmy sposób zapisywania zestawów parametrów i kojarzenia ich z różnymi szablonami „formatowymi”, co zasadniczo pozwala mieszać i dopasowywać raporty w puszkach oraz publikować je innym osobom. To była rzeczywiście najbardziej wydajna rzecz, jaką kiedykolwiek zrobiliśmy, biorąc pod uwagę, że był to około dwóch tygodni czasu programowania (oprócz podstawowego sparametryzowanego systemu raportów w puszkach) i używali go z powodzeniem przez lata. Był to bardzo prosty interfejs użytkownika, ale niektórzy użytkownicy nie mogli tak naprawdę tworzyć własnych raportów, po prostu nie mogli ustalić, jakie powinny być ich kryteria. Lecz odkąd każdy może zbudować raport i udostępnić go komuś innemu, może po prostu poprosić współpracownika o zgłoszenie, zamiast iść do jakiegoś zespołu MIS i stać w kolejce.

Próbowaliśmy go jednak ulepszyć i zmarnowaliśmy setki tysięcy dolarów. Firma Crystal Decisions miała ciekawy zestaw narzędzi jako dodatek do produktu dla przedsiębiorstw Crystal Reports. To była wersja 9 lub 10. Już dawno została przemianowana, przemianowana przez Business Objects, ale myślę, że wciąż istnieje jej wersja. To było dość drogie i dało ci kompletnego projektanta stron internetowych do budowania praktycznie dowolnego formatu raportu. Miał także przykładową aplikację, która była bardziej czarodziejem, który przeprowadził cię przez modyfikację istniejącego raportu. Odnieśliśmy sukces dzięki pomysłowi „Zapisz i udostępnij sparametryzowany szablon”, więc spodobało nam się to, że posunęliśmy się o krok dalej. Krótko mówiąc, tak naprawdę tego nie zrealizowaliśmy. Myślę, że to narzędzie było w porządku, ale to, co próbowaliśmy zrobić, było po prostu zbyt zmieszane i źle działało.

Przez cały ten czas firma musiała utrzymywać pracowników programistów MIS, którzy często raportowali ad hoc. Najlepsze, co kiedykolwiek wyciągnęli z naszych materiałów, to nieco bardziej elastyczne raportowanie w puszkach, co w najlepszym przypadku przyspieszyło opracowanie nowego raportu w puszce, pod warunkiem, że istnieje inny podobny raport. Jeśli chcesz jakoś zintegrować nowe źródło danych, zapomnij o tym. I przede wszystkim to, co zrobiła dla nich MIS, polegała na integracji coraz większej liczby źródeł danych w niechlujny, ale bardzo szybki sposób na wprowadzenie na rynek.

W końcu zaczęli intensywnie korzystać z Business Objects - komputerowej wersji narzędzia BI. Pozwala to zintegrować dane lokalne z danymi, o których dowiedziałeś się w internetowym katalogu metadanych. Moglibyście więc zrobić zarówno prawdziwe produkcje dla mas, jak i kwanty i menedżerowie mogliby gromadzić różne zestawy danych, do których doprowadziły ich badania. Zestaw umiejętności stał się jeszcze rzadszy, z pewnością nie było to coś, co każdy mógł po prostu zrobić. Mimo to udało im się sprawić, by znacznie więcej osób korzystało z niego efektywnie, niż mogliby sobie pozwolić na zatrudnienie jako oddani ludzie MIS. Personel MIS nigdy nie został znacznie zredukowany, co mówi.

Mam wrażenie, że ten ogólny problem polega na tym, że musisz zainwestować znaczne środki w rozwój umiejętności osób, które wyobrażasz sobie za pomocą tego narzędzia, i musisz zaakceptować fakt, że nie wszyscy Twoi pracownicy kiedykolwiek tam dotrą. A jeśli nie mogą oni spędzić kilka tygodni nauki platformę BI, będą one nigdy nie być w stanie uzyskać jak najwięcej z dowolnego narzędzia, które je dać. Niektórzy ludzie, z jakiegokolwiek powodu, nigdy nie wydają się mieć podstawowych pomysłów, takich jak połączenia zewnętrzne. Ogromne klasy zestawów problemów nigdy nie będą w stanie rozwiązać za pomocą jakiegokolwiek narzędzia, ponieważ nie dostają się wystarczająco daleko, aby zrozumieć na poziomie koncepcyjnym, co tak naprawdę próbują poprosić komputer. Nie oznacza to, że „nie mogą” się tego nauczyć, tyle że wielu z nich nigdy się nie dowie.

Obecnie mamy do czynienia z tą sytuacją. W tym momencie zamiast interfejsu raportowania ad-hoc przeprowadzamy próbę z wykorzystaniem Excela i Power Pivot. Zintegrowaliśmy go z paskiem narzędzi programu Excel i umożliwiamy użytkownikom importowanie danych bezpośrednio do i tworzenie raportów przy użyciu tego. Okazało się, że w wielu z tych raportów ad hoc zdarza się, że w razie potrzeby w określonym czasie odpowiada na konkretne pytanie.

W tym momencie działa dobrze, wymagane było trochę treningu i trzymania za rękę, ale jest to wykorzystywane przez dział finansowy, więc oczywiście najlepiej czują się w programie Excel.

Przy okazji, jeśli chcesz porozmawiać o niektórych szczegółach implementacji, daj mi znać.

W podobnym scenariuszu w zarządzanym przez nas projekcie zaproponowaliśmy klientowi dodanie magazynu danych z rozwiązaniem OLAP na wierzchu. Aby obniżyć koszty, wybraliśmy PostgreSQL jako bazę danych DWH, a Pentaho Enterprise jako narzędzie analityczne BI / OLAP - wybraliśmy wersję płatną, ponieważ narzędzie OLAP jest znacznie bardziej przyjazne dla użytkownika.

Dokładnie tak, jak powiedziałeś, musisz przeprowadzić analizę, aby zaprojektować model danych, który będzie odpowiedni dla potrzeb użytkowników. Zajęło nam to trzy miesiące od wymagań do wdrożenia, i na początku było kilka usterek do naprawienia, ale ostatecznie klient jest bardzo zadowolony z rezultatów. Użytkownicy tworzą teraz własne analizy i czasami wykorzystują je jako raporty (eksportując je do pliku PDF). Istnieje również funkcja, która pozwala tworzyć wystarczająco proste raporty ad-hoc, ale przynajmniej na razie narzędzie analityczne jest więcej niż wystarczające dla ich potrzeb.

Im szersza domena i rozmiar firm, które masz jako klienci, skłaniają się ku dostosowaniom, integracji danych i raportowaniu ad hoc. Sprowadzi się to do kosztów.

Większość firm odradza dostosowywanie, więc pobierają wysokie opłaty za tę usługę. Programiści postrzegają to jako niepotrzebne, ale gdy można zaoszczędzić czas i ułatwić kilkaset użytkownikom, oszczędności sumują się.

W przypadku raportów stwarza to możliwość pobierania opłat za dodatkowe szkolenie. Raportowanie ad hoc może mieć dodatkową opłatę.

Twoja praca jako programisty będzie trudniejsza. Większość miejsc, w których kiedykolwiek pracowałem, które miały oprogramowanie innych firm, miały niestandardowe raporty. Dla niektórych było to łatwe, ponieważ mieli proste struktury danych. Większe / bardziej złożone wymagały niestandardowego raportowania, ponieważ w taki sposób prowadzą swoją działalność. Gdyby chcieli robić to samo co wszyscy, nie zatrudnialiby mnie. Musiałem zadać kilka pytań związanych z raportowaniem DevExpress na temat SO.

To, czy zajdzie taka potrzeba, zależy od sprzedaży i marketingu. Nie „raportowanie ad hoc byłoby fajne”, ale „kupiłbym twoje oprogramowanie, ponieważ ma raportowanie ad hoc”. Musisz tylko uświadomić wszystkim o wymaganej inwestycji technicznej.

Moim rozwiązaniem jest, aby Twoja aplikacja generowała podstawowe arkusze kalkulacyjne i pozwalała użytkownikom grać z Access, dopóki nie zobaczą, czego chcą.

Bardziej wyrafinowanym podejściem byłoby napisanie programu dostępowego / vbscript, aby „odświeżyć” dane podstawowe, umożliwiając użytkownikom ponowne wykorzystanie dostosowań.

Zrobiłem kilka lat. Jak już wspomniałeś, w bazach danych opartych na pewnej wiedzy domenowej może to być bardzo trudne. Jako taki ja (lub zespół, w którym pracowałem) opracowałem je bez korzystania z narzędzia raportowania. Szczerze mówiąc, mieli za dużo kłopotów z pracą, próbując wprowadzić w nich całą niezbędną logikę. W końcu walczysz z nimi tak bardzo, jak pomagają.

Użytkownicy naprawdę lubią tworzyć własne raporty, więc powiedziałbym, że zdecydowanie warto było, jeśli masz czas na opracowanie takiego systemu.

Krótka odpowiedź brzmi: może być.

W połowie lat 90. pracowałem dla firmy, która stworzyła oprogramowanie, które robi dokładnie to, o co prosi. Mieliśmy dobry rynek w branży farmaceutycznej, gdzie badania kliniczne wymagały wielu zapytań i raportów - do tego stopnia, że ​​wykluczenie środkowych mężczyzn z IS miało sens.

Ta firma została połknięta przez inną, która z kolei została połknięta przez inną, która nie wiedziała ani nie obchodziła, co zrobić z produktem.

Mimo to (oksymoroniczny) świat Business Intelligence częściowo polega na umożliwieniu użytkownikom końcowym definiowania lub przynajmniej udoskonalania zapytań do systemów danych. Istnieją narzędzia ułatwiające to użytkownikowi. Business Objects (obecnie część SAP) był królem w tej dziedzinie. Potem kupili Crystal. Następnie SAP je kupił. Ich obecna oferta w tej dziedzinie to SAP Crystal Interactive Analysis.

To duży wysiłek - narzędzia zwykle wymagają dużo pracy przy konfigurowaniu metadanych i tym podobne. To naprawdę pytanie, czy Twoi użytkownicy NAPRAWDĘ tego potrzebują - jaki będzie ROI?

Pracuję dla rządowego systemu informatycznego, który ma wymagania raportowania ad hoc i konserwy. Dodatkowo użytkownicy chcieli rozwiązania raportowania ad hoc, które wydawałoby się „osadzone” w istniejących aplikacjach, zapewniło możliwości szczegółowego przeglądania informacji o wynikach raportu i zapewniło pełne dostęp do zapytania do bazy danych. Docelowymi produktami raportów były zazwyczaj tylko strona internetowa lub MS Excel. Bezpieczeństwo chciało zintegrować raporty z istniejącymi kontrolami bezpieczeństwa JEE.

Po tym, jak nie znaleźliśmy istniejącego rozwiązania na rynku, ostatecznie uruchomiliśmy nasze własne narzędzie do raportowania ad hoc, z którego korzystamy od kilku lat. Jest to jednak kosztowne w utrzymaniu, a jego ulepszenie jest niedźwiedziem, ponieważ nie zostało zaprojektowane tak, aby wykraczało poza skromne łączenie, filtrowanie i sortowanie przypadków użycia.

Niektóre problemy mieliśmy podobne do wspomnianych przez innych:

• Niemożność zrozumienia modelu danych przez użytkowników - w szczególności użytkownicy regularnie tworzą produkty łączenia krzyżowego za pomocą narzędzia i są zdezorientowani wynikami.
• Brak możliwości wyświetlania wyników na mapie, mimo że większość danych ma atrybuty przestrzenne.
• Niemożność dodania zakładek i powrotu do wybranych raportów ad hoc (była to wada oryginalnego projektu narzędzia).

Obecnie analizujemy raporty Pull, aby ustalić, czy może rozwiązać te problemy. Podoba nam się, jak interfejs ad hoc zapewnia użytkownikom uproszczony wygląd modelu danych wraz z tekstowymi opisami tabel i kolumn. Fakt, że wybory filtrów użytkownika są osadzone w danych wyjściowych raportu, zmniejsza obawy, że wyniki będą niewłaściwie interpretowane.

Jeśli chodzi o to, czy wszystko to było „tego warte”: w naszym przypadku raportowanie ad hoc było tańsze i łatwiejsze do zarządzania niż zlecenie personelowi technicznemu zarządzania mnożeniem raportów w puszkach. Pytanie jest jednak nieco dyskusyjne, ponieważ raporty standardowe - zarówno za pomocą naszego wewnętrznego narzędzia raportowania, jak i za pomocą raportów Pull - są zwykle budowane na silniku zapytania / raportowania narzędzia raportowania ad hoc. Oznacza to, że raporty w puszce są tylko raportami ad hoc ze wstępnie skonfigurowanymi ustawieniami.