ITSM - Microsoft Access im Unternehmen · 2018. 12. 14. · den Unternehmen unweigerlich zu hohen...

Lösungen für mittelständische Unternehmen

Microsoft Access im Unternehmen

Microsoft Access im Unternehmen / Entwicklungsplattform? Stand: 29.07.2017 Seite 1 von 12

Geeignet als Entwicklungsplattform?

Copyright © 2017 ITSM OHG

ITSM OHG

Elisabeth-Selbert-Str. 19a

40764 Langenfeld / Rheinland

Fon

Fax

www.itsm-erp.de

[email protected]

+49 (0) 2173 10648-0

+49 (0) 2173 10648-48

http://www.itsm-erp.de/

mailto:[email protected]




Management Summary

Microsoft Access – als Bestandteil einiger Microsoft Office-Versionen – ist ein nahezu überall verfügbares Werkzeug für die „Programmierung“ einfacher Anwendungen.

Kann Microsoft Access aber auch als Entwicklungsplattform für robuste, komplexe und skalierbare Unternehmenssoftware verwendet werden? Die Antwort ist eindeutig „Ja“, wenn die eigentlichen Daten in einer „richtigen“ Datenbank wie SQL Server oder Oracle gespeichert werden, und wenn es professionelle Standards für die Programmierung gibt.

Die Abneigung der meisten IT-Verantwortlichen gegen Microsoft Access ist in vielen Fällen berechtigt, denn ein sehr großer Teil von Access-Anwendungen dürfte von Menschen ohne Programmierausbildung erstellt worden sein. Sie erfüllen ihren eingeschränkten Zweck für eine Arbeitsgruppe, können aber nur mit großer Mühe für einen größeren Benutzerkreis bereitgestellt werden. Größere Datenmengen führen häufig zu inakzeptablen Antwortzeiten, und viele Anwendungen reagieren hilflos bis gar nicht auf nicht vorhergesehene Fehlerbedingungen. Ein Wildwuchs von vielen kleineren Access-Anwendungen führt in den Unternehmen unweigerlich zu hohen Administrationsaufwänden.

Andererseits bietet Microsoft Access eine sehr schnelle und grundsätzlich auch einfache Möglichkeit, intuitiv einzusetzende und optisch ansprechende Benutzeroberflächen zu schaffen. Ebenso können professionell wirkende Druckausgaben (Reports) rasch entworfen werden. Das schafft die Voraussetzungen für ein schnelles Prototyping.

Das geht dann in die Richtung „agile Softwareentwicklung“ und Scrum.

Einer der Nachteile bei der Entwicklung von Individualsoftware besteht in der langen Planungsphase: Im Lastenheft und im Pflichtenheft müssen alle Details der Software von den Anforderungen bis hin zur technischen Umsetzung sauber beschrieben werden. Mit der Programmierung kann erst dann begonnen werden, wenn diese häufig umfangreichen Dokumente vollständig vorliegen. Beim Prototyping dagegen kann sehr schnell einmal eine Maske für den späteren Benutzer entworfen werden. Fehlentwicklungen und Missverständnisse können bei dieser Methode sehr frühzeitig und damit kostengünstig festgestellt bzw. vermieden werden.

Was ist also zu beachten, um Microsoft Access als Entwicklungsumgebung für umfangreiche Unternehmenssoftware wie ein kombiniertes ERP- und CRM-System einzusetzen?

• Verzicht auf die Datenhaltung in Microsoft Access

• Ein professionelles und umfassendes, normalisiertes Datenmodell

• Rigorose Programmierrichtlinien mit Namenskonventionen

• Modulare Programmierung mit robustem Fehler-Handling

• Nutzung von Stored Procedures und Triggern

• Ein Konzept für das Rollout der Anwendung

Mit ITSM!ERP ist ein komplexes ERP/CRM-System entstanden, das diese Voraussetzungen erfüllt. Wir stellen Ihnen auf den folgenden Seiten vor, wie ITSM diese Punkte grundsätzlich umgesetzt hat.

http://scrum-master.de/Was_ist_Scrum




Verzicht auf die Datenhaltung in Microsoft Access

Das klingt zunächst verrückt: Wir setzen ein Datenbank-Managementsystem (DBMS) ein, um keine Daten darin zu speichern? Ja, genau darauf läuft es hinaus.

Microsoft Access nutzt eine ausgereifte Datenbanktechnik (ACE-Modul) für die Speicherung von Daten in einer Datenbank (früher .mdb, ab Access 2007 .accdb). Der Zugriff kann über verschiedene Techniken wie DAO, ADO, ODBC etc. erfolgen. Die Nutzung des ACE-Moduls ist nicht auf Microsoft Access beschränkt. Das ACE-Modul bietet zusammen mit der Access-Benutzeroberfläche das vollständige Datenbank-Managementsystem.

Wenn man also die Access-Benutzeroberfläche zur Softwareentwicklung nutzt, warum sollte man dann nicht auch noch den zweiten Teil, nämlich das ACE-Modul zur vorgesehenen Speicherung der Daten in einer .accdb-Datei nutzen?

Dagegen sprechen bei größeren Benutzerzahlen und höheren Datenmenge in erster Linie die zu erwartenden schlechteren Antwortzeiten. Hinzu kommt, dass die Fehlertoleranz zum Beispiel bei Netzwerkproblemen nicht so ausgeprägt ist. Eine „richtige“ Datenbank wie im Microsoft SQL Server oder einer Oracle-Instanz, die auf einem getrennten Server betrieben wird, ist da wesentlich stabiler und schneller.

Wenn also mit größeren Datenmengen zu rechnen ist, sollte auf jeden Fall von vornherein der Einsatz einer robusten Server-Datenbank erfolgen. Bei ITSM arbeiten wir grundsätzlich mit dem SQL Server, da hier zusätzlich die Möglichkeit besteht, Logik in der Programmiersprache Transact-SQL (T-SQL) abzubilden. Von dieser Möglichkeit machen wir in Triggern, Stored Procedures und benutzerdefinierten Funktionen (UDF) auch regen Gebrauch. Die transaktionsorientierte Ausführung von Code direkte im SQL Server ist schneller und sicherer als die entsprechende Programmierung in Visual Basic for Applications (VBA).




Ein normalisiertes Datenmodell

Was ist Normalisierung?

Zu diesem Thema gibt es umfassende Literatur und Informationen im Internet, so dass wir hier nur auf die wesentlichen praxisrelevanten Punkte eingehen.

• Ein Datenfeld darf nur eine Information enthalten

• Daten sollten eindeutig sein

• Daten sollten redundanzfrei sein

Dazu nachfolgend kurze Erläuterungen und Beispiele.

Ein Datenfeld darf nur eine Information enthalten

Nach den Regeln (Boyce Codd Normal Form, BCNF) muss der Inhalt eines Datenfeldes atomar sein, also nicht weiter logisch aufgeteilt werden können.

Ein Datenfeld mit dem Inhalt „Kira Müller, geb. 19.03.2004, Bremen“ enthält mehrere Informationen, was bei Suchvorgängen nicht optimal ist. Das Datenfeld ist nicht atomar. Es sollte aufgeteilt werden in die Felder:

Nachname Vorname Geburtsdatum Wohnort

Müller Kira 19.03.2004 Bremen

Schulte Wolfgang 07.10.1978 Wuppertal

…

Erst diese Struktur ermöglicht es, einfach nach allen Personen zum Beispiel aus Bremen zu suchen.

Daten sollten eindeutig sein

Beim obigen Beispiel ist es nicht ausgeschlossen, dass es in Bremen eine zweite Person mit gleichem Namen und gleichem Geburtstag gibt. Wenn wir es bei der Tabellenstruktur belassen, könnte es folgende Datensätze geben:

Nachname Vorname Geburtsdatum Wohnort


Schulte Wolfgang 07.10.1978 Wuppertal


Das ist nicht mehr eindeutig, denn welche Person ist gemeint?

Wir benötigen ein weiteres Feld zur eindeutigen Unterscheidung. Das ist häufig ein künstliches numerisches Feld, das wir als Primärschlüssel definieren:

ID Nachname Vorname Geburtsdatum Wohnort

1 Müller Kira 19.03.2004 Bremen

2 Schulte Wolfgang 07.10.1978 Wuppertal

3 Müller Kira 19.03.2004 Bremen

Jetzt ist die Unterscheidung durch die numerische ID jederzeit möglich.




Daten sollten redundanzfrei sein

Nehmen wir an, dass die Personen in unseren Beispielen Kunden sind, die wiederholt etwas bei uns kaufen. Dann könnte man sich eine Tabelle der verkauften Artikel vorstellen, die so aussieht:

Gegenstand Preis ID Name Nachname Wohnort

1 PC 448 € 1 Müller Kira Bremen

1 Fotoapparat 286 € 1 Müller Kira Bremen

1 Taschenrechner 79 € 2 Schulte Wolfgang Wuppertal

Die Wiederholung von Name, Nachname und Wohnort führt a) zu redundanten Daten und ist b) wegen der eindeutigen ID auch nicht erforderlich. Die folgenden Daten reichen völlig aus:

Gegenstand Preis ID

1 PC 448 € 1

1 Fotoapparat 286 € 1

1 Taschenrechner 79 € 2

Das Beispiel bietet noch erheblichen Raum für weitere Verbesserungen, aber wir wollen es im Rahmen dieses Dokuments dabei belassen.

Sind alle Access-Anwendungen normalisiert?

Nein, das sind sie definitiv nicht. Vielen Microsoft Office-Nutzern, die mal eben schnell mit Vorlagen und Makros eine Access-Anwendung erstellen, sind die Regeln der Normalisierung natürlich nicht bekannt.

Was kann man mit solchen Anwendungen machen? Die ehrliche Antwort ist: Man muss sie neu designen. Eine Reparatur oder gar Weiterentwicklung auf einer nicht sauberen Grundlage ist nicht sinnvoll, sondern kostet nur Zeit und Geld und führt zu keinem befriedigenden Ergebnis.

Das ist auch der Grund dafür, weshalb ITSM keine Aufträge zur Weiterentwicklung von reinen Access-Anwendungen annimmt. Wir wissen aus Erfahrung, dass damit weder Auftraggeber noch Auftragnehmer glücklich werden wird.

Dennoch sind die Daten in solchen Anwendungen nicht verloren. Es besteht durchaus die Möglichkeit, in einer neuen Datenbank ein sauberes Datenmodell zu definieren und die Daten – zumindest weitgehend – automatisiert zu übernehmen. Voraussetzung dafür ist allerdings, dass keine Datenfelder missbraucht wurden und zum Beispiel einmal eine Telefonnummer und einmal ein Geburtsdatum enthalten.




Programmierrichtlinien mit Namenskonventionen

Wartbarkeit ist das Designziel

Mit der einmaligen Programmierung einer Software ist es in aller Regel nicht getan. Es wird immer wieder die Situation kommen, in der man selber oder auch ein anderer Mitarbeiter in den Code schauen muss – entweder, um einen gemeldeten Fehler zu beheben oder um eine gewünschte Erweiterung umzusetzen.

Schön, wenn man sich dann schnell wieder zurechtfindet. Das kann aber nur funktionieren, wenn sich jeder Programmierer eines Teams an einige Regeln hält. Es darf nicht sein, dass die Variable zur Zwischenspeicherung eines numerischen Wertes in einer Funktion aPreis heißt und in einer anderen Funktion bPreis.

In vielen bestehenden Access-Anwendungen mangelt es leider an dieser Wartbarkeit. Das einfache Einfügen zum Beispiel einer Schaltfläche durch Ziehen des Symbols in ein Formular führt nun einmal dazu, dass dieses neue Steuerelement Command13 heißt, was nicht gerade aussagefähig ist. Wer es dann versäumt, dem Control einen aussagefähigen Namen zu geben, verliert bei der Fehlersuche unweigerlich Zeit und den schnellen Überblick.

Ein weiterer Knackpunkt ist der Umgang mit Fehlern. Es ist ziemlich unverantwortlich, davon auszugehen, dass keine Fehler vorkommen. Fehler der unterschiedlichsten Art werden vorkommen und sie sollten möglichst intelligent abgefangen werden. Eine globale Fehlerroutine, die für aussagefähige Meldungen sorgt, ist unverzichtbar. Mit der Meldung „Invalid use of Null“ ist dem Endanwender (und etwas später dem Mitarbeiter an der Hotline) wenig geholfen. Besser wäre eine Meldung mit dem Inhalt „Das Feld ‚Straße‘ ist ein Pflichtfeld“. Und noch besser wäre es, wenn der Benutzer gar nicht erst die Möglichkeit zum Speichern der eingegebenen Daten bekäme, wenn nicht alle Pflichtfelder gefüllt sind.

Programmierrichtlinien

Wir verstehen unter Programmierrichtlinien verbindliche Vorschriften zum Beispiel für das Formatieren von Codezeilen und die Verwendung von Variablen. Es ist im Grunde unerheblich, welche Vereinbarungen man im Team trifft, wenn man denn überhaupt Vereinbarungen trifft und einhält. Dennoch haben sich einige Grundsätze als sinnvoll erwiesen. So sollte man in VBA

• nicht auf die Deklaration von Variablen verzichten

• den Rückgabewert von Funktionen wirklich auswerten

• mit Einrückungen und Kommentaren arbeiten

• Code-Wiederholungen vermeiden

• passende Datentypen deklarieren

• Errorhandling aktivieren

• endlosen Spaghetti-Code vermeiden

Auch für die Programmierung in T-SQL gelten entsprechende Regeln wie zum Beispiel mit Begin Try … End Try arbeiten oder einheitliche Konventionen für die Übergabe von Parametern an und aus Stored Procedures.




Namenskonventionen

Bei den Namenskonventionen unterscheiden wir zwischen den Objektnamen im SQL Server selber und den Objekten im Frontend. So können wir anhand eines dreistelligen Prefix bei jedem Tabellenfeld sofort erkennen, aus welcher Tabelle es stammt. Ebenso lassen sich viele Datentypen bereits aus dem Namen ableiten. Bei einem Preisfeld in einer View reicht uns kein Price, sondern es heißt zum Beispiel cPOS_mPrice_LV_DBI. Das sieht zwar kompliziert aus, hält aber sofort folgende Informationen für uns bereit:

cPOS_mPrice_LV_DBI c Es handelt sich um ein Feld, das in einer View aus anderen Feldern berechnet wurde (computed)

cPOS_mPrice_LV_DBI POS Der berechnete Wert basiert auf der Tabelle mit dem Präfix POS (für Auftragspositionen [Order Position])

cPOS_mPrice_LV_DBI m m steht für Money – es handelt sich also um einen Betrag, im Gegensatz z.B. zu Prozent

cPOS_mPrice_LV_DBI Price Das Feld beinhaltet einen Preis

cPOS_mPrice_LV_DBI L Es ist ein Betrag für eine Zeile (Line), im Gegensatz z.B. zur Summe

cPOS_mPrice_LV_DBI V Es ist der Mehrwertsteuerbetrag für eine Zeile (V für VAT)

cPOS_mPrice_LV_DBI DBI Der berechnete Wert ist für eine Zeile in einer Rechnung bestimmt (DBI ist der Präfix für die Rechnungstabelle [Debtor Invoice])

Vergleichbare Regeln gibt es für die Benennung von Variablen, Funktionen und Subroutinen.




Modulare Programmierung

Der Begriff Modul hat durchaus mehrere Bedeutungen. Wir verstehen darunter zunächst die Gesamtmenge aller Funktionen und Prozeduren zu einem übergeordneten Bereich wie Stammdaten-verwaltung oder Dokumentenmanagementsystem. Ein Modul im engeren Sinne von Microsoft Access ist eine Sammlung von Funktionen und Subroutinen, die in einer logischen Einheit zusammengefasst sind.

Unter modularer Programmierung verstehen wir weiterführend die Aufteilung komplexerer Aufgaben in kleinere, mehrfach nutzbare Abschnitte. Ein einmal geschriebener und sorgfältig getesteter Codeabschnitt wird auch bei millionenfacher Ausführung immer zuverlässig das richtige Ergebnis bringen – der Vorteil liegt auf der Hand. Ein anderer Aspekt liegt in der Strukturierung.

Überschaubare Funktionen

ITSM hat zu diesem Zwecke für wiederkehrende Aufgaben eine Funktionsbibliothek, die ITSM Library, entwickelt, die mit jeder individuell entwickelten Softwarelösung ausgeliefert wird. Die Bibliothek enthält weit über 100 häufig benutzte Funktionen. So gibt es beispielsweise eine Funktion, die aus einem Datum im Access-Format ein vom SQL Server oder von Oracle „verstandenes“ Format macht:

Public Function lfGetDateOrTS( _

Var_Date As Variant, _

Optional Int_RDBMS As Integer = 1, _

Optional Bool_TS As Boolean = False) As Variant

Beispiel:

Der Funktionsaufruf lfGetDateOrTS("23.03.2016", 1, False) führt zu einem Ergebnis, das im T-SQL des SQL Server verwendet werden kann:

CONVERT(DATETIME, '2016-03-23', 102)

Der Funktionsaufruf lfGetDateOrTS("23.03.2016", 2, True) führt zu einem Ergebnis, das in PL/SQL in einer Oracle-Datenbank verwendet werden kann:

TO_DATE('23.03.2016 00:00:00', 'DD MM YYYY HH24 MI SS')

Strukturierung

Die modulare Programmierung bietet aber auch bei größeren Projekten die Möglichkeit einer sauberen Strukturierung und damit einer besseren Übersichtlichkeit.

So lassen sich beispielsweise alle VBA-Routinen für das Dokumentenmanagementsystem in einem Access-Modul und alle Funktionen für das Scannen von Barcodes in einem anderen Modul zusammenfassen.

Das lässt sich auch auf der Ebene von Forms fortführen: In jeder Maske in ITSM!ERP, in der Daten eingegeben oder geändert werden können, gibt es diese gleichbenannten Funktionen:

fNew() Vorbereiten des Forms für einen neuen Datensatz

fRead() Einlesen und Anzeigen eines einzelnen Datensatzes

fSave() Speichern eines eingegebenen oder geänderten Datensatzes

fReset() Zurücksetzen der Suchargumente

fShow() Auswerten der Suchargumente und Anzeigen der Ergebnisliste




Stored Procedures und Trigger

Hier ist ein weiterer Unterschied zwischen einer reinen Access-Anwendung und einem kombinierten Access- und SQL Server-Projekt: Im SQL Server steht die Sprache Transact SQL (T-SQL) zur Verfügung, in der reine SQL-Statements in die Ablauflogik eingebettet werden können. Die Verarbeitungsgeschwindigkeit ist sehr hoch - unter anderem, weil die Kommunikation zwischen dem Frontend, also Microsoft Access und dem Backend, also dem SQL Server, entfällt.

Wir nutzen bei ITSM diese Möglichkeit, um den größten Teil der Businesslogik im SQL Server direkt abzubilden. Dieses transaktionsorientierte Verfahren ist sicherer als die Ausführung auf einem Client, die durch eine Störung theoretisch auch mitten in der Verarbeitung unterbrochen werden kann und unter Umständen einen unsauberen Datenzustand hinterlässt.

Trigger sind eine Möglichkeit, auf Veränderungen in den Daten (Insert, Update oder Delete eines Datensatzes) zu reagieren. Das ist ein Feature, das es in Access allein nicht gibt und das umfassende Möglichkeiten eröffnet. Damit besteht beispielsweise die Möglichkeit, Veränderungen im Datenbestand in einer weiteren Tabelle aufzuzeichnen. So lässt sich die Historie eines Datensatzes rekonstruieren.

Bei ITSM setzen wir Trigger unter anderem dafür ein, nicht zeitkritische Arbeitsschritte in einem Batchverfahren asynchron auszuführen. Ein Beispiel dafür ist das Aufbereiten von Daten für spätere Auswertungen. Wenn der Trigger angestoßen wird, schreiben wir nur einen Datensatz mit dem Primärschlüssel der Tabelle, dem Tabellenpräfix und der Änderungsart in eine Batch-Tabelle. Im SQL Server Agent wird ein Job definiert, der in bestimmten Zeitintervallen eine Stored Procedure aufruft, die dann die eigentliche Berechnung auf Basis der Daten in der Batch-Tabelle ausführt.




Rollout der Anwendung

Ein häufig gehörter Einwand gegen eine Access-Anwendung ist der Aufwand, die Software erstmalig oder in einer neuen Version auf einer Vielzahl von PCs zu installieren. Das ist nicht ganz von der Hand zu weisen. Gerade in Umgebungen mit PCs, auf denen unterschiedliche Betriebssysteme laufen, kann die Installation einer Access-Anwendung kompliziert werden. Dennoch lässt sich auch das mit MSI-Paketen, also einem ordentlichen Setup-Verfahren, lösen.

Ein besserer Ansatz ist die Installation auf einem Terminalserver. Diese Lösung ist deutlich weniger aufwändig und bietet zudem noch den Vorteil, dass auch vom Homeoffice oder einer Zweigstelle aus über eine sichere VPN-Verbindung sehr schnell mit der Anwendung gearbeitet werden kann.

Das ist die Lösung, die von den meisten unserer Kunden in den letzten Jahren genutzt werden, und mit der wir auch selber seit Jahren arbeiten. Die Mitarbeiter unserer Schwestergesellschaft, der ITSM GmbH, beraten Sie gern bei der Umsetzung dieser und anderer Infrastrukturaufgaben. Und wenn Sie ohnehin darüber nachdenken, können Sie auch noch einen Schritt weitergehen und Ihre Anwendungen auf einem virtuellen Server in einem von zwei Rechenzentren in Düsseldorf hosten lassen. Weitere Informationen hierzu finden Sie unter www.itsm.de.

Runtime Version

Für Benutzer, die Microsoft Access nicht lizensiert haben, liefert ITSM ohne zusätzliche Kosten eine Runtime-Version von Microsoft Access, die eine uneingeschränkte Nutzung der Anwendung ermöglicht.

Erstmaliges Rollout

Da die SQL-Datenbank eine grundlegende Voraussetzung für den Betrieb des ITSM!ERP darstellt, muss diese zuerst installiert werden. Dabei unterstützen Sie gern auch die Mitarbeiter unserer Schwestergesellschaft, der ITSM GmbH.

Für die Erstinstallation der Anwendung auf dem Terminalserver wird eine auf die Umgebung des Kunden angepasste Setup-Datei bereitgestellt. Diese Datei wird mit administrativen Rechten einmalig auf dem Server ausgeführt. Sie installiert im ersten Schritt die ausführbare Datei, die mittels Verknüpfung von jedem berechtigten Client aufgerufen wird, in das vom Betriebssystem vorgegebene Programm-Verzeichnis. Später führt sie bei jedem Programmstart einen Abgleich zwischen der aktuellen Client-Version und der auf dem Terminalserver installierten Version durch. In einem zweiten Schritt erfolgt die Erstellung des Serververzeichnisses zur Bereitstellung der Anwendungsdateien und der ITSM-Library. Dieses Verzeichnis, standardmäßig C:\Apps\ITSMERP, kann vom Kunden vorgegeben werden. Damit ist die serverseitige Installation abgeschlossen.

Für die Erstinstallation auf der Clientseite wird ebenfalls eine angepasste Setup-Datei bereitgestellt. Diese Datei muss von jedem berechtigten Benutzer einmalig ausgeführt werden. Sie erstellt das Verzeichnis zur Aufnahme der Anwendungsdateien im Benutzerbereich, standardmäßig in %LocalAppData%\ITSMERP, und kopiert die grundlegende Konfigurationsdatei als Voraussetzung für jeden Programmstart dorthin. Anschließend wird noch eine Programmverknüpfung auf dem Desktop erstellt. Damit ist auch die clientseitige Erstinstallation abgeschlossen, dem Programmstart steht nichts mehr im Wege.

http://www.itsm.de/




Verteilung einer neuen Version

Wie kommt eine neue Version der Anwendung in das spezifische Verzeichnis auf dem Terminalserver bzw. auf den PC des Benutzers? Eine geänderte Version auf die Client-Rechner zu verteilen, erfordert lediglich kurze Aktionen auf dem Terminal-Server. Mit administrativen Rechten wird die Datei der neuen Anwendungs- bzw. ITSM-Lib-Version in das o.g. Serververzeichnis kopiert. Hier wurde durch die Setup-Routine ein Verzeichnis analog zur verwendeten Access-Version erstellt, z.B. C:\apps\ITSMERP\ITSMERP2016, welches auch die bisher verwendeten Dateien der Anwendung und der ITSM-Library enthält. Zudem wird eine Datei mit den Buildnotes dorthin kopiert, welche die Benutzer beim ersten Aufruf der neuen Version über die Änderungen informiert. Im übergeordneten Verzeichnis, standardmäßig C:\apps\ITSMERP, wird in der Datei VCK.xml die neue Versionsnummer eingetragen. Damit ist bereits die gesamte Aktualisierung abgeschlossen.

Muss nun auch auf jedem Client eine entsprechende Änderung durchgeführt werden? Nein, es ist bereits alles geschehen. Liegt auf dem Server eine neue Version der Anwendung und / oder der ITSM-Library vor, wird beim Programmaufruf die jeweilige Datei automatisiert in das lokale Verzeichnis auf dem Client-Rechner kopiert. Der Benutzer wird anhand der Buildnotes über die Änderungen informiert und kann ohne Verzögerung mit dem ITSM!ERP arbeiten.

Somit ist garantiert, dass jeder Benutzer ohne weiteres Zutun oder gar aufwändigen Eingriff eines Administrators den aktuellen Stand von Anwendung und Library verwendet.




Über ITSM

Die ITSM Gesellschaft für Informationstechnologie und Services Meiß mbH ist ein 1998 gegründetes IT-Systemhaus in Langenfeld/Rheinland, das mittelständische Unternehmen in allen Fragen der Informationsverarbeitung und Telekommunikation berät und unterstützt. Die Gesellschaft bedient schwerpunktmäßig die Themen „Server Based Computing“ und „Local Cloud Hosting“, die erhebliches Einsparungspotenzial bei Investitionen und laufendem Betrieb aufweisen. ITSM plant und realisiert als Microsoft Partner individuell ausgelegte Netzwerkinfrastrukturen, die auch in deutschen Rechenzentren gehostete Server und Speicher umfassen.

In 2015 wurde die Softwareentwicklung in die Schwestergesellschaft ITSM OHG ausgegliedert. Hier erfolgt die kontinuierliche Weiterentwicklung des Kernprodukts ITSM!ERP. Neben dieser individuell anpassbaren ERP/CRM-Lösung auf Basis der Produkte Microsoft SQL Server und Microsoft Office bietet die ITSM OHG auch Auftragsprogrammierung wie zum Beispiel Schnittstellen oder Webservices an.

Beide Unternehmen arbeiten an einem gemeinsamen Standort in Langenfeld/Rheinland – also in zentraler Lage zwischen Düsseldorf und Köln – eng zusammen und stehen unter gemeinsamer Leitung. Seit Jahren bildet ITSM selber Fachinformatiker mit dem Ziel der späteren Übernahme als feste Mitarbeiter aus. Anfang 2017 beschäftigt ITSM 16 Mitarbeiter.

75096_00117734-0002.docx

http://www.itsm.de/

ITSM - Microsoft Access im Unternehmen · 2018. 12. 14. · den Unternehmen unweigerlich zu hohen...

Documents

Transcript of ITSM - Microsoft Access im Unternehmen · 2018. 12. 14. · den Unternehmen unweigerlich zu hohen...