Polska firma — tworzymy w Polsce 🇵🇱

Zasady firmowe

Zespół redakcyjny Flowtly3 min

Zasady firmowe to spisane wewnętrzne reguły organizacji, aktualizowane na bieżąco: zasady urlopów, uprawnienia do benefitów, limity wydatków, korzystanie ze sprzętu. Każdy pracownik może je czytać. Pisać je może tylko administrator.

Każda zasada to strona ze stałym identyfikatorem, a jej treść jest przechowywana jako seria wersji. Wersja ma datę, od której obowiązuje, więc strona odpowiada na pytanie, które ma znaczenie po zmianie reguły: co obowiązywało 15 marca? Wcześniejsze brzmienie nie jest nadpisywane ani usuwane, zostaje czytelne pod swoją datą.

Czytanie zasady

Lista zasad pokazuje wszystkie zasady w organizacji. Po otwarciu jednej widać wersję obowiązującą dzisiaj, z datą, od której obowiązuje.

Historia wersji obok strony pokazuje wszystkie wersje i oznacza każdą z nich:

  • Obowiązuje: brzmienie, które ma zastosowanie dzisiaj. Jest dokładnie jedno.
  • Archiwalna: brzmienie, które obowiązywało wcześniej i zostało zastąpione. Nadal można je przeczytać.
  • Zaplanowana: brzmienie już opublikowane, ale jego data jeszcze nie nadeszła. Jeszcze nie obowiązuje, choć każdy może je otworzyć i przeczytać.

Wybranie wersji archiwalnej otwiera ją z wyraźną informacją, że to nie jest dzisiejsza reguła. Ustawienie pola Na dzień na dzień w przeszłości pokazuje, co obowiązywało tego dnia.

Zasady mogą linkować do siebie nawzajem. Link w zasadzie zawsze prowadzi do wersji docelowej zasady obowiązującej w chwili kliknięcia, a nie do brzmienia, które obowiązywało, gdy link został napisany.

Tworzenie zasady

Te akcje widzi tylko administrator. Pozostali widzą te same strony bez nich.

Nowa zasada tworzy stronę. Wymaga tytułu i identyfikatora. Identyfikator służy innym zasadom do linkowania i nie można go później zmienić: nic nie zapisuje, które zasady linkują do danej strony, więc zmiana identyfikatora po cichu zepsułaby te linki.

Zmień nazwę zmienia tylko tytuł, z tego samego powodu.

Opublikuj wersję dodaje nową wersję. Wymaga treści i daty, od której wersja obowiązuje:

  • Dzisiaj: od razu staje się wersją obowiązującą, a poprzednia staje się archiwalna.
  • Data w przyszłości: wersja zostaje zapisana jako zaplanowana. Do tej daty obowiązuje dotychczasowe brzmienie, a edytor informuje o tym przy wyborze przyszłej daty. Tak przygotowuje się zmianę reguły ogłoszoną z wyprzedzeniem, bez wcześniejszego wejścia w życie.

Publikacja zawsze dodaje wersję. Opublikowanej wersji nie można edytować ani usunąć, i to jest celowe: wersja, którą dałoby się zmienić po fakcie, nie odpowie już, co obowiązywało w marcu. Poprawkę publikuje się jako nową wersję, tak jak aneks na papierze.

Administrator może natomiast wycofać całą zasadę. Wtedy znika ona z listy i nie da się jej otworzyć.

Zasady nie wysyłają powiadomień o nowej wersji, nie zbierają potwierdzeń zapoznania się i nie są podpisywane. Data wejścia w życie zmienia tylko to, które brzmienie jest pokazywane jako obowiązujące. Do podpisu elektronicznego służy osobna funkcja w Zarządzaniu dokumentami.

Przykładowe zastosowania

  • Opublikuj zasady urlopowe, żeby każdy pracownik mógł przeczytać aktualne reguły bez pytania.
  • Odpowiedz księgowej na pytanie, która zasada benefitowa obowiązywała w dniu wypłaty.
  • Przygotuj z wyprzedzeniem limity wydatków na kolejny kwartał z datą pierwszego dnia miesiąca, a do tego dnia pracownicy nadal widzą obecne limity jako obowiązujące.
  • Popraw błąd w obecnym brzmieniu, publikując poprawioną wersję; zapis tego, co obowiązywało wcześniej, zostaje nienaruszony.
  • Podlinkuj zasady korzystania ze sprzętu z zasad onboardingu, żeby nowa osoba przeszła z jednej strony na drugą.

Mapa powiązań

Odnosi się doCzęśćRealizuje
Opisane tutajOpisane gdzie indziej
audit-log rejestruje person. setting definiuje attribute. org-document dostęp regulowany przez setting. subscription warunkuje setting. setting wymaga second-factor. second-factor należące do person. recovery-code zastępuje second-factor. trusted-device pomija second-factor.rejestrujedefiniujedostęp regulowany przezwarunkujewymaganależące dozastępujepomijaDDziennik zdarzeń — The record of who did what and when. It is how a user action is investigated after the fact, and what compliance is demonstrated from.Dziennik zdarzeńOOsoba — An employee. The central record the rest of the workforce data hangs off — profile, documents, leave, benefits, rates.OsobaUUstawienie — Platform-wide configuration — behaviours, permissions, security.UstawienieAAtrybut — A custom data field defined once and collected across the platform, so an organisation can record what Flowtly does not ship a field for.AtrybutDDokument — An organisational file, stored with control over who can reach it.DokumentSSubskrypcja — The plan the organisation is on, and what it is billed for.SubskrypcjaDDrugi składnik — The extra proof of identity asked for at sign-in on top of the password — a six-digit code from an authenticator app, changing every 30 seconds.Drugi składnikKKod odzyskiwania — One of ten single-use codes issued when an authenticator is confirmed. Each stands in for a code from the app once, for the day the phone is gone.Kod odzyskiwaniaZZaufane urządzenie — A browser a person has chosen to trust, which is not asked for a second factor again for 30 days. Per browser, not per person.Zaufane urządzenie

Powiązane pojęcia