• Work on SaaS Platform

    26. November 2020 | B. Jannedy

    We are currently working hard to enable the Software as a service platform

    Since Atlassian will cancel all OnPremise installations soon, many customers are looking for alternatives. Resourcecloud is being developed by a German company and is hosted completely in German datacenters. So from a DSGVO standpoint all Resourcecloud customers are save.

  • iPhone Thumbnail
  • New Tutorial Video Online

    29. July 2020 | B. Jannedy

    We have just uploaded the first tutorial video on how to use Resourcecloud. You find the first episode here.

    In the first episode we focus on the user interface and some basic principles. In the following videos, we will explain more advanced features like Virtual Teams, Scrum, workflows and much more.

    This is the beginning of a complete tutorial video series on working with Resourcecloud and getting the best out of it. In fact when you just work with it, it’s really easy to work with that tool. Just log in and work on the tasks with the highest value. If you don’t have anymore tasks, go to the taskpool and grab one. That’s all. For the rest will be taken care of by Resourcecloud… easy, isn’t it?

    You can find the video >> here <<.

  • iPhone Thumbnail
  • Arbeitsorganisation: Mensch versus Maschine

    11. July 2018 | B. Jannedy

    Mit aller Macht und ohne übergreifendes Konzept zu digitalisieren, führt im seltensten Fall zu den erhofften Zielen. Warum in Prozessen der Arbeitsorganisation Verlässlichkeit vor Geschwindigkeit steht.

    In den letzten Tagen gab es öffentlichkeitswirksame Beispiele, warum planlose oder erzwungene Digitalisierung „von oben“ nicht funktioniert. „Missglückte Digitalisierung bei Cali Burger“ titelte jüngst WELT Online. Die Fastfood-Kette hatte den Flippy genannten Roboter an den Grill gestellt. Dort sollte er Bestellungen entgegennehmen, Fleisch-Patties wenden und diese auf vorbereitete Burger legen. Bis zu 150 Burger in der Stunde sollte er so produzieren. Soweit zur Theorie. In der Praxis scheiterte Flippy daran, dass zu viele seiner Kollegen ihm umständlich zuarbeiten mussten – dazu gehörte auch das millimetergenaue Ausrichten der Brötchen, da sonst der Bratling daneben geht. Zudem mussten alle Kollegen ihren Arbeitsrhythmus vollständig auf den Roboter ausrichten, anstatt sich wie bisher dynamisch untereinander abzustimmen. 50 Mitarbeiter sollte Flippy ersetzen, stattdessen suspendierte die Unternehmensleitung ihn schon nach seinem ersten Arbeitstag.

    Ein anderes Bespiel lieferte Elon Musk – einer der aktuell prägendsten Technologie-Persönlichkeiten. Nach wie vor läuft die Produktion seines neuen Tesla-Modells nur stockend. Nun räumte Musk ein, zu sehr auf Automatisierung und Roboter gesetzt und dabei die Menschen unterschätzt zu haben. Zudem seien zu viele Technologien auf einmal in den Herstellungsprozess gepackt worden.

    ARBEITSORGANISATION

    Solche Fälle zeigen, dass es nicht reicht, wenn Unternehmen blindlings Softwarelösungen und Roboter einsetzen oder Abläufe automatisieren ohne die daran gebundenen Mitarbeiter und Prozesse zu berücksichtigen. Digitalisieren allein um der Digitalisierung Willen ist nicht zielführend. Ein holistischer Ansatz ist notwendig, der die gesamte Produktions- und Prozesskette umfasst. Nur weil ein Baustein davon schneller abläuft, muss am Ende nicht zwangsläufig der Output größer sein. Für eine erfolgreiche Digitalisierung müssen Unternehmen ihre Prozess- und Technologielandschaft genauso betrachten wie die Bedürfnisse ihrer Mitarbeiter und die eigene Firmenkultur.

    Heute erfolgt die Erbringung von Leistungen und Ergebnissen (Businessvalue) niemals durch eine Person alleine. Nahezu immer sind mehrere Personen oft sogar mehrere Teams, manchmal sogar mehrere Firmen an der Leistungserbringung beteiligt. Die meisten Verluste (Zeit und Ergebnisse) entstehen bei der Übergabe von einer Instanz zur nächsten. Man kann nicht davon ausgehen, dass eine Instanz sofort nahtlos nach der Übergabe weiterarbeiten kann, weil zeitgleich in diesem Team auch andere Arbeiten anliegen die um die verfügbaren Ressourcen ringen. Man muss sich die Leistungserbringung wie eine Maschine mit vielen Zahnrädchen vorstellen. In diesem Gedankenspiel wird deutlich, dass die Maschine nicht schneller wird, wenn sich nur eines der Rädchen plötzlich schneller dreht.

    STAFFELLAUF UND ABLÄUFE

    Die von einer Instanz zur nächsten übergebene Arbeit muss stattdessen rechtzeitig eingeplant werden, damit darauffolgende zuliefernde Einheiten wissen wann der nächste Arbeitsschritt auf sie zukommt und sie ihrerseits die Arbeit einplanen und Ressourcen für die Abarbeitung einplanen können. Diese Arbeitsplanung ist nicht einfach, weil die Dauer komplexer Arbeiten und damit das Fertigstellungs- und damit das Übergabedatum and die nächste Einheit in der Prozesskette nicht immer exakt vorhersehbar sind. Das ist nur dadurch zu lösen, dass man die zuliefernden Einheiten planerisch nicht zu hundert Prozent auslastet sondern Freiraum für mögliche Verzögerungen schafft. Was man unbedingt vermeiden muss ist die Terminzusage für die Übergabe an die nächste Einheit zu reissen.

    UMPLANUNGEN

    Das führt dann nämlich zu einer Folge von massiven kurzfristigen Umplanungsnotwendigkeiten entlang der gesamten Leistungserbringungskette mit damit entstehenden Kosten und es folgt eine ineffiziente Abarbeitung bzw. Stress bei den Mitarbeitern. Wenn ich z.B. eine Infrastruktur nicht zum avisierten Termin bereitstellen kann sitzen ggfs. mehrere Entwicklerteams die bezahlt werden müssen da und können nicht arbeiten. Das führt dazu, dass ein Softwarefeature nicht rechtzeitig fertig wird und Kunden umplanen müssen die dadurch wiederum Kosten haben. Um diese Kausalkette zu vermeiden muss man die Zusageverlässlichkeit von Übergabeprodukten an den Schnittstellen der Zuliefereinheiten vor die Liefergeschwindigkeit stellen. Mit „Time-to-Market“ ist die Fähigkeit zur schnellen Lieferung der gesamten Prozesskette gemeint und nicht die einzelner Einheiten.

    Nur wie kann man die Zusageverlässlichkeit innerhalb der Prozesskette verbessern? Es gibt praxiserprobte Wege und Möglichkeiten dazu. In einem folgenden Blogbeitrag werde ich vorstellen, wie ResourceCloud dabei helfen kann.

  • Scrum is inflexible

    11. July 2018 | B. Jannedy

    Situation

    Most developers are using a scrum based development process. I wonder why, because it’s definitely not well suited for DevOps teams. Let me tell you why! With Scrum, you commit your team to fullfill a defined and agreed amount of stories within the upcoming sprint due to the sprint planning. Your business owner and the sprint team agree on the commitment. It is based on the calculated or estimated team velocity. So far so good. But what happens in real life?

    Real Life

    During a sprint, a super critical bug comes in and has to be solved, which eats up the storypoints that where planned for anything else. Or one of your team members gets ill. So you can’t bring those advertised storypoints to the street. Or a competitor releases a feature that is a game changer and has to be implemented as well, or your customer / BO suddenly changes his mind about a feature which leads to massive refactoring, or… you get the point.

    You could fight these things by not assigning all available storypoints to a sprint and keep headroom for unforeseen incidents. That’s what you can do with the virtual team feature of ResourceCloud. But in fact, scrum is not well suited in those agile environments. We tend to list all stories in the backlog and dynamically change the priorities of them as long as they are in the backlog. We got rid of the sprint rhythm, because it introduces long reaction times. So to keep track of when a feature or story will be finished, ResourceCloud dynamically recalculates the possible finishing week / day of a story continuously. So you always have a good estimation on when a feature/ bugfix/ story will be ready for production.

  • iPhone Thumbnail