Technischer Artikel
Wann lohnt es sich, einen AutoCAD-Ablauf zu automatisieren?
Praktische Kriterien, um einen geeigneten Ablauf zu erkennen und seine Regeln zu erfassen.
Ein wiederkehrender Arbeitsablauf kann wie ein offensichtlicher Kandidat für Automatisierung wirken. Wiederholung allein bedeutet jedoch nicht, dass die Entwicklung eines Werkzeugs die beste Entscheidung ist.
Bevor AutoLISP, C#/.NET oder eine andere Technologie gewählt wird, sollte geprüft werden, ob der Prozess erkennbare Eingaben, ausreichend stabile Regeln, verstandene Ausnahmen und ein überprüfbares Ergebnis hat.
Mit dem Prozess beginnen, nicht mit dem Werkzeug
Eine nützliche Bewertung macht aus einer allgemeinen Sorge eine beobachtbare Abfolge. Dieser Ablauf trennt das Problem von der technischen Entscheidung:
- 01
Beobachtetes Problem
- 02
Aktueller Prozess
- 03
Eingaben
- 04
Regeln
- 05
Ausnahmen
- 06
Erwartete Ausgabe
- 07
Abnahmekriterien
- 08
Technische Entscheidung
Signale für einen geeigneten Automatisierungskandidaten
Automatisierung ist meist sinnvoller, wenn mehrere dieser Signale gemeinsam auftreten:
- Die Aufgabe tritt häufig genug auf, um Entwicklung, Bereitstellung und Wartung zu rechtfertigen.
- Erforderliche Eingaben können vor der Ausführung identifiziert und geprüft werden.
- Die Regeln sind stabil, dokumentierbar und dem Prozessverantwortlichen bekannt.
- Die wichtigsten Ausnahmen sind bekannt und haben eine definierte Behandlung oder einen sicheren Haltepunkt.
- Die erwartete Ausgabe kann mit objektiven Abnahmekriterien verglichen werden.
- Jemand ist für die Validierung von Prozessänderungen und die Pflege der Regeln verantwortlich.
Signale für eine Pause vor der Entwicklung
In manchen Situationen ist es wichtiger, die Routine zu ordnen, als sie sofort zu automatisieren:
- Der Prozess ändert sich bei jeder Ausführung oder hat keine abgestimmte Reihenfolge.
- Relevante Ausnahmen sind nicht verstanden oder erscheinen erst bei der Abschlussprüfung.
- Die Tätigkeit ist selten, und die Wartung eines Werkzeugs kann mehr kosten als seine Nutzung.
- Die Entscheidung hängt von technischem Ermessen ab, das noch nicht in eine überprüfbare Regel überführt wurde.
- Erfolg, Fehler und akzeptable Ausgabe sind nicht klar definiert.
- Häufige Änderungen an Standards, Teams oder Systemen könnten die Lösung schnell veralten lassen.
Den Arbeitsablauf vor der Entwicklung abbilden
Für das erste Gespräch ist keine Zeichnung und keine vertrauliche Datei erforderlich. Eine strukturierte Beschreibung kann das Problem bereits definieren:
- Einen repräsentativen Fall auswählen und angeben, wo der Ablauf beginnt und endet.
- Die Eingaben und ihre jeweilige Herkunft auflisten.
- Die Regeln in der Reihenfolge ihrer Anwendung festhalten.
- Bekannte Ausnahmen, menschliche Entscheidungen und sichere Haltebedingungen trennen.
- Die erwartete Ausgabe und ihre Überprüfung definieren.
- Kriterien für Abnahme, Bereitstellung, Wartung und Verantwortung für Änderungen festlegen.
Synthetisches Beispiel
Synthetisches Beispiel: Layer-Namen prüfen
Demonstrationsbeispiel mit synthetischen Namen und Regeln. Es stellt weder einen Kunden noch eine reale Zeichnung, eine AutoCAD-Ausführung oder ein bereitgestelltes Werkzeug dar.
Betrachten wir die Prüfung von Layer-Namen vor der Ausgabe einer Zeichnung. Das Beispiel kann beschrieben werden, ohne zu behaupten, dass bereits eine Automatisierung existiert:
- 01
Bekannte Eingabe
Eine synthetische Liste mit Namen wie „ARQ PAREDE“, „cotas-01“ und „Texto Geral“ ist verfügbar.
- 02
Explizite Regeln
Überflüssige Leerzeichen entfernen, Trennzeichen normalisieren und das Präfix mit einer genehmigten Liste vergleichen.
- 03
Erkannte Ausnahmen
Reservierte Layer, externe Referenzen und vertraglich festgelegte Namen gehen in die menschliche Prüfung.
- 04
Überprüfbare Ausgabe
Jede Eingabe wird gemäß den Regeln der erwarteten Ausgabe zugeordnet, während Ausnahmen separat aufgeführt werden.
Was dieses Beispiel nicht zeigt
- Das Beispiel ordnet eine mögliche Transformation; es demonstriert kein Plugin, Skript oder ausgeführten Befehl.
- Es belegt weder Bereitstellung, Produktivität, Einsparungen, Produktionsstabilität noch Fehlerreduzierung.
Die Technologie nach der Bewertung wählen
AutoLISP kann für manche Routinen nahe an der Zeichnungsumgebung geeignet sein. C#/.NET kann sinnvoll sein, wenn der Umfang Schnittstellen, größere Strukturen, Integrationen oder besondere Anforderungen an Bereitstellung und Wartung umfasst.
Keine der beiden Optionen ist allgemein besser. Die Wahl hängt vom erforderlichen Verhalten, den Umgebungsbedingungen, der Verteilung, den Integrationen und der zuständigen Unterstützung ab.
Eine kurze Checkliste zur Beschreibung des Bedarfs
Für eine erste Bewertung sollten diese Punkte beschrieben werden, ohne DWG-Dateien, Zeichnungen oder vertrauliche Informationen anzuhängen:
- Wie häufig tritt der Ablauf auf und wer ist beteiligt?
- Wie sehen die aktuellen Schritte, Eingaben und Datenquellen aus?
- Welche Regeln sind dokumentiert und wer kann sie validieren?
- Welche Ausnahmen erfordern menschliches Ermessen oder einen sicheren Stopp?
- Was ist das erwartete Ergebnis und wie kann es geprüft werden?
- Welche Einschränkungen für Umgebung, Bereitstellung und Wartung sind bereits bekannt?
Noch nicht zu automatisieren kann ebenfalls eine gute Entscheidung sein
Wenn der Prozess noch instabil ist, kann es sinnvoller sein, Regeln zu dokumentieren, Variationen zu reduzieren und Abnahmekriterien zu definieren. Das verringert Unklarheiten und schafft eine sicherere Grundlage für eine spätere Entscheidung.
Eine verantwortungsvolle Bewertung setzt nicht voraus, dass Automatisierung zwingend erforderlich ist. Sie vergleicht Bedarf, Grenzen und Erhaltungskosten der Lösung mit dem erwarteten Ergebnis in diesem Kontext.