Bücherregale in Bibliothek

Kernkompetenzen?

Wo sind Ihre? Was passiert, wenn Sie mit Externen zusammenarbeiten?

Lesezeit 5 min

Kernkompetenzen, bzw. deren Erhalt und Schutz sind immer wieder ein Thema, wenn Firmen mit externen Entwicklungsdienstleistern zusammenarbeiten. "Kernkompetenzen" ist sehr leicht daher gesagt. Ich glaube aber, dass das Thema einige vertiefte Gedanken verdient:

Was sind eigentlich Kernkompetenzen?

Kernkompetenzen sind die Fähigkeiten, das Handlungswissen, welches Sie von den Konkurrenten unterscheidet, welches sich nicht leicht substituieren lässt. Mit diesen "distinktiven" Kompetenzen erzeugen Sie Wert für Ihre Kunden, Sie differenzieren sich und machen sich für Ihre Kunden schwer ersetzbar.

Die meisten Firmen können relativ schnell ihre Kernkompetenzen benennen. Aber wo sind diese in einer Organisation überhaupt zu finden?

Wo sind die Kernkompetenzen?

Um zu sehen, wo in einer Organisation die Kernkompetenzen vorkommen, ist es wichtig zu bedenken, dass es sich um Handlungswissen handelt, d.h. darum, wie man etwas tut, nicht nur um theoretisches Wissen an sich.

Und wo sind diese Kompetenzen nun?

  • Bei den Schlüsselmitarbeitern? Der Service weiss es?
  • Der Chef weiss es? Der Gründer wusste es mal?
  • Im Quellcode unserer Software? In den Elektro- und Elektronikschemas?
  • In den Maschinen, Messgeräten und Tools?
  • In unserem Sharepoint? In der Inbox?

Oder müssten sie auch bewusst erzeugt werden?

  • In Produktarchitekturen auf dem neusten Stand?
  • In aktuellen Lastenheften, technischen Architektur- und Designdokumenten?
  • In Prozessen, Checklisten und Vorlagen? Als "Organisations-Wissen"?

Es gibt also implizite und explizite Kernkompetenzen, persönliche und kollektive. Grundsätzlich lassen sich vier Varianten von Kernkompetenzen, von Wissen unterscheiden.

Was sind die Vor- und Nachteile dieser Varianten?

  • Persönliches Wissen: Jemand weiss es
    • Vorteile:
      • Das Wissen kann sehr einfach angezapft werden, wenn man danach fragt.
      • Das Wissen ist einfach da, es entsteht kein Zusatzaufwand für die Ablage oder Pflege des Wissens.
    • Nachteile:
      • Wie findet man heraus, wer was weiss?
      • Was passiert, wenn dieser jemand die Firma verlässt?
  • Organisationswissen: In Prozessen ("Qualitäts-Managementsystem"), Checklisten und Vorlagen
    • Vorteile:
      • Das Erfahrungswissen ist explizit vorhanden, v.a. wenn man die z.B. Checklisten jedes Mal aufdatiert, wenn ein Fehler passiert ist oder sich sonst neue Erkenntnisse ergeben.
    • Nachteile:
  • Architekturen: In Produktarchitekturen und technischen Architektur- und Designdokumenten
    • Vorteile:
      • Die Information darüber, wieso was gemacht wurde, ist explizit vorhanden.
    • Nachteile:
      • Die Dokumente müssen erstellt und gepflegt werden, was in der Hitze des Gefechts nicht immer die erste Priorität hat.
  • Arbeitsresultate: Im Quellcode, in Schema-und Layoutunterlagen, in Produktions- und Konstruktionsunterlagen
    • Vorteile:
      • Diese Daten werden sowieso erzeugt, also ergibt sich kein Zusatzaufwand für die Erzeugung und Speicherung.
    • Nachteile:
      • Stehen dort wirklich die wichtigen Informationen? Es steht was gemacht wurde, meist aber nicht wieso. Diese Unterlagen lassen ohne zusätzliche Angaben viel Interpretationsspielraum und benötigen viel Zeit für die Aufarbeitung. D.h. wenn wir etwas ändern oder etwas Neues entwickeln wollen, wie wissen wir, welche Lösungen wirklich wichtig sind, und welche einfach gewählt wurden, weil es nicht darauf ankam?

Kernkompetenzen und Externe

Was passiert mit Ihren Kernkompetenzen, wenn Sie mit Externen zusammenarbeiten? Ist der Weg, Freelancer im Team zu haben wirklich die beste Variante zur Sicherung der Kernkompetenzen? Sind Sie sicher, dass diese auch Architekturen und Organisationswissen erzeugen? Oder bleiben nur Arbeitsresultate und am letzten Tag verlässt das persönliche Wissen die Firma zusammen mit dem Mitarbeiter?

Wie bleiben die Kernkompetenzen erhalten?

Das Problem der fehlenden Bewahrung, des fehlenden Schutzes zeigt sich meist zu spät. Wenn z. B. Unternehmen verkauft werden und wichtige Mitarbeiter das Unternehmen aus "Integrationsgründen" verlassen, bedeutet das , dass das gesamte Wissen weg ist. Oder wenn der Ingenieur in Pension geht, der die Architektur des ganzen Produktes bestimmt hat. Dann weiss niemand mehr, wieso die Software funktioniert und weshalb sie so und nicht anders codiert sein muss.

Der Schutz des gespeicherten Wissens und der Arbeitsresultate wird meist durch einen Risikomanagement-Ansatz (lines of defense etc.) gesteuert. Das ist notwendig, meiner Meinung nach jedoch nicht hinreichend, da sich nur die wenigsten Organisationen im Risikomanagement die Frage stellen, ob alles, was schützenswert wäre, auch wirklich irgendwo aufgeschrieben ist.

Was wäre dann ein sinnvoller Schutz?

Disclaimer: ein solches Vorgehen ist eher mühsam und daher nicht für jede Organisation geeignet.

  1. Kernkompetenzen identifizieren
  2. Herausfinden, wo diese eigentlich abgespeichert sind
    • Prozesse/ Vorlagen/ Checklisten: Sofern diese eine gewisse Maturität haben, d.h. es gibt aufgeschriebene Prozesse, die nicht nur ISO 9001 Auditoren gezeigt, sondern gelebt werden.
      Das gibt auch eine neue Perspektive zur Prozesserstellung: die Maturität sollte nicht da hoch sein, wo es einfach ist (für die es z.B. im Internet Vorlagen oder von Beratern Standards gibt), sondern da, wo die Kernkompetenz liegt. Die ist per Definition distinktiv, d.h. sie kann nicht gleich wie in anderen Organisation über dieselben Vorlagen oder ERP Module abgebildet werden.
    • Weiterentwicklung: Die Prozess-Assets werden aus dem Wissen der Betroffenen und dem aus den Projekten weiterentwickelt.
    • Produktarchitektur: Wenn diese sinnvoll (mit einer gewissen Maturität) dokumentiert ist, d.h. es gibt eine überschaubare Anzahl lesbarer und strukturierter (gemäss Prozessen) Dokumente für jede Produktgruppe, nicht nur einen Tickethaufen oder ein undurchsichtiges Wiki oder Sharepoint Repository, in dem man sich nur dank der Suchfunktion zurechtfindet.
    • Pflege: es gibt eine sinnvolle Pflege aller Dokumente ("Knowledge Management") über die Produktlebensdauer.
  3. Die Erstellung von Prozess-"Assets" und Architekturdokumenten da priorisieren, wo sie noch fehlen, bzw. nur als persönliches Wissen in den Köpfen vorhanden sind.

Dies schliesst auch den Kreis zur Zusammenarbeit mit Externen: Wählen Sie einen Partner, der das geistige Eigentum auch als detaillierte Pflichtenhefte und strukturierte Architekturdokumente liefert, und von dessen Erfahrungswissen Sie in Checklisten und Vorlagen profitieren können.

Ohne Lock-In können Sie ein Ingenieurbüro auch an Ihren Kernkompetenzen arbeiten lassen, Sie bekommen dann alles Wissen, alle Kernkompetenzen, die keine Beine haben, nämlich Arbeitsresultate, Architekturen und sogar zusätzliches Organisationswissen. Und wenn das Ingenieurbüro langjährige Mitarbeiter hat, dann bleibt sogar der Zugriff auf das Wissen in den Köpfen erhalten....

Andreas Stucki

Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!

Autor

Fragen & Kommentare

Keine Kommentare

Haben Sie zusätzliche Fragen?

* Diese Felder sind erforderlich

Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!