20
Rechnungen über Excel - Datenbank, Software - Ideensammlung
HIer geht es um eine Ideensammlung und eure Einschätzungen
Hallo,
in unserer Firma ( Handwerksbetrieb) werden alle Rechnungen, Angebote usw in Excel verfasst. Das ist über die Jahre so gewachsen und wird mit einem beachtlichem Aufwand betrieben.
Ich würde das ganze gerne vereinfachen und effektiver machen, nur ist mir bisher nicht ganz klar wie ich das am besten anstelle.
Daher würde ich euch bitten mir hier einige Tipps zugeben.
Ich bin im Datenbankbereich auch noch nicht sonderlich erfahren, würde mich aber gerne einarbeiten. Nur wäre es natürlich ziemlich ärgerlich, wenn ich nach 2-3 Monaten merke "Oh die von mir gewählte Lösung/Technologie ist eher ungeeignet".
Wie gesagt: Bisher wird alles, bei jedem Angebot, jeder Rechnung von neuem in Excel eingegeben.
Mir geht es also um eine Möglichkeit Textbausteine schnell einzufügen, Kundendaten einzufügen und vorallem Artikel zu zuverwalten.
Stelle mir das so vor, dass man in einer Datenbank alle möglichen "Bausteine" hat (zb Schanier1, Schrauben5, Brett 50*20cm, Farbe1 usw), diese dann zu einem Produkt zusammenfügen kann(zb Schrank).
Vorgefertigte Lösungen, wenn man mal von komplexen Softwarelösungen absieht, halte ich erstmal für nicht so geeignet. Am besten wäre etwas, das langsam, Schritt für Schritt, in die bestehende Struktur eingepflegt werden kann.
Bisher habe ich mir mal PHP, Mysql angeschaut. Damit sollte das doch möglich sein, oder?
Bitte um vorschläge und Anregnungen.
Danke schonmal
in unserer Firma ( Handwerksbetrieb) werden alle Rechnungen, Angebote usw in Excel verfasst. Das ist über die Jahre so gewachsen und wird mit einem beachtlichem Aufwand betrieben.
Ich würde das ganze gerne vereinfachen und effektiver machen, nur ist mir bisher nicht ganz klar wie ich das am besten anstelle.
Daher würde ich euch bitten mir hier einige Tipps zugeben.
Ich bin im Datenbankbereich auch noch nicht sonderlich erfahren, würde mich aber gerne einarbeiten. Nur wäre es natürlich ziemlich ärgerlich, wenn ich nach 2-3 Monaten merke "Oh die von mir gewählte Lösung/Technologie ist eher ungeeignet".
Wie gesagt: Bisher wird alles, bei jedem Angebot, jeder Rechnung von neuem in Excel eingegeben.
Mir geht es also um eine Möglichkeit Textbausteine schnell einzufügen, Kundendaten einzufügen und vorallem Artikel zu zuverwalten.
Stelle mir das so vor, dass man in einer Datenbank alle möglichen "Bausteine" hat (zb Schanier1, Schrauben5, Brett 50*20cm, Farbe1 usw), diese dann zu einem Produkt zusammenfügen kann(zb Schrank).
Vorgefertigte Lösungen, wenn man mal von komplexen Softwarelösungen absieht, halte ich erstmal für nicht so geeignet. Am besten wäre etwas, das langsam, Schritt für Schritt, in die bestehende Struktur eingepflegt werden kann.
Bisher habe ich mir mal PHP, Mysql angeschaut. Damit sollte das doch möglich sein, oder?
Bitte um vorschläge und Anregnungen.
Danke schonmal
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 162559
Url: https://administrator.de/contentid/162559
Printed on: April 19, 2024 at 18:04 o'clock
20 Comments
Latest comment
Hallo,
das was Du Dir vorstellst in Excel umzusetzen wird sehr komplex. Mit PHP sowieso, dazu müsstest Du Dir ein komplett neues Programm bzw. im Falle PHP eine Weboberfläche basteln. Über einen ODBC Treiber wäre es immerhin möglich, mit Excel auf eine MySQL DB zuzugreifen, aber auch dann müsstest Du Dir entspechende Programmfunktionen in VB programmieren.
Du sagst zwar, die fertigen Lösungen scheinen Dir ungeeignetm, aber schau Dir doch mal CAO-Faktura an. Das ist kostenlos und für Kunden- bzw Artikelverwaltung sowie Angebot, Rechnung, Lieferschein usw bestens geeignet.
Falls Du Unterstützung brauchst, um das Programm mal zu Testen oder mal ne Online Vorführung möchtest, gib nochmal bescheid.
Gruß
Andi
das was Du Dir vorstellst in Excel umzusetzen wird sehr komplex. Mit PHP sowieso, dazu müsstest Du Dir ein komplett neues Programm bzw. im Falle PHP eine Weboberfläche basteln. Über einen ODBC Treiber wäre es immerhin möglich, mit Excel auf eine MySQL DB zuzugreifen, aber auch dann müsstest Du Dir entspechende Programmfunktionen in VB programmieren.
Du sagst zwar, die fertigen Lösungen scheinen Dir ungeeignetm, aber schau Dir doch mal CAO-Faktura an. Das ist kostenlos und für Kunden- bzw Artikelverwaltung sowie Angebot, Rechnung, Lieferschein usw bestens geeignet.
Falls Du Unterstützung brauchst, um das Programm mal zu Testen oder mal ne Online Vorführung möchtest, gib nochmal bescheid.
Gruß
Andi
Guten Morgen.
Und warum nichts kostenloses nutzen und dann ausbauen?
http://www.cao-faktura.de/
ist kostenlos, einfach zu bedienen und erleichert bestimmt die arbeit.
Und warum nichts kostenloses nutzen und dann ausbauen?
http://www.cao-faktura.de/
ist kostenlos, einfach zu bedienen und erleichert bestimmt die arbeit.
guten morgen.
Danke erstmal für eure Hinweise. Ich schauen es mir in jedem Fall mal an.
Eine vorgefertigte Lösung habe ich bisher als die schlechtere Alternative angesehn, da die User sich dann direkt komplett umgewöhnen müssten und das bei unseren Mitarbeitern schwierig wäre.
In meiner Vorstellung hatte ich halt gedacht, ich koennte das bestehende Excelsystem Schritt für Schritt umbauen. Rechnungs., Angebotsvorlagen in Excel gibt es ja. Da dachte ich halt, wenn ich mit einer Datenbank und Anbindung in Excel vielleicht zuerst die Artikelverwaltung mache, gibts einen geringeren "Anpassungsschock", danach dann die Textbausteine usw.
Bei uns kommt erschwerend hinzu, dass wir in den Bereichen Rechnungs-, Angebotserstellung usw eine starke Mitarbeiterfluktuation haben. Dort kommen häufig neue Mitarbeiter zum Einsatz.
Bisher müssen die dann nur Excelgrundlagen beherrschen, um die Angebote quasi nur (in Excel) abzutippen.
Aus diesem Grund wurde bisher auch keine prof. Software angschafft.
Hintergrund:
Unsere Handwerksmeister arbeiten quasi nie am PC. Sie erstellen also auf Papier einen Plan was sie brauchen um eine bestimmt Baustelle abzuarbeiten, lassen dann unser Büro das abtippen bzw im Rechner aufarbeiten. Das ganze wird dann an unsere Lieferanten geschickt damit die uns Preise raussuchen.
Dann kalkuliert ein Vorgesetzter das ganze und das Büro tippt anschliessend, wie blöd, ein Angebot oder Rechnung in Excel. Dabei sind Einzelpositionen irgendwann mal zu einer Position zusammengerechnet worden
Sobald eine Änderung (wunsch des Kunden) eintritt, wird quasi das ganze wiederholt. Da arbeiten zum teil 4-5 Menschen, mehrere Tage an so einem Angbot.
sry für den langen Text ;)
Danke erstmal für eure Hinweise. Ich schauen es mir in jedem Fall mal an.
Eine vorgefertigte Lösung habe ich bisher als die schlechtere Alternative angesehn, da die User sich dann direkt komplett umgewöhnen müssten und das bei unseren Mitarbeitern schwierig wäre.
In meiner Vorstellung hatte ich halt gedacht, ich koennte das bestehende Excelsystem Schritt für Schritt umbauen. Rechnungs., Angebotsvorlagen in Excel gibt es ja. Da dachte ich halt, wenn ich mit einer Datenbank und Anbindung in Excel vielleicht zuerst die Artikelverwaltung mache, gibts einen geringeren "Anpassungsschock", danach dann die Textbausteine usw.
Bei uns kommt erschwerend hinzu, dass wir in den Bereichen Rechnungs-, Angebotserstellung usw eine starke Mitarbeiterfluktuation haben. Dort kommen häufig neue Mitarbeiter zum Einsatz.
Bisher müssen die dann nur Excelgrundlagen beherrschen, um die Angebote quasi nur (in Excel) abzutippen.
Aus diesem Grund wurde bisher auch keine prof. Software angschafft.
Hintergrund:
Unsere Handwerksmeister arbeiten quasi nie am PC. Sie erstellen also auf Papier einen Plan was sie brauchen um eine bestimmt Baustelle abzuarbeiten, lassen dann unser Büro das abtippen bzw im Rechner aufarbeiten. Das ganze wird dann an unsere Lieferanten geschickt damit die uns Preise raussuchen.
Dann kalkuliert ein Vorgesetzter das ganze und das Büro tippt anschliessend, wie blöd, ein Angebot oder Rechnung in Excel. Dabei sind Einzelpositionen irgendwann mal zu einer Position zusammengerechnet worden
Sobald eine Änderung (wunsch des Kunden) eintritt, wird quasi das ganze wiederholt. Da arbeiten zum teil 4-5 Menschen, mehrere Tage an so einem Angbot.
sry für den langen Text ;)
Hallo,
dann mach folgendes:
Lege Dir eine Exceltabelle mit mehreren Tabellenblättern an. Jeweils ein Blatt für Kunden, Artikel und Textbausteine.
Eine weitere Tabelle legst Du als Vorlage für Deine Rechnungen, Angebote, Lieferscheine,.... an. Darin wird mit SVERWEIS auf die andere Tabelle referenziert.
Dann musst Du nur noch Kundennummer, Artikelnumer und gegebenenfalls die Textbausteinnummer eingeben und alles ist ausgefüllt.
Für diese Lösung brauchst Du keinerlei Datenbank bzw. Programmierkenntnisse. Lediglich die SVERWEIS-Funktion in Excel.
Solltest Du Hilfe benötigen, melde Dich bei mir (Kontaktdaten auf meiner Homepage - siehe Profil).
Ich sende Dir dann gerne eine Beispieldatei zu. Ich habe das vor CAO-Faktura genau so gemacht.
Gruß
Andi
dann mach folgendes:
Lege Dir eine Exceltabelle mit mehreren Tabellenblättern an. Jeweils ein Blatt für Kunden, Artikel und Textbausteine.
Eine weitere Tabelle legst Du als Vorlage für Deine Rechnungen, Angebote, Lieferscheine,.... an. Darin wird mit SVERWEIS auf die andere Tabelle referenziert.
Dann musst Du nur noch Kundennummer, Artikelnumer und gegebenenfalls die Textbausteinnummer eingeben und alles ist ausgefüllt.
Für diese Lösung brauchst Du keinerlei Datenbank bzw. Programmierkenntnisse. Lediglich die SVERWEIS-Funktion in Excel.
Solltest Du Hilfe benötigen, melde Dich bei mir (Kontaktdaten auf meiner Homepage - siehe Profil).
Ich sende Dir dann gerne eine Beispieldatei zu. Ich habe das vor CAO-Faktura genau so gemacht.
Gruß
Andi
Moin,
wir haben uns vor Jahren selber was auf Basis von Access und Excel erstellt.
Vorher hatten wir das mit Excel gemacht und Angebote kopiert.
Das ist aber einer bestimmten Menge doch mühsam und fehleranfällig.
Aber wir wollten nicht die flexibilität verlieren, schnell mal was anzubieten ohne es einpflegen zu müssen.
Es gibt also eine Exceldatei als Formular, die Stammdaten und die einzelnen Waren kann man über ein Makro aus der Accessdatenbank hinzufügen.
Man kann es aber auch selber schnell eintippen.
Beim speichern werden bestimmte Daten in die Datenbank übertragen.
Funktioniert prima in seinen Grenzen.
Stefan
wir haben uns vor Jahren selber was auf Basis von Access und Excel erstellt.
Vorher hatten wir das mit Excel gemacht und Angebote kopiert.
Das ist aber einer bestimmten Menge doch mühsam und fehleranfällig.
Aber wir wollten nicht die flexibilität verlieren, schnell mal was anzubieten ohne es einpflegen zu müssen.
Es gibt also eine Exceldatei als Formular, die Stammdaten und die einzelnen Waren kann man über ein Makro aus der Accessdatenbank hinzufügen.
Man kann es aber auch selber schnell eintippen.
Beim speichern werden bestimmte Daten in die Datenbank übertragen.
Funktioniert prima in seinen Grenzen.
Stefan
Ja genau, so dachte ich mir das auch.
Mit Excel + Mysql ist das so nicht möglich?
In unserem Officepacket steht uns Access leider nicht zur verfügung und das haben wir quasi grade erst angesc hafft.
Mit Excel + Mysql ist das so nicht möglich?
In unserem Officepacket steht uns Access leider nicht zur verfügung und das haben wir quasi grade erst angesc hafft.
Moin Moin,
so wie ich das sehe: EDV zu Fuß
Mal als Anregung: Ein Angbot kann doch kopiert werden und der Kopf in Rechnung geändert werden. Das dürfte schneller gehen als alles neu einzutippen.
Grundsätzlich gibt es viele gute fertige Programme die sich leicht an deine Bedürnisse anpassen lassen. Sehr viele haben auch gleich eine Schnittstelle zur Buchhaltung.
Gerade für Handwerker gibt es Software wie Sand am Meer. Bei jeder Umstellung werden sich die Mitarbeiter umgewöhnen müssen, das ist normal.
Teste mit deinen Mitarbeitern diverse Lösungen und einigt Euch auf ein Programm, dass für Euch am besten passt. Testversionen gibt es eigentlich immer.
Selber Programmieren kostet Zeit (ungeübt bis zu zwei Jahre) und somit sehr viel Geld. Da ist der Umstieg auf eine fertige Lösung die günstigste und schnellste Lösung.
Suche mal nach Faktura und/oder nach WAWI. Ein paar € sollte dir so ein Programm Wert sein, wenn im Netzwerk mehrere Personen damit arbeiten sollen.
Empfehlungen:
http://www.lexware.de/shop/productDetails?orderNo=A08871
http://www.amicron.org/
Grüße aus Rostock
Wolfgang
(Netwolf)
so wie ich das sehe: EDV zu Fuß
Mal als Anregung: Ein Angbot kann doch kopiert werden und der Kopf in Rechnung geändert werden. Das dürfte schneller gehen als alles neu einzutippen.
Grundsätzlich gibt es viele gute fertige Programme die sich leicht an deine Bedürnisse anpassen lassen. Sehr viele haben auch gleich eine Schnittstelle zur Buchhaltung.
Gerade für Handwerker gibt es Software wie Sand am Meer. Bei jeder Umstellung werden sich die Mitarbeiter umgewöhnen müssen, das ist normal.
Teste mit deinen Mitarbeitern diverse Lösungen und einigt Euch auf ein Programm, dass für Euch am besten passt. Testversionen gibt es eigentlich immer.
Selber Programmieren kostet Zeit (ungeübt bis zu zwei Jahre) und somit sehr viel Geld. Da ist der Umstieg auf eine fertige Lösung die günstigste und schnellste Lösung.
Suche mal nach Faktura und/oder nach WAWI. Ein paar € sollte dir so ein Programm Wert sein, wenn im Netzwerk mehrere Personen damit arbeiten sollen.
Empfehlungen:
http://www.lexware.de/shop/productDetails?orderNo=A08871
http://www.amicron.org/
Grüße aus Rostock
Wolfgang
(Netwolf)
Hallo mbrkmann!
Also, der Meinung von SteffanKittel schließe ich mich an. Wenn schon über Excel, dann etwas Vernünfiges per VBA-Code mit UserForms und Datenbank. Die Frage ist nur, wer den VBA-Code schreibt und pflegt?
Das sollte eigentlich mit jeder Datenbank-Anbindung möglich sein, wobei sich meine Datenbankkenntnisse allerdings auf Access beschränken.
@ AndiW
Sorry, aber Deinen letzten Vorschlag finde ich geradezu anspruchslos und lächerlich
Gruß Dieter
Also, der Meinung von SteffanKittel schließe ich mich an. Wenn schon über Excel, dann etwas Vernünfiges per VBA-Code mit UserForms und Datenbank. Die Frage ist nur, wer den VBA-Code schreibt und pflegt?
Das sollte eigentlich mit jeder Datenbank-Anbindung möglich sein, wobei sich meine Datenbankkenntnisse allerdings auf Access beschränken.
@ AndiW
Sorry, aber Deinen letzten Vorschlag finde ich geradezu anspruchslos und lächerlich
Gruß Dieter
Zitat von @76109:
Also, der Meinung von SteffanKittel schließe ich mich an. Wenn schon über Excel, dann etwas Vernünfiges per
VBA-Code mit UserForms und Datenbank. Die Frage ist nur, wer den VBA-Code schreibt und pflegt?
Also, der Meinung von SteffanKittel schließe ich mich an. Wenn schon über Excel, dann etwas Vernünfiges per
VBA-Code mit UserForms und Datenbank. Die Frage ist nur, wer den VBA-Code schreibt und pflegt?
Nun ich würde mich da schon einarbeiten. Jetzt wird schon seit Jahren mit Excel so kompliziert gearbeitet da muss die Lösung nicht sofort her und wie ich das sehe, ist ja bei Datenbank + Excel/VBA auch eine schrittweise Erweiterung möglich.
Die Frage ist halt nur ob Excel über einen Connector auch die Daten vernünftig (in gewünschter Form) in eine Mysql-Datenbank Ein.- bzw auslesen kann?!
Ja, natürlich bringt ein sofortiger Umstieg auf eine prof. Software viele Vorteile. In unserm spez. Fall (hohe Mitarbeiterfluktuation) halte ich diese Lösungen aber i.d.R. für zu komplex. Es ist wirklich so, dass dann dort alle 3-5 Monate neue Mitarbeiter angelernt werden müssten.
Ich habe mir ja schon einige Lösungen angeschaut (Sage zb) aber das ist ja wirklich sehr komplex.
Werde aber noch mal mit den entsprechenden Mitarbeitern beraten
Ich habe mir ja schon einige Lösungen angeschaut (Sage zb) aber das ist ja wirklich sehr komplex.
Werde aber noch mal mit den entsprechenden Mitarbeitern beraten
Tag
Siehe hier:
http://www.greencube.ch/#footer&TT&Elements&TT&Footer&a ...;
Bei mehreren Kunden im Einsatz (vor allem auch bei Handwerkern und Garagen), bietet Adressverwaltung, Debitoren & Kreditorenverwaltung, Lagerverwaltung, FiBu, Fakturierung, Lohnverwaltung für 10 Mitarbeiter, etc. etc. Mehr brauchst du nicht. Die Software ist gratis, übersichtlich gegliedert und basiert auf MS SQL-Server 2008 Express Edition. Beim Backup musst du beachten, dass du entweder den SQL-Dienst stoppst, die DB sicherst und dann den Dienst wieder startest oder einen Dump der DB machst.
Siehe hier:
http://www.greencube.ch/#footer&TT&Elements&TT&Footer&a ...;
Bei mehreren Kunden im Einsatz (vor allem auch bei Handwerkern und Garagen), bietet Adressverwaltung, Debitoren & Kreditorenverwaltung, Lagerverwaltung, FiBu, Fakturierung, Lohnverwaltung für 10 Mitarbeiter, etc. etc. Mehr brauchst du nicht. Die Software ist gratis, übersichtlich gegliedert und basiert auf MS SQL-Server 2008 Express Edition. Beim Backup musst du beachten, dass du entweder den SQL-Dienst stoppst, die DB sicherst und dann den Dienst wieder startest oder einen Dump der DB machst.
Hallo mbrkmann!
Gruß Dieter
Zitat von @mbrkmann:
Die Frage ist halt nur ob Excel über einen Connector auch die Daten vernünftig (in gewünschter Form) in eine
Mysql-Datenbank Ein.- bzw auslesen kann?!
Wie bereits erwähnt, sollte es mit allen Datenbanken funktionieren. Die Frage ist nur das wie? D.h. die Verbindung (Connect) mit den entsprechenden Parametern herstellen und per SQL-Syntax die entsprechenden Daten in einen ADO-Recordset zu laden. Der ADO-Recordset ist praktisch eine Schnittstelle, in der unabhängig vom Datenbank-Typ, die Daten gelesen/bearbeitet/gespeichert... werden können.Die Frage ist halt nur ob Excel über einen Connector auch die Daten vernünftig (in gewünschter Form) in eine
Mysql-Datenbank Ein.- bzw auslesen kann?!
Gruß Dieter
@Dieter: Ich bin gerne "anspruchslos und lächerlich". Wenn ich den Leuten damit Helfen kann....
Ich habe nicht nur diesen Vorschlag gemacht. Aber für das gewünschte Ziel würde es genügen, denn: Wenn ich von Datenbank reden würde, wäre es mindestens eine MySQL - kein Access.
@mbrkmann: Du kannst mit dem Connector in der Datenbank alles machen - wie vernünftig das ganze ist, hängt von der Datenbankstruktur ab.
Solltest Du Dich für diese Lösung entscheiden, nimm Dir viel Zeit für das Konzept. Das erspart Dir Ärger, wenn Du das ganze mal erweitert werden soll.
Bsp: Statt eine Tabelle anzulegen in der die kompletten Adressinformationen ablegegt sind, kannst Du z.B. PLZ + Ort auslagern. Damit stellst Du sicher, das Du nicht 1000 Mal den selben Ort in der Datenbank hast, sondern nur einmal - referenziert wird dann über die sogenannten Primary Keys. Ist zwar etwas mehr Programmieraufwand - aber Zukunftsicher.
Für den Anwender hätte es sogar den Vorteil das er bei Kundenneuanlage nur die PLZ eingibt und der Ort automatisch eingetragen wird, sofern es den schon gibt.
Ich habe nicht nur diesen Vorschlag gemacht. Aber für das gewünschte Ziel würde es genügen, denn: Wenn ich von Datenbank reden würde, wäre es mindestens eine MySQL - kein Access.
@mbrkmann: Du kannst mit dem Connector in der Datenbank alles machen - wie vernünftig das ganze ist, hängt von der Datenbankstruktur ab.
Solltest Du Dich für diese Lösung entscheiden, nimm Dir viel Zeit für das Konzept. Das erspart Dir Ärger, wenn Du das ganze mal erweitert werden soll.
Bsp: Statt eine Tabelle anzulegen in der die kompletten Adressinformationen ablegegt sind, kannst Du z.B. PLZ + Ort auslagern. Damit stellst Du sicher, das Du nicht 1000 Mal den selben Ort in der Datenbank hast, sondern nur einmal - referenziert wird dann über die sogenannten Primary Keys. Ist zwar etwas mehr Programmieraufwand - aber Zukunftsicher.
Für den Anwender hätte es sogar den Vorteil das er bei Kundenneuanlage nur die PLZ eingibt und der Ort automatisch eingetragen wird, sofern es den schon gibt.
Hallo,
Ich würde vorschlagen, einige Stunden in Ausarbeitung von Standardabläufen & eine gute Dokumentation derselbigen zu verwenden. Gerade, wenn man viel Fluktuation hat, ist das wichtig.
Von einer Eigenentwicklung würde ich in fast allen Fällen abraten. Nicht nur, dass die Erstellung irre aufwändig ist, du musst das ganze ja auch pflegen. Und was passiert, wenn der Entwickler vom Zug überfahren wird?
Gruß
Filipp
halte ich diese Lösungen aber i.d.R. für zu komplex. Es ist wirklich so, dass dann dort alle 3-5
Monate neue Mitarbeiter angelernt werden müssten.
was bringt dich denn zu der Überzeugung, dass für eine von dir entwickelte Lösung keine Einarbeitung notwendig wäre? Was du später haben willst ist ja auch mehr als "ganz einfaches" Excel.Monate neue Mitarbeiter angelernt werden müssten.
Ich würde vorschlagen, einige Stunden in Ausarbeitung von Standardabläufen & eine gute Dokumentation derselbigen zu verwenden. Gerade, wenn man viel Fluktuation hat, ist das wichtig.
Von einer Eigenentwicklung würde ich in fast allen Fällen abraten. Nicht nur, dass die Erstellung irre aufwändig ist, du musst das ganze ja auch pflegen. Und was passiert, wenn der Entwickler vom Zug überfahren wird?
In meiner Vorstellung hatte ich halt gedacht, ich koennte das bestehende Excelsystem Schritt für Schritt umbauen.
Auch das halte ich für einen Trugschluss (bzw. für einen Nach- keinen Vorteil). Das bedeutet ja, dass du über einen langen Zeitraum ständig wieder Änderungen hast. Gerade, wenn man wieder weiß, wie alles funktioniert, kommt der ITler mit seinem nächsten blöden Update. Gerade nicht-IT-affine reagieren unwirsch, wenn sie jeden Monat was neues zur IT lernen müssen. Dann lieber einmal auf ein neues Produkt schulen und gut ist.Gruß
Filipp
Zitat von @filippg:
was bringt dich denn zu der Überzeugung, dass für eine von dir entwickelte Lösung keine Einarbeitung notwendig
wäre? Was du später haben willst ist ja auch mehr als "ganz einfaches" Excel.
Ich würde vorschlagen, einige Stunden in Ausarbeitung von Standardabläufen & eine gute Dokumentation derselbigen zu
verwenden. Gerade, wenn man viel Fluktuation hat, ist das wichtig.
Von einer Eigenentwicklung würde ich in fast allen Fällen abraten. Nicht nur, dass die Erstellung irre aufwändig
ist, du musst das ganze ja auch pflegen. Und was passiert, wenn der Entwickler vom Zug überfahren wird?
> In meiner Vorstellung hatte ich halt gedacht, ich koennte das bestehende Excelsystem Schritt für Schritt umbauen.
Auch das halte ich für einen Trugschluss (bzw. für einen Nach- keinen Vorteil). Das bedeutet ja, dass du über einen
langen Zeitraum ständig wieder Änderungen hast. Gerade, wenn man wieder weiß, wie alles funktioniert, kommt der
ITler mit seinem nächsten blöden Update. Gerade nicht-IT-affine reagieren unwirsch, wenn sie jeden Monat was neues zur
IT lernen müssen. Dann lieber einmal auf ein neues Produkt schulen und gut ist.
was bringt dich denn zu der Überzeugung, dass für eine von dir entwickelte Lösung keine Einarbeitung notwendig
wäre? Was du später haben willst ist ja auch mehr als "ganz einfaches" Excel.
Ich würde vorschlagen, einige Stunden in Ausarbeitung von Standardabläufen & eine gute Dokumentation derselbigen zu
verwenden. Gerade, wenn man viel Fluktuation hat, ist das wichtig.
Von einer Eigenentwicklung würde ich in fast allen Fällen abraten. Nicht nur, dass die Erstellung irre aufwändig
ist, du musst das ganze ja auch pflegen. Und was passiert, wenn der Entwickler vom Zug überfahren wird?
> In meiner Vorstellung hatte ich halt gedacht, ich koennte das bestehende Excelsystem Schritt für Schritt umbauen.
Auch das halte ich für einen Trugschluss (bzw. für einen Nach- keinen Vorteil). Das bedeutet ja, dass du über einen
langen Zeitraum ständig wieder Änderungen hast. Gerade, wenn man wieder weiß, wie alles funktioniert, kommt der
ITler mit seinem nächsten blöden Update. Gerade nicht-IT-affine reagieren unwirsch, wenn sie jeden Monat was neues zur
IT lernen müssen. Dann lieber einmal auf ein neues Produkt schulen und gut ist.
Eine Einarbeitung wäre vermutlich auch notwenig aber es macht schon einen Unterschied ob ich 5-10 extra Schaltflächen in Excel habe und nur bestimmte Daten in ein bekanntes System importiere oder aber eine komplette eigene Oberfläche mit eigenen Regeln usw. habe.
Dazu kommt das das meiner Erfahrung nach, auch eine noch so tolle Software immer Anpassungs.- und Pflegearbeiten mit sich bringt, die auch nicht unterschätzt werden sollten. Mal abesehen von der Abhängigkeit die sich einstellt wenn ich 1 Jahr alle Dokumente in einer neuen Software verwalte und dann vor einem größerem Problem stehe. Da kommt man an den prof. Support nicht mehr vorbei und ist erstmal Lahm gelegt (Kunden, Angebote, Rechnungen, Schriftstück).
Stirbt der Entwickler (was ich jetzt mal nicht hoffe *g*) ...installiert man Office neu und kann sofort mit dem alten System weiter machen. Ok, vielleicht müssen Kunden aus Mysql in Outlook importiert werden aber das ist auch schon alles.
Den von dir aufgeführten letzten Punkt halte ich auch nicht für entscheidend ...
oft neue Mitarbeiter bedeutet ja auch, nur wenige werden den gesamten Prozess mitmachen und diese (so hoffe ich) wachsen ja auch mit dem Projekt.
Wenn zb zuerst eine Datenbank mit Kunden erstellt wird und diese über eine Schaltfläche eingefügt werden koennen, ist die Veränderung für den User nun nicht so riesig. Mit der Pflege der Datensätze hätten die Mitarbeiter wenig zutun.
Ähnlich schätze ich es auch mit Artikeln usw ein.
Ich denke das eine Eigenetwicklung zumindest eine Überlegung Wert ist. Vorallem da unsere Struktur wirklich ...aehm besonders ist. Neben unseren 4 Handwerksgewerken, wird bei uns auch noch die Verwaltung für 2-3 andere Firmen gemacht (Gastronomie zb) , auch alles in Excel.
Ich danke dir aber für deine Einwände, werde mir mal Gedanken dazu machen.
Haben denn noch mehr Leute Erfahrungen zb mit CAO Faktura?
Im Netz findet man ja nicht so viel dazu (wiki usw habe ich natürlich gesehen). Wird noch aktiv an dem Projekt gearbeitet?
Bei Heise hält sich die Resonanz ja in Grenzen.
Danke nochmals für eure Einschätzungen
Hi,
also entweder mach es richtig - oder gar nicht. Du schreibst du möchtest das auf Excel/VBA o.ä. bauen? Halte ich für zimlich Unsinnig. Denn was passiert wenn du in einem Jahr das SP2 für dein office installierst (oder nen neues Office angeschafft werden muss) und dort dein Code nicht mehr läuft? Und du verlierst auch gleichzeitig die ganzen guten Dinge die eine DB so bringt - oder musst solche Filter umständlich bauen... Wie willst du z.B. die Stammdaten-Eingabe lösen?
Von daher gibt es für mich 4 Optionen:
a) Es bleibt wie es ist - weil war schon immer so und neu kostet immer Zeit...
b) Du baust das z.B. mit Access (oder Open-Office - die haben mittlerweile auch eine DB-Anwendung).
c) Du baust das ganze mit PHP/MySQL. Je nachdem wie fit du bist auch kein Thema - und die Angebote dann als PDF rausfeuern, dann hast du auch keine allzugroßen Probleme. Ok, die Eingabemaske muss natürlich vernünftig formatiert werden, ein (minimales) Rechtesystem brauchst du auch (sonst kann jeder ja alles mögliche ändern - eher schlecht...). Ob du das ganze jetzt in PHP, Java oder sonsteiner Sprache schreibst ist zweitrangig - die Sprache ist nur der kleinste Part...
d) Du kauft eine Anwendung - hier gibts genug zum Testen...
Du kommst eh nicht umzu dir verschiedene Programme anzusehen - bzw. wärst schön doof wenn du das nicht machst. Denn auch wenn du selbst Programmierst - dann hat ggf. Programm X noch eine Funktion die dir noch gar nicht in den Kopf kam - aber die richtig genial ist. Dasselbe gilt auch für Excel - ggf. hat man da ja noch ne Idee die einen aus so einem Programm gradezu anspringt während nur noch niemand darüber nachgedacht hat.
Wichtig ist jedoch: Rechne bei so einer Umstellung IMMER mit einem großen Zeitaufwand. Nicht nur das Programmieren selbst - sondern auch die Nebenkriegsschauplätze. Ich hatte z.B. in meinem Betrieb immer gesagt das es doof ist wenn nur ich das Programm kenne - WENN ich einmal das Unternehmen verlasse dann könnte das Probleme geben... Und grade wenn da das ganze Angebots-/Rechnungssystem von betroffen ist dann muss man da einfach auch dem Chef gegenüber ehrlich sein.
Schönen Gruß
Mike
also entweder mach es richtig - oder gar nicht. Du schreibst du möchtest das auf Excel/VBA o.ä. bauen? Halte ich für zimlich Unsinnig. Denn was passiert wenn du in einem Jahr das SP2 für dein office installierst (oder nen neues Office angeschafft werden muss) und dort dein Code nicht mehr läuft? Und du verlierst auch gleichzeitig die ganzen guten Dinge die eine DB so bringt - oder musst solche Filter umständlich bauen... Wie willst du z.B. die Stammdaten-Eingabe lösen?
Von daher gibt es für mich 4 Optionen:
a) Es bleibt wie es ist - weil war schon immer so und neu kostet immer Zeit...
b) Du baust das z.B. mit Access (oder Open-Office - die haben mittlerweile auch eine DB-Anwendung).
c) Du baust das ganze mit PHP/MySQL. Je nachdem wie fit du bist auch kein Thema - und die Angebote dann als PDF rausfeuern, dann hast du auch keine allzugroßen Probleme. Ok, die Eingabemaske muss natürlich vernünftig formatiert werden, ein (minimales) Rechtesystem brauchst du auch (sonst kann jeder ja alles mögliche ändern - eher schlecht...). Ob du das ganze jetzt in PHP, Java oder sonsteiner Sprache schreibst ist zweitrangig - die Sprache ist nur der kleinste Part...
d) Du kauft eine Anwendung - hier gibts genug zum Testen...
Du kommst eh nicht umzu dir verschiedene Programme anzusehen - bzw. wärst schön doof wenn du das nicht machst. Denn auch wenn du selbst Programmierst - dann hat ggf. Programm X noch eine Funktion die dir noch gar nicht in den Kopf kam - aber die richtig genial ist. Dasselbe gilt auch für Excel - ggf. hat man da ja noch ne Idee die einen aus so einem Programm gradezu anspringt während nur noch niemand darüber nachgedacht hat.
Wichtig ist jedoch: Rechne bei so einer Umstellung IMMER mit einem großen Zeitaufwand. Nicht nur das Programmieren selbst - sondern auch die Nebenkriegsschauplätze. Ich hatte z.B. in meinem Betrieb immer gesagt das es doof ist wenn nur ich das Programm kenne - WENN ich einmal das Unternehmen verlasse dann könnte das Probleme geben... Und grade wenn da das ganze Angebots-/Rechnungssystem von betroffen ist dann muss man da einfach auch dem Chef gegenüber ehrlich sein.
Schönen Gruß
Mike
Ich nutze für sowas schon seit Jahren JTL-WAWI.
Kostenlos, Mehrbenutzerfähig, Mandantenfähig, Datenbankbasiert und wirklich einfach.
http://www.jtl-software.de/produkte/jtl-wawi/
Wenn ihr sowieso eine hohe Fluktuation in dem Bereich habt, sollte es nicht so schwer sein, ein neues System einzuführen. Eine Lösung mit Excel wird nie zu einem vernünftigen Ergebnis führen.
Kostenlos, Mehrbenutzerfähig, Mandantenfähig, Datenbankbasiert und wirklich einfach.
http://www.jtl-software.de/produkte/jtl-wawi/
Wenn ihr sowieso eine hohe Fluktuation in dem Bereich habt, sollte es nicht so schwer sein, ein neues System einzuführen. Eine Lösung mit Excel wird nie zu einem vernünftigen Ergebnis führen.
Zitat von @mbrkmann:
oft neue Mitarbeiter bedeutet ja auch, nur wenige werden den gesamten Prozess mitmachen und diese (so hoffe ich) wachsen ja auch
mit dem Projekt.
oft neue Mitarbeiter bedeutet ja auch, nur wenige werden den gesamten Prozess mitmachen und diese (so hoffe ich) wachsen ja auch
mit dem Projekt.
Das ist eine Fehleinschätzung hoch drei.
Oft neue Mitarbeiter bedeutet zunächst, dass in dieser Firma irgendwas nicht rund läuft. Eine Fluktuation wo ich alle 3 bis 5 Monate die
Leute neu einarbeiten kann, das gibt es vielleicht bei Direktvertrieben im Außendienst. Diese Mitarbeiter haben aber wohl nix mit Excel-Files
am Hut. Aber wenn im kaufmännischen Bereich (egal ob Handwerkbetrieb, Handel, Produktion, ...) eine so hohe Fluktuation herrscht, dann
muss da zuvorderst eine Lösung her, die die Leute länger zu halten geeignet ist.
Ist euch bekannt woher diese hohe Fluktuation kommt?
Wenn es nicht am Führungsstil liegt, z.B. weil der Boss ein A.....h ist, dann wohl an irgendwas anderem, eventuell eben an den Arbeitsbedingungen
und dazu gehört ja wohl regelmäßig auch die IT-Bedienbarkeit und die wird durch Aufblähen einer an sich schon ungeliebten Sache nicht besser,
eher im Gegenteil. (Nur mal so zum drüber nachdenken.)
Ob es wirklich daran liegt - who knows. Aber die Handwerker/ Handwerksmeister rühren nach deiner Schilderung die EDV sowieso eher nicht an.
Also betrifft es wohl nur den kaufmännischen Bereich. Wenn also die IT tatsächlich der Reibungspunkt ist, dann kannst du auch gleich eine Komplettlösung
einführen.
Ich würde erst mal die Betroffenen fragen, wieso sie nach so kurzer Zeit schon wieder weg wollen. Und ruhig auch die Zusatzfrage wegen
der EDV-Bedienbarkeit stellen. Erst wenn das als Ursache ausgeschlossen ist, kannst du ungefähr abschätzen, ob sich der Aufwand für
Option A (Excel plus ggf. Access),
Option B (Standalone-Komplettlösung wie auch immer) oder
Option C (wie immer die auch aussehen mag)
überhaupt rechnet. Weil sonst fängt nach Deiner Fluktuation *g* der nächste IT-Verantwortliche von vorne an. Klar was ich meine?
nun, woran diese hohe Fluktuation liegt, lasse ich hier jetzt mal unbeantwortet. soviel: es liegt nicht an der Edv und oder den direkten Arbeitsbedingungen.
aber stimmt schon - es liegt da etwas im argen..leider kann ich als Edvmitarbeiter da nun wirklich nichts dran ändern.
ich möchte euch nochmals für die Ideen und Meinungen danken. Vermutlich werde ich das Excelsystem etwas pimpen und mittelfristig zu einer Komplettlösung raten.
Gruß
marco
aber stimmt schon - es liegt da etwas im argen..leider kann ich als Edvmitarbeiter da nun wirklich nichts dran ändern.
ich möchte euch nochmals für die Ideen und Meinungen danken. Vermutlich werde ich das Excelsystem etwas pimpen und mittelfristig zu einer Komplettlösung raten.
Gruß
marco
Hi,
vielleicht ist das Interessant für dich
http://www.webdesign-facts.de/joomla-cms/joowi/14-joowi-joomla-warenwir ...
ist ein WaWi auf Joomla bassierend und grad in der Entwicklung, ne Demo gibt es schon und ist frei Testbar, denke da wäre so ziemlich alles damit machbar was du möchstest. Ich habs schon getestet und finde es wirklich gut...
Grüße
Chris
vielleicht ist das Interessant für dich
http://www.webdesign-facts.de/joomla-cms/joowi/14-joowi-joomla-warenwir ...
ist ein WaWi auf Joomla bassierend und grad in der Entwicklung, ne Demo gibt es schon und ist frei Testbar, denke da wäre so ziemlich alles damit machbar was du möchstest. Ich habs schon getestet und finde es wirklich gut...
Grüße
Chris
