Category Archives: Digitale Transformation – Digitalisierung

Digitale Transformation – Digitalisierung

05Sep/17
API

Webservice

In der heutigen Zeit gibt es Anwendungen wie Sand am Meer. Nicht wenige erkennen Synergiepotenziale bei einer Zusammenarbeit von Applikationen.

Beispiel: Auf der einen Seite gibt es Shopsysteme und auf der anderen Seite gibt es Anbieter, die online Zahlungsdienste anbieten. Es wäre für den Shopsystem Hersteller sinnvoll mit dem Zahlungsdienstanbieter zusammen zu arbeiten. Wieso? Somit kann er sich auf sein Kerngeschäft / Kernsystem auf das Shopsystem konzentrieren und muss nicht den Aufwand treiben einen eigenen Zahlungsdienst aufzubauen. Nur bei wenigen Fällen macht diese Eigenentwicklung Sinn.

Ein Webservice ermöglicht die Kommunikation von Maschinen basierend auf HTTP-Protokoll über das Internet. Daten werden ausgetauscht und Funktionen können aufgerufen, von und aus verschiedenen Anwendungen heraus.

Somit wird mittels eines Webservice eine Kommunikation von mehreren Anwendungen, die auf verschiedenen Sprachen implementiert sind.

Ein Webservice besitzt:

  • Uniform Resource Identifier (URI)
  • Schnittstellenbeschreibung (als XML Artefakt z.B. WSDL)

 

Client Programme senden ein request an ein Webserivce. Der Webservice antwortet auf die Anfrage mit den gewünschten Informationen und Daten. Ein Webservice orientiert sich an der SOA Architektur.

Die drei wichtigsten Teile der Zusammenarbeit zwischen Client und Server sind:

  • Zusammenfinden
  • Binden
  • Datenaustausch

Ein Webservice ist stets über einen URI (uniform resource identifier) erreichbar.

Zwischen dem Client und dem Server werden Daten als XML Daten ausgetauscht. Anwendungen reden miteinander auf XML.

In diesem Artikel betrachten wir ein Webservice nach SOAP und REST:

Webservice Komponenten

SOAP (Simple Object Access Protocol)

Es liegen jede Menge Anwendungen geschrieben auf Java, .Net, PHP etc. vor. Miteinander zu kommunizieren kann XML verwendet werden, da alle gängigen Programmiersprachen diese XML Sprache verstehen.  Einen Standard hierfür gibt es leider nicht. SOAP wurde entwickelt mit XML über http Requests zu funktionieren.

SOAP ist ein Nachrichten-Protokoll, womit XML Daten ausgetauscht werden. Alle Nachrichten werden via das http Standard Web Protokoll versendet

SOAP (Simple Object Access Protocol) Nachricht:

  • <Envelope> Dieses Element wird verwendet um die Details von SOAP Nachricht einzubetten. Der Anfang und das Ende einer SOAP Nachricht wird mit diesem Element definiert. Jedes Envelope muss ein Body und maximal einen header enthalten.
  • Die Elemente <header> und <body> müssen ebenfalls vorliegen. Das <header> Element enthält die header Informationen wie Authentifizierung Schlüsseln, Parametern oder auch komplexe Objekte.

Beispiel für ein komplexes Objekt:

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“Tutorial Name“ type=“string“/>

<xsd:element name=“Tutorial Description“  type=“string“/>

</xsd:sequence>

</xsd:complexType>

  • <body> enthält die eigentliche Nachricht. Aufruf und Antwort -Informationen sind in einem body Element enthalten. Hierbei stehen die eigentlichen Daten. Anbei ein Beispiel:
  • <soap:Body>
  • <GetTutorialInfo>
  • <TutorialName>Webservices</TutorialName>
  • <TutorialDescription>All about Webservices</TutorialDescription>
  • </GetTutorialInfo>
  • </soap:Body>

 

Elemente einer SOAP Nachricht:

Diese Nachrichten werden automatisch vom Service generiert, wenn der Webservice gerufen wird.

Die Client- Anwendung ruft eine Methode im Webservice auf und der Webservice generiert die SOAP Nachricht mit den relevanten Informationen.

Warum SOAP?

  • SOAP ist das Protokoll Daten zwischen Anwendungen auszutauschen.
  • Das SOAP Protokoll wurde auch von W3C empfohlen
  • SOAP ist Sprach- und Betriebssystem unabhängig
  • SOAP funktioniert auf das http Protokoll

 

Fehler Nachrichten

Wenn eine Anfrage an den SOAP Webservice vorliegt, kann entweder eine erfolgreiche Antwort verschickt werden oder auch eine Fehlernachricht (http 500 – Fehler). Die Fehlernachricht enthält folgende Elemente:

SOAP – ENV VersionMismatch à ungültiges Zeichen beim SOAP Envelope Element

SOAP- ENV: MustUnderstand à Fehler beim Kind Element vom Header Element

SOAP-ENV: Client à  Die Nachricht was nicht korrekt formatiert oder enthält falsche Information

SOAP – ENV: Server à Ein Fehler mit dem Server liegt vor

<faultString>

<faultActor>

<detail>

 

SOAP Kommunikationsmodell:

Marshalling (Client):  Der Client formattiert den Auftrag in eine SOAP Nachricht und sendet diesen an den Server als ein HTTP Request. Das „encapsulating“ (einkapseln) der Daten in eine SOAP Nachricht nennt man marshalling.

Demarshalling (Server): Das Auspacken einer Anfrage vom Client versteht man als demarshalling.

WSDL (Webservices description language)

Ein Webservice muss lokalisiert werden, bevor man diesen nutzt. WSDL ist bekannt als die Sprache für die Beschreibung eines Webservice. Diese ist eine XML basierte Datei, welchen dem Client sagt, was eigentlich ein Webservice macht. Der client erfährt wo der Webservice vorhanden ist und wie dieser zu nutzen ist. Folgende Tags sind wesentlich bei einer WSDL Deklaration:

  1. <message>   definiert Datenelemente für header Operation durch den Webservice
  2. <portType> beschreibt die eigentliche Operation, welche vom Webservice durchgeführt wird
  3. <binding> enthält das verwendete Protokoll

Ein Webservice hat eine Beschreibungssprache, WSDL genannt. Eine WSDL Datei wird verwendetet um zu verstehen was der Webservice eigentlich macht. Diese Datei enthält den Ort und die Methoden vom Service. Eine WSDL Datei ist wie folgt strukturiert:

  • Definition
  • TargetNamespace
  • DataTypes
  • Messages
  • Porttype
  • Bindings
  • service

Die Nachricht, welche von SOAP Protokoll ist, wird im WSDL Dokument definiert. WSDL Datei ist wie eine Postkarte, welche die Adresse vom Webservice besitzt und welche alle notwendigen Funktionen enthält.

<!– WSDL definition structure –>

<definitions

name=“Guru99Service“

targetNamespace=http://example.org/math/

xmlns=http://schemas.xmlsoap.org/wsdl/>

<!– abstract definitions –>

<types> …

<message> …

<portType> …

 

<!– concrete definitions –>

<binding> …

<service> …

</definition>

 

Struktur einer WSDL Datei

 

Definition:

  • type — message
  • porttype – operation, input, output

 

  • Binding:
  • Service: port
  • <types> wird verwendet Datentypen zu definieren
  • <messages> definiert die Nachricht, welche zwischen der Client-Anwendung und dem Webserver ausgetauscht wird
  • <portType> wird verwendet, um input und output Nachrichten in einzubetten
  • <binding> wird verwendet um Operation zu einem Port-Typ zu verbinden. Port Typen sind wie Schnittstellen.
  • <service> ist der gegebene Name an den Webservice. Eine Webanwendung ruft nach einem Webserivce mit Hilfe des Namens.

Mit WSDL kann eine Java Klasse den Output eines .Net Webservices konsumieren.

  • WSDL – Message

Beschreibt die Daten, die zwischen der Anwendung und dem Webservice, ausgetauscht werden. Jeder Webservice enthält 2 Typen von messages einen für den Input (welche Inputparameter akzeptiert werden) und einen für den Output vom Service.

Das Element <part> wird verwendet um die Input und Output Parameter zu beschreiben.

 

Port type beschreibt die komplette Operation, welche vom Webservice angeboten wird.  Die Input und Output Nachricht aggregieren zu einer kompletten Operation. <binding> Element definiert wie die Nachrichten ausgetauscht werden. Mit den Informationen in binding verbindet sich die Anwendung mit dem Webservice. Erst dann können die Funktionen vom Webservice verwendet werden. Der „transport layer“ wird hierbei ebenfalls gesetzt.

 

UDDI: ist ein Standard einen Webservice zu beschreiben, veröffentlichen und zu entdecken. UDDI schafft ein Repository, wo WSDL Dateien gehosted werden. Die Client-Anwendung hat Zugriff auf UDDI, welche wie eine Datenbank für die WSDL Dateien fungiert. Bildlich kann man UDDI wie ein Telefonbuch vorstellen, der die relevanten Informationen zu einer Person enthält.

Vorteile eines Webservice:

  • Funktionen erhalten eine hohe Reichweite
  • Kommunikation zwischen Anwendungen vereinfacht
  • Standardisiertes bekanntes Protokoll
  • Internet ist ausreichend um eine Webservice zu implementieren

 

Webservice Architektur

  • Provider – erstellt den Webservice
  • Requestor – Client Anwendung, der die Funktion benötigt via eines Webservices
  • Broker – schafft den Zugang zum UDDI

 

Eigenschaften eines Webservice:

  • Basieren auf XML
  • Funktionieren synchron und asynchron
  • Unterstützen Remote Procedure Calls (RPCs)
  • Unterstützt Dokumentenaustausch

 

Prinzipien einer SOA

  • SOA vereinfacht DIE Zusammenarbeitet von Software Komponenten
  • Standardisierte Serviceverträge
  • Funktionsänderungen beeinträchtigt die Zusammenarbeit mit dem Webservice nicht
  • Abstrakter Service
  • Service wiederverwendbar
  • Service sollten Standards nutzen um den Service nutzbar zu machen
  • Services sollten mehrere Module je Problem haben

 

 

 

 

 

 

 

 

 

 

 

RESTful Webservices

Wartbare und skalierbare Webservice sollten mit REST gebaut werden. Das Protokoll für REST lautet http web Protokoll. REST ist ein Weg um Ressourcen, die auf einer Umgebung vorliegen, zuzugreifen.

Schlüsselelemente einer RESTful Implementierung

  • Ressources
  • Requests Verbs — GET (erhalten einer Liste), POST (Erstellen einer Einheit in einer Liste), PUT (Aktualisierung einer Einheit), DELETE (Löschen einer Einheit)
  • Request Headers – zusätzliche Anweisungen mit dem Request
  • Request Body – Daten welche zusammen mit dem Request gesendet werden
  • Response Body – Hauptteil einer Antwort
  • Response Status codes – 200 OK

 

Ähnlich wie SOAP lässt auch REST die Kommunikation zwischen Anwendungen verschiedener Sprachen zu. Besonders Cloud basierte Architektur arbeiten gut mit dem REST Prinzip.

 

Restful Architektur

  1. Zustand und Funktionen sind unterteilt in verteilte Ressourcen; Ressourcen sollten über http Befehle zugänglich sein.
  2. Die Architektur ist ein Client und Server basiertes; Der Client fragt nach Informationen und der Server liefert die Antwort. Sequentiell geht es so weiter und der Server merkt sich die vergangenen Fragen und Antworten nicht.
  3. Client à Cache à Server lautet die Architektur um wiederholende Fragen über Cache sich antworten zu lassen

 

SOAP vs REST

SOAP REST
SOAP ist ein Protokoll. Sie schließt eine WSDL Datei ein, welche die notwendigen Information zum Webservice besitzt REST kann nur angewendeten werden wenn Client-Server Architektur vorliegt.
SOAP kann REST nicht nutzen REST kann SOAP anwenden
SOAP verwendet Schnittstellen um Funktionen zu Webanwendungen zu zeigen REST verwendet Uniform Service locator um Bestandteile von Hardware.

https://checkideas.com/Mitarbeiter

SOAP enthalten viel Informationen zu den messages. REST benötigt nicht viel Bandbreite, da die requests werden als JSON Objekte versendet
SOAP sorgt auch für WS Security um Sicherheit bei einem Webservice zu schaffen

WS Security kann mit Name und Passwort aufgerufen werden oder mit einem binären Zertifikat für die Authentifizierung

 

 Bei REST kann Sicherheit mit https Verbindung aufgebaut werden

 

 

  • API – Application Programming Interface wird vom Client und Server angeboten.
  • REST API – Mangel an Sicherheit; Mangel an Zustand (Warenkorb merken kann nicht)

 

Andere Remote Access Techniques -> RPC (remote procedure call)

  1. DCOM – Distributed Component Object Model à Microsoft Technologie um auf Client remote Komponenten zuzugreifen.  Client Anwendung muss Ressourcen befreien, falls nicht mehr notwendig! Bei Java müssen weitere Java Codes geschrieben werden.
  2. Java RMI Java Remote Method Innovation kann nur auf Java Virtual Maschine laufen
  3. Cobra (Common Object Request Broker Architecture) Eine weitere Sprache muss erlernt werden, um die Kommunikation zwischen den Anwendungen

Alle oben genannten Technologien basieren nicht auf HTTP Protokoll. Teilweise müssen sogar auf verschiedenen Ports müssen zugegriffen werden

16Jun/17

Business Analyse richtig gemacht!

Analysiert ein Business Analyst ein Geschäftsbereich eines Unternehmens? Was macht er denn genau? Der Business Analyst analysiert fachlich die Anpassungsnotwendigkeiten von IT Systemen, formuliert konkrete Anforderungen unter Einbeziehung der beteiligten Geschäftsprozesse, erstellt Lastenhefte unter Berücksichtigung der geschäftlichen Anforderungen (Abwicklungsprozesse), prüft Pflichtenhefte (Fachkonzepte) auf die korrekte Erfüllung der fachlichen Anforderungen, begleitet fachliche und IT – Testaktivitäten und macht auch Abnahmeerklärungen für Produktionsfreigabe der „Relase“ (Freigabe) von Software Entwicklungsiterationen. Ein Business Analyst analysiert frühzeitig die Anforderungen und strukturiert diese, damit ein Überblick vorliegt, bevor das Umsetzungsvorhaben im Detail festgelegt wird. Ob die Anforderungen gemäß Wasserfallmodell oder agil (Stichwort: SCRUM) dokumentiert werden wird nicht im Rahmen dieses Artikels berücksichtigt.

Im Zusammenhang von Business Analyse werden oftmals die Begriffe „Lastenheft“ und „Pflichtenheft“ verwendet. Doch wofür stehen diese Begriffe?

Lastenheft: Wie sieht die Sicht des Auftraggebers aus?

In einem Lastenheft wird die Sicht des Auftraggebers festgehalten. Im Rahmen eines Lastenhefts, macht sich der Auftraggeber umfänglich Gedanken über die genauen Anforderungen an eine Software zum Beispiel. Darüber hinaus wird das Lastenheft genutzt um von Dienstleistern Angebote einzuholen. Diese können gegenübergestellt werden, bevor man sich für einen Dienstleister entscheidet. Oftmals werden selektierte Dienstleister auch vor Ort eingeladen, damit sie Ihre Lösung zu den Anforderungen vorstellen können. Anschließend entscheidet sich der Auftraggeber nach interner Abstimmung für einen Dienstleister.

  • Wie sieht der Ist – und Soll – Zustand aus? Wie lauten die aktuell vorliegenden Voraussetzungen? Welche Funktionen soll das Produkt haben?
  • Ein kleiner Projektplan wird mit den Projektmitgliedern und den Verantwortlichen entworfen?
  • Funktionale und nicht funktionale Anforderungen werden ebenfalls im Rahmen des Dokuments festgehalten.

Pflichtenheft: Wie sieht die Sicht des Auftragnehmers aus?

Das Pflichtenheft wird mit Hilfe des Lastenhefts erstellt. Es beschreibt Vorgehensweisen und Lösungsansätze des Auftragnehmers. Dieses wird oft mit einem Angebot angereichert, welches die vertragliche Grundlage zu den erbringenden Leistungen dokumentiert. In dem Dokument werden klare und eindeutige Aussagen getroffen, welche positiven und negativen Abgrenzungen des angebotenen Produkts mitdokumentiert. Nur eindeutige Aussagen in dem Dokument können einen Streit zwischen Auftraggeber und Dienstleister bei der finalen Abnahme des Produktes, sofern der Auftragnehmer den Auftrag auch abschließt, vermeiden. Ansonsten kann es bekanntermaßen zu zahlreichen Streitigkeiten und unschönen gerichtlichen Prozessen führen.

Aus dem Grund ist es ratsam viel Zeit in ein Lastenheft und der Prüfung eines Pflichtenheftes zu investieren, damit das Projekt erfolgreich und mit weniger Nacharbeit bzw. wenigen „change requests“ durchgeführt werden kann.

 

Fazit: Business Analyse ist eine wichtige Aufgabe in IT Projekten. Ein gutes Endprodukt kann nur vorliegen, wenn die Anforderungen konkret, vorausschauend und nachhaltig definiert wurden. Ein Lastenheft ist eine Art und Weise diese Anforderungen schriftlich festzuhalten. Die Dienstleister nutzen ein Pflichtenheft um diese Anforderungen in Zielen und nicht Zielen zu transformieren. Ein erfolgreiches Projekt sollte zusehen, dass erfahrene Business Analysten in Ihrem Projekt mitarbeiten, die idealerweise sowohl Produkt als auch Fachkenntnisse für das jeweilige Projekt haben.

05Jun/17

Agiles Projektmanagement – Die Tools

Agiles Projektmanagement – Die Tools

Agiles Projektmanagement: Dieser Begriff schließt unterschiedliche Methoden ein, die Ihren Wert auf Flexibilität und Anpassung legen. Die Flexibilität, das Geplante zu ändern und auf spontan auftauchende Herausforderungen reagieren zu können, macht ein agiles Projekt aus. In so einem agilen Projekt ist die Zusammenarbeit mit dem Kunden, die Fähigkeit auf Veränderungen zu reagieren, die Konzentration auf weniger Dokumentation und eher auf eine funktionierende Software wichtiger.

Kanban Board – Tool für ein Scrum Projekt

In einem Scrum Projekt werden alle Tickets auf einer Tafel übersichtlich festgehalten. Hiermit liegt stets ein Projektüberblick allen Projektbeteiligten vor. Diese Tickets werden aufgeteilt nach dem Status eines Tickets von „in Bearbeitung“ bis „Test erfolgreich abgeschlossen“. Die Aufgabenverteilung und der Arbeitsfluss können eindeutig einfach von der Tafel entnommen werden.

JIRA, Ein Tool

Jira ist ein Projekt- und Fehlertracking System. In Softwareprojekten wird dieses Tool eingesetzt, damit die Steuerung zu einem reibungslosen Endprodukt gelingt. In Jira können Tafeln, Backlogs, Tickets, digital erstellt werden und verschiedenen Projektmitgliedern und Teams zugewiesen werden. Auch der Status eines Tickets kann entsprechend hinzugefügt werden. Auch Testmanagement Tools, wie HPQC, können mit JIRA integriert werden. Auswertungen für den Projektsponsor sind ebenfalls möglich. Auch Dokumente und der Wissensstand der Projektmitglieder kann in Jira aufgenommen werden. Jira unterstützt ein Projekt IT gesteuert, um ein Scrum Projekt zu gestalten.

05Jun/17
IT Projekt digitale Transformation

Scrum Projekt und seine Probleme

Scrum Projekt und seine Probleme

Ein Projekt besteht aus einem Scrum Team, Product Owner und einem Scrum Master. In diesem Artikel betrachten wir die einzelnen Rollen und schauen uns ein Projektablauf näher an.

Ein Scrum Team ist interdisziplinär zusammengesetzt, so dass verschiedene Expertisen vorliegen. Dieses Team soll sich selbst organisieren und ist so nur wenigen einfachen Regeln untergeordnet. Für den Projekterfolg sind sie neben dem Product Owner und dem Scrum Master maßgeblich. Mit allen drei Parteien soll ein Projekt erfolgreich gestaltet werden.

Am Anfang eines Projektes liegt eine Produktvision vor. Diese soll im Rahmen eines Scrum Projekts erarbeitet werden.

 

  1. Die Vision wird in Anforderungen in Story Cards aufgeschrieben. Diese werden in dem Worten der Anwender formuliert.
  2. Diese Anforderungen werden in Arbeitspakete zusammengeschrieben und in ein Product Backlog eingefügt
  3. Dann kommt es zu einer Priorisierung der Anforderungen. Welche Funktionen braucht der Anwender am dringlichsten? Was sind die sogenannten „paint points“?
  4. Basierend auf diesem Backlog, wird ein Sprint geplant. Bei der Planung werden die Aufgaben, Ziele, Teilaufgaben und die einzuhaltenden Konventionen betrachtet.
  5. Ein Sprint kann von 1-4 Wochen dauern. Je kürzer ein Sprint desto besser die zielgerechte fokussierte Umsetzung. Ein Sprint beinhaltet mehrere einzelne Aufgaben oder auch Tickets, die aus dem Arbeitspaket des Backlogs hervorgehen.
  6. Das Scrum Team arbeiten die Tickets ab.
  7. Täglich in einem 15-minutügen Meeting berichtet jedes Projektmitglied seinen Stand und die Probleme, die ihm ggf. bei der Arbeit hindern. Der Scrum Master muss für eine gute Arbeitsfähigkeit der Scrum-Teammitglieder sorgen.
  8. Nach einem Sprint kommt es zu einem Sprint Review. Der Prdouct Owner muss die Ergebnisse abnehmen und akzeptieren. „Lesson Learned“ Punkte werden besprochen, welche in die nächste Sprintplanung mit einfließen.
  9. Projektabschluss bedeutet, dass alle Sprints durchgelaufen sind und dass der Produkt Owner sein Produkt final geliefert bekommt.

Probleme von Scrum:

  • Ein Scrum Projekt sorgt für weniger Overhead Aufwand als herkömmliche Projektmanagementmethoden ein Projekt erfolgreich mit einem Endprodukt abzuschließen. Doch ohne Probleme kann auch dieses Projekt nicht abgeschlossen werden.
  • Es gibt Mitarbeiter, die mit der Scrummethode nicht zurechtkommen. Wieso? Mit dieser Methode liegt eine Transparenz der Leistung jedes einzelnen Mitarbeiters vor. Schwächen von Mitarbeitern werden offenbart in den täglichen Meetings. So kann es zur Kritiken kommen, welchen zu Team-Konflikten führen können.
  • Auch Scrum Master stehen vor Schwierigkeiten, da sie bei so einem Projekt „nur“ den Moderator spielen sollen. Ihre Wichtigkeit im Projekt wird zurückgestuft, da Scrum Teams als Experten mächtiger und selbstorganisiert sind.
  • Innerhalb des Unternehmens muss ein Vertrauensvorschuss von Projektsponsoren vorliegen, da die Projektmitglieder selbst führen und nicht geführt waren.
  • Besonders Vertrauen ist wichtig. Somit ist in der Unternehmenskultur auch Vertrauen essentiell. Darüber hinaus muss es bei einem Scrum Projekt auch ein Produkt oder Dienstleistung geben, bei der das Ziel spezifiziert sein muss.

 

Folgende Schlüsselkriterien müssen bei einem Scrum Projekt vorliegen:

  • Projektteam sollte idealerweise in einem Raum sitzen
  • Die Scrum-Teammitglieder sollten über das gesamte einheitlich und verfügbar sein
  • Anforderungen des Kunden sollten eindeutig und klar kommuniziert sein
05Jun/17

Agiles Projekt – Scrum

Entwerfen digitale Strategie

Agiles Projekt

Banken, Unternehmen und Start Ups sprechen von agilen Projekten und in dem Zusammenhang fällt oftmals der Begriff „Scrum“ von Projektsponsoren und Managern. In diesem Artikel werden wir uns diese beiden Stichworte uns näher anschauen.

Traditionell ist es bekannt, dass Projekte oftmals Ihre initial erfassten Ziele nicht erreichen. Es wird viel geplant und dokumentiert doch am Ende wird es eng mit der Zeit, dem Budget oder dem Scope. Um diese Probleme zu adressieren soll das agile Projektmanagementmethode helfen. Mit Scrum wird ein agiles Projekt ausgeführt.

Scrum:

Die drei wichtigsten Rollen in Scrum heißen:

  • Product Owner: Er gibt die fachlichen Anforderungen vor. Gleichzeitig ist er der Vertreter des Produktanwenders und Projektstakeholders im Projekt.
  • Scrum Master: Er koordiniert das Team und ist für das Prozessmanagement zuständig. Er wird auch als der Moderator bezeichnet, da er die Hindernisse im Umfeld des Scrumteams beseitigt und für ein zielorientiertes Arbeitsumfeld sorgt. Er sorgt dafür, dass die methodischen Vorgaben eingehalten werden.
  • Scrum Team: Das Team ist interdisziplinär aufgebaut und besteht aus einzelnen Experten

 

  1. Anforderungen werden zusammenschrieben und priorisiert. Diese Requirements werden in einem „Product Backlog“ festgehalten. Der Product Owner kann und muss die Anforderungen stets angepasst und kundenorientiert halten
  2. Ein Arbeitspaket, wo die Anforderungen komplett sind, wird im Rahmen einer Iteration, auch Sprint genannt, vom Scrum Team abgearbeitet. Die Anforderungen werden in kleineren Tasks geteilt. Diese werden dem Scrum Teammitgliedern zugeordnet. Anforderungsänderungen bei einem laufenden Sprint sind nicht erlaubt. In einem täglichen Jour fix, auch „morgen Stand up“ genannt, haben die Scrum Teammitglieder die Möglichkeit den aktuellen Entwicklungsstand und die Probleme zu kommunizieren.

 

  1. Nach jedem Sprint wird dem Product Owner und / oder Stakeholdern die Ergebnisse vorgestellt. Im Rahmen dieses Sprint Reviews werden „Lesson Learned“ Themen besprochen. Der Inhalt fließt auch in die Planung des nächsten Sprints mit ein.

Hiermit ermöglicht die Scrummethode schnelle und flexibel kleiner Projektziele mit an fassbaren Ergebnissen zu erzielen.

19Mai/17

IT Projekt – Kauf einer Software

IT Projekt digitale Transformation

Täglich steigt die Zahl der digitalen Lösungen, die IT Unternehmen anbieten. Der Vertrieb des Softwareunternehmens schaffen einen Termin mit den Entscheidungsträgern eines Unternehmens zu machen, so die Experten das IT und Business Team vom Unternehmen überzeugen kann.

Eine erfolgreiche Verkaufsaktion gibt den Startschuss für ein IT Projekt. Dieses Projekt kann agil oder auch klassisch nach der Wasserfallmethode gestaltet werden. Ein Scrum Projekt schauen wir uns ein anderes Mal an. In diesem Artikel wird der klassische Weg näher betrachtet. Hierbei kommt es zu den folgenden Phasen (siehe Grafik).

  • Anforderungen
  • Implementierung
  • Test
  • Linienübergabe
  • Stabilisierungsphase
IT Projekt digitale Transformation

Die Anforderungen für die IT Lösungen wurden bereits vor der Kaufentscheidung der Software getroffen. Doch nun kommt es zur detaillierten Planung. Business Analysten agieren zwischen dem Fach Team und den Softwareanbietern um eine reibungslose technische Abbildung der Anforderungen durchzuführen. Zusätzlich zu den Anforderungskonzepten werden vom Business Analysten Datenverarbeitungs-Konzepte geschrieben.

Anhand dieser Spezifikation wird die Software implementiert oder „customized“. Die technischen Mitarbeiter, entweder die internen Mitarbeiter oder externe Dienstleister, werden die Implementierung anhand der DV Konzepte durchführen.

Die Ergebnisse werden anschließend vom Test Team geprüft. In der Testphase kann es zu einem Lasttest, Komponententest, Integrationstest, Systemtest und Abnahmetest kommen. Auch Business Analysten testen manchmal mit, da sie die Anforderungen genau kennen und das Outcome exakt prüfen können. In dieser Phase kann es zu einer Schleife zurückkommen, dass 1. Anforderungen angepasst werden im Rahmen von “Change Requests“ (CR);  2. Bugs werden erkannt und diese werden dann von den Software Entwicklern behoben.

Nach einer erfolgreichen Testphase wird das Release in die Linie vorberietet. Auch diese Linienübergabe kann portionsweise stattfinden abhängig von der Größe der Endnutzer. Vor der Einführung in die Linie müssen die Endnutzer auch geschult werden. Nach Projektschluss wird es auch eine Stabilisierungsphase geben, je nachdem wie stabil das System ist. Mit dem Projektabschluss gibt es auch ein Abschlusstermin mit den Projektsponsoren, wobei es final mit dem initialen Business Case auch reflektiert wird. Ein erfolgreiches Projekt endet auch mit einer Projektabschlussfeier mit alle Projektbeteiligten.

18Mai/17

Checkideas – Ehrliches und anonymes Feedback

Die digitale Transformation ist auch nun auch bei Gründern mit Hilfe von checkideas angekommen. Diese Plattform bietet Menschen mit Ideen, StartUPs und Gründern die Möglichkeit frühzeitig Feedback abzuholen. Auf der Seite kann schnell eine Idee oder ein Produkt eingetragen werden. Dieser Eintrag kann über Whatsapp, Facebook oder andere sozialen Kanälen geteilt werden.

Ein Feedback erhält er im Rahmen von Emojis oder Kommentare. Hiermit ermöglicht checkideas frühzeitig Feedback zu erhalten und die Idee oder das Produkt so anzupassen, wie der Kunde von morgen dies haben möchte. Ein großer Vorteil, den checkideas bietet, ist das anonyme Feedback. Feedback-Geber können ohne Gedanken über Ihre direkte und offene Kritik zu machen, ehrlich kommunizieren. So erhält der Ideeninhaber ein offenes und ehrliches Feedback.

01Mai/17

Effizientes Projekt in der digitalen Transformation

In der aktuellen Zeit sind Unternehmen damit beschäftigt, digitale Techniken wie soziale, mobile, analytische und auch Cloud basierte Anwendungen in Ihr Geschäft zu integrieren.
Der Mittelstand ist zunehmend mit der Einführung von digitalen Lösungen für diverse Geschäftsprobleme beschäftigt.

Geschäftsführer suchen nach Strategien, wie Sie Ihre Geschäftsmodelle nachhaltig aufbauen kennen. Aktuell führt der Weg an einer digitalen Strategie nicht vorbei. Hierbei machen sich die Geschäftsführer auch Gedanken über die Bereitschaft der Mitarbeiter. Die Wichtigkeit der nachhaltigen Strategie muss an die Mitarbeiter kommuniziert werden und auch von denen verstanden, damit alle an einem Strang ziehen.

25Feb/17

Digitale Transformation – Wieso muss ein Unternehmen in die digitale Welt seine Schritte machen?

Digitale Transformation – Ist die digitale Transformation eine Chance oder
eine Gefahr für die Mitarbeiter?

Die digitale Transformation soll die Arbeit der Mitarbeiter eines Unternehmens erleichtern. Gleichzeitig wird die Frage hervorgerufen, ob diese auch zur Streichung von Stellen führen kann.

Hierbei ist die Frage mit einem „Ja“ zu beantworten. Doch müssen Unternehmen die Perspektive der Mitarbeiter und andersherum muss ebenfalls die Perspektive verstanden werden.

  1. Ein Unternehmen arbeitet Tag für Tag daran erfolgreicher zu werden; dies wird oft mit Schlagwörtern wie „Marktanteil gewinnen“, „Umsatz steigern“, oder auch „Kosten reduzieren“ assoziiert. Darüber hinaus liegt der Wettbewerbsdruck ebenfalls vor. Damit ein Unternehmen langfristig erfolgreich sich in der Wirtschaft platzieren kann, ist stets dessen Optimierung notwendig. Hierzu ist die digitale Transformation ein viel versprechendes Instrument.
  2. Die Mitarbeiter können diesen Wandel sowohl als eine Chance als auch eine Bedrohung sehen. Eine Chance wäre für die aktiven Mitarbeiter da, diese aktiv an diesen Wandel zu beteiligen und sich lernend diesem Thema zu nähern. Sie entwickeln sich weiter und bringen somit auch das Unternehmen weiter.
  3. Doch die Mitarbeiter die nicht wandlungsfähig sind, hängen bei einer radikalen Transformation an dünnem Ast. Wenn Sie sich weigern droht Ihnen eine Kündigung. Oftmals sind Mitarbeiter mit langer Betriebszugehörigkeit schwer zu kündigen. Auch die negativen finanziellen Auswirkungen im Rahmen von Abfindung oder auch Themen mit dem Betriebsrat können den Unternehmen solch eine Transformation erschweren.

Fazit: Eine digitale Transformation funktioniert bei einem Unternehmen, wenn die Mitarbeiter des Unternehmens bereit sind, sich an dieser Transformation zu beteiligen und mitzuwirken. Eine defensive Haltung könnte das Unternehmensziel stark gefährden.

25Feb/17

Einsatz von neuen Technologien im Rahmen einer digitalen Wandlung / Transformation

Für ein Unternehmen heißt der Einsatz von neuen Technologien eine Übersicht der möglichen Anwendungen zu erhalten. Diese müssen bewertet und die Integrierbarkeit in das eigene Unternehmen steht an vorderster Stelle.

Kunden sind heutzutage technikaffin, so erwarten diese auch von verschiedenen Anbietern ständig innovative Lösungen. Beispiele sind oftmals, Google, Snapchat, Zynga oder auch Pinterest, die die Interessen der Menschen schnell verstehen und diese auch in eine nützliche Anwendung unter das Volk bringen. Das Ziel der Technologien führt vom Kerngeschäftsmodell bis hin zum finalen Kundenerlebnis (englisch:„Customer Experience“).

Den Kunden muss man verstehen und auch deuten was er morgen möchte. Von diesem Punkt muss betrachtet werden, was denn alles möglich ist, im Rahmen des operationellen Prozesses für das Unternehmen zu realisieren. Final müssen diese Prozesse auch mit dem Business Model oder Geschäftsmodell des Unternehmens zusammenpassen, damit das Ziel dem Kunden Mehrwert zu bringen auch erfüllt wird. Sicherlich ist hierbei für die Umsetzung nicht nur die Strategie wichtig. Es ist vor allem die Integration des Fachbereichs mit der IT essentiell, die Projekte in die Erfolgsschiene zu bringen. Es braucht Innovative Mitarbeiter, die sich mit „Change Management“ auskennen und offen dafür sind sich neue Technologien anzueignen bzw. zu lernen und diese für das Wohl des Unternehmens anzuwenden.