Jak w Apexloopie zaprojektować bazy danych, relacje, formuły i widoki tak, aby workspace obsłużył CRM, projekty, faktury i procesy wewnętrzne bez ślepych zaułków.
Dobrze zaprojektowany workspace nie zaczyna się od pytania, ile stron stworzyć. Zaczyna się od pytania, które rzeczy mają własny cykl życia. Firma, kontakt, projekt, zadanie, faktura, pozycja, newsletter czy e-mail to nie tylko akapity w dokumencie. To rekordy, które mają status, właściciela, historię, relacje i często też wyniki.
W Apexloopie warto więc myśleć najpierw o bazach danych, a dopiero potem o stronach, które je wyjaśniają lub prezentują.
Zacznij od procesu, nie od doskonałego modelu
Pierwsza wersja modelu ma pokrywać realny proces, którego zespół używa co tydzień. Zwykle wystarczą trzy do pięciu baz danych. Na przykład CRM może zacząć od baz Firmy, Kontakty, Szanse sprzedaży, Aktywności i E-maile. Zarządzanie projektami może zacząć od Projektów, Zadań, Kamieni milowych, Ryzyk i Plików.
Przy każdej bazie danych zapisz sobie:
- kto tworzy rekord,
- kto jest jego właścicielem,
- jakie statusy przechodzi,
- do czego się odnosi,
- jaki raport lub wynik z niego powstaje.
Dzięki temu unikniesz kolumn, które nigdy nie zostaną użyte, i stron, które tylko powtarzają dane z gridu.
Kolumny wybieraj według znaczenia
Plain text nadaje się do prostych wartości, ale większość danych roboczych ma precyzyjniejszy typ. Liczby mogą nieść jednostkę lub walutę, daty określają planowanie, kolumna person przechowuje osoby i grupy, a kolumna files attachment przechowuje załączniki. Rich text należy umieszczać w popoverze komórki, gdy potrzebujesz krótkiego, ustrukturyzowanego opisu. Odnośnik do strony dokumentowej stosuj wtedy, gdy każdy rekord ma własny dokument.
Szczególną uwagę warto poświęcić ID. Identyfikator użytkownika z prefiksem i numerem autoincrement jest praktyczny dla faktur, zgłoszeń, umów czy incydentów. Systemowy GUID pozostaje ukryty i służy do jednoznacznej identyfikacji.
Relacje to szkielet workspace'u
Kolumny select i multiselect łączą rekordy z konkretną bazą danych. Kolumna record jest polimorficzna i może odnosić się do rekordu z dowolnej bazy danych. Kolumna view pokazuje przefiltrowane powiązane rekordy, na przykład pozycje bieżącej faktury albo zadania bieżącego projektu.
Backlinków przez related property używaj przy relacjach, które mają być synchroniczne: „Subitem / Parent item", „Blokuje / Zablokowane przez", „Firma / Kontakt" czy „Projekt / Klient". Użytkownik nie musi wtedy ręcznie uzupełniać drugiej strony relacji.
Słowniki należą do baz danych
Statusów, priorytetów, segmentów, typów zleceń i powodów utraty nie trzymaj tylko jako sztywnych list. W Apexloopie opłaca się zrobić z nich osobne bazy danych i używać ich przez select lub multiselect.
Dzięki temu wartości można opisywać, filtrować, adnotować, sortować i wykorzystywać w widokach oraz automatyzacjach. Gdy dział sprzedaży doda nowy segment, nie trzeba zmieniać struktury CRM. Przybędzie tylko rekord w słowniku.
Formuły łączą poziomy danych
Formuła potrafi wypełnić pole liczbowe, tekstowe, datę, boolean lub person na podstawie kontekstu rekordu. Gdy formuła zależy od innej formuły, powstaje kaskada w ramach jednego wiersza. Kolumna view dodatkowo wprowadza do kontekstu przefiltrowane elementy podrzędne.
To umożliwia rollupy bez ręcznego przepisywania. Zadanie liczy koszt, projekt sumuje zadania, a firma sumuje projekty. Ta sama zasada działa dla pojemności, marży, otwartych blokerów, stopnia realizacji czy ryzyka.
Widoki dopasuj do roli
Datagrid świetnie sprawdza się w zarządzaniu danymi, ale nie jest jedynym trybem pracy. Kanban pomaga zarządzać statusem, calendar i schedule pracują z czasem, timeline utrzymuje długie plany, chart pokazuje agregacje, a gallery nadaje się do treści wizualnych.
Jeden model danych może mieć wiele widoków dla różnych ról. Finanse śledzą kwoty, sprzedaż pipeline, zespół projektowy zadania, a zarząd podsumowanie. Wszyscy przy tym pracują na tych samych rekordach.
Dobry model poznaje się po wynikach
Na koniec projektowania zapytaj, co workspace ma umieć stworzyć. Jeśli ma generować fakturę, potrzebujesz numeracji, klienta, pozycji, kwot, adresu, kodu QR i szablonu PDF. Jeśli ma wysyłać newsletter, potrzebujesz kampanii, segmentu, treści dokumentowej, terminu i automatyzacji konwersji do email-safe HTML.
Model nie jest gotowy, gdy ma wszystkie kolumny. Jest gotowy, gdy zespół może na jego podstawie niezawodnie wykonać kolejny krok.
Jeśli wystarczy Ci gotowy szablon, czy potrzebujesz własnego modelu, pomoże rozstrzygnąć test na trzy pytania. A co model danych dodaje w porównaniu do zwykłej listy zadań, pokazuje artykuł Lista zadań to nie system. Projektowanie modelu w kontekście całego wdrożenia systemu prowadzi przewodnik po systemie firmowym szytym na miarę.