future - Limitierungen & technische Voraussetzungen

CHECK-IN

• Beinhaltet sind eine für den normalen Gebrauch unlimitierte Anzahl an einzelnen Aufbereitungs-Runs (getriggert z.B. durch “Zeitreihen vorbereiten” im Schritt 4 des Frontends) pro Benutzerkonto und Monat. Ein Gebrauch von mehr als 500 Aufbereitungs-Runs wird als nicht mehr normal erachtet. Die Daten werden nicht dauerhaft für den Zugriff durch den Nutzer bereitgestellt.
• Je mehr Rohdaten verarbeitet und je mehr Zeitreihen erstellt werden, desto länger dauert die Aufbereitung. Beinhalten die zu verarbeitenden Rohdaten mehr als 250.000 Zeilen und/oder 15 Spalten bzw. werden mehr als 1.000 Zeitreihen erstellt, ist unter Umständen mit Berechnungszeiten von mehr als 15 Minuten zu rechnen oder die Berechnung kann ggf. gar nicht durchgeführt werden.
• Sekunden sowie Zeitzonen in der Datumsspalte werden ignoriert.
• Es können nur Aggregationen (z.B. durch Summierung) auf höhere zeitliche Granularitäten behandelt werden. Disaggregationen werden nicht unterstützt, eine automatische Prüfung der in den Rohdaten vorliegenden kleinsten zeitlichen Abstände findet nicht statt.

FORECAST via futureNOW

• Es erfolgt keine dauerhafte Speicherung der in einer Sitzung erzeugten Analyseergebnisse.
• Die Anzahl der möglichen Backtesting-Prognosen ist abhängig von der verfügbaren Datenhistorie, ggf. sind keine historischen Prognosen möglich.
• Die Qualität der Ergebnisse ist abhängig von der zu Grunde liegenden Datenqualität, insbesondere auch der Länge der Datenhistorie. Bei sehr kurzer Datenhistorie von weniger als zehn Datenpunkten können unter Umständen keine Vorhersagen berechnet werden.

FORECAST via futureEXPERT

• Forecast-Objekte und Kovariaten müssen auf derselben zeitlichen Granularität vorliegen.
• Der Vorhersagezeitraum kann flexibel bis zu einer Länge von 60 eingestellt werden. Damit ein valides Ergebnis erzielt sowie Backtesting-Ergebnisse berechnet werden können, sollte der Vorhersagehorizont ein für die vorliegende Zeitreihe sinnvolles Maß nicht überschreiten. - Grobe Faustregel für eine sinnvolle Einstellung: Vorhersagehorizont nicht größer als das 1,5-fache der für die vorliegende Granularität typischen Saisonlänge bzw. max. 1/5 der Länge der Datenhistorie - je nachdem, was zuerst greift.
• Bei Überschreiten einer gewissen maximalen Länge der Zeitreihe werden in Abhängigkeit von der Granularität der Zeitreihe nur eine gewisse Anzahl an zurückliegenden Datenpunkten berücksichtigt.
• Die Anzahl an Backtesting-Iterationen kann flexibel bis 24 eingestellt werden.
• Prognoseintervalle werden i. d. R. bei allen Forecast-Methoden berechnet, welche modellbasierte Intervallgrenzen liefern (z. B. ARIMA, TBATS, Exponentielle Glättung). Insbesondere bei Machine-Learning-Verfahren (z. B. SVM, Random Forest, CatBoost) sowie Basisverfahren wie z. B. Moving Average werden keine Intervallgrenzen ausgegeben.
• Finales Ranking und Ausgabe von vollständigen Ergebnissen nur für in allen Backtesting-Iterationen sowie für den finalen Forecast erfolgreich optimierten FC-Methoden mit plausiblen Ergebnissen (automatisiert identifiziert durch die Plausibilitätschecks). Im Falle von gar keinem erfolgreich optimierten plausiblen Modell mit vollständigen BT-Ergebnissen werden Forecast-Ergebnisse von wenigen Fallback-Methoden ausgegeben (ohne BT-Ergebnisse). Dies ist z. B. auch dann der Fall, wenn es sich um eine für die Einstellungen zu kurze Zeitreihe handelt, ggf. noch im Zusammenspiel mit einem hohen Vorhersagehorizont.
• Die Qualität der Ergebnisse ist abhängig von der zu Grunde liegenden Datenqualität, insbesondere auch der Länge und lückenlosen Verfügbarkeit der Datenhistorie.
• Die Ersetzung fehlender Werte ist sinnvoll für wenige einzelne fehlende Werte. Eine automatische Überprüfung der Anzahl an fehlenden Werten findet nicht statt. Enthält die Datenhistorie zu viele fehlende Werte (im Extremfall sogar nur zwei Werte verfügbar), werden diese trotzdem ersetzt. Da dies auch die Forecasts entsprechend beeinflusst, sollte auf eine gute Datenbasis geachtet werden.
• Saisonerkennung von multiplen Saisonalitäten ist für bis zu drei Saisonlängen möglich. Dabei müssen die längeren Saisonalitäten jeweils Vielfache der kürzeren sein.
• Die Vorhersagemethode ARIMA ist nur für Forecast-Objekte auf Monats-, Quartals- und Jahresbasis verfügbar. Sollte sie explizit eingestellt werden, wird sie bei niedrigeren Granularitäten automatisch aussortiert und eine Warnung ausgegeben.

MATCHER

• Forecast-Objekte und Kovariaten müssen auf derselben zeitlichen Granularität vorliegen.
• Eine Analyse ist für glatte und erratische Forecast-Objekte möglich, nicht für sporadische oder geklumpte (lumpy). (Weitere Informationen zu den verschiedenen Zeitreihenklassen.)
• Für eine Berechnung ist eine ausreichend lange gemeinsame Datenhistorie zwischen Forecast-Objekt und Kovariaten erforderlich. Der gemeinsam überlappende Zeitraum muss dabei im Default mindestens die Länge von viermal der für die Granularität typischsten Saisonlänge plus 14 Datenpunkte aufweisen. Im Monatsdatenfall entspricht das z.B. der Länge von 62 (4*12+14). Werden die zu analysierenden Lags selbst eingestellt, so ist die Mindestlänge des gemeinsamen Zeitraums ggf. noch länger (abhängig vom maximalen Lag, ggf. in Kombination mit minimalem Lag, sofern dieser negativ ist). Die Analysen werden nur für diejenigen Kovariaten, welche die Bedingungen an den gemeinsamen Zeitraum zusammen mit dem Forecast-Objekt erfüllen, durchgeführt. Die anderen werden automatisch ausselektiert.
• Es können nur Ergebnisse von Einflussfaktoren von Modellen mit vollständigem Backtesting-Ergebnis berücksichtigt werden (z. B. erfolgreiche Optimierung in jedem Backtesting-Schritt).
• Es findet eine bivariate Analyse zwischen Forecast-Objekt und jeder Kovariate einzeln statt, es werden nicht mehrere Einflussfaktoren gleichzeitig (in Kombination) oder deren Wechselwirkungen untereinander untersucht.
• Je mehr fehlende Werte die Forecast-Objekte oder Kovariaten aufweisen, desto stärker sind die Analyseergebnisse von den Ersatzwerten beeinflusst. Eine Ersetzung findet unabhängig von der Anzahl an fehlenden Werten statt.
• Bei Überschreiten einer gewissen maximalen Länge der Zeitreihe werden in Abhängigkeit von der Granularität der Zeitreihe nur eine gewisse Anzahl an zurückliegenden Datenpunkten berücksichtigt.
• Die maximale Anzahl von gleichzeitig zu prüfenden zeitlichen Verschiebungen (Lags) der Kovariaten zu den Forecast-Objekten in einem Lauf ist 15. Im Default ist dies immer gewährleistet durch die automatische Logik. Dabei werden die Lags von -2 bis zum Minimum aus 12 und der Hälfte der für die Granularität typischsten Saisonlänge (48 bei halbstündlich, 24 bei stündlich, 7 bei täglich, 52 wöchentlich, 12 bei monatlich, 4 bei quartalsweise) geprüft.

POOL

• Über den POOL bereitgestellte Einflussfaktoren werden nicht notwendigerweise in ihrer ursprünglichen Form bereitgestellt, sondern teilweise zum Zwecke der Analyse verändert (Beispiel: Herunterbrechen von Monatsindikatoren auf Tagesbasis). Es wird nicht offen gelegt, wie sich der Indikator exakt zusammensetzt.
• Es besteht kein Anspruch auf Aktualität der im POOL verfügbaren Einflussgrößen: Einflussfaktoren werden in der Form benutzt, wie sie zum Zeitpunkt der Verwendung in future vorliegen. Dieser Zeitpunkt entspricht nicht notwendigerweise dem Veröffentlichungsdatum der neuen Indikatorwerte in Bezug auf die Quelle.

Technische Voraussetzungen

• Voraussetzung für die Nutzung der Leistungen von prognostica mittels der SaaS-Lösung future sind ein Endgerät sowie eine aktive Internetverbindung zur Nutzung der Software.
• futureNOW ist auf eine Verwendung des Endgeräts PC mit Maus und Tastatur optimiert. Bei Verwendung von Smartphones oder anderen mobilen Endgeräten können Einschränkungen in der Nutzung auftreten. Um die Software zu verwenden, ist ein fähiger Browser notwendig. Wir empfehlen und testen die Verwendung von Chrome (“stable Channel”), Edge (“Stable-Kanal”), Firefox (“default channel”) oder Safari in den aktuellen Versionen oder die jeweiligen zwei Updates vor der aktuellen Version.
• futureEXPERT bietet eine Python-Bibliothek zur Kommunikation mit der future-SaaS-Plattform und erfordert dafür eine Python-Umgebung ab Version 3.9. (Für die Nutzung der zur Verfügung gestellten Jupyter-Notebooks mit Beispielen ist Jupyter erforderlich.)

Limitierungen

• prognostica stellt mittels future kein dauerhaftes Speichersystem für die Daten und Ergebnisse bereit.
• Ergebnisse von futureNOW werden i. d. R. unmittelbar bei Verwendung der App bzw. nach dem Starten der Berechnungen bereitgestellt.
• Ergebnisse von futureEXPERT werden i. d. R. je nach Art der Ergebnisse für einen oder mehrere Tage vorgehalten.
• Der Kunde ist selbst verpflichtet, die erzeugten Ergebnisse von futureEXPERT und futureNOW sowie von ihm hochgeladene Daten dauerhaft in seinen Systemen abzulegen, sofern eine dauerhafte Speicherung gewünscht ist.

Supportleistungen

• Die E-Mail-Adresse support@future-forecasting.de steht für direkten Kontakt mit unserem Support zur Verfügung. Insbesondere können auf diesen Wegen Mängelmeldungen zu future getätigt werden und Anfragen zur Aufnahme weiterer Funktionalitäten in future gestellt werden. Bei letzterem besteht keine Verpflichtung seitens prognostica, diese Funktionalitäten umzusetzen und bereitzustellen. Zudem besteht im futureEXPERT -GitHub-Projekt die Möglichkeit, über Issues mit uns in Verbindung zu treten.
• Weitere Supportleistungen, wie beispielsweise Schulungen zur Nutzung der Software, sind nicht in den direkt buchbaren Abo-Paketen Basis, Standard und Premium von future enthalten und müssen, falls gewünscht, separat hinzugebucht werden, z. B. möglich über das Paket Enterprise. Zudem fällt bei nicht erbrachter bzw. nicht vollständig und/oder korrekt erbrachter Mitwirkungspflicht des Kunden eine zusätzliche Vergütung des dadurch verursachten Mehraufwandes an. Hierfür werden Kosten i.H.v. 108 EUR zzgl. USt pro Stunde in Rechnung gestellt, wobei je 1/12 des Stundensatzes für eine angefangene Fünf-Minuten-Einheit abgerechnet wird.