Trzy źródła, jeden raport — scalanie ERP, MySQL i API rynkowych w jednym dashboardzie
Klient zarządzał portfelem kilku budynków biurowych i mieszanych — najem krótko- i długoterminowy, kilkudziesięciu najemców. Dane finansowe były w systemie ERP, rezerwacje lokali w wewnętrznej bazie MySQL, ceny rynkowe u zewnętrznego dostawcy przez API. Każdy system dawał inny wycinek rzeczywistości. Pytanie "czy nasz czynsz jest zgodny z rynkiem i jednocześnie mamy dobry wskaźnik konwersji zapytań?" wymagało trzech okienek i ręcznego scalania.
Przed wdrożeniem
- 3 systemy, 3 różne „prawdy"
- Ręczne scalanie danych w Excelu
- Brak wskaźnika konwersji rezerwacji
- Czynsz ustalany intuicyjnie — bez porównania z rynkiem
- Alert o wygasających umowach: brak
Po wdrożeniu
- Jeden dashboard NOI zamiast trzech okienek
- Dane z poprzedniego dnia, codziennie
- Konwersja rezerwacji → umowa widoczna wprost
- Porównanie czynszu z rynkiem per lokalizacja
- Alert: czynsz >15% poniżej rynku + umowa wygasająca w 6 miesięcy
Skąd płynęły dane
System ERP (Comarch Optima)
Faktury, płatności, koszty, należności, kontrahenci. Jedyne źródło prawdy dla finansów. Połączenie przez dedykowane konto SQL tylko do odczytu.
Wewnętrzna baza MySQL — CRM i rezerwacje
Zapytania o najem, rezerwacje lokali, statusy, historia kontaktów z potencjalnymi najemcami. Dane zasilane przez własny system klienta.
Zewnętrzne API — ceny rynkowe
Ceny rynkowe najmu per mkw per lokalizacja, wskaźniki dostępności w okolicy. Dane historyczne dostępne z oknem 90 dni.
Jak to działa — logika bez technikaliów
Każde źródło ma inny rytm zasilania. System ERP jest pobierany raz dziennie o 06:00 — inkrementalnie, tylko dokumenty zmienione od ostatniego uruchomienia. MySQL z rezerwacjami co 15 minut, bo klient chciał wiedzieć o zmianie statusu lokalu blisko rzeczywistości. API rynkowe co godzinę — dane agregowane do poziomu miesięcznego.
Kluczowy problem był w warstwie Silver: ERP i MySQL nie znały się nawzajem. Optima używała własnego ID kontrahenta, MySQL własnego ID klienta. Żadnego wspólnego klucza. Rozwiązaniem była tabela mapowania — uzupełniona ręcznie przez klienta dla ~200 najemców, potem utrzymywana przez trigger przy każdym nowym kliencie.
Po scaleniu na wspólnych kluczach warstwa Gold przygotowała widoki analityczne: NOI per budynek per miesiąc, porównanie stawek z rynkiem, ścieżka rezerwacji. Power BI odświeżany codziennie o 07:00 — po załadowaniu ERP. Dane z MySQL i API załadowane wcześniej są dostępne od razu.
Bronze
Surowe dane z 3 źródeł w osobnych schematach. Każde źródło niezależnie.
Silver
Tabela mapowania łączy ERP z MySQL. Wspólne klucze, oczyszczone dane.
Gold
NOI, konwersja, porównanie z rynkiem — gotowe dla Power BI.
Co konkretnie stało się dostępne
NOI per budynek per miesiąc
Przychody z faktur minus koszty operacyjne — jeden widok, bez Excela. Filtr po budynku, miesiącu, typie powierzchni.
Porównanie stawki czynszu z rynkiem
Stawka z umowy najmu zestawiona ze średnią rynkową per lokalizacja i typ powierzchni. Widać od razu które lokale są niedoszacowane.
Konwersja zapytań w umowy
Dane z MySQL (rezerwacje, statusy) połączone z Optimą (umowy) — po raz pierwszy widoczny wskaźnik ile zapytań o wynajem przeradza się w podpisaną umowę.
Alert renegocjacyjny
Lokalek z czynszem >15% poniżej rynku i umową wygasającą w ciągu 6 miesięcy. Kandydaci do renegocjacji — niemożliwe do wyliczenia bez połączenia danych z API i ERP.
Co było trudne
Mapowanie klientów między systemami zajęło klientowi 2 tygodnie — to jego praca, nie moja. Nie ma technologicznego sposobu na połączenie dwóch systemów, które nigdy nie były zaprojektowane żeby się znać. Trzeba zbudować tę wiedzę raz, ręcznie. Potem tabela mapowania utrzymuje się sama.
API rynkowe nie miało danych historycznych starszych niż 90 dni. Wsteczna analiza porównawcza stawek jest dostępna dopiero od momentu uruchomienia projektu — to ograniczenie dostawcy danych, które trzeba było zaakceptować.
Dane o powierzchni (NLA) lokali leżały w trzech różnych Excelach z niespójnymi nazwami budynków i lokali. Standaryzacja podczas Fazy 0 — typowy brud, który nie jest problemem technicznym, tylko informacyjnym.
Trzy źródła to standard, nie wyjątek
W projektach z nieruchomościami rzadko kiedy cała wiedza jest w jednym systemie. ERP wie o pieniądzach, CRM wie o relacjach, dane rynkowe są poza firmą. Jeden raport łączący wszystkie trzy warstwy to standard docelowy — nie wyjątek od reguły.
Technologia pozwala to połączyć. Kluczem jest uzgodnienie wspólnych kluczy między systemami — i to jest praca Fazy 0, nie etap po wdrożeniu. Bez tabeli mapowania Silver jest niemożliwy.
Masz dane w kilku systemach i brak spójnego widoku?
Napisz z jakich systemów korzystasz — sprawdzę jak je połączyć.
Napisz do mnie