Individuelle ERP Lösungen 

Individuelle Anpassungen

Jedes Unternehmen ist anders, und findet seine Existenzberechtigung auch darin, dass es sich von seinem Mitbewerber unterscheidet.

Der Einsatz neuer Werkzeuge muss daher sorgfältig darauf hin geprüft werden, dass nicht nur die Kosten gesenkt und die Leistungsfähigkeit gesteigert wird, sondern dass die unverwechselbare Eigenart des Unternehmens erhalten bleibt.
Oft liegt daher eine individuelle Anpassung eines Standard-Werkzeugs an die speziellen Gegebenheiten auf der Hand.

odoo ist konsequent daraufhin ausgelegt, dass es einfach angepasst und erweitert werden kann.

redO2oo hat ein erfahrenes Team von gut ausgebildeten Software-Ingenieuren, die in der Lage fast jeden IT-Wunsch zu erfüllen.

Aber ..

Es gibt auch viele gute Gründe, sich die Entwicklung von angepassten Lösungen gut zu überlegen.
Oft ist es nicht so einfach, wie es scheint, wenn Kunden denken, dass sie kundenspezifische Entwicklungen benötigen.
Eine kundenspezifische Entwicklung verursacht zusätzliche Kosten und Zeitverzögerungen für das Projekt, manchmal bis hin zur Gefährdung des Erfolges. Darüber hinaus führt die kundenspezifische Entwicklung zu einer technischen Bindung, die Sie in den nächsten Jahren in Form von höheren Wartungs- und Upgrade-Kosten abtragen müssen.
Jede Entwicklung mag einfach und erschwinglich erscheinen. Aber die Komplexität eines Projekts wächst mit dem Quadrat der Anzahl der Anpassungen, nicht linear. Sie wollen wahrscheinlich das lösen, was Ihnen in Ihrer bisherigen Software nicht gefallen hat. Ein ander Ansatz könnte aber sein, die Geschäftsprozesse zu überdenken und das Projekt so 2x schneller und kostengünstiger umzusetzen?


Ist es das Werkzeug?

Im folgenden vier Portraits. Sie sind von verschiedenen Künstler erschaffen worden. Alle zeigen aussdruckstark eine Person. Alle sind mit den selben Werkzeugen erstellt worden, nämlich Farbe, Pinsel, Stift und Leinwand, aber erzählen doch je eine komplet andere Geschichte.

Oder die Hand des Künstlers ..

Im Falle der Bilder ist die Frage einfach zu beantworten.

Erstaunlicherweise, ist es mit mit Geschäftsprozessen und den Werkzeugen mit denen diese implementiert werden oft genau gleich.

Es ist die Hand des Künstlers die das Resultat bestimmt, nicht das Werkzeug!


A.Anker Mädchenbildnis

Picasso Portrait of A. Vollard
Van Gogh Selbstbildnis
A Dürrer Ulrich Varnbuler

Werkeuge muss man kennen

Damit ein Werkzeug richtig geführt werden kann, muss man es kennen. Es muss so konfiguriert sein, dass gut in der Hand liegt. Man erstellt sinnvollerweise erst weniger anspruchsvolle Werkstücke um sich in seinem Gebrauch zu üben, bevor man sich an ein Meisterwerk wagt.

Auf odoo übertragen, heisst dass, man versucht schrittweise vorzugehen. Erst werden Prozesse mit odoo organisiert, welche wenige Umstellungen benötigen. Dadurch wir eine vertiefte Kenntnis der von odoo bereitgestellten Arbeitstechniken erarbeitet. Erst diese erlaubt allen Beteiligten, die neuen gegen die traditionell genutzten Werkzeuge abzuwägen.

um sie zu führen 

Gewappnet mit diesem Wissen werden komplexere Prozesse untersucht, wie sich odoo und die firmenspezifischen Abläufe vereinigen lassen.

Dabei sind Aha-Erlebnisse nicht ungewöhnlich, bei denen festgestellt wird, dass Bewährtes auf eine neue und elegante Art erledigt werden kann.

Alter Wein

Ungeachtet odoo’s Flexibilität und Leistungsfähigkeit, sind Individual-Lösungen oft unvermeidlich.

Auch hier brilliert odoo, denn es wurde von Anfang an als Werkzeugkasten konzipiert, dessen Einzelteile wie Lego Teile zu neuen Werkzeugen zusammengesetzt werden können.

odoo hat ein über Jahre gereiftes, “kampferproptes” API, welches erlaubt beliebige Prozesse in die odoo-Datenstruktur einzubinden.

Odoo API  

Eine lange Reihe von Fachbücher und Online-Kurse wurden publiziert um sowohl Anwender als auch Fachentwickler mit dem notwendigen Wissen zu versehen.

in neuen Schläuchen

redO2oo entwickelt seit vielen Jahren individuelle Anpassungen und Neuentwicklungen.

Wir haben grosse Erfahrungen in sehr unterschiedlichen Arbeitsgebieten.

Um kostengünstige Lösungen anzubieten, haben wir vor einigen Jahren mit einem ehemaligen Mitarbeiter, eine Entwicklungsfirma in Indien gegründet.

So können wir in idealer Weise schweizerische Qualität mit indischem Wissensdurst und competitiveness vereinen.

Wir erarbeiten sehr gerne mit Ihnen ein Konzept für Ihre individuelle Lösung



 

Ich bin ein Entwickler. Ich entwickle mich gerne, es macht Spaß und ist intellektuell herausfordernd.

Als Geschäftsführer von redO2oo weiß ich aber auch, dass bei ERP-Einführungsprojekten kundenspezifische Entwicklungen so weit wie möglich vermieden werden sollten.

Es ist nicht so einfach, wie es scheint, wenn Kunden oft denken, dass sie kundenspezifische Entwicklungen benötigen. Auf der anderen Seite berechnen Implementierungsdienstleister gerne zusätzliche Service-/Entwicklungstage für diese Anpassungen. Aber ich muss beide Seiten warnen, kundenspezifische Entwicklungen sind nicht gut für Sie!

Warum kundenspezifische Entwicklungen minimieren?
Für Kunden verursacht eine kundenspezifische Entwicklung zusätzliche Kosten und Zeitverzögerungen für das Implementierungsprojekt, manchmal bis hin zur Gefährdung des Projekts. Darüber hinaus führt die kundenspezifische Entwicklung zu einer technischen Verschuldung, die Sie in den nächsten Jahren in Form von höheren Wartungs- und Upgrade-Kosten bezahlen müssen. Eine solche technische Verschuldung kostet etwa 25% der Entwicklungskosten JEDES JAHR (~17% in der Wartung + ~8% in Upgrades).

Jede Entwicklung mag einfach und erschwinglich erscheinen. Aber die Komplexität eines Projekts wächst mit dem Quadrat der Anzahl der Anpassungen, nicht linear. Sie wollen wahrscheinlich das lösen, was Ihnen in Ihrer bisherigen Software nicht gefallen hat; aber wäre es nicht besser, Ihre Geschäftsprozesse zu standardisieren und das Projekt 2x schneller und kostengünstiger umzusetzen?

Für Partner sind kundenspezifische Entwicklungen in der Regel mit hohen Kosten und geringem Kundennutzen verbunden. Wie oft haben Sie 10 Tage veranschlagt, um ein Feature zu entwickeln; der Kunde denkt, dass es zu viel für ein solches Basisfeature ist, also berechnen Sie nur 8 Tage; aber am Ende verbringen Sie 12 Tage. Oh, und wenn wir später Probleme/Änderungen entdecken, weil Sie es eilig hatten, wird der Kunde nicht für den zusätzlichen Tag bezahlen, da es Ihre Schuld ist. Was ein 35%iger Margenservice hätte sein sollen, ist jetzt ein 6%iger Serviceverlust!

Um zu wachsen, ist es einfacher, sich auf wertvolle Dienstleistungen mit besseren Margen zu konzentrieren und das Risiko von nicht abrechenbaren Stunden zu verringern. Dazu gehören: Projektmanagement, Geschäftsanalysen, Anpassungen ohne Entwicklungen, Change Management und Schulungen.

Wenn Sie sich keine Gedanken darüber machen, wie Sie kundenspezifische Entwicklungen reduzieren können, werden Sie früher oder später nicht mehr wettbewerbsfähig sein. Wettbewerber, die die Kundenerwartungen besser managen, haben niedrigere Projektdurchführungskosten. Haben Sie jemals ein Projekt verloren, weil der Kunde sagte: "Sie sind zu teuer", nur um festzustellen, dass der Kunde viel weniger gekauft hat, als Sie geliefert hätten?

Natürlich sind manchmal kundenspezifische Entwicklungen notwendig, um das Geschäft zu führen. Aber meiner Erfahrung nach sind die meisten Kundenanfragen entweder die Kosten für sie nicht wert, nicht relevant, wenn sie Odoo einsetzen, oder sie können ohne es auskommen, da es nicht Teil ihrer Kernnutzung ist. Werden Sie diese Anfragen annehmen oder nicht? Alles hängt von Ihrer Implementierungsmethodik und Ihrer Einstellung zum Unternehmen ab.

Der Kunde ist wahrscheinlich noch kein Experte für das Produkt und wahrscheinlich auch nicht in Implementierungsprojekten. Daher können sie die Kosten eines bestimmten Merkmals nicht einfach mit den Einnahmen, die sie daraus erzielen, in Einklang bringen. Kundenwünsche basieren auf den Herausforderungen, die sie mit ihrer alten Software oder ihrer aktuellen Arbeitsweise hatten. Die meisten dieser Probleme werden gemildert oder sind nicht mehr anwendbar, sobald sie auf Odoo umgestellt werden.

Die richtige Balance zwischen Standard- und kundenspezifischen Entwicklungen zu finden, ist nicht einfach. Was sich für den einen Kunden nicht lohnt, kann für den anderen sehr wertvoll sein.

Wenn Sie Dienstleistungsunternehmen fragen, sagen sie Ihnen alle, dass sie nur das entwickeln, was der Kunde braucht (und sie glauben es wirklich). In Wirklichkeit ist es sehr schwer, sich selbst zu beurteilen und zu wissen, ob man gut darin ist, den Return on Investment zu bewerten und Probleme mit guter Beratung statt mit Entwicklungen zu lösen.

Um die unterschiedlichen Denkweisen zu verstehen, betrachten wir die Implementierungsstruktur zweier Dienstleistungsunternehmen.

FALL 1: Wenn ein Unternehmen 8 Entwickler und 2 Projektmanager hat, liegt ihr Fokus auf kundenspezifischen Entwicklungen. Ihre Methodik ist wahrscheinlich Scrum (oder eine andere agile), und ihr Projektmanager wird die meiste Zeit damit verbringen, Spezifikationen zu schreiben und Entwicklungen zu testen. Sie befriedigen die Kunden durch die Entwicklung, aber dieser Ansatz führt zwangsläufig zu einer Erhöhung der Gesamtkosten des Projekts (natürlich nicht absichtlich). Die Kunden sind kurzfristig zufrieden (da sie alles bekommen, was sie wollen), können aber mit steigenden Kosten und Verzögerungen unzufrieden sein.
CASE 2: Ein Unternehmen mit 2 Entwicklern und 8 Geschäftsleuten (Analysten oder Projektmanager) konzentriert sich auf Business Services: Change Management, Business Process Engineering, Finden von Standardlösungen für Geschäftsprobleme, Schulungen. Sie haben Buchhalter, Lagerverwalter oder andere Experten in ihrem Team, die Kundenwünsche herausfordern können. Sie stellen die Kunden zufrieden, weil sie einen sehr hohen Wert zu einem sehr guten Preis liefern. Die meisten Kunden werden den Ansatz mögen, aber einige könnten kurzfristig frustriert sein, wenn Sie ihre Wünsche in Frage stellen. Im Gegensatz dazu werden diese Kunden mittelfristig sehr zufrieden sein.

Was ist die richtige Balance zwischen CASE 1 und CASE 2? Leider gibt es keinen Benchmark.

Bei Odoo gibt es eine Serviceabteilung mit Entwicklern, Projektmanagern und Business-Experten. Im Laufe der Jahre haben wir uns auf die Verbesserung der Projektgeschwindigkeit konzentriert, anstatt zu versuchen, mehr Dienstleistungen im Voraus zu verkaufen.

Hier sind unsere Teamgrößen für unsere direkten Implementierungsprojekte:

Für kleine Kunden (1-50 User) haben wir 11 Entwickler für 80 Projektmanager & Business Analysten. Also ein 12%iges Entwicklerprofil.

Bei großen Projekten (>500 Benutzer) liegt unser Anteil bei 50% Entwicklern, 50% Nicht-Entwicklern.

Oder Sie sehen es anders: Bei kleinen bis mittelgroßen Projekten werden durchschnittlich 12% unserer Zeit für Entwicklung und 88% für Business Services in Rechnung gestellt.

Als Kunde hilft Ihnen dieser einfache Trick, die Teamgröße zu überprüfen, dabei, Ihren potentiellen Partner nach Ihren Erwartungen zu beurteilen. Als Dienstleistungsunternehmen rechnen Sie mit Ihren eigenen Teamgrößen. Dieses Verhältnis sagt Ihnen, ob Sie Verbesserungspotenzial haben, um Ihre Margen und die Projektgeschwindigkeit zu erhöhen.

Wenn Ihr Verhältnis doppelt so hoch ist wie dieses, lohnt es sich, über Ihre Methoden, Ihr Geschäftsmodell und Ihr Rekrutierungsprofil nachzudenken. Ein guter Ausgangspunkt ist die Odoo-eigene "Implementierungsmethodik".

Wie geht man mit kundenspezifischen Anforderungen um?
Beim Umgang mit Kunden ist zu beachten, dass es einen Unterschied zwischen den Zielen der Stakeholder und den Bedürfnissen der Key-User gibt. Die meisten Entscheidungsträger werden Ihnen sagen, dass ihre Priorität Zeit und Budget ist, während Key-User meist in Bezug auf die zu entwickelnden Features denken. Da sich diese Ziele widersprechen, müssen Sie sich entscheiden; wen wollen Sie zufrieden stellen?

Ich denke, man sollte immer das tun, was man für das Projekt für gut hält; das bedeutet, dass man die Wünsche der Key-User in Frage stellt, bis hin zur Weigerung, es zu tun, wenn man denkt, dass es sich für das Projekt nicht lohnt. Der Versuch, die Anforderungen der Schlüsselanwender zu erfüllen, indem man alles tut, was sie verlangen, ist eine sehr kurzfristige Denkweise; es ist besser, sich auf den Erfolg des Projekts zu konzentrieren.

Ich benutze das folgende Framework, um kundenspezifische Entwicklungsaufträge zu bearbeiten:

Ist das wirklich notwendig?

Lohnt es sich, die Kosten (für Entwicklung und Wartung) zu tragen?

Ist der Gewinn signifikant genug?

Können wir dem gleichen Ziel dienen, mit einem anderen Ansatz?

Wenn Sie zu dem Schluss gekommen sind, dass es sich nicht lohnt, eine bestimmte Funktion zu entwickeln, sollten Sie versuchen, den Kunden zu überzeugen. Dafür gibt es verschiedene Taktiken: das "Warum" erklären, nach dem "Go-Live"-Datum einführen, zu einem Manager eskalieren (obwohl nicht ideal, ist es manchmal notwendig).

Ist das wirklich notwendig?

Nehmen wir an, Sie haben eine Anfrage für die folgende kundenspezifische Entwicklung:

Der Kunde hat eine mit Magento Commerce entwickelte Website und möchte diese nicht verändern, da er bereits viel investiert hat. Aber sie möchten, dass Odoo vollständig in ihre Magento-Website integriert wird (einschließlich Produkte, Coupons, Follow-ups für verlassene Wagen usw.).

Der beste Weg, um festzustellen, ob es notwendig ist, ist zu prüfen, ob der Kunde diese Funktion bereits in seiner alten Software hat. Wenn der Kunde alle Aufträge manuell in seiner alten Software erfasst, kann er dies auch mit Odoo tun. Ich würde dann empfehlen, in die Produktion zu gehen, ohne eine Integration mit Magento zu entwickeln, verwenden Sie Odoo für 3 Monate, und dann überprüfen Sie die Prioritäten und entscheiden, ob es sich lohnt; zu diesem Zeitpunkt haben Sie eine 50% Chance, dass der Kunde Odoo so sehr liebt, dass sie für Odoo eCommerce gehen wird, anstatt ein Stecker für Magento. :)

Im Hinblick auf das Change Management ist es immer besser, Geschäftsprozessänderungen schrittweise einzuführen, als alles auf einmal. Durch die Modularität von Odoo ist der Einsatz in mehreren Phasen sinnvoll: 1/ Mit dem, was der Kunde unbedingt braucht, um das Geschäft zu betreiben und erst nach dem Wechsel zu 2/ Andere Funktionen zur Verbesserung der Effizienz.

In der Realität werden sich die Entwicklungsprioritäten der Kunden ändern, wenn sie in die Produktion gehen. Gründe dafür sind u.a:

Bei der Nutzung der Software entdecken sie neue Entwicklungen, die wichtiger sind und neue Prioritäten setzen.

Nachdem sie etwas Geld für die Implementierung ausgegeben haben, sind sie mit dem Ergebnis zufrieden und ziehen es vor, die Ausgaben für unnötige Funktionen zu reduzieren.

Wenn der Kunde Odoo in der Produktion einsetzt, ändert sich seine Einstellung, wenn er sein Wissen über das Produkt erweitert.

Lohnt es sich, die Kosten zu tragen?

Zweitens müssen Sie den Nutzen bewerten; wie viele Manntage pro Monat spart der Kunde durch diese Funktion. Oftmals rechnet der Kunde nur damit, wie viel Zeit er derzeit für diese Art von Aufgaben aufwendet und wie viel er in Zukunft sparen will. In Wirklichkeit müssen sie noch alle für die Berechnung notwendigen Daten erfassen, Ausnahmen manuell behandeln, etc: Selbst wenn der Kunde einen Magento-Connector entwickelt, muss er alle Konflikte lösen, Preisnachlässe in beiden Softwarelösungen erfassen, sich mit Bestandskonflikten befassen, da die Synchronisation nicht in Echtzeit erfolgt, etc.

Dann müssen Sie die Kosteneffizienz bewerten. Oft sieht der Kunde nur die "One-Shot-Entwicklungskosten". In Wirklichkeit können Sie diese Kosten leicht mit 2 oder 3 multiplizieren, da Sie mehrere Faktoren berücksichtigen müssen: Zeit für Tests, Fehler und zusätzliche Verzögerungen im Projekt, Anpassung der Dokumentation, da diese nicht Standard ist, zukünftige Wartung und Upgrades in den nächsten 5 Jahren.

Beachten Sie, dass Sie durch die Verwendung eines Community-Moduls die Zeit der ersten Entwicklung sparen können, aber die Kosten für Tests, Wartung, Projektverzögerungen und Upgrades bleiben erhalten. Ein Community-Modul ist auch eine technische Schuld.

Ist der Gewinn signifikant genug?

Nehmen wir an, Sie haben eine Anfrage für die folgende kundenspezifische Entwicklung:

Wenn wir einen Verkaufsauftrag für ein Bauprojekt bestätigen, wollen wir eine Reihe von Aufgaben auf der Grundlage eines Regelwerks erstellen, das von den Produkten, Kunden und Standorten abhängt.


Wenn Sie einen Anpassungswunsch haben, sollte Ihr erster Reflex darin bestehen, das Volumen in Frage zu stellen: Wie viele Bauprojekte gewinnen Sie pro Monat? Nehmen wir an, der Kunde gewinnt 10 solcher Projekte pro Monat. Es dauert wahrscheinlich 10 Minuten, um Aufgaben zu erstellen und zu aktualisieren, indem man Projektvorlagen dupliziert und aktualisiert.

Lohnt es sich, eine komplexe Entwicklung zu starten, um weniger als 2 Stunden oder Arbeit pro Monat zu sparen? Sicherlich nicht, diese Funktion wird etwa 10 Tage Entwicklung kosten, plus 25% davon jedes Jahr.

Können wir dem gleichen Ziel dienen, mit einem anderen Ansatz?

Nehmen wir an, Sie haben folgenden Kundenwunsch:

Ich möchte unseren Outlook-Kalender mit Odoo CRM synchronisieren.

Odoo hat einen Connector mit Google Kalender im Standard, aber nicht mit Outlook. Aber die Entwicklung und Wartung eines Steckverbinders kann eine Menge Geld kosten. Es gibt jedoch viele Dienste, die Google Kalender mit Outlook synchronisieren (z.B. IFTTT). Eine Lösung wäre also, einen solchen Service für jeden Mitarbeiter zu abonnieren und einzurichten.

Es ist nicht perfekt, da Sie Ihr Setup jedes Mal ändern müssen, wenn Sie einen neuen Mitarbeiter einstellen. Aber die Lösung ist in 2 Stunden fertig, und es dauert nur 10 Minuten pro neuem Mitarbeiter. Es ist immer noch viel weniger als eine Neuentwicklung, wenn das Unternehmen weniger als 100 Mitarbeiter hat.

Hinweis: In Wirklichkeit hat Odoo einen Outlook-Connector in den Community-Anwendungen, daher empfehlen wir, diesen zu verwenden. Das war nur ein theoretisches Beispiel.

Partner FAQ Wenn ich kundenspezifische Entwicklungen reduziere, verliere ich dann signifikante Einnahmen?
Wenn Sie 80% Ihres Teams als Entwickler und 20% als Projektmanager haben, haben Sie vielleicht das Gefühl, dass Entwicklungen notwendig sind, um Ihren Umsatz zu sichern. Aber Unternehmen, die 20% ihrer Teams als Entwickler haben, haben eine genau entgegengesetzte Sichtweise; Business Services sind notwendig, um Einnahmen und Margen zu erhalten.

In der Realität brauchen die Kunden funktionale Dienstleistungen, oft mehr als Entwicklungen. Man muss nur den richtigen Weg finden, sie zu verkaufen und zu warten. Normalerweise nimmt die Anzahl der Entwicklungsanfragen ab, während die Nachfrage nach Business Services weiter abnimmt, wenn Ihr Ansatz gut ist.

Natürlich kann man nicht von einem Tag auf den anderen wechseln; ein Umdenken im Unternehmen und seine Umsetzungsmethodik braucht Zeit. Aber wenn Sie von 80/20 auf 70/30 gehen können, werden Sie Ihre Margen verbessern. Dann gehen Sie zu 60/40 und Sie werden einen weiteren Schritt vorwärts machen.

Meine Empfehlung wäre es:

Arbeiten Sie an Ihrer Implementierungsmethodik (beginnen Sie mit unserer, wenn Sie keine haben).

Behalten Sie Ihr Team, aber rekrutieren Sie nach und nach ein paar zusätzliche Business-Analysten oder Projektmanager, die kein Entwicklerprofil haben.

Dinge, die man im Hinterkopf behalten sollte:

Vermeiden Sie Entwickler, die auch Projektmanagement betreiben. Ein fachkundiger Entwickler zu werden, ist schwierig und erfordert jahrelange Erfahrung. Ein guter Projektmanager zu sein, erfordert auch Zeit und Erfahrung. Wenn Sie Entwickler zu Projektmanagern befördern, haben Sie in beiden Rollen durchschnittliche Mitarbeiter, die in einer nicht exzellent sind; und durchschnittliche Projektmanager sind schädlich für Ihre Implementierungen.

Vermeiden Sie den Einsatz von Entwicklern in der Kundenbeziehung. Entwickler können alles, sie finden leicht Lösungen für technische Probleme. Daher ist es für sie leicht, "Ja" für eine individuelle Entwicklung zu sagen, da sie nicht den Schmerz empfinden, dass sie damit umgehen müssen. Als Odoo nur 10 Mitarbeiter (meist Entwickler) hatte, war das der Umzug, der es mir ermöglichte, schneller zu wachsen: Ich habe begonnen, Projektmanager ohne Entwicklungswissen zu rekrutieren und die Rolle aller besser zu strukturieren.

Wenn der Kunde sich für Odoo entschieden hat, ist es nicht so, weil er all diese Anpassungen will?
Odoo ist eine erstaunliche Software. Allein durch die Verwendung des Odoo-Standards wird das Unternehmen des Kunden massiv verändert, zum Besseren. Die meisten Abteilungen werden effizienter und die Mitarbeiter haben ein Werkzeug, um ihre Produktivität zu steigern. Hier liegt der Wert; die kundenspezifischen Entwicklungen werden nur 5% bis 10% der Features betragen, die der Kunde von der Plattform nutzen wird.

Sie sollten die Kundenerwartungen managen, noch bevor Sie ein Angebot machen, und der Kunde wird es Ihnen danken, wenn Sie seine Wünsche herausfordern; das ist es, was er normalerweise von großen Projektmanagern erwartet. Dies ermöglicht es Ihnen, das anfängliche Budget zu reduzieren und wettbewerbsfähiger zu sein, während gleichzeitig kostspielige Entwicklungen begrenzt werden, um sich auf hohe Margen im Zusammenhang mit Business Services zu konzentrieren.

Sobald der Kunde ist in der Produktion und glücklich, werden sie viel eher zu kaufen mehr von Ihren Dienstleistungen als Ihr Wert für das Geld ist groß. Es gibt so viele Anwendungen, die Sie auf Odoo einsetzen können, dass das Potenzial nahezu unbegrenzt ist, dass Sie den Umfang jederzeit erweitern können.

Die meisten Unternehmen denken, dass sie einzigartig und besonders sind und fühlen sich in ihrem Wunsch, sich anzupassen, gerechtfertigt. Das ist die falsche Einstellung für ein erfolgreiches Projekt. Es liegt an Ihnen, das Projekt in eine werteorientierte Richtung zu lenken, die dem Kunden hilft, nicht nur Wünsche zu erfüllen. Sie werden Sie langfristig für einen solchen Ansatz belohnen. Odoo ist nicht nur eine Plattform, sondern "Best Business Practices" in der Software. Dabei handelt es sich um Praktiken, die aus der langjährigen Erfahrung in der Arbeit mit Kundenimplementierungen entstanden sind.

Lohnt es sich, eigene Features zu entwickeln, wenn sie in mehreren "zukünftigen" Kundenprojekten wiederverwendet werden können?
In der Vergangenheit haben wir mehrmals versucht, eine benutzerdefinierte Funktion für einen Kunden zu entwickeln, mit der Hoffnung, diese Funktion für zukünftige Kunden wiederzuverwenden. Sie ist in den meisten Fällen gescheitert:

Die Leute haben immer das Gefühl, dass ein Feature generisch genug ist und viele Leute es wollen. In Wirklichkeit werden die anderen Kunden es etwas anders wollen und Sie werden verschiedene Versionen Ihres benutzerdefinierten Codes verwalten.

Dieses Argument wird oft verwendet, damit der Kunde einen Weg aushandelt, um die Kosten einer benutzerdefinierten Funktion zu "teilen", oder damit Ihr internes Team eine "nicht abgerechnete" Funktion rechtfertigt. In beiden Fällen ist es nicht gut für die Margen des Unternehmens.
Die Entwicklung von Funktionen für den Verkauf an mehrere Kunden ist das Geschäftsmodell eines Softwareanbieters (wie Odoo SA), aber es ist ein völlig anderes Geschäftsmodell als ein Dienstleistungsunternehmen. Es ist ein Modell, bei dem Sie 80% Marge für Ihre Produkte benötigen, um die sehr hohen F&E-Kosten zu decken. Es ist ein Modell, bei dem >50% Ihrer Kosten Entwickler in F&E sind und nicht den Kunden in Rechnung gestellt werden.

Ein leistungsfähiges Dienstleistungsunternehmen strebt eine Abrechnungsquote von rund 80% an. Das ist es, was Sie für ein gesundes Wachstum brauchen. Wenn Sie ein gemischtes Geschäftsmodell aus Software-Entwicklung und Dienstleistungen haben, werden Sie dieses Niveau nicht erreichen.

Meine Entschuldigungen Ich weiß, dass ein solcher Blog-Beitrag nicht jedem gefällt. Ich bitte um Entschuldigung. Ich will niemanden verletzen. Ich will nur helfen. Und um hilfreich zu sein, muss ich direkt und transparent sein.

Bitte lesen Sie diesen Blog nicht als Standpunkt eines "Softwareanbieters". Das sind Dinge, die wir im letzten Jahr in unserer Serviceabteilung gelernt haben, wobei wir uns auf Projektgeschwindigkeit und Wettbewerbsfähigkeit konzentrieren und das tun, was wir für den Erfolg des Projekts für gut halten, nicht das, was uns die Key-User von uns verlangen. Es stellt sich heraus, dass diese Serviceabteilung jetzt genauso störend und effizient ist wie unser Produkt, so dass es zu einem massiven Wettbewerbsvorteil wurde.

Ich hoffe, dass es einigen Partnern helfen wird, ihr Wachstum zu beschleunigen, so wie es SAP vor einigen Jahren mit ASAP, der Accelerated SAP Implementation Methodik, getan hat. ASAP hat in den ersten Jahren eine wichtige Rolle bei der Entwicklung von SAP und ihrer Fähigkeit, komplexe Unternehmen zu implementieren, gespielt. Ein wesentlicher Bestandteil ihres Ansatzes ist die Einhaltung des Standards, der "Best Business Practices". Wenn ihr Ansatz zu erfolgreichen Implementierungen mit einem veralteten Produkt wie SAP führt, stellen Sie sich vor, was wir mit einer erstaunlichen Software wie Odoo tun können!

Wir haben ein großes Partnernetzwerk von sehr klugen Leuten. Unsere einzige Schwäche: Wir sind jünger, weniger reif. Wenn es uns gelingt, in der Reife zu wachsen, werden wir den Markt stören, schneller als jedes andere Produkt jemals zuvor. Wir haben die Arbeitsweise der 3.7M-Anwender in wenigen Jahren verändert. Aber um 100 Millionen Anwender zu erreichen, reicht ein großartiges Produkt nicht aus; wir müssen gemeinsam das beste Partnernetzwerk aller Zeiten aufbauen.


Übersetzt mit www.DeepL.com/Translator