Laravel-Entwicklung für Unternehmen in Augsburg

Augsburg wird häufig als Vorort Münchens beschrieben, was der Stadt nicht gerecht wird. Die Wirtschaft steht auf eigenen Beinen, mit Maschinenbau, Mechatronik, Leichtbau und Faserverbundtechnik. Dazu kommt ein Schwerpunkt, der aus der alten Textilindustrie herausgewachsen ist und die Stadt heute prägt: Umwelttechnik und Ressourceneffizienz.

Der Standort versteht sich ausdrücklich als bayerisches Zentrum für dieses Thema, mit einem Innovationspark, Forschungseinrichtungen und einer Reihe von Betrieben, die sich darauf spezialisiert haben. Das ist keine Marketingzeile, sondern schlägt bis in die Softwareprojekte durch.

Mehrere Werke, eine Datenlage

Was uns von hier aus erreicht, hat oft mit Verteilung zu tun. Ein Betrieb hat über die Jahre zugekauft oder erweitert, und jeder Standort führt seine eigene Liste. Am Monatsende setzt jemand daraus eine Zahl zusammen, die niemand so recht glaubt.

Der erste Schritt ist dann keine Programmierarbeit, sondern eine Verständigung darüber, welcher Begriff was bedeutet. Ein „abgeschlossener Auftrag“ ist in der Fertigung etwas anderes als in der Buchhaltung. Erst wenn das geklärt ist, lohnt es sich, eine gemeinsame Anwendung zu bauen. Wie so etwas entsteht, steht unter Laravel-Entwicklung.

Anlagen, die schon Daten liefern

Vieles ist bereits vorhanden, nur nicht abrufbar. Maschinen schreiben Protokolle, Waagen liefern Werte, Prüfstände legen Dateien ab. Was fehlt, ist der Weg von dort in ein System, in dem man damit arbeiten kann. Solche Übergänge bauen wir regelmäßig, meist als Schnittstelle gegen ein bestehendes ERP. Wie wir sie schneiden, steht unter API- und Backend-Entwicklung.

Wenn Verbrauch nachgewiesen werden muss

Ressourceneffizienz ist in Augsburg selten nur ein Anspruch, sondern häufig eine Anforderung von außen. Ein Kunde verlangt Angaben zum Energieeinsatz, eine Zertifizierung will Zahlen über mehrere Jahre, eine Förderung hängt an einem Nachweis.

Der Unterschied zu einer gewöhnlichen Auswertung liegt in der Belegbarkeit. Es genügt nicht, eine Zahl zu zeigen; man muss erklären können, woher sie kommt. Welcher Zähler, welcher Zeitraum, welche Umrechnung, und was passiert ist, als das Messgerät drei Tage ausfiel.

Solche Anwendungen bauen wir so, dass eine Lücke sichtbar bleibt, statt geglättet zu werden. Eine geschätzte Zahl, die als geschätzt gekennzeichnet ist, hält jeder Prüfung stand. Eine geschätzte Zahl, die aussieht wie gemessen, kostet im Zweifel das Zertifikat.

Der zweite Standort ist der ehrliche

Eine Anwendung, die in einem Werk läuft, ist noch kein Beweis. Erst bei der Einführung im zweiten kommt heraus, was man stillschweigend vorausgesetzt hat. Dort heißt eine Position anders, ein Schritt wird übersprungen, weil die Anlage ihn nicht braucht, und jemand hat seit zehn Jahren ein eigenes Kürzel für einen Sonderfall.

Wir planen die Einführung deshalb nicht als einmalige Umstellung, sondern als Reihe. Das erste Werk bekommt Zeit für Rückmeldungen, das zweite deckt die Annahmen auf, ab dem dritten wird es Routine. Wer alle gleichzeitig umstellt, spart ein paar Wochen und bezahlt sie im Support zurück.