Blogreihe: Microsoft Dynamics CRM erfolgreich nutzen (Teil 1): Überraschend einfach einsteigen

, , ,

Für Unternehmen die ihre kundenorientierten Prozesse in Vertrieb und Marketing digitalisieren möchten, ist ein CRM System wie Microsoft Dynamics CRM unverzichtbare Voraussetzung. Viele Verantwortliche sehen die Einführung eines CRM Systems allerdings als eine Herkulesaufgabe, die sie nur mit großer Mühe bewältigen können. Mit der richtigen Strategie kann der Einstieg jedoch erstaunlich einfach gelingen.

In dieser Blogreihe zeigen wir in leicht verständlicher Sprache wie die ersten Schritte für den erfolgreichen Einsatz eines CRM Systems, hier am Beispiel des „Microsoft Dynamics CRM“, aussehen.

Weiterlesen

/0 Kommentare/von

Azure IoT in der Praxis (Teil 1): Systemaufbau

,

Azure IoT in der Praxis – Teil 1 Systemaufbau

Einleitung

Das Internet der Dinge, kurz „IoT“ ist derzeit in aller Munde. Hier übertreffen sich die „Experten“ mit Ihren Ideen und Visionen einer rosigen Zukunft. Wenn es aber um konkrete, praktische Umsetzungen geht, wenn beispielsweise die Frage beantwortet werden soll wie ein IoT Szenario in der Praxis tatsächlich gestaltet werden kann, dann wird es vertiefenden Informationen schnell sehr dünn.
Mit dieser mehrteiligen Artikelserie „Azure IoT in der Praxis“ wollen wir deshalb Abhilfe schaffen. Hier werden wir die verschiedenen Aspekte bei der Realisierung einer praxistauglichen IoT-Lösung anschaulich darstellen und beschreiben.
In diesem ersten Artikel erläutern wir einen industrietauglichen Systemaufbau und die dabei verwendeten Hard- und Software Komponenten. In den weiteren Artikeln werden wir dann einige spezielle Aspekte technisch vertiefen – beispielhaft seien hier die Themen „Datensicherheit“ oder „Alarmierung bei Störfällen“ genannt.

Wenn Sie keinen dieser Beiträge auf diesem Blog versäumen wollen, so empfehlen wir Ihnen, sich in die Mailingliste einzutragen. Sie erhalten dann eine kurze Nachricht, sobald der nächste Artikel zum Thema IoT erschienen ist. Es erfolgt keine Weitergabe der Email-Adresse an Dritte und Sie werden von uns auch keine Werbeemails bekommen. Das versprechen wir Ihnen.

Zielsetzung des IoT-Showcase

Das Team von SIC! Software hat das erste IoT Projekt mit Mobile Anbindung bereits im Jahre 2013/14 realisiert. Seitdem wächst die Zahl der erfolgreich umgesetzten Projekte ständig und damit natürlich auch der Wunsch vieler Unternehmen, mehr über diese Projekte zu erfahren und zu sehen, wie solche Lösungen erfolgreich umgesetzt werden können.
Dabei handelt es sich in nahezu allen Fällen um neuartige Konzepte und Ideen, mit denen bestehende Systeme für das digitale Zeitalter erweitert und fit gemacht werden sollen. Daher wollen unserer Kunden verständlicherweise nichts über ihre neuen Ideen veröffentlichen.
Wir haben uns daher entschlossen, einen eigenen, realitätsnahen IoT-Showcase zu schaffen, der eine durchgängige Technologiekette zeigt, wie sie von SIC! geliefert werden kann.
Dieser Showcase zeigt ein praxisnahes Beispiel von der Embedded Plattform bis hin zur Auswertung der Daten in der Cloud. Es wurde unter Verwendung von Standard-Hardware von STMicroelectronics für das IoT-System, sowie den Cloud-komponenten Microsoft Azure IoT und Microsoft PowerBI umgesetzt. Wir haben uns hier beispielhaft für die Microsoft Azure-Architektur entschieden, da dies derzeit die von unseren Kunden favorisierte IoT-Plattform ist.
Ein denkbarer Anwendungsfall einer solchen Lösung ist beispielsweise ein „Predictive Maintenance“-Szenario, bei dem der möglicherweise drohende Ausfall eines Motors erkannt wird.
Die physikalische Grundlage der Erkennung sind ungewöhnliche Schwingungsmuster, die darauf schließen lassen, dass eventuell ein Schaden am Motor vorliegt.

Auswahl der IoT-Embedded Plattform

Es gibt am Markt eine nahezu unüberschaubare Anzahl von Embedded-Plattformen für solche Anwendungen. Wir haben uns in diesem Fall für eine Evaluationshardware von STMicroelectronics entschieden. Basis ist eine auf dem STM32 Prozessor basierende Hardware (http://www.st.com/en/evaluation-tools/nucleo-f401re.html). Entscheidendes Auswahlkriterium war hier der Umstand, dass hier die für unsere Anwendung nötigen Hardwareerweiterungen für Motorsteuerung, WLAN Modul und Accelerometer-Sensorik als aufsteckbare Nucleo-Komponenten für das STM Evaluationsboard gibt.

BILD

Tiefergehende technische Details findet der interessierte Leser unter den nachfolgenden Links:
Motorsteuerung:
http://www.st.com/content/st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-move-actuate-hw/x-nucleo-ihm11m1.html
WLAN -Modul:
http://www.st.com/content/st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-connect-hw/x-nucleo-idw01m1.html
Accelerometer:
http://www.st.com/content/st_com/en/products/mems-and-sensors/accelerometers/lis3dh.html

Messverfahren und Sensorik

Das Messobjekt ist ein kleiner Drehstrom-Elektromotor mit 15W Leistung, der vom STM32 Board gesteuert, einen kleinen Propeller antreibt. Dieser ist schwingend gelagert montiert. Unter dem Motor ist der Accelerometer-Sensor am Motorträger montiert, mit welchem die Schwingungen des Motors gemessen werden.

Die fehlerhaften Schwingungen im Betrieb werden simuliert, indem am Propeller ein Klebeband angebracht und somit eine Unwucht erzeugt wird.

Signal Theorie und Motor Vibration

Spannend war die Frage, ob es mit dem Accelerometer möglich ist, die feinen Abweichungen der Schwingungsmuster sicher zu detektieren. Die üblichen Accelerometer haben einen Messbereich von +/- 2g mit einer Auflösung von 16 Bit. Das bedeutet, ein Bit entspricht 0,5mg.
Wenn man die technische Dokumentation studiert, stellt man aber fest, dass die tatsächliche, sicher zu detektierende Auflösung eher im Bereich von 1mg aufwärts liegt. (Siehe http://www.st.com/resource/en/datasheet/lis3dh.pdf). Dies sollte aber für diese Anwendung ausreichend sein.
Der kleine Drehstrommotor in unserem Prototyp läuft mit einer Drehzahl von 1500 U/Min, also 25 U/s. Es soll eine mögliche Exzentrizität gemessen und erkannt werden. Dazu gehen wir davon aus, daß jede Vibration eine Sinuswelle produziert. Zur Vereinfachung nehmen wir ferner an, dass die Drehzahl des Motors die niedrigste Frequenz produzieren wird, also rund 25Hz. Um die Sinuswelle sicher zu erkennen, muss mindestens mit der doppelten Frequenz gemessen werden, also 50Hz. In unserer Beispiellösung messen wir mit einer Abtastrate von 400 Hz. Das sollte also auch für deutlich höhere Drehzahlen des Motors noch ausreichend sein.
Für die Errechnung der Vibration gibt es mehrere Möglichkeiten. Wir haben uns hier für die Varianz als einfachste Möglichkeit entschieden (https://de.wikipedia.org/wiki/Stichprobenvarianz). Entscheidend für die Messung ist die Definition des Zeitabschnittes für eine einzelne Messung. In unserem Fall nehmen wir 512 Samples, was bei der Frequenz von 400 Hz eine Aufzeichnungsdauer von 1,2s die Daten zum Analysieren liefert.
Das ermittelte Ergebnis ist ein Messwert, welcher die Abweichung von einem Mittelwert zeigt und damit das Maß der Vibration. Steigt dieser Wert, steigt die Vibration.

Azure IoT Cloud Anbindung Embedded

Nach der Auswahl der Hardware für die Messung und Kommunikation beschrieben wurde, folgt nun der interessante Teil – die Software zur Datenerfassung und Auswertung.
Für die Integration in die Azure Cloud stellt ST eine Referenz-Implementierung für sein Evaluationsboard zur Verfügung, auf die wir weiter aufgebaut haben (http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-ode-function-pack-sw/fp-cld-azure1.html).

Quelle: http://www.st.com/content/ccc/fragment/product_related/rpn_information/board_photo/group0/f3/24/5d/c0/08/39/4c/af/FP-CLD-AZURE1%20image/files/fp-cld-azure1.jpg/_jcr_content/translations/en.fp-cld-azure1.jpg

Das reine IoT SDK von Microsoft, welches im ST-Beispielcode enthalten ist, kann unter dem nachfolgenden Link eingesehen werden (https://github.com/azure/azure-IoT-sdk-c).
Und da der Code ein Multi-Threading verwendet, ist natürlich auch ein entsprechendes Betriebssystem auf der STM32 Plattform erforderlich. Wir setzen hier aus das vielfach bewährte FreeRTOS, das auch von ST für den IoT-Einsatz empfohlen wird.

Microsoft Azure IoT Hub

Der eingesetzte Cloud-Service wird aus den entsprechenden Komponenten auf der Microsoft Azure Seite zusammengestellt. Als zentraler Knotenpunkt wird der ein Azure IoT Hub eingesetzt. Dieser dient dazu, die Daten aller IoT-Geräte entgegenzunehmen und für die weitere Auswertung den nachfolgenden Diensten zur Verfügung zu stellen.
Das Aufsetzen des IoT Hub ist unkompliziert, da dieser einfach im Azure Portal angelegt werden kann. Für diesen Showcase haben einen kostenfreien Demo- Hub eingesetzt, der bis zu 8000 Meldungen pro Tag verarbeiten kann.

Dort werden die Zugangsdaten erzeugt, welche man benötigt, um die IoT-Geräte zu Authentifizieren, damit diesen dann mit dem Hub kommunizieren können.
Anmerkung: Das Thema Sicherheit in IoT Anwendungen werden wir in Kürze in einem weiteren Artikel auf diesem Blog behandeln.

Die Darstellung der Daten im IoT Hub ist allerdings noch relativ unspektakulär. Man sieht zwar, dass Daten fließen und wie viele Geräte aktiv sind, aber für eine sinnvolle Auswertung ist dies noch nicht ausreichend.

Microsoft Azure Power BI

Um nun die gemessenen Vibrationen zu überwachen und Abweichungen erkennen zu können, werden die erfassten Messdaten mit dem Microsoft Power BI visualisiert.
Zu diesem Zweck bietet Microsoft Azure den Dienst „Stream Analytics“ an. Stream Analytics dient – wie der Name schon sagt – dazu, Datenströme zu transportieren und zu analysieren. Dabei werden der Stream Analytics Auftrag und der IoT-Hub am selben Azure-Standort gehostet, um zusätzliche Hosting-Kosten zu vermeiden.

Als Eingabequelle wird der angelegte IoT Hub ausgewählt, als Datenausgabe ein PowerBI Konto.

Damit fließen die erfassten Messdaten vom IoT-Gerät über den Azure IoT Hub und den Stream Analytics Dienst in das Microsoft PowerBI.
Dort wird ein Dashboard zu Visualisierung angelegt, auf dem in einem Liniendiagramm die Werte unserer IoT-Plattform dargestellt werden. Dieses Streamingdataset lässt sich jetzt mit allen von PowerBI zur Verfügung gestellten Mitteln auswerten.

Auswertung und Erkennung

Nachfolgende Masken zeigen, wie unser Algorithmus zur Schwingungserkennung funktioniert.
Im folgenden Diagramm sieht man deutlich den Sprung im Diagramm „Schwingung“ genau in dem Moment, wo der Motor gestoppt das Klebeband befestigt wird.

Beginnt sich der Motor mit angebrachtem Klebeband wieder zu drehen, so erhalten wir einen deutlich höheren Schwingungswert. Dies ist am höheren Schwingungsniveau zu erkennen.
In der Praxis, zum Beispiel bei einem langsam eintretenden Lagerschaden, würde dieser Schwingungs-Messwert wohl eher langsam ansteigen und nicht so schlagartig wie bei unserem Eingriff mit dem Klebeband. In diesem Falle wäre auch optisch am langfristigen Verlauf nicht viel zu bemerken, weshalb hier eine geeignete Logik zum Auswertung der Messwerte und zur Alarmierung vorzusehen ist.
Wie man auf Basis dieser Daten ein entsprechende Erkennung und Alarmierung implementiert, wird Inhalt eines nachfolgenden, vertiefenden Blogartikels sein.

Wie hat Ihnen dieser Artikel gefallen? Gerne lesen wir Ihre Kommentare.
Wenn Sie keinen dieser Beiträge auf diesem Blog versäumen wollen, so empfehlen wir Ihnen, sich in die Mailingliste einzutragen. Sie erhalten dann eine kurze Nachricht, sobald der nächste Artikel zum Thema IoT erschienen ist. Es erfolgt keine Weitergabe der Email-Adresse an Dritte und Sie werden von uns auch keine Werbeemails bekommen. Das versprechen wir Ihnen.

 

/0 Kommentare/von

Innovationsentwicklung mit User Story Mapping

, ,

In unseren Kundenprojekten wird von unseren UX Design Spezialisten regelmäßig ein sehr hilfreiches und nützliches Tool eingesetzt: Das „User Story Mapping“. Hierbei handelt es sich um eine von Jeff Patton entwickelte Methode, mit der im Rahmen von agiler Produktentwicklung eine stimmige User Experience geschaffen wird. So lässt sich der Erfolg für die auf diese Weise realisierten digitalen Produkte maximieren.

Beim User Story Mapping wird der Arbeitsfluss des Users, also des Produktnutzers, in einzelne „User Stories“ unterteilt und mit Hilfe von Klebezetteln auf einer Wand in Form einer Art Karte („Map“) visualisiert. Die Flexibilität der Klebezettel ermöglicht eine schnelle und einfache Optimierung der Prozesse bzw. des Produktes durch Umsortieren, Aufteilen, Ergänzen, Erweitern, Vertiefen, usw. An einer User Story Mapping Session nehmen idealerweise alle am Produkt Beteiligten – vom Auftraggeber über den Designer bis zum Entwickler – teil und erarbeiten einen Konsens. Durch das bessere gemeinsame Gesamtverständnis vom Produkt, seinen Eigenschaften und seiner Anwendung wird die Gefahr reduziert, sich in unwichtigen Details zu verzetteln oder das Produkt an den Bedürfnissen des Produktnutzers vorbei zu entwickeln.

Mit User Story Mapping wird ein Produkt mit genau jenen Features entwickelt, die für den Anwender wirklich nützlich und dabei auch noch realisierbar und bezahlbar sind. Dabei können mehrere aufeinanderfolgende Release-Stufen festgelegt werden – angefangen vom „Minimum Viable Product (MVP)“ über Zwischenversionen bis zur finalen Version mit dem kompletten Feature-Set. Die in der ersten Session erstellte User Story Map bildet gleichzeitig eine Basis für das Projektmanagement. Im Verlauf des Projekts kann und soll die Story Map im Rahmen einer agilen Produktentwicklung in weiteren Sessions anhand von User Feedback, Tests und Erfahrungen dann permanent weiter optimiert werden.

Entsprechend einem vielfach von unseren Kunden geäußerten Wunsch nach einer kompakten Übersicht und Kurzanleitung zum User Story Mapping haben unsere Grafiker eine Infografik mit dem Titel „Innovationsentwicklung mit User Story Mapping“ erstellt, die wir hiermit gerne allen an der Methode Interessierten zur Verfügung stellen. zur Infografik

vorschau-infografik-user-story-mapping

/1 Kommentar/von

MQTT Protokoll: Anwendungsbeispiele

, , , , ,

Viele Leser unseres Blogs haben uns nach dem Studium unseres Grundlagenartikels zum MQTT-Protokoll nach Anwendungsbeispielen gefragt. Diesem Wunsch wollen wir gerne entsprechen und präsentieren Ihnen nachfolgend eine kleine Sammlung einiger interessanter Projekte, bei denen das MQTT-Protokoll zum Einsatz kommt.

Wir bei SIC! Software setzen das MQTT Protokoll im Bereich von Embedded Projekten sehr häufig ein, da dieses Protokoll einfach zu handhaben ist und sich dank breiter Unterstützung zum DeFacto-Standard im Bereich von Internet of Things (IoT) und Industrie 4.0 entwickelt hat.

Wie z.B. beim Forschungsprojekt IMPROVE, bei dem das MQTT Protokoll dazu eingesetzt wird, um Echtzeitdaten vom Fahrzeug zu übertragen.
/forschungsprojekte/improve-automotive/

 

Da unsere Kundenprojekte der Vertraulichkeit unterliegen, listet die nachfolgende Sammlung beispielhaft öffentlich zugängliche Projekte mit MQTT-Support auf.

 

Beispiel 1: Übermittlung von Temperatursensor-Daten

Implementierung von MQTT auf dem  ESP8266 WIFI Funkmodul mit einer „einfachen“ publish / subscribe Routine.

http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/113-mqtt-basic-esp8266-mqtt-example

—

Beispiel 2: Übertragung des Haustürklingel-Signals

Installation des Moskito MQTT Broker auf einem Raspberry Pi. Ein ESP8266 nimmt das Klingelsignal an der Haustür auf und sendet es drahtlos an Fhem via MQTT.

http://blog.wenzlaff.de/?p=6487

—

Beispiel 3: Temperatur-Überwachung (Englisch)

Eine Musterhafte Lösung zur Überwachung von Temperaturen mit dem ESP8266 WIFI Funkmodul und der Anbindung an einen MQTT-Broker-Dienst unter Ubuntu:

http://www.instructables.com/id/Remote-Temperature-Monitoring-Using-MQTT-and-ESP82/

—

Beispiel 4: Basis-Plattform für Home-Automation (Englisch)

Implementierung eines MQTT-Stacks auf einem ATMEL  ATmega328p

http://blog.atx.name/building-avr-board-with-mqtt-support-for-iot/

—

Beispiel 5: Steuerung einer LED-Beleuchtung (Englisch)

Steuerung einer LED-Beleuchtung mit einem WS2812 LED Controller über das MQTT-Protokoll.

http://www.instructables.com/id/ESP8266-Led-Strip-MQTT-Control-Lights-WS2812/?ALLSTEPS

—

Beispiel 6: Regelung der CPU-Kühlung eines Raspberry Pi (Englisch)

Regelung der CPU-Kühlung eines Raspberry Pi über einen mit dem MQTT-Protokoll konfigurierbaren PID Regler:

http://www.instructables.com/id/PID-Control-for-CPU-Temperature-of-Raspberry-Pi/

—

Beispiel 7: Steuerung eines LCD-Displays (Englisch)

Applikationsbeispiel zur Steuerung eines LCD-Displays am INTEL Edison über das MQTT-Protokoll:

http://www.instructables.com/id/MQTT-what-is-this/

—

Weitergehende Grundlagen und Informationen zur MQTT-Standardisierung sind auf der Webseite http://mqtt.org/ beschrieben.

Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

IoT Protokolle – MQTT vs. AMQP

Modbus über MQTT – wie geht das?

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

/0 Kommentare/von

IoT Protokolle: MQTT vs. AMQP

, , , , ,

Das „Internet of Things“ – kurz „IoT“ – ist im Moment das große Thema in der Industrie und Softwarebranche. Nachdem wir schon in einem etwas älteren Blockartikel das Thema MQTT aufbereitet und analysiert haben, ist es Zeit, sich einem zweiten wichtigen Protokoll im Umfeld von IoT anzunehmen. In diesem Artikel werden wir die beiden Protokolle vergleichen und mögliche Unterschiede bei den Einsatzszenarien beschreiben.

Wer heute ein IoT-Projekt umsetzen möchte, muss sich vor allem Gedanken darum machen, wie er die auszutauschenden Daten möglichst effizient und standardisiert übertragen kann. Zu diesem Zweck gibt es verschiedenste Protokollstandards, die entwickelt wurden, damit Plattform und Technologie übergreifend miteinander kommunizieren können.

Speziell im IoT Umfeld erfüllen die entwickelten Protokolle vor allem noch die Aufgabe möglichst mit wenigen Ressourcen auszukommen.

Was ist also AMQP und was kann es leisten?

AMQP steht für Advanced Message Queuing Protocol und wurde durch ein Konsortium von großen Unternehmen aus verschiedenen Branchen – u.a. VMware, Microsoft und Cisco – entwickelt. Bereits in 2010 gab es den ersten Draft des Protokolls.

Im Kern handelt es sich um ein asynchrones Protokoll zur Nachrichtenübertragung. Die bisher beste Erklärung zur Idee hinter AMQP findet man auf der Seite von RabbitMQ (https://www.rabbitmq.com/tutorials/amqp-concepts.html).

AMQP funktioniert demnach nach folgendem Prinzip:
Nachrichten werden an sogenannte Börsen (Exchanges) übertragen (vergleichbar mit einem Postamt). Die Börsen verteilen dann Nachrichtenkopien in Warteschlangen (Queue) basierend auf Regeln, sogenannten Bindings.

Die Nachrichten werden dann vom Empfänger direkt abgeholt, wenn er das möchte. Alternativ kann der Empfänger die Nachrichten auch bei einer Warteschlange abonnieren und bekommt diese dann direkt zugestellt.

Wenn die Nachrichten publiziert werden, kann der Herausgeber der Nachricht diese noch mit Attributen (Meta-Daten) versehen. Diese Metadaten können vom Empfänger beliebig genutzt werden.

Nachrichten bleiben so lange in den Warteschlangen, bis der Empfänger bestätigt hat, die Nachricht auch wirklich empfangen zu haben. Damit ist auch bei schlechtem Netz und Abbrüchen bei der Verbindung sichergestellt, dass die Nachricht den Empfänger erreicht.

Wenn eine Nachricht nicht zugestellt werden kann, erhält der Sender eine entsprechende Nachricht.
Die Umsetzung der Börse und der Warteschlange erfolgt innerhalb des sogenannten Brokers. Ein Broker ist z.B. der freie Server von RabbitMQ.

Die Börse ist dafür zuständig, die Nachrichten in eine oder mehrere Warteschlangen zu übertragen. Die Regeln dafür leiten sich aus den vordefinierten Austauschformaten (exchange types) und den Bindings ab.

Es gibt vier solche Austauschformate:

  • Direct –> Stellt eine feste Verbindung zwischen einer Börse und einer Warteschlange dar. Wenn eine Nachricht mit einem entsprechenden Schlüssel ankommt, wird diese gleich an die verknüpfte Warteschlange zugestellt.
  • Fanout –> Wird für sogenannte Broadcast Nachrichten verwendet. Die Nachricht wird von der Börse an alle angeschlossenen Warteschlangen zugestellt
  • Topic –> Wird für Publish/Subscribe Szenarien verwendet. Die Nachrichten werden an eine oder mehrere Warteschlangen ausgeliefert, abhängig vom Binding Key. Folgendes Bild von RedHat veranschaulicht das sehr schön.
  • Headers –> Die Zustellung der Nachricht zur Warteschlange erfolgt hier über den Nachrichten-Header und nicht den Routing Key. Es ist vergleichbar mit dem Direct Routing – nur mit etwas mehr Möglichkeiten zur Regelerstellung.

Neben den Austauschformaten gibt es eine Reihe von Attributen für die Nachrichten. Die wichtigsten sind:

  • Name
  • Durability (gibt an, ob die Börse einen Neustart des Broker übersteht)
  • Auto-delete (Börse wird gelöscht, wenn keine Warteschlange diese benötigt)

AMQP vs. MQTT im Vergleich

Der größte Unterschied der beiden Protokolle besteht in den Möglichkeiten für die Nachrichtenzustellung. Während MQTT ausschließlich auf Publish/Subscribe basiert, lassen sich mit AMQP auch andere Zustellungsformen realisieren.

Außerdem ist der Unterschied bei der Implementierung nicht zu unterschätzen. MQTT ist mit seinen 5 Methoden relativ schnell und einfach umzusetzen, während AMQP schon einen vergleichsweise großen Umfang mit sich bringt. Das betrifft sowohl die Definition des eigenen Protokoll wie auch die Implementierung und Test.

Die kleinste Paketgröße bei AMQP ist mit 60 Byte auch nicht zu vernachlässigen. MQTT begnügt sich im besten Fall mit 2 Byte. Das beeinflusst insbesondere bei einer großen Zahl von Geräten und Nachrichten den aufzuwendenden Aufwand erheblich. Dazu kommen größer Laufzeiten der Pakete die je nach Anwendungsfall auch kritisch zu betrachten sind.

Es gilt also abzuwägen, ob der Funktionsumfang von AMQP im jeweiligen Anwendungsfall wirklich benötigt wird oder nicht. Wenn man mit dem Publish/Subscribe Model von MQTT auskommen kann, hat man in jedem Fall eine einfacher umzusetzende und auch ressourcenschonende Lösung.

Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

MQTT Protokoll – Anwendungsbeispiele

Modbus über MQTT – wie geht das?

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

 

/0 Kommentare/von

Vertrieb 4.0: Digitalisierung in Vertrieb und Marketing (Teil 3): Digitale Vertriebs Systeme in der „Perfektionismus Falle“

, , ,

Als Berater für die Digitalisierung von Geschäftsprozessen im Kontext von Vertrieb 4.0 werden wir von unseren Kunden immer wieder mit der Anforderung konfrontiert, ein „perfektes, flexibles und zukunftsfähiges“ IT-System für den Vertrieb zu planen, welches idealerweise nicht nur die aktuellen Anforderungen sondern möglichst auch die der kommenden 10 Jahre erfüllen kann.

Mission Impossible

Interessanterweise tappen oftmals gerade die als marktführend wahrgenommenen Unternehmen in diese technische und organisatorische “Perfektionismus-Falle” bei der Umsetzung der Paradigmen von Vertrieb 4.0. Sie wollen ihre oft stark veralteten technischen IT-Systeme (CRM, ERP) entweder mit wenig Aufwand zukunftsfähig machen oder aber durch ein neues, perfektes und für alle künftigen Herausforderungen gewappnetes (CRM-)System für den Vertrieb ersetzen. Natürlich will man dabei auch möglichst wenig investieren und sehr ressourcenschonend vorgehen. Die Umsetzung von Vertrieb 4.0 soll dann von einem Assistenten des IT- oder Vertriebsleiters verantwortet werden, der zudem als „Digital Evangelist“ nebenbei auch noch alle anderen Unternehmensstrukturen ins digitale Zeitalter transformieren soll. Das jedoch ist eine „Mission Impossible“ und wir kennen kein Unternehmen, das einen derartigen Zielkonflikt kompromisslos hätte für sich lösen können.

Denkmuster aus dem letzten Jahrhundert

Doch woher stammt dieser Denkfehler? Dazu müssen wir in die 90er Jahre des vergangenen Jahrhunderts zurückblicken, also den Zeitraum in welchem viele der heute verantwortlichen CIOs ihre eigenen, unmittelbaren Praxiserfahrungen gesammelt haben. Damals hatten die etablierten IT-Unternehmen wie IBM, SAP und andere ihren Fokus auf der Einführung kompletter ERP Landschaften. Die Probleme ihrer Kunden lösten sie, indem sie einfach eine bestehende Arbeitsweise in einem Unternehmen möglichst 1:1 in einem preiswerten Stück Software abgebildet haben. Vorher war es Handarbeit und Papier, nachher eben eine Software im PC.

Der Vertriebsprozess selbst dagegen blieb davon weitestgehend unberührt, bestenfalls wurde noch eine Adressverwaltung mit Umsatzlisten kombiniert. Zu dieser Zeit konnte sich aber auch noch niemand vorstellen, wie die B2B-Vertriebsprozesse 15 oder 20 Jahre später aussehen und funktionieren würden. Dieser Umstand ist bis heute auch im Kontext von Vertrieb 4.0 noch unverändert gültig. Er hat sich sogar noch weiter verschärft, da sich die Geschwindigkeit des digitalen Wandels und die damit verbundenen Einflussfaktoren massiv erhöht haben.

Man kann aber aus den Erfahrungen von IBM & Co für den Vertrieb 4.0 doch etwas lernen, weil auch damals nämlich versucht wurde, „moderne” Vertriebsprozesse (Beispiel BANT-Kriterien) und ihre Anforderungen vollständig in den bestehenden IT-Infrastrukturen abzubilden. Der Vater der populären IBM Websphere Plattform, Donald Ferguson, bringt das in einem Interview ziemlich auf den Punkt:

Frage:
“What’s the biggest technology mistake you ever made – either at work or in your own life?”

Antwort:
“When I was at IBM, I started a product called Websphere [which helps companies to operate and integrate business applications across multiple computing platforms]. Because I had come from working on big mission-critical systems, I thought it needs to be scalable, reliable, have a single point of control … I tried to build something like a mainframe, a system that was capable of doing anything, that would be able to do what might be needed in five years. I call it the endgame fallacy. It was too complex for people to master. I overdesigned it.“

Das „perfekte Vertriebs-System“ – ein Denkfehler

Diesem Denkfehler, unbedingt bereits zu Beginn ein perfektes System für den digitalisierten Vertrieb zu definieren, unterliegen heute auch die meisten etablierten Unternehmen, die sich in Richtung Vertrieb 4.0 bewegen. Sie versuchen zwanghaft ihre IT-Prozesse im Vertrieb so weit wie möglich gleich komplett zu definieren und danach umzubauen, so dass man alle Eventualitäten des digital unterstützten Vertriebsprozesses auf Anhieb meistern kann. Der Anspruch dabei ist nicht mehr und nicht weniger, als „das perfekte Vertriebssystem“ digital abzubilden.
Doch das ist aufgrund der Dynamik in der Digitalisierung und den rasanten Entwicklungen im technischen Fortschritt von der IT-Abteilung in absehbarer Zeit so nicht umsetzbar. Denn niemand kann heute wissen, welche Arbeitsweisen und Prozesse in fünf Jahren für einen erfolgreichen Vertrieb relevant sein werden. Alles, was heute noch einen Knaller in der Branche darstellt, kann bereits in zwei Jahren ein vom Kunden als selbstverständlich erachteter Standard sein.

Alte Probleme werden ohne eigene Digitalisierung verschärft

In der Zwischenzeit sind die Außendienstmitarbeiter aber leider noch immer mit Block und Stift sowie Print-Katalogen und Papier-Datenblättern unterwegs, bestenfalls unterstützt durch einige Powerpoint-Präsentationen auf unhandlichen Laptops. Gleichzeitig führt der digitale Fortschritt aber dazu, dass dem Vertriebsmitarbeiter Kunden gegenüber sitzen, die sich dank Internet immer besser informieren. Gleichzeitig bearbeiten bzw. betreuen immer mehr Wettbewerber ihre Interessenten und Kunden mithilfe der Digitalisierung viel intensiver als früher und sichern sich damit Wettbewerbsvorteile. Steigender Aufwand für Angebotstermine, sinkende Abschlussquoten sowie Nachwuchsprobleme machen die Situation zusätzlich nicht einfacher.

Vertrieb 4.0 – schneller Einstieg contra perfekte Lösung

Für jedes Unternehmen, das mittel- bis langfristig überleben möchte, stellt sich daher nicht die Frage, ob die Vertriebsprozesse im Sinne von Vertrieb 4.0 digitalisiert werden sollen, sondern nur noch wann. Dabei gilt eindeutig der Grundsatz: Je schneller, desto besser! Denn es werden jene Unternehmen, die einen unmittelbaren, leichtgewichtigen Einstieg in die digitalen Vertriebsprozesse wählen, wie z.B. mit VERMO cloud, um diese dann erst im Laufe der Zeit zu optimieren und zu erweitern, die Nase vorn haben. Diejenigen Unternehmen dagegen, die in langwierigen internen Verfahren versuchen, gleich auf Anhieb ein bis ins letzte Detail perfektes Vertriebs-System zu kreieren, werden das Nachsehen haben. Für ein Unternehmen ist es daher ratsam, sich gut zu überlegen, in welcher technischen Perfektion man seine Vertriebsprozesse im Kontext von Vertrieb 4.0 im ersten Schritt digital abbilden will, um nicht am Ende in die „Perfektionismus-Falle“ zu tappen.

Blog-Reihe „Vertrieb 4.0 – Digitalisierung und Vernetzung der Prozesse in Vertrieb und Marketing“

Weitere Beiträge zum Thema Digitalisierung im Vertrieb:

Die Messe als Umsatz-Booster: 5 Tipps für ein gewinnbringendes Messe-Lead-Management

 

/0 Kommentare/von

Vertrieb 4.0: Digitalisierung in Vertrieb und Marketing (Teil 2): Die 5 wichtigsten Herausforderungen für den Vertrieb

, , ,

Bei Führungskräften und Vertriebsmitarbeitern in Unternehmen ist häufig zu beobachten, dass sie mit den Vorgehensweisen und Einstellungen der Vergangenheit versuchen, auch in der Gegenwart oder sogar der Zukunft erfolgreich zu sein. Das Umfeld, in dem wir uns jedoch aktuell befinden, ist gekennzeichnet durch eine rasante Beschleunigung, welche durch die zunehmende Digitalisierung getrieben wird. Die mit Industrie 4.0 sich verändernden Anforderungen der Kunden bedeuten auch für den Anbieter, eine neue Denkweise in seinen Vertriebsstrukturen zu implementieren.

Es sind vor allem die folgenden fünf wichtigsten, aktuellen Herausforderungen für den Vertrieb, die eine Digitalisierung der Vertriebsprozesse in Vertrieb und Marketing im Sinne von Vertrieb 4.0 notwendig machen:

1. Bestandskunden müssen viel enger betreut werden.
Wenn Sie es nicht tun, dann tut es Ihr Wettbewerber. Gerade in Märkten, die hart umkämpft sind, entsteht nicht sofort mehr Kaufkraft, sondern ist häufig zuerst eine Umverteilung zu beobachten. Wenn ein Hersteller von Bauteilen beispielsweise einen Großkunden über Jahre mit modernster Technik beliefert hat, wünscht der Kunde heute vielleicht ein komplettes Funktionsmodul, was aus Sicht des Kunden nicht zwingend vom bisherigen Lieferanten bezogen werden muss. Und plötzlich werden Beziehungen zwischen dem Kunden und dem Anbieter auf die Probe gestellt. Rein bedarfsorientiertes Verkaufen ist hier in der Regel chancenlos.

2. Inbound Marketing als zentrales Thema zur Neukundengewinnung
Der klassische „cold calling“ – Ansatz ist im B2B Vertrieb fast obsolet. Interessenten und auch Kunden wollen heute selbst entscheiden, wann sie mit wem zu welchem Thema in Kontakt treten. Die Telefonkaltakquise wird bei Interessenten zunehmend als lästig empfunden und führt beim Auftraggeber in der Regel nicht zu den gewünschten Resultaten. Noch schlimmer: er bindet in Vertrieb und Verkauf häufig Mitarbeiter, die Tag ein Tag aus die Nadel im Heuhaufen suchen, sprich einen Kunden der optimal zum Lösungsangebot passt. Im modernen Vertrieb 4.0 geht es darum, genau zu wissen, wie der ideale Ziel-Wunschkunde seine Kaufentscheidungen vorbereitet, um dann im richtigen Moment die potentiellen Kunden anzusprechen.

3. Vertrieb muss die informelle Führung im Verkaufsprozess zurückerobern
Aufgrund der fortschreitenden Digitalisierung durchläuft ein Kunde die ersten und häufig entscheidenden Stufen im B2B Verkaufsprozess eigenständig. Über das Internet sucht er den passenden Anbieter für seine Aufgabenstellung und prüft, wer sein Interesse verdient, weil er eine optimale Lösung verspricht. Der Anbieter wird häufig erst dann tatsächlich kontaktiert, wenn es um die Lösung oder ein konkretes Angebot geht. Bei solch einem Einstieg geht es darum, dass der Vertriebsmitarbeiter als Erstes die informelle Führung im Verkaufsgespräch zurückerobert. Ansonsten besteht die Gefahr, wertvolle Zeit in Kunden zu investieren, die nicht zum Unternehmen passen oder nur eine geringe Abschlusswahrscheinlichkeit versprechen.

4. Enge Zusammenarbeit von Marketing und Vertrieb gefordert
In den meisten B2B Vertriebsszenarien bei mittelständischen Unternehmen sind mehrere Unternehmensbereiche in die Gewinnung von Neukunden eingebunden. Und deshalb kommt es auf das Zusammenspiel an. Die zentrale Frage dabei lautet: wer hat den zentralen Hut auf und wer sieht sich in welcher Rolle? Die Antwort fällt leicht, wenn wir uns ansehen, was die Kunden wünschen und brauchen, um zu einer guten Kaufentscheidung zu kommen. In den allermeisten Fällen geht es darum, den Kunden sicher zu seiner Kaufentscheidung zu führen.

5. Andere Ergebnisse fordern ein anderes Verhalten
Wenn neue Technologien und Geschäftsmodelle in den Markt kommen, weil sie von Kunden gefordert oder von Anbietern vorangebracht werden, dann ist es klar, dass sich Menschen an irgendeinem Ort ändern müssen. Auf jeden Fall trifft es die Anwender bestehender Lösungen oder Arbeitnehmer in Prozessen, die zukünftig digitalisiert werden. Dort, wo kaum ein Augenmerk liegt, ist im IT-Vertrieb. Hier besteht manchmal noch die Erwartungshaltung, dass Verkäufer, wenn sie welche sind, alles verkaufen können und somit gestern Produkte mit Features & Functions verkauft haben und jetzt eben Lösungen. Jeder, der die Branche in den letzten Jahren in diesem Bereich aktiv beobachtet hat, sieht, dass das nicht immer ohne eine persönliche Entwicklung funktioniert. Nichts wirkt mehr als Authentizität und deshalb dürfen Menschen auf diesen Positionen nicht verbogen werden, sondern sollten nach ihren Fähigkeiten eingesetzt sein. Und dann haben sie auch einen Anspruch darauf, stärken- und ergebnisorientiert geführt zu werden.

Blog-Reihe „Vertrieb 4.0 – Digitalisierung und Vernetzung der Prozesse in Vertrieb und Marketing“

Weitere Beiträge zum Thema Digitalisierung im Vertrieb:

Die Messe als Umsatz-Booster: 5 Tipps für ein gewinnbringendes Messe-Lead-Management

 

/0 Kommentare/von

Blogreihe: Microsoft Dynamics CRM erfolgreich nutzen (Teil 7): Ansichten einfach Anpassen

,

Microsoft Dynamics CRM (Teil 7) – Ansichten einfach Anpassen

In diesem Teil der Blogreihe erfahren Sie:

  • Wie Sie die Optik Ihrer Ansichten in Dynamics verändern können
  • Wie Sie selbst Felder in Ihren Ansichten hinzufügen und verändern können
  • Wie Sie Dynamics für die mobile Nutzung optimieren

Im Auslieferungszustand finden sich in Microsoft Dynamics in allen Bereichen sehr umfangreiche Eingabemasken, die für die meisten Nutzer des CRM-Systems auf den ersten Blick eher abschreckend wirken.
Das liegt vor allem daran, dass hier von Microsoft versucht wurde, möglichst viele Informationen darzustellen, um das Dynamics CRM für eine sehr breite Gruppe an Nutzern attraktiv zu machen.
Jedes Unternehmen hat allerdings sehr unterschiedliche Bedürfnisse an die Daten rund um ihre Kunden und unterschiedliche Ansichten darüber, was tatsächlich relevante Informationen sind.
Daher ist es für einen effektiven Einsatz im Unternehmen sinnvoll, die Masken und Felder an die eigenen Bedürfnisse anzupassen. Dies vereinfacht die Bedienung und steigert die Akzeptanz des CRM-Systems im Unternehmen.

MS Dynamics erlaubt es dem Anwender sehr einfach sowohl das Look&Feel als auch den Aufbau aller Eingabemasken und Seiten zu verändern.
Wir starten mit einem einfachen Beispiel und zeigen hier wie man die Ansicht zum Datensatz eines „Lead“ verändern kann.

TIPP: Um mit dem Formulareditor von MS Dynamics schnell und komfortabel arbeiten zu können, sollten Sie einen Computer mit einem möglichst großen Bildschirm (> 20 Zoll) benutzen

Ansicht Lead verändern

Öffnen Sie zum Verändern dieser Ansicht einfach einen beliebigen Lead.

Lead1

Öffnen Sie nun im oberen Menü über den rechten Eintrag „…“ den Formular Editor.

Lead2

Es öffnet sich ein neues Fenster mit sehr vielen Einstellmöglichkeiten zu der aktuellen Ansicht. Lassen Sie sich aber nicht erschrecken – Änderungen am Layout sind recht einfach zu bewerkstelligen.

Lead3

Angenommen Sie benötigen die Information, zu welchem Zeitpunkt dieser Lead zuletzt aktualisiert wurde, auch in der Lead Ansicht.
Dazu scrollen Sie im rechten Bereich mit der Überschrift „Feld Explorer“ einfach so weit, bis Sie den Eintrag „Geändert am“ finden. Klicken Sie mit der Maus auf diesen Eintrag und ziehen Sie diesen jetzt mit gedrückter Maustaste nach links in den Bereich „Kontakt“.

Lead4

Eine rote Line kennzeichnet den Bereich, in welchen das zusätzliche Feld eingefügt wird, wenn Sie die Maustaste loslassen.

Lead5

TIPP: Es empfiehlt sich die Standardansichten zu belassen und alle Änderungen jeweils unter einem neuen Namen zu speichern. Bitte klicken Sie nach Ihrer ersten Änderung an der Ansicht links oben auf das Symbol „Speichern unter“ und vergeben Sie einen aussagekräftigen Namen für Ihre neue Ansicht. Damit haben Sie eine neue Ansicht erstellt.

Jetzt können Sie die Ansicht ganz nach Ihren Wünschen und Bedürfnissen umgestalten. Löschen Sie am besten zuerst alle nicht benötigten Felder, um mehr Übersicht und Platz auf dem Bildschirm zu bekommen. Dazu klicken Sie ein Feld an – es bekommt einen blauen Rand – und nun drücken Sie die Taste „Entfernen“.
Sollten Sie versehentlich ein falsches Feld gelöscht haben, können Sie die Aktion mit der Tastenkombination STRG-Z oder dem Rückgängig-Symbol wieder rückgängig machen.

Lead6

Die Anordnung bestehender Felder kann ganz einfach per Drag&Drop verschoben werden.

Um einzelne Gruppen von Feldern, die sog. Registerkarten, in Gänze zu verändern, machen Sie einen Doppelklick, z.B. auf „Zusammenfassung“. Es öffnet sich ein Fenster, in dem verschiedene Details dieses Bereichs verändert werden können.

Lead7

Wollen Sie z.B. die Darstellung von drei auf zwei Spalten ändern, so können Sie das unter dem Reiter „Formatierung“ einstellen.

Lead8

Damit lassen sich alle bestehenden Ansichten deutlich übersichtlicher gestalten, ohne unnötigen Datenballast mitzuschleppen, der die Arbeit mit dem CRM erschwert.

Die gemachten Änderungen beziehen sich auch immer nur auf die Ansicht. Sollten Sie irgendwann die Felder wieder benötigen, können Sie diese einfach wieder hinzufügen. Es geht nichts verloren.

Wichtig: Mit dem Befehl „Speichern“ alleine ist Ihre Änderung noch nicht im MS Dynamics verfügbar. Sie müssen diese auch noch veröffentlichen. Klicken Sie dazu auf „Veröffentlichen“.

Lead9

Nun steht Ihre neue Ansicht allen Benutzern Ihres MS Dynamics CRM-Systems zur Verfügung.

Neue Standardansicht

Nachdem Sie alle Anpassungen durchgeführt haben, können Sie das Ergebnis live ansehen, indem Sie wieder einen Lead-Datensatz öffnen.

Schalten Sie die Ansicht um, indem Sie über dem Titel die Auswahl öffnen.

Lead10

Um diese Ansicht jetzt zum Standard zu machen, gehen Sie im Kachelmenü in den Reiter „Einstellungen“ ? „Anpassung“ ? Eintrag „Anpassungen“ ? Neuer Dialog „System Anpassen“
Lead11 Lead12

Öffnen Sie jetzt im linken Hierachiebaum die „Entitäten“ und suchen Sie den Eintrag „Lead“. Doppelklicken Sie auf die Entität „Lead“. Diese wird im linken Hierarchiebaum geöffnet. Dort wählen Sie den Eintrag „Formulare“. Es erscheint der Dialog zum Verwalten der Formulare.

Lead13

Lead14

Wählen Sie jetzt „Formularreihenfolge“ –> „Hauptformularsatz“. Jetzt wir Ihr neues Lead-Formular in der Liste erscheinen und Sie können es an die erste Stelle schieben. Damit wird es zum neuen Standard für die Lead-Ansicht.

Lead15

Die alten Ansichten lassen sich natürlich weiterhin auswählen, wenn gewünscht, solange Sie diese nicht löschen.

Auf diese Art und Weise lassen sich jetzt alle Ansichten im MS Dynamics CRM anpassen und zum neuen Standard erklären.

Mobile Nutzung

Für die mobile Nutzung können Sie ebenfalls eine separate Ansicht erstellen. Microsoft hat hier auch schon einige Vorlagen mitgeliefert, aber Sie können auch diese Ansichten nochmals für Ihre Bedürfnisse anpassen.

Gehen Sie in „Einstellungen“ ? „Anpassungen“ ? „System Anpassen“

Öffnen Sie jetzt die „Entitäten“ und suche Sie „Lead“. Wenn Sie die Entität „Lead“ geöffnet haben, wählen Sie „Formulare“. Das Formular „Information“ ist die normale Ansicht für mobile Geräte. Öffnen Sie diese Ansicht und bearbeiten Sie diese wie oben beschrieben. Speichern Sie auch diese Ansicht unter einem neuen Namen und veröffentlichen Sie die Änderung.

Danach setzten Sie unter „Formularreihenfolge“ ? „Mobil-Express“ das neue Template nach oben.

Lead16

Auch Sie werden sicherlich schnell erleben, dass mit Änderungen in den Ansichten des CRM-Systems in Punkto Akzeptanz und Effizienz eine deutliche Verbesserung im Unternehmen eintreten wird. Vergessen Sie dabei nicht, Ihre Arbeitskollegen über die neu verfügbaren Ansichten in Ihrem MS Dynamics CRM zu informieren.

 

Microsoft Dynamics CRM erfolgreich nutzen

Blogartikel-Übersicht:

TEIL 1: MS Dynamics CRM – Überraschend einfach einsteigen

TEIL 2: MS Dynamics CRM – Unterschiede der Versionen

TEIL 3: MS Dynamics CRM – arbeiten mit Leads

TEIL 4: MS Dynamics CRM – Kontakte und Firmen

TEIL 5: MS Dynamics CRM – Marketinglisten ganz einfach

TEIL 6: Auswertungen, Diagramme und Filter

TEIL 7: Ansichten einfach Anpassen

Weitere Beiträge zum Thema Digitalisierung im Vertrieb:

Die Messe als Umsatz-Booster: 5 Tipps für ein gewinnbringendes Messe-Lead-Management

Vielleicht auch interessant:

Wie lassen sich die Informationen aus dem persönlichen Beratungs- oder Verkaufsgespräch schnell, einfach und vollständig im CRM-System erfassen?

Lösung: Mit einer Mobilen Vertriebs-App, die eine automatisierte Gesprächsdatenerfassung ermöglicht.

/0 Kommentare/von

Swift: Die eine Programmiersprache für „alles“ ?! (Teil1)

,

tl;dr

  • Swift eignet sich bereits jetzt zur Entwicklung einer produktiven verteilten mobilen Anwendung (Client-App + Backend-Webservice)
  • Proof-of-Concept Beispiel: verteilte App mit Shared Code
  • Deployment des Webservices via Docker-Container
  • Große Vorteile für Developer, DevOps, CTOs, CIOs und die zentralen Stakeholder/Kunden
  • Update: links und libraries-Empfehlungen

Apples Swift und Open Source

Im Juli 2014 hat Apple der Öffentlichkeit die neue Programmiersprache Swift vorgestellt. Zunächst wurde auf den eigenen Plattformen die Software-Entwicklung mit dieser Sprache realisiert: von der kleinen Smartwatch appleWatch (watchOS), über die Set-Top-Box appleTV (tvOS), auf ihren mobilen Geräten iPhone/iPodTouch/iPad (iOS) bis hin zu ihren Desktop-Geräten MacPro/iMac/MacBookPro/… (OSX).

Vor etwa einem halben Jahr (Dezember 2015) ging Apple dazu über, Swift als Open-Source Projekt der Öffentlichkeit bereitzustellen. Apple war mit diesem Schritt derart entschlossen und überzeugt, dass sie die Vorteile von ihrer aktuellen Programmiersprache Swift -z.B. die Flexibilität und die Skalierbarkeit (von Command-Line-Tools über Software für ‚kleine‘ embedded IoT-Geräte bis hin zu Server-Systemen und Betriebssystemen), die maschinennahe performate Ausführung  der damit erstellten Software (kompilierter/nativer Binär-Code !), sowie die modernen Features und Sprachkonstrukte- der gesamten Developer/IT-Community bereitgestellt haben wollten. Das ausgesprochene Ziel Apples: Durch die verändernden Software/IT-Anforderungen heutiger Systeme und Anwendungen, die in die Jahre gekommene native Programmiersprache C (bzw. auch C++) als de-facto-Standard mittelfristig abzulösen. Ein sehr ehrgeiziges Ziel -wie man ruhig finden darf- das nur durch Offenlegung und die Beteiligung der großen Entwickler-Community überhaupt erst machbar sein kann.

Weiterlesen

/6 Kommentare/von

Blogreihe: Microsoft Dynamics CRM erfolgreich nutzen (Teil 6): Auswertungen, Diagramme und Filter

,

Microsoft Dynamics CRM (Teil 6) – Auswertungen, Diagramme und Filter

In diesem Teil der Blogreihe erfahren Sie:

  • Wie Sie einfach Auswertungen mit ihren Daten durchführen können
  • Wie Sie selbst Diagramme nach ihren Bedürfnissen erstellen

Weiterlesen

/1 Kommentar/von