Praxis vs. Prozess: Was ist der Unterschied?

Praxis vs. Prozess: Was ist der Unterschied?

  • ITOps & DevOps
6 Minuten Lesezeit Aktualisiert Sep 8, 2020

Auf einen Blick: Das Verständnis des Unterschieds zwischen Praktiken und Prozessen ist in der Unternehmens-IT entscheidend. Praktiken konzentrieren sich auf kontinuierliche Verbesserung, während Prozesse strukturierte Schritte sind, um spezifische Ziele zu erreichen, die jeweils einzigartig zu Effizienz und Agilität beitragen.

  • Praktiken fördern kontinuierliche Weiterentwicklung und umfassen mehrere Prozesse.
  • Prozesse bestehen aus starren Abfolgen, die auf bestimmte Ziele abzielen.

Wir verwechseln manchmal die Begriffe Praxis und Prozess, aber sie sind unterschiedlich. Oft sind Praktiken und Prozesse eng miteinander verbunden. In der Unternehmens-IT, im Mittelpunkt dieses Artikels, bauen viele Praktiken auf einzelnen Prozessen auf. Schauen wir uns das an.

Was ist ein Prozess?

Die Unternehmens-IT-Branche ist im Allgemeinen der Meinung, dass der Prozess die Grundlage ist, also fangen wir damit an. Prozesse beziehen sich darauf, wie man Dinge erledigt: die Schritte von Punkt A nach Punkt B. Der Prozess kann aus ein paar einfachen Schritten bestehen, um ein bestimmtes Ergebnis zu erreichen. Oder ein Prozess kann eine Abfolge oder mehrere Ebenen von Abläufen haben, die Menschen, Technologie, Strategien und Governance umfassen. In jedem Prozess sind die Schritte aus gutem Grund starrer: Sie können sich also selbst durch die Schritte führen. Die Intelligenz des Prozesses – wie etwas erledigt wird – ist nicht in einer Person, sondern direkt im Prozess verankert. In der Unternehmens-IT folgt man oft einem Prozess , um etwas zu erledigen. Zum Beispiel nehmen wir die Serviceerstellung und -bereitstellung. Sie müssen den Service entwerfen, dann bauen und schließlich liefern. Jeder Schritt erfordert jedoch möglicherweise keinen expliziten Prozess:

  • Einen Service erfinden. Vielleicht brauchst du keinen Prozess, um einen Service zu erfinden oder zu erstellen, oder die Idee für einen Service. Dein Ansatz könnte kreativer sein – eine Idee, die dir mitten in der Nacht gekommen ist – oder agil, bei dem du die Lücken in deinen aktuellen Produkten siehst. Eine bestimmte Anzahl von Schritten führt nicht zu Innovation oder garantiert nicht. (Wenn es so einfach wäre, würden wir es alle machen!)
  • Einen Service aufbauen. Sobald Sie den Service entworfen haben, müssen Sie ihn selbst bauen oder herstellen. Dieses Teil könnte von einem Prozess abhängen – Schritte, die in einer bestimmten Reihenfolge ausgeführt werden müssen. Oder, je nach Umgebung, braucht es vielleicht nicht viel Prozess.
  • Erbringung eines Services. Es ist wahrscheinlich, dass die Art und Weise, wie Sie einen Service erbringen, einem oder mehreren Prozessen folgt, die erledigt werden müssen, damit die Endnutzer diesen Prozess empfangen und nutzen können. Hier sind Prozesse entscheidend für eine effiziente Servicebereitstellung und für die Erhöhung des Skalierens.

Das Ende eines Prozesses

Ein Unterscheidungsmerkmal eines Prozesses ist, dass er ein Ende hat. Ein Prozess gilt im Allgemeinen als abgeschlossen, wenn man das Ziel des Prozesses erreicht hat.

Was ist eine Praxis?

Eine Praxis ist ganzheitlicher und umfassender als jeder einzelne Prozess. Eine Praxis ist das fortlaufende Verfolgen eines Ziels oder Interesses – und es ist in der Regel etwas, das Sie kontinuierlich verbessern oder optimieren möchten. Schließlich verwenden wir den Begriff Best Practice, nicht Best Process. Best Practice ist etwas, das eine Branche im Allgemeinen als den effektivsten Weg zur Erreichung von etwas ansieht. In der Enterprise IT sind Practices jene Aktivitäten, die Sie stets effektiver und effizienter gestalten möchten. Diese Bereiche bestehen weiter aus vielen Praktiken – einige sind erforderlich, viele optional. Je nach Organisationsstrategie und -struktur werden diese Bereiche meist als Praktiken betrachtet – viel größer als Prozesse – und sie werden oft direkt in zusätzliche Teilpraktiken unterteilt:

In jeder Praxis sitzt die Intelligenz meist bei einer Person oder einem Team: der Person/dem die Praxis gehört oder die Expertise in der Praxis ist. Diese Person kann eine Vielzahl von Prozessen in ihrem Experten-Werkzeugkasten nutzen, um sicherzustellen, dass die Praxis das tut, wofür sie gedacht ist. Ebenso kann diese Person entscheiden, welche Prozesse die übergeordnete Praxis nicht mehr unterstützen. Der Ausdruck "Übung macht den Meister" fasst es perfekt zusammen – wir üben regelmäßig etwas, um besser darin zu werden. Im Gegensatz dazu ist ein Prozess perfekt, wenn er die eine Aufgabe erfüllt, die er eigentlich erfüllen sollte.

Das Ende einer Praxis

Das Ende der Praxis ist schwerer zu messen. Wo Prozesse klare Anfänge und Enden haben, sind Praktiken fortlaufend und umfassend und bestehen aus einer Vielzahl von Prozessen. Deshalb basieren Praktiken auf Kennzahlen – um zu messen, wie unsere Praxis funktioniert:

  • Qualität
  • Agilität
  • Einhaltung
  • Agilität
  • Weitere Bedürfnisse

Im Grunde musst du eine Praxis auf eine quantifizierbare Weise messen, um zu wissen, dass deine Praxis funktioniert – dass du dich in diesem Bereich verbesserst.

Beispiele für Praktiken

Beispiele für unternehmensinterne IT-Praktiken sind:

Prozess vs. Praxis: IT-Beispiele

Schauen wir uns einige gängige Technologiebereiche an und wie sie mit Prozessen und Praktiken umgehen.

ITIL

Das führende Service-Management-Framework, ITIL® , wurde traditionell in verschiedene Praktiken unterteilt. Mit der Veröffentlichung von ITIL 4 im Jahr 2019 reagierte ITIL auf Kritik, dass es sich nicht modernisierte oder mit dem digitalen Zeitalter nicht Schritt hielt. Diese neueste Version hörte tatsächlich auf, den Begriff "Prozess" zu verwenden, zugunsten von "Praxis", ein Schritt, den viele ITSM-Profis loben. Wie Kirstie Magowan erklärt:

"In Wirklichkeit... "Prozesse" war in ITIL v3 und früheren Iterationen ein irreführender Begriff. Als wir zum Beispiel über den Incident-Management-Prozess sprachen, sprachen wir nie von einem einzelnen Prozess. Stattdessen sprachen wir von einer Gruppe von Prozessen und Fähigkeiten, die es uns ermöglichten, Vorfälle effizient zu managen. ITIL 4 hat all diese Facetten zusammengeführt und es als Praxis bezeichnet. Für mich ergibt das vollkommen Sinn."

Agile

Ursprünglich als Reaktion auf traditionelle Softwareentwicklungsmethoden, können die Prinzipien und Werte der agilen Methodik auf die Entwicklung sowie andere IT- und Geschäftsbereiche im weiteren Sinne anwendbar sein. Die agile Methodik behandelt Praktiken und Prozesse auf ähnliche Weise:

  • Prozesse sind klar definierte Schritte, die ein vorhersehbares Ergebnis erzielen.
  • Praktiken sind Aktivitäten, die eine Vielzahl von Prozessen umfassen können.

Ein Prozess ist eine Reihe klar definierter, wiederholbarer Schritte mit vorhersehbaren Ergebnissen. Hier ist das gesamte Wissen, das Sie für die jeweilige Aufgabe benötigen, in den Prozess eingebettet – Sie müssen sich nicht auf Ihre eigene Erfahrung oder Ihr Wissen verlassen. Agile Praktiken hingegen sind individuelle Aktivitäten, die agile Prinzipien und Werte umsetzen. Im Großen und Ganzen schreibt die agile Methodik keine expliziten Praktiken vor (im Gegensatz zu ITIL). Stattdessen überlassen sie die Einzelheiten den Einzelpersonen, die sie zum Funktionieren bringen, basierend auf agilen Prinzipien und basierend auf Wissen, Erfahrung und Bedarf. Agile sieht Praxis vs. Prozess eher als ein Kontinuum: klar definierte Prozesse auf dem einen Ende, lose definierte Praktiken auf dem anderen.

Prozesse und Praktiken: Wie viele sind genug?

Wenn Sie Schwierigkeiten haben, Dinge zu erledigen, fragen Sie sich vielleicht, ob Sie mehr oder bessere Prozesse oder Praktiken benötigen. In den meisten Organisationen ist es eine Frage des Grades: Sie brauchen einige, aber nicht zu viele. Prozesse und Praktiken sind nur dann nützlich, wenn sie Ihrem Unternehmen einen gewissen Wert bieten. Nicht alles muss ein Prozess oder eine Praxis sein. Manche Aufgaben, Aktivitäten und Ziele können einfach erreicht werden, abhängig von:

  • Die bevorstehende Aufgabe
  • Die beteiligten Personen

Überlegen Sie, für welche Art von Arbeit Sie verantwortlich sind. Was ist der Zweck? Ist die Arbeit starr oder offener? Wenn Sie ein Rechenzentrum rund um die Uhr leiten, das wiederholbare Aktionen für ein garantiertes Ergebnis erfordert, könnten Sie eines von zwei Dingen tun:

  • Vertrauen Sie darauf, dass Ihr Personal sich an alle Aufgaben erinnert, die sie erledigen müssen.
  • Führen Sie wiederholbare Aktionen und Prozesse ein, die eine hohe Verfügbarkeit garantieren.

Hier können Prozesse und Praktiken den Erfolg unterstützen. Aber andere Bereiche benötigen möglicherweise nicht dieses Maß an Detailgenauigkeit und Mikromanagement. Eine allgemeine Faustregel:

  • Prozesse und Praktiken können hochstarre Arbeit unterstützen, wie IT-Betrieb, einschließlich Infrastruktur und Netzwerk.
  • Prozesse und Praktiken können agilere, offene Arbeit behindern, wie Servicedesk-Support und Software-/Anwendungsentwicklung.

Auf dem Weg zur Größe

Mit unnötigen Prozessen und Praktiken verbunden zu sein, macht einen bürokratischer – einen Prozess um des Prozesses willen zu machen. (Das erkennt man, wenn man von zu viel Mikromanagement hört oder sieht.) Die Auswirkungen davon sind negativ:

  • Wenig bis keine Agilität
  • Minimale Kreativität und Innovation
  • Längere Markteinführungszeit

In Good to Great erläutert Jim Collins, wie die Anzahl der Praktiken und Prozesse, die Sie benötigen, in der Kompetenz und Disziplin Ihres Teams abhängt:

"Bürokratie... kompensiert Inkompetenz und mangelnde Disziplin."

Die erfolgreichsten Prozesse und Praktiken müssen für jeden, der kommt und einen Teil von ihnen berührt, explizit festgelegt werden. Insbesondere neue Mitarbeiter profitieren von Prozessen. Aber Prozesse und Praktiken haben einen Overhead. Das Management jedes Prozesses und jeder Praxis wird zur Arbeit an sich: Menschen, die sie managen, sicherstellen, dass sie funktionieren, sie ändern, wenn sie aufhören zu arbeiten, usw. Es ist wahrscheinlich, dass mindestens eine Person jeden Prozess oder jede Praxis besitzt oder dafür verantwortlich ist. Dieses Problem wird jedoch verschwinden, sobald Sie die richtigen Talente in Ihrem Unternehmen haben. Die richtigen Personen können Arbeit erledigen, ohne sich auf jede einzelne Regel zu verlassen – sie verstehen das Endziel und wissen, wie ein Prozess oder eine Praxis ihnen helfen oder schaden kann, dieses Ziel zu erreichen. Und da Sie die Regeln kennen, sehen Sie Bereiche mit Verschwendung, die nicht mehr notwendig sind. Nutzen Sie diese Möglichkeiten, um zu innovieren oder etwas effizienteres zu gestalten.

Übung macht den Meister

Am Ende des Tages wirst du wahrscheinlich einige Prozesse und Praktiken entwickeln, sei es natürlich oder bewusst. Prozesse und Praktiken selbst sind weder gut noch schlecht – sie sind einfach mehr oder weniger hilfreich, je nachdem:

  • Industrie
  • Organisationsstruktur und Strategie
  • Menschen und Talente
  • Produkte
  • Ressourcen

Sowohl Praktiken als auch Prozesse sollten das System ermöglichen, nicht zum System werden. Diese Aktivitäten sind nicht das Endziel – sie sollten Ihnen nur helfen, das Endziel zu erreichen. Wenn ein neuer Prozess nützlicher wird, wenden Sie sich darauf um.

Zusätzliche Ressourcen

Für mehr Informationen zur IT-Strategie entdecken Sie diese Ressourcen:

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus ITOps & DevOps

Abonnieren Sie The Brief

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Danke

Sie haben The Brief abonniert
Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.