10 Projekt indywidualny

Po spotkaniu: zaplanujesz własny projekt modelu procesu w tok z analizą symulacyjną · przygotujesz raport w R Markdown, który sam uruchamia tok i liczy wskaźniki · przedstawisz model i wyniki w pięciu minutach · Czas: Nauka 20 min, Wyzwanie 70 min

10.1 Nauka

Czego wymaga projekt

Projekt łączy wszystko, czego nauczyłeś się w kursie. Wybierasz proces informacyjny z prawdziwej instytucji, zapisujesz go w tok, dodajesz decyzje i dane, przygotowujesz symulację dwóch scenariuszy i opisujesz wyniki w raporcie. Pełne polecenie i kryteria oceny są w opisie zadania P w dodatku C. Najważniejsze wymagania w skrócie:

Część	Minimum
model	basen instytucji z co najmniej trzema liniami, basen zewnętrzny, 10–20 elementów, bramka, zdarzenie graniczne albo podproces, dane
decyzje	co najmniej jedna tabela decyzyjna wywoływana przez zadanie rule
wariant	formularze i eksport wykonywalny dla Camunda 8 albo zmienne procesu w symulacji (variable, assign, when)
symulacja	zasoby, czasy, napływ spraw, co najmniej dwa scenariusze różniące się jednym założeniem
raport	R Markdown albo Quarto, wyrenderowany do HTML albo PDF
prezentacja	5 minut i 2 minuty na pytania

Jak wybrać proces

Dobry proces do projektu spełnia trzy warunki.

1. Znasz go albo możesz go poznać. Najlepiej z regulaminu, procedury albo rozmowy z pracownikiem. Opis „z wyobraźni” daje model, którego nie da się sprawdzić.
2. Ma pytanie, na które odpowie symulacja. Na przykład: czy dyżur dwóch bibliotekarzy wystarczy w sesji, czy archiwum nadąży z kwerendami po digitalizacji inwentarzy, ile trwa obieg pisma, gdy kierownik akceptuje pisma raz dziennie.
3. Ma decyzję według reguł. Limity wypożyczeń, tryb udostępnienia, kwalifikacja wniosku, kategoria archiwalna. Taka reguła staje się tabelą decyzyjną.

Przykłady: udostępnianie zbiorów specjalnych w czytelni, obsługa dezyderatów, deponowanie prac w repozytorium, rejestracja i dekretacja korespondencji, kwerendy archiwalne, przyjmowanie darów, digitalizacja na zamówienie, wypożyczenia międzybiblioteczne. Możesz wybrać proces z kursu „Modelowanie procesów informacyjnych”, ale nie przykład z tej książki.

Skąd wziąć parametry symulacji

Parametry to najsłabsze ogniwo każdej symulacji, dlatego każdy z nich uzasadniasz w raporcie jednym zdaniem.

Źródło	Przykład	Jak zapisać w tok
rozmowa z pracownikiem	„rejestracja trwa od 5 do 20 minut, zwykle 10”	duration="tri(5m, 10m, 20m)"
rejestr albo system	średnio 6 h, odchylenie 3 h (policzone z dat w EZD)	duration="lnorm(6h, 3h)"
statystyki roczne	1500 kwerend rocznie, około 250 dni pracy, czyli 6 dziennie	arrival="exp(80m)" przy pracy ciągłej, z komentarzem o założeniu
regulamin	„wnioskodawca ma 14 dni na uzupełnienie”	boundary … timer=P14D
szacunek autora	„mniej więcej co piąty wniosek jest niekompletny”	p=0.2 z komentarzem w modelu

Komentarz w modelu (#) to dobre miejsce na źródło parametru:

    # czas wg rozmowy z kierownikiem kancelarii, październik
    user rejestracja "Rejestracja wniosku" by=kancelisci duration="tri(5m, 10m, 20m)"

Struktura raportu

Raport ma od 4 do 8 stron i zawiera:

1. Cel. Jakie pytanie instytucji zadajesz modelowi (jedno, konkretne).
2. Opis procesu. Instytucja, uczestnicy, źródła wiedzy o procesie.
3. Model. Diagram wygenerowany z tok, najważniejsze decyzje modelowania i ich uzasadnienie. Cały tekst modelu w załączniku.
4. Decyzje i dane. Tabela decyzyjna w czytelnej postaci, zmienne procesu, formularze albo eksport wykonywalny.
5. Symulacja. Założenia (tabela parametrów ze źródłami), scenariusze, liczba spraw, ziarno.
6. Wyniki. Tabela wskaźników dla scenariuszy, co najmniej jeden wykres, interpretacja.
7. Wnioski. Co z wyników wynika dla instytucji. Rekomendacja i warunki, w których byłaby błędna.
8. Ograniczenia. Czego model nie obejmuje (np. kalendarzy pracy, różnic kompetencji między pracownikami).
9. Praca z agentem. Które części przygotował agent i co w nich zmieniłeś, albo oświadczenie o samodzielnej pracy.

Szablon raportu w R Markdown

Raport może sam uruchamiać tok. Dzięki temu po każdej zmianie modelu wystarczy wyrenderować go ponownie, a diagram, wskaźniki i wykresy zaktualizują się same. Minimalny szablon raport.Rmd, umieszczony w jednym folderze z plikiem proces.tok:

---
title: "Kwerenda archiwalna: model i symulacja"
author: "Imię Nazwisko"
date: "`r Sys.Date()`"
output: html_document
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = FALSE, message = FALSE)
```

## Model procesu

```{r model}
cat(system2("tok", c("check", "proces.tok", "--lang", "pl"), stdout = TRUE), sep = "\n")
system2("tok", c("svg", "proces.tok"), stdout = FALSE)
knitr::include_graphics("proces.svg")
```

## Symulacja

```{r symulacja}
system2("tok", c("sim", "proces.tok", "--seed", "7",
                 "--log", "log.csv", "--cases-csv", "sprawy.csv"), stdout = FALSE)
sprawy <- read.csv("sprawy.csv", encoding = "UTF-8")
sprawy$czas_h <- sprawy$cycle_time_s / 3600
```

Zasymulowano `r nrow(sprawy)` spraw. Średni czas cyklu wyniósł `r round(mean(sprawy$czas_h), 1)` h,
a 90% spraw zakończyło się w ciągu `r round(quantile(sprawy$czas_h, 0.9), 1)` h.

```{r wykres, fig.cap="Rozkład czasu cyklu"}
hist(sprawy$czas_h, breaks = 30, main = "", xlab = "Czas cyklu (godziny)", ylab = "Liczba spraw")
```

Pobierz szablon raportu (.Rmd)

Dla modelu kwerendy z rozdziału 8 wyrenderowany raport zawiera zdanie: „Zasymulowano 300 spraw. Średni czas cyklu wyniósł 17.5 h, a 90% spraw zakończyło się w ciągu 36.9 h.”

Raport renderujesz w RStudio przyciskiem Knit albo poleceniem rmarkdown::render("raport.Rmd"). Jeśli R nie znajduje polecenia tok (komunikat „‘“tok”’ not found”), zamień w szablonie system2("tok", c(...)) na system2("py", c("-m", "tok", ...)) w Windows albo system2("python3", c("-m", "tok", ...)) w macOS i Linuksie.

Drugi scenariusz dodajesz tak samo: osobny plik .tok, osobne wywołanie tok sim z tym samym ziarnem i wspólna tabela wskaźników. Wzór porównania dwóch scenariuszy jest w skrypcie z rozdziału 8.

Prezentacja

Masz 5 minut na prezentację i 2 minuty na pytania. Sprawdzony układ:

1. Instytucja i pytanie (30 s): czyj to proces i co chcesz sprawdzić.
2. Model (1,5 min): diagram, prowadzony jedną typową sprawą. Pokaż też fragment tekstu tok, np. tabelę decyzyjną.
3. Założenia (1 min): skąd wziąłeś czasy i prawdopodobieństwa.
4. Wyniki (1,5 min): tabela scenariuszy i jeden wykres.
5. Wniosek (30 s): jedno zdanie rekomendacji i jedno zdanie o ograniczeniach.

Nie czytaj kodu wiersz po wierszu. Mów językiem instytucji: „tu kancelista od razu odrzuca wnioski, których nie da się zrealizować”, a nie „tu jest bramka xor z p równym 0,15”.

Lista kontrolna przed oddaniem

• tok check proces.tok --lang pl zgłasza 0 błędów, a ostrzeżenia są uzasadnione w raporcie.
• tok fmt proces.tok --check potwierdza formę kanoniczną.
• Każdy scenariusz różni się od bazowego jednym założeniem i ma to samo ziarno.
• Każdy parametr symulacji ma w raporcie albo w komentarzu modelu źródło.
• Raport renderuje się od zera w czystym folderze, a liczby w tekście pochodzą z kodu, nie są przepisane ręcznie.
• Wnioski mówią, co zrobić w instytucji, i podają warunki, w których rekomendacja byłaby błędna.
• Dołączony jest rejestr prompty.md i opis pracy z agentem albo oświadczenie o samodzielnej pracy.
• W plikach nie ma danych osobowych prawdziwych osób.

10.2 Wyzwanie

Polecenie: zaprezentuj swój projekt i oceń dwa projekty innych osób.

Przebieg: prezentacja 5 minut, pytania 2 minuty. Kolejność ustala prowadzący na początku zajęć. Prezentujesz z własnego laptopa albo z pliku prezentacja.pdf.

Ocena koleżeńska: każda osoba ocenia dwa wylosowane projekty, odpowiadając na trzy pytania:

1. Czy po prezentacji wiesz, jakie pytanie instytucji rozstrzyga projekt i jaka jest odpowiedź? (tak / częściowo / nie, z uzasadnieniem w jednym zdaniu)
2. Które założenie symulacji wydaje Ci się najmniej pewne i dlaczego?
3. Jaki trzeci scenariusz warto byłoby sprawdzić?

Oceny przekazujesz autorom przez Pegaz. Nie wpływają na ocenę projektu, ale autor może je uwzględnić w raporcie przed terminem oddania.

Rezultat: prezentacja i oddanie zadania P.

Czas: 70 minut, a w dużej grupie prezentacje trwają także przez część czasu przeznaczonego na Naukę.

Zadanie P. Projekt indywidualny (50%). Oddajesz archiwum z modelem tok, scenariuszami, eksportem, raportem w R Markdown albo Quarto, danymi z symulacji, rejestrem poleceń dla agenta (jeśli z niego korzystasz) i slajdami. Pełne polecenie i kryteria oceny są w dodatku C.

Na co zwrócić uwagę

• Jedno konkretne pytanie jest lepsze niż pięć ogólnych. „Czy trzeci archiwista skróci czas odpowiedzi poniżej tygodnia?” da się rozstrzygnąć. „Jak usprawnić archiwum?” nie.
• Pokaż na slajdzie liczby z raportu, a nie zrzut ekranu terminala.
• Przygotuj odpowiedź na pytanie „skąd wiesz, że czas wynosi tyle?”. Pada niemal zawsze.

10.3 Pytania sprawdzające

1. Jakie trzy warunki powinien spełniać proces wybrany do projektu?
2. Skąd można wziąć parametry symulacji? Jak udokumentujesz ich źródło?
3. Dlaczego raport powinien sam uruchamiać tok, zamiast zawierać przepisane liczby?
4. Co powinien zawierać rozdział raportu o ograniczeniach?
5. Jak opisać w raporcie pracę z agentem AI zgodnie z zasadami UJ?