Scitotec GmbH

Scitotec GmbH Individuelle IT-Lösungen für konkrete Probleme. Unsere Spezialitäten sind leistungsstarke Web-App

Sechs Personen sitzen in einem Boot. Fünf zeigen in unterschiedliche Richtungen. Einer rudert.Genau daran musste ich bei...
01/09/2026

Sechs Personen sitzen in einem Boot. Fünf zeigen in unterschiedliche Richtungen. Einer rudert.

Genau daran musste ich bei einem überschaubaren Intranet-Projekt denken. Zwei interne Mitarbeiter liefern Inhalte. Drei externe Berater steuern das Projekt, organisieren die Kommunikation und erstellen Berichte. Ein Entwickler richtet das CMS ein, erstellt das Template, pflegt die ersten Inhalte ein und führt die Schulung durch.

Dreimal darf man raten, wer über die gesamte Projektlaufzeit am wenigsten daran verdient. Natürlich derjenige, der das sichtbare Ergebnis produziert.

Ich habe nichts gegen externe Beratung. Im Gegenteil. Bei komplexen Vorhaben, fehlender Erfahrung oder schwierigen Veränderungsprozessen kann sie entscheidend sein. Aber wenn fünf Menschen damit beschäftigt sind, die Arbeit einer Person zu planen, zu kontrollieren und zu dokumentieren, stimmt das Verhältnis nicht mehr. Dann wird nicht technische Komplexität bezahlt, sondern organisatorische Unsicherheit.

Mehr Menschen im Boot bedeuten nicht automatisch mehr Geschwindigkeit. Besonders dann nicht, wenn fast alle den Kurs erklären und nur einer rudert.

Wo zieht ihr die Grenze? Wann schafft Beratung echten Nutzen und wann verwaltet sie nur die eigentliche Arbeit?

In vielen etablierten mittelständischen Unternehmen gibt es dieses eine System. Es läuft seit 10, 15 oder mehr Jahren im...
25/08/2026

In vielen etablierten mittelständischen Unternehmen gibt es dieses eine System. Es läuft seit 10, 15 oder mehr Jahren im Hintergrund, steuert die Kernprozesse der Wertschöpfung, wird aber intern behandelt wie ein rohes Ei. Das Motto lautet: „Bloß nicht anfassen, solange es irgendwie funktioniert.“

Das Problem: Altsysteme (Legacy-Code) entwickeln sich still und heimlich von einer verlässlichen Basis zu einer tickenden Zeitbombe für das gesamte operative Geschäft.

Das größte Risiko ist dabei selten die Technologie selbst, sondern der Faktor Mensch. Oft hängen geschäftskritische Abläufe am impliziten Wissen eines einzigen Entwicklers oder Mitarbeiters, der das System damals aufgebaut hat. Wenn diese Schlüsselpersonen in den Ruhestand gehen, entsteht ein existenzbedrohliches Know-how-Vakuum. Findet sich kein Ersatz, ist das Unternehmen bei Fehlern oder notwendigen Updates handlungsunfähig.

Zusätzlich blockiert Legacy-Code jede Form von Innovation. Moderne Cloud-Infrastrukturen, KI-Schnittstellen oder agile Web-Anwendungen lassen sich mit veralteten Monolithen kaum verknüpfen. Jede kleine Anpassung wird zum unkalkulierbaren Risiko.

Als strategischer IT-Berater erleben wir bei Scitotec oft, dass die Angst vor einer Modernisierung zu Lähmung führt. Die Sorge: Ein jahrelanges, extrem teures Riesenprojekt, das den Betrieb lahmlegt.

Doch eine zukunftssichere Modernisierung bedeutet fast nie den radikalen Kahlschlag („Alles wegschmeißen und neu bauen“). Der weitaus erfolgreichere Weg in der Praxis ist die schrittweise Migration:

- Die Entkopplung: Kritische Kernfunktionen werden Stück für Stück identifiziert, in moderne Microservices oder Module ausgelagert und über saubere Schnittstellen (APIs) angebunden.
- Das kontinuierliche Refactoring: Der Altcode wird schrittweise bereinigt und dokumentiert, während das Gesamtsystem stabil weiterläuft.
- Risikominimierung: Der Geschäftsbetrieb wird zu keinem Zeitpunkt gefährdet, da die Transformation in kontrollierten, messbaren Etappen erfolgt.

Software-Modernisierung ist kein IT-Projekt, sondern eine strategische Risiko- und Investitionsabsicherung für die Geschäftsführung. Wer den Elefanten im Serverraum ignoriert, zahlt am Ende den höchsten Preis.

Hand aufs Herz: Läuft in euren Unternehmen noch ein System, bei dem alle hoffen, dass es einfach morgen noch anspringt?

Bei der Auswahl neuer Unternehmenssoftware steht der Mittelstand oft vor einer scheinbar einfachen Rechenaufgabe: Auf de...
18/08/2026

Bei der Auswahl neuer Unternehmenssoftware steht der Mittelstand oft vor einer scheinbar einfachen Rechenaufgabe: Auf der einen Seite stehen die hohen Initialkosten einer maßgeschneiderten Individualsoftware. Auf der anderen Seite lockt die Standard-SaaS-Lösung mit einer schnellen Einführung und vermeintlich geringen, monatlichen Lizenzgebühren.

Die Praxis zeigt jedoch: Wer nur die Anschaffungskosten vergleicht, übersieht den TCO-Effekt (Total Cost of Ownership). Nach 24 bis 36 Monaten kippt die Rechnung in vielen Unternehmen dramatisch.

Die versteckten Kosten von „Software von der Stange“ basieren meist auf drei Faktoren:

1. Die Wachstums-Steuer (Lizenz-Explosion)
Standardsoftware wird pro Nutzer und Monat abgerechnet. Was bei 20 Mitarbeitern noch überschaubar ist, entwickelt sich bei 100 oder 200 Mitarbeitern zu einem massiven, dauerhaften Kostenblock. Das Paradoxe daran: Sie zahlen mit jedem neuen Mitarbeiter mehr Geld an einen Drittanbieter, ohne dass sich der Wert der Software für Ihr Unternehmen erhöht.

2. Der „Verbiegungs-Aufwand“ (Customizing)
Kein Standard-Tool passt zu 100 % auf Ihre gewachsenen, wettbewerbsentscheidenden Prozesse. Also wird die Software angepasst. Diese externen Implementierungskosten und das Mieten von spezialisierten Beratern für komplexe Schnittstellen übersteigen nicht selten die ursprünglichen Lizenzkosten um ein Vielfaches.

3. Der Effizienzverlust durch Prozess-Inversion
Das gefährlichste Szenario: Die Software lässt sich nicht flexibel genug anpassen. Die Folge ist, dass sich Ihre Mitarbeiter und Workflows an die Logik der Software anpassen müssen und nicht umgekehrt. Wenn wertvolle Arbeitszeit durch manuelle Workarounds und Medienbrüche verloren geht, entstehen die höchsten, weil unsichtbaren Kosten.

Der strategische Ansatz von Scitotec: Individualsoftware ist keine Ausgabe, sie ist eine Investition in ein Unternehmens-Asset. Sie zahlen die Entwicklung einmalig. Danach gehört das System Ihnen. Es skaliert unbegrenzt mit Ihrem Wachstum ohne zusätzliche Lizenzgebühren pro Kopf. Vor allem aber bildet es exakt die Prozesse ab, die Ihren Marktvorteil ausmachen.

Standardsoftware eignet sich hervorragend für Commodity-Prozesse (wie die Buchhaltung). Wenn es jedoch um Ihre Kernwertschöpfung geht, wird der vermeintlich günstigere Standard langfristig fast immer zur teuersten Option.

Ab welchem Punkt lohnt sich eurer Meinung nach der Wechsel von einer gemieteten Standardlösung zu einer eigenen Software?

Es ist ein klassisches Szenario in vielen IT-Projekten: Das UX/UI-Design-Team übergibt ein optisch beeindruckendes Konze...
11/08/2026

Es ist ein klassisches Szenario in vielen IT-Projekten: Das UX/UI-Design-Team übergibt ein optisch beeindruckendes Konzept in Figma. Die Animationen sind elegant, die Layouts hochkomplex. Doch beim Technical Review schlägt das Entwicklungsteam die Hände über dem Kopf zusammen.

Das Urteil: In dieser Form sprengt die Umsetzung das Budget, drückt massiv auf die Performance des Systems oder lässt sich mit der bestehenden Architektur schlicht nicht skalieren.

Das Problem dahinter ist kein mangelndes Talent, sondern das klassische „Silo-Denken“. Wenn Design und Entwicklung als sequenzielle Phasen statt als parallele Prozesse verstanden werden, entstehen Reibungsverluste, die Unternehmen bares Geld kosten. Ein Design kann noch so schön sein – wenn es nicht wirtschaftlich und technisch sauber entwicklungsfähig ist, scheitert das Projekt an der Realität.

Bei Scitotec lösen wir diese Schnittstellen-Problematik durch einen radikal integrativen Ansatz.

1. Entwickler sitzen ab Tag 1 mit am Designtisch
Ein Softwarearchitekt gehört nicht erst in die Implementierungsphase. Wenn Entwickler bereits bei den ersten Wireframes und User Flows Feedback geben, können technische Blocker (wie inkompatible Drittsystem-Schnittstellen oder Performance-Flaschenhälse) erkannt werden, bevor die erste Zeile Code geschrieben oder das finale UI gerendert ist.

2. Design-Systeme statt loser Figma-Files
Ein reibungsloser Hand-off basiert auf einer gemeinsamen Sprache. Durch den Aufbau konsistenter Design-Systeme definieren wir UI-Komponenten, Abstände und Logiken so, dass sie direkt in wiederverwendbaren Code (z. B. React- oder Vue-Komponenten) übersetzt werden können. Das spart Wochen an doppelter Arbeit.

3. Machbarkeit schlägt optischen Overkill
Gutes UX/UI-Design zeichnet sich nicht durch maximale Komplexität aus, sondern durch die perfekte Balance aus exzellenter User Experience und technischer Machbarkeit. Echte Fachkompetenz bedeutet, zu wissen, wann eine Standardkomponente die bessere wirtschaftliche Entscheidung ist als eine maßgeschneiderte Sonderlösung.

Der Erfolg digitaler Produkte entscheidet sich an der Schnittstelle zwischen Kreativität und Code. Nur wenn beide Disziplinen von Beginn an Hand in Hand arbeiten, entstehen Lösungen, die sowohl den Nutzer begeistern als auch das Budget schonen.

Die Versprechungen rund um KI-Code-Generatoren und No-Code-Plattformen sind enorm: Softwareentwicklung per Knopfdruck, A...
04/08/2026

Die Versprechungen rund um KI-Code-Generatoren und No-Code-Plattformen sind enorm: Softwareentwicklung per Knopfdruck, Anwendungen ohne Programmierkenntnisse, das vermeintliche Ende der klassischen Individualsoftware.

Als IT-Dienstleister betrachten wir diese Entwicklung ohne Berührungsängste, aber mit dem realistischen Blick der Praxis. Die Wahrheit ist: Für Standardaufgaben sind diese Tools großartig. Einfache Landingpages, standardisierte Web-Formulare oder erste Klick-Dummys lassen sich damit effizienter umsetzen als je zuvor. Auch wir bei Scitotec nutzen KI-Tools im Entwicklungsalltag, um Routineprozesse zu beschleunigen und schneller ans Ziel zu kommen. Die Grenze dieser Tools wird jedoch dort erreicht, wo Software echten Wettbewerbsvorsprung generieren muss.

Wenn es um hochkomplexe Intranetlösungen, geschäftskritische Data Warehouses oder maßgeschneiderte Business-Analyse-Systeme geht, scheitert die automatisierte Generierung an drei wesentlichen Faktoren:

1. Softwarearchitektur im Kontext: KI generiert Codefragmente auf Basis bestehender Muster. Sie versteht jedoch nicht die historisch gewachsene IT-Infrastruktur eines Unternehmens, die spezifischen Schnittstellenabhängigkeiten oder die langfristige Skalierungsstrategie. Ein stabiles Fundament braucht nach wie vor menschliche Softwarearchitekten.

2. Menschliches UX/UI-Verständnis: Ein Algorithmus kann Layouts optimieren, aber er versteht keine menschliche Psychologie, keine individuellen Workflows von Mitarbeitern im Mittelstand und keine nuancierte Markenidentität.

3. Haftung und Wartbarkeit: Wer Code per Prompt erzeugt, baut oft eine Blackbox. Wenn im Produktivsystem ein kritischer Fehler auftritt, haftet keine KI. Individualsoftware zeichnet sich dadurch aus, dass jede Zeile Code verstanden, gewartet und flexibel weiterentwickelt werden kann.

Das Fazit: KI ersetzt nicht die Individualsoftware, sie verändert nur das Werkzeugset. Die Kombination aus technologischer Innovationskraft und menschlicher Architektur-Expertise bleibt der Schlüssel für zukunftssichere IT-Projekte.

Im Produktmanagement von Startups und Mittelständlern steht die Velocity meist an oberster Stelle. Das Ziel ist klar: Da...
28/07/2026

Im Produktmanagement von Startups und Mittelständlern steht die Velocity meist an oberster Stelle. Das Ziel ist klar: Das MVP (Minimum Viable Product) muss so schnell wie möglich an den Markt, um echtes Nutzerfeedback einzusammeln.

Die Praxis in der IT-Beratung zeigt jedoch regelmäßig einen kritischen Denkfehler: Schnelligkeit wird zu oft mit dem Verzicht auf softwarearchitektonische Substanz verwechselt. Wer hier am falschen Ende spart, baut unbewusst massive technische Schulden auf. Das bittere Erwachen folgt meist 6 bis 12 Monate nach dem Launch: Jedes neue Feature dauert plötzlich dreimal so lange, die Performance bricht ein und der Code wird zum Innovationskiller. Ein erfolgreiches MVP reduziert deshalb die Funktionstiefe, niemals die Architekturqualität.

Wo Abstriche im ersten Release sinnvoll sind:
- Der Funktionsumfang: konsequenter Verzicht auf „Nice-to-have“-Features. Nur der absolute Kernwert gehört in den Release.
- Prozess-Automatisierung: Im Hintergrund dürfen Prozesse anfangs noch manuell oder über einfache Workarounds laufen, solange es die Skalierung nicht behindert.

Wo Kompromisse das Unternehmen später doppelt so viel kosten:
- Die Datenbankarchitektur: Ist das Datenmodell von Anfang an unsauber aufgesetzt, ist eine spätere Skalierung ohne teures und riskantes Refactoring (Neubau) kaum möglich.
- Die IT-Sicherheit: Datensicherheit ist kein Feature, das man nachrüsten kann. Ein Sicherheitsleck beim Launch beschädigt die Reputation nachhaltig.
- UX/UI-Grundlagen: Die Kern-User-Experience muss intuitiv sein. Frustrierte Erstnutzer kommen nicht zurück, um die zweite Version zu sehen.

Fazit für die Praxis: Software ist dann „gut genug“ für den Release, wenn das Fundament stabil steht, während das Haus darauf noch wachsen kann.

Wer am Fundament spart, zahlt später doppelt. Lieber ein fehlerhaftes, schnelles Release oder ein verspätetes, aber stabiles Produkt? Was ist eure Philosophie?

In vielen Softwareprojekten ist am Anfang noch ziemlich klar, was erreicht werden soll. Dann kommen neue Anforderungen d...
21/07/2026

In vielen Softwareprojekten ist am Anfang noch ziemlich klar, was erreicht werden soll. Dann kommen neue Anforderungen dazu.

- Ein zusätzlicher Export.
- Ein Sonderfall aus der Fachabteilung.
- Eine Regel, die "eigentlich nur für wenige Fälle" gilt.
- Eine Maske, die man "bei der Gelegenheit" gleich mitbauen könnte.

Für sich genommen ist das oft alles nachvollziehbar. Das Problem entsteht nicht durch eine einzelne neue Idee. Das Problem entsteht, wenn nichts mehr wirklich eingeordnet wird. Wenn niemand priorisiert, wird alles wichtig. Wenn der Scope aus dem Blick gerät, wird aus einem klaren Ziel irgendwann eine Sammlung guter Wünsche. Und wenn es auf dieser Ebene keinen echten Entscheider gibt, bleibt am Ende alles im Projekt hängen. Die Fachabteilung wünscht sich etwas, die IT bewertet den Aufwand und die Projektleitung versucht zu vermitteln.

Aber irgendjemand muss sagen können, was jetzt wirklich in den Scope gehört und was bewusst nicht. Aus meiner Sicht scheitert Scope selten nur an fehlender Disziplin. In der Regel scheitert er daran, dass Entscheidungen vermieden werden. Und genau das wird später teuer. Nicht jede gute Idee gehört sofort in die erste Version. Manchmal ist die wichtigste Projektentscheidung die, etwas bewusst wegzulassen.

Wie erlebt ihr das in Projekten? Fehlt eher die Priorisierung oder fehlt am Ende der klare Entscheider?

Alte Software ist nicht automatisch schlecht.Viele individuelle Lösungen, Plugins oder Erweiterungen laufen seit Jahren ...
14/07/2026

Alte Software ist nicht automatisch schlecht.

Viele individuelle Lösungen, Plugins oder Erweiterungen laufen seit Jahren zuverlässig. Sie sind oft nah an den echten Prozessen entstanden und haben sich im Alltag bewährt. Genau deshalb ist ein kompletter Neustart nicht immer der beste erste Schritt. Schwierig wird es erst, wenn jede Änderung zur kleinen Operation am offenen Herzen wird. Wenn ein Plugin nur noch vorsichtig angefasst wird, weil niemand sicher sagen kann, welche Nebenwirkung das nächste Update hat. Oder wenn eine eigentlich einfache Anforderung plötzlich unverhältnismäßig viel Aufwand erzeugt.

Dann entsteht schnell der Wunsch, alles einmal neu zu machen.
- Alles sauber.
- Alles modern.
- Alles auf einmal.

Das klingt verlockend, ist aber oft der schmerzhafteste Weg. Bei einer Big-Bang-Modernisierung kommt vieles gleichzeitig zusammen: alte Daten, gewachsene Abläufe, Schnittstellen, Sonderfälle, Gewohnheiten und Erwartungen der Nutzer. Deshalb ist Modernisierung für mich selten ein Abriss. Eher eine Sanierung bei laufendem Betrieb. Manchmal reicht es, ein bestehendes System zuerst sauberer anzubinden oder eine bessere Oberfläche davorzusetzen. Manchmal ist es sinnvoller, einzelne problematische Bereiche herauszulösen und neu zu bauen. Und manchmal ist ein vollständiger Ersatz richtig, aber eben nicht als Reflex, sondern als bewusste Entscheidung.

Legacy ist nicht das eigentliche Problem. Teuer wird es, wenn ein System irgendwann nicht mehr verändert werden kann.

Ich glaube, viele ERP-Probleme entstehen nicht durch eine falsche Softwareentscheidung. Sie entstehen dadurch, dass Anfo...
07/07/2026

Ich glaube, viele ERP-Probleme entstehen nicht durch eine falsche Softwareentscheidung. Sie entstehen dadurch, dass Anforderungen zu schnell umgesetzt werden, ohne vorher sauber über Ziele, Daten und Prozesse zu sprechen.

Im Lebenszyklus eines ERP-Systems entstehen immer wieder neue Anforderungen. Das ist völlig normal. Unternehmen verändern sich, Prozesse werden angepasst, Produkte werden komplexer, Schnittstellen kommen hinzu und Fachbereiche brauchen neue Möglichkeiten.

Problematisch wird es, wenn jede Anforderung sofort umgesetzt wird, nur weil es technisch schnell möglich ist. Ohne genau zu klären, welches Problem eigentlich gelöst werden soll. Ohne zu prüfen, welche Auswirkungen die Änderung auf Datenstruktur, Bedienbarkeit, Prozesse und angebundene Systeme hat.

Ich habe erlebt, wie ein Unternehmen von SAP auf eine andere ERP-Lösung gewechselt ist, weil diese zunächst flexibler und leichter anpassbar wirkte. Am Anfang sah das nach einer guten Entscheidung aus. Die ersten Wünsche wurden schnell umgesetzt, vieles schien einfacher.

Schwierig wurde es später, als Produkte sauber spezifiziert, kombiniert und in bestehende Abläufe eingebunden werden sollten. Dinge, die man eigentlich als Standard erwarten würde, waren plötzlich keine Selbstverständlichkeit mehr. Änderungen wurden durchgewunken. Konkrete Ziele wurden zu wenig diskutiert. Schnittstellen zu Drittsystemen wurden nicht konsequent mitgedacht. Die Datenstruktur wurde immer schwerer beherrschbar und die Datenqualität hat sichtbar gelitten.

Am Ende steht nun wieder ein Neustart im Raum. Für mich zeigt genau das: Datenqualität entsteht nicht durch ein ERP-System allein. Sie entsteht durch klare Verantwortung, saubere Prozesse und ehrliche Gespräche über Ziele, Probleme und Konsequenzen. Ja, Konzeption kostet Zeit. Sie braucht Geduld und manchmal auch Kompromisse. Aber diese Investition ist oft deutlich günstiger als ein System, das zwar schnell angepasst wurde, später aber kaum noch zu bedienen ist.

Wer auf einer Geschäftsreise von einem Kunden eingeladen wird oder selbst Geschäftspartner zum Essen ausführt, steht am ...
02/07/2026

Wer auf einer Geschäftsreise von einem Kunden eingeladen wird oder selbst Geschäftspartner zum Essen ausführt, steht am Monatsende oft ratlos vor der Reisekostenabrechnung. Hier hält sich ein steuerlicher Mythos hartnäckig: „Wenn mein Chef das Essen nicht direkt bestellt hat, muss ich auch nichts kürzen.“

Das klingt zwar logisch, ist steuerlich aber falsch und gefährlich. Das Finanzamt schaut hier nämlich ganz genau hin.

Hier ist die einfache und rechtlich korrekte Erklärung, wie es wirklich läuft:
Das Gesetz ($9 Abs. 4a EStG) sagt vereinfacht: Die Verpflegungspauschale ist dafür da, deine Zusatzkosten für Essen auf Reisen auszugleichen. Wenn du auf Dienstreise eine Mahlzeit bekommst, für die du selbst keinen Cent bezahlst, hast du diese Zusatzkosten nicht. Folge: Deine Pauschale muss gekürzt werden, und zwar um 20 % fürs Frühstück und je 40 % für Mittag- oder Abendessen.

Schauen wir uns die zwei typischen Situationen an:

Situation A: Ein Geschäftspartner lädt DICH ein. Du bist auf Dienstreise und ein Kunde sagt: „Komm, ich lade dich zum Mittagessen ein.“

Die Wahrheit: Du musst deine Verpflegungspauschale kürzen. Warum? Weil das Treffen geschäftlich ist. Das Finanzamt sagt: Du sitzt dort im Auftrag deines Arbeitgebers. Damit ist das Essen „auf Veranlassung des Arbeitgebers“ spendiert worden. Einen steuerfreien „Bonus“ gibt es hier leider nicht.

Situation B: Du lädst einen Geschäftspartner ein (Bewirtung). Du gehst mit einem Kunden essen, zahlst mit der Firmenkreditkarte (oder streckst das Geld vor) und reichst die Quittung als Bewirtungskosten bei deiner Firma ein.

Die Wahrheit: Auch hier musst du deine Pauschale kürzen. Am Tisch wurde zwar verhandelt, aber dein eigenes Essen hat am Ende des Tages die Firma bezahlt. Du hattest also keine eigenen Kosten für dein Mittag- oder Abendessen.

Adresse

Otto-Schwade-Str. 8
Erfurt
99085

Öffnungszeiten

Montag 09:00 - 17:00
Dienstag 09:00 - 17:00
Mittwoch 09:00 - 17:00
Donnerstag 09:00 - 17:00
Freitag 09:00 - 17:00

Webseite

Benachrichtigungen

Lassen Sie sich von uns eine E-Mail senden und seien Sie der erste der Neuigkeiten und Aktionen von Scitotec GmbH erfährt. Ihre E-Mail-Adresse wird nicht für andere Zwecke verwendet und Sie können sich jederzeit abmelden.

Service Kontaktieren

Nachricht an Scitotec GmbH senden:

Verknüpfungen

Teilen

Kategorie