1. CEL PROJEKTU

Opis biznesowy:

Zakres funkcjonalny (co ma konfigurować):

Skrzynki łączeniowe (Ex e / Ex i / Ex d)
Panele sterowania (Ex e / Ex d)
Inne (opcjonalnie)

Wynik końcowy (np. plik PDF, BOM, oferta, itp.):

Plik PDF z ofertą
BOM (Bill of Materials)
Konfiguracja do systemu ERP
Pliki CAD

2. ZAKRES SYSTEMU

2.1 Typy użytkowników

Handlowiec
Inżynier
Klient końcowy (tak/nie)

2.2 Główne moduły

Wybór typu urządzenia i obudowy
Dobór komponentów
Sprawdzanie zgodności technicznej / ATEX
Wizualizacja (2D/3D?)
Generowanie dokumentacji / BOM / oferty
Integracje (ERP, magazyn, cenniki, CAD, itp.)

2.3 Zakres faz (MVP vs pełna wersja)

MVP będzie obejmować podstawową funkcjonalność, pełna wersja zostanie rozbudowana o dodatkowe moduły i integracje.

3. WYMAGANIA FUNKCJONALNE

Lista funkcji z priorytetem:

MUST: Konfiguracja podstawowych produktów, walidacja techniczna, generowanie BOM i PDF.
SHOULD: Wizualizacja 2D, integracja z cennikiem, obsługa wersji.
NICE TO HAVE: Wizualizacja 3D, integracja z CAD, dostęp dla klienta końcowego.

4. WYMAGANIA TECHNICZNE

Technologia front-end: Do ustalenia (np. React, Angular)
Technologia back-end: Do ustalenia (np. .NET, Java, Node.js)
Baza danych: Do ustalenia (np. SQL, NoSQL)
Hostowanie: Aplikacja webowa (wewnętrzna / publiczna)
Integracje: API (REST/SOAP)
Bezpieczeństwo: System ról i uprawnień
Wersjonowanie: Tak

5. LOGIKA KONFIGURACJI

Reguły techniczne (np. max ilość otworów)
Zgodność z certyfikacją / strefami Ex
Ograniczenia wymiarowe
Automatyczna walidacja

6. PROCES UŻYTKOWANIA (USER FLOW)

Start → Konfiguracja → Walidacja → Wynik (BOM / oferta / plik / zamówienie)

7. DANE WEJŚCIOWE

Biblioteka obudów
Biblioteka komponentów
Cenniki
Normy / certyfikaty
Szablony dokumentów

8. DANE WYJŚCIOWE

BOM
Schemat / rysunek / CAD
Oferta / PDF
Kod produktu / SKU
Dane do ERP / CRM

9. INTERFEJS UŻYTKOWNIKA

Layout: Intuicyjny, krok po kroku
UX wymagania: Minimalizacja kliknięć, podgląd na żywo
Języki interfejsu: Polski, Angielski
Responsywność: Desktop, Tablet

10. ZESPÓŁ I ODPOWIEDZIALNOŚCI

Product Owner
Analityk
Programista front-end
Programista back-end
QA / Tester
Ekspert ATEX / techniczny

11. HARMONOGRAM (ETAPY)

Analiza i specyfikacja: [Start] – [Koniec]
Architektura i UX prototyp
Implementacja rdzenia konfiguratora
Integracje
Testy techniczne
Testy użytkownika (UAT)
Dokumentacja i szkolenia
Wdrożenie MVP
Rozwój funkcji rozszerzonych

12. RYZYKA I OGRANICZENIA

Braki danych technicznych
Złożoność logiki
Zmiany wymagań
Zależność od innych systemów
Certyfikacja

13. KPI / SUKCES PROJEKTU

Skrócenie czasu przygotowania oferty z X do Y
Zmniejszenie liczby błędów
Samodzielność handlowca / klienta
Wzrost konwersji

14. UTRZYMANIE I ROZWÓJ

Aktualizacje komponentów
Dodawanie nowych produktów
Feedback użytkowników
Wsparcie techniczne

Propozycja uzupełnienia specyfikacji

1. Propozycja podziału na wersje (MVP vs Pełna Wersja)

1.1 MVP (Minimum Viable Product)

✅ Dobór obudowy na podstawie liczby i typu terminali oraz dławików.
✅ Generowanie BOM (Bill of Materials) w formacie PDF.
✅ Integracja z bazą cennikową w celu podstawowej wyceny.

1.2 Pełna Wersja

📋 Interaktywna wizualizacja 2D produktu.
📋 Generowanie plików CAD (np. STEP) oraz plików dla maszyn CNC.
📋 Pełna, dwukierunkowa integracja z systememami.
📋 Uruchomienie publicznej wersji konfiguratora dla klienta końcowego.
📋 Moduł symulacji i weryfikacji zgodności termicznej

2. Kluczowe obszary do uzupełnienia (Braki)

✗ Jasne zdefiniowanie MVP vs Full Version: Należy formalnie zatwierdzić powyższy podział i szczegółowo opisać każdą funkcję.
✗ Priorytetyzacja funkcji: Należy przypisać każdej funkcji priorytet (MUST / SHOULD / NICE TO HAVE), aby elastycznie zarządzać zakresem projektu.
✗ Definicja metryk sukcesu (KPI): Konieczne jest zdefiniowanie mierzalnych wskaźników sukcesu projektu.

Propozycja KPI:

Cel: Skrócenie czasu przygotowania oferty o 70% (z obecnych X godzin do Y minut).
Cel: Zmniejszenie liczby błędów w konfiguracjach i ofertach o 90% w ciągu pierwszych 6 miesięcy.
Cel: Umożliwienie 80% handlowców samodzielnego tworzenia ofert bez wsparcia działu inżynieryjnego.
Cel: Wzrost konwersji zapytań ofertowych o 15% w ciągu roku od wdrożenia pełnej wersji.

3. Potrzeba danych do testowania aplikacji

Do prawidłowego rozwoju i przetestowania aplikacji niezbędne są rzeczywiste, zróżnicowane dane i przykłady konfiguracji. Im więcej przykładów otrzymamy na wczesnym etapie, tym lepiej konfigurator będzie odpowiadał realnym potrzebom i tym mniej błędów wystąpi po wdrożeniu.

Podstawowe pojęcia:
- Jak nazywamy to, co tworzymy? “Konfiguracja”, “Projekt”, “Zestawienie”, “Produkt na zamówienie”? Ustalmy jedno, spójne określenie.
- Jakie są główne “klocki” (obiekty), z których składa się konfiguracja? (np. Obudowa, Dławik, Terminal, Szyna DIN, Zaślepka, Przycisk).
- Jakie są kluczowe “akcje” lub “decyzje” w procesie? (np. “Dobór”, “Rozmieszczenie”, “Weryfikacja”, “Wycena”, “Generowanie”).
- Jakie są stany, w jakich może być nasza Konfiguracja? (np. “Nowa”, “W trakcie edycji”, “Zwalidowana”, “Błędna”, “Zakończona”).

Tożsamość i cykl życia Konfiguracji:
- Co musi się stać, żeby Konfiguracja w ogóle mogła powstać? Czy zaczynamy od wyboru typu produktu (np. “Skrzynka łączeniowa Ex e”), czy od wyboru klienta?
- Jakie informacje są absolutnie niezbędne na samym początku? (np. Strefa Ex, wymagany certyfikat, nazwa projektu).
- Kiedy Konfiguracja jest uznawana za kompletną?

Pytania o Dławiki (Glands):

Jakie parametry definiują dławik? (Typ gwintu, średnica kabla, materiał, typ Ex).

Jakie są kluczowe atrybuty terminala? (Przekrój przewodu, prąd znamionowy, napięcie, typ Ex – np. Ex e vs Ex i).
Jakie są zasady ich montażu i doboru? (REGUŁY):

Specyfikacja Projektu: Konfigurator Produktów