logo domkeconsulting

Beratung und Entwicklung - Mehr Produktivität für Microsoft Office

Lösungen mit Microsoft Office

 

Microsoft Office im Unternehmen

 

Fachliche Software. Jedes Unternehmen versucht, über fachliche und branchenbezogene Software seine Geschäftsprozesse möglichst vollständig abzudecken. Dies gelingt nie vollständig. Manche Geschäftsvorfälle müssen flexibel gehandhabt werden, andere kommen selten vor, oder sind schwierig zu verallgemeinern.

Microsoft Office – die Ergänzung. Bei vielen Unternehmen gehört deshalb Microsoft Office zur Grundausstattung eines PC-Arbeitsplatzes. Benutzer können individuelle Dokumente, ad-hoc-Reports, und innovative Kalkulationen erstellen, ohne an Vorgaben gebunden zu sein.
Outlook ist ein Sonderfall, weil es für viele Benutzer das zentrale Mittel der Selbstorganisation darstellt. Entsprechend groß ist das Angebot an Add-ins, mit denen fachliche Programme in Outlook integriert werden.

Der Graubereich. Zwischen den perfekten Lösungen fachlicher Software und dem individuellen Arbeiten in Word, Excel, oder PowerPoint gibt es einen Graubereich von Problemen und Anwendungsfällen. Hier müssen immer wieder Dateien importiert, Dokumente vereinheitlicht, Kalkulationen automatisiert oder ad-hoc-Workflows erstellt werden – kurz, es gibt einen Bedarf an Anpassungen, "Makros", "Tools" und "Vorlagen" für Microsoft Office.

Die aktuelle Situation. Wer erstellt aber die Anpassungen für Microsoft Office? Administratoren sind keine Entwickler und haben andere Aufgaben. Das Systemhaus installiert und wartet die Hard- und Software, oder es versteht sich als Solution Provider für Geschäftsprozesse, hat aber keine Kompetenzen im Bereich der Office-Programmierung. Die Werkstudenten sind interessiert und bemüht, aber erstens lernen sie noch die Best Practices, und zweitens sind sie nur für einen beschränkten Zeitraum da.

Selbsthilfe und die Folgen. Von der Unternehmens-IT bei solchen Fragen im Stich gelassen, helfen sich die Benutzer und die Teams im Unternehmen selbst. IBM schuf Mitte der 2000er Jahre dafür den Begriff "IDV" – Individuelle Datenverarbeitung.

Nach meiner langjährigen Erfahrung sind diese Lösungen teils interessant, teils fehlerträchtig und umständlich, selten praktisch, in Sonderfällen gefährlich, wenn nämlich kritische Daten in problematischer Weise behandelt werden[1]. Ältere Lösungen können nicht mehr gewartet werden, weil der Mitarbeiter das Unternehmen verlassen hat.

Leider haben nur wenige Manager ein Auge für die verdeckten Kosten und die verborgenen Risiken der IDV.

Professionelle Entwicklung ist sinnvoll. Überlegen Sie, ob Sienicht besser solche Produktivitätslösungen durch einen professionellen Entwickler erstellen lassen. Die damit verbundenen Aufwände werden wettgemacht durch den Zuwachs an Produktivität und die Vermeidung von Risiken.

Anforderungen an den Professionellen Office-Entwickler

Den Spagat beherrschen. Microsoft selbst behandelt das Feld der Office-Entwickler häufig mit Herablassung, so als spreche man von der Gruppe der Hobbyprogrammierer und Excel-Freaks. Wer sich aber in diesem Feld bewegt, muss von Anfang an den Spagat zwischen zwei Domänen beherrschen:

  • Office-Objekte. Auf der einen Seite: Kenntnis des Objektmodells der Office-Anwendung und aller Eigenschaften und Methoden der Objekte (zum Beispiel: das Range-Objekts in Excel, die HeaderFooter-Collection in Word, das Inspector-Object in Outlook, oder die Gestaltung des Ribbons in der Office-Benutzerschnittstelle).
  • Programmiersprache. Auf der anderen Seite: Kenntnis der Methoden, Limits und Fähigkeiten der verwendeten Programmiersprache und die Regeln der objektorientierten Programmierung (zum Beispiel: Einsatz von Linq in C# oder vb.net, Zustandsautomaten für Windows Forms und VBA-Forms, Nutzung von Webservices, Asynchrone Techniken).

Best Practices. Der professionelle Office-Entwickler bringt nicht nur seine Erfahrung aus vielen Projekten mit, sondern kennt auch die "Best Practices": sowohl bezüglich der Office-Anwendung als auch bei der Codierung (wie in "Code Complete" von Steve McConnell beschrieben). Der Code ist also gut strukturiert, defensiv programmiert (Vorwegnahme von Fehlersituationen), hat eine ergonomische Schnittstelle, ist dokumentiert und nachvollziehbar.

Zu den Best Practices gehören auch die Debugging-Techniken, eine funktionierende Quelldaten-Verwaltung, das Denken in Test- und Produktionsumgebungen, sowie die korrekte Durchführung von Tests.

Konzepte, Schnittstellen, Datenbanken, Bibliotheken. Der Entwickler ist vertraut mit den aktuellen Konzepten der Office-Programmierung. Er hat keine Probleme damit, Schnittstellen zu anderen Anwendungen zu bedienen, Datenbanken zu verwenden oder Bibliotheken einzusetzen.

Verteilung im Unternehmen. Das Codieren ist nur ein Teil der Arbeit. Der professionelle Office-Entwickler muss aber auch wissen, wie eine Lösung im Unternehmen zu verteilen ist: Benutzerrechte? Terminalserver? Gruppenrichtlinien? Verteilung durch MSI-Dateien? Vorlagenverzeichnisse? Benutzer- oder maschinenbezogene Installation? Der professionelle Entwickler wird auch über die Windows Installer Technologie Bescheid wissen.

Ihr Nutzen

Anforderungsermittlung. Auch wenn ein Team "mal eben schnell" eine ad-hoc-Lösung realisiert haben möchte: sowohl der Kunde wie auch der Entwickler gewinnen, wenn eine kurze Spezifikation geschrieben wird. Dies verhindert Missverständnisse, zeigt die gemachten Annahmen auf, und legt die Basis für ein erfolgreiches Projekt.

Zielgerichteter Lösungsansatz. Der Entwickler wird entweder den bestenLösungsansatz schon kennen, oder ihn mit geringem Aufwand finden. Welche Programmiersprache (VBA oder net-Add-in) zum Einsatz kommt, hängt von den konkreten Anforderungen des Kunden und seiner IT-Architektur ab.

Probleme kennen und vermeiden. Beständig ist nur der Wandel, und er stellt uns vor neue Probleme. Es gibt aber in Geschäftsprozessen ein paar Problem-Standardkandidaten– und die kann man vermeiden: Duplizieren von Daten, naives Vervielfältigen von Dokumenten, Übersehen des Jahreswechsels, falsche Formeln, Testen in Produktion, etc.

Time-to-Market. Der programmierende Power-User kann die Entwicklung nur nebenbei betreiben und muss seine eigentliche Arbeit liegen lassen. Der professionelle Entwickler wird sich zu 100% der Aufgabe widmen und deshalb den Prototyp und die Releases schneller liefern.

Ein offenes Wort über Aufwände

Office-Lösungen sind individuell. Natürlich hat jeder professionelle Entwickler seine Codebibliothek und seine bewährten Klassen, die er seinen Projekten häufig einsetzt. Dennoch bleibt jede Office-Produktivitätslösung eine sehr individuelle Angelegenheit, allein schon deshalb, weil jedes Unternehmen seine besondere Ansicht über Ablage, Standortstruktur, und die Softwareverteilung in Client-Umgebungen hat, und weil die Office-Lösung sich dort einfügen muss.

Ein "normales Programm" wird durch ein MSI-Setup im Programmverzeichnis installiert und registriert – Fertig! Dagegen setzt zum Beispiel die automatisierte Distribution eines globalen Word Add-ins in den Word-Startup-Ordner voraus, dass das Setup diesen Ordner erst einmal findet, und das ist von der Bitness des Rechners und der Office-Version, sowie von der Sprache abhängig, d.h. es sind einige Registry-Zugriffe und Prüffunktionen notwendig.

Generalisierungen sind selten. Auch weil die Anforderungen höchst individuell sind, gibt es wenig Berührungspunkte zwischen den Office-Lösungen verschiedener Kunden. Somit kann der Office-Entwickler extrem selten "Produkte" verkaufen, oder durch die Kombination von "niedrigem Preis" und "hoher Anzahl" Gewinne erzielen. Es entsteht somit immer ein Mindestaufwand für Bestandsaufnahme, Konzept, Prototyping und Abstimmung, den jeder Kunde zu tragen hat.

Häufig zu teuer für kleinere Unternehmen. In kleineren Unternehmen sind meiner Erfahrung nach die Budgets zu limitiert für eine Individual­entwicklung. Die höhere Produktivität durch die Office-Lösung reicht nicht aus, die Kosten einzuspielen. Lässt der Entwickler sich auf ein Festpreis-Projekt ein, entsteht oft "Scope screeping": es werden zusätzliche Leistungen gefordert, die anfangs nicht gefordert und also nicht kalkuliert waren.

Aufwände des Entwicklers. Man kann Word starten, Alt+F11 drücken, im VBA-Editor ein neues Modul in der Normal.dotm erstellen und loslegen mit "Public Sub HelloWord()". Das kostet nichts als die Lizenz für Microsoft Office. Der professionelle Entwickler benötigt aber eine MSDN-Lizenz (alle Microsoft-Server, alle Microsoft-Clients), und Werkzeuge, die nicht umsonst zu haben sind.


 


[1] Siehe auch das Protokoll der Fachtagung 2006 des Deutschen Instituts für Revision "Prüfung von IDV und End-User-Developments am Beispiel der Office-Produktpalette"