Etwas Offtopic:
Das Controlling des Unternehmens muss Projektdaten aus den einzelnen Fachabteilungen sammeln, überprüfen und dann in ein Excel-Sheet(1) übertragen. Die Struktur dieser Tabelle ist festgelegt und wird zu einem späteren Zeitraum in eine Lotus Notes-Anwendung übertragen. In dieser Tabelle werden komplexe Berechnungen durchgeführt...
Wer schreibt eigentlich solche Anforderungen?
Ich beginne mit einem Tool, welches sehr flexibel aber wenig steuerbar (aus IT-Leistungssicht) ist : Excel.
Sätze wie:
wird zu einem späteren Zeitraum in eine Lotus Notes Anwendung übertragen
kenne ich, wir hier alle. Zu diesem Zeitpunkt ist das Kind üblicherweise bereits in den Brunnen gefallen - es gibt sagen wir mal 25 bekannte und 100 unbekannte Varianten des Excel Sheets, alle mit unterschiedlichen "Datenmodellen"
Und weiterhin stellt sich die Frage: Warum soll das ausgerechnet nach Notes übertragen werden - sicherlich für vieles Tool der Wahl aber für Rechenaufgaben?
Am Ende kommt eine vollkommen vermurkste Anwendung raus, die wahnsinnigen manuellen Aufwand in der Wartung verursacht und wieder Anwender in die "Notes ist scheiße" Fraktion zieht.
Eigentlich sollte man solche Projekte ablehnen, weil:
Wenn der Umfang der Anwendung zu Beginn auch nicht annähernd klar ist kann ich kein Datenmodell erstellen.
Mit Excel als Frontend kann nicht/kaum sichergestellt werden, dass das Datenmodell eingehalten wird
Wegen des 'Shit in shit out Prinzips' verläuft der Rest der Lebenszeit der Anwendung entsprechend.
Ohne jetzt die Details zu kennen: Alles was mit Berechnungen von Finanzwerten zu tun hat, sollte in relationalen Systemen abgelegt werden - das bietet sich einfach an.
Wenn ich am Ende ohnehin da ende, kann ich auch gleich da anfangen. Wenn es unbedingt Notes sein muss: XPage, die (weitestgehend) in SQL-XYZ speichert. Je weniger System-Übergänge es gibt um so besser/einfacher ist das. Weiß jeder hier (oder?).
Weiterhin hat das den Vorteil für Dich, dass Du auf Dir hoffentlich bekannten Technologien Java und JavaScript aufsetzen kannst und nicht soooo tief in die Abgründe des doch sehr proprietären Notes tauchen musst. Hier ist alles anders - nicht alles ist schlechter oder besser - aber eben anders.
Die nächste Frage ist auch, was man wirklich von Dir erwartet: In 3 Monaten ohne Vorwissen scheitert das Projekt meiner Meinung nach sicher(unabhängig von Deinem Talent), weil diese Kombination einfach fürchterlich viele Fallen und Probleme beinhaltet. Ausserdem sieht das nach einem Kaugummiprojekt aus: Erst kaut man ziemlich lange und dann klebt es einem ziemlich lange am Fuß. Aufgrund der vorausgesetzten Architektur ist zum Beispiel keine einfache Wartbarkeit und Erweiterbarkeit möglich.
Drei Monate für Einarbeitung in Thema (möglicherweise in die Unternehmenswelt), Einarbeitung in Technologie, Planung und Umsetzung der Lösung sowie anschließender Dokumentation für viel zu knapp. Da würde ich auf jeden Fall nachverhandeln. Vielleicht in Richtung: Was ist das eigentliche Problem? Wie sieht der abzubildende Prozess aus? Welche Mittel kann man nutzen, um das Problem effektiv, effizient umsetzen kann nicht ohne Folgekosten bei Wartung und Erweiterung aus den Augen zu lassen. Da kannst Du Tonnen an Wissen ansammeln hinsichtlich Anforderungserfassung, Pflichtenheftverfassung, Tool-Evaluation, Tool-Markt, Datenmodellierung, Geschäftsprozessmodellierung etc..
Im Grunde wäre das ein Nachweis Deiner Fähigkeiten als Wirtschaftsinformatiker.
Und schließlich noch ein Wort an die IT-Verantwortlichen dieser Welt:
Excel ist kein geeignetes Mittel um Datenverarbeitung strategisch zu betreiben. Es hilft dann und wann - aber wann immer es in dauerhafte Lösungen integriert werden soll verursacht es Datenfriedhöfe, Inkonsistenzen, niedrige und nichtprüfbare Qualität (wer prüft die Qualität der verteilten Excel Sheets), hohen Wartungsaufwand uns schlechte Erweiterbarkeit. In diesem Sinne empfinde ich auch die Erklärung einzelner IT-Verantwortlicher auf Sharepoint zu wechseln, da man dort besser mit Excel und Word arbeiten könne auch als vollkommene Bankrotterklärung.