Lieferanten- und Kunden-Datenbank anlegen... WIE?

[alexkunde]

WOW, da hab ich ja ne richtige Lawine losgetreten...!  

also, weiß jetzt gar nicht, wo ich anfangen soll...

Habe am Freitag in diesem Forum mein erstes Posting überhaupt geschrieben, in der Hoffnung bei der Entwicklung/Implemetierung einer Lieferanten-Datenbank (mit möglicherweise erweiterter Funktion) auf einem Domino-Server in einem kleinen Unternehmen Hilfe zu bekommen. Dieses Unternehmen hat 12 Mitarbieter und keine eigene IT-Abteilung... also vegleicht "mein" Unternehmen nicht mit einem DAX-Unternehmen, die Domino-Server für 50.000 MA aufsetzen und über entsprechende Etats verfügen. Ich studiere auch nicht Informatik, wie viele wahrscheinlich denken, sondern Wirtschaftsingenieurwesen. Und was machen Wirtschaftsingenieure? Sie prüfen, wie und unter welchen Bedingungen und Gesichtspunkten sich gegebene Problemstellungen umsetzen lassen! Einen Lotus-Domino-Server einzurichten, ist nicht schwer... auch nicht für einen Wirtschaftsingenieur, zumindest nicht, diesen innerhalb eines kleinen Unternehmens produktiv einzusetzen. Dafür hab ich mir ein paar Bücher gekauft, bzw. "kaufen lassen", wobei ich noch gar nicht dazu gekommen bin, diese ganzen Bücher durchzuarbeiten.  Sicherheitsvorkehrungen zu schaffen, dass ein Domino-Server seinen Dienst für Zigtausend Mitarbeitet leistet, ist dagegen sicherlich nur mit viel größerem Wissen möglich und mit viel mehr Aufwand verbunden... das sollten dann auf jeden Fall Spezialisten übernehmen, wie ihr welche seid und keine Generalisten, wie ich einer werde!!!
Was wollte ich noch mal hier? Ach ja... fragen, ob es bereits Lösungen für eine Adress-Datenbank gibt, mit deren Hilfe ich mir vielleicht ein paar Anregungen holen kann. (Im Internet gibt es doch für alles irgendwelche Lösungen und Templates, gerade im Open-Source-Bereich - da wird man normalerweise immer fündig und braucht dann nur eingeschränkte Kenntnisse im Programmieren. Klar, Leistung muss bezahlt werden...  ist mir auch bewußt! Ich dachte eben, dass es auch im Lotus-Notes-Bereich so etwas ähnliches wie OpenSource gibt). Und sollte der Fall eintreten, dass es nix gibt, und schon gar nicht kostenlos, dann sag ich das meinem Chef, schreib das so in die Diplomarbeit rein und dann ist das auch ein Ergebnis! Ja, und was die "Nieten im Nadenstreifenanzug in der obersten Etage" eines mächtigen Konzerns angeht, was die entscheiden, ist mir egal, bzw. NOCH egal... ich will nur meine Diplomarbeit anständig hinter mich bringen.

Also, ich wollte von euch keine fertige Lösung für ein hochkompliziertes CRM-System vorgekaut bekommen, alles was ich wollte, waren ein paar Tips (in Form von Links oder Büchertips), wie ich mit meinem Problem am besten fertig werde. Natürlich bin ich hier her gekommen, um von euch zu lernen... jeder von euch hat ja auch mal klein angefangen.

Ich mach jetzt mal Schluss und hoffe, auch weiterhin von euch noch viel lernen zu dürfen, wenn ich euch mit meinen kleinen Domino-Problemchen auf die Nerven gehe...

In diesem Sinne, euch allen einen schönen Sonntag noch!

Alex

[Semeaphoros]

Opensource gibt es hier:

www.openntf.org

Allerdings ist die OpenSource-Bewegung unter ND nicht soo besonders gross und ich denke, das hat seine Gründe

[eknori]

Es ist zwar schon Abend, aber ich glaube, Du bist mit dem falschen Fuss aufgestanden

na, dann halte ich mich wohl besser in Zukunft aus solchen Diskussionen raus.

[Thomas Schulte]

so und damit ihm (alexkunde) jetzt auch noch ein bischen geholfen wird, Hier http://www.openntf.org/projects/pmt.nsf/1af5f59bae92986c85256bae000f898c/f49885bda4e1739f88256d330047e33d!OpenDocument findest du ein einfaches CRM System.

Thomas

[smoky]

Hallo,

ich mische mich hier mal kurz ein.

Also ich bin auch kein Profi und habe mir alles im Selbstlern verfahren angeeignet. (Was man bei meinen Arbeiten mitunter noch immer merkt)  

Ich würde so vorgehen:

Zuerst mußt du feststellen welche felder du brauchst. diese Info bekommst du am besten von den Leuten die bisher mit den Lieferanten arbeiten. Z.B. Firmenname, Ansprechpartner, Zuständigkeiten usw.

Danach erstellst du eine leere Datenbank mit einer Maske und eben diesen Feldern und schmückst sie optisch ein wenig aus.
Bei mehreren ansprechpartner in einer Firma legst du die Firma als Hauptdokument und die Personen darunter als Antwortdokumente an.

Nun kommt es darauf an was noch mit dieser Adressen Sammlung gemacht werden soll.
zum Beispiel eine weitere Datenbank für Schriftverkehr, E-Mail Adressierung.

Vielleicht hilft dir das für den Anfang weiter?


Smoky

[koehlerbv]

Schön geschrieben, smoky ;-)
Ich hatte das vorher ja auch schon postuliert: 'Ne neue Datenbank "from the scratch" aufziehen, und nebenbei (!) in anderen Apps stöbern, wie die denn das gemacht haben.

Ich glaube, was wichtiges haben wir alle vergessen: Wie lautet denn eigentlich die genaue Aufgabenstellung ? In welchem Zusammenhang steht denn die Lieferanten- und Kunden-Db zu Deiner Diplomarbeit ? Ich glaube, dass wir so am ehesten Ansätze finden können, Dir zu helfen. Wichtig zu wissen wäre auch: Wie produktiv soll denn das Teil mal in Deiner Praktikumsfirma eingesetzt werden ? Wieviel Zeit kannst Du in den Notes-Teil investieren ? Macht es überhaupt Sinn für Dich, zu programmieren ? Da hängt soviel vom Thema Deiner Diplomarbeit ab ...

Sag' mal genauer an - wir helfen schon (all' die anderen "Nebengeräusche" sind ja schon in einen Off-topic-thread verschoben ;-)

Ciao,
Bernhard

[heini_schwammerl]

Hi,

bei all dem Weltschmerz scheint mein Hinweis bezüglich der Notes 6 Version jetzt untergegangen zu sein.
Ich denke unter Nutzung der Standard Templates ließe sich für eine 12 Mann/Frau Firma schon etwas zaubern was zumindest rudimentär funktioniert und ggf. aufgebläht werden kann.
Schade eigentlich.
Gruß

Heini

[alexkunde]

Leider können wir nicht notes 6 einsetzen, die Firma besitzt nur eine 5er-Lizenz.

Die Zielvorstellung dieser Datenbank hat sich mittlerweile ein wenig geändert, bzw. mein erstes Projekt wird eine Kunden/Vertriebsdatenbank sein. Diese Datenbank soll folgende Informationen beinhalten:

- Kundennummer
- Kunden-Firmenname
- Kunden-Ansprechpartner mit Telefonnummer
- Kunden-Adresse (Tel, Ort, Mail, www, ...)
- Art der Aktion, mit welcher der Kunde gewonnen werden konnte (könnte vielleicht per Drop-Down gelöst werden)
- Datum des letzten Kontaktes zwischen einem Vertriebler meines Unternehmens mit dem Kunden
- Kontakthistorie (wann und mit welcher Person hat der Kontakt stattgefunden und was war das Ergebnis des Kotaktes)
- Kategorie des Kunden (Unterscheidung zwischen A, B und C)
- Allgemeine Info zum Kunden (vielleicht ließen sich an dieser Stelle kundenspezifische Dokumente an den Datensatz anhängen)
- Datum des nächsten geplanten Kontaktes mit dem Kunden
- Zuständiger Vertriebler für den nächsten Kontakt mit dem Kunden

Wenn möglich, sollte des Datum, an dem der nächste Kontakt stattfinden soll, automatisch in den Kalender des zuständigen vertrieblers eingetragen werden, damit dieser am Tag des geplanten Kontaktdatums an diesen Termin/Aufgabe in seinem Lotus Notes erinnert wird.

Meint ihr, ich krieg das hin? Über welches Template könnte dies gelöst werden?

[Semeaphoros]

Das ist eine ganze Menge Arbeit weit entfernt von den Basics ...... insbesondere wenn dann noch in bestehende Strukturen wie der Kalender eingegriffen werden soll, da scheitern selbst erfahrene Leute ....

[Gandhi]

Solange die Applikation 'dumm' sein soll und nur Eingaben von Benutzern gepflegt werden müssen, kann man die pernames.ntf als Basis verwenden (oder eine komplett neue Datenbank erstellt werden).
Diese zunächst auf die Personendaten reduzieren und dann die noch fehlenden Felder ergänzen.
Die Historie z.B. als RTF.
Von der Implementierung von Funktionen wie Terminsuche rate ich bei einer auf diesem Weg erstellten Anwendung aber ausdrücklich ab. Auch sollten die Erwartungen nicht zu hoch sein. Diese Applikation dient dann nur zur Ablage von Daten.
Weiterhin musst Du dann noch jede Menge Views einbauen, damit die Dinge gefunden werden.
Sollte man mehr von Dir erwarten würde ich - im Interesse aller, auch Deiner Vorgesetzten vor allem aber von Dir - kategorisch abblocken.
Fange auf jeden Fall klein an und erarbeite Dir die Basics. Code a little test a little.

Und noch was: Meine Einstellung zu dem Vorgehen Deiner Firma im Gesamten heiße ich deswegen immer noch nicht gut. Sowas sollten besser erfahrenere Menschen implementieren. Hoffentlich erwartet da niemand zu viel.

Bevor Du damit anfängst rate ich Dir dennoch dringend zunächst ein Buch zu dem Thema Anwendungsentwicklung unter Notes zu lesen. Diese investierte Zeit wird sich im Laufe des Projektes mit sicherheit bezahlt machen.

[Semeaphoros]

Genau, mit der Reduktion auf nur wesentliches, einfaches und machbares könnte ein Weg gefunden werden, Ghandi hat das jetzt sehr gut umschrieben.

[ata]

... in der Konzeption hat sich das ja nun gewandelt. Es handelt sich nicht mehr nur um eine Adressdatenbank, dazu gekommen ist eine Art Vertriebsunterstützung - ich möchte es mal Kontaktmanagement nennen...

... daraus ergeben sich 2 verschiedene Zweige, der eine ist die Datenpfelge zum Kunden, und der andere ist die Pflege der Kontakte. Ich würde dies in 2 Vorgängen trennen.

Adresspflege:
- Kundennummer
- Kunden-Firmenname
- Kunden-Ansprechpartner mit Telefonnummer
- Kunden-Adresse (Tel, Ort, Mail, www, ...)
- Art der Aktion, mit welcher der Kunde gewonnen werden konnte (könnte vielleicht per Drop-Down gelöst werden)
- Kategorie des Kunden (Unterscheidung zwischen A, B und C)
- Allgemeine Info zum Kunden (vielleicht ließen sich an dieser Stelle kundenspezifische Dokumente an den Datensatz anhängen)

Kontaktpflege:
- Datum des letzten Kontaktes zwischen einem Vertriebler meines Unternehmens mit dem Kunden
- Kontakthistorie (wann und mit welcher Person hat der Kontakt stattgefunden und was war das Ergebnis des Kotaktes)
- Datum des nächsten geplanten Kontaktes mit dem Kunden
- Zuständiger Vertriebler für den nächsten Kontakt mit dem Kunden

... in der Maske der Kontaktpflege kann dann eine Aktion einen Termin für den zuständigen Vertriebler erstellen...

... die Addresspflege lässt sich mit kleinen Erweiterungen aus einer Notes-Adressdatenbank ertellen. Du benötigst dazu die Maske für einen Adresseintrag und die dazugehörigen Teilmasken, Dialogmasken und ScriptLib's. Die Erweiterungen wären zum Beispiel die Kundennummer, der zuständige Vertriebler etc. Zusätzliche Informationen lassen sich als Antwortdokumente zuordnen...

... bei der Kontaktpflege würde ich eine neue Maske verwenden, in der du eben all die Informationen aufnimmst, die solch einen Kontakte prägen - den Grund der Kontaktaufnahme, Datum, Termine etc - also alles von der Kontaktaufnahme und Abwicklung...
.. zusätzliche Informationen zum Kontakt lassen sich als Antwortdokumente zuordnen...

das wär mal so ein erster Brain-Storm zu deiner Aufgabenstellung...

ata

[Gandhi]

Mal so als Inspiration:
Aktionen zu den Kontakten alsl Antwortdokumente realisieren.
Kontaktdaten als Hauptdokumente.
Aber zuerst würde ich eine saubere Kontaktdatenbank entwickeln, in der nur die Kontaktdaten ermittelt werden - ganz ohne Vertriebsaktivitäten. Das würde ich erst nach Vollzug der ersten Stufe bauen.

[Gandhi]

Ach und noch ein ganz wichtiger Hinweis:
Schreib zuerst ein Lasten/Pflichtenheft und lass Dir das unterschreiben.
Nur so bist Du vor späteren 'Ach da fällt mir noch ein ganz tolles Feature ein' Anfällen der Auftraggeber so einigermaßen sicher.
Außerdem unterstützt das Schreiben von so einem Ding den strukturierten Denkprozess - und Du kannst es in den schriftlichen Teil Deines Diploms einfließen lassen.

[ata]

@Gandhi

... was verstehst du unter Kontaktdaten - die Adressdaten oder die Kontaktdaten?

... ich würde die Kontakte nicht als Antwortdokumente unter die Adressen hängen. In meiner Task-DB habe ich mir etwas ähnliches realisiert. Ich habe in den Adressdaten eine eingebettete Ansicht, die alle die Person betreffenden Aufgabe nach Status darstellt - damit brauch ich keine hierarchischen Dokumente...

ata

[Gandhi]

Mit Kontaktdaten meinte ich Adressdaten.
Die Idee mit der eingebetteten Ansicht finde ich gut. Kann man so machen. Auf jeden Fall.
Andererseits muss man ja auf jeden Fall die Incidents zu einer Adresse mit dieser verknüpfen. Und am einfachsten ist das m.e. mit einer Hierarchie.

[ata]

... hierarchische Dokumente haben Vorteile, aber auch Nachteile. Sie lassen sich nur einem Hauptdokument zuordnen. Wenn der Kontakt nun 2 Kunden betrifft, dann musst entweder 2 Vorgänge öffnen, oder einem einen Link hinterlegen - bei Auswertungen wird es dann erst richtig kompliziert...

... Über kategorisierte Ansichten habe ich die Möglichkeit der Mehrfachzuordnung...

.. du hast aber den wichtigen Punkt bereits angesprochen: die Referenzierung, der gemeinsame Nenner. Und hier würde zum Beispiel ein Aliaswert ziehen - "Name des Kunden | DocID_des_Adressdokumentes". Damit kannst du dann - vorrausgesetzt beide Bereiche werden in einer DB abgehandelt - in deinem Kontaktformular die Adressdaten des Kunden spiegeln - so habe ich das bei mir eingebaut...

ata

[Gandhi]

Ja, dass nur eine Adresse als Parent definiert werden kann schränkt die Sache ein - wobei es meiner Meinung nach aber auch sauberer ist.
Darüberhinaus ermöglicht die Hierarchie es, auch Antworten auf Antworten abzubilden.
Beispiel:
Ich schicke der Adresse einen Brief (Spam ). Auf diese Aktion folgt dann irgendwann ein Anruf.
Somit ist dann der Anruf die Antwort auf den Brief, der eine Antwort auf die Adresse ist.
Mit eingebetteten Ansichten ist das dann nicht mehr ganz so trivial (berichtige mich bitte, sollte ich irren).
Dennoch würde ich auf jeden Fall eine Ansicht in der Adressmaske einbauen - dann eben mit den Antworten und deren Descendanten.

Auswertungen habe ich ganz aus meinen Überlegungen gelassen - schließlich soll ein Newbie das ganze implementieren.

[Semeaphoros]

Dreistufig ist gar nicht so schwierig, schwieriger wirds, wenn Du noch mehr Ebenen haben willst, aber auch das ist möglich. Frage ist, wann man mehr als 3 Ebenen braucht, eigentlich nur selten

[Thomas Schulte]

Zwei Pakete die die von euch genannten unterschiedlichen Ansätze richtig gut darstellen (das heist nicht das sie gut sind) sind Gedys (pleite) Office und OCTO Office (Globalware).
Gedys hat diesen alles ist ein Hauptdokument Ansatz durchgezogen und Globalware den alles ist Hierarchie Ansatz. Wenn du beide Konstruktionen miteinander vergleichst siehst du  die jeweiligen Schwachstellen.
So hat Gedys einen Irrsinnsaufwand betreiben müssen um Schlüsselwerte die durchgereicht werden mussten, wie z.B. eine Adressänderung der Firma, die bei allen Ansprechpartnern ebenfalls zutrifft zu realisieren. Die haben da mit eigenen generierten Schlüsseln gearbeitet und noch so einiges mehr angestellt. Bernhard kann ein Lied davon singen, was es bedeutet Dokumente mit und zwischen Gedys Office Datenbanken abzugleichen.
Globalware hat z.B. erst in den letzten Versionen das Problem gelöst, was stelle ich mit Dokumenten an, die zu zwei oder mehr Basisdokumenten gehören. Zum Beispiel, wie kann ich eine Projektstruktur übers CRM legen (mehrere Beteiligte, unterschiedliche Firmen zuordnen). Mittlerweile funktioniert es, die Programmierer mussten die Anwendung aber ziemlich verbiegen.

Beide Ansätze haben ihre Vorteile. Der Hierarchische ist meiner Meinung nach für Anfänger besser geeignet. Die Grenzen bemerkt man erst relativ spät und ist dann vom Verständnis her eher in der Lage außen rum zu programmieren.
Der Ansatz von Ata ist wenn "geplant" vorgegangen wird vielleicht der langfristig bessere. Für einen Domino "Anfänger" ist er aber absolut zu schwer. Hier brauchst du eine Menge Erfahrung mit diesem System um das mit einem brauchbaren Ergebnis abzuschließen.

Thomas