Unfairer Service Partner

[SPLH]

Hi,

Unser Sage Support Partner macht uns das Leben aktuell extrem schwer. Es geht um Zusatzmodule welche mit der 9.0.7.1 jetzt nicht mehr funktionieren.
Ein Zusatzmodul haben selbst entwickelt und haben hierfür die MDA. Das ersetzen der Add-ins im Modul hat keine 2 Minuten gedauert. Das selbe ist hier mit den Zusatzmodulen der Fall.

Unser Sage Support Partner hält uns nun schon seit über 2 Wochen hin und wir haben immer noch kein Angebot. Beim letzten Request für ein winzige 1-zeilige Codeänderung wurde uns nach Prüfung ein 4 stelliger Betrag genannt da wir ohne die Änderung nicht mehr arbeiten konnten. Ich habe zufällig die MDA bei uns gefunden und es dann binnen 60 Sekunden selbst gemacht. Dadrüber waren die natürlich überhaupt nicht happy. Ich gehe mal davon aus das jetzt halt die Rache dafür kommt. Einige unserer Mitarbeiter haben Urlaub beantragt da das Arbeiten mit Sage aktuell unerträglich ist.

Ich verstehe das der Code deren Eigentum ist, aber ich hatte heute bereits ein Termin mit unserem Anwalt da deren Verhalten einfach unfair und nicht akzeptabel ist. Außerdem haben wir keinerlei Möglichkeit zu prüfen ob deren Code überhaupt richtig läuft. Ein anderes Zusatzmodul welche die verwalten hatte Jahrelang einen Fehler drin. Hätten wir das Zusatzmodul überprüfen können wäre uns das damals schon aufgefallen und dank dem Fehler waren Jahrelang die Bilanzen falsch. Das kann doch nicht sein das ein Sage Partner so sein Geld verdient? Immerhin zahlen wir Monatlich unsere Servicevertragsgebühren und sollen jetzt noch einmal über €100 extra im Monat zahlen weil das neue Sage wohl komplexer ist...

Habt Ihr solch eine Situation schon einmal gehabt? Wie würdet Ihr damit vorgehen? Der Anwalt will sofort Klage einreichen auf Übergabe der MDA sowie Schadensersatzansprüche, aber Anwälte wollen immer irgendetwas versuchen was nicht umbedingt auch bedeutet das wir Recht bekommen würden.

Danke

 

[KMoeser]

Hallo,

da der genaue Sachverhalt vermutlich hier zu aufwändig ist zu klären, ist eine Antwort zu dem geschilderten Problem schwierig.

Ich kann dazu aus unserer Sicht als Business-Partner sagen:
Für den Endkunden sieht es oft so aus als wären es nur 2min. Arbeit und dennoch berechnen wir 500€ dafür.
Das liegt dann aber an der Vor- und Nachlaufzeit.
Es wird ja auch zeit benötigt um die Kunden-VM zu laden, das problem zu erkennen+beseitigen, die Dokumentation zu erstellen und dann die Aktualisierung auf dem Kunden-System einzurichten.
Da sind schnell ein paar Stunden vergangen.

Wenn es noch eine MDA ist, wurde als 4stelliger Betrag vermutlich die Umsetzung im App-Designer angeboten, oder?

Den Code zu prüfen ist sehr unüblich, da kaum ein Endkunde inhouse jemand qualifiziertes hat.
Dann könnte dieser es ja auch gleich selbst bauen.

Üblich ist eigentlich die Prüfung durch den Endkunden im Programm.
Wenn also in diesem Beispiel die Bilanz falsch ist, sollte dies dem person in der Buchhaltung per nachrechnen eigentlich auffallen.
Wenn wir Anpassungen rausgeben, prüfen wir diese zwar. Aber besser der Kunde prüft nochmal, ob alles korrekt ist.

Wo ich Recht gebe:
Wenn ein Fehler auffällt, sollte der natürlich schnellstmöglich(idealerweise am nächsten Tag) korrigiert werden.
Je nach Umfang der Korrektur und Urlaub-/Krankenstand kann das aber auch mal 2 Wochen dauern - wenn es nicht gerade ein A-Bug ist.
Der hätte bei uns oberste Priorität.

... noch einmal über €100 extra im Monat zahlen weil das neue Sage wohl komplexer ist...

Kann ich leider nicht nachvollziehen.
Auch hier natürlich schwierig, weil ja nicht bekannt wo/wie die Änderung eingreift.
100€/Monat zusätzlich halte ist aber für viel, wenn es nicht gerade vorher 5.000€/Monat waren.


VG

 

[MPollmer]

Hallo!

Das ist eine doofe Situation. Ich würde immer empfehlen, dass beidseitig eine Lösung gefunden wird. Sobald Anwälte im Spiel sind und die Stimmung kippt, hat niemand etwas davon (außer die Anwälte).

Die Anpassung auf eine neue Versionen kann schon aufwendig sein. Was oft untergeht ist, dass wir als Partner in der Regel Arbeit drumherum haben. Auch eine Zeile Code muss getestet werden. Es muss die Dokumentation angepasst werden etc. etc.

Trotzdem ist die Transparenz wichtig. Warum ist das so aufwendig? Gibt es nicht eine andere Möglichkeit? Was wird denn überhaupt gemacht? Was deckt eigentlich die Wartung ab und was nicht?

Es gibt auch Vereinbarungen, dass der Code für beide Seite offen zur Verfügung steht. Auch das könnte man gegebenenfalls klären und abstimmen.

Sprecht ihr schon mit der Geschäftsführung des Partners? Vielleicht kann da noch ein wenig Ruhe rein, wenn andere Ansprechpartner involviert werden?

In Summe wollen ja alle, dass das System läuft und alle vernünftig arbeiten können.

 

[Steffen Heil]

Das klingt natürlich sehr unglücklich - ob das Verhalten des Partners aber tatsächlich unfair ist, kann ich anhand der Schilderung nicht wirklich einschätzen, eher sogar mit Tendenz zu einem "nein".

Ein Zusatzmodul haben selbst entwickelt und haben hierfür die MDA. Das ersetzen der Add-ins im Modul hat keine 2 Minuten gedauert. Das selbe ist hier mit den Zusatzmodulen der Fall.
Unser Sage Support Partner hält uns nun schon seit über 2 Wochen hin und wir haben immer noch kein Angebot. [...] Einige unserer Mitarbeiter haben Urlaub beantragt da das Arbeiten mit Sage aktuell unerträglich ist.

Sage baut die Sage100 derzeit technologisch massiv um. Wenn ihr tatsächlich noch MDAs einsetzt, handelt es sich um 20 Jahre alte Access-Technologie, welche Sage sukzessive durch aktuellere Technologien (AppDesigner-Metadaten + .Net-Programmierung) ablöst. Der Updateaufwand dieser alten AddIns hängt sehr stark vom Detail ab: spielen sie sich in quasi unveränderten Bereichen ab, genügt es tatsächlich, die Systemmodule zu aktualisieren. Es kann jedoch auch sein, dass größere Umbauarbeiten nötig sind (bspw. "Einflechten" der neuen Programmelemente ins alte Tool durch andere Aufrufe o.ä.) oder sie komplett neu umgesetzt werden müssen, weil die Technologien nicht mehr kompatibel sind. Somit kann sowohl die Aussage, dass es in nur wenigen Minuten / Stunden umgestellt ist (ohne Tests etc.) korrekt sein als auch, dass mehrere Manntage benötigt werden.
Konkretes Beispiel: mit der Version 9.0.7 hat Sage die Druckprozessverwaltung und -logik grundlegend modernisert. AddIns, welche diese nutzten oder in diese eingriffen, müssen höchstwahrscheinlich in neuer Technologie umgesetzt werden. Eine solche Neuumsetzung ist sehr aufwändig, häufig muss mit ähnlichen Aufwänden wie bei der erstmaligen Erstellung gerechnet werden. Ein Gegenbeispiel ist der Preislistenassistent, der nach wie vor in Access gehalten ist. AddIns, die diesen nutzen oder anpassen, sollten recht einfach auf die 9.0.7 angepasst werden können.

Weiterhin halte ich auch 2 Wochen für die Erstellung eines Angebots nicht zwangsweise für übermäßig lange. Natürlich hängt dies auch von Anzahl und Komplexität der Module ab, die ich nicht kenne. Falls es sich um individuell für euch entwickelte Module handelt, muss der Fachhändler diese eben auch individuell prüfen, bevor er eine Schätzung abgibt. Und auch bei allgemein vertriebenen Modulen kann es gerade bei kleineren Fachhändlern sein, dass sie die Module erst noch prüfen müssen. Diese Prüfungen können durchaus einige Zeit benötigen, von der Umsetzung ganz zu schweigen. Hinzu kommt, dass ihr euer System evtl. besser kennt als euer Fachhändler: wenn er nicht regelmäßig mit euch zu tun hat, werden seine Mitarbeiter sich erst einmal mit eurem System & euren Tools vertraut machen müssen und das dauert auch mit der besten Doku seine Zeit. Wenn das Angebot also fundiert sein soll, ist durchaus mit etwas Zeit zu rechnen. Es handelt sich schließlich nicht um Produkte von der Stange, die zudem sehr vielseitig eingesetzt werden können.

Ich frage mich an dieser Stelle aber auch, weshalb ihr offenbar ohne Rücksprache mit / Freigabe durch euren Partner bereits auf die 9.0.7 upgedatet habt? Ich arbeite selbst für Sage Fachhändler als Programmierer und Consulant. Über einen gewisses Supportkontingent (d.h. Bugs und die ein oder andere Unterstützung / Kleinigkeit) hinaus sind wir meist über Wochen ausgebucht. In den seltensten Fällen könnten wir "einfach" ein Update zwischenschieben und würden bei einem nicht abgesprochenen Update zwar soweit möglich helfen, aber auch nicht gerade alles dafür stehen und liegen lassen können und wollen. In anderen Branchen ist es doch auch nicht üblich, dass sofort reagiert werden kann (habe ich in der Autowerkstatt gerade erst selbst erleben dürfen). Warum soll es ausgerechnet in der hochindividuellen IT so sein?

Beim letzten Request für ein winzige 1-zeilige Codeänderung wurde uns nach Prüfung ein 4 stelliger Betrag genannt da wir ohne die Änderung nicht mehr arbeiten konnten. Ich habe zufällig die MDA bei uns gefunden und es dann binnen 60 Sekunden selbst gemacht. Dadrüber waren die natürlich überhaupt nicht happy. Ich gehe mal davon aus das jetzt halt die Rache dafür kommt.

Auch hier: es KANN sein, dass sie euch Geld aus der Tasche ziehen wollten, muss aber nicht. Und dass sie wegen einer solchen Kleinigkeit "Rache" nehmen wollen halte ich - zumindest ohne weitere Vorgeschichte - für sehr unwahrscheinlich.
Wie lange hast Du denn gebraucht, diese Zeile zu finden? War es eine "eindeutige" Stelle oder hat (wie Du selbst andeutest) der Zufall sehr geholfen? Ist es eine Indivudualentwicklung? Ich habe selbst einige Tools programmiert, deren Funktionsweise und Aufbau ich nach Jahren wartungsfreier Nutzung vergessen habe, während der Kunde, der sie täglich nutzt, sie in- und auswendig kennt. Da kann es durchaus einige Zeit dauern, die entsprechende Stelle zu finden, zu testen, zu dokumentieren und ggf. zu installieren.

Was mit euren Servicegebühren abgedeckt ist und ob die 100€ mehr / Monat gerechtfertigt sind weiß nicht. Was ich aberdefinitiv weiß, ist, dass es ohne entsprechende Vereinbarung nicht üblich ist, den Quellcode (=MDA) herauszugeben. Die vereinbarten Funktionen können und müssen i.d.R. über das Programm selbst geprüft werden.

Rein anhand dieser Schilderungen halte ich es daher tendenziell nicht für gerechtfertigt, zum Anwalt zu gehen. Da ich wie gesagt für Fachhändler arbeite, ist meine Sicht aber auch sicherlich nicht neutral.

Edit(h) merkt an, dass es etwas länger wurde als gedacht. Sorry

 

[SPLH]

Hallo KMoesser,

Hallo,

da der genaue Sachverhalt vermutlich hier zu aufwändig ist zu klären, ist eine Antwort zu dem geschilderten Problem schwierig.

Vielen Dank. Ja, deswegen habe ich hier gefragt. Viele hier verdienen Ihr täglich Brot mit dem Entwickeln & Bug-fixing von Sage Applikationen. Eins der Zusatzmodule ist von uns entwickelt worden, aber wurde dann an den Service Partner abgegeben zur weiteren Pflege - so gab es keine Streitigkeiten mehr welcher Entwickler was verbockt hat und welche Version als letzten aktualisiert wurde etc.

Wenn es noch eine MDA ist, wurde als 4stelliger Betrag vermutlich die Umsetzung im App-Designer angeboten, oder?

Ja. Nach mehrmaligem hin und her über warum die kosten so hoch sind hieß es das es wegen Umstellung auf App-Designer ist (obwohl wir unter Zeitdruck standen). Dann hatte ich gesagt das ich keine Umstellung möchte. Dann wurde mir gesagt das es 2 Stunden dauern würde. Auf erneutes Nachfragen warum es so lange dauern sollte wurde mir dann geschrieben;
"vielleicht nochmal als Erklärung. Wir würden das Modul so umbauen, dass es zukünftig nicht auf 6 Ziffernbegrenzt wäre, sondern dass es dynamisch wäre. Ich frage mich an dieser Stelle, in wie weit es sinnvoll ist noch mehr Zeit auf Ihrer und unserer Seite in dieses Thema zu investieren. Sollten wir nicht lieber die 2h Umsetzung starten um weitere Kosten zu sparen? Ich denke dies sollte doch auch in Ihrem Interesse sein, oder?" Erneut, das war nicht die Aufgabe. Ich hatte darum gebeten aus einer 5 eine 6 zu machen bei Belegnummernlänge, sonst nichts.

Kleine Korrektur: Der Service Partner hat uns den Quellcode damals am Ende auch zugesendet welcher angepasst werden sollte damit das Zusatzmodul von denen weiterhin die neuste Version ist (falls unsere veraltet war in anderen Bereichen). Also da gab es wenigstens keine Anstände oder so bezüglich das die meine Änderungen nicht akzeptieren würden.

 

[SPLH]

Hallo!

Das ist eine doofe Situation. Ich würde immer empfehlen, dass beidseitig eine Lösung gefunden wird. Sobald Anwälte im Spiel sind und die Stimmung kippt, hat niemand etwas davon (außer die Anwälte).

Stimme ich 100% zu.

Die Anpassung auf eine neue Versionen kann schon aufwendig sein. Was oft untergeht ist, dass wir als Partner in der Regel Arbeit drumherum haben. Auch eine Zeile Code muss getestet werden. Es muss die Dokumentation angepasst werden etc. etc.

Trotzdem ist die Transparenz wichtig. Warum ist das so aufwendig? Gibt es nicht eine andere Möglichkeit? Was wird denn überhaupt gemacht? Was deckt eigentlich die Wartung ab und was nicht?

Es gibt auch Vereinbarungen, dass der Code für beide Seite offen zur Verfügung steht. Auch das könnte man gegebenenfalls klären und abstimmen.

Sprecht ihr schon mit der Geschäftsführung des Partners? Vielleicht kann da noch ein wenig Ruhe rein, wenn andere Ansprechpartner involviert werden?

In Summe wollen ja alle, dass das System läuft und alle vernünftig arbeiten können.

Alles exzellente Punkte. Diese werde ich morgen mit dem Partner einmal durchgehen. Eventuell haben wir hierdurch einen guten Lösungsansatz. Ich werde Berichten wie es lief.

 

[SPLH]

Das klingt natürlich sehr unglücklich - ob das Verhalten des Partners aber tatsächlich unfair ist, kann ich anhand der Schilderung nicht wirklich einschätzen, eher sogar mit Tendenz zu einem "nein".

Hoffen wir mal das Sie Recht haben.
Mir wäre es weitaus lieber das ich aus einer Mücke einen Elefanten mache, als das es tatsächlich der Wahrheit entspricht. Ich werde berichten wie es in den nächsten Tagen/Wochen weiter verlief.

Sage baut die Sage100 derzeit technologisch massiv um. Wenn ihr tatsächlich noch MDAs einsetzt, handelt es sich um 20 Jahre alte Access-Technologie, welche Sage sukzessive durch aktuellere Technologien (AppDesigner-Metadaten + .Net-Programmierung) ablöst. Der Updateaufwand dieser alten AddIns hängt sehr stark vom Detail ab: spielen sie sich in quasi unveränderten Bereichen ab, genügt es tatsächlich, die Systemmodule zu aktualisieren. Es kann jedoch auch sein, dass größere Umbauarbeiten nötig sind (bspw. "Einflechten" der neuen Programmelemente ins alte Tool durch andere Aufrufe o.ä.) oder sie komplett neu umgesetzt werden müssen, weil die Technologien nicht mehr kompatibel sind. Somit kann sowohl die Aussage, dass es in nur wenigen Minuten / Stunden umgestellt ist (ohne Tests etc.) korrekt sein als auch, dass mehrere Manntage benötigt werden.
Konkretes Beispiel: mit der Version 9.0.7 hat Sage die Druckprozessverwaltung und -logik grundlegend modernisert. AddIns, welche diese nutzten oder in diese eingriffen, müssen höchstwahrscheinlich in neuer Technologie umgesetzt werden. Eine solche Neuumsetzung ist sehr aufwändig, häufig muss mit ähnlichen Aufwänden wie bei der erstmaligen Erstellung gerechnet werden. Ein Gegenbeispiel ist der Preislistenassistent, der nach wie vor in Access gehalten ist. AddIns, die diesen nutzen oder anpassen, sollten recht einfach auf die 9.0.7 angepasst werden können.

Ja, die 9.0.7.1 bringt viele Veränderungen und ja, wir nutzten noch relativ viele Zusatzmodule welche auf Access basieren welche über die nächsten Monate neu programmiert werden müssten damit wir das neue Sage Smart wunderbar nutzen können. Das austauschen der Systemmodule/Add-ins würde uns aber erstmal ausreichen damit beide Seiten sehen können ob es erstmal ausreicht oder nicht. In unseren Tests schien alles zu laufen, aber wir hatten nichts 'gedruckt' - wir hatten nur geschaut ob alle Masken richtig funktionieren.

Ich frage mich an dieser Stelle aber auch, weshalb ihr offenbar ohne Rücksprache mit / Freigabe durch euren Partner bereits auf die 9.0.7 upgedatet habt? Ich arbeite selbst für Sage Fachhändler als Programmierer und Consulant. Über einen gewisses Supportkontingent (d.h. Bugs und die ein oder andere Unterstützung / Kleinigkeit) hinaus sind wir meist über Wochen ausgebucht. In den seltensten Fällen könnten wir "einfach" ein Update zwischenschieben und würden bei einem nicht abgesprochenen Update zwar soweit möglich helfen, aber auch nicht gerade alles dafür stehen und liegen lassen können und wollen. In anderen Branchen ist es doch auch nicht üblich, dass sofort reagiert werden kann (habe ich in der Autowerkstatt gerade erst selbst erleben dürfen). Warum soll es ausgerechnet in der hochindividuellen IT so sein?

Früher wurde das Live Update immer vom Service Partner durchgeführt während der Arbeitszeit. Seit langem installieren wir es selbst außerhalb der Geschäftszeit weil wir uns so viel Zeit sparen das Mitarbeiter nicht dumm rum sitzen. Jede E-Mail Beantwortung vom Service Partner wird uns berechnet. Da kontaktiert man diese nicht gerne. Wofür wir einen Wartungsvertrag haben verstehe ich nicht so ganz wenn wir für alles immer extra bezahlen müssen. Wir kontaktieren seit bestimmt einem Jahr an sich nur noch Sage direkt und erklären denen jedes Mal warum wir nicht über unseren Service Partner das Problem melden. Die sind sehr verstehend.

Auch hier: es KANN sein, dass sie euch Geld aus der Tasche ziehen wollten, muss aber nicht. Und dass sie wegen einer solchen Kleinigkeit "Rache" nehmen wollen halte ich - zumindest ohne weitere Vorgeschichte - für sehr unwahrscheinlich.
Wie lange hast Du denn gebraucht, diese Zeile zu finden? War es eine "eindeutige" Stelle oder hat (wie Du selbst andeutest) der Zufall sehr geholfen? Ist es eine Indivudualentwicklung? Ich habe selbst einige Tools programmiert, deren Funktionsweise und Aufbau ich nach Jahren wartungsfreier Nutzung vergessen habe, während der Kunde, der sie täglich nutzt, sie in- und auswendig kennt. Da kann es durchaus einige Zeit dauern, die entsprechende Stelle zu finden, zu testen, zu dokumentieren und ggf. zu installiere

In dem Fall war es extrem einfach den Fehler zu finden und zu lösen. Die Fehlerursache war sehr einfach zu erkennen.
Uns wird eigentlich immer gesagt das es eine Individualprogrammierung ist, aber später heißt es dann das das Zusatzmodul bei anderen Kunden einwandfrei läuft.

Was mit euren Servicegebühren abgedeckt ist und ob die 100€ mehr / Monat gerechtfertigt sind weiß nicht. Was ich aberdefinitiv weiß, ist, dass es ohne entsprechende Vereinbarung nicht üblich ist, den Quellcode (=MDA) herauszugeben. Die vereinbarten Funktionen können und müssen i.d.R. über das Programm selbst geprüft werden.

Rein anhand dieser Schilderungen halte ich es daher tendenziell nicht für gerechtfertigt, zum Anwalt zu gehen. Da ich wie gesagt für Fachhändler arbeite, ist meine Sicht aber auch sicherlich nicht neutral.

Deswegen frage ich hier. Meine Sichtweise ist 100% anders als die eines Fachhändlers. Es ist also extrem Hilfreich eure Sichtweise zu sehen. Meine Ansicht der Situation ist 100% auch anders als die vom Fachhändler. Immerhin werden die nicht denken 'den zocken wir mal ab' sondern eher 'ok, schlagen wir lieber mal €€€ drauf falls etwas nicht läuft und wir dann zusätzliche Stunden auf Kulanz arbeiten müssen', aber trotzdem kann es sich für mich so anfühlen als ob es Abzocke wäre.

Naja, schauen wir mal. Ich melde mich wenn ich Infos habe.

 

[Steffen Heil]

[...]
Ja, die 9.0.7.1 bringt viele Veränderungen und ja, wir nutzten noch relativ viele Zusatzmodule welche auf Access basieren welche über die nächsten Monate neu programmiert werden müssten damit wir das neue Sage Smart wunderbar nutzen können. Das austauschen der Systemmodule/Add-ins würde uns aber erstmal ausreichen damit beide Seiten sehen können ob es erstmal ausreicht oder nicht. In unseren Tests schien alles zu laufen, aber wir hatten nichts 'gedruckt' - wir hatten nur geschaut ob alle Masken richtig funktionieren.

Früher wurde das Live Update immer vom Service Partner durchgeführt während der Arbeitszeit. Seit langem installieren wir es selbst außerhalb der Geschäftszeit weil wir uns so viel Zeit sparen das Mitarbeiter nicht dumm rum sitzen. Jede E-Mail Beantwortung vom Service Partner wird uns berechnet. Da kontaktiert man diese nicht gerne. Wofür wir einen Wartungsvertrag haben verstehe ich nicht so ganz wenn wir für alles immer extra bezahlen müssen. Wir kontaktieren seit bestimmt einem Jahr an sich nur noch Sage direkt und erklären denen jedes Mal warum wir nicht über unseren Service Partner das Problem melden. Die sind sehr verstehend.

Da Sie das nötige Wissen und die personellen Ressourcen im Haus haben, ist es durchaus nachvollziehbar, dass Sie die Updates selbst durchführen. Problematisch hierbei ist allerdings die derzeitige Strategie von Sage, so lange an der Version 9.0.x fest zu halten. Zwischen Version 9.0.1 und 9.0.7 sind die Unterschiede mittlerweile deutlich größer als zwischen zwei "alten" Hauptversionen (bspw. 8.1 auf 9.0); das Service Pack 7 ist eigentlich eher eine neue Hauptversion als "nur" ein SP oder gar LiveUpdate. Während innerhalb eines SPs (bspw. 9.0.6.1 auf 9.0.6.9) i.d.R. nur geringfügige Änderungen stattfinden und AddIns sowie andere Zusatzlösungen (meist) kompatibel bleiben, ist es bei neuen SPs und eben gerade dem SP 7 häufig nicht der Fall. Wir haben daher sogar einen Newsletter an alle unsere Kunden mit Zusatzlösungen / Anpassungen geschickt, das Update auf SP 7 möglichst erst nach Rücksprache und Freigabe durch uns oder nach eigener Prüfung auf einem Testsystem auszuführen. Aber auch bei den vorherigen ServicePacks war es auf Grund der umfangreichen Umbauarbeiten nicht unüblich, dass wir Zusatzlösungen updaten und im Zuge des LiveUpdates ausrollen mussten - daher war eine frühzeitige Kontaktaufnahme für Prüfung und ggf. Anpassung immer ratsam. Wie gesagt hängt dabei viel von den Modulen selbst ab. Vereinfacht gesagt: je mehr die Module in die Standardprozesse der Sage ein- oder diese aufgreifen, desto wahrscheinlicher ist Anpassungsbedarf. Wenn die Module eher in sich geschlossen arbeiten (eigene Masken mit eigenen Reports etc.) sollte es einfacher möglich sein, sie auch künftig zu nutzen.

In dem Fall war es extrem einfach den Fehler zu finden und zu lösen. Die Fehlerursache war sehr einfach zu erkennen.
Uns wird eigentlich immer gesagt das es eine Individualprogrammierung ist, aber später heißt es dann das das Zusatzmodul bei anderen Kunden einwandfrei läuft.

Das klingt tatsächlich nicht gerade vertrauensbildend und ist das Gegenteil der von @MPollmer erwähnten Transparenz. Den Vorschlag, das Gespräch mit der GF zu suchen, halte ich daher auch für sinnvoll.

Deswegen frage ich hier. Meine Sichtweise ist 100% anders als die eines Fachhändlers. Es ist also extrem Hilfreich eure Sichtweise zu sehen. Meine Ansicht der Situation ist 100% auch anders als die vom Fachhändler. Immerhin werden die nicht denken 'den zocken wir mal ab' sondern eher 'ok, schlagen wir lieber mal €€€ drauf falls etwas nicht läuft und wir dann zusätzliche Stunden auf Kulanz arbeiten müssen', aber trotzdem kann es sich für mich so anfühlen als ob es Abzocke wäre.

Naja, schauen wir mal. Ich melde mich wenn ich Infos habe.

Ja, auch das ist verständlich - und genau deswegen antworte ich auch hier. Den Austausch und Perspektivwechsel halte ich für extrem wichtig, es sollen schließlich alle Seiten profitieren. Bin also gespannt, wie es weiter geht

 

[KMoeser]

.... Sollten wir nicht lieber die 2h Umsetzung starten um weitere Kosten zu sparen? Ich denke dies sollte doch auch in Ihrem Interesse sein, oder?" ....

Den Satz des Kollegen halte ich für absolut korrekt an dieser Stelle.

Mit "...weitere Kosten..." ist hier schlicht die Arbeitzeit von ihm und Ihnen gemeint, immer wieder über das Thema zu schreiben/reden.
2 Stunden für eine Änderung halte ich - ohne genau den Aufwand zu wissen - aber auch für ein Minimum, da dabei wie oben ja schon geschrieben die ganzen Vor- und Nachlaufzeiten notwendig sind.

Wie @Steffen Heil ja schon schrieb, ist das alte Access nicht mehr Stand der Dinge und ich würde die beiden Stunden eher in die Umsetzung als AppDesigner-Lösung einsetzen. Die muss sowieso kurz-/mittelfristig gemacht werden.
Schonmal gefragt, ob das nicht kurzfrsitig auch gemacht werden kann?

 

[breithecker]

ich kann mich hier gerne mal "outen" - der unfaire Partner sind wir/bin ich.

Im Markt sind wir sicherlich als alles andere bekannt als "unfairer Partner". Ihr könnt euch sicherlich vorstellen, dass es auch eine andere Seite der Medaille gibt. Ich möchte es aber an der Stelle meinem Kunden nicht gleich tun und es hier öffentlich zur Schau stellen.

 

[breithecker]

vielleicht eine Frage ganz neutral - würde irgendjemand empfehlen, dass ein Sage 100 Anwender auf Basis des Standard Sage Supports eine Sage 100 mit einer Vielzahl an Anpassungen (Addins, AppDesigner, AC) selbstständig und ohne Rücksprache auf die 9.0.7 updatet?

 

[SPLH]

2 Stunden für eine Änderung halte ich - ohne genau den Aufwand zu wissen - aber auch für ein Minimum, da dabei wie oben ja schon geschrieben die ganzen Vor- und Nachlaufzeiten notwendig sind.

Es ging bei der Änderung darum aus einer '5' eine '6' zu machen da der Code halt "Belegnummer 5 Ziffern lang" diktierte. Mehr nicht. Wenn es irgend etwas anderes wäre, oder auch nur minimal komplexer, kann ich es verstehen. Aber nicht wenn der Kunde mitteilt was gemacht werden muss damit es läuft und es sich auf einen Tastenschlag beläuft.

 

[KMoeser]

vielleicht eine Frage ganz neutral - würde irgendjemand empfehlen, dass ein Sage 100 Anwender auf Basis des Standard Sage Supports eine Sage 100 mit einer Vielzahl an Anpassungen (Addins, AppDesigner, AC) selbstständig und ohne Rücksprache auf die 9.0.7 updatet?

In unseren Newslettern steht dazu sinngemäß "Wenn Sie selbst das LiveUpdate durchführen möchten ist das auf einem Test-System kein Problem. Prüfen Sie dort ob alle Anpassungen noch voll funktionsfährig sind und stimmen dann einen Termin mit uns ab, bevor sie das LU im Live-System machen."

Anwender mit größeren Anpassungen empfehlen wir sowieso dringend IMMER erst auf einer Test-Installation die Neuerungen selbst zu prüfen.
Wie oben schon geschrieben wurde, können wir nicht bis ins Detail das machen, was der Anwendende tut. Oft wissen wir ja nicht mehr - obwohl die Programmierung von uns ist - was genau alles passieren muss.

 

[SPLH]

In unseren Newslettern steht dazu sinngemäß "Wenn Sie selbst das LiveUpdate durchführen möchten ist das auf einem Test-System kein Problem. Prüfen Sie dort ob alle Anpassungen noch voll funktionsfährig sind und stimmen dann einen Termin mit uns ab, bevor sie das LU im Live-System machen."

Anwender mit größeren Anpassungen empfehlen wir sowieso dringend IMMER erst auf einer Test-Installation die Neuerungen selbst zu prüfen.
Wie oben schon geschrieben wurde, können wir nicht bis ins Detail das machen, was der Anwendende tut. Oft wissen wir ja nicht mehr - obwohl die Programmierung von uns ist - was genau alles passieren muss.

Bei der 9.0.7 schien alles in der Test-VM zu laufen, auch Eigenprogrammierungen liefen nach befolgen der Sage Doku, aber es wurde halt nichts gedruckt 'ohne Vorschau'. Ich hatte immer Vorschau genutzt da ich nicht vor Ort war um zu sehen wie der Druck aussieht. Mit Vorschau läuft Sage ja, nur 'ohne Druck-Vorschau' löst halt einen total-absturz aus.

 

[KMoeser]

Es ging bei der Änderung darum aus einer '5' eine '6' zu machen da der Code halt "Belegnummer 5 Ziffern lang" diktierte. Mehr nicht. Wenn es irgend etwas anderes wäre, oder auch nur minimal komplexer, kann ich es verstehen. Aber nicht wenn der Kunde mitteilt was gemacht werden muss damit es läuft und es sich auf einen Tastenschlag beläuft.

Wie schon gesagt: Schwierig zu sagen, ob es wirklich nur eine Änderung 5 zu 6 im Code ist - auch wenn das auf den ersten Blick so aussieht.

Oft zieht es noch andere Punkte nach sich, wenn man nur eine Stelle ändert, weil der Wert ja irgendwo weiterverwendet, gespeichert, gedruckt, ... wird. Diese Punkte müssen zumindest angeschaut und geprüft werden.

So 2 Stunden sind ganz schnell rum, wenn man zusammenrechnet das jemand ja eine Doku für die Entwicklung macht, die Entwicklung die Kunden-EntwicklungsVM starten muss, die Änderung druchführt, den eigenen Test macht, die Bereitstellung und Abschlußdoku erstellt.

 

[KMoeser]

Mit Vorschau läuft Sage ja, nur 'ohne Druck-Vorschau' löst halt einen total-absturz aus.

Und das ist das "Problem" der Programmierung?

Ich bin jetzt nicht der Entwickler, aber für mein Verständnix hört die Entwicklung bei der Vorschau auf.
Danach macht doch StimulSoft den Rest.
Aber ich kann mich da auch irren.

 

[breithecker]

Da sind wir beim Thema - Doku und Tests braucht dieser Kunde ja nicht. Wie die Tests dann verlaufen, sieht man ja bei der VM mit der 9.0.7.

Ich will mich da wirklich nicht auslassen aber es gibt doch einen Grund warum wir Sage Partner, jeder Mitarbeiter, etc jedes Jahr aufs neue zertifizieren und weiterbilden und das nicht in unwesentlicher Höhe. Aber wenn das Verständnis nicht da ist, können wir da wenig machen.

Aus die beschrieben Details möchte ich nicht eingehen - ich will hier keine "Wäsche waschen" - das heißt nicht, dass es so korrekt ist.

 

[Steffen Heil]

Und das ist das "Problem" der Programmierung?

Ich bin jetzt nicht der Entwickler, aber für mein Verständnix hört die Entwicklung bei der Vorschau auf.
Danach macht doch StimulSoft den Rest.
Aber ich kann mich da auch irren.

Nicht ganz. Die meisten Anpassungen & Erweiterungen sollten dann zwar bereits durchlaufen sein, es gibt aber auch Schnittstellen, die bei der tatsächlichen Druckdurchführung greifen. U.a. eine, die mit dem SP 7 entfällt (Edit: oder geändert wird? Müsste ich mir selbst erst näher anschauen, jedenfalls wurde da etwas gemacht). Könnte ich mir durchaus als (Teil-)Ursache der Probleme vorstellen (Edit: und ist nicht unbedingt trivial zu lösen).

 

[SPLH]

Wie schon gesagt: Schwierig zu sagen, ob es wirklich nur eine Änderung 5 zu 6 im Code ist - auch wenn das auf den ersten Blick so aussieht.

Oft zieht es noch andere Punkte nach sich, wenn man nur eine Stelle ändert, weil der Wert ja irgendwo weiterverwendet, gespeichert, gedruckt, ... wird. Diese Punkte müssen zumindest angeschaut und geprüft werden.

So 2 Stunden sind ganz schnell rum, wenn man zusammenrechnet das jemand ja eine Doku für die Entwicklung macht, die Entwicklung die Kunden-EntwicklungsVM starten muss, die Änderung druchführt, den eigenen Test macht, die Bereitstellung und Abschlußdoku erstellt.

Ja, macht Sinn. In normalen Fällen würde ich hier zustimmen das 2 Stunden i.O. wären, kann natürlich auch blöder Zufall sein das in diesem Fall mit dem Ändern der 5->6 sich damit alles erledigt hatte. Da ich aber wusste das 5->6 die Lösung ist fand ich es nicht gerade Erfreulich so etwas zu hören wie 'zahlen Sie einfach die 2 Stunden, lohnt sich doch nicht zu besprechen warum wir so viel berechnen wollen'.

 

[Steffen Heil]

So 2 Stunden sind ganz schnell rum, wenn man zusammenrechnet das jemand ja eine Doku für die Entwicklung macht, die Entwicklung die Kunden-EntwicklungsVM starten muss, die Änderung druchführt, den eigenen Test macht, die Bereitstellung und Abschlußdoku erstellt.

Aus Entwicklersicht kommt noch hinzu, dass ich mich dagegen sträube, einfach einen Wert zu ändern, dessen Auswirkung ich nicht überbliche. Wenn ich das Tool also nicht gerade in und auswendig kenne, muss mich für eine gewissenhafte Umsetzung erst einmal in die Lösung hinein denken, mögliche Fallstricke ausmachen, etc. Zu Beginn meiner Entwicklerlaufbahn bin ich ich ein paar Mal auf solche Fälle wie "musst doch nur schnell den Wert ändern" eingegangen und plötzlich traten an ganz anderer Stelle (oder noch gefährlicher: mit zeitlichem Versatz, bspw. in der Weiterverarbeitung der Daten) Probleme auf. "Nur mal kurz" gibt es m.E. in der Programmierung so gut wie nie und v.a. nicht von außen herangetragen.