Software > Softwaresuche / Ausschreibungen > Immobiliendienstleister sucht Standardsoftware zur Dokumentation von Prüfungen gemäß DGUV Vorschrift 3

Immobiliendienstleister sucht Standardsoftware zur Dokumentation von Prüfungen gemäß DGUV Vorschrift 3

Suche / Ausschreibung von: ImmobiliendienstleisterProjekt Nr. 20/2296, bis: 16. Okt. 2020

Wir sind ein führender Immobiliendienstleister (Bereiche z.B. Facility Management, Gebäudetechnik) und suchen eine Standardsoftware zur Dokumentation von Prüfungen gemäß DGUV Vorschrift 3. Sie soll nicht extra für uns entwickelt werden, sondern wir möchten eine bestehende (Standard-)Software beschaffen. Es wird eine Schnittstelle zu MS Navision und perspektivisch zu MS Outlook, MS Excel, BOX.net benötigt.

1 Einleitung

1.1 Ausgangssituation

Das bisher genutzte Software Tool zur Dokumentation von Prüfungen gemäß DGUV basiert auf überholten Technologien. Aufgrund der eingeschränkten Funktionalität und Performance sowie zur Umsetzung neuer Anforderungen an die Software, wird ein neues Produkt benötigt. Das neue Produkt soll eine zeitgemässe Architektur besitzen und in den nächsten Jahren skalierbare Funktionalitäten aufweisen. Nachfolgend werden die maßgeblichen Anforderungen an das gesuchte Software Tool genannt.

1.2 Ziele

Wesentliches Ziel des neuen Software Tools ist die Optimierung der Prozesse von der Auftragserstellung bis zur Dokumentation beim Kunden. Dazu sind folgende Aspekte zu betrachten.

Aspekte und Ziele des Prüftools

  • Datenbankperformance
    Insbesondere bei einer großen Anzahl von Daten (> 20 Tsd.) soll eine gleichmäßige und schnelle Bedienbarkeit des Systems sichergestellt sein
  • Verwaltungsaufwand
    Die händische Datensicherung im Zentralsystem soll mit einer automatisierten Sicherung der mobilen Anwendung im Zentralsystem generell nicht mehr notwendig sein.
  • Projektabschluss
    • Nach Abschluss der Leistungen beim Kunden soll eine möglichst einfache Aufmaßerstellung auf Basis der Preismerkmale möglich sein.
    • Die Kundenansicht soll möglichst selbständig und ohne großen manuellen Aufwand im Kundenportal erzeugt werden können. Eine Aktualisierung der Kundendaten soll für den Kunden nach jeder Datensicherung der mobilen Anwendungen sichtbar sein.
    • Eine gesonderte Datensicherung und Wiederherstellung der Daten muss sichergestellt sein.

1.3 Nicht-Ziele

Mit der Neuentwicklung sollen keine Prozesse im Unternehmen bzw. in anderen Softwaretools des Unternehmens abgebildete Funktion redundant umgesetzt werden. Erforderliche Schnittstellen sind auf ein Minimum zu beschränken. Ferner soll keine Einschränkung hinsichtlich der Art der Prüfung oder Inhalte im Tool vorhanden sein.

1.4 Stakeholder

Folgende Beteiligte sind in das Projekt involviert:

  • Anwendergruppe - Nutzung des Prüftools stationär und mobil
  • IT - Betrieb der IT-Infrastruktur, Endgeräte, Server, Zugriffe extern
  • Navision Team - Schnittstellen Prüftool / ERP – bereitstellen und betreuen
  • Vertrieb - Kundenmehrwert der digitalen Dokumentation vermarkten
  • Anbieter Prüftool - Bereitstellen, Warten und Fortschreiben der Software
  • Kunde - Nutzung der Prüfdokumente ggf. digitale Abrechnung

 

2 Allgemeine Übersicht

2.1 Systemkontext und -schnittstellen

Die Software soll aus einer Kombination aus einem zentralen Verarbeitungssystem (Web Anwendung) und einer mobilen Komponente, welche für Tabletts/Laptops optimiert ist, bestehen. Die zentrale Anwendung dient einerseits zur Verwaltung der Transaktion von Prüfaufträgen und andererseits der Veröffentlichung der Prüfprotokolle für den Kunden. Die mobile Anwendung dient zur Auftragsbearbeitung durch die Techniker und Bearbeiter beim Kunden. Es soll möglich sein, Schnittstellen zur Groupware (Outlook) sowie zum kaufmännisch führenden System (Navision) zu realisieren.

2.2 Kurzbeschreibung und Einsatzgebiet der anzubindenden Systeme

Eine unserer Aufgabe ist die Prüfung elektrischer Geräte und anderer Facilities mittels standardisierter Checklisten. Bei der Prüfung von Objekten werden in Abhängigkeit der Ergebnisse auch andere Dienstleistungen (z.B. Kleinreparaturen oder der Austausch von Komponenten) flexibel passend zur Situation realisiert. Für die dauerhafte digitale Dokumentation werden die Prüfobjekte eindeutig identifizierbar codiert, um Änderungen bei wiederkehrenden Prüfungen bei Stamm- und Bewegungsdaten nachvollziehen zu können. Nachfolgend werden die wesentlichen Schritte, die mit der Software unterstützt werden sollen, dargestellt.

2.3 Kurzbeschreibung weiterer Systeme für evtl. zukünftige Anbindungen

2.3.1 Kalender
Zur Unterstützung der Ressourcenplanung soll es möglich sein, im System vorhandene Termine und Fristen zu verplanen. Eine Schnittstelle zu einer Groupware (z.B. MS Exchange) oder clientseitigen Kalendern (z.B. Outlook) ist ebenso denkbar wie eine integrierte Planungslösung.

2.3.2 ERP
Für die Integration des Prüftools in die kaufmännischen Prozesse ist die Integration in die aktuell verwendete Software MS Navision die Zielrichtung. Die Schnittstelle besteht dabei aus mehreren zu transportierenden Datencontainern (IN = Input in Prüftool; OUT = Output aus Prüftool).

2.4 Kurzbeschreibung der zukünftigen Anwender

Folgende Anwender werden zukünftig mit der Software arbeiten:

  • Projektleiter: Erstellen von Prüfaufträgen, Planen und kontrollieren der Aufträge, Termine und Leistungsnachweise, Freigabe der Prüfprotokolle für Kunden, Freigabe der Abrechnungsgrundlagen
  • Prüfer: Inventarisierung von Prüfobjekten, Durchführen der Prüfung, Erstellen der Prüfprotokolle, Erstellen von Nachweisen für Zusatzleistungen, Feinplanung der Termine mit dem Kunden, Rückmelden von Leistungen
  • Kunde: Bestätigung von Prüfprotokollen (Unterschrift), Download von Prüfprotokollen
  • Administrator: Nutzerverwaltung, Katalogverwaltung, Konfiguration und Kontrolle der Schnittstellen

 

3 Funktionale Anforderungen

3.1 Allgemeine Systemanforderungen

Das Tool soll alle für die Durchführung des Prozesses erforderlichen Schritte unterstützen. Dabei wird besonderer Wert auf standardisierte Objekte und Prozesse gelegt.

Struktur und Systemanforderungen des Prüftools

Abbildung 1: Allgemeine Struktur und Systemanforderungen des Prüftools

3.2 Systemarchitektur

Die nachfolgende Abbildung skizziert die Vorstellung der Systemarchitektur der neuen Softwarelösung.

Systemarchitektur des Prüftools

Abbildung 2: Systemarchitektur des Prüftools

3.3 Generisches Funktionsmodell

Die Software verarbeitet Massendaten mit einer hohen Wiederholungsrate gleicher Funktionen. Dabei spielen Methoden, die zeitliche Ordnung der Objekte sowie Ein- und Ausgaben eine Rolle.

Funktionen des Prüftools

Abbildung 3: Funktionen des Prüftools

3.4 Prozessabbildung

In der Anlage wird der Gesamtworkflow als Flussdiagramm dargestellt. Dieser Prozess besteht aus mehreren Teilprozessen.

Teilprozesse mit Beschreibung:

  • Angebot
  • Auftragseingang
  • Auftragsvorbereitung
  • Auftragsbearbeitung
  • Abrechnung
  • Abschluss

 

4 Qualitätsanforderungen

4.1 Performance

Die Software dient der Verarbeitung von Massendaten. Es werden mehrere tausend Prüfobjekte mit mehreren Messdaten im System erfasst, bearbeitet und über Schnittstellen transportiert.

Für die Reaktions- und Verarbeitungszeiten im System werden folgende Anforderungen gestellt:

  • Seite aufrufen < 3s
  • Suchen < 5s
  • Auswerten < 30s
  • Ausgabe/ Export < 60s, Download und ZIP < 5 min

Die Verarbeitung der Daten erfordert Sicherheit in mehreren Ebenen:

  • Schnittstellen/ Übertragung Datenpakete verschlüsseln
  • Anmeldung und Authentifizierung
  • PW-Regelungen
  • Personenbezogene Daten verschlüsselt ablegen
  • Regelmäßige Sicherheitsupdates

5 Randbedingungen

5.1 Datenmigration

Im bisherigen Tool werden die Geräte- und Prüfdaten für mehr als 150.000 Prüfobjekte gehalten. In das neue Tool sollen die Stammdaten der Orte, Kunden und Prüfobjekte übernommen werden. Diese liegen als MS Access-Datenbank vor. Durch den Anbieter ist ein Mapping dieser Daten in die neue Datenstruktur zu erstellen. Prüfprotokolle können ggf. migriert werden.

Die Messdaten sind nicht zu migrieren.

5.2 Datenexporte

Das System (Zentralsystem) soll in der Lage sein, alle tabellarischen Anzeigen und individuelle Abfragen von Stammdaten in MS Excel zu exportieren.

Es sollen häufig verwendete Listen angelegt und verwaltet werden können.

Für die Änderung von Massendaten ist ein Wiederimport exportierter Listen wünschenswert.

5.3 IT-Unternehmensarchitektur

Die Unternehmensinfrastruktur umfasst umfangreiche intern und extern gehostete Systeme.

Für das Prüftool werden folgende technische Voraussetzungen benötigt:

  • Mob. Endgerät - Tablet/Laptop (MS Windows 10, für Tablets sind iOS und eventuell auch MS Windows und Android zu unterstützen, Crossplattform)
  • Verbindung zum Zentralsystem - Verschlüsselte LAN/WLAN-Verbindung
  • Dokumentationssystem - webbasierte Plattform (BOX.net)
  • Backup - z.B. NAS

5.4 Lieferung und Implementierung von Releases, Updates und Hotfixes

Die Lieferung von Updates, Upgrades oder Patches erfolgt im Zentralsystem nach Abstimmung zwischen Kunde und Softwareanbieter, Die mobilen Anwendungen sollen über die jeweiligen Stores der Betriebssysteme mit Updates versorgt werden, um sicherzustellen, dass alle Endgeräte kompatible Versionen zum Zentralsystem haben. Eine Prüfung ist beim Start der App erfolgen. Treten zwischen zwei Versionen Inkompatibilitäten zwischen App und Zentralem System auf, so ist eine Lösung anzubieten, die die Herstellung der Kompatibilität unterstützt.

5.5 Rechtliche Randbedingungen

Basis des Prüftools sind die Vorschriften der DGUV sowie spezifischer Richtlinien aus dem Bereich VDE, DIN und anderen Normen. Ändert sich die rechtliche Grundlage oder Anforderungen an die im Softwaretool unterstützten Funktionen und Inhalte, sind Updates binnen 6 Monaten ab Inkrafttreten der Änderung durch den Softwareanbieter zu liefern.

5.6 Schnittstellen

Aktuell wird von vier Schnittstellen im System ausgegangen:

  • Navision
  • Outlook
  • Excel
  • BOX.net

5.7 Support und Wartung

Durch den Softwareanbieter sind Serviceleistungen zur Unterstützung des Kunden im Rahmen eines Softwarewartungsvertrags anzubieten. Diese sind insbesondere der Anwendungssupport sowie die regelmäßige Aktualisierung und Fortschreibung des Systems.

6 Anforderungen an das Angebot

Das Angebot soll Varianten der Bereitstellung beinhalten, wobei eine Festlegung seitens des Auftraggebers, welche Variante bevorzugt ist, aktuell noch nicht getroffen wurde:

  • Kauf – Betrieb durch Kunde
  • Kauf – Betrieb durch Anbieter
  • SaaS

Durch den Anbieter ist die Art der Lizensierung bekannt zu geben.

Wichtig sind verschiedene Servicelevel für die Softwarelösung im Betrieb.

Die Anzahl der Arbeitsplätze wird wahrscheinlich im zweistelligen Bereich liegen.

 

Hinweis von SoftGuide: Ein detailliertes Lastenheft kann gegebenenfalls bei SoftGuide angefordert werden.

Wir haben 16 Softwarelösungen recherchiert. Beispielsweise kommen aufgrund der spezifischen Anforderungen folgende Lösungen in Frage:

Software Lösungen finden
Das SoftGuide Rechercheteam erarbeitet weitere potenzielle Lösungen...
Weitere vorgeschlagene Softwarelösungen zu diesem Projekt
Projektdokumentation

Weitere vorgeschlagene Softwarelösungen mit detaillierten Informationen, projektspezifischen Fragestellungen und Antworten sowie strukturierten Vergleichsmöglichkeiten stehen in der Projektdokumentation zur Verfügung:

Projektstatistik (Stand 22.09.2020)

Anzahl
Recherchierte und befragte Lösungen 16
Selektierte potentiell relevante Lösungen (davon veröffentlicht) 9 (5)
Gesendete E-Mails (Fragen, Rückfragen) und Telefongespräche 31
Erhaltene E-Mails von Anbietern 9
Direkte Antworten auf die Ausschreibung 4
Als relevant eingestufte und eingepflegte Antworten 4