Blog
Vertrauensentzug StartSSL

Im Oktober diesen Jahres hat Mozilla in ersten Stellungnahmen angekündigt, der israelischen Zertifizierungsstelle StartSSL das Vertrauen zu entziehen (https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/). Inzwischen hat sich das ganze als gesicherte Tatsache herausgestellt. Mit dem Firefox Update 51 wird Firefox neu ausgestellte Zertifikate von StartSSL und WoSign nicht mehr als vertrauenswürdig einstufen. StartCOM darf sich gemäß Ticket #1311832 ab dem 01. Juni 2017 wieder neu bewerben.

Auch Google hat kurz darauf reagiert (https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html) und wird ebenso WoSign und StartCOM das Vertrauen entziehen. Und auch Apple hat reagiert.

Wie man den verschiedenen Berichten entnehmen kann, funktionieren die Sicherheitsregeln bei den Zertifikaten und das ist ein sehr gutes Signal. Zertifizierungsstellen müssen sich eben stets behaupten und wie sich das auf StartCOM und WoSign auswirkt, bleibt abzuwarten. Und warum schreiben wir darüber?

Seit einigen Jahren haben wir erfolgreich auf die CA von StartCOM gesetzt. Die Zertifizierungsmethoden waren sehr gut und sicher. Der Service war gut und die Preise stimmten. Wir hatten Zertifikate für unsere Webseiten und auch ein paar persönliche Zertifikate. Inbesondere für unsere Website und das Ticketportal hatten wir sogar eine extended validation (zu sehen an dem grünen Balken im Browser). Der gründe Balken ist jetzt weg.

Wir haben nun mit heutiger Wirkung unsere Zertifikate ausgetauscht. Wir setzen nun auf die deutsche Bundesdruckerei als Zertifizierungsstelle (D-TRUST). Der Service ist zu empfehlen und nach eingehender Beratung haben wir für uns auch festgestellt, dass wir keine extended validation benötigen. 

Unsere Kunden können aber auch in 2017 davon ausgehen, das wir die Daten sicher verschlüsseln und das sie auf unseren Seiten unterwegs sind. Sollten Sie Fragen oder Hinweise haben, melden Sie diese bitte an ssladmin@bidcore.de.

So einfach kann es sein...

Unser Einstieg in die VOIP Welt war nicht so einfach, wie es die ganzen Prospekte der großen Anbieter hoffen lassen. Technisch gesehen, war alles möglich und nichts funktionierte. Daher freuen wir uns alle riesig, dass wir nun endlich frei und ohne Grenzen telefonieren können und das mit jedem beliebigem Endgerät.

 

Schon lange hatte Starface die neue Appliance Starface Connect herausgegeben. Wir wollten nur bei uns noch nicht den Unstieg machen, da uns der passende Provider fehlte. SIP sagen alle, kann aber nicht jeder. WIr sind nach langen Versuchen und Tests bei toplink gelandet. Das war eine sehr professionelle Umstellung und ein guter Service. 

Dann haben wir erstmal unsere Clients aufgerüstet. Der neue UCC Client von Starface ist wirklich klasse und integriert sich nun sowohl unter Windows als auch unter Mac OS hervorragend in die Arbeitsabläufe.

Letzte Woche kam dann die Starface Connect an und nun läuft alles rund. Die Installation war grundsätzlich in 5 Minuten erledigt. 

Wirklich klasse sind auch die 4 analogen Anschlüsse (die gab es früher nicht). Unser Türsprechanlage war nun ganz schnell eingerichtet.

Ebenfalls klasse sind die kleinen Details, z.B. die Einbindung einer Türkamera über eine URL. Der Bau einer kleinen Überwachung mittels Raspberry ist damit schon klar.

 

Wer bis dahin noch keinen SIP Provider hat, kann auch direkt über die Starface zu attraktiven Konditionen einen Anschluß freischalten. Wer SIP-Trunking machen möchte, dem sei TopLink oder QSC empfohlen.

Die Umstellung hat sich gelohnt und ist jedem zu empfehlen. Die Basisinvestition ist mit 1300,00€ sehr überschaubar und im Vergleich zur Konkurrenz günstig. Nähere Informationen gibt es bei uns gern. 

Launch der Starface Compact

Die neueste Appliance, die STARFACE Compact, ist für kleine und mittlere Unternehmen für bis zu 20 Benutzer ausgelegt. Die STARFACE Compact überzeugt durch eine in ihrer Größenklasse einzigartige Vielzahl von Anschlussoptionen:
Neben vier Analog- und zwei ISDN-Amtsanschlüssen verfügt die neue UCC-Plattform erstmals übereinen dedizierten NGN-Anschluss

 

Verlagern Sie ihre Telefonie auf einen komplett für VoIP optimierten Internet-Anschluss und profitieren Sie von der kristallklaren Sprachqualität der Zukunftstechnologie NGN.

 

Am 10.09.2013 wurde ein Workshop zum Thema IT-Security vom BVMW und der Oldenburgischen Landesbank ausgerichtet.

Wir waren dabei und wollen hier kurz unsere Eindrücke zum Thema IT-Security mit Ihnen teilen.

IT-Security ist...

... oder besser, was ist es nicht.

Wir haben aus den diversen Vorträgen erfahren, das IT-Security nicht grundsätzlich darauf basiert, die neueste Firewall, die aktuellsten Virenscanner und Verschlüsselungsalgorithmen einzusetzen. Selbstverständlich sind technische Hilfsmittel relevant spielen am Ende eine Kette von Entscheidungen eine Rolle. 

In erster Linie ist festzuhalten, dass Sicherheit ein Thema für die Geschäftsführung eines Unternehmens ist. Jeder Geschäftsführer muss sich über den Umfang des Schutzbedarfs im Klaren sein und diesen Bedarf stetig überprüfen. Denn auch mit Änderungen im Unternehmen, ändern sich die Anforderungen an den Schutz. Und dabei geht es hier ganz klar nicht um den gesetzlich geregelten Datenschutz. Es geht um die eigene Wahrnehmung welche Informationen meines Unternehmens vor den Zugriffen anderer zu schützen sind.

Was ist IT-Security

Diese Definition gilt es in erster Linie festzulegen. Denn in einem Unternehmen gibt es ein Bermudadreieck, in dem gerade der Sicherheitsgedanke verschwindet.

Dieses Dreieck kann nur durch klare Richtlinien, und die Einbindung aller Beteiligten aufgelöst werden.

Interessant waren die unterschiedlichen Ansätze der Vortragenden an diesem Abend. Über die Website des Bundesamtes für Sicherheit in der Informationstechnik (BSI) erhält man viele Grundlagen, um das Thema grundsätzlich aufzuarbeiten. Die Verwendung des GSTOOLS hat sich aber inzwischen auch erledigt und ist auch vielfach nicht notwendig. Man kann einiges an Komplexität reduzieren, wenn man einfach die folgenden Schritte beachtet:

  1. Erstellung eines Sicherheitsleitfadens durch die GL
  2. Einrichtung einer Taskforce bestehend aus Mitgliedern der GL, den Anwendern und den Administratoren
  3. Umsetzung der Ergebnisse durch die Administratoren

Zu diesen Punkten kann man beim BSI auch Dokumente und Vorlagen finden. Diese kann man als Anhaltspunkt verwenden

Erstellung eines Leitfadens

Definieren Sie auf einer sehr hohen Ebene im Kreise der Geschäftsleitung einen Leitfaden, was Sie unter IT-Sicherheit verstehen. Grenzen Sie die Themen klar von dem gesetzlichem Datenschutz ab und definieren Sie klar die Bereiche, die besonders zu schützen sind. Um eine hohe Ebene zu gewährleisten, versuchen Sie, das Dokument auf eine DINA4 Seite zu begrenzen.

Taskforce

Die Taskforce definiert aus der Leitlinie der Geschäftsleitung eine IT-Security Policy. Diese Policy definiert in detailliertere Form die Eckpunkte des Sicherheitsbedarfs. Hier muss vor allem gelten, dass die einzelnen Andorderungen

  1. erreichbar
  2. messbar
  3. maßvoll

sind. Achten Sie darauf, dass Sie nicht mit Kanonen auf Fliegen schießen. Die entwickelte Policy muss von der Geschäftsführung bestätigt werden und im Unternehmen akzeptiert werden. Die beste Policy nützt nichts, wenn organisatorische Schutzmassnahmen nicht anerkannt und gelebt werden.

Umsetzung

Technische Maßnahmen aus der Policy werden durch die Administratoren umgesetzt. Organisatorische Maßnahmen werden durch die Taskforce-Mitglieder in das Unternehmen getragen.

Unterstützung

Hilfestellungen findet man beim BSI. Versuchen Sie die Einführung einer IT-Security Policy selbstständig umzusetzen. Gute Unterstützung leisten jedoch auch Moderatoren, die das Thema IT-Sicherheit verstehen. Auch wir können Ihnen mit unseren Erfahrungen gern helfen.

Überprüfung

Überprüfen Sie die Policy mindestens alle 2 Jahre, besser noch jedes Jahr. Fragen Sie sich und Ihre Taskforce, ob die Maßnahmen ausreichen. Ob technische Prozesse noch funktionieren. Wenn man nie einen Crash hatte, sollte man prüfen, ob Backups und Wiederherstellungsprozesse noch funktionieren.


Alles in allem war dieser Workshop ein guter Anfang. Wir sollten uns alle als Unternehmer öfter zu diesen Themen austauschen. Der BVMW ist dafür eine gute Plattform und wir sind sicherlich immer wieder gern dabei.





Sinnvoller DVCS Workflow

Grundidee

Die Nutzung eines DVCS (distributed version control system) erfordert insbesondere in einem Team ein gewisses Maß an Disziplin und Abstimmung. In 2010 veröffentlichte Vincent Driessen einen Artikel "A successful Git branching model" über ein Workflow-Modell, dass sinnvoll in einem GIT-System genutzt werden kann. Die Idee dahinter ist ein standardisiertes Modell für Branching und Merging in der Weiterentwicklung von Features, Bereitstellung von Releases und Hoffixes unter dem Fokus dauerhaft ein konsistentes Repository zu haben und flexibel reagieren zu können.

Ein derart komplexes Modell kann jedoch extrem komplex sein und die Nutzung eines standardisierten Vorgehens kann helfen:

  • ein aufgeräumtes Repository zu behalten
  • Verfahren klarer zu definierten
  • besserer Orientierung bei verschiedenen Projekten zu gewährleisten 
  • Neue Entwickler schneller einzuführen

Die Workflows können auch einfach über die Kommandozeile oder die IDE umgesetzt werden. SourceTree unterstützt die Workflows aber auch durch einfache Klicks. 

Unabhängig von technischen Hintergründen soll die Methode hier vorgestellt werden.

Die Basisidee verschiedene standardisierte Branches zu unterscheiden:

  • Development branch (‘develop’)
    Der Entwicklungszweig in dem alle Änderungen des nächsten Releases liegen. Änderungen erfolgen direkt in diesem Branch oder werdeb durch merges aus anderen Zweigen (z.B. feature) in den Zweig übernommen.
  • Production branch (‘master’)
    Dieser Zweig repräsentiert das letzte Release. Dieser Zweig darf nur durch merge aus anderen Zweigen verändert werden.
  • Feature branches (‘feature/’)
    Wenn Änderungen erfolgen müssen, die nicht trivial sind, sollte ein feature-branch erfolgen. Wenn die Arbeit beendet ist, wird der branch in den Development Branch übernommen.
  • Release branches (‘release/’)
    Wenn das neue Release zusammengebaut wird, wird ein release branch aus dem development branch erzeugt. Man kann das commit während der Releasevorbereitung durchführen, wenn das Release bereit für eine Auslieferung ist. Der Zweig wird via Merge in den Development und Master-Branch übernommen.
  • Hotfix branches (‘hotfix/’)
    Wenn das letzte Release gepacht werden muss, ohne das neue Features übernommen werden sollen, so kann ein Hotfix-Branch aus dem Master erstellt werden. Wenn die Änderungen erfolgt sind, kann der Hotfix-Branch in den Master-Branch und Development-Branch übernommen werden.

Dezentral aber Zentral

Das Setup des Repository für das Branching Modell basiert auf einem wahrem zentralen Repository. Aus Sicht eines DVCS gibt es nicht das zentrale Repository (zumindest nicht aus technischer Sicht). Wir nennen dieses Repository origin.

Jeder Entwickler führt die Pulls und Pushs gegenüber dem origin aus. Aber pulls aus den anderen Repositories sind selbstverständlich erlaubt.

Workflow-Schritte

Feature-Branch

Wenn die Arbeit an einem neuen Feature erfolgen soll, wird ein Branch aus dem develop Branch erstellt.

hg update develop
hg branch myfeature
hg commit -m "start myfeature"

Wenn die Arbeit an dem Feature beendet ist, müssen die Änderungen übernommen werden.

hg update develop
hg merge myfeature
hg commit -m "Merging myfeature"
hg push

 

Release-Branch

hg update develop
hg branch release-1.3
// durchführung der release arbeiten, z.B. manuelle Anpassungen etc.
hg commit -m "Release 1.3"

Existiert der Branch länger und sind zwischendurch Bugfixes notwendig, so muss dieser Branch in den Development-Branch übernommen werden.

 

Ist das Release fertiggestellt, muss der Stand in den Masterbranch übernommen werden.

hg update master
hg merge release-1.3
hg tag 1.3hg commit -m "Master aktualisiert"

Das Release muss dann noch in den Development-Zweig übernommen werden.

hg update develop
hg merge release-1.3hg commit -m "Aktualisierung aus Release"

Eventuell entstehen hier Konflikte, z.B. aus Bugfixes, die dann bereinigt werden müssen.

 

Hotfix

Hitfixes werden oft aus dem Master verzweigt. Das Vorgehen ist analog zu den oben beschriebenen. Nach der Fertigstellung ist darauf zu achten, dass nicht nur der master sondern auch unbedingt der develop Zweig aktualisiert wird.

 

Zusammenfassung

 

Grundsätzlich ist das Modell nichts wirklich neues. Eine konsequente Umsetzung erleichtert die Arbeit in kleinen und großen Teams und dient in erster Linie als mentales Modell.

 

Wenn man die unterschiedlichen Informationen rund um das Thema Informationstechnologie im Mittelstand im Jahr 2012 durchforstet, so fallen einige Kernthemen auf, die sich alle auf die Wertschöpfungskette und den Erfolg eines Unternehmens beziehen. Schauen wir uns diese doch einmal genauer an und entwickeln einem mögliche Potenziale.

Kernthemen

Es finden sich in größer Häufigkeit die Themen

  • Datenqualität
  • Standardprozesse
  • Insellösungen 
  • Integration
  • flexible Arbeitsplätze
Bei den unterschiedlichen Analysen und Meinungen fällt mir jedoch auf, dass es viele Ansätze gibt, die den Unternehmensentscheidern Vorgaben machen. Allerdings kommt mir da der Gedanke, dass dabei der Unternehmer selbst nur selten zu Wort kommt. Ich möchte daher zu diesen Themen auch mal die andere Seite beleuchten.

Datenqualität

Aus einem Artikel von iconomy entsteht durch Datenqualität ein ganz erhebliches Risiko.

Allein nur durch Zweifel an der Datenqualität und den daraus folgenden Kontrollen und Überarbeitungen gaben amerikanische Mitarbeiter an, 30% ihrer Arbeitszeit zu verbrauchen. Für einige US-Unternehmen entstehen dadurch Kosten von 600.000 Dollar. Gehen wir mal von einem mittelständischem Unternehmen aus. 10 Verwaltungsmitarbeiter mit einem Bruttolohn von 2000 Euro verwenden nun 30% der Arbeit für Qualitätskontrollen so ergeben sich Kosten von 72.000 Euro pro Jahr. Darin sind die Überarbeitungen möglicher Fehler nicht eingerechnet.

 

 

Standardprozesse

Ebenfalls bei iconomy findet sich ein auch sonst nicht unüblicher Artikel über Standardprozesse. Diese beschreibt, dass in der logischen Konsequenz zur Einführung von Standardsoftware auch die Standardisierung der Geschäftsprozesse folgen muss. Ungeachtet dessen, dass eine Standardisierung von Geschäftsprozessen und die kritische Betrachtung der Prozesskosten richtig und wichtig ist, stelle ich die Frage, warum ein mittelständisches Unternehmen abhängig der eingesetzten Software und IT-Architektur gesteuert wird.

Insellösungen

Insellösungen sind technische Systeme, die nur innerhalb eigener Grenzen funktionieren. Laut einer Studie von RAAD bergen gerade solche Insellösungen ungeahnte Risiken. Meist sind diese Insellösungen mit der bekannten "heißen Nadel gestrickt". Oft werden Office-Produkte eingesetzt und die Interoperabilität mit den zentralen Systemen spiel meist eine untergeordnete Rolle. Insellösungen gefährden bedingen oft eine schlechte Datenqualität. Aber sie spiegeln oft die tatsächlich gelebten Unternehmensprozesse wieder, die sich eben nicht im Rahmen der eingeführten Standardsoftware standardisieren lassen wollen.

Die Antwort der Hersteller sind ganzheitliche Lösungen. Das sind meist hochintegrative Lösungen, die versprechen, dass keine Insellösungen mehr notwendig sind. Aber sind wir mal ehrlich. Der ganzheitliche Ansatz hält genau so lange, bis das eigene Unternehmen sich weiter entwickelt hat und der Hersteller nicht schnell genug reagieren kann, oder diese Reaktionen mit hohem Anpassungsaufwand verbunden ist. Das ist meistens die Geburtsstunde der nächsten Insellösung, richtig?

Integration

Heute integrieren wir alles. Cloud, Social Networking, Customer Relation Management, Business Intelligence, Business Process und viele weitere Trends begegnem dem Unernehmer von heute. Insgeheim wollen wir auch alle dazu gehören. Und wärhend wir die neue Cloud-Lösung einführen und dann via EXCEL eine neue Auswertung aus unserem neuen Berichtswesen erstellen und darüber in unserem firmeninternen sozialem Netzwerk berichten, stellen wir uns immer wieder die Frage: "Ist das Integrativ?".

Soziale Integration heißt, wir nehmen verschiedene Personen/Gruppen in eine Gemeinschaft auf. Software-Integration heißt, wir verknüpfen verschiedene Anwendungen derart, dass diese als eine Einheit funktionieren. Ein wirklich toller Ansatz ist EAI (Enterprise Application Integration). Das können sich aber nur wenige leisten.

Wir können zwar von verschiedenen Anwendungen auf die Daten anderer Anwendungen zugreifen. Aber das geht auch nur dann, wenn wir bei der Investition bewusst darauf achten, dass entsprechende Schnittstellen auch existieren. Gelingt das?

Als Unternehmer wünschen wir uns ein gute, ausreichende und sinnvolle Unterstützung unserer Geschäftsprozesse durch die IT. Nach ökonomischen Prinzip gilt hier natürlich auch, dass die Lösungen so preiswert wie möglich sein sollen. Ist es dabei sinnvoll, große und scheinbar integrative Lösungen zu implementieren, bei denen viele Funktionen bezahlt werden, die wir nicht brauchen.

Formulieren wir doch einfach unsere Wünsche, Anforderungen und Ziele und lassen diese so umsetzen, wie unser Unternehmen sinnvoll damit umgehen kann. In der produzierenden Industrie ist dieses Vorgehen seit Dekaden bewährt. Die meisten Unternehmen haben eigene Schlosser, die die Maschinen gemäß den Produktionsanforderungen rüsten. Universelle Lösungen gibt es nicht, warum sollten generalistische Implementierungen dann integrativ sein.

flexible Arbeitsplätze

Im Unternehmen, in den Familien und in der Politik wachsen die Anforderungen an flexible Arbeitsplätze. Technisch gibt es hier kaum Grenzen und mit geringen Investitionen lassen sich alle notwendigen Voraussetzungen schaffen. Viele Systeme lassen sich auf unterschiedliche Weise aus der Ferne bedienen oder bieten mobile Anwendungen. Aber der flexible Arbeitsplatz ist doch keine Frage der Technik allein.

Die Flexibilität beginnt im Unternehmen. Für die Mitarbeiter, die aus der Ferne arbeiten, muss der Unternehmer ein großes Vertrauen aufbringen. - Wirklich?

Ist der Vertrauensvorschuss an extern arbeitende Mitarbeiter wirklich größer, als gegenüber den internen Mitarbeitern? Eher nicht. Kein Arbeitgeber stellt sich den ganzen Tag hinter seine Mitarbeiter. Entscheidend ist doch die Produktivität und das Verhältnis zwischen geleisteter Arbeit und den erzielten Ergebnissen.

Trauen wir uns und in den meisten Fällen, werden es uns unsere Mitarbeiter danken.

Wenn Sie diese Punkte inspiriert haben und Sie mehr über die verschiedene Ansätze wissen wollen, melden Sie sich doch einfach bei uns.

Agile Mythen

Es gibt einige Mythen zu agilen Prozessen, insbesondere in der Softwareentwicklung. Wir setzen selbst agile Methoden ein und wollen daher den ein oder anderen Mythos ausräumen.

Agile Entwicklung ist undiszipliniert

Agile Entwickler müssen sehr diszipliniert mit Entwicklungspraktiken und -ritualen umgehen. Techniken wie Continous Integration, Refactoring, Test Driven Development, Behaviorial Driven Development, eXtreme Programming und Peer Reviews sichern einen klaren Code - jeden Tag.

Das Projektmanagement auf Basis von Daily Scrum, Sprint Planung und Retrospektiven erfordert ebenso ein hohes Maß an Konsequenz.

Das Produktmanagement basiert und einem Produkt-Backlog und regelmäßigen Demos.

Agile Teams sind planlos

Konstante Planung is ein bedingter Teil von Agilität. Die Planung verläuft im agilen Ansatz lediglich anders. Traditionell wird eine Detailplanung von Anfang an gemacht. Agile Planung heißt:

  • eine High-Level Planung erfolgt zu Beginn des Projektes mit Release Meilensteinen. Basis ist das Product Backlog
  • Das Product Backlog wird mit dem Product Owner analysiert. Der Product Owner entscheidet, welche Features in welchem Release integriert werden.
  • Wenn die Releases geplant sind, werden diese in sogenannte User Stories heruntergebrochen und priorisiert. Riskoreiche, notwendige und wichtige Features werden in die früheren Sprints geplant. Ein Sprint enthält verschiedene User Stories.

Der Plan wird durch Indikatoren überwacht (Release/Sprint burn down, Feature burn-up)

Agile Entwicklung ist nicht prognostizierbar

Kunden wechseln ihr Verhalten, das Geschäft ändert sich, Märlte ändern sich, Wettbewerb ändert sich, Anforderungen ändern sich, Produkte ändern sich.

Änderungen gehören zum Leben. Die Zeiten, in denen Projektprognosen gefragt sind, sind vorbei. Wir erinnern uns doch nur ungern an die Zeiten, in denen wir Monate lang Spezifikationen geschrieben haben und Feinplanungen abgestimmt haben. Und am Ende wurden Festpreis-Verträge ausgehandelt, die Unmengen an Klauseln enthalten, um gegenseitiges Risiko zu vermeiden. Kunden und Hersteller verwalten mit immensem Aufwand die Wertschöpfung, Termine. Das alles haben wir getan, um eine 100%-ige Prognose zu liefern.

Agile Entwicklung verwaltet die Unvorhersehbarkeit. Mit der richtigen Planung und dem richtigem Tracking kann der ausgelieferte Wert einen Produktes viel besser geplannt und überwacht werden. Agile verlässt sich nicht auf Moon-Charts. Allein das Produkt und seine Entwicklung zählt. So lässt sich eine handfeste Vorhersage prüfen.

Agile heißt: Ich kann meine Meinung immer ändern

Einer der größten Mythen in Bezug auf Agile. Die Meining stets zu ändern und Aussagen wie: 'Ach, laß uns das im nächsten Step machen' ist meistens Teil eines Experiments.

Agile Entwicklung orientiert sich am Geschäftswert einer Anforderung. Wenn die Beteiligten das unternehmerische Geschäft nicht im Fokus haben, entstehen diese Situationen. Es ensteht kein Mehrwert, die Ideen müssen stetig überarbeitet werden, die Entwicklung frustiriert und das Projekt stürzt ab.

Es ist extrem wichtig zu wissen, was geliefert werden soll, wie die Akzeptanz gegeben ist und dann auszuliefern, zu validieren und produktiv zu arbeiten.

Agile heißt, keiner dokumentiert

Das ist wie folgt umzuformulieren: Agile heißt, es wird keine unnötige Dokumentation erstellt, die keiner liest. Traditionell haben wir früher große Spezifikationen, Flußdiagramme, Designs, Anforderungsmatrizen, Handbücher etc. geschrieben. Und was davon wird gelesen? Wieviele dieser Dokumente wurden aktualisiert? Welche Dokumente waren wirklich sinnvoll oder liegen nur in einem Ordner herum?

In agilen Prozessen stellen wir sicher, dass die Dokumentation natürlich verwaltet wird. In-line Dokumentation, Architektur- und Designdokumente, Wikis, Soziale Team Bereiche und on-line Handbücher. Wir automatisieren möglichst viele Tests, definieren automatische Akzeptanz Kriterien über BDD Tools, Testberichte und historische Reports die im Rahmen des Deploys erstellt werden.

Wir dokumentieren sinnvoll, gehaltvoll und natürlich. Wir werden für innpvative Produkte und nicht für hübsche Dokumente bezahlt, oder?

Agile Teams sind nicht kontrollierbar

Die Frage, die sich stellt, ist vielmehr: Müssen Teams durch ein Management kontrolliert werden, oder muss das Projekt kontrolliert werden?

Agile Teams zeichnen sich durch ein Eigenmanagement, Bevollmächtigungen und Motivation aus. Das Team arbeitet sehr eng mit den Endusern und dem Product Owner zusammen und wird an der Unterstützung der Geschäftsprozesse gemessen. Die Tatsache, dass in sehr kleinen Zeitabständen geliefert wird, bindet das Team sehr viel stärker, als in herkömmlichen Ansätzen.

Je mehr ein Team kontrolliert wird, desto weniger trägt das Team die Verantwortung. Andererseits stellt ein hoher Grad an Disziplin eine wichtige Voraussetzung dar, um den Projektfortschritt und die Qualität zu sichern.

Agile Prinzipien basieren auf Motivationsfaktoren. Die Menschen, die am Projekt arbeiten, sind gut ausgebildet und Stolz, die 'Besten' für das Projekt zu sein. Das Management sollte nicht für die Kontrolle zuständig sein. Das Management stellt Infratrukturen, Arbeitsbereiche, Freiräume zum Experementieren, Sprechen, Diskutieren und Lernen bereit. Der Fokus wird auf den Projektfortschritt, den Kunden und die Qualität gelenkt.

Agile ist nicht skalierbar

Aktuelle Studien zeigen, dass Agile Methoden schon erfolgreich bei großen und kirtischen Projekten funktioniert haben. Immer mehr Entwickler nutzen Agile Methoden und die Unternehmen, die Agile Methoden einsetzen sind auch größere Unternehmen.

(Source : The Business Value of Agile Software Methods)

Die Möglichkeit, eine Projektvision auf verteilte übersichtliche Teams aufzusplitten, gibt auch die Möglichkeit große Projekte umzusetzen.

Agile Entwicklung ist nur ein Hype

Laut Gartner werden agile Methoden bei 40% der Software-Entwicklungs-Teams in 2012 eingesetzt. Die Nutzung und Integration von agilen Methoden verläuft langsamer, insbesondere bei großen Unternehmen. Aber insbesondere Unternehmen, deren Geschäftsprozesse extrem volatil sind, profitieren von agilen Methoden. Bei großen und langlaufenden Projekten mit sehr vielen Projektbeteiligten wird sich die Nutzung agiler Methoden sicherlich noch weiter hinauszögern. Aber es ist eher eine Frage weniger Jahre, dass sich agile Methoden zunehmend durchsetzen werden.

(Quelle: people10)

 

 

 

Projektbericht eCore

Wir können über ein neues Projekt berichten, dass zeigt, dass man mit Individualsoftware eigene Geschäftsmodelle effizienter umsetzen kann. Es gibt bereits viele Lösungen am Markt, die die energiewirtschaftlichen Herausforderungen meistern. Unser Kunde GETEC net GmbH hat sich aber dazu entschlossen, alle Anforderungen integrativ umzusetzen und bestehende Einzellösungen abzuschaffen.

Lesen Sie im Projektbericht Details zur Architektur und den Funktionen. Vielleicht wollen auch Sie Ihre Geschäftsprozesse besser integrieren, dann kontaktieren Sie uns. Wir freuen uns auf Ihre Ideen

Willkommen 2012

Wieder geht ein Jahr zu Ende und ein neues spannendes Jahr beginnt. Anlass genug, um die letzten 12 Monate zu reflektieren und die kommenden zu fokussieren.

Das Jahr 2011war für uns ein aufregendes Jahr. Wir haben

  • unser Framework erweitert
  • neue Kunden gewonnen
  • bestehende Kunden zufriedener gemacht
  • die erste freie Anwendung auf den Markt gebracht
  • Mitarbeiter rekrutiert
  • Kontakte geknüpft
  • uns sozial vernetzt
  • Büros erweitert
  • viel Kaffee und Tee getrunken
  • und Spaß gehabt

Alle Aktivitäten waren wichtig und alle haben uns weitergebracht. Grund genug, kurz zu berichten.

Frameworkerweiterungen

Unser Framework wurde um eine eigene Kalenderkomponente erweitert. Wir verfügen damit über eine hauseigene Komponente, die die besten Eigenschaften aus Outlook und Mac OS iCal vereint und sich nahtlos in unser Framework einfügt. Das ist toll für uns und unsere Kunden. Unsere Anwendungen werden damit stark aufgewertet.

Ferner haben wir unserem Framework interne Komponenten hinzugefügt. Einen verbesserten Transaktionsmanager, ein asynchrones Server-Modul, eine EDIFACT-Komponente und unseren flexiblen Import noch flexibler gemacht.

 

Unsere Kunden

Wir konnten neue Kunden gewinnen und werden nach Abschluss der Projekte noch weiter darüber berichten. Dafür ist es noch zu früh.
Unsere bestehenden Kunden haben Anwendungen zu energiewirtschaftlichen CRM-Systemen und Facility-Management geordert. Das werden auch in Zukunft spannende Aufgaben bleiben.

Auch konnten wir unsere Wartungskonzepte weiter etablieren und unsere Kunden schätzen unsere Wartungsdienstleistungen und Flexibilität.

bidFaktura - Rechnungen für jedermann

Unsere erste freie Anwendung bidFaktura soll allen Anwendern und potenziellen Kunden zeigen, wie Individualsoftware einsetzbar ist (http://www.heise.de/software/download/bidfaktura_basic).
bidFaktura ist bereits heute für uns eine Komponente für Interessenten eine gute Gelegenheit, uns kennenzulernen

Mitarbeiter

Wir haben die Bereiche Entwicklung, Test und Support verstärkt. Gerne sind wir an weiteren Kontakten interessiert und wenn wir unsere Kompetenzen ausbauen wollen, brauchen wir ein starkes Team.

Ausblick 2012

Auch in 2012 haben wir viel vor. Mit unseren neuen Kunden wollen wir weiter gemeinsam erfolgreiche Projekte durchführen. Wir wollen auch in 2012 unser Team verstärken und uns öffentlicher präsentieren.

Seien Sie doch auch mit uns erfolgreich und erleben wir gemeinsam ein tolles 2012.

Jeder 10. ein MAC

Jeder zehnte Computer in einem Unternehmen ist ein Mac (MacTechNews). Dies bedeutet gleichermaßen, dass viele Unternehmen zunehmend Probleme haben, die eigenen Anwendungen auf allen Plattformen bereitzustellen. In einigen Fällen stehen browser-basierte Anwendungen zur Verfügung. Aber diese stellen auch oftmals nicht die Prozesse des Unternehmens in gewünschter Form bereit.

Für uns bestätigt sich daher die Mission, individuelle Prozesse der Unternehmen plattform-unabhängig zur Verfügung zu stellen.

bidFaktura ist da

Darf es noch etwas mehr sein?

Kein Problem. Besuchen Sie uns erneut und klicken Sie einfach auf das PayPal-Symbol auf der bidFaktura-Seite. Sobald wir die Benachrichtigung von PayPal über die erfolgreiche Transaktion haben, nehmen wir Sie in unseren Kundenstamm auf und Sie erhalten einen Lizenzschlüssel. Dann steht Ihnen der volle Umfang mit

  1. Kontenplan
  2. Offene Posten/Zahlungseingang
  3. Mahnwesen

und vielen anderen Features zur Verfügung.

Brauchen Sie noch mehr?

Zum Beispiel einen elektronischen Katalog und Shopsystem und einer Anbindung an bidFaktura. Mit unserem Partner OSG Online Software und dem Katalogsystem ELKAT entwickeln wir die für Sie genau richtige Version (Preis auf Anfrage).

Steigen Sie ein, in Ihre ganz persönliche Welt der Informationstechnologie und holen Sie sich Ihren Maßanzug für Ihr Business. Es kostet weniger, als Sie vermuten.

Das Hotel Jacobsbrunnen aus Westoverledingen/Ihrhove steht uns als Branchendesigner für eine Verwaltungssoftware für kleinere und mittlere Hotelbetriebe als Branchendesigner zur Seite. Mit dem Manager Sebastian Gerlach zusammen werden wir eine flexible Software entwickeln, die für flexibel auf die Bedürfnisse angepasst werden kann und die Standardprozesse eines Hotel- und Gaststättenbetriebs beherrscht. 

Neben den üblichen Reservierungs- und Buchungsprozessen werden wir die debitorische Buchhaltung und Faktura integrieren. Durch die Unterstützung verschiedener Plattformen (Windows und MacOS) können die Betriebe je nach Anforderung die Software unterschiedlich im Betrieb nutzen.

Aktuell haben wir die Anforderungen aufgenommen und beginnen mit dem grundsätzlichem Design. 

BiDcore ist registriert

Mit Wirkung zum 31.10.2010 wurde unter der Registernummer 30 2010 042 291 die Wort-/Bildmarke unseres Unternehmens beim Patent- und Registeramt registriert. Zusätzlich zur ursprünglichen Registrierung haben wir die Marke in verschiedenen Klassen registriert, um damit die Möglichkeiten zu schaffen, unsere Produkte auch zukünftig breiter und geschützt anbieten zu können. Die Marke ist in den Klassen

  1. Computersoftware
  2. Dienstleistungen für Informations- und Kommunikationstechnologie
  3. Installation, Reparatur und Wartung von datentechnischen Anlagen
  4. Bereitstellung des Zugriffs auf weltweite Netzwerke
  5. Organisation und Durchführung von Aus- und Weiterbildungsveranstaltungen
  6. technische Beratung im Bereich der Informations- und Kommunikationstechnologie; Sicherheitsdienstleitungen, Administration und Projektmanagement

Damit ist BiDcore ein geschützter Unternehmensname und ein Namensraum für viele unserer Produkte. Insbesondere ist damit auch der Name unseres Kernprodukts, unsere Applikationsframework namensrechtlich geschützt. 

In diesem Monat haben wir erfolgreich eine SAP-Ergänzung bei einem großen Energieversorger integriert. Die Anwendung unterstützt den Fachbereich bei der Abrechnung von speziellen Produkten, die aktuell im eingesetzten SAP-System nicht direkt abgerechnet werden können. Es geht hier um Themen wie:

  • Mehr-/Mindermengen-Abrechnung Strom/Gas
  • Erhaltungskosten
  • Vermiedene Netznutzung Biogas

Weitere Module sollen folgen. Die Anwendung kann über eine Schnittstelle die Abrechnungsdaten an das SAP übergeben. Genutzt wird dazu das Modul Billable Items (BIT). Für die Fälle, die nicht im SAP abgerechnet werden sollen, kann die Anwendung die Rechnungen selbst drucken und liefert auch für SAP-FI sogenannte Batch-Input-Mappen, die für die direkte Buchung genutzt werden können.

Durch die Modularität des Systems, können nach Bedarf schnell neue Abrechnungsmodule geschaffen werden. Bestehende Module können auch wieder abgeschaltet werden, wenn die Prozesse anderweitigt umgesetzt werden.

Die vollständige Integration ersetzt die Notwendigkeit, kritische Prozesse mit Office-Lösungen aufzubauen, die dann nur schwer zu warten sind und auch nicht einer Prüfung durch die Revision standhalten.

Weitere Informationen erwünscht. Kontaktieren Sie uns.

bid-system wird bidcore

Durch die aktiven Markenanmeldungen unseres Produkts bidCore ist nach umfangreichen Recherchen aufgefallen, dass der Name bid-system als Name nicht gänzlich wiederspruchsfrei ist. Wir haben uns daher kurzfristig dazu entschlossen, zur bidcore GmbH umzufimieren. Die aktuellen Mailadressen werden zunächst beibehalten und die Domains bleiben bestehen. Nach Bestätigung der Umfimierung werden die entsprechenden Daten hier aktualisiert.