Eigene WaWi programmieren

[koshop]

Komplett selbstprogrammieren kämme für mich jetzt nicht in Frage. Ich nutze CAO Faktura, das läuft auf MySQL und das hab ich sozusagen "aufgebohrt". D.h. ich greife mit zahlreichen externen Modulen auf die Datenbank zu. In der Regel werden da aber Daten nur ausgelesen, bis auf einfach Sache wie z.B. Versandflag auf versendet setzen usw.

Der Grund warum ich das so mache ist simpel: Selbst wenn ich selbst als Programmierer ausfalle und die Zusatzmodule mal nicht mehr funktionieren und upgedatet werden können - das Grundsystem läuft wird von den Entwicklern regelmäßig aktualisiert und mit dem ist auch ein Geschäftsbetrieb möglich.

[Patchwork (R.i.P.)]

die wichtigsten Vorrausetzungen für ein WaWi sind für uns:
- webbasierte Lösung
- bestimmte Funktionen auch auf Smartphone / Tablet nutzbar
- Benutzerkonten / Berechtigungen / Rollenvergabe
- Scannerunterstützung
- Performance
- automatisierung von Prozessen z.B. Emailversand
- API für eigene Erweiterungen (falls Kaufsystem)
- Datenbank im Intranet oder auf eigenem Webserver
- es gehen keine Daten nach aussen!
Diese Liste ist natürlich je nach persönlichen Anforderungen erweiterbar.

Darüberhinaus trennen wir klar zwischen Onlineshop und WaWi (wobei es hier auch immer Schnittmengen gibt). D.h. der Shop muss auch ohne WaWi weiterlaufen können ohne Einschränkungen!
Ein Satz wie "das WaWi ist jetzt das führende System und Änderungen dürfen nur noch im WaWi gemacht werden ist für mich ein No-Go!

[dance]

eine wichtige Software für (m)ein Unternehmen selbst programmieren? Never ever.
Kein Steuerberater programmiert eine Steuer- Mandantensoftware, weil DATEV Macken hat.
Konzerne sind alle weg von ERP Eigenlösungen und nutzen SAP, Oracle, Navision o.ä.m.
Für Kalkualtion gibt es EXCEL und Co., für Projekte MS Projekt und höher, für Briefe schreiben WORD.

Wer soll den die Programmpflege bei Änderungen / Neuerungen wirtschaftlich machen?
Wo lieg5t denn das know-how bei einer Eigenlösung? Doich nur im Kopf einiger weniger Leute. Wenn die mal das Unternehmen verlassen. Dann Gute Nacht!

[Patchwork (R.i.P.)]

das Problem ist ja dass man uU in eine Zwangsjacke kommen kann - indirekt bestätigst Du das ja auch
Man sollte sehr genau prüfen, ob einem der "Standard" ausreicht - den meisten wohl nicht, denn Erweiterungen zum Standard werden massenhaft programmiert.
Und hier muss man abwägen: wie viele Erweiterungen brauche ich - die meist richtig teuer werden - oder reicht mir der Standard

[webstar]

Schau mal bei Tricoma.de nach - vielleicht ist diese eine Option.

Noch nie gehört, gemäß Webauftritt scheinen die ja ALLES zu können. Können die aber die wichtigsten Sachen richtig?

[lallekalle]

Schau mal bei Tricoma.de nach - vielleicht ist diese eine Option.

Noch nie gehört, gemäß Webauftritt scheinen die ja ALLES zu können. Können die aber die wichtigsten Sachen richtig?

Die Dinge die ich für meine Abläufe (Verkauf von personalisierten Artikeln mit hohem Automatisierungsgrad) können die dank Individualprogrammierungen besser, als alle anderen von mir angeschauten Warenwirtschaften. Somit wurde das System direkt auf mich angepasst und nicht ich musste mich auf eine starre Warenwirtschaft anpassen.

Aber darum geht es hier nicht. Es geht darum, eventuell die Idee für ein ein Basis-System zu finden, welches man mit überschaubarem Aufwand auf seine eigenen Bedürfnisse anpassen kann - durch Eigenprogrammierungen. Und ich glaube, dass das hier ohne Probleme realisierbar ist.

[vbc]

Ich bin immer wieder erstaunt, wie wenige scheinbar "Filemaker" kennen, bzw. nutzen.
Wenn man sich was eigenes programmieren lassen möchte, sollte man auch mal bei Filemaker Programmierern anfragen.

[neimles]

Ich bin immer wieder erstaunt, wie wenige scheinbar "Filemaker" kennen, bzw. nutzen.
Wenn man sich was eigenes programmieren lassen möchte, sollte man auch mal bei Filemaker Programmierern anfragen.

das nutzen wir auch viel, ich bekam den tipp auch hier im forum.

das ist schon ziemlich mächtig und man bekommt wirklich gute lösungen hin.

wir haben uns damit ein PIM programmiert, das produktdaten auf knopfdruck für ama, wawi, usw... auswirft. wir pflegen produktinfos nur mehr zentral und bedienen damit alle plattformen.

spart hunderte stunden im jahr....

[pvdb]

Bei uns ist seit 2009 eine Eigenentwicklung im Einsatz. Bis zur ersten Nutzung hat da eine Person 6 Monate dran gearbeitet. Im Laufe der Jahre kamen dann immer neue Funktionen hinzu. Man unterliegt schon permanenten Anpassungen. Sei es Fehler, neue Funktion und Anpassungen aufgrund rechtlicher Anforderungen.

Da wir vorher Pixi im Einsatz hatten, haben sich einige Abläufe daran orientiert. Im Laufe der Jahre wurde der Schwerpunkt jedoch auf Dropshipping gesetzt, so dass viele neue Abläufe entstanden.

In 2018 wollte ich unsere Eigenentwicklung auf den neusten Stand bringen und quasi komplett neu entwickeln. Mehr in Richtungen Mandaten und Hooks, so dass individuelle Änderungen das ganze nicht mehr vercoden und die Wartbarkeit wesentlich einfacher wird. Das ganze ist Webbasierend. Ich schätze hier die Entwicklungszeit auf ca. 12 Monate bei 80% Einsatz.

Wenn eine Fertiglösung alle Wünsche abdeckt, würde ich dabei bleiben. Sind jedoch ganz andere Abläufe da und besondere Anforderungen kann eine Eigenentwicklung Sinn machen. Wenn man jemand drittes beauftragt, kann man die Kosten nicht einschätzen und man kann auch nie 100% sicher sein, ob es dann auch laufen wird, wenn der Entwickler die Erfahrung nicht hat. Wenn, dann sollte es meiner Meinung nach intern entwickelt werden.

Zum Thema Buchhaltung, dass hat unsere Lösung nicht. Man kann sich die Buchungssätze der Rechnungen und Gutschriften exportieren, die dann in eine externe Buchhaltungssoftware importiert werden. Ähnliches mit Intrastat.

[Arakis]

Gern möchte ich auch ein Feedback geben zu unserer selbstimplementierten Lösung.

- vollständig Linux/Mono/C#-basiert (wir verfügen im gesamten Unternehmen nicht über einen einzigen Windows-PC)
- Ursprünglich mit Desktop-UI (GTK-basiert), nun ist fast alles über den Browser möglich.
- Anbindung an ebay und Amazon
- automatischen Preiskalkulation inkl. Berechnung des optimalen Kartons/Vesandtasche, selbst bei komplexen Multi-Bestellungen. Tetris lässt grüßen.
- die notwendigsten Statistiken
- Picklist-Verwaltung, Paket-Verwaltung inkl. Ersatzlieferungen und manuellen Anpassungen
- Warenbeschaffung/Bestellvorschläge (eines der komplexesten Module mit viel Spezial-Logik, denn Lagerplatz und Kapital sind bekanntlich begrenzt)
- Wareneinkaufs-Verwaltung inkl. Ware in Zulauf
- Anbindung an die wichtigsten Versanddienstleister
- Kassensystem. Aus rechtlichen Gründen verfolgen wir aber dennoch das Konzept der "offenen Ladenkasse". Ist eigentlich kaum mehr Aufwand, denn gezählt werden muss eh bei jedem Schichtwechsel (Zählprotokoll).
- Dokumentenmanagementsystem

Angefangen sind wir mit einer Excel-Tabelle, welche wir jedoch nach wenigen Tagen schon aufgegeben haben. Dann folgte eine absolut rudimentäre Anbindung an Amazon und ebay. Das Bestellwesen wurde implementiert und eine einfache Anbindung an unseren Hauptversanddienstleister. Bis dato hatten wir noch keine Picklisten/Scanner. Mit den ersten beiden Mitarbeitern musst dies schnell aus dem Boden gestampft werden. Schnell musste auch eine chaotische Lagerverwaltung her, denn die Mitarbeiter wussten meist nicht wo sich was befindet. Irgendwann mussten wir auch unsere Lieferscheine von Bestellungs-Basiert auf Lieferungsbasiert umstellen, da es Ersatzlieferungen geben kann oder mehrere Pakete pro Bestellung. Statistiken sind recht spät rein gekommen, zuvor habe ein paar Kennzahlen gereicht. Gerade in dem Moment wird ein Zeiterfassungssystem implementiert, damit sich Mitarbeiter mit ihren Handscannern ein- und auschecken können. Das nächste Projekt wird wohl Windows Mobile/Android sein, weil unsere Bluetooth-Handscanner bald gegen WLAN-Scanner ausgetauscht werden müssen aufgrund des zu groß gewordenen Lagers.

Und das Shop-System ist bis heute nicht mal zu 30% fertig.

Bis dato habe ich alle selber implementiert. Einen Entwickler habe ich erst vor wenigen Wochen eingestellt, welcher erst jetzt anfängt sich allmählig zu rechnen und nicht mehr meine Zeit mit Fragen frisst.

Fazit:
Wenn ich heute nochmal wählen müsste, ich würde nicht noch einmal diesen Weg gehen. Dennoch glaube ich nicht, dass der Weg völlig falsch war. Er ist aber zeitaufwendig und schränkt hier und da ein, bzw. alles dauert ein wenig länger, da immer erst die Schnittstellen/Module implementiert werden müssen.

[Dusty]

Wer hat das schon gemacht?

Bin beim Googlen zufällig auf diesen Thread gestoßen und wollte mal kurz "Hier!" rufen. Wir sind ein kleines IT-Systemhaus und haben bis 2016 mit einer DOS-basierten Software gearbeitet (um die wir dann so Sachen wie E-Mail-Versand, Aktualisierung von Webshop-Artikeln usw. drumrum gebastelt hatten). Leider hat diese Software ein Jahr-2015-Problem, sodass wir sie nur noch eingeschränkt nutzen konnten.

Der Gedanke reift bei mir immer mehr. Um maximal effizient arbeiten zu können, müsste eine Eigenentwicklung her.

Ich habe immer mehr Workarounds und Krücken, die von der Wawi verursacht werden.

Ging uns exakt genauso. Nachdem wir uns etliche andere Lösungen angeschaut haben (wobei für uns 3 Kriterien entscheidend waren: 1. Arbeitsgeschwindigkeit, 2. Datenmigration, 3. Kosten), haben wir uns für "selbst ist der Nerd" entschieden. Entwicklungszeit von der 1. Codezeile bis zur Einführung im Februar 2016 waren ca. 800 Programmierstunden, das wären bei meinem Stundensatz ca. 67.000,- EUR gewesen (nur mal so als Hausnummer - mit weniger Funktionsumfang kriegt man sowas bestimmt für 30-35K hin).

Ist das der richtige Weg? Vielleicht ein Muß ab einer bestimmten Größenordnung?
Oder gibt es die perfekte Wawi für diese Summe zu kaufen?

Aus meiner Erfahrung tendiere ich zu "Ja, das ist der richtige Weg". Wir haben unsere Arbeitsabläufe hier so "geil" optimiert bekommen, dass ich ohne Übertreibung 10 Stunden pro Woche einspare.

Bei der Entwicklung haben wir uns natürlich an die alte Software angelehnt, so ist unsere neue z.B. auch komplett über Tastatur bedienbar (Arbeitsgeschwindigkeit!). Außerdem haben wir alle Daten der alten Software übernommen bekommen (Migration! - Hat kein anderer Lösungsanbieter hinbekommen, max. die Stammdaten wären möglich gewesen, aber so habe ich auch noch alle alten Aufträge, Bestellungen, usw. in der neuen Software greifbar). Na ja, und da (größtenteils an den Wochenenden) selbst gemacht, hielten sich auch die Kosten im Rahmen.

In den Beiträgen meiner Vorredner kam immer wieder das Argument auf: "Wenn der Entwickler vor den Baum fährt, ist die Investition verloren". Das stimmt natürlich nur bedingt, denn wenn Du Dir sowas für Dich entwickeln lässt, lässt Du Dir natürlich die Übergabe des Quellcodes vertraglich zusichern. Achte darauf, dass der Auftragnehmer eine gängige Programmiersprache verwendet (bei einer Windows-Anwendung also am besten Visual Studio.net - bei webbasiertem UI am besten PHP). Als Datenbank sollte MySQL oder ein Derivat zum Einsatz kommen.

Wenn der Entwickler dann einigermaßen ordentlich kommentiert und dokumentiert, kannst Du relativ leicht den Programmierer wechseln, sollte es wirklich zum Worst Case Scenario kommen.

Übrigens bist Du auch bei großen Software-Häusern keinesfalls davor sicher, dass Deine Investition geschützt ist: Das Software-Haus, das unsere DOS-Software entwickelt hat, wurde bspw. aufgekauft und die Lizenzbedingungen radikal geändert, sodass uns ein Update auf die aktuelle Version bei 5 Arbeitsplätzen (das wäre die absolute Untergrenze gewesen, mit der wir hätten leben können) auch mehrere tausend Euro gekostet hätte. Und ich kenne auch mehr als ein Beispiel, wo ganze Software-Linien plötzlich vom Markt verschwunden sind, aus den unterschiedlichsten Gründen (Hersteller pleite oder von der Konkurrenz aufgekauft, Neuausrichtung des Unternehmens etc. pp.) Na ja, und das Austesten verschiedener fertiger Lösungen kostet natürlich auch Zeit und Geld.

Ich denke, das hier so vielfach an die Wand gemalte Risiko des plötzlich nicht mehr greifbaren Autors kannst Du getrost vernachlässigen! (just my 5 cent)

[Tony]

Danke für den Erfahrungsbericht. Interessant und ja - beneidenswert!

Ich scheue im Moment den großen Aufwand und mein Programmierer hat ja jetzt nicht die ganze Zeit Langeweile, so dass er andersrum nicht monatelang ausschließlich an der WaWi arbeiten könnte.
Daher liegt das Projekt bzw. die Idee derzeit auf Eis.

[Mankra]

Aufzeig und ich hab beide Varianten durch:
Damals über Jahre immer wieder nach diversen Anbietern gesucht, welche den 3 Satz: Webshop - Kasse (6 Filialen) - Schnittstelle für die Buchhaltung abdecken.
Dabei natürlich auch zig Programme im günstigen Bereich (Cao, JTL, Amicron, usw.) durchprobiert.
War tw. schon ein Trauerspiel, bis die Programme stabil liefen. Anfragen dauerten tagelang....wäre unbrauchbar, wenns Kunden im Geschäft stehen hast.

Irgendwann ging das Budget immer weiter rauf, waren dann auch mit Pixi im Kontakt, zuerst schnelle Antworten, aber mit der Zeit, dauerten die Antworten immer länger + diverse Benutzer-Feedbacks mit tw. Serverausfällen verlief dies auch im Sande.

Grundsätzlich ist das Problem bei allen Universalprogrammen, dass diese mit hunderten Eingabefeldern und Funktionen zugemüllt wird, ein Programm für Alles.
Somit werden die Masken, Workflows, Bedienung unnötig kompliziert.

kamen wir letztendlich zu einem Anbieter, welcher uns mit dem Versprechen fing: Sie haben ein Core Programm, der Rest wird auf unsere Anforderungen angepaßt.
Als wir den Vertrag dann unterschrieben hatten und es zur Anpassung ging, war dann Vieles doch nicht so einfach möglich, bzw. nicht so einfach bedienbar, wie erhofft.
Weiters wissen die Softwarefirmen, dass eine Warenwirtschaft nicht so einfach und schnell getauscht wird, d.h. man gibt sich in Geiselhaft.
So hat jede spätere Änderung und Optimierung, welche oft erst im Betrieb ergibt, gleich eine Lawine gekostet.
In Summe haben wir in 2 Jahren knappe 70k reingesteckt........

Dann hab ich die Reisleine gezogen und die Wawi selbst geschrieben:
PHP/MySql, somit mit jedem PC/Tablet bedienbar.
Jede Änderung, welche sich mit der Zeit ergibt oder im Betrieb zeigt, ist schnell umgesetzt (Kleinigkeiten dauerten tw. in der Erklärung länger, als die Umsetzung).
Die Bedienmasken sind reduziert auf das Notwendigste.
Die Bedienschritte sind in der optimalen Reihenfolge.
Ohne viel Bling/Bling, dementsprechend schnell
Datenbankstruktur ist bekannt, jede Preis/Artikeldatenänderung, etc. ist recht einfach eingespielt.

Die Grundfunktionen hatte ich recht schnell umgesetzt (ich bin kein gelernter Programmierer, Fast & Dirty, Funktioneller Stil), nach einem Monat war es rudimentär Einsatzfähig, habs zuerst im Winter, im Versand ausprobiert und in den nächsten Monaten am Workflow optimiert und nicht so wichtige Funktionen hinzugefügt.

Wenn die Möglichkeit besteht, würd ichs immer wieder so umsetzen.
Allein wegen der Unabhängigkeit und der schnellen Anpassungsmöglichkeit.

Aber es ist ein großer Unterschied, ob man etwas selbst programmiert oder von jemand fremden/Agentur: Die Abhängigkeit besteht dann schnell wieder, eventuell schlimmer, als wenn eine bekanntes OS-Programm von einer großen Agentur angepaßt wird.

[Xantiva]

Die Grundfunktionen hatte ich recht schnell umgesetzt (ich bin kein gelernter Programmierer, Fast & Dirty, Funktioneller Stil), nach einem Monat war es rudimentär Einsatzfähig, habs zuerst im Winter, im Versand ausprobiert und in den nächsten Monaten am Workflow optimiert und nicht so wichtige Funktionen hinzugefügt.

Ich wünsche Dir echt, das Du damit nachhaltig "glücklich" wirst. Ich denke jetzt nicht an 1-2 Jahre. Wie steht es um Deine Software, wenn PHP noch mal so etwas macht, wie die alte, immer wieder gern genutzte MySQL Schnittstelle ab zu schaffen und durch neue Varianten zu ersetzen? Musst Du dann nur an einer Stelle die gekapselten Datenbankzugriffe umstellen? Oder doch eher überall im Code Änderungen vornehmen? Ich habe an einigen funktionalen (quick&dirty) Anwendungen gearbeitet, die doch länger liefern, als ursprünglich vielleicht mal angedacht. Ab einem gewissen Grad an Komplexizität wird das Hinzufügen von neuen Features auf einmal sehr aufwendig und es passieren Dinge, die man nicht mehr berücksichtigt hat. Stichwort Evolvierbarkeit und Seiteneffekte.

[cmayr@descartes.com]

Aufzeig und ich hab beide Varianten durch:
Damals über Jahre immer wieder nach diversen Anbietern gesucht, welche den 3 Satz: Webshop - Kasse (6 Filialen) - Schnittstelle für die Buchhaltung abdecken.
Dabei natürlich auch zig Programme im günstigen Bereich (Cao, JTL, Amicron, usw.) durchprobiert.
War tw. schon ein Trauerspiel, bis die Programme stabil liefen. Anfragen dauerten tagelang....wäre unbrauchbar, wenns Kunden im Geschäft stehen hast.

Irgendwann ging das Budget immer weiter rauf, waren dann auch mit Pixi im Kontakt, zuerst schnelle Antworten, aber mit der Zeit, dauerten die Antworten immer länger + diverse Benutzer-Feedbacks mit tw. Serverausfällen verlief dies auch im Sande.

Grundsätzlich ist das Problem bei allen Universalprogrammen, dass diese mit hunderten Eingabefeldern und Funktionen zugemüllt wird, ein Programm für Alles.
Somit werden die Masken, Workflows, Bedienung unnötig kompliziert.

(...)
Dann hab ich die Reisleine gezogen und die Wawi selbst geschrieben:
Die Grundfunktionen hatte ich recht schnell umgesetzt (ich bin kein gelernter Programmierer, Fast & Dirty, Funktioneller Stil), nach einem Monat war es rudimentär Einsatzfähig, habs zuerst im Winter, im Versand ausprobiert und in den nächsten Monaten am Workflow optimiert und nicht so wichtige Funktionen hinzugefügt.

Danke für deinen Beitrag. Da ich jetzt deinen Sellerforum-Account nicht der Anfrage in unserem CRM zuordnen kann, fehlt mir der Einblick, warum die Kommunikation zwischen uns (pixi*) und dir zunehmend langsamer verlaufen wäre. Uns ist es generell wichtig, dass wir unsere Interessenten konsequent und hervorragend und stets immer unverbindlich beraten - das beinhaltet auch, dass wir den Interessenten Zeit geben, die richtige Entscheidung zu treffen und darauf verzichten, regelmäßig nach dem Status zu fragen, denn uns ist bewusst, dass - abgesehen von Unternehmensgründern und neuen eCommerce-Projekten - ihr alle im Tagesgeschäft steckt. Für ein erfolgreiches Projekt muss der Interessent selbst den Nutzen und den richtigen Zeitpunkt erkennen, wenn ein Vertriebsmitarbeiter so etwas zu forcieren versucht, macht er n.m.E. etwas falsch.

Zu 'Ausfällen': Ja, wir hatten in den vergangenen 17 Jahren exakt eine einzige Server-Störung für einige Stunden, die 3 anderen Vorkomnisse in diesem gesamten Zeitraum waren Störungen von Netzknotenpunkten geschuldet, kurzum, da war - vereinfacht gesagt - das Internet generell massiv 'gestört' und das fällt Nutzern manchmal erst recht spät auf ("Achso, Sie haben recht, jetzt weiss ich auch, warum das Telefon nicht mehr klingelt, weil das über VOIP geht. Die Damen im Kundenservice waren auch erstaunt, dass bis jetzt noch keine neue E-Mail reinkam".).

Was uns zudem auszeichnet - vielleicht hatte ich dir pixi* auch mal präsentiert? - ist ja, dass wir auf das 'Bling Bling', wie du das so schön umschreibst, verzichten und vor allem die Prozesse straff und weitestgehend automatisiert laufen. Ja, wir setzen nicht jeden Wunsch um - und genau hier hast du mit deiner eigenen Entwicklung die Lösung geschaffen, die du dir vorstellst.

Wie früher angemerkt, bin ich kein genereller Gegner von Eigenentwicklungen, man muss einfach vernünftig abwägen und entscheiden, seine Bedürfnisse, Prozesse und Anforderungen kennen und auch Prognosen treffen können, was heute vielleicht weniger, morgen deutlich mehr relevant sein wird. Dass du diverse billige Systeme probiert und dann mit einem anderen Projekt durchaus einen nicht geringen Betrag quasi 'verbrannt' hast, auch das gehört zu den Risiken, wenn man sich durchprobiert und die Entscheidung nicht auf soliden Füßen stand. Mit deinem nun selbstentwickelten Projekten dir weiterhin viel Erfolg, wenn es reibungslos funktioniert, war das für dich in letzter Instanz wohl tatsächlich die beste Lösung.

Und in jedem Fall gebe ich dir auch hier recht, dass es einen deutlichen Unterschied macht, wer so ein Individualprojekt umsetzt. Entsprechend ist dein Beitrag in diesem Thread in jedem Fall ein nützlicher Beitrag, wie ich finde.

[Mankra]

Ich wünsche Dir echt, das Du damit nachhaltig "glücklich" wirst. Ich denke jetzt nicht an 1-2 Jahre. Wie steht es um Deine Software, wenn PHP noch mal so etwas macht, wie die alte, immer wieder gern genutzte MySQL Schnittstelle ab zu schaffen und durch neue Varianten zu ersetzen? Musst Du dann nur an einer Stelle die gekapselten Datenbankzugriffe umstellen? Oder doch eher überall im Code Änderungen vornehmen? Ich habe an einigen funktionalen (quick&dirty) Anwendungen gearbeitet, die doch länger liefern, als ursprünglich vielleicht mal angedacht. Ab einem gewissen Grad an Komplexizität wird das Hinzufügen von neuen Features auf einmal sehr aufwendig und es passieren Dinge, die man nicht mehr berücksichtigt hat. Stichwort Evolvierbarkeit und Seiteneffekte.

Garantie für die Ewigkeit gibt's natürlich nicht, natürlich kann niemand sagen, wie in 10, 20 oder 30 Jahren aussieht.
Genauso gibt es keine Garantie, dass heutige Anbieter in 10, 20 oder 30 Jahren noch am Markt sind und in der Zeit auch ein Systemumstieg nötig ist.
Der große Vorteil liegt trotzdem in der Unabhängigkeit:
Mein schlankes System ist auf Updates recht schnell und einfach anzupassen.
Es gibt keine, für mich ungeplanten, unpassenden Zwangsupdates, welche mit eigenen Erweiterungen, Zusatzmodulen, etc. ev. Probleme machen, neue Bugs bringen, welche dann tagelang nicht behoben werden.
Es gibt keine öffentlich bekannten Sicherheitslücken.

Gerade das hinzufügen, neuer Features ist recht einfach, A natürlich, weil ich mich in meinem Programm blind auskenne, B da nicht mit unnötigen Funktionen überfrachtet.
Und vor allem schnell, wie gestern geschrieben, ich brauch nicht erst lange Erklären, was ich möchte, gibt somit keine Missverständnisse, sondern in der Zeit ist es oft schon umgesetzt.

Mein System läuft nun seit knapp 9 Jahren, in der Zeit gabs natürlich schon einige Anpassungen, glaub bin von PHP 5.5 weg, aktuell auf PHP 7, mit den dementsprechenden Updates.

Damals, als ich noch im Einzelhandel war (Ende 2012 verkauft, seit 2014 B2B Großhandel) deckte mein System 6 Einzelhandelsfilialen + OnlineVersand mit 6 stelligen Rechnungsanzahl pro Jahr ab (Fürs System natürlich egal, soll zeigen, dass das System sich in der Praxis bewährt hat).
Die Käufer des Einzelhandels haben das System heute noch im Einsatz, ich habs natürlich für meinen B2B Handel angepaßt und auch im Einsatz.

Musst Du dann nur an einer Stelle die gekapselten Datenbankzugriffe umstellen?

Ja klar. Auch wenn ich kein großes MVC/OOP Framework dafür erstellt hab, natürlich sind alle Funktionen, welche mehrfach benötigt werden, in '"function" ausgelagert.
Die Umstellung auf mysqli hat, einlesen ausgenommen, damals sicher keine Stunde gedauert.

Da ich jetzt deinen Sellerforum-Account nicht der Anfrage in unserem CRM zuordnen kann, fehlt mir der Einblick, warum die Kommunikation zwischen uns (pixi*) und dir zunehmend langsamer verlaufen wäre.

Denn Konjunktiv kannst rausnehmen, die Antworten dauerten bis zu 2 Wochen, und ich glaub auf mein letztes Mail kam dann keine Antwort mehr.
Das Ganze lief damals unter Bikestore.cc und müßte 2008 oder 2009 gewesen sein.

Für mich als Kunde ist es egal, wo in der Infrastruktur, oder Warum das System steht oder hackt.
Als Kunde hab ich da nur eine reduzierte Schwarz/Weiß Wahrnehmung: Läuft oder läuft nicht....

Über die Arbeits-Prozesse haben wir ausführlich diskutiert, und daran gabs die längeren Diskussionen und ein gutes Beispiel:
Diese vom Programm vorgegebenen Arbeitsprozesse waren für uns nicht immer umsetzbar, oder zumindest zeitraubend. Eurer Programm ist optimiert für ein definiertes Warensortiment, gelabelte Artikel.
Wir im Fahrrad Einzelhandel, bei mehreren 100.000 Ersatzteilen, Vieles ohne EAN oder Aftermarket Verpackung. Solche Ersatzteile werden oft einzeln, Auftragsbezogen bestellt.
Das war bei Eurem System viel zu umständlich.
Dito beim Onlineshop, bei der Vielzahl an Artikeln mußten wir viel mit Streckengeschäft arbeitetn.

Euer System ist für bestimmte Szenarien sicher gut vorbereitet und optimiert, aber, und da kommt mein Pro für die Eigententwicklung: Für speziellere Anwendungen sind Systeme, welche allgemein, für 1000te Unternehmen passen sollen, starr, unflexibel.

[cmayr@descartes.com]

Da ich jetzt deinen Sellerforum-Account nicht der Anfrage in unserem CRM zuordnen kann, fehlt mir der Einblick, warum die Kommunikation zwischen uns (pixi*) und dir zunehmend langsamer verlaufen wäre.

Denn Konjunktiv kannst rausnehmen, die Antworten dauerten bis zu 2 Wochen, und ich glaub auf mein letztes Mail kam dann keine Antwort mehr.
Das Ganze lief damals unter Bikestore.cc und müßte 2008 oder 2009 gewesen sein.

Für mich als Kunde ist es egal, wo in der Infrastruktur, oder Warum das System steht oder hackt.
Als Kunde hab ich da nur eine reduzierte Schwarz/Weiß Wahrnehmung: Läuft oder läuft nicht....

Über die Arbeits-Prozesse haben wir ausführlich diskutiert, und daran gabs die längeren Diskussionen und ein gutes Beispiel:
Diese vom Programm vorgegebenen Arbeitsprozesse waren für uns nicht immer umsetzbar, oder zumindest zeitraubend. Eurer Programm ist optimiert für ein definiertes Warensortiment, gelabelte Artikel.
Wir im Fahrrad Einzelhandel, bei mehreren 100.000 Ersatzteilen, Vieles ohne EAN oder Aftermarket Verpackung. Solche Ersatzteile werden oft einzeln, Auftragsbezogen bestellt.
Das war bei Eurem System viel zu umständlich.
Dito beim Onlineshop, bei der Vielzahl an Artikeln mußten wir viel mit Streckengeschäft arbeitetn.

Euer System ist für bestimmte Szenarien sicher gut vorbereitet und optimiert, aber, und da kommt mein Pro für die Eigententwicklung: Für speziellere Anwendungen sind Systeme, welche allgemein, für 1000te Unternehmen passen sollen, starr, unflexibel.[/quote]

Danke für das offene Feedback, habe jetzt mal kurz recherchier, ist lieb, dass du das konkret ansprichst: Ja, ich war anno 2008 mit dir direkt in Kontakt und hatten wir uns schon sehr intensiv über deine speziellen Anforderungen unterhalten, damals war dein eigener Eindruck, dass du mit Standardprozessen nicht viel erreichen würdest, 2009 hat dann ein Kollege noch mal nachgefragt, ist aber wohl zum gleichen Ergebnis gekommen und damit haben wir's beruhen lassen. Deckt sich also auch mit deiner aktuellen Einschätzung. Du schilderst nun ja auch selbst, dass du einen anderen 'Need' gesehen hättest, auch wenn ich beim Bereich von Ersatzteilen und auch nicht ausgezeichneten Produkten durchaus Lösungen sehe, aber unser Produkt hat sich ja auch zwischenzeitlich enorm in vielen Bereichen weiter entwickelt und zu vielen Problemstellungen haben wir heute auch ganz andere Lösungen und mitunter halt auch den ein oder anderen Workaround etabliert oder holen Partner in's Boot, die für spezielle Anforderungen auch spezielle Lösungen anbieten. Und Fulfillment/Dropshipping geht ja mit mit pixi* sowieso. Aber du schreibst ja, dass du nun mit deinem eigenen System sehr zufrieden bist und das ist in der Summe doch die Hauptsache.

Was Störungen/Ausfälle betrifft, sehe ich das ein bisschen anders: Es macht schon einen Unterschied, ob ein Anbieter seine Produkte / Server regelmäßig nicht im Griff hat oder die Ursache mit dem Anbieter rein gar nichts zu tun hat. Klar, das Ergebnis ist das gleiche: Man kann nicht vernünftig arbeiten. Und natürlich, wenn was nicht geht, greift man erstmal zum Telefon, ruft beim Anbieter an und reklamiert. Wenn man dann aber die Frage stellt, ob beispielsweise "das Internet" geht und man als Antwort hört "hab ich noch nicht geguckt, warten Sie mal, oh, stimmt, wir sind komplett offline", dann betrachtet man eben das aus einem anderen Blickwinkel und lernt, nicht einmal vorab blindlings zu pauschalisieren. Und man sollte sicher auch differenzieren, wie oft sowas passiert.


Zurück zum Thread und wie eingangs auch schon erwähnt, sowohl absolut individuelle Systeme wie auch vollständige Eigenentwicklungen haben ihre Daseinsberechtigung. Was ich an dieser Stelle aber noch gern auf den Weg mitgeben will, ist, dass auch Mischformen durchaus passend sein können. Wir erhalten gerade zunehmend mehr Anfragen, ob man pixi* nicht nur als reines Lager- und Versandsystem einsetzen könnte (klar, das geht), Themen wie Faktura, Zahlungswesen oder auch Einkauf würden dann über andere Systeme laufen.

Wenn man also vor der Entscheidung stehen sollte, sich ein nicht passendes Standardprodukt zu holen oder alles von Grund auf neu und selbst zu entwickeln, kann man also auch die Idee in Betracht ziehen, dass man sich überlegt, was am eigenen Geschäftsmodell so speziell ist, dass kein Standard es abdeckt und was wiederum am Geschäftsmodell so ähnlich zu anderen Unternehmen ist, dass 'ne klassische WaWi diese Funktionsbereiche gut bis sehr gut erfüllen kann. Und damit 'ne Mischform einsetzt. Das also nur als Idee meinerseits, zumal wir solche Projekte auch schon realisiert haben und die Ergebnisse ziemlich gut geworden sind. Heisst also, um den schönen o.g. 'schwarz-weiß'-Terminus aufzugreifen: Es muss nicht unbedingt schwarz oder weiß sein, auch Grautöne in verschiedenen Abstufungen sind erlaubt und können sinnvoll sein.