Das die Office Suite von Microsoft ein mächtiges Produkt ist, ist klar. Mit dem Gemeinschaftsprojekt von SAP und Microsoft „Duet“ rückt ein Aspekt in den Vordergrund, den man den Produkten bisher nicht zugetraut hat. Nun wird die Office Suite zum Anwendungsfrontend. Was sich merkwürdig anhört ist schlicht brilliant.
In den vergangenen Jahren haben die meisten Unternehmen ihre Anwendungslandschaft zentralisiert. Neben den bekannten SAP R/3 Anwendungen findet man auch einen erheblichen Anteil individual auf die Kunden zugeschnittener Lösungen mit unterschiedlichster technischer Umsetzung. Ob nun mit Enterprise Java (J2EE), Microsoft .NET oder ASP oder auch PHP umgesetzt spielt dabei keine Rolle. Wichtig sind andere Aspekte. Allein danke zentraler Administration, einfacher Bereitstellung und vergleichsweise geringen Client Anforderungen sparen die Unternehmen Kosten. Diese angenehme Seite hat aber leider auch Nachteile. Die Anwendungen wurden fast alle auf webbasierte und browsergestützte Bedienung umgestellt. Einem einfachen Vergleich mit Desktopanwendungen halten diese Lösungen in Punkto Bedienungskomfort nicht stand. Auch in Zeiten von Rich-/Smart Clients und AJAX hat sich die Situation nicht wirklich verbessert. Während die Interaktion von verschiedensten ERP Systemen immer ausgefeilter wird, bleiben die Anwender mit ihren Bedürfnissen noch immer auf der Strecke.
Dabei könnte alles so einfach sein. Das beste Beispiel dafür liefert Microsoft mit seiner Office Suite. Programme wie Word und Excel sind aus dem heutigen Leben nicht mehr wegzudenken. Kaum ein Anwender in einem Unternehmen, der nicht die Grundlegenden Kenntnisse schon vor langem Erworben hat. Auch wenn sich bereits eine stattliche Anzahl Mitbewerber auf dem Markt tummelt, kann man die Produkte doch als „de-facto“-Standard für Text- und Datenverarbeitung betrachten. Wird irgendwo eine datenverarbeitende Software neu programmiert kann man vielleicht auch deshalb immer mal wieder von den zukünftigen Endanwendern hören, dass sie „es gerne so wie in Excel“ hätten. Ein Wunsch, dem sich nur mit sehr viel Aufwand halbwegs nachkommen lässt. Schnell stößt man an Grenzen. Entweder scheitert es an der zur Verfügung stehenden Zeit, dem Budget oder schließlich den technischen Möglichkeiten der Webstandards oder befähigter Anzeigegeräte. Vernachlässigt man all das, bleibt schlussendlich noch immer ein konzeptionelles Problem, welches sich einfach nicht lösen lässt. In der täglichen Arbeit geht es meist um Dokumente und nicht nur um Daten. Um aus Daten wirkliche Dokument zu machen ist eine Transformation notwendig, die einem die Technik nur sehr begrenzt abnehmen kann. Im Falle von Wohldefinierten Vorlagen, wie beispielsweise Reports, Rechnungen und Angeboten ist eine Lösung möglich. Hier werden die Dokumente in einer zentralisierten IT-welt einfach generiert und quasi vorausgefüllt an den Anwender ausgeliefert. Sind Änderungen notwendig, müssen die Anwender das selber machen. Sind die Änderungen permanent, dann sind die Vorlagen anzupassen. Ein verhältnismäßig hoher Aufwand. Zumal es meistens nur darum geht, einen speziellen Teil eines Dokuments mit Daten aus zentralen Systemen anzureichern. Betrachtet man dann noch den erheblichen Bedarf an zentralen Ressourcen, die für die aufwändige Generierung erforderlich sind, ist es nicht verwunderlich, dass dieser Weg nur in ausgewählten Situationen gegangen wird. Die Anwender sind also gezwungen, einen gewissen Teil ihrer täglichen Arbeitszeit mit dem Sammeln von Daten und dem kopieren in relevante Dokumente zu verbringen. Zumeist erfolgt die Suche in entsprechenden Weboberflächen. Anschließendes Copy&Paste und manuelle Formatierung komplettieren einen zähen Arbeitsschritt. Speziell häufig wiederkehrende Vorgänge werden damit zur Qual.
Während der Powernutzer möglicherweise selbstgebaute VBA Lösungen für solcherlei Probleme findet, ist ein normaler Anwender viel früher lustlos. Wo Arbeit keinen Spaß macht, gerät dann auch die Produktivität ins Hintertreffen. Und das alles nur, weil man die Anwender aus Kostengründen eines ihrer mächtigsten Werkzeuge beraubt und sie zwingt mit Weboberflächen zu arbeiten.
Umgehen kann man das nur, wenn man darüber nachdenkt, wie die zwei Welten Web und Desktop zusammenwachsen können. Bei Daten- und Dokumentenzentrierten Unternehmensanwendungen bietet sich eine möglichst nahtlose Integration von Office mit Webanwendungen an. Dabei besteht eine gute Chance, dass die wieder gesteigerte Produktivität dem Wunsch nach Kostenersparnis in den Unternehmen viel eher gerecht wird, als die Umsetzung von komplett zentralisierten und webbasierten Anwendungen. Dies ist sicherlich ein Ansatz, den Microsoft gerne sieht. Hat das Unternehmen doch mit hauseigenen Lösungen genau die passenden Werkzeuge für solche Probleme im Angebot. Angefangen bei dem altbekannten Visual Basic for Applications (VBA) über das Information Bridge Framework (IBF) bis hin zu den Visual Studio Tools for Office (VSTO) gibt es bereits eine ganze Menge Wege, die man gehen kann. Eins haben sie allerdings alle gemeinsam. Es handelt sich um Microsoft eigene Wege. Sie setzen zumindest die Kenntnis der Produkte, zumeist auch die Kenntnis der entsprechenden Programmiersprachen und ihrer Möglichkeiten voraus. Das möchten sich viele Unternehmen aber sparen. Je stärker die IT auf Enterprise Java ausgerichtet ist, je schwieriger wird es, einen solchen Weg zu gehen. Die beiden Welten sind halt doch grundverschieden. Eine Lösung gibt es dennoch. In Zeiten von Serviceorientierten Architekturen (SOA) ist es ja auch schon länger kein Geheimnis mehr. Webservices überbrücken spielend die Kluft zwischen beliebigen Welten und sind die modernen Vermittler zwischen bisher unvereinbarem.
Da das nicht wirklich so ganz einfach und ohne Aufwand funktioniert, muss man doch einen kleinen Schritt in die Microsoft Welt wagen. Unter dem Produktnamen „Microsoft Office“ sind in der aktuellen Version 2003 viele Einzelprodukte versammelt. Word und Excel sind dabei jedem ein Begriff. Dazu kommen die Emaillösung Outlook und die Datenbank Access sowie Powerpoint als Präsentationsanwendung. Diese Standardprodukte gibt es in drei verschiedenen Editionen mit weiteren Ergänzungsprodukten zu kaufen. Den Anfang macht dabei die schlanke "Basic Edition" mit Word, Excel und Outlook. Die "Small Business Edition" enthält dann noch Powerpoint und den Publisher. In der „Professional Edition“ ist zusätzlich noch die Datenbank Access enthalten. Dabei entspricht vor allem das letzte Paket am ehesten dem, was man als „Office Suite“ kennt. Programme wie Visio, Project, FrontPage sowie OneNote, der Communicator und InfoPath haben ihren Platz ebenfalls unter dem Office Dach gefunden. hinzu. Zu fast allen Desktopanwendungen gibt es noch die serverseitigen Gegenspieler. Hier sind vor allem der Exchange Server für Outlook und die SharePoint Services und der –Server für die Zusammenarbeit in Teams zu nennen.
Bei so vielen Programmen und Versionen bleibt die Frage, wo man mit einem Integrationsansatz am besten starten sollte. Hier hat sich Microsoft bereits für die eigenen Lösungen zwei Konzepte ausgedacht, die auf Nutzerseite die erweiterten Funktionalitäten bereitstellen. Das erste Konzept heißt ActionPane. Diese Aktionsleiste stellt ein, an die aktuelle Arbeitsfläche aller Office Anwendungen andockbares, Fenster dar. In ihm werden kontextabhängig verschiedene Funktionen bereitgestellt. Beim ersten Öffnen einer Office Anwendung findet man dort zumeist die Hilfe (Erste Schritte) Funktion. Aber auch die erweiterte Zwischenablage wird dort angezeigt. Navigiert man über das Menü Ansicht->Aufgabenbereich, kann man dieses Fenster ein- und ausschalten. STRG und F1 erledigen dies per Tastatur.
Als zweites Integrationskonzept kennt Office die so genannten SmartTags. Sie sind schon länger in Office enthalten und haben schon für den ein oder anderen sicherheitsrelevanten Unmut gesorgt. Vor allem, weil es eine Möglichkeit gibt, diese von Webseiten aus über den Internet Explorer bereitzustellen. Mit dem Begriff Smarttag werden Mustererkennungsmechanismen beschrieben, die während der Texteingabe arbeiten. Werden diese bei einem eingegebenen Wort oder einer Zeichenfolge fündig, werden die Textteile mit einer gepunkteten, violetten Linie markiert. Fährt man mit dem Coursor über diesen Bereich, stellt sich ein Kontextmenü dar, über das zusätzliche Funktionen aufgerufen werden können.
Beide Konzepte kann man programmatisch mit Leben füllen. Hierfür gibt es technisch gesehen unterschiedliche Wege. Zumeist wird eine entsprechende API von Microsoft verwendet und eine Dynamic Linked Library (DLL) bereitgestellt, welche in Office registriert wird. Will man nicht mit Microsoft Werkzeugen programmieren kann man für den Anfang aber auf eine sehr einfache Version zurückgreifen. Diese ermöglicht die Verwendung beider Nutzerkonzepte per simpler XML Datei bereitstellen. Diese stellt zugegebenermaßen nur einen Bruchteil der tatsächlichen Möglichkeiten zur Verfügung, ermöglicht aber ein sehr gutes und grundlegendes Verständnis für die Integrationswege. Und vielleicht reicht es ja, um einen ersten Schritt in diese Richtung mit einfachen Anwendungen zu wagen.
Der einfachste Weg, um SmartTags in Office zu umzusetzen, stellt sicherlich die Verwendung von Simple Smart Tags dar. Zuerst muss eine schemabasierte XML Datei erstellt werden.
<FL:smarttaglist xmlns:FL="urn:schemas-microsoft-com:smarttags:list">
<FL:name>iX bezogene Bezeichnungen</FL:name>
<FL:lcid>1033</FL:lcid>
<FL:description>eine Liste von Bezeichnungen, die fuer auf die iX hinweisen.</FL:description>
<FL:moreinfourl>http://www.heise.de/ix</FL:moreinfourl>
<FL:smarttag type="urn:schemas-microsoft-com:smarttags#msdnterms">
<FL:caption>iX bezogene Bezeichnungen</FL:caption>
<FL:terms>
<FL:termlist>iX, IX, Heise, ct, newsticker</FL:termlist>
</FL:terms>
<FL:action id="newsticker">
<FL:caption>Heise Newsticker</FL:caption>
<FL:url>http://www.heise.de/newsticker/</FL:url>
</FL:action>
</FL:actions>
</FL:smarttag>
</FL:smarttaglist>
Diese wird dann in das gemeinsam verwendete Verzeichnis aller Office Anwendungen
C:\Programme\Gemeinsame Dateien\Microsoft Shared\Smart Tag\LISTS gelegt. Bevor man das allerdings tut, sollte man alle Office Anwendungen beenden. Normalerweise steht nach dem erneuten Starten die neue Funktionalität direkt bereit. Überprüfen kann man das, wenn man sich im Menü Extras->AutoKorrektur-Optionen zum Reiter Smarttags begibt. In diesem Beispiel wird beim Auftreten eines unter <FL:termlist> geführten Begriffs ein Kontextmenü mit einem Link zum Heise-Newsticker angeboten. Welche Funktionen es noch gibt, kann man den Schemabeschreibungen aus dem Smarttag-SDK entnehmen. Dies kann kostenlos von den Microsoft Entwicklerseiten bezogen werden (Siehe Kasten Infos im Web).
Da Office extrem sparsam ist, was Fehlermeldungen für die Konfigurations-XML Dateien angeht, empfiehlt sich grundsätzlich die Verwendung eines XML Editors, der in der Lage ist, die Dateien gegen das hinterlegte Schema zu prüfen. Hat man den nicht zur hand, kann ein einfaches Anzeigen der XML Datei im Internet Explorer wenigstens schon mal die gröbsten Fehler aufdecken.
Will man die Aktionsleiste Programmieren, muss man schon ein wenig mehr machen. Hier reicht es nicht mehr, wenn einfach nur eine XML Datei in ein Verzeichnis geschoben wird. Allerdings bietet Office auch hier einen recht einfachen Schnelleinstieg. Die Research Services stellen eine vordefinierte Schnittstelle zur Suche und Ergebnisanzeige bereit. Man kann sie direkt über das Menü Extras->Recherchieren anzeigen. Um sie für eigene Zwecke zu nutzen und einen eigenen Recherche Dienst zu installieren, muss man lediglich zwei Webservices bereitstellen. Einen, um den Dienst im Office zu registrieren und einen, für die eigentliche Anfrage. Beide Webservices bekommen eine entsprechende Methode (Register bzw. Query) mit einem zugehörigen xsd:string als Rückgabewert spendiert. Das gelingt heutzutage schnell auf vielen Plattformen. Ein Auszug aus einer entsprechenden WSDL sieht dann beispielsweise so aus:
[...]
<operation name="Registration">
<soap:operation soapAction="urn:Microsoft.Search.Registration.Request#Register"
style="rpc" />
[...]
</operation>
[...]
Für die eigentliche Suchanfrage entsteht dann ein ähnlicher Webservice mit anderem Methodennamen.
[...]
<operation name="Query">
<soap:operation
soapAction="urn:Microsoft.Search.Response#Query"
style="rpc" />
[...]
</operation>
[...]
Über die Webservice Schnittstellen werden XML Dokumente zwischen Office und der jeweiligen Anwendung ausgetauscht. Diese müssen XML Schema konform sein.Das gelingt alles recht einfach. Die Arbeit beginnt in der gewöhnungsbedürftigen Dokumentation von Microsoft zum Recherche Dienst. Das SDK wird als kompiliertes HTML ausgeliefert und steht nach erfolgter Installation über das Startmenü unter Windows bereit. Leider sind die dort verfügbaren Informationen komplett auf die Microsoft-Welt ausgerichtet. Für Programmierer aus anderen Welten bleibt also eigentlich nur der Blick auf die XML Schema und die beispielhaften Austausch-XML Fragmente in der Dokumentation. Die sind leider von der Komplexität meistens auf Anfängerniveau und daher nicht wirklich immer zu gebrauchen um Probleme zu lösen. Weniger Probleme macht die Registrierung des Research Service. Über die Recherche Optionen kann man in der Aktionsleiste einen neuen Service einrichten. Das jeweilige Office Produkte schickt dann ein XML Paket an den Webservice.
<RegistrationRequest
revision='2'
build='(11.0.6568)'
xmlns='urn:Microsoft.Search.Registration.Request'>
<OriginatorId>{GUID}</OriginatorId>
<SystemInformation>
<SkuLanguage>en-us</SkuLanguage>
<LanguagePack>en-us</LanguagePack>
<LanguagePack>de</LanguagePack>
<InterfaceLanguage>de</InterfaceLanguage>
<Location>DE</Location>
</SystemInformation>
</RegistrationRequest>
Im Feld GUID findet sich der eindeutige Identifier von Microsoft für das jeweils installierte Produkt. Auf diese Anfrage wird vom Webservice mit einem entsprechenden XML Fragment geantwortet:
<ProviderUpdate
xmlns=\"urn:Microsoft.Search.Registration.Response\">
<Status>SUCCESS</Status>
<Providers>
<Provider>
[...]
<Id>{GUID}</Id>
<Name>ix Newsticker Research Pane</Name>
<QueryPath>http://{host}:{port}/{context}/{file}</QueryPath>
<RegistrationPath>
http://{host}:{port}/{context}/{file}
</RegistrationPath>
<Type>SOAP</Type>
[…]
</Provider>
</Providers>
</ProviderUpdate>
Eine Herausforderung ist die Generierung der GUIDs. Dieses von Microsoft verwendete Konstrukt zur eindeutigen Identifizierung von unter Windows installierten Anwendungen, kennt natürlich keine andere Umgebung. Daher bleibt einem nichts anderes übrig, als sich selber eine GUID zu besorgen. Wer eine Microsoft Entwicklungsumgebung installiert hat, der kann mit dem Werkzeug guidgen.exe von Microsoft erledigen. Ansonsten gibt es noch ein paar Hilfreiche Webseiten zu dem Thema (Siehe Kasten: Infos im Web). Pro angebotenem Service muss die GUID eindeutig sein. Ist die Registrierung im Office erledigt, muss man noch den Query Webservice mit Leben füllen. Beim Aufruf aus Office heraus wird wieder eine XML Datei an den Webservice übergeben. Neben schier endlos vielen Infos über den Office Client (Sprache, Version, etc.) findet man in den Tiefen schließlich das eigentliche Suchwort. Neben dem Originaltext auch aufgeschlüsselt nach einzelnen Bestandteilen.
<QueryPacket >
<Query>
[…]
<Keywords
xmlns='urn:Microsoft.Search.Query.Office.Keywords' revision='1'>
<QueryText>heise</QueryText>
<Keyword>
<Word>heise</Word>
</Keyword>
</Keywords>
</Query>
</QueryPacket>
Diese sind entsprechend programmatisch zu behandeln und als Antwort auf die Anfrage ist mal wieder ein XML Dokument aufzubauen. Und genau an dieser Stelle wird es kompliziert. Mithilfe des Dokuments kann nahezu das komplette Aussehen der Aktionsleiste und eine Menge an Funktionen beeinflusst werden. Hier ist viel SDK Studieren und Probieren angesagt. Grundlegend sieht ein Response für den Research Service immer gleich aus:
<ResponsePacket>
<Response domain="{GUID}">
<QueryId>{GUID}</QueryId>
<Range>
<StartAt>1</StartAt>
<Count>10</Count>
<TotalAvailable>100</TotalAvailable>
<MustDisplayCount>10</MustDisplayCount>
<Results>
[...]
</Results>
</Range>
<Status>SUCCESS</Status>
</Response>
</ResponsePacket>
Neben den GUIDs von Aufrufer und Service sind noch die Anzeigeoptionen (Anzahl, Start, Ende, etc.) zu übergeben. Den tatsächlichen Inhalt kann man zwischen den <Results>-Tags angeben. Um den Inhalt des Heise Newstickers anzuzeigen, verwendet man am besten den Document-Typ.
<Document xmlns="urn:Microsoft.Search.Response.Document">
<Title>{Headline}</Title>
<Action>
<LinkUrl>{URL}</LinkUrl>
</Action>
<DisplayUrl>{URL}</DisplayUrl>
<Description>{Newstext}</Description>
</Document>
Neben dem Document- gibt es noch den Content- und den Form-Typ. Auch mit diesen lassen sich Ergebnisse darstellen. Mit dem Form-Typ kann man sogar komplette Formularelemente in der Aktionsleiste darstellen und so beispielsweise eine erweiterte Suchfunktion für den Recherche Dienst anbieten. Mit dem Content-Typ können beliebige Texte, Bilder, et cetera dargestellt werden. Hier sind der Phantasie und den Möglichkeiten fast keine Grenzen gesetzt. Lediglich die korrekte Aufbereitung des ResponsePacket ist eine Herausforderung. Hier muss wieder sehr auf die korrekte Abbildung auf das zugehörige Schema geachtet werden. Probiert man ein wenig mit den Recherche Diensten herum, dann stellt man schnell fest, wie hilfreiche eine solche Integration für viele Webanwendungen wäre. Neben der reinen Anzeige, können auch Funktionselemente eingebunden werden, die dem Nutzer dann erlauben die Ergebnisse direkt in das entsprechende Office Dokument zu übernehmen. Bei der klassischen Adresssuche wäre das der optimale Anwendungsfall. Manuelles Copy&Paste entfällt damit für die Anwender komplett. Vorsichtig sollte man bei der Datenmenge sein, die man an Office zurückliefert. Pumpt man die Ergebnisliste richtig voll, kann man durchaus einen Programmabsturz provozieren. Insofern sollte man wert drauf legen, mit geeigneten Datenmengen zu arbeiten. Debugging und Fehlersuche sind mal wieder so ein Thema für sich. Office versteht sich wie kaum eine andere Software darauf, den Anwender nicht mit Fehlermeldungen zu langweilen. Leider gibt es keinen Schalter, mit dem man das für Entwickler umkehren könnte. Da Fehler aber zumeist mit falsch aufgebautem und nicht schema-konformen XML zusammenhängen, findet man geeignete Wege um dieses Manko herum.
Ein sehr gutes Beispiel für eine funktionierende Office Integration haben Microsoft und SAP im vergangenen Jahr gestartet. Unter dem Namen „Mendocino“ wurde ein Joint-Venture-Produkt gestartet, welches in der aktuellen Version für vier verschiedene Anwendungsszenarien von SAP eine Office Integration bereitstellt. Die Umsetzung basiert hierbei auf dem Information Bridge Framework (IBF). Mit den schlanken Versionen der Integration kommt dieses Szenario also nicht klar. Bei diesem Ansatz wird auch deutlich, dass Mendocino nicht wirklich ein neues Produkt ist. Es handelt sich lediglich um die Abbildung von SAP Funktionen in Microsoft/Office/XML Dateien, welche vom IBF Server ausgeliefert werden. Auf Seiten von SAP mussten lediglich Webservices mit passender Fachlichkeit bereitgestellt werden. Die Darstellung im Office übernimmt das IBF Client Framework. Klar, dass Mendocino daher auch nur für die Anwender von Interesse, die die entsprechende SAP Lösung bereits im Einsatz haben. In der ersten offiziell verfügbaren Version, welche den Namen „Duet“ tragen und im Juni diesen Jahres verfügbar sein wird, werden vier SAP Produkte in die Office Welt gebracht. Darunter Lösungen für Zeitmanagement, Budgetkontrolle, Abwesenheitsmitteilungen und Organisationsmanagement. Im zweiten Halbjahr 2006 sollen dann bereits die nächsten beiden Ergänzungslieferungen verfügbar sein. Diese erweitern die verfügbaren Szenarios um Funktionen für mySAP ERP, CRM und SRM.
Auch wenn das beschriebene Beispiel erfreulich wenig Microsoft Spezialwissen benötigt, lässt sich nicht verbergen, dass erst mit der konsequenten Verwendung aller von Microsoft bereitgestellter Funktionalitäten eine wirklich gelungene Office Integration erzielen lässt. Allein aus den XML-Beschreibungen des Recherche Dienstes heraus kann kein Smart Tag auf den Client befördert werden. Hier kann man lediglich auf entsprechend installierte Versionen zugreifen. Im Umkehrschluss muss man daher auch zugeben, dass die Möglichkeiten abseits der Microsoft Welt noch als beschränkt zu bezeichnen sind. Bei bestimmten Anwendungsfällen lohnt sich der kurze und einfache Weg dennoch. Mit überschaubarem Aufwand sind auf alle Fälle beeindruckende Ergebnisse zu erzielen. Wem das nicht reicht, dem bleibt das Information Bridge Framework (IBF) mit all seinen Möglichkeiten. Dafür muss allerdings eine zugehörige Infrastruktur, bestehend aus Office Client Komponenten und Internet Information Server (IIS) verfügbar sein. Ob sich der ganze Aufwand für Unternehmen lohnt, die ihre Schwerpunkte außerhalb der Microsoft Welt haben, darf getrost bezweifelt werden. Neue Wege zeigen sich in diesem Fall mit dem kommenden Office 2007. Es kommt mit einem neuen Dokumentenformat. Dieses ist dann kein hochkomplexes OLE Verbunddokument mehr. Stattdessen wird "Open XML" verwendet. Jedes Dokument ist ein ZIP Archiv, das XML Dateien enthält. Die zugehörigen XML Schemata sind vollständig offen gelegt. Für die Vorgängerversionen soll es kostenfreie Importfilter geben, die dieses Format ebenfalls lesen und schreiben können. Damit kann Open XML sogar dort Verwendung finden, wo aus organisatorischen Gründen Office 2007 erst nach längerer Vorbereitungszeit ausgerollt werden wird. Das Erzeugen von Office Dokumenten ist damit zukünftig ohne Einschränkungen auf beliebigen Servern mit nahezu beliebigen Sprachen möglich. Die Brücke zwischen den Welten ist damit aber wieder in weitere Ferne gerückt. Vielleicht muss es zukünftig doch eine friedliche Koexistenz sein, damit die Information Worker ohne Restriktionen erfolgreich ihrer täglichen Arbeit nachgehen können und die Unternehmen dennoch Geld sparen und wachsen können.
