Ablösungs- oder Migrationsstrategie für Excel/Access

Question

Gibt es eine Möglichkeit, die von den Endbenutzern geschätzte Flexibilität der Excel/Access-Entwicklung zu bieten und gleichzeitig eine zentrale IT-Verwaltung einzurichten, so dass Daten und Logik sicher, gesichert, versionskontrolliert usw. sind? Die gängigsten Optionen sind das Umschreiben in C#/ASP.Net/Java/Python/Your Choice, aber das entzieht den Benutzern die Kontrolle. Gibt es einen besseren Weg, und wie gehen Sie an Ihrem Standort vor?

Es ist ein allgemeines Problem, dass Benutzer fantastisch nützliche Excel/Access-Mini-Apps erstellen, die die IT-Abteilung gerne unter Kontrolle bringen würde. Die Benutzer lieben die Flexibilität, die Excel bietet, insbesondere die Möglichkeit, Änderungen während des laufenden Betriebs vorzunehmen, Diagramme zu erstellen und Daten zu importieren/exportieren. In Access haben wir eine hervorragende QBE. Der Nachteil ist, dass es nach kurzer Zeit Legionen von außer Kontrolle geratenen Tabellenkalkulationen/Datenbanken gibt, die geschäftskritisch sind, mit einer Menge schlecht verstandener Geschäftslogik und brüchigem Code, die zu betreuen sehr mühsam ist, vor allem wenn die Mitarbeiter weiterziehen.

Das bringt die IT-Abteilung in eine missliche Lage: Sie würde diese Anwendungen gerne unterstützen, weiß aber nicht genug darüber. Erschwerend kommt hinzu, dass sie in der Regel unsicher sind und keinerlei Dokumentation enthalten.

Answer 1

Wenn die "Benutzer" die Kontrolle haben, bedeutet das normalerweise, dass eine bestimmte Person die Kontrolle über die Architektur, das Design, die Kodierung und die Dokumentation hat... außer, dass sie normalerweise den Schritt der Dokumentation auslassen. Quellenkontrolle und Fehlerberichte, die Prüfsteine der Softwareentwicklung, fehlen normalerweise. Es gibt nur wenige Beispiele für die Wiederverwendung von Code, was auf die Art der Office-Anwendungen (Code-Module sind in der Regel in Dokumente eingebettet) und VBA (wenig OOP, die meisten VBA-Programmierer verwenden keine Implements usw.) zurückzuführen ist. All dies bedeutet, dass die daraus resultierenden Anwendungen nicht ordnungsgemäß geprüft werden und die Qualität darunter leiden kann, was bedeutet, dass es wahrscheinlich zu Wartungsproblemen kommt, vor allem, wenn der eine Benutzer ausscheidet. Ich weiß das, weil ich früher diese Person war ;)

Um die IT-Abteilung zufrieden zu stellen, muss also das richtige Verfahren angewandt werden. Dieser eine "Power"-Benutzer kann weiterhin das Design und die Programmierung übernehmen, erhält aber eine Peer Review, vielleicht die Dienste eines technischen Autors und eines engagierten Testers, muss die Versionskontrolle verwenden, vielleicht die Integration mit Unternehmenssystemen in Betracht ziehen usw.

Answer 2

Es führt kein Weg an der Verwendung von Excel/Access vorbei. Es ist das, was zur Verfügung steht, und immer noch sehr leistungsfähig und flexibel. Am besten ist es, wenn Sie einige Richtlinien vorgeben, wie die Dateien aussehen und aufgebaut sein sollten. Wenn alle ähnliche Standards verwenden, werden die Dateien länger und produktiver leben, auch über die Zeit hinaus, in der der Ersteller im Unternehmen tätig ist.

Answer 3

Sie haben einige ausgezeichnete Antworten zum Umgang mit den Leuten und der geschäftlichen Seite der Dinge. Meine Antwort wird also eher technischer Natur sein.

Wenn Sie die App neu gestalten wollen, sollten die Entwickler in denselben Büros arbeiten wie die Benutzer. Geben Sie den Nutzern alle ein oder zwei Tage Updates. Wenn die Benutzer kleinere Vorschläge haben, geben Sie diese innerhalb von ein oder zwei Tagen an die Benutzer weiter. Extrem häufige Anwendungsbereitstellung

Geben Sie den Power-Usern eine mit den Tabellen verknüpfte Access MDB/ACCDB mit einer Reihe von Startabfragen. Lassen Sie sie die Abfragen erstellen, die sie für den Export der Daten nach Excel für ihre eigenen Zwecke und die Weitergabe an Kunden benötigen.