Twój system odwzorowuje firmę klienta, nie twoją

Modelujesz cudzą firmę

To jest różnica, która nie ma odpowiednika w B2C i dlatego regularnie zaskakuje.

Twój katalog opisuje twoją rzeczywistość - wiesz, jakie masz produkty, bo je kupiłeś. Twoje konto klienta w B2C opisuje osobę i to też jest proste, bo osoba to osoba.

W B2B konto musi opisać organizację kupującego: kto tam pracuje, kto komu podlega, kto ma prawo wydać ile pieniędzy, gdzie jedzie towar i kto płaci. Nie masz nad tym kontroli i nie dowiesz się o zmianach - klient zreorganizuje działy w kwietniu i po prostu zacznie zamawiać inaczej.

Cztery układy, które spotkasz

W praktyce polskiego B2B powtarzają się cztery i warto wiedzieć, że będą wszystkie naraz.

Jednoosobowy. Właściciel małej firmy kupuje sam. Konto to osoba, koniec. Około połowy twoich kontrahentów.

Zaopatrzeniowiec i akceptujący. Ktoś składa koszyk, ktoś inny zatwierdza powyżej progu. Dwie role, jedno konto firmowe.

Centrala i oddziały. Piętnaście oddziałów zamawia osobno, każdy na swój adres, ale limit kredytowy jest wspólny, cennik jest wspólny, a faktura idzie do centrali. Centrala chce widzieć wszystko, oddział - tylko siebie.

Grupa kapitałowa. Kilka spółek z osobnymi NIP-ami, wspólnym cennikiem wynegocjowanym na grupę i osobnymi limitami. Formalnie osobni kontrahenci, handlowo jeden klient.

Twój model musi obsłużyć wszystkie cztery jednocześnie, bo masz je wszystkie w bazie. Jak to rozłożyć na encje, rozbieram w tekście o multi-account.

Pułapka jednego poziomu

Najczęstszy błąd projektowy wygląda niewinnie: firma ma użytkowników. Płasko, jeden poziom.

Działa dla trzech pierwszych układów - w czwartym przewraca się na relacji grupa-spółka. Ale prawdziwy problem pojawia się wcześniej i gdzie indziej: przy adresie dostawy.

W modelu płaskim adres wisi przy użytkowniku albo przy firmie. Klient z piętnastoma oddziałami ma piętnaście adresów, a zaopatrzeniowiec z centrali zamawia raz na jeden, raz na drugi. Nagle okazuje się, że adres nie jest własnością użytkownika ani firmy, tylko oddziału, którego w modelu nie ma.

Dorobienie poziomu pośredniego po starcie oznacza migrację wszystkich kont i historii zamówień. To jest projekt, nie poprawka - i to jest powód, dla którego ta decyzja zapada na początku albo nie zapada wcale.

Co zaprojektować od razu

Nie chodzi o to, żeby zbudować wszystko na start. Chodzi o to, żeby model miał gdzie urosnąć.

Poziom pośredni istnieje od pierwszego dnia, nawet jeśli 90% klientów ma go pustego. Firma → jednostka → użytkownik. Jednoosobowa działalność ma jedną jednostkę i nikt tego nie zauważa. Grupa kapitałowa ma ich dwanaście i działa bez migracji.

Rola jest relacją, nie polem. Ten sam człowiek bywa akceptującym w jednym oddziale i zamawiającym w drugim. Rola przypisana do użytkownika tego nie opisze - rola musi wisieć na parze użytkownik-jednostka. Rozwijam to w tekście o rolach i uprawnieniach.

Limit i cennik mogą wisieć na innym poziomie niż zamówienie. Cennik na grupie, limit na spółce, zamówienie na oddziale. Jeśli wszystko zaczepisz o jedną encję „kontrahent", pierwszy klient z grupy kapitałowej rozbije ten model.

Test przed startem jest ten sam co zwykle: weź trzech najbardziej pokręconych organizacyjnie klientów i narysuj ich w swoim modelu. Jeśli się nie mieszczą, masz to na papierze zamiast w migracji.

Co dalej

• Jak rozłożyć to na encje: Multi-account dla organizacji
• Rola jako relacja, nie pole: Role i uprawnienia kupujących
• Akceptacja powyżej progu: Workflow akceptacji zamówień