eBizTalk - Berichten, Unterhalten, Weiterbilden
Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

SQL Server 2016 - Improvements: InMemory

Veröffentlicht am 01.05.2017 von Ireen Raue , SQL Server , Custom Development , Data

Seit Juni 2016 steht der SQL Server 2016 zur Verfügung und bringt eine Unmenge an Weiterentwicklungen und Verbesserungen mit sich.

Einen ersten groben Überblick dazu habe ich bei den ‚SQL TechnologieDay SQL Server 2016‘ der ppedv in Leipzig bekommen. Dort wurde sehr kompakt auf die Neuerungen eingegangen. Manche dieser Neuerungen sind sehr interessant und spannend, weshalb ich mich damit etwas intensiver beschäftigt habe.

Sehr viele Verbesserungen gab es vor allem im InMemory-Bereich. Da ich mich aktuell für den SQL Server 2014 mit diesem Thema beschäftige, war das eine der für mich sehr interessanten Neuerungen.

InMemory-Erweiterung

Die erste inMemory-Technologie wurde mit dem SQL Server 2012 mit dem ColumnStore Index eingefügt und von Version zu Version stetig erweitert.

image

Auch die Analyse bestehender Projekte auf Migrationsmöglichkeiten hat sich deutlich vereinfacht. Wo beim SQL Server 2014 noch über ein Data Warehouse und DataCollector eine Datenbasis zum Auswerten aufgebaut werden muss, kann der ARM-Report beim SQL Server2016 direkt auf den Produktivdaten ausgeführt werden. So ist ohne größeren Aufwand eine Analyse möglich.

image

Durch die Aufhebung vieler Einschränkungen bei der Migration zu InMemory-Tabellen oder nativly compiled Procedures wird es mit dem SQL 2016 auch deutlich einfach für bestehende Projekte diese Technologie einzusetzen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

DevOps - eine schöne neue Welt?

Veröffentlicht am 17.04.2017 von Florian Hieber , DevOps , ALM

Die DevOps Welt ist recht neu und mit agilen Ansätzen versehen. Theoretisch klingt das sehr gut, aber wie sieht es in der Praxis aus? Wie gut ist das Produkt, dass dabei herauskommt? Wo liegen die Schwierigkeiten? Ich versuche mich einmal an einer Betrachtung.

Microsoft propagiert seit Neustem die Prinzipien von DevOps – also dem Schulterschluss zwischen Softwareentwicklern (Developer) und IT-Betrieb (Operations). Noch vor einem Jahr gab es auf der Technical Summit 2015 Empfehlungen, die auf der diesjährigen Tech Summit wieder verworfen wurden. DevOps ist dieses Jahr das Trendthema schlechthin. Es gab sehr viele Vorträge, eine Keynote und eine Diskussionsrunde zu dem Thema. SCRUM, Canban oder gar klassische Vorgehensmodelle wurden noch nicht einmal angesprochen. Als zertifizierter Projektleiter und SCRUM Master bin ich naturgemäß an neuen Vorgehensmodellen interessiert. Dementsprechend verfolge ich den DevOps-Ansatz schon über ein Jahr mit Interesse.

Deshalb habe ich mich unter anderem auch dazu entschlossen, an der Tech Summit in Darmstadt teilzunehmen und dort einige Veranstaltungen zu diesem Thema zu besuchen. Gerade die Diskussionsrunde war sehr spannend, da auch einige Teilnehmer dabei waren, für die DevOps nicht nur graue Theorie war, sondern gelebtes Verhalten. Zwei Teilnehmer waren sogar aus der mittleren Führungsebene, die DevOps in ihr Unternehmen gebracht haben und die ihre Erfahrungen ebenfalls bereitwillig geteilt haben. Ein weiterer Teilnehmer war Administrator und konnte seine Erfahrungen mit DevOps ebenfalls vorbringen. Um es vorweg zu nehmen, es gab niemanden, der DevOps lebte und unzufrieden war. Aber was ist DevOps überhaupt?

DevOps ist eine Methodik, die Softwareentwicklung unter agilen Gesichtspunkten ansieht.

  • Entwickelt werden Produkte, es geht nicht um Projekte
  • Produkte werden durch Funktionen beschrieben
  • Projekte dagegen werden durch Kosten, Zeit und Annahmen der Funktionen beschrieben
  • Projekte dagegen beziehen den Auftraggeber nur sehr eingeschränkt ein
  • Zum Team gehören Betreiber und Entwickler des Produktes
  • Release-Zyklen sind sehr kurz (bis zu mehrmals täglich)

Die Idee, Betrieb und Entwicklung als zusammengehörige Einheiten zu betrachten, ist sicherlich gut, erfordert aber ein Umdenken im gesamten Unternehmen und nicht zuletzt bei den Beteiligten. Ein Prozess, der bislang auch in den Aussagen der Beteiligten noch nicht abgeschlossen ist. Der Gedanke, Produkte zu entwickeln und nicht Projekte zu definieren ist nicht neu, sondern wird bei allen agilen Methoden genutzt. Die Nachteile (keine Kostenschätzung möglich, keine Kontrolle des Funktionsumfangs möglich, etc.) sind immer noch in den Köpfen der meisten Mitarbeiter und der Führungsebene fest verankert. Dieses Denken steht der DevOps Methode auch entgegen. Neue Ansätze, wie eine engere Zusammenarbeit zwischen Betrieb und Entwicklung finden sicher schnell Gefallen im Unternehmen, mehrmals am Tag ein produktives System neu zu releasen aber ganz sicher nicht. Unternehmen, die DevOps einsetzen, stellen mehrmals am Tag ein Release ein. Damit der Prozess aber von anderen Abteilungen akzeptiert wird, nennen sie den Vorgang dann „Update“.

Ein „Release“ hatte bislang immer eine Besonderheit inne. Nicht nur aus der Gefahr, Fehler in den produktiven Betrieb zu bringen, sondern auch aus Marketing Gesichtspunkten. Ein Release war eine Neuerung, die vielleicht sogar preisliche, sicher aber funktionale Änderungen beinhaltete, die es wert waren, angekündigt zu werden. Auch das fällt mit DevOps weg.

Besonders die sehr kurzen Zyklen zur Bereitstellung neuer Funktionen am Produkt werfen aber die Frage auf, wie man in so kurzer Zeit verlässlich Testen kann. Um es vorweg zu nehmen, keine der beteiligten Parteien und auch die anderen Beiträge brachten mir da eine wirklich befriedigende Antwort.

In der Diskussion kamen viele Stimmen auf, die meinten, Tests (von Unit bis Systemtests) würden nichts bringen und nur Zeit und Geld kosten, deshalb hätten sie das Testen auf Akzeptanztests reduziert. Diesen Ansatz halte ich für problematisch, auch wenn es bislang laut der Anwesenden zu keinen großen Problemen gekommen sei. Die Gefahr, dass es zu solchen Problemen kommen kann, ist doch sehr hoch. Ganz zu schweigen davon, dass weder Qualitätskontrollen noch Zertifizierungen möglich sind. Quality Gates sind in den Köpfen vieler Menschen keine Kostenfresser, sondern unerlässlich, wenn man ISO-zertifizierte Qualität liefern will.

Auch sollen nach der Meinung von Microsoft keine Branches zu Testzwecken im Code Repository genutzt werden. Nach der Entwicklung (und Test) auf dem lokalen Entwicklerrechner geht es in die Produktion. Richtig ist das Argument der DevOps-Verfechter, dass normalerweise keine großen Änderungen in den Zyklen gemacht werden und deshalb ein auftretender Fehler auch schnell rückgängig gemacht werden kann. Was ist jedoch mit schleichenden Fehlern, die erst sehr spät auffallen, da sie sich auf Bereiche im Produkt auswirken, die man nicht im Fokus hatte? Ein Fehler, der erst nach Wochen, also nach mehreren Zyklen, auffällt ist durchaus möglich und nicht nur Theorie. Ob man dann auch noch so schnell reagieren kann?

Bislang konnte ich keine Person ausfindig machen, die wirklich negative Erfahrungen mit DevOps gemacht und die Methodik dann wieder verworfen hat. Insofern scheinen meine Zweifel nicht berechtigt, dennoch werde ich sie nicht los. Meine Berufserfahrung scheint meiner Gutgläubigkeit etwas entgegenzustehen.

Trotz meiner Zweifel bezüglich Test und Dokumentation finde ich die Methodik sehr interessant und würde gerne einmal eine Produktentwicklung mit DevOps unterstützen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

Ein kleiner Einstieg in die Windows 10 IoT Welt

Veröffentlicht am 31.03.2017 von Ronny Ulbricht , IoT , Azure

Das Internet der Dinge (englisch: Internet of Things) wird gern als die nächste industrielle Revolution bezeichnet. Das Thema der „intelligenten Gegenstände“ hat in den letzten Jahren immens an Fahrt aufgenommen und ist mittlerweile sowohl im Enterprise als auch im Consumer Umfeld angekommen. Mit Windows 10 als Plattform, den Universal Windows Platform Apps und dem Azure IoT Hub mischt auch Microsoft kräftig mit.

clip_image002

Für die eBiz Consulting GmbH als Beratungsunternehmen und Integrationspartner für Software-Systeme, aber auch für mich persönlich als interessierter Entwickler ist das Thema „Internet of Things“ (IoT) schon länger auf dem Radar relevanter Trendthemen.

Meine Erfahrungen beschränkten sich dabei jedoch eher auf theoretisches Wissen aus verschiedenen Blog-Artikeln und anderen Publikationen sowie Samples, die ich bei Kollegen und befreundeten Entwicklern bestaunen durfte.

Im Rahmen der Microsoft Veranstaltung „Technical Summit 2016“ bot sich die Möglichkeit, an einem Tages-Workshop teilzunehmen und so in den praktischen Teil der IoT-Welt einzusteigen. Ich bekam einen ersten Überblick mit welchen Dingen man sich beschäftigen sollte und mit welchen nicht, wenn man sich in der Microsoft Welt des Internet der Dinge bewegt. Im Folgenden möchte ich diese Erfahrungen nun gern teilen.

Die richtige Idee

„Einfach mal so probieren“ mag im Bereich der Software Entwicklung ein probater Ansatz sein, um in neue Themen einzusteigen und sich auszuprobieren, am Ende liefert aber ein konkreter Anwendungsfall das höchste Motivationspotenzial. Eine halbwegs sinnvolle Idee sollte daher am Anfang aller Bemühungen stehen. Das ist schon deshalb notwendig, weil die benötigte Hardware mit einem finanziellen Investment verbunden ist, das sich je nach Ausstattung der Hardware (Anschlüsse, Sensoren) unterscheiden kann. Hier zum Beispiel eine Liste verschiedener Windows 10 IoT-fähiger Devices:

clip_image004

Eine naheliegende Idee ist beispielsweise das Auslesen und Weiterverarbeiten von Sensordaten einer Kaffeemaschine, einer Wetterstation oder das Ansteuern eines LED Displays zur Darstellung von Zustandsinformationen.

Wie den richtigen Einstieg finden?

Weiß man was man machen möchte, dann ist es zielführend sich Hilfestellung zu organisieren um geleitet in das Thema einzusteigen. Microsoft bietet für den Einstieg in die Windows 10 IoT-Welt einen „Get started“-Bereich im Windows Dev Center.

https://developer.microsoft.com/de-de/windows/iot/getstarted

Hier wird man mit Hilfe eines Wizards beim Aufsetzen des Devices unterstützt.

Wichtig ist, dass man sich im Vorfeld alle für Setup, Entwicklung und Deployment notwendigen Tools besorgt. Die meisten der Tools werden im Wizard erwähnt und verlinkt, hier jedoch noch mal eine Liste der Tools, die man auf jeden Fall haben sollte:

· Windows Assessment and Deployment Kit - Tools, zum Anpassen von Windows-Images

· https://github.com/ms-iot/iot-adk-addonkit/ - command line Skripte zur Paketierung und zur Image Erstellung

· Windows Driver Kit – enthält toolset zum Entwickeln, Bauen, Paketieren, Ausliefern, Testen, und Debugging von Geräte Treibern für die Windows Plattform

Der Wizard geht von der Verwendung der Standard-Images für die Windows 10 IoT-Editionen aus. Es besteht darüber hinaus noch die Möglichkeit eigene Images zu erstellen, um bestimmte Device-Voreinstellungen und andere Constraints setzen zu können, wie beispielsweise das Abschalten von Gerätefeatures. Dies ist bei einfachen Samples und wenigen Geräten nach Verwendung eines Standard-Images aber auch direkt über das Device selbst möglich und in dem Fall das empfohlene Vorgehen.

Nicht zuletzt, weil der Prozess der Erstellung von eigenen Images noch nicht wirklich ausgereift und daher fehleranfällig ist.

Anmerkung: Eine Übersicht über die Windows 10 IoT-Editionen und weitere Zusatzinformationen zu Windows 10 für das Internet der Dinge findet man unter:

https://www.microsoft.com/de-de/WindowsForBusiness/windows-iot

Universal Windows Platform Apps

Hat man das Setup seines Devices abgeschlossen und eine laufende Version von Windows 10 IoT deployed, so kann man sich an die eigentliche Aufgabe machen und seine App Entwickeln.

Grundsätzlich gibt es im Umfeld von Windows IoT nicht sonderlich viel zu beachten. Aufgrund des Konzeptes von Windows Universal Platform und der Universal Windows Platform Apps ist es einzig notwendig, dass die App für die richtige Prozessorarchitektur gebaut wird, um lauffähig zu sein, z.B. ARM für Raspberry Pi 2, Raspberry Pi 3 oder x86 für MinnowBoard Max.

Was eine Universal Windows Plattform App ist und vieles mehr dazu erfährt man unter:

https://msdn.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp

Für Apps, die Hersteller-spezifische Bauteile und Features nutzen wollen, benötigt man entsprechende Bibliotheken. So ist z.B. für das Pin Board und die Nutzung von GPIO das Windows IoT Extension SDK notwendig.

Wie man seine Apps auf das IoT-Device deployed kann man hier gut nachvollziehen.

https://developer.microsoft.com/en-us/windows/iot/Docs/appdeployment#csharp

Befindet sich das IoT-Device im Netzwerk mit Zugang zum Internet, kann direkt vom Device eine Verbindung zu Cloud Services oder ähnlichem aufgebaut werden und zwar bidirektional.

Azure IoT Hub

Last but not least bietet Microsoft mit dem Azure IoT Hub noch die Möglichkeit, die IoT-Devices zu verbinden, überwachen und zu verwalten.

Neben zahlreichen hilfreichen Features ist hier vor allem die Möglichkeit einer zuverlässigen, bidirektionalen Kommunikation mit dem Device der Grund, warum man sich Azure IoT Hub auf jeden Fall einmal ansehen sollte.

Zugang zum Azure IoT Hub findet man hier:

https://azure.microsoft.com/de-de/services/iot-hub/

Zu Testzwecken kann man sich kostenlos für den Dienst registrieren und bis zu 8000 Nachrichten am Tag für Testszenarien an seine Devices verschicken.

Kurze Schlussbemerkung

Mir persönlich hat der IoT-Workshop Lust gemacht, mich nochmal etwas praktischer mit dem Thema auseinander zu setzen. Natürlich weiter im Umfeld von Windows IoT, da mein technischer Fokus im Arbeitsalltag auch auf Microsoft-Technologien liegt. Aber auch die Möglichkeiten, die Microsoft Entwicklern bietet, sich kostengünstig dem Thema zu nähern, haben mich überzeugt.

Stellt sich nun die Frage, ob ich an die Elektronik unserer Kaffeemaschine darf ☺

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

Wir haben auch noch Schoki da!

Veröffentlicht am 28.02.2017 von Clemens Kruse , DevOps , Cloud , Event

Rub a little DevOps on it - “Delivering Value to our Customers. That’s what it is about.”

Donovan Brown hat mich auf der Technical Summit durchaus beeindruckt. Trotz der fortschrittlichen Inhalte seiner Keynotes lag das aber vor allem daran, dass er schlichtweg ein Entertainer ist. Dies trifft nicht nur auf Donovan zu.

Mein Gesamteindruck der Technical Summit 2016 ist ein Mix aus Entertainment, Werbung und sehr guten Ideen. Ich bekam zahlreiche Eindrücke, wie gewisse Probleme angegangen werden können - die Methoden dazu gibt es aber nicht erst seit gestern. Der Fokus der meisten Vorträge lag auf dem Thema „Microsoft ❤ Open Source“. So auch der von Donovan, der ein Szenario aus Ubuntu + aspnet core + Docker + yeoman + Visual Studio Code präsentierte, um die Nachricht der neu entdeckten Affinität von Microsoft zu Open Source Software zu verbreiten.

Erste Tutorials mit ähnlichen Szenarien gibt es allerdings schon seit Februar 2016 (beispielsweise dieses hier: https://blogs.infosupport.com/build-deploy-test-aspnetcore-docker-linux-tfs2015/ oder hier: http://blog.codingtimes.com/2016/06/29/net-core-mvc-web-application-at-ubuntu-16-04-with-yeoman-docker-and-visual-studio-code/). Ich wollte einigen Impulsen folgen und das ein oder andere Tutorial nachbauen und habe recht schnell gemerkt, wie umständlich das ganze Prozedere ist. Bisher habe ich in Visual Studio nur ein Projekt-Template gewählt, programmiert und nach getaner Arbeit schließlich via Rechtsklick die Solution bereitgestellt. Jetzt fühlt es sich so an, als hätte man den Ferrari gegen einen Lada eingetauscht, weil der Lada-Verkäufer so charmant gewesen ist.

Meinen persönlichen Höhepunkt hatte die Ferrari-Lada-Metapher im Vortrag „Yo ASP.NET – was ist neu und was bleibt mit ASP.NET Core 1.0“. DOTNET ist mit Core nun modular geworden. Das ist schön. Da Microsoft ja mittlerweile Open Source liebt, wurde auch in diesem Vortrag alles mit Ubuntu und VS Code umgesetzt. Das heißt im Klartext: alles zu Fuß. Das funktioniert sicherlich irgendwie (wenngleich die Demo etwas holprig verlief), hat aber meiner Ansicht nach nichts mit Fortschritt zu tun. Um das Publikum während des Vortrages bei Laune zu halten, wurden die Schokoladen-Reste vom Nicolaus verteilt. „Wenigstens gab es Schoki“ wird der ein oder andere Besucher am Ende der Veranstaltung gedacht haben.

Fazit aus Perspektive des Studenten: Um sich Impulse zu holen war die Technical Summit 2016 in Darmstadt sehr gut geeignet. Auch das Essen war deutlich besser, als das was man aus der Mensa gewohnt war. Und zwischendurch gab es auch richtig gute Vorträge. „Machine Learning for Developers“ von und mit Seth Juarez war einer davon. Richtig in die Tiefe gehen muss man jedoch immer noch selbst. Immerhin haben mich die zwei Tage dazu gebracht, mich mehr mit Docker und Microservices auseinanderzusetzen. Wenngleich ich auch dort in meinem Mini-Projekt (WCF-Service in einem Container) in der begrenzten Zeit nur an der Oberfläche kratzen konnte.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

Die Möglichkeit der Wiedereingliederung nach längerem Ausfall

Veröffentlicht am 01.02.2017 von Florian Hieber , Insights@ebizcon

Nach einer langwierigen gesundheitlichen Einschränkung bietet die Deutsche Rentenversicherung oder die Krankenversicherung die Möglichkeit der Wiedereingliederung. Während dieser Maßnahme bezahlt der Kostenträger dem Versicherten einen Großteil seines Gehaltes, während dieser unter Aufsicht eines Arztes teil- und stufenweise wieder in das Arbeitsleben zurückfindet.

Ich hatte Mitte des Jahres ein gesundheitlich einschneidendes Erlebnis. Nach einer recht plötzlichen und aufwändigen Operation war ich vier Monate arbeitsunfähig, inklusive einer Rehabilitationsmaßnahme. Vorher hätte ich es mir nicht vorstellen können, dass selbst alltägliche Dinge ein Problem darstellen können. Aber ich musste erleben, dass selbst Einkaufen oder Haushaltstätigkeiten mich dermaßen anstrengen können, dass ich diesen kaum gewachsen war.

Noch in der Rehabilitation wurde ich vom Sozialdienst und der Psychologin gefragt, ob eine Wiedereingliederungsmaßnahme in die Arbeit für mich interessant ist. Man selbst ist nämlich auch schon die erste Hürde für solch eine Maßnahme. Der Kostenträger, der Patient, der Arbeitgeber und der behandelnde Arzt müssen mit dieser Maßnahme einverstanden sein. Bei mir war diese Hürde schnell genommen, die eBiz Consulting hat diese Maßnahme sofort unterstützt. Arzt und Kostenträger haben diese Maßnahme ja vorgeschlagen, und auch mir hat die Aussicht, etwas früher, dafür schrittweise in das Berufsleben zurückzukehren, gut gefallen.

Wenn alle ihr Einverständnis bekundet haben, legt der Arzt einen Plan fest, der die Tagesarbeitszeiten für einen bestimmten Zeitraum festlegt. Das geschieht in Stufen solange, bis die Tagesarbeitszeit wieder der normalen Arbeitszeit entspricht. Zu diesem Zeitpunkt endet dann auch die Krankschreibung. Bis dahin ist man krankgeschrieben und

1. darf erstens keinen Urlaub nehmen, zweitens zahlt der Arbeitgeber keine Bezüge und drittens müssen Reisetätigkeiten mit dem Arzt besprochen werden.

Diese Planung sowie ein Antragsformular wurden vom Sozialdienst an die Deutsche Rentenversicherung gesendet, die die Maßnahme sehr schnell genehmigte.

Zwischen der Reha und der Maßnahme liegt üblicherweise noch ein gewisser Zeitraum.

clip_image002

Ist dieser länger als 28 Tage, ist der Träger der Maßnahme die Krankenkasse, ansonsten die Rentenversicherung. In meinem Fall war der Träger war die Rentenversicherung. Diese differenziert zwischen der Maßnahme selbst und dem Übergangsgeld, man muss also weitere Formulare ausfüllen, um eine Lohnfortzahlung in Form von Übergangsgeld zu erhalten. Das Übergangsgeld wurde erst sehr spät gezahlt, etwa zwei Monate nach Beginn der Maßnahmen. Hier müssen sich also genügend liquide Geldmittel auf dem Konto befinden. Die Rentenversicherung zahlt auch keine Abschläge, da sie argumentiert, man müsse dafür finanzielle Rücklagen für so einen Fall aufbauen.

Umfang und Dauer der Wiedereingliederung sind unter anderem abhängig vom Wiedereingliederungsplan des behandelnden Arztes und der Berufstätigkeit. Mein Plan sah vor, mit 4h Arbeit am Tag über einen Zeitraum von 14 Tagen zu beginnen. Danach wurde die Anzahl auf 6 Stunden pro Tag für die nächsten 14 Tage vorgeschlagen. Krankheitsbedingt war Reisen erst in der letzten Woche erlaubt, Fliegen für den Zeitraum der Wiedereingliederung gar nicht. Da bei der eBiz Consulting das Motto „Erst wer, dann was“ wirklich gelebt wird, wurden schnell Aufgaben gefunden, die mit meinem gesundheitlichen Zustand vereinbar waren. Es wurde sogar über die Wiedereingliederung hinaus darauf geachtet, dass die übernommenen Tätigkeiten nicht zu anstrengend waren, obwohl ich offiziell ja wieder gesund war. Tatsächlich benötigte ich etwas mehr Zeit, um wieder ins Arbeitsleben zu gelangen als selbst der Arzt mit seinem Plan angenommen hatte. Insofern war ich der eBiz Consulting sehr dankbar für die Rücksichtnahme und das Verständnis. Ich selbst habe nicht mit so starken Einschränkungen und Startschwierigkeiten gerechnet, da war es erst recht außergewöhnlich und eine gute Erfahrung, dass der Arbeitgeber hier Verständnis zeigt.

Fazit:

Die Wiedereingliederung war eine neue und positive Erfahrung, die ich Jeder und Jedem ans Herz legen kann, der nach längerer Krankheit rasch und sicher zurück ins Berufsleben gehen möchte. Einzig die Herausforderungen finanzieller Art, die ich bei der Deutschen Rentenversicherung erlebt habe, haben das Bild etwas getrübt. Unterm Strich ist das aber kein Grund , die Wiedereingliederung nicht zu machen. Ansonsten würde man länger krank sein und direkt wieder zu 100% in das Berufsleben gehen. Diesen Schritt hätte ich mir unten meinen persönlichen Umständen sehr schwer vorgestellt.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise