[gelöst]RTC RDL und NAV7

Das Argument mit der Konkurrenz habe ich schon gehört, als MS die Outlook Synchronisation und die E-Mail-Protokollierung eingeführt hat. Aber da habe ich immer zu den Kunden gesagt: "NAV ist so offen gestaltet, dass wir auch eine Anbindung an andere Systeme programmieren können, Sie müssen es nur bezahlen". Das MS nur die Anbindung an eigene Produkte selbst integriert finde ich nachvollziehbar. Dass eine Anbindung an Konkurrenzprodukte nicht möglich ist, ist in vielen Fällen ein Gerücht. (Wenn MS für die Outlook-Synchronisation DLLs schreiben und ansprechen kann, warum sollten das andere Hersteller nicht auch können und jetzt mit den WebServices ist vieles überhaupt erst sinnvoll möglich).

Wenn die Bindung an den Programmierer bei euch durch den RTC steigt, dann macht ihr irgendwas falsch. Auch im RTC ist es nur Programmierung. Die ist genauso dokumentierbar wie vorher auch. Und wenn man vielleicht tatsächlich mal NAV im VisualStudio programmieren kann, dann werden Dokumentations- und Team-Möglichkeiten deutlich verbessert gegenüber dem heutigen Stand (ich sag nur Tschüss Object Manager, etc.).

Noch eine kurze Anmerkung zu den Neuprogrammierungen: auch ich habe mich am Anfang dabei ertappt ständig zu denken: wie kriege ich das nur genauso gelöst wie zuvor. Und das ist eben total falsch. Der RTC hat ein wesentlich besseres Bedienkonzept als der CC. Wenn man das verstanden hat und die Möglichkeiten des RTC ausnutzt, dann geht's viel lockerer von der Hand und die Kunden sind zufriedener. Ich reagiere jedenfalls inzwischen allergisch auf die Anti-RTC-Haltung. Dass die erste RTC-Version (also NAV 6) noch nicht in allen Belangen das Gelbe vom Ei ist, ist denke ich auch MS klar. Aber irgendwann muss man ja damit anfangen. Und ich persönliche halte sehr viel von der Roadmap für NAV. Das wird richtig Spaß machen, denke ich.

Nur ganz kurz noch:
Zum ersten Absatz: Ich meinte jetzt nicht so Banalitäten wie Outlook, sondern Dinge wir Sharepoint oder Azure.
Zum zweiten Absatz: Die Bindung an den Programmierer steigt nicht mit dem RTC sondern wenn er "drum rum" programmiert. Wer wartet das später?
Zum dritten Absatz: Ich hatte selbst schon mehrere Anforderungen, die ich mit dem RTC nicht mehr erfüllen kann. Aber diese hier zu beschreiben würde den Rahmen sprengen. Ich weiß natürlich, dass es umgekehrt auch Dinge gibt, die ich früher nicht machen konnte. Ganz klar.

Das letzte Wort aber hat ganz sicher der Kunde. Der sagt uns, was er es haben will. Entweder wir können es liefern oder nicht.

Macht es das teurer? Für mich kein Unterschied, ob der Kunde den Aufwand vorher für besser Software oder nachher für Fehlerbehebung bezahlt.

Das würde ja bedeuten, daß jede Lösung im Nachgang eine Fehlerbehebung benötigt. Dem ist bei weitem nicht so.

Außerdem gibt es genauso selbst in der "einfachen" IDE von NAV Programmierer, die Unfug abgeliefert haben. Das hat also rein gar nichts mit programmierenden Consultants oder beratenden Programmierern zu tun. Das ist einfach wie überall, es gibt solche und solche. Man kann auch einen gelernten Handwerker erwischen, der nur Unfug macht. Man weiß es halt vorher nicht.
Selbst Referenzen von NAV-Partnern sind fragwürdig, denn innerhalb der Firma kann die Qualität auch schon sehr unterschiedlich sein.

Ich bin kein Freund vom RTC. Ich finde die Übersichtlichkeit ist nicht wirklich da und für den Anwender sehe ich keine große Verbesserung gegenüber dem RTC. Allerdings ist die Möglichket andere Systeme anzubinden in meinen Augen schon sher viel einfacher geworden.

Ich bin aber auch der Meinung, dass mit der Einführung des RTC seitens MS erhebliche Fehler gemacht wurden. So we ich das sehe hat man es versäumt ein NAV-Framework für die Entwickler zu Verfügung zu stellen mit der Folge, dass nun jeder Entwickler einen eigen Ansatz ausdem weiten .Net-Feld verfolgt. Wünschenswert finde ich auch die Veröffentlichung von einigen Formaten oder Schnittstellen (z. B. Komprimierung der BLOB im SQL.Server, Server-RTC-Verbindung - wahrscheinlich irgendwie WCF).

Die z. T. fehlende Akzeptanz von NAV liegt mit Sicherheit auch an der fehlenden Dokumentation. Ein Howto der wesentlichen Funktionen für den User (wie z. B. von Kindermann angeboten) gehört eigentlich in die Hilfe oder auf die CD. Auch sonst ist die Auswahl an Büchern für NAV ja nicht gerade groß. Man gebe nur mal bei Amazon die Stichworte NAV, SAP, KHK, Lexware ein und erhält 58, 1676, 401 und 2648 Treffer. Hinzu kommt, dass bei NAV vieles auf Englisch ist, was der normale Anwender nur schwer versteht.

Was die Partner angeht, habe ich eine andere Meinung. Auch in anderen Bereichen gibt es viele mit schlechtem Ruf oder schlecht ausgebildet. Ich bin eher der Meinung, dass durch mehr Wissen und mehr Möglichkeiten der Kunden eine insgesamt bessere Qualität und bessere Akzeptanz entsteht. Als Kunde will ich mir ein Zusazprodukt eines Anwenders kaufen ohne auf den Partner angewiesen zu sein. Dies setzt allerdings klare Programmier-Richtlinien voraus, damit das Zusammenspiel von individuellerAnpassung und zusätzlichen Tools funktioniert, womit wir wieder beim Versäumnis seitens MS sind ein entsprechende Framework zur Verfügung gestellt zu haben. Ich glaube aber das diese extreme Partnerabhängigkeit einigen (potentiellen) Kunden nicht gefällt.

Volker

Zum ersten Absatz: Ich meinte jetzt nicht so Banalitäten wie Outlook, sondern Dinge wir Sharepoint oder Azure.

Verstehe ich nicht. Wenn du mit Sharepoint den zukünftigen "Online-Client" meinst: mit den Webservices kannst du deine Daten doch auch in einer Wiki von Wikimedia oder einem phpbb aus- und eingeben. Vorher war das nur mit komplexen Techniken (z.B. MSMQ) oder einer der Schnittstellen möglich, die aber keine Geschäftslogik geboten haben. Zu Azure: das ist doch nur eine zusätzliche Möglichkeit. Hättest du Vertrauen in MS, wenn sie sagen: also wir bieten NAV in der Cloud an, aber nicht in unserer eigenen, sondern bei Amazon?

Zum zweiten Absatz: Die Bindung an den Programmierer steigt nicht mit dem RTC sondern wenn er "drum rum" programmiert. Wer wartet das später?

Dann verstehe ich nicht, was mit drumrum gemeint ist. Ich dachte entweder an Add-Ins oder an zusätzliche Programme, die man im Visual Studio schreibt, die im Wesentlichen über WebServices kommunizieren und nur die Daten anders anzeigen/aufnehmen (z.B. für BDE etc.). Aber das wäre ja jetzt schon viel einfacher, übersichtlicher und besser wartbar möglich als früher.

Zum dritten Absatz: Ich hatte selbst schon mehrere Anforderungen, die ich mit dem RTC nicht mehr erfüllen kann. Aber diese hier zu beschreiben würde den Rahmen sprengen. Ich weiß natürlich, dass es umgekehrt auch Dinge gibt, die ich früher nicht machen konnte. Ganz klar.

Kannst du denn Add-Ins programmieren? Ist nicht böse gemeint die Frage, aber ich habe tatsächlich noch keine Anforderung, die ich nicht auch im CC hätte aufgeben müssen (mit anderen Worten: Beschränkung durch Client, früher konnte man halt auch keinen zusätzlichen PDF-Button auf die RequestForm eines Reports bekommen, im RTC hat das MS für uns erledigt).

So we ich das sehe hat man es versäumt ein NAV-Framework für die Entwickler zu Verfügung zu stellen...

Soll das nicht mit NAV 7 kommen? Ich hörte da was. Und wenn man mal guckt, was an der Architektur zwischen 6 R2 und 7 noch gemacht werden soll, macht es auch Sinn das Framework erst mit 7 auszuliefern.

Auch in anderen Bereichen gibt es viele mit schlechtem Ruf oder schlecht ausgebildet.

Stimmt.

Ich bin eher der Meinung, dass durch mehr Wissen und mehr Möglichkeiten der Kunden eine insgesamt bessere Qualität und bessere Akzeptanz entsteht. Als Kunde will ich mir ein Zusazprodukt eines Anwenders kaufen ohne auf den Partner angewiesen zu sein. Dies setzt allerdings klare Programmier-Richtlinien voraus, damit das Zusammenspiel von individuellerAnpassung und zusätzlichen Tools funktioniert...

Ich glaube nicht, daß es zu mehr Qualität führen wird. Zumindest nicht in den ersten paar Jahren. Und damit vielleicht auch nicht zu mehr Akzeptanz. Es ist doch eben genau die Gefahr, daß es Zusatztools auf .NET-Ebene geben wird, von Nicht-Partnern, die keine Ahnung von Business Logic haben und die auch nicht wissen (können), wie bestimmte Fragestellungen schon mit Boardmitteln dargestellt werden können. Ich weiß es nicht genau, aber vielleicht wird es einen Wust aus unterschiedlichsten Lösungen geben, die das gleiche Problem behandeln. Damit würde alles noch unübersichtlicher werden und die Akzeptanz eher sinken als steigen.

Ich glaube aber das diese extreme Partnerabhängigkeit einigen (potentiellen) Kunden nicht gefällt.

Das ist doch teilweise jetzt schon so.

Zuletzt geändert von HattrickHorst am 14. Februar 2012 17:15, insgesamt 1-mal geändert.

Mach doch mal einen Vorschlag, wie man die Schlechten aussortieren kann. Was sind deine Kriterien?

Ich denke da geht Microsoft den richtigen Weg mit den Zertifizierungen und der Zertifizierung von Branchenlösungen. Allerdings würde ich mir eine bessere Dokumentation seitens Microsoft wünschen.

Allerdings ist eine allgemein gültige Benutzerdokumentation schwierig, da NAV bei jedem Endanwender anders aussieht. Und da sehe ich die Partner in der Pflicht, eine Dokumentation zu erstellen die genau auf den Betrieb zugeschnitten ist. Und das wiederum möchte selten einer bezahlen.

Ich glaube aber das diese extreme Partnerabhängigkeit einigen (potentiellen) Kunden nicht gefällt.

Das ist doch teilweise jetzt schon so.

Aber wie ist es denn bei anderen. Da macht man sich vom Hersteller abhängig. Und wenn man nicht mehr zufrieden ist, muss man das ganze System tauschen. Bei Navision suche ich mir einfach einen neuen Partner. (Es sei denn ich bin mit NAVision nicht zufrieden.)

Noch in der Kürze mein Senf zum Thema Dokumentation.
Microsoft hat zu jeder Version kurze Handbücher herausgebracht.
Wenn ich mich richtig erinnere hat Natalie diese auch erst vor wenigen Tagen hier oder in einem anderen Thema verlinkt.
Ich bin ein autodidaktisch veranlagter Mensch und habe bis jetzt keine Probleme gehabt mich einem NAV-Standard-Thema nur mit diesen Büchern anzunehmen.
Es war nie nötig das Internet zu Hilfe zu ziehen. Was jetzt nicht heissen soll, dass ich davon abrate es trotzdem zu tun ;)

Auch zum Programmieren in VS mit RDLC und speziell zur Verwendung der neuen Reporttechniken von NAV gibt es inzwischen genug Material auf dem Markt um ohne wirklich große Probleme und Blog-durchforsten das ganze zu lernen.

Soll das nicht mit NAV 7 kommen? Ich hörte da was. Und wenn man mal gut, was an der Architektur zwischen 6 R2 und 7 noch gemacht werden soll, macht es auch Sinn das Framework erst mit 7 auszuliefern.

Schön wärs. Aber NAV ist nicht neu und ein solches Framework (womit arbeiten denn die NAV-Entwickler?) sollte dann doch wenigstens gleichzeitig mit einer Version auf den Markt kommen. Das neue Visual Studio kommt doch auch gleichzeitig, wenn nicht sogar etwas früher als das neue Windows 8. Das macht MS doch nicht zum Spaß und ist doch auch sinnvoll, gerade für die Partner, die diese Palttform vertreiben.

Es ist doch eben genau die Gefahr, daß es Zusatztools auf .NET-Ebene geben wird, von Nicht-Partnern, die keine Ahnung von Business Logic haben und die auch nicht wissen (können), wie bestimmte Fragestellungen schon mit Boardmitteln dargestellt werden können.

Hierzu möchte ich für alle die Zugriff haben mal auf einen Artikel von Ralf Westphal (http://www.dotnetpro.de/articles/onlinearticle3912.aspx) verweisen. Genau die estrem hohe Verflechtung von Berater und Entwickler und die extreme Fokusierung verhindert innovative Lösungen und macht abhängig. Genau definierte Schnittstellen, Programmierrichtlinien und ein einheitliches Framework aber ermöglichen die Zusatztools doch erst.

Ich denke da geht Microsoft den richtigen Weg mit den Zertifizierungen und der Zertifizierung von Branchenlösungen.

Wir sind hier in Deutschland ein bißchen zertifikatsgläubig. Zertifikate erhöhen die Verkaufschancen, sagen ber nichts über die tatsächliche Qualität aus oder wie ist das bei Biosiegel oder TÜV-geprüftem Onlineshop oder Ökotex100? Das Zertifikat sagt nur "Sollwerte erfüllt". Es sagt nicht "gute Qualität". Das die Qualität nicht zunehmen würde wenn man nicht so restriktiv wäre bezweifel ich, Beispiel Firefox. Jetz kommt natürlich der Einwand, dass man das nicht vergleichen kann. Stimmt bedingt, bei NAV wären die Vorraussetzunge besser. Hier steht immerhin eine große professionelle Firma dahinter die viel Knowhow einfließen läßt. Es geht ja auch das Gerücht, das MS Mono als .NET-Lösung unter Linux unterstützt, warum dann nicht das eigene ERP?

Volker

Hättest du Vertrauen in MS, wenn sie sagen: also wir bieten NAV in der Cloud an, aber nicht in unserer eigenen, sondern bei Amazon?

Was die Cloud betrifft, habe ich weder in M$ noch in Amazon Vertrauen, denn genau die beiden haben es bisher als einzige geschafft, Kundendaten so zu vernichten, dass sie nicht mehr herstellbar waren.

Dann verstehe ich nicht, was mit drumrum gemeint ist.

Add-Ins, nicht Add-Ons.

Kannst du denn Add-Ins programmieren? Ist nicht böse gemeint die Frage

Definitiv nein, und die meisten meiner Kollegen derzeit auch (noch) nicht. Wenn es jetzt nur einer könnte, dann hätten wir die bereits besprochene Abhängigkeit.

ich habe tatsächlich noch keine Anforderung, die ich nicht auch im CC hätte aufgeben müssen

Die Anforderung musste ich nicht aufgeben, aber die Änderung war recht aufwändig. Die Details erspare ich mir und euch, es ist zu viel.

Ich glaube aber das diese extreme Partnerabhängigkeit einigen (potentiellen) Kunden nicht gefällt.

Das ist doch teilweise jetzt schon so.

Aber wie ist es denn bei anderen. Da macht man sich vom Hersteller abhängig. Und wenn man nicht mehr zufrieden ist, muss man das ganze System tauschen. Bei Navision suche ich mir einfach einen neuen Partner. (Es sei denn ich bin mit NAVision nicht zufrieden.)

Das ist ein äußerst schwieriges Thema und mit Sicherheit nicht einfach so mal eben zu beantworten. Wieviele Endkunden sind auch nach mehreren Partnerwechseln nicht zufrieden? Das mag daran liegen, daß sie immer den falschen Partner gewählt haben oder immer die schlechten Berater innerhalb eines Partners erwischt haben oder deren Zufriedenheitsschwelle einfach viel zu hoch angesetzt ist oder sie eigentlich ein generelles Problem mit dem Produkt haben oder ... oder ... oder... Pauschal läßt sich da kein Königsweg finden. Und mal ehrlich, bevor man ein gerade eingeführtes ERP-System wieder tauscht, ist einiges an Selbsterkenntnis, Überwindung und Planung nötig. Hinzu kommen die zusätzlichen Kosten und die Notwendigkeit den operativen Betrieb des Unternehmens aufrecht zu erhalten. Das macht man also nicht mal eben.

(womit arbeiten denn die NAV-Entwickler?)

Bei MS meinst du, richtig? Das habe ich mich auch schon gefragt. Ist irgendwie etwas unlogisch bzw. zwiespältig, oder? Ich würde vermuten, daß die Architektur-Entwickler komplett von den Entwicklern der Business Logic getrennt sind. Anders ist das nicht zu erklären. Offenbart aber auch, warum einige Dinge so sind, wie sie sind. Das wäre aber ein Organisationsproblem innerhalb von MS.

Bei Navision suche ich mir einfach einen neuen Partner.

Wir hatten auch schon Kunden, die hatten vor uns schon einige Partner und danach auch noch. Bis man dann irgendwann mitbekommen hat, dass sie "endlich" oder "glücklicherweise" das Zeitliche gesegnet haben. Ich will damit sagen, es gibt nicht nur schlechte Partner, es gibt auch schlechte Kunden. Aber das steht dann wieder auf einem anderen Blatt.

Das neue Visual Studio kommt doch auch gleichzeitig, wenn nicht sogar etwas früher als das neue Windows 8. Das macht MS doch nicht zum Spaß und ist doch auch sinnvoll, gerade für die Partner, die diese Palttform vertreiben.

Naja, ich glaube nicht, daß das wirklich gekoppelt ist. Das 4er Framework wurde auch nachgeschossen, obwohl die Entwicklung lange absehbar war.

Hierzu möchte ich für alle die Zugriff haben mal auf einen Artikel von Ralf Westphal (http://www.dotnetpro.de/articles/onlinearticle3912.aspx) verweisen. Genau die estrem hohe Verflechtung von Berater und Entwickler und die extreme Fokusierung verhindert innovative Lösungen und macht abhängig. Genau definierte Schnittstellen, Programmierrichtlinien und ein einheitliches Framework aber ermöglichen die Zusatztools doch erst.

Interessante Sichtweise! Das zeigt mal wieder, man kann fast alles von mindestens zwei Seiten beleuchten.

... es gibt nicht nur schlechte Partner, es gibt auch schlechte Kunden. ...

Das Zitat des Jahres.

Es ist auch fast nicht zu stemmen, alle Mitarbeiter eines NAV-Partners innerhalb von 3 Jahren auf den auf Faktor 10 angewachsenen Wissensbedarf zu heben, was Dank entsprechender fehlender Dokumentation auch nicht autodidaktisch erreicht werden kann, und andere Ausbildungsmöglichkeiten gibt es ja auch kaum, zumindest habe ich keine entdeckt, außer den gelegentlichen Webcasts vielleicht.

Für die Navision Weiterbildung nehmen wir vorzugsweise die Kurse der Impuls Academy.

Für SQL-Server, Reporting-Service, Integration-Service, .NET, Webserviceses und C# ist Learn Dev Now eine super preiswerte Lernmethode.

Wir haben neben der Partnerlizenz auch noch eine Kundenlizenz mit aktivem BREP. Damit kann man im Customersource alle Kurse aus dem E-Learning-Katalog ohne weitere Kosten aufrufen. Da sind neben den Anwendungskursen auch die Entwicklungskurse enthalten. Ist außerdem ein guter Englisch-Kurs da alles geschriebene von einer Microsoft-Dame vorgelesen wird

Ich verstehe den anstehenden Systemsprung. 64-Bit Systeme und neue Architekturen stehen ja inzwischen bereit, aber das Ziel ist nach wie vor eine kaufmännische Anwendung. Ich komme aus dem Objektorientierten und der SQL-Server-Entwicklung, aber der Lernaufwand ist trotzdem heftig. Wir können nicht nur lernen. Irgendwann muss man ja auch mal den Kunden versorgen. Gleichzeitig müssen wir Microsoft neuerdings Mindestumsätze bringen. Da bleibt dann noch weniger Zeit für guten Service. Ist der Kunde zufrieden, dann ist das Produkt aus seiner Sicht gut. Ich würde mich freuen, wenn Microsoft den Zyklus entschleunigen und die Partner besser mitnehmen würde. Ich bin mir recht sicher, dass es langfristig erfolgreicher wäre.

eine Kundenlizenz mit aktivem BREP

Was ist das denn schon wieder?

BREP = Business Ready Enhancement Plan. Also die aktuelle Wartung für Navision. Damit hat man Zugang zum Customer Source und da stehen die Kurse zur Verfügung.

Was die Cloud betrifft, habe ich weder in M$ noch in Amazon Vertrauen, denn genau die beiden haben es bisher als einzige geschafft, Kundendaten so zu vernichten, dass sie nicht mehr herstellbar waren.

Hmmm? Belege, Link, Erklärung? Also zu Microsoft. Amazon hab ich die Belege :)

Belege, Link, Erklärung?

Reicht Sidekick als Stichwort?

Hallo Rainer,

jepp, reicht. Habs gefunden. War mir bisher nicht geläufig. Ich kannte Sidekick nicht einmal, war wohl in Europa auch eher "nebensächlich".

Hättest du Vertrauen in MS, wenn sie sagen: also wir bieten NAV in der Cloud an, aber nicht in unserer eigenen, sondern bei Amazon?

Was die Cloud betrifft, habe ich weder in M$ noch in Amazon Vertrauen, denn genau die beiden haben es bisher als einzige geschafft, Kundendaten so zu vernichten, dass sie nicht mehr herstellbar waren.

Es ging mir nicht ums Vertrauen in die Cloud. Wenn du kein Vertrauen in die Cloud hast, dann installierst du halt klassisch auf deinem eigenen Server. Da wurden sicherlich noch niemals Daten zerstört. Aber ich würde es sehr merkwürdig finden, wenn ein Hersteller einer Software sagt: ich nutze lieber die Cloud eines anderen Anbieters, als meine eigene. Insofern ist es verständlich, dass MS NAV nicht mit Amazon, Google und OpenOffice verknüpft, sondern mit eigenen Produkten. Ich weiß aber natürlich: in der Realität ist MS der einzige Hersteller, der im Wesentlichen die eigenen Produkte vernetzt.

Dann verstehe ich nicht, was mit drumrum gemeint ist.

Add-Ins, nicht Add-Ons.

Und da steigt die Abhängigkeit jetzt wo? Immer, wenn nur ein MA eine Technik beherrscht, ist eine Abhängigkeit vorhanden. Das liegt aber nicht im Einflußbereich von Softwareherstellern (vormals: Das ist aber nicht die Schuld von MS.) Es wäre dir lieber, dass ein Softwarehersteller (vormals: MS) sagt: nein, die Technik implementieren wir nicht, das kann ja gar kein Partner bedienen/programmieren? (Bitte beachten, dies ist eine Frage, keine Behauptung, deshalb das Fragezeichen.) Finde ich abstrus diesen Gedanken.

Kannst du denn Add-Ins programmieren? Ist nicht böse gemeint die Frage

Definitiv nein, und die meisten meiner Kollegen derzeit auch (noch) nicht. Wenn es jetzt nur einer könnte, dann hätten wir die bereits besprochene Abhängigkeit.

Seid ihr auch so ehrlich und sagt das euren Kunden? Ohne euch zu nahe treten zu wollen: aber ihr seid doch gar nicht für NAV 2009 gerüstet und das ist immerhin schon dreiJahre auf dem Markt und man kann sich seit vier Jahren darauf vorbereiten. Das ist fahrlässig und deshalb sollte MS strenger werden, was die Anforderungen an Partner angeht. Wer versucht in NAV 2009 ausschließlich die bekannten Techniken des CC einzusetzen, kann meiner Meinung nach gar kein gutes NAV 2009 Produkt abliefern. Es sei denn natürlich ein Kunde kommt weitestgehend mit den Standard klar und braucht nur ein paar neue Felder oder es wird der CC implementiert.

ich habe tatsächlich noch keine Anforderung, die ich nicht auch im CC hätte aufgeben müssen

Die Anforderung musste ich nicht aufgeben, aber die Änderung war recht aufwändig. Die Details erspare ich mir und euch, es ist zu viel.

Ich könnte mir vorstellen (vormals: behaupte): das liegt an eurer vernachlässigten Weiterbildung in Sachen Visual Studio, C# und Add-Ins.

Auch hier, ich möchte dir nicht zu nahe treten, aber ich finde diese Argumentationslinie ziemlich weltfremd. Wenn MS (bzw. PC&C, bzw. Navision Software A/S, bzw. NavisionDamgaard, bzw. Navsion A/S [sonst macht die Aussage gar keinen Sinn]) deine Wünsche berücksichtigt hätte, hätten wir immer noch Navision "Blau", vielleicht nichtmal das. Es gibt bei einer technischen Weiterentwicklung immer einen Zeitpunkt, wo das nur ein Mitarbeiter bedienen/programmieren kann. Aber es wäre (vormals: ist) Pflicht der Firma diese Phase so kurz wie möglich zu halten und vor allem rechtzeitig die Mitarbeiter zu schulen (das ist natürlich in der Praxis unmöglich, es gibt in der Realität so gut wie keine Partner, die die neuen Techniken verwenden). Wenn das nicht gemacht wird, kann weder der Kunde noch MS was dafür.

EDIT: Da es wohl möglich ist, Kernpunkte fehlzuinterpretieren. Dafür möchte ich mich entschuldigen. Einfügungen durch Unterstreichen gekennzeichnet. Realitätssinn geschärft.

Zuletzt geändert von Tim am 13. Februar 2012 13:09, insgesamt 1-mal geändert.

[rainergaiss]

Aber ich würde es sehr merkwürdig finden, wenn ein Hersteller einer Software sagt: ich nutze lieber die Cloud eines anderen Anbieters, als meine eigene. Insofern ist es verständlich, dass MS NAV nicht mit Amazon, Google und OpenOffice verknüpft, sondern mit eigenen Produkten.

Aus M$-Sicht hast du natürlich Recht (willst du doch hören, oder?), aber aus Anwendersicht mag es doch durchaus sinnvoll sein, ein Produkt zu haben, was unter den verschiedensten Umgebungen und Konfigurationen läuft. Im übrigen gibt es DIE Cloud sowieso nicht, heute werden auch Techniken und Lösungen als Cloud verkauft, die schon längst unter anderen Begriffen auf dem Markt waren. Das Ganze ist für mich sowieso nur ein großer Hype. Was davon übrig bleiben wird, weiß man nicht, aber ich bin sicher, dass das dann auch etwas taugt.

Das ist aber nicht die Schuld von MS.

Das war auch keine Schuldzuweisung.

Finde ich abstrus diesen Gedanken.

Ich finde es abstrus, dass du mir unterstellst, ich würde so etwas denken.

Seid ihr auch so ehrlich und sagt das euren Kunden? Ohne euch zu nahe treten zu wollen: aber ihr seid doch gar nicht für NAV 2009 gerüstet und das ist immerhin schon dreiJahre auf dem Markt und man kann sich seit vier Jahren darauf vorbereiten.

Erstens haben wir schon etliche 2009-Projekte realisiert, zweitens hat uns sogar M$ attestiert, dass wir im Größenverhältnis mehr RTC-Kompetenz haben als die meisten anderen. Bisher konnten wir mit den uns zur Verfügung stehenden Mitteln alle Anforderungen unserer Kunden erfüllen.

Kann meiner Meinung nach gar kein gutes NAV 2009 Produkt abliefern.

Was ist ein gutes NAV 2009 - Produkt?

Ich behaupte: das liegt an eurer vernachlässigten Weiterbildung in Sachen Visual Studio, C# und Add-Ins.

Die ist zwischenzeitlich in die Wege geleitet.

Auch hier, ich möchte dir nicht zu nahe treten

Und warum tust du es dann andauernd?

Wenn MS deine Wünsche berücksichtigt hätte, hätten wir immer noch Navision "Blau"

Diese Aussage ist völlig unqualifiziert. Ich ganz klar gesagt,dass es Anforderungen gibt, die sich mit dem CC ganz easy erfüllen lassen, während mit dem RTC an dieser Stelle eine komplette Neuprogrammierung erforderlich ist. Nostalgie ist nicht mein Ding.

Aber es ist Pflicht der Firma diese Phase so kurz wie möglich zu halten und vor allem rechtzeitig die Mitarbeiter zu schulen. Wenn das nicht gemacht wird, kann weder der Kunde noch MS was dafür.

Schaffst du es, ALLE Mitarbeiter sofort auf den neuesten Stand zu bringen, wenn sich die Anforderungen schnell mal fast verzehnfachen, und gleichzeitig laufende Projekte abzuarbeiten? Wir haben, nicht zuletzt durch diese Diskussion die Dringlichkeit erkannt und handeln bereits.

Zuletzt geändert von rainergaiss am 15. Februar 2012 16:14, insgesamt 1-mal geändert.

So, jetzt atmen wir alle einmal tief durch und lenken die Diskussion wieder auf die sachliche Ebene.

Sorry, aber ich fühlte mich irgendwie schon bemüßigt, noch einmal zu antworten, nachdem ich das als persönlichen Angriff empfunden hatte nachdem auf sachlicher Ebene eigentlich alles gesagt war. Da das vielleicht eine Fehlinterpretation war, habe ich die beiden letzten Beiträge noch mal geändert.

Ich habe an den Thread jetzt ein "gelöst" drangemacht und denke, dass die Diskussion, die ansonsten sehr fruchtbar war, ihr Ziel erreicht hat. Danke dafür!

Rainer