Also ganz so standard vermutlich auch nicht, odoo.sh wäre sicher schon der Weg für uns. Ich meinte eher, wenn man die Drittanbieter-Plugins & Co. nutzt aber nur wenige Module selbst entwickelt (anders als ihr, wo du quasi alles anpasst), dann dürfte der Update-Pfad etwas einfacher sein.
Ja, das könnte/sollte einfacher sein. Die Drittanbieter passen ihre Module für die neue Odoo-Version an – was man dann neu kaufen muss. Und bei den eigenen Anpassungen sollte nichts weiter zu beachten sein, wenn kein eigener Code geschrieben wurde.
Seitens der Agentur haben wir gesagt bekommen, dass Odoo Studio manchmal bei Upgrades Probleme macht. Aber das ist Hörensagen.
Wenn man eigene Module schreibt, kommt es halt auch darauf an. Einfacher wird es, wenn diese zum Beispiel eigene Datenmodelle aufspannen und nicht in die Datenmodelle anderer Module eingreifen. Oder man biegt damit „nur“ die Views etwas zurecht. (Die Suchoptionen im Backend kann man so beispielsweise zügig tunen, um den Benutzern kleine aber feine Usability-Verbesserungen zu gönnen.)
Insgesamt schreibt es sich für Odoo besser als für plenty. Man hat ja Zugriff auf den gesamten Code. Also kann man sich konkret anschauen, wie Sachen umgesetzt sind und welche Patterns usw. als Best Practice genutzt werden. Dazu noch eine deutlich bessere Doku. Man programmiert also mit dem System und nicht gefühlt nur dagegen.
1 „Gefällt mir“
Hallo,
wir stecken gerade mitten in der Odoo Migration und fühlen uns gelinde gesagt etwas vor den Kopf gestoßen . Ich würde gerne mal eine Einschätzung zu unserem aktuellen Fall hören.
Die Ausgangslage:
Wir wechseln nach 15 Jahren unser ERP-System (über 750 Artikel, komplexe Prozesse). Da wir das Ganze unmöglich in der Standard-Testphase prüfen können, haben wir vor Kurzem regulär einen Nutzer für ein Jahr gebucht. Mein Sohn richtet das System jetzt Schritt für Schritt ein, testet intensiv und baut unsere Prozesse nach. Ziel ist der Live-Gang im Oktober mit dann insgesamt 5 Nutzern.
Jetzt haben wir innerhalb kürzester Zeit zwei Dämpfer bekommen, die uns massiv am Vertrauensaufbau zweifeln lassen:
-
Warnung wegen „Nutzungsintensität“:
Wir haben eine automatisierte Systemmeldung erhalten, dass bei unserem Abonnement „zusätzliche Benutzer festgestellt“ wurden. Wir sollen entweder mehr Nutzer buchen oder die Nutzung bis zum 03.07. reduzieren, andernfalls wird die Datenbank deaktiviert. Fakt ist: Wir nutzen definitiv nur den einen gebuchten Account – allerdings verständlicherweise sehr intensiv für das Setup. Gibt es bei Odoo neuerdings eine versteckte Obergrenze für Klicks oder Datenverkehr pro User, oder wie kommt so eine Willkür zustande? -
Das „Entweder-Oder“-Dilemma beim Custom Code:
Weil wir benutzerdefinierten Code drin haben (12 Zeilen für Backend / Shop) , liegt uns nun ein Angebot vor: 184,60 € Jahresgebühr für die Wartung von benutzerdefiniertem Code (wird ja pro 100 Zeilen berechnet und umfasst Fehlerbehebung, Support, Upgrades). Das Prinzip verstehe ich. Was mich aber massiv stört, ist die schriftliche Formulierung des Odoo-Mitarbeiters. Sinngemäß hieß es: Entweder Sie nehmen das Angebot für den Code an, oder Sie nehmen sich einen Support und löschen die Codezeilen wieder.
Diese „Friss-oder-Stirb“-Mentalität direkt in der sensiblen Einrichtungsphase verunsichert uns total. Man fragt sich unwillkürlich, welche unerwarteten Forderungen oder Systemmeldungen als nächstes um die Ecke kommen.
Ist das das normale Verhalten und die gängige Praxis bei Odoo? Oder haben wir schlicht Pech gehabt bei unserem Ansprechpartner ?
Grüße
Marcel
@Marcel-1 Du bist von der SaaS Lösung Plenty offenbar zur SaaS Variante von Odoo gewechselt. Und dort gelten eben die Regeln von Odoo, weil SaaS.
Ich würde sagen: Entweder bei der SaaS Version zahlen was verlangt wird, oder die Community Edition selbst hosten.
@uweschuermann kann bestimmt genauer erklären ob das mit dem selbst-hosten praktikabel ist bei Odoo?
SaaS ist schon okay und gewollt.
Na ja ganz so einfach ist es nicht. Eine Forderung ist im idealerweise transparent und nachvollziehbar. Zumindest finde ich das selbstverständlich.
Bis jetzt ist es mir nicht gelungen herauszufinden wie ein überschreiten Nutzungsintensität definiert ist. Und eine Preisliste für benutzerdefiniertem Code finde ich auch nicht. Aber besser sowas kommt direkt am Anfang. Ansonsten ist es so oder so zig mal besser und günstiger als Plenty. Und ja man ist echt überrascht was alles möglich ist
Im Forum wird es erklärt, etwa 16eur je 100 Zeilen je Monat:
Mich wundert das bei SaaS eher nicht, da werden eben Gebühren eingeführt um Geld zu verdienen, auch wenn man sie nicht immer nachvollziehen kann. Bei plenty etwa die Gebühren für 404-Weiterleitungen oder für das Hosting von Dokumenten. Bei meinem Vertrag (Zero) war das auch nicht bei Vertragsabschluss klar, sondern wurde einfach mal als extra Gebühren eingeführt, nach dem Motto “wenns nicht passt kannst du ja kündigen”.
Und das mit den “mehreren Usern”: Aufpassen, ob mehrere Sessions auf verschiedenen geräten gleichzeitig aktiv sein könnten. Zur Not vielleicht einen 2. User buchen um über 2 Geräte laufend testen zu können.
Ich fände halt so eine Preisliste wie in jeder Imbissbude super. Im Forum hab ich nie geguckt. Der Preis an sich ist ja auch schon okay und muss ich bei Odoo ja eigentlich auch nicht verstecken.
Bei Plenty versteh ich das schon viel eher das auf Preistransparenz verzichtet wird. Bis jetzt bin ich sehr positiv überrascht.
Hatte ich auch noch nicht. Welches Hosting?
Und ansonsten: Einfach mal nachhaken. Ich denke, dass Odoo hier verhindern möchte, dass mehrere Benutzer sich einen Zugang teilen. Immerhin baut die Kostenstruktur auf diesem Prinzip auf.
Komplett ignorieren. Der Mitarbeiter wird aus dem Vertrieb sein. Und deren Provision hängt auch von solchen Dingen ab.
Habt ihr noch einen anderen Ansprechpartner? Der normale Support ist in der Regel nicht so drauf.
Ja, das ist definitiv intransparent. Irgendwo auf der Seite findet man es. Und in der Regel schreibt es der Vertrieb auch in die Angebote rein. Es bleibt aber rein optional.
Wir hosten bei OPaaS. Das ist die Hosting-Tochter von OBS – also der Agentur, die wir für die Migration zu Odoo an der Hand haben. Darüber haben wir Odoo auch gebucht, weil sich der Odoo-Vertrieb zu dem Zeitpunkt noch ein wenig dümmer angestellt hatte.
Das ist an sich stressfrei und scheint sich immer mehr als Glücksgriff zu erweisen. Nicht, dass wir gar nichts auszusetzen hätten, aber so manche Probleme tauchen gar nicht erst auf.
Wir haben einen Ansprechpartner bzw. eine Support-E-Mail-Adresse beim Hosting. Antwortzeiten sind flott und Antworten kompetent. Gerade neulich konnten wir damit ein kleines Dilemma bei den Cronjobs beheben.
Dann haben wir einen festen Ansprechpartner bei Odoo. Einfach für Bugmeldungen, allgemeine Rückfragen und solche Sachen. Der ist nett und antwortet auch zügig.
Und dann haben wir natürlich noch unseren Ansprechpartner bei der Agentur. Das ist kostenpflichtig. Anfangs haben wir das intensiver genutzt und wir hatten ehrlich gesagt auch etwas Lehrgeld bezahlt, weil die Zusammenarbeit eher geknirscht hatte. Ist dann deutlich besser geworden, weil wir inzwischen wissen, mit welchen Fragen und Themen wir uns überhaupt dort hin wenden. Zudem scheinen wir wohl so was wie „Power User“ zu sein, weil wir eben das System nach unseren Vorstellungen verfeinern.
Komplett selbst hosten geht natürlich auch, wenn man schon eigene Server und In-House-Kompetenz hat. Ansonsten empfehle ich tatsächlich einen spezialisierten Odoo-Hosting-Dienst.
Ach ja. Mit dem Hosting selbst haben wir fast nie Probleme. Das fällt im Verhältnis zu den dauernden Ausfällen bei plenty umso mehr auf. Bei dem großen Ausfall von Cloudflare waren wir natürlich auch betroffen. Wobei man sich meines Wissens auch gegen Cloudflare entscheiden kann.
Ansonsten waren es nur sehr seltene und kurze Downtimes oder Performanceprobleme. Auch hier wieder: Bei Meldung gab es zeitnah eine Reaktion.
Also falls Odoo (mit Odoo.sh?) dir dumm kommt, hast du beim Hosting definitiv Auswahl. Und von wegen „Support“ kann es auch eine Agentur sein. Je nach Ausgestaltung des Vertrags zahlt man dann zum Beispiel nach tatsächlich angefallenem Aufwand. Odoo-Agenturen gibt es viele. Da muss man schauen, ob es für einen passt.
2 „Gefällt mir“
Hallo Uwe,
ich habe dazu eine Frage an dich, weil ihr mit eurer Odoo-Umstellung ja schon deutlich weiter seid.
Ich hatte zuerst Odoo Online gebucht, habe mich inzwischen aber für Odoo.sh entschieden, weil Odoo Online für unseren Anwendungsfall doch einige klare Nachteile hat, insbesondere bei eigenen Modulen, Drittanbieter-Apps und mehr Kontrolle über die Umgebung.
Du hattest geschrieben, dass ihr über OBS Solutions bzw. deren Opaas-Cloud geht.
Mich würde interessieren, welche Vorteile du bei Opaas im Vergleich zu Odoo.sh siehst – abgesehen vom Preis. Dass Odoo.sh vermutlich etwas teurer ist, ist mir klar. Mir geht es eher um praktische Vorteile im Betrieb, Betreuung, Performance, Updates, Zugriffsmöglichkeiten oder Support.
Ein zweites Thema betrifft die Performance des Odoo-Shops.
Wir haben den Livegang für Oktober geplant und aktuell für die Einrichtungsphase erst einmal nur einen Worker gebucht. Mir ist klar, dass wir im Livebetrieb mindestens zwei Worker benötigen werden. Der Shop ist aber bereits grob eingerichtet, mit Artikeln, Kategorien usw.
Jetzt habe ich testweise einen Google-PageSpeed-Test gemacht. Das Ergebnis war ehrlich gesagt etwas enttäuschend. Vor allem die Werte bei First Contentful Paint, Total Blocking Time, Speed Index und Largest Contentful Paint waren nicht überzeugend.
Meine Frage dazu:
Liegt das nach deiner Erfahrung hauptsächlich daran, dass aktuell nur ein Worker gebucht ist? Oder lassen sich diese PageSpeed-Werte nur begrenzt über zusätzliche Worker beeinflussen?
Habt ihr euren Odoo-Shop schon einmal mit Google PageSpeed getestet? Und falls ja: Seid ihr mit den Ergebnissen zufrieden?
Mich würden deine Erfahrungswerte dazu sehr interessieren, gerade weil ihr schon näher am fertigen System seid.
Viele Grüße
Marcel
Ich meine, dass OPaaS sogar ein wenig teurer ist als Odoo.sh; aber die neue Preisübersicht auf der OPaaS-Seite macht mir den Vergleich gerade schwer.
Vorteile: Hmmm … Der Odoo-Vertrieb war halt einfach doof. Das ging hin und her und deshalb hatten wir dann erst mal eine Agentur gesucht und die hatte dann auch noch das Hosting „angeschlossen“. Wobei es keine Voraussetzung für die Zusammenarbeite ist, dass man dort hostet.
Geschwindigkeit im Shared Hosting ist passabel. Dedicated wäre potenziell noch mehr drin. Odoo.sh ist wahrscheinlich sogar etwas schneller. Aber das müsste man sauber vergleichen, um eine echte Aussage zu treffen. Support hatte ich ja schon erwähnt: nichts zu beanstanden. Insgesamt sehr wenige Probleme.
Shop-Performance: Das ist tatsächlich ein Thema bei uns, aber eher auf einer anderen Ebene. Mit Theme Prime und unseren Anpassungen – die eher nichts mit Frontend-Performance zu tun haben – kommen wir auf sehr ähnliche Werte zu unserem Plenty-Shop. In Lighthouse sind es 74 (Odoo) vs. 79 (plenty LTS) Punkte. FPC und LCP sind besser, TBT ist schlechter. CLS bei beiden: 0.
Ich habe einfach mal eine Produktseite (selbes Produkt) zum Vergleich genommen. Bei Odoo ist das unsere Staging, weil da schon die Produktdaten verfügbar sind.
Man sollte dabei allerdings beachten: In den plenty-Shop sind etliche Monate an Arbeit geflossen, um dieses Niveau zu erreichen. In den Odoo-Shop nichts. Nach dem Livegang habe ich vor, die wichtigsten Punkte anzugehen, die wahrscheinlich mit wenig Aufwand umgesetzt werden können: kritischer Pfad, Rendering-Blockaden und mal sehen, was da mit der Schriftanzeige laut Google nicht ganz auf der Höhe ist. Das hebt die Werte potenziell in die 80er-Region.
Mit den Workern hat das übrigens nichts zu tun – oder nur bedingt. Bei nur einem Worker kann es zu einer gewissen Latenz im Shop-Frontend kommen, wenn im Backend viel los ist oder wenn viele Besucher gleichzeitig im Shop unterwegs sind. Das sieht man ja schnell im Dev-Tab des Browsers. Wenn die TTFB hoch ist, liegt es am Worker.
PageSpeed/Lighthouse misst wiederum die Gesamtperformance. Die Serverantwortzeit ist da nur ein Teil. JS, CSS, kritisches Pfad bei den Assets, Codierung der Bilder usw. spielen da auch mit rein. Der Score gibt ja eher das Optimierungspotenzial wieder. Die Bereiche „Statistiken“ und „Diagnose“ geben Hinweise, an was man arbeiten könnte/sollte.
Die „Core Web Vitals-Bewertung“ bei PageSpeed gibt dann in etwa die echten Benutzererfahrungen wieder. Das sind Messungen von Chrome, die Google fröhlich einsammelt.
Und nur kurz zum Einzelwert „TBT“: Den sieht Google selbst kritisch. Daher wurde er in den Core Web Vitals gegen „INP“ getauscht.
Abschließend noch zu unserer Performance-Herausforderung. Wir haben gemerkt, dass die Anzahl an Produkten für den Odoo-Shop teilweise etwas viel zu sein scheint. Das führte zu recht hohen Latenzen bei verschiedenen Seitenaufrufen im Shop. Daher haben wir auf der Datenbank- und Python-Seite schon ein paar Sachen getunt und sind jetzt deutlich zufriedener.
Der Vergleich mit plentyShop LTS ist recht schwierig. Bei plenty sitzt da noch der ShopBooster dazwischen, der seine ganz eigenen Probleme hat. Bei Odoo gibt es nichts in dieser Art. Der Vorteil ist: Sobald man etwas an einem Produkt anpasst, ist es in der nächsten Sekunde im Shop aktuell.
Wie sich das alles im Produktivsystem und mit mehr Workern verhält, werde ich recht bald sagen können.
1 „Gefällt mir“
Hi Uwe, sag mal, war nicht einmal die Rede davon, dass du ein Migrationstool baust und evtl. anderen anbieten würdest? Was ist daraus geworden? VG Alexander
Ja, das ist noch der Plan. Wir machen das gerade rund und machen Features noch sattelfest.
Wer Interesse hat, kann sich einfach schon mal an contact@puresports.shop wenden. Wir würden recht bald auch Vorführtermine anbieten. Nach unserem ersten Testlauf ist uns allerdings aufgefallen, dass wir uns eine Art Skript erarbeiten müssen, damit es nicht komplett konfus wird. 
3 „Gefällt mir“
Hab euch diesbezüglich ne Mail geschickt.
Ja, wenig konfus wäre cool 
1 „Gefällt mir“
Moin,
ich kann inzwischen nur empfehlen, sich Odoo einmal als Testsystem anzusehen. Wir sind ständig überrascht, was dort alles möglich ist.
Gerade als langjähriger Plenty-Kunde stellt man mit Verwunderung fest, welche Funktionen in anderen Systemen offenbar ganz selbstverständlich sind. Odoo ist grundsätzlich logisch aufgebaut. Natürlich ist das System komplex – aber genau daraus ergeben sich auch sehr viele Möglichkeiten.
Wir können inzwischen Dinge umsetzen, von denen wir schon gar nicht mehr geglaubt hatten, dass sie sich vernünftig abbilden lassen.
Das soll keine Lobhudelei sein. Natürlich werden sich im weiteren Verlauf auch bei Odoo noch Probleme und Ärgernisse zeigen.
Aber gerade als Plenty-Händler fühlt sich Odoo momentan wie eine Oase an, wenn man zuvor jahrelang durch die PlentyMarkets-Wüste gezogen ist.
Und ich freue mich schon jetzt auf den Anruf von Plenty, wenn man wieder versucht, mich für den doppelten Preis in den PlentyONE-Tarif zu zwingen. Dieses Gespräch dürte ausgesprochen unterhaltsam werden. Ich kann ja fragen ob die mit einer Aufzeichnung einverstanden sind. 
Grüße
Marcel
Genau das. Kann ich voll unterschreiben.
Ja, die gibt es immer und überall. 
2 „Gefällt mir“
Ich war ja erst auf Odoo Online, aber erst mit SH bieten sich wirklich ungeahnte Möglichkeiten.
Dazu kommt das es so aussieht als ob ich einige externe Tools wie Plenty2Datev (haben die Gebühren ja auch verdreifacht) und Rapidmail (auch zu teuer) in Rente schicken kann. Das bietet weitere erhebliche Einsparpotenziale und mach Odoo noch günstiger als es eh schon ist.
Sendcloud & co. brauchen wir auch nicht, ein eigenes, externes Versandcenter war mit Ki Hilfe in Odoo in einem Tag gebaut und in die Oberfläche verknüpft. Tatsächlich kann sogar es Spaß machen sich damit zu beschäftigen. Selbst die Schufa Integration ist schon fertig. Alleine dafür wurden vor Jahren 10.000 EUR aufgerufen.
Kurze Frage zu diesem Versandthema: Mit welchen Versanddienstleistern arbeitet ihr hier und wie sieht so ein Versandcenter dann in etwa aus?
Wir nutzen eigentlich sehr gerne Jumingo als Versandbroker für alles was etwas spezieller ist und haben ansonsten DHL eingebunden.