EInfachste Praktikantenarbeit

die sache mit dem "automatisieren" ist nur die, dass man dabei zwangsläufig vor dem problem steht gleichzeitig sowohl so viele fälle wie möglich zu erfassen, als auch noch so präzise wie möglich.

die realität haut da leider immer wieder gerne mit einem großen "f*ck you" gegen und leider sind "automatisierte abläufe" oft besonders zeitaufwendig für's personal (eben weil etwas passiert oder zu tun ist, dass die programmierer nicht vorausgesehen haben)
 
Nun ja.ich glaube, wir denken da an verschiedene Fälle bzw. Abläufe. Die Abläufe an die ich denke, die sind doch eher ziemlich low Level. Da gibt es nicht so viel Spielraum. Und doch ist man oft damit konfrontiert. Eine Freundin von mir musste im Zuge ihres Praktikums zum Beispiel Tag ein Tag aus Apps in den Google App Store hochladen.
 
Eine Freundin von mir musste im Zuge ihres Praktikums zum Beispiel Tag ein Tag aus Apps in den Google App Store hochladen.

Dann fehlt in dem Unternehmen aber lediglich ein brauchbarer System Engineer. Denn gerade dieses Problem können moderne Build-Tools bereits völlig automatisiert lösen. Du siehst also, dass es nicht immer nur mit "mal schnell 'nen Skript dafür machen" getan ist. Oftmals müssen einfach nur die vorhandenen Tools korrekt eingesetzt werden oder bereits verfügbare Tools in den Arbeitsablauf integriert werden. Und um solche Tools zu kennen und einsetzen zu können, bedarf es Erfahrung in den Abläufen des Unternehmens, in typischen Abläufen bestimmter Produktionsschritte (z.B. in der Software-Entwicklung der Build-Schritt) uvm.. Und an dem Punkt kommen dann Prozessoptimierer in's Spiel. Die fangen nicht einfach wild an zu automatisieren sondern machen Workflow-Diagramme usw. um die Abläufe in ihrer Gänze zu verstehen. Und dann setzen sie sich mit entsprechenden Fachleuten (Sysadmin, System Engineers, Software-Entwickler usw.) zusammen und arbeiten ein Konzept aus, das wirklich Prozesse optimiert und nicht im Endeffekt nur Teile automatisiert, die ggf. irgendwann gegen die Wand laufen, weil irgendein Arbeitsablauf, der nur alle paar Monate mal auftritt, nicht bedacht wurde.

Daher mein Tipp: Wenn du unbedingt automatisieren und dich dabei auf die technische Seite konzentrieren willst, tu dich mit Prozessoptimierern zusammen. Die suchen häufig mal jemanden, der die technische Umsetzung macht.
 
Dann fehlt in dem Unternehmen aber lediglich ein brauchbarer System Engineer. Denn gerade dieses Problem können moderne Build-Tools bereits völlig automatisiert lösen. Du siehst also, dass es nicht immer nur mit "mal schnell 'nen Skript dafür machen" getan ist. Oftmals müssen einfach nur die vorhandenen Tools korrekt eingesetzt werden oder bereits verfügbare Tools in den Arbeitsablauf integriert werden. Und um solche Tools zu kennen und einsetzen zu können, bedarf es Erfahrung in den Abläufen des Unternehmens, in typischen Abläufen bestimmter Produktionsschritte (z.B. in der Software-Entwicklung der Build-Schritt) uvm.. Und an dem Punkt kommen dann Prozessoptimierer in's Spiel. Die fangen nicht einfach wild an zu automatisieren sondern machen Workflow-Diagramme usw. um die Abläufe in ihrer Gänze zu verstehen. Und dann setzen sie sich mit entsprechenden Fachleuten (Sysadmin, System Engineers, Software-Entwickler usw.) zusammen und arbeiten ein Konzept aus, das wirklich Prozesse optimiert und nicht im Endeffekt nur Teile automatisiert, die ggf. irgendwann gegen die Wand laufen, weil irgendein Arbeitsablauf, der nur alle paar Monate mal auftritt, nicht bedacht wurde.

Schon richtig. Aber wenn man sie im Unwissen lässt und einfach den "befehl" ausführt, sie aber von dem Skript nichts wissen lässt - das ist doch eine Win-Win Situation :D.


Ein Job bei Prozessoptimierern ist sicher sehr interessant - aber die wissen wsl., was sich automatisieren lässt und dann hat man erst wieder 40 Stunden Arbeit.
 
Du kannst dir sicher sein, dass nicht die Zeit weniger wird, sondern die Arbeit mehr. Effizienz heisst nicht mehr Zeit für die wichtigen Dinge zu haben, sondern mehr Arbeit in kürzerer Zeit zu erledigen. Du kannst auch 40h mit einer Bohrmaschine arbeiten ;)

@White_Fox:
Erfahrungsgemäß ist selbstgeschriebene Software in Unternehmen Schrott, da sie einerseits unter Zeitdruck zusammengezimmert, andererseits irgendwann nicht mehr gepflegt wird - und ein Konzept fehlt bei sowas üblicherweise eh, genauso wie die Einbindung in vorhandene Unternehmensstrukturen und -software. Das führt bei wachsenden Unternehmen sehr schnell zu Problemen, die dann meist in einer überstürzten und kostenintensiven Reorganisationen enden.
Dem ersten Teil kann ich mich nur anschließen. Wer Arbeit schneller erledigt bekommt nur mehr davon. Der äußerst unangenehme Nebeneffekt ist, daß, hat man einmal ein rasches Arbeitstempo bewiesen, dann wird das schlimmstenfalls kontinuierlich erwartet.

@pi():
Wehe dein Script läuft mal nicht richtig, oder benötigt eine umfangreichere Erweiterung. Und dein Chef erwartet die Erledigung aufgrund deiner bisher guten Leistung bereits für gestern.

@SB:
Genau das, was du im zweiten Absatz beschreibst, scheint mir mit dem Programm geschehen zu sein daß ich bereits bitter beklagt habe. Da wurde mit Sicherheit von Anfang an nicht die nötige Zeit in Planung investiert, und auftretende Probleme auch nur durch Raten, bzw. Versuch auf Erfolg und Fehlschlag getestet.
Ich habe nichts gegen Oberflächendesign im Stil von Win95, meinem Laptop mit Win7 habe ich bis vor kurzem auch dieses "Klassik-Design" verpasst.
Was ich aber leidenschaftlich hasse sind z.B. völlig überflüssige Fehlermeldungen. Besagtes Programm speichert z.B. einzelne Änderungen an einer Position automatisch, bei einem Wechsel der Positionsgruppe fordert es aber zum Speichern auf (wohlgemerkt, es fragt nicht ob man speichern will oder nicht). Wenn es schon automatisch speichert, dann will ich nicht noch irgendeine Meldung wegklicken müssen. Das steigert nur den Streßpegel. Sowas ist für sich betrachtet zwar eine Kleinigkeit, wenn derartige Kleinigkeiten sich jedoch summieren kostet es irgendwann auch Nerven.

Ach, nochwas:
@pi():
Ich bin mir sicher, du findest in fast jeder Firma Arbeit, die du automatisieren kannst. Insbesondere Klitschen, d.h. Firmen, die nur irgendwelche Handlanger suchen, haben oft solche Arbeit. Da sind oft Leute die einfach machen was man ihnen sagt, und das setzen die dann genauso um. Hirnschmalz (oder gar die Fertigkeiten um wenigstens ein Excelscript zu schreiben) sind da auch selten. Also, einfach mal drauflos bewerben...

Man glaubt nicht, wieviel Zeit und Geld manche Firmen damit versenken, jeden Tag vier Mitarbeiterstunden mit vollkommen sinnloser Handarbeit beshäftigen, anstatt den Mißstand aus dem Weg zu räumen. Da könnte ich trotz meines noch recht jungen Lebens bereits Geschichten erzählen... :D
 
Zuletzt bearbeitet:
@pi():
Wehe dein Script läuft mal nicht richtig, oder benötigt eine umfangreichere Erweiterung. Und dein Chef erwartet die Erledigung aufgrund deiner bisher guten Leistung bereits für gestern.

Das glaub ich dir sofort! Man muss es wirklich unbedingt verschweigen :D.

Ach, nochwas:
@pi():
Ich bin mir sicher, du findest in fast jeder Firma Arbeit, die du automatisieren kannst. Insbesondere Klitschen, d.h. Firmen, die nur irgendwelche Handlanger suchen, haben oft solche Arbeit. Da sind oft Leute die einfach machen was man ihnen sagt, und das setzen die dann genauso um. Hirnschmalz (oder gar die Fertigkeiten um wenigstens ein Excelscript zu schreiben) sind da auch selten. Also, einfach mal drauflos bewerben...

ok!

Man glaubt nicht, wieviel Zeit und Geld manche Firmen damit versenken, jeden Tag vier Mitarbeiterstunden mit vollkommen sinnloser Handarbeit beshäftigen, anstatt den Mißstand aus dem Weg zu räumen. Da könnte ich trotz meines noch recht jungen Lebens bereits Geschichten erzählen... :D

Jap, das glaube ich sofort. Habe ich auch selbst schon erlebt und auch oft genug von Freunden mitgeteilt bekommen. Sind eben auch alle nur Menschen. Und vor allem denkt nicht jeder wie ein Informatiker/Programmierer sondern es gibt auch noch andere Berufe und vor allem Denkweisen. Also wird oft einfach Demütig eingeklopft.
 
bei einem Wechsel der Positionsgruppe fordert es aber zum Speichern auf [...] dann will ich nicht noch irgendeine Meldung wegklicken müssen. Das steigert nur den Streßpegel. Sowas ist für sich betrachtet zwar eine Kleinigkeit, wenn derartige Kleinigkeiten sich jedoch summieren kostet es irgendwann auch Nerven.

Versuch doch mal spaßeshalber die Zeit zu messen, die du hier verbrauchst. Rechne auch eine Art Gewohnheitsfaktor (Klicken ohne Lesen) aus. Das rechnest du dann pro Mitarbeiter un Tag hoch. Ich wette, du bleibst weit unter 30 Sekunden pro Tag und Mitarbeiter. Auch wenn es nervt, so lohnt sich die Investition in ein neues Produkt hier einfach nicht, da die Investitionskosten nicht in absehbarer Zeit die 30 Sekunden Ersparnis bzw. die "Erhaltung der Nerven" rechtfertigen würden ;)
 
Versuch doch mal spaßeshalber die Zeit zu messen, die du hier verbrauchst. Rechne auch eine Art Gewohnheitsfaktor (Klicken ohne Lesen) aus. Das rechnest du dann pro Mitarbeiter un Tag hoch. Ich wette, du bleibst weit unter 30 Sekunden pro Tag und Mitarbeiter. Auch wenn es nervt, so lohnt sich die Investition in ein neues Produkt hier einfach nicht, da die Investitionskosten nicht in absehbarer Zeit die 30 Sekunden Ersparnis bzw. die "Erhaltung der Nerven" rechtfertigen würden ;)

Das mag schon sein, dass es wenig Zeit braucht. Ob es in diesem Fall der Fall ist, weiß ich nicht aber es gibt auch Dinge die einen so nerven oder ablenken, dass sie dass sie jemanden aus dem Flow bringen. Das mögen ruhig Dinge sein, die an sich nicht viel Zeit brauchen, aber Zeit ist gar nicht so wichtig wie Energie der Mitarbeiter-finde ich. Wenn jemanden eines Sache aus der Flow bringt, dann kostet das schon ganz schön viel Umsatz - davon bin ich überzeugt. Stelle dir zum Beispiel vor, du musst in der Arbeit etwas wirklich kompliziertes programmieren und einmal alle 20 Minuten stört dich jemand mit einer Zwischenfrage zu einem ganz anderen Thema. Und zwar einem Thema bei dem du zumindest kurz nachdenken musst um eine Antwort sagen zu können. Ich bin mir sicher, du brauchst um das Problem zu lösen deutlich länger und bist nachher deutlich erschöpfter.
 
So ein paar Monate später bin ich nun Arbeitnehmer und kann sagen: Es funktioniert. Im richtigen Leben fällt doch sehr oft "Monkeywork" an, auch in "richtigen" Jobs. Und das lässt sich toll per Skript automatisieren!

Ein Hoch der Skripterei! :) :) :)
 
Schaut doch einfach mal dieses geile Video an:

[video=youtube;ytDamqTjPwg]https://www.youtube.com/watch?v=ytDamqTjPwg[/video]

Es ist nur ein einziges Beispiel, wie man (in dem Fall leider illegal), passive Einkommen generieren kann, durch IT. Das Internet gibt uns wirklich die allerbesten Möglichkeiten, richtig viel Geld, richtig passiv zu verdienen. Ich finde deine Idee ziemlich intelligent und würde Sie gerne weiterspinnen.

Was mir spontan einfällt:

#1 Job-Futuromat den Job-Futuromat crawlen und rausfinden, welche Jobs den höchsten Automatisierungsgrad haben/werden. Dann schauen, welche Jobs darunter am wenigsten physische Anwesenheit erfordern: et voilà da ist das passive Nebeneinkommen.

#2 Smartphone-Viren: Viren auf dem Smartphone – wie gross ist die Gefahr? - 7mobile Smartphone News wir benutzen die Dinger jeden Tag und haben keinerlei Sicherheitssoftware auf den Smartphones, vor allem bei Android (soweit ich weiß) nicht. Sachen werden unterwegs gekauft, etc. Was das für Möglichkeiten gibt.

Ich finde die Idee genial - zumal ich es mir auch im deutschen Arbeitsrecht extrem schwer vorstelle, dass man dafür irgendwie Ärger bekommen könnte, denn man schuldet ja nur die normative Arbeitsleistung. Wenn das erfüllt wird, was im Arbeitsvertrag gefordert ist (und das ist i.d.R. Arbeitnehmerfreundlich), dann sollte es keine Probleme geben!
 
Was mir spontan einfällt:
#1 Job-Futuromat den Job-Futuromat crawlen und rausfinden, welche Jobs den höchsten Automatisierungsgrad haben/werden. Dann schauen, welche Jobs darunter am wenigsten physische Anwesenheit erfordern: et voilà da ist das passive Nebeneinkommen.

So einfach ist es dann leider nicht. Ein hoher Automatisierungsgrad heißt nicht zwangsläufig, dass die Arbeit nicht in einer komplexen Domäne stattfindet. Schau dir einfach die Automobilbranche an. Hoher Automatisierungsgrad, trotzdem bleibt es sehr komplex ein Auto aus 8000 Einzelteilen zusammen zu bauen.

Ich mache auf der Arbeit fast nichts anderes als automatisieren. In einer komplexen Problemdomäne wird das dann allerdings schnell dein neuer Vollzeitjob, da sich Anforderungen und Schnittstellen nicht selten ändern und du ansonsten damit beschäftigt bist, die Prozesse zu stabilisieren, da es oft Fälle gibt, die du noch nicht berücksichtigt hast.

Daher bin ich der Meinung: Wenn du wirklich etwas hast, das du automatisieren kannst und dessen manuelle Durchführung Firmen richtig viel Geld kostet, dann baust du das eher zu einem seriösen Geschäft aus als es über ein "passives Einkommen" als Angestellter zu versuchen.
 
Ich würde in die gleiche Richtung argumentieren: Als Selbstständiger hättest du doch deutlich mehr Vorteile, wenn du ein kostspieliges Verfahren autmatisieren kannst. Dann kannst du die Herstellung, Dienstleistung whatever du anbieten willst, auch gleich selbst aufziehen. Nicht zu vergessen: Autoamtisierungsprozesse sind selbst auch intensive Arbeit: nach kreativen Schritten, Analayseverfahren etc. kommt noch die Entwicklung und Umsetzung etc. Ist ja nciht so, dass Automatisieren gleichbedeutend mit Däumchendrehen ist - im Gegenteil. Ein Großteil der höheren Jobs im IT-Bereich hat einzig und allein die Optimierung und Automatisierung von Prozessen zum Ziel.
 
Ich würde in die gleiche Richtung argumentieren: Als Selbstständiger hättest du doch deutlich mehr Vorteile, wenn du ein kostspieliges Verfahren autmatisieren kannst.

"Kostspielige" Verfahren lassen sich nicht vom heimischen Schreibtisch aus automatisieren.
Und wenn du mit dem Gedanken spielst Steuerungen herzustellen, darfst du erstmal schön für Zertifikate zahlen.
Vielleicht hast du auch noch mit dem ElektroG2/WEEE2 Gesetz zu tun.
Und dann wirst du als Unternehmer auch für Arbeiten und Geräte haften müssen, dafür braucht es Versicherungen und Anwälte.
Am Ende brauchst du einen Vertrieb in den Unternehmen und da stehen auch andere Unternehmen, die den Fuß bereits in der Tür haben und/oder sowieso ähnliche Ideen haben.

Ich will keine Kreativität abwürgen aber in JEDEM Fall, braucht es in diesem System, für ein solches Vorhaben sehr sehr sehr viel Geld ;)
 
Das stimmt alles.

aber in JEDEM Fall, braucht es in diesem System, für ein solches Vorhaben sehr sehr sehr viel Geld ;)
und davon mal ganz abgesehen, was aber auf jeden (angehenden) Selbstständigen zutrifft. Trotzdem finde ich die Überlegung von Ark als Gedankenexperiment in einer Dienstleistungsgesellschaft spannend: Vielleicht gibt es ja Firmen, die für externe Automatisierungs- und Prozessoptimierer Budget haben?
 
Trotzdem finde ich die Überlegung von Ark als Gedankenexperiment in einer Dienstleistungsgesellschaft spannend: Vielleicht gibt es ja Firmen, die für externe Automatisierungs- und Prozessoptimierer Budget haben?
Die gibt es und der Markt ist hier leider auch bereits hoch professionalisiert. Meistens sind es ja große Konzerne, die solche Dienstleistungen in Anspruch nehmen und die gehen in der Regel dann direkt zu großen Unternehmensberatungen wie Boston Consulting, KPMG oder eben McKinsey. Bei den UB's findest du dann auch entsprechende Jobs. Hier mal ein schnelles Beispiel:

McKinsey Operations Consultant

Hier sieht man schon, dass da Generalisten gesucht werden und die Anforderungen sind auch sehr hoch - sowohl was die formale als auch qualitative Bildung angeht. Wer es drauf hat, der kann sich in einer UB mit ein paar Jahren Berufserfahrung und bei guten Erfolgen über ein höheres 5 stelliges Jahresgehalt freuen. Angeblich verdienen die Top-Consultants dort ja mehrere Millionen pro Jahr. Wobei das gewiss nur die absolute Minderheit ist.
 
Zuletzt bearbeitet:
Automatisierung ist bereits lange ein recht großer Markt, der mit der IT sogar noch weiter gewachsen ist. Ich habe als Freelancer selbst ziemlich viel mit Aufträgen zu tun, bei denen es in erster Linie um Automatisierung geht. Seien es Dinge wie Auto-Scaling um Cloud-Umgebungen dynamisch an die aktuelle Last anzupassen und somit kosteneffizienter zu machen, oder seien es Automatisierungen wiederkehrender Abläufe durch Skripte, Test-Automatisierungen etc..

Der Markt ist also da, verlangt aber auch, dass man sich sehr schnell in die Tiefen neuer Umgebungen einarbeiten kann. Sonst riskiert man Seiteneffekte, die ganze Plattformen zum Absturz bringen können. Und als Auftragnehmer trägt man dann eine gewisse Verantwortung, die man als Festangestellter eher selten hat. Entsprechend gute Versicherungen gegen solche Fehler sind also ein Muss.

Ohne Erfahrung würde ich mich an solche Dinge jedenfalls nicht wagen. Man sollte schon wissen, was man von einer Plattform wissen muss, bevor man irgendwelche Aspekte davon automatisiert, die bisher unter menschlicher Kontrolle standen. Auch sollte man wissen welche Technologien für welche Aufgaben zur Verfügung stehen, denn ständig individuelle Skripte zu schreiben ist erfahrungsgemäss eher ein kontraproduktiver Weg, da die Pflege der Skripte oft irgendwann mehr Aufwand verursacht als die Skripte selbst vermeiden. Daher sollte man dann auf bestehende Werkzeuge zurückgreifen, die von anderen Leuten/Unternehmen weiterentwickelt werden, so dass man möglichst nur noch Konfigurationen/Manifeste anpassen muss, wenn man die initiale Einrichtung abgeschlossen hat.

Ein Beispiel: Es ist unsinnig Klick-Skripte zum Test von Webapplikationen zu bauen, wenn man sowas automatisiert mit Tools wie Jenkins und Selenium machen kann, die wesentlich weiter entwickelt sind als es jedes individuelle Klick-Skript jemals sein wird, und die schnell an verschiedene Applikationen angepasst werden können, ohne dass man mehr als nur ein paar wenige Zeilen Groovy-Code schreiben muss.

Das zeigt aber auch, dass man in der Automatisierungswelt sehr flexibel sein muss. Nur mit Shell-Skripten kommt man da nicht weiter. Ich arbeite derzeit z.B. mit Groovy, Scala, R, Node.js, Perl, Ruby und Python, obwohl ich lediglich die Plattformen von "nur" 4 Unternehmen betreue. Die ganzen Tools, die ich für verschiedene Aufgaben einsetze, kommen da noch hinzu. Das beginnt bei Rancher, Kubernetes, Docker Swarm und OpsWorks/cloud-init für Cloud-Deployments, geht weiter über Jenkins, Selenium, Docker Cloud etc. für Test-Automatisierung und endet nicht zuletzt bei diversen Monitoring-Tools, die in Fehlerfällen entsprechende Trigger für Failover auslösen. Das muss dann auch noch verbunden werden mit Tools für Notifications etc.. Mit anderen Worten: Man braucht allein schon einige Jahre um die zur Verfügung stehenden Möglichkeiten kennenzulernen und um zu lernen, in welchen Fällen man welche Tools einsetzen kann und sollte. Vom Lernaufwand für die verschiedenen Programmiersprachen, sowie theoretischen Background (was ist eine Build- und Test-Pipeline und wie funktioniert sie etc.) ganz zu schweigen. Aktuell verbringe ich ca. 1/3 meiner Zeit mit Weiterbildung, ohne dass das von irgendwem bezahlt wird. Das geht also von dem Geld ab, das ich mit meinem Job verdiene (zusätzlich zu Steuern, Versicherungen etc., worüber man sich ja auch noch Kenntnisse aneignen muss).

Versucht man immer eigene Lösungen zu bauen, ist man recht schnell weg vom Markt. Der heutige Markt erwartet State-of-the-Art-Lösungen, die nicht auf individuellen Skripten basieren. Jedes Unternehmen checkt irgendwann, dass es für die Skripte, die ihr Freelancer entwickelt hat, weitaus bessere Lösungen in der Software-Welt gibt. Und wenn sich sowas über einen Freelancer erstmal rumspricht, dann bekommt er bald keine Aufträge mehr. Kennt man hingegen viele Technologien und kann Unternehmen individuelle und wartungsarme Lösungen anbieten, kann man damit recht gutes Geld verdienen.

Übrigens: Industrie-Automatisierungen sollte man den großen (Beratungs)Unternehmen überlassen, die sich darauf spezialisiert haben. Das bekommt man als Einzelperson kaum hin. Wenn man als Einzelperson/Freelancer in der Automatisierung Fuss fassen will, sollte man sich auf die IT-Welt konzentrieren.

Achja: Bitte nicht Business Consulting mit Automatisierung verwechseln. Consultants sind dazu da Geschäftsabläufe zu optimieren. Automatisierer sorgen dafür, dass bisher manuell durchgeführte Tätigkeiten in Zukunft von Software übernommen werden.
 
Achja: Bitte nicht Business Consulting mit Automatisierung verwechseln. Consultants sind dazu da Geschäftsabläufe zu optimieren. Automatisierer sorgen dafür, dass bisher manuell durchgeführte Tätigkeiten in Zukunft von Software übernommen werden.
So kann man es natürlich ausdrücken, wenn man Automatisierung auf die Inbetriebnahme von Software reduziert. Mein Vorposter hat ja explizit auch von Prozessoptimierung gesprochen. Wenn ich mich hier auf meine verlinkte Stellenanzeige beziehe, dann verrät das Wort "Kaizen" das es sich hier um Beschaffung und/oder Fertigung handeln muss und hier leiten sich operative Maßnahmen eben aus den strategischen/taktischen Überlegungen und der Definition neuer Prozesse ab. Ein Beispiel wäre z. B. Just in Time Lieferung. Die findet dann natürlich Software gestützt statt - die Überlegungen dazu macht aber eben nicht der "Automatisierer" der die Software dazu installiert.

Warum sich das nicht so einfach trennen lässt sieht man z. B. eben in der IT. Wenn du Vorgänge im Deployment automatisierst, dann wirst du dir ja wahrscheinlich auch erstmal die Prozesse überlegen, bevor du die Inbetriebnahme der Infrastruktur um die Umsetzung der Prozesse auf eben dieser durchführst. Wäre das so gestrickt getrennt wie du oben sagst, dann müsste dir ja jedesmal jemand die Prozesse vorher geben, bevor du diese umsetzt. Wird wohl denke ich mal nicht der Fall sein.
 
Zuletzt bearbeitet:
So kann man es natürlich ausdrücken, wenn man Automatisierung auf die Inbetriebnahme von Software reduziert. Mein Vorposter hat ja explizit auch von Prozessoptimierung gesprochen.
Auch die Inbetriebnahme von Software bedingt Umstellungen in den Geschäftsprozessen. Jeder, der mal DevOps in einem Unternehmen eingeführt hat, kann ein Lied davon singen, was da im Miteinander der Mitarbeiter alles verändert werden muss. Selbst scheinbar einfache Einführung von Software hat also auch oft massive Auswirkungen auf die Arbeitsweisen in einem Unternehmen.

Warum sich das nicht so einfach trennen lässt sieht man z. B. eben in der IT. Wenn du Vorgänge im Deployment automatisierst, dann wirst du dir ja wahrscheinlich auch erstmal die Prozesse überlegen, bevor du die Inbetriebnahme der Infrastruktur um die Umsetzung der Prozesse auf eben dieser durchführst. Wäre das so gestrickt getrennt wie du oben sagst, dann müsste dir ja jedesmal jemand die Prozesse vorher geben, bevor du diese umsetzt. Wird wohl denke ich mal nicht der Fall sein.

Da hast du absolut Recht und ich habe mich vermutlich nur einfach nur missverständlich ausgedrückt, da ich versucht habe das (zum TE passend) aus Sicht der IT aufzuzeigen. Ich denke aber, dass Business Consulting dennoch von der Automatisierung getrennt betrachtet werden muss, da sie wesentlich weiter geht. Wenn man z.B. DevOps in einem Unternehmen einführt, dann betrifft das üblicherweise 2 Abteilungen des Unternehmens, die Software-Entwicklung und den Operations-Bereich. Wenn ein Business Consultant jedoch die Vorgänge in einem Unternehmen allumfassend angeht, dann ändert er z.B. bei der Umsetzung von Datenschutzrichtlinien sämtliche Arbeitsweisen im Unternehmen. Er führt dann auch Kommunikationsketten ein, die wiederum alle Bereiche betreffen und vieles mehr. Aber nur ein kleiner Teil seiner Änderungen betrifft tatsächlich Automatisierungen. Diese überträgt er dann üblicherweise entsprechenden Spezialisten und gibt dabei Rahmenbedingungen vor, die eingehalten werden müssen. Von daher gibt der Business Consultant üblicherweise die Prozesse vor, die dann teilweise durch Automatisierung gelöst werden, wofür er dann aber nicht mehr verantwortlich ist. Mit anderen Worten: Der Business Consultant überblickt das große Ganze. Der Prozess-Automatisierer überblickt nur jene Bereiche, die für die Automatisierung relevant sind.

Betrachten wir uns den Ausgangspunkt dieses Threads (Zitat) "Ich träume schon lange davon, irgend einen ganz einfachen Job anzunehmen und die Arbeit dann dort vollständig zu automatisieren", dann geht es hier wohl eher um die Automatisierung bestimmter Tätigkeiten. Das kann man zwar in gewisser Weise auch als Prozessoptimierung betrachten, ist aber meiner Meinung nach tatsächlich eher eine Prozess-Automatisierung, bei der Gefahr gelaufen wird, dass alles andere als eine Optimierung dabei rauskommt, weil die Fehleranfälligkeit ggf. steigt, der Wartungsaufwand erhöht wird etc.. Es ist jedenfalls von dem, was Business Consultants tun, weit entfernt. Die bekommen, zumindest meiner Erfahrung nach, von solchen stumpfsinnigen Tätigkeiten oft gar nichts mit, weil sie dafür zu wenig in die individuellen Abläufe einzelner Mitarbeiter schauen. Sie betrachten hingegen eher die übergeordneten Abläufe in den Abteilungen und abteilungsübergreifend. Deswegen hat ein Business Consultant auch nichts mit der Einführung von DevOps zu tun sondern delegiert diese an entsprechende Spezialisten. Er gibt lediglich vor, dass DevOps an den Punkten X und Y Zeit, Geld und Ressourcen einsparen kann.
 
In jedem Baumarkt gibt es Bedarf nach einer Optimierung des Zuschnitts. Die Kosten wären allerdings viel Höher, als die aktuelle Lösung aussieht: 3 Aushilfen auf 450€ Basis. Sind die Aushilfen nicht da, ist der Zuschnitt (incl. Fräsung) geschlossen oder nur nach Bedarf besetzt.

Ich versuche die Arbeit mal nur für die reine Sägearbeit zu glieder:

Kundeninterface:
  • Produktauswahl mit Eigenschaften der Produkte (Belastbarkeit, Verarbeitung, Werbung für weitere Produkte, die damit gut interagieren)
  • Fragenbeantwortung (hier trifft man statistisch immer wieder auf gleiche Fragen oder schmale Gruppen von Fragen)
  • Maße (rechteckig) und stärke abfragen
  • Auswahl in welche Richtung die Maserung verlaufen soll mit "egal" Option.
  • Anzeigen, ob genug Material vorhanden ist (Speicherung der Zwischenergebnisse und autmatische Neuerkennung. Ggs. eigenständiges Einräumen)
Sägearbeit
  • Aus einem bestehenden (!) Regalsystem müssen die (richtigen!) Platten herausgezogen und zur Säge befördert werden
  • Die Säge kann nur von oben nach unten und links nach rechts sägen
  • gewünschte Maße mit Säuberungsschnitte ausschneiden, zum Kunden befördern
  • Reststück der Platte zurück ins Regal, ab einer gewissen Restgröße in eine besondere Box mit Preisauszeichnung (Bemerkung: Es kann dadurch passieren, dass der benötigte Platz verdoppelt wird also muss hier eine effiziente Logik hinter sein)
Kundenabfertigung
  • Ware vollständig übergeben
  • Kassenzettel drucken

Optional: Arbeitsplattenzuschnitt und Fräsungen.

Ist also recht einfach zu automatisieren. Aber die Roboter, die dafür nötig wären, und die Arbeitszeit für den Softwareeinsatz, würden sich nicht amortisieren, außer das System bleibt ein paar Jahrzehnte fehlerfrei.

Auch das Kassensystem lässt sich einfach automatisieren.
Ware vom Band und Einkaufswagen erkennen/einscannen, weiterschieben, addieren, Geld anfordern, Zahlung durchführen, Ware freigeben. Mögliche Probleme: Objekte ohne Namen (Strichcode). Tritt vermehr bei Pflanzen und anderen Objekten auf, die per Hand etikettiert werden müssen.

Aber wenn sowas jemand realisiert, werden auf einen Schlag ca. 14 Arbeitsplätze pro größeren Baumarkt freigegeben und wir haben mehr Arbeitslose :D
 
Wo bleiben die Lagerlogistik, Maschinenwartung, manuelle Änderungen, ERP Anbindung, usw..? Und wie passt das zur Kundenbeziehung, oder neu-schwäbisch auch Experience, oder letzten Endes zum Geschäftsmodell? Nur weil es möglich ist, heißt es nicht, dass sinnvoll ist.

Mich wundert es bei solchen Themen immer, dass sich die Informatik als Weltretter ansehieht, die irgendwie alles kann, auch ohne Expertenwissen oder Arbeitserfahrung. Es ist diese Arroganz, die uns interessanterweise am Ende oft mehr zu schaden scheint, als dass sie uns nützt.
 
Zurück
Oben