Wenn Navision nicht genug ist...Eigenlösung vs. QlikView

Hallo alle zusammen!

Ich bin in meinem Bereich gerade an die Grenzen von Navision bzw. an die Grenzen eines seiner Module gestossen...
Jetzt sehe ich mir gerade die Alternativen an:
Welche Erfahrungen habt ihr gemacht im Vergleich zwischen Programmierung/Eigene Lösung in Navision und dem Programm QlikView?
Bisher habe ich die Argumente aufgeschnappt, dass durch eine eigene programmierte Lösung beim Wechsel auf die neue NAV-Version ein Mehraufwand entstehen würde. QlikView dagegen sei einfach aufgebaut und leicht zu bedienen, von der Anwender- als auch von der Erstellerseite aus gesehen. Beides ist kostenintensiv...

Welche Erfahrungen habt ihr gemacht?

Grüße

Hallo,

an welche Grenzen bist du denn gestoßen, vielleicht kann man dir da ja mit wenig Aufwand weiterhelfen.

Zu QlikView wirst du hier im Forum wahrscheinlich nur wenig Informationen bekommen.

Gruß, Fiddi

Nach der Präsentation auf der Homepage verspricht QlikView mehr oder minder das, was auch die Cubeware basierten Lösungen versprechen, die ich mir mal angesehen habe.

Da stellten sich die üblichen Fragen wie der nach Support, nach der Erweiterbarkeit und Notwendigkeit, alle Daten schnell in verschiedener Tiefe und Zusammenstellung (und bunter Darstellung für die GF sowie dem Export in verschiedene Formate) parat haben zu müssen.

Falls die Aufbereitung der Geschäftszahlen mit üblichen NAV-Reports ausreicht, kann man sicher eine Menge Geld sparen. Sonst hilft wohl nur der Kauf.

Mit seinen BI-Tools kann z.B. Sharepoint auch vieles, was QlikView bietet.

Aber es ist halt wirklich die Frage, was man benötigt.

Egal welches Tool man verwendet, man wird immer für neue Berichte Zeit aufwenden, das darf man nie vergessen. (Auch das ist meistens kostenintensiv, vor allem wenn man Cubes verwenden will) Das sollte man in seine Berechnungen auch miteinbeziehen.

Hallo,

an welche Grenzen bist du denn gestoßen, vielleicht kann man dir da ja mit wenig Aufwand weiterhelfen.

Zu QlikView wirst du hier im Forum wahrscheinlich nur wenig Informationen bekommen.

Gruß, Fiddi

Hallo und danke für die schnellen Antworten. Hier kurz und knackig, auf welche Probleme ich gestossen bin (verallgemeinert):
viewtopic.php?f=7&t=6261&p=28895&hilit=liquidit%C3%A4t#p28895

lt. unserem Support ist eine Plan-/Ist- Darstellung im Liquiditätsmodul nicht möglich!

Kann mich da dunkel an eine Jet- Reports Präsentation erinnern, wo das auch ein leichtes Thema war. Wen Ihr eine gewartete NAV- Installation habt, dann dürftest du Jet- Reports- Essentials kostenlos nutzen (evtl. technisch auf NAV- 2009 CC bringen)

Gruß, Fiddi

Hallo alle zusammen!

Ich bin in meinem Bereich gerade an die Grenzen von Navision bzw. an die Grenzen eines seiner Module gestossen...
Jetzt sehe ich mir gerade die Alternativen an:
Welche Erfahrungen habt ihr gemacht im Vergleich zwischen Programmierung/Eigene Lösung in Navision und dem Programm QlikView?
Bisher habe ich die Argumente aufgeschnappt, dass durch eine eigene programmierte Lösung beim Wechsel auf die neue NAV-Version ein Mehraufwand entstehen würde. QlikView dagegen sei einfach aufgebaut und leicht zu bedienen, von der Anwender- als auch von der Erstellerseite aus gesehen. Beides ist kostenintensiv...

Welche Erfahrungen habt ihr gemacht?

Grüße

Man sollte nicht Äpfel mit Birnen vergleichen!

Navision = ERP-System, genauso wie z.B. SAP R/3, Oracle E-Business Suite, Axapta, Semiramis, Bison Greenax, ProAlpha, Sage Bäurer etc. etc.
QlickView = BI-System, genauso wie z.B. CubeWare, IBM-Cognos, SAP Business Objects, Microsoft SSAS(OLAP-Cube)+SSIS(DWH)+SSRS(Reporting) => alle 3 sind SQL-Server basiert.

ERP = daily business, transaktionsorientiert, Stammdaten, tägliche Bewegungen, 50% Lese- und 50% Schreibzugriffe.
BI = Vorschau + Vorplanung auf Monats-, Quartals-, Jahresbasis mit dynamischen Kennzahlen, Rückschau anhand von statischen Kennzahlen, meistens nur Lesezugriff.
BI kann auch eingesetzt werden, um Datenqualität von historisch eingerichteten bzw. angesammelten Stamm- bzw. Bewegungsdaten zu prüfen.

Du musst dich fragen: wie komplex sind die Anforderungen an NAV, welche du individual programmieren musst?
Sind mehrere 100 Tabellen über Relations zu verknüpfen und auszuwerten?

=> dann könntest du das ganze im SQL-Server Management Studio flach per langem TSQL-Code oder sogar noch komplexer per Stored Procedures ausprogrammieren (reines RDBMS-Knowhow) oder aber per BI grafisch modellieren und später mit einem OLAP-Cube weiterverarbeiten und Beziehungen herausfinden.

Irgendwann wird der ellenlange TSQL-Code (bzw. C/AL-Code in NAV) unleserlich, schwer wartbar, fehleranfällig.
Dagegen wirkt ein grafisches Modell übersichtlicher, aufgeräumter und erfordert weniger Programmierknowhow denn Architekturtalent.

So steht es im Internet geschrieben, wenn man ERP-System samt RDBMS dahinter einem BI-System samt Multi Dim DB gegenüberstellt.

Ich glaube, hier geht es eher darum, ob man eine teure Kiste Äpfel kauft, oder auch von einer Birne, die man selbst züchtet, satt wird.

Wenn es ausschließlich um einen Vergleich Plan/ist handelt, kann man das wahrscheinlich selbst hinkriegen, mit einem Excelexport oder Jetreports auch optisch ein wenig aufbereitet. Fehlende Verknüpfungen kann man möglicherweise so über Dimensionen oder ein paar neue Felder lösen, dass der insgesamte Aufwand bei Updates überschaubar sein sollte. Und man ist - was man nicht unterschätzen sollte - in seinem bekannten Umfeld.

Eine BI-Lösung muss man kaufen, lizensieren, und ein eigener kleiner Server für dessen Datenbank muss wahrscheinlich auch noch her. Und um so chice Sachen wie in den Präsentationen der Hersteller selbst zu erstellen, braucht man auch nach den Schulungen zumindest die Hotline, eher aber einen Consultant für eine Woche. Und da muss man sich genauso reinfuchsen wie in alles andere auch. Ganz egal, wie einfach und schnell das alles angeblich geht.

Das ist halt alles je nach Anspruch und finanziellen Möglichkeiten. Eine BI-Lösung bietet natürlich viel mehr Möglichkeiten und ist, wenn einmal erstellt, bedeutend flexibler als etwas mit Bordmitteln selbst gebautes.

Also was im Einzelfall benötigt wird kann hier wohl keiner festlegen, aber man sollte doch die vorhandenen (oder zukünftig vorhandenen) Teile nicht unberücksichtigt lassen, besonders dann wenn der Schulungsaufwand sehr nach unten geht (z. b. Excel, Sharepoint ab 2013, evtl. auch Access).

Bei dem Gedanken an Access als Lösung habe ich dann doch etwas geschluckt, weil man damit wie wohl die meisten anderen Lösungen auch direkt auf die SQL-DB zugreifen wird. Access könnten nun dazu verleiten eigene Masken zu erstellen und nicht nur Daten zu lesen, sondern auch schreiben/ändern und das ganze unter Umgehung der NAV-Logik und Rechte.

Bei all diesen Lösungen sei daher jedem Admin und Partner noch einmal Jörgs Artikel (http://dynamicsuser.net/blogs/stryk/archive/2010/02/16/extended-database-hardening-nav-sql.aspx) ans Herz gelegt. Nicht nur aus Gründen des Manipulationsschutzes, sondern auch aus Gründen des Datenschutzes (Bankdaten, Einkaufspreise, Personaldaten, ...)


Volker

Hallo vsnase, ich befasse mich seit ca. 7 Jahren mit QlikView und wir arbeiten selber mit QlikVIew und NAV (RTC). Wir sind Implementierungspartner für beide Produkte.
Grundsätzlich sind die beiden Produkte ja mit ganz anderen Zielsetzungen und Aufgaben zu verbinden, aber wie wahr wie wahr, jedes ERP behauptet BI zu können.
Realistisch betrachtet kann die BI-Funktionalität von NAV oder jedem anderen ERP gegenüber einem QlikView nur als rudimentär bezeichnet werden. Die Möglichkeiten die QlikView hier bietet, gehen enorm weit über die eines NAV oder ERP hinaus.
Da QlikView auf der In-Memory-Technologie aufsetzt und somit das aufwändige und IT-getriebene Erstellen von Cubes komplett entfällt, ist man mit QlikView viel schneller beim Erstellen von Analysen und auch viel schneller im Antwortzeitverhalten. Ab 10 Sekunden Antwortzeit sprechen wir bei QlikView von schlechter Performance.
Ich kann Ihnen gerne umfassende Infos über QlikView geben, es Ihnen an Hand diverser Beispiele und unseres NAV-Templates zeigen und wahrscheinlich alle Fragen dazu beantworten.
Wenn Sie also mehr Infos haben wollen, einfach fragen!

Man sollte nicht Äpfel mit Birnen vergleichen!

Navision = ERP-System, genauso wie z.B. SAP R/3, Oracle E-Business Suite, Axapta, Semiramis, Bison Greenax, ProAlpha, Sage Bäurer etc. etc.
QlickView = BI-System, genauso wie z.B. CubeWare, IBM-Cognos, SAP Business Objects, Microsoft SSAS(OLAP-Cube)+SSIS(DWH)+SSRS(Reporting) => alle 3 sind SQL-Server basiert.

ERP = daily business, transaktionsorientiert, Stammdaten, tägliche Bewegungen, 50% Lese- und 50% Schreibzugriffe.
BI = Vorschau + Vorplanung auf Monats-, Quartals-, Jahresbasis mit dynamischen Kennzahlen, Rückschau anhand von statischen Kennzahlen, meistens nur Lesezugriff.

Genau das habe ich auch gedacht. Ob die Prozentzahlen jetzt stimmen oder nicht, ist eigentlich völlig egal. Es sind zwei unterschiedliche Systeme mit zwei unterschiedlichen Intentionen. Das sollte man sich zuerst klarmachen.

BI kann auch eingesetzt werden, um Datenqualität von historisch eingerichteten bzw. angesammelten Stamm- bzw. Bewegungsdaten zu prüfen.

Ich behaupte sogar, in einem gut organisierten BI-Projekt sollte dieser Teil zwingend eingeplant werden. Jedes ERP-System hat eine gewisse Rate an schlechter Datenqualität. Bei der Implementierung eines BI-Systems sollten gewisse Kennzahlen zu genau dieser Rate ermittelt werden und dann entschieden werden, ob und welche Prozeßoptimierung man durchführen kann, um die Datenqualität dauerhaft zu verbessern.

Hallo zusammen!
Ich stosse das Thema jetzt doch noch mal in eine andere Richtung an, denn gekauft ist gekauft und die Realisierung der Liquiditätsplanung muss bei mir in NAV geschehen.

Insgesamt bauen wir derzeit unser ERP kontinuierlich aus, um unter Anderem unsere Analyse- und Berichtsfähigkeiten zu verbessern. Dabei stößt man jedoch ab und an auch an die Grenzen der Standardlösungen.
Wir haben bereits das Modul ‚Liquidität‘ erstanden. Zu unserem Bedauern ist dieses Standardmodul jedoch nicht ausreichend für unsere Zwecke geeignet.

-Was wir speziell in diesem Bereich benötigen würden, wäre ein mehr dynamisch agierendes Liquiditätsmodul.
-Es sollte vor allem zu einer Plan/ Ist – Darstellung fähig sein, ähnlich wie es beispielsweise die Anwendung ‚Kostenartenbudgets‘ bereits vermag.
-Die Fortschreibung einzelner Salden innerhalb des Kontenschemas sollte möglich sein.
Wir wollen die eigene Programmierung umgehen und suchen daher eine bereits ausgearbeitete Lösung.

Eine Lösung per Suche im Internet bzw. einen Anbieter einer solchen Lösung kann ich nicht finden. Es muss doch bereits Anderen auch aufgefallen sein, dass das angebotene Standardmodul 'Liquidität' nicht ausreichend ist.

Könnt Ihr mir vielleicht hierbei weiterhelfen?

Grundsätzlich würde ich sagen, wenn es nur um die Darstellung einer bestimmten Fragestellung geht, dann braucht man kein BI-System. Da steht der Aufwand (Zeit, Kosten, etc.) einfach in keinem Verhältnis zum anschließenden Nutzen.

Wenn man allerdings etwas gedanklich abstrahieren kann und evtl. auch schon eine strategische Vorstellung von zukünftigen Fragestellungen hat, dann würde ich zumindest über ein BI-System nachdenken, besonders wenn dafür Informationen aus unterschiedlichen Datenquellen abgegriffen werden müssen.

Hallo zusammen!
Ich stosse das Thema jetzt doch noch mal in eine andere Richtung an, denn gekauft ist gekauft und die Realisierung der Liquiditätsplanung muss bei mir in NAV geschehen.

Insgesamt bauen wir derzeit unser ERP kontinuierlich aus, um unter Anderem unsere Analyse- und Berichtsfähigkeiten zu verbessern. Dabei stößt man jedoch ab und an auch an die Grenzen der Standardlösungen.
Wir haben bereits das Modul ‚Liquidität‘ erstanden. Zu unserem Bedauern ist dieses Standardmodul jedoch nicht ausreichend für unsere Zwecke geeignet.

-Was wir speziell in diesem Bereich benötigen würden, wäre ein mehr dynamisch agierendes Liquiditätsmodul.
-Es sollte vor allem zu einer Plan/ Ist – Darstellung fähig sein, ähnlich wie es beispielsweise die Anwendung ‚Kostenartenbudgets‘ bereits vermag.
-Die Fortschreibung einzelner Salden innerhalb des Kontenschemas sollte möglich sein.
Wir wollen die eigene Programmierung umgehen und suchen daher eine bereits ausgearbeitete Lösung.

Eine Lösung per Suche im Internet bzw. einen Anbieter einer solchen Lösung kann ich nicht finden. Es muss doch bereits Anderen auch aufgefallen sein, dass das angebotene Standardmodul 'Liquidität' nicht ausreichend ist.

Könnt Ihr mir vielleicht hierbei weiterhelfen?

Nicht falsch verstehen, aber seit mindestens 4.03 weiss jeder NAV-Partner, dass das Liq.Modul gelinde ausgedrückt "wenig tauglich" ist (böse Zungen würden einfach "Schrott" sagen)
Man hat euch etwas verkauft, von dem man wusste, dass es nicht rund läuft.
Ihr habt 3 Optionen:
(1) irgend ein Addon, welches auf dem Liq.Modul aufsetzt (was soll dieses kosten dürfen, 1'000, 10'000 €?)
(2) selber programmieren um das Liq.Modul herum
(3) Aussserplanmässige Sonder-AfA in höhe der AoHK des Liq.Moduls und ein BI-System anschaffen (JetReports ist sogar kostenlos, wenn man NAV 2009 hat).

Vielen Dank für deine ehrliche Meinung zu diesem Thema!

Nicht falsch verstehen, aber seit mindestens 4.03 weiss jeder NAV-Partner, dass das Liq.Modul gelinde ausgedrückt "wenig tauglich" ist (böse Zungen würden einfach "Schrott" sagen)
Man hat euch etwas verkauft, von dem man wusste, dass es nicht rund läuft.
Ihr habt 3 Optionen:
(1) irgend ein Addon, welches auf dem Liq.Modul aufsetzt (was soll dieses kosten dürfen, 1'000, 10'000 €?)
(2) selber programmieren um das Liq.Modul herum
(3) Aussserplanmässige Sonder-AfA in höhe der AoHK des Liq.Moduls und ein BI-System anschaffen (JetReports ist sogar kostenlos, wenn man NAV 2009 hat).

Zu deinen 3 Optionen:
(1)In welcher Richtung sollte ich denn nach einem solchen Add-On suchen bzw. welche Anbieter könnten mir da weiterhelfen? Denn um ehrlich zu sein scheint mir eine Lösung/ Fortentwicklung dieses Moduls seitens Microsoft Partner aber auch seitens Microsoft nur selten vorhanden bzw. gar nicht erst im Fokus des Geplanten!
(2) Die eigene Programmierung erscheint verführerisch als die "schnellste" Lösung, jedoch meinte ich zu wissen das bei Eigenanfertigungen der Schritt hin zu einer höheren Version von NAV zu Mehraufwand und -kosten führen würde?!


Danke für eure rege Teilnahme an dem Diskussionsthema!
Gruß

[Datenkultur]

(1)In welcher Richtung sollte ich denn nach einem solchen Add-On suchen bzw. welche Anbieter könnten mir da weiterhelfen?

Hallo marcege,

es gibt eine sehr flexible Lösung für NAV-Planung im allgemeinen. Das funktioniert auch mit der Liquiditätsplanung.

Eine kleine Übersicht findest Du in dem Post Liquidität jederzeit im Blick

Es gibt auch ein NAV-Modul mit dem man den real erfolgten Zahlungsfluss auf die zugehörigen Sachkonten zuordnen kann. Damit ist dann auch ein Soll/Ist-Vergleich für den Zahlungsfluss möglich.

Gruß

Andreas

Zuletzt geändert von Datenkultur am 5. April 2020 16:36, insgesamt 2-mal geändert.

evtl. gibts hier noch weitere Infos.

Gruß, Fiddi