Auch wenn wir jetzt etwas in OT abdriften
Ich bin davon überzeugt, dass Beiträge von Leuten, die Ahnung von dem haben was sie tun, hilfreich sind.
Vielleicht nicht unbedingt für den TE, aber doch für den einen oder anderen der in der Lage ist, über den Tellerrand zu schauen und sich auf diesem Weg weiterzubilden...
Woraus aber auch der Umkehrschluss resultiert, dass die Programmierer 80% der Softwareleistung für'n Ar.. erstellen. Was für eine Verschwendung von Ressourcen.
DAS sollten sich aber auch mal SÄMTLICHE Software-"Ersteller" sowas von hinter die Ohren schreiben! Und nicht nur die!
Wobei aber immer hinterfragt werden sollte, aus welchem Grund der/die Programmierer 80% der Funktionalität "umsonst" erstellt. Antwort: weil er schlichtweg absolut keine Ahnung von dem hat, was er dort tut/tun soll!
Wie auch, denn sein Job ist, die meist nur vage formulierten Vorgaben von Leuten, die meist auch nur wenig Ahnung von den konkret ablaufenden Prozessen haben, in Software umzusetzen.
Und das macht er dann auch! Und zwar so, wie ER es für richtig hält. Da wird dann auch mal (kein Witz jetzt, Beispiel aus der Praxis) anstatt den Kunden nach den fachspezifischen Vorgängen/Termini zu fragen, "mal eben" ein Wikipediaartikel hergenommen um überhaupt zu verstehen, um was dem Kunden VIELLEICHT geht. Um im Anschluß daran ein Softwaremodul zu präsentieren, das in keinster Weise funktioniert.
Diskussionen bis hin zur Geschäftsleitungsebene, die aber (beide, sowohl Auftraggeber als auch SW-Ersteller) wiederum gar nicht wissen, was überhaupt erreicht werden sollte.....
Daher auch mein Hinweis zum Lasten- und Pflichtenheft. Vgl. die Grundsätze von "agilem" Projektmanagement und/oder "Voice of the Customer" bei 6Sigma.
Ich hatte auch schon mit meiner liebreizenden Art den Geschäftsführer eines (weltweit tätigen) Softwareunternehmens zur Weißglut gebracht, weil ich immer wieder darauf hingewiesen hatte, MEINE Vorgaben GENAU SO WIE BESCHRIEBEN umzusetzen. Und nur genau diese Umsetzung wird dann auch bezahlt....
Und genau hier liegt der Hase im Pfeffer! Der Ablauf beim Softwareersteller ist nämlich folgender: Lastenheft anschauen, grobe Peilung Machbarkeit/Umsetzung/Zeitplan ermitteln und Angebot abgeben mit (gesalzenem) Preis.
Nach Auftragseingang Projekt nach hinten schieben (ist doch eh nur pillepalle und ausserdem haben wir noch genug Zeit...) und dann auf der letzten Rille loslegen.
Die Umsetzung der Vorgaben wird auch nicht mit dem Kunden besprochen, dafür ist keine Zeit und der Kunde könnte merken, dass es nicht vorwärts geht!
Stattdessen wird sich etwas aus den Fingern gesaugt (wird schon so hinhauen...) und Praxisfern umgesetzt. Bis der Kunde merkt, dass er das in Auftrag gegebene Modul so nicht anwenden kann, ist es zu spät. Der Softwareersteller will seine bisherige und unnütze Arbeit bezahlt haben, und der Kunde ein anwendbares Produkt. DAS kann nur zu Unzufriedenheit bei beiden führen....
Ich kann jetzt nichts über alle Anfragen sagen. Aber die 98% kommen mir einfach sehr hoch vor. Einfach weil ich denke, dass es sehr oft noch Bedarf gibt.
Relativiere mal die 98%....
WER fragt an? Derjenige, der von Excel/VBA keinerlei Ahnung hat. Und auch nicht von AutoIt! Hätte er von einem von beiden Ahnung, würde er nicht fragen, sondern hätte eine Lösung!
Keine Ahnung von irgendetwas zu haben ist ja per se nicht das Problem, das Problem liegt meist im Bereich X-Y.
Der Frager "denkt" sich wie die Lösung aussehen könnte, fängt damit an, kommt aufgrund mangelndem Knowhow nicht weiter und anstatt sich zu ins Thema einzuarbeiten wird dann panisch kurz vor Angst Aktivismus in Form von diversen Forenanfragen geübt. Und da soll das "Problem" jemand lösen, der mangels adäquater Beschreibung auch keine Ahnung von dem hat, was der Frager benötigt.
Vergleiche DAS mal mit dem im oberen Absatz beschriebenen Ablauf bei einem SW-Unternehmen.....identisch!
Der "Anwender" ist von seiner Denke her genauso beschränkt wie der "Programmierer".
Und wenn da der eine Blinde dem anderen Blinden über die Straße helfen soll, muss man sich nicht wundern, wenn das in die Hose geht....und auch mal RICHTIG Geld kostet, s. bspw. HIER . Wenn man sich mit den im Artikel beschriebenen Vorgängen beschäftigt stellt man schnell fest, dass das Problem nicht die "Standard"-Software ist, sondern die Umsetzung/Erweiterung auf die kundenspezifischen Prozesse.
Analog zum Problem des TE....nicht Excel ist das Problem, sondern die vermeintlich "so" nicht umsetzbare "Lösung" des Anwenders...
....besagt, dass es, würden die 80% ihren Job auch richtig machen, kein Problem gäbe 
Pareto ftw! 