Projekty, które dowieźliśmy

Problem

Sieć hotelowa, w której każdy obiekt ma własną skrzynkę recepcyjną, a ponad nimi działa skrzynka ogólna zbierająca wszystko, co wykracza poza pojedynczą recepcję. Do tego dochodzą rezerwacje z zewnętrznych portali. Setki maili dziennie – rezerwacje, zmiany terminów, zapytania grupowe, faktury i spam – które ktoś musiał ręcznie rozdzielać między obiekty i działy.

Jak to rozwiązaliśmy

Zbudowaliśmy silnik reguł, którego zestaw powstał ramię w ramię z hotelarzami: o przekazaniu maila decydują nadawca, domena, temat i treść. Na wierzchu postawiliśmy warstwę AI, która bierze na siebie wyłącznie przypadki niepewne i rozstrzyga, czy wiadomość jest rezerwacją. Człowiek dostaje dziś tylko to, co naprawdę wymaga decyzji.

Problem

Zwroty obsługiwane w pełni ręcznie – klient składał je w salonie albo przez biuro obsługi, a pracownik przeklikiwał każdą sprawę osobno. Marka prowadzi kilka niezależnych sklepów i nie było jednego miejsca, w którym widać wszystkie zamówienia klienta oraz to, co faktycznie wolno mu jeszcze zwrócić.

Jak to rozwiązaliśmy

Zbudowaliśmy panel self-service, który po adresie e-mail lub numerze telefonu zaciąga zamówienia klienta ze wszystkich sklepów Magento 2 naraz i pokazuje, co może zwrócić, a czego już nie – bo minął termin albo przesyłka nie dotarła. Spięliśmy go z systemem Comarch XL oraz z kurierami InPost i DPD, więc system zna realny status paczki i sam rozstrzyga zasadność zwrotu.

Problem

Źródłem prawdy o magazynie, zamówieniach i dostawach jest system Comarch XL – o dużej złożoności i rozbudowanej strukturze tabel. Odpytywanie go wprost ze sklepu było ryzykowne podwójnie: kod e-commerce musiałby znać wewnętrzne bebechy ERP, a ruch ze sklepu obciążał bazę Comarch XL i zakładał na niej locki.

Jak to rozwiązaliśmy

Zbudowaliśmy osobną szynę danych, która przejmuje całą złożoność systemu Comarch XL i odciąża jego bazę. Synchronizacja działa dwustronnie: zamówienia płyną z Magento 2 do ERP, a z powrotem wracają statusy, dane wysyłek i faktury – z tych ostatnich generujemy PDF-y dla klientów. Tą samą drogą jedzie cały katalog produktowy z cenami i stanami magazynowymi.

Problem

SAP jest źródłem prawdy o produkcji: każdy produkt rozkłada się w nim na tysiące SKU – każdą śrubkę i każdy element – wraz z symbolami, dopuszczalnymi materiałami, regułami łączenia i cenami. Sklep z konfiguratorem 3D potrzebuje czegoś dokładnie odwrotnego: gotowego produktu z kompletem opcji i kolorów, których liczba idzie w miliony. Między tymi światami nie ma mapowania jeden do jednego.

Jak to rozwiązaliśmy

Współtworzyliśmy aplikację, która zaciąga dane z systemu SAP i skleja z nich pełne produkty wraz ze wszystkimi dopuszczalnymi konfiguracjami, a następnie rozkodowuje pojedyncze elementy na modele 3D, materiały i meshe zasilające konfigurator. Całość jedzie na kolejkach – przy takiej liczbie kombinacji przetwarzanie musi być asynchroniczne i odporne na skalę, zamiast liczyć się w locie.

Problem

Firma zarządzająca kilkoma budynkami chciała pozbyć się kart magnetycznych – gubionych, kopiowanych i wymagających ciągłego wydawania nowych. Kontrola dostępu żyła w sterownikach Modbus rozsianych po budynkach, a pracownik nie miał jednego miejsca, w którym widzi historię swoich wejść czy przypisane miejsce parkingowe.

Jak to rozwiązaliśmy

Zbudowaliśmy aplikację PWA, która po przyłożeniu telefonu do markera NFC na ścianie otwiera pracownikowi drzwi, komunikując się ze sterownikami Modbus przez nasze API. Ta sama aplikacja jest cyfrową wizytówką pracownika: dane, historia otwieranych drzwi, miejsce parkingowe i wyszukiwarka osób w firmie.