Od pomysłu do pilotażu: plan wdrożenia blockchain w szkole w 90 dni i lista kontrolna

Dlaczego szkoła potrzebuje strategii blockchain i co realnie da się zrobić w 90 dni

Blockchain w szkole nie jest celem samym w sobie. To narzędzie, które ma rozwiązać realne problemy: bałagan w dokumentach, trudności z weryfikacją certyfikatów uczniów, brak przejrzystości w ocenianiu, konieczność wielokrotnego wpisywania tych samych danych czy brak zaufania do „papierowych” świadectw. Plan wdrożenia blockchain w szkole w 90 dni musi zaczynać się od bardzo trzeźwego spojrzenia na te problemy i przełożenia ich na konkretny, ograniczony pilotaż, a nie rewolucję w całej instytucji.

90 dni to wystarczający czas, by: zdefiniować obszar pilotażu, przygotować podstawową dokumentację, wybrać technologię, zbudować prosty prototyp, przetestować go z małą grupą nauczycieli i uczniów oraz podsumować wyniki. Nie jest to czas na wymianę wszystkich systemów, przebudowę dziennika elektronicznego czy konieczność pisania całej infrastruktury od zera.

Praktyczny plan wdrożenia blockchain w szkole w 90 dni powinien być podzielony na jasne etapy: analiza, projekt, wybór technologii, prototyp, pilotaż, ewaluacja. Do każdego z tych etapów da się przygotować krótką, konkretną listę kontrolną, która pozwala dyrektorowi, koordynatorowi IT i nauczycielom sprawdzić, czy zmierzają w dobrą stronę. Najważniejsze, aby od początku trzymać się ograniczonego zakresu i nie dokładać nowych pomysłów w połowie prac.

Fundamenty: co blockchain może – i czego nie może – załatwić w szkole

Typowe problemy, które blockchain w szkole rozwiązuje najlepiej

Wdrożenie blockchain w szkole ma sens tylko wtedy, gdy poprawia obszary, gdzie liczy się wiarygodność, niezmienność, zaufanie i długoterminowe przechowywanie danych. Dobrze sprawdza się przede wszystkim w trzech kategoriach:

• Certyfikacja – cyfrowe świadectwa, dyplomy, certyfikaty kompetencji, potwierdzenia udziału w projektach czy konkursach. Blockchain pozwala każdej uczelni, pracodawcy czy organizacji w kilka sekund zweryfikować, czy dokument jest autentyczny, bez dzwonienia do sekretariatu.
• Rejestry osiągnięć ucznia – zapisy projektów, portfolio, badge’y kompetencyjne, mikrocertyfikaty za konkretne umiejętności (np. „obsługuje drukarkę 3D”, „zna podstawy Pythona”, „ukończył moduł z edukacji medialnej”). To szczególnie istotne przy edukacji kompetencyjnej.
• Przejrzyste logi działań – historia istotnych zdarzeń edukacyjnych, np. przyznania indywidualnych dostosowań, zmiana programu nauczania, ważniejsze decyzje rady pedagogicznej dotyczące danego ucznia. Tu blockchain bywa wykorzystywany jako niezmienny rejestr odwołań.

Nie wszystkie dane muszą (ani powinny) trafiać na blockchain. Dane wrażliwe (szczególnie zdrowotne, socjalne, objęte tajemnicą) lepiej przechowywać w tradycyjnych systemach, a na łańcuchu bloków trzymać jedynie skróty kryptograficzne (hash) dokumentów lub odwołania do zaszyfrowanych zasobów.

Czego blockchain nie rozwiąże w procesach szkolnych

Nie ma sensu oczekiwać, że wdrożenie blockchain w szkole w 90 dni rozwiąże wszystkie bolączki organizacyjne. Ta technologia:

• nie zastąpi dziennika elektronicznego – może go uzupełniać, np. w zakresie trwałego potwierdzania ocen końcowych czy egzaminów, ale nie służy do codziennego wpisywania uwag i frekwencji,
• nie naprawi złej komunikacji – brak zaufania między nauczycielami, uczniami i rodzicami nie zniknie dzięki nowej technologii, może jedynie zyskać nowe narzędzie do przejrzystego potwierdzania faktów,
• nie zautomatyzuje chaosu – jeśli obecny obieg dokumentów jest niejasny, powielony lub sprzeczny, blockchain tylko utrwali ten bałagan; zanim cokolwiek się zarejestruje w łańcuchu bloków, trzeba uporządkować procedury.

Dlatego pierwszy etap prac powinien skupić się na pytaniu: jaki jeden konkretny proces szkolny można w 90 dni przenieść na blockchain w sposób sensowny, mierzalny i zrozumiały dla uczestników? Unikanie zbyt szerokich ambicji na początku jest kluczowe dla powodzenia pilotażu.

Najprostsze scenariusze na start: jeden proces, jedna grupa, jasny efekt

W praktyce dobrymi kandydatami do pierwszego pilotażu bywają:

• Certyfikaty ukończenia kursu dodatkowego – np. zajęcia z programowania, koło robotyki, warsztaty językowe. Mała, wybrana grupa uczniów, wyraźny początek i koniec, łatwy do opisania rezultat: certyfikat na blockchain.
• Badges kompetencyjne dla uczniów technikum lub liceum profilowanego – np. „ukończył ścieżkę DevOps”, „praktyki zawodowe w branży logistycznej”. Uczeń dostaje indywidualny, łatwy do weryfikacji wpis, który może pokazać pracodawcy.
• Potwierdzenie udziału w olimpiadach i konkursach – szkoła zapisuje fakt zdobycia miejsca lub wyróżnienia w ramach prostego rejestru, do którego dostęp ma organizator, kuratorium czy uczelnia.

Każdy z tych scenariuszy ma wspólną cechę: ograniczony zakres i niski poziom ryzyka. Jeśli coś się nie uda technicznie, uczniowie nadal otrzymają klasyczne certyfikaty papierowe, a szkoła zdobędzie bezcenne doświadczenie, jakie jest konieczne przed rozważaniem większej skali.

90-dniowy plan wdrożenia blockchain w szkole: mapa etapów

Struktura czasu: trzydzieści dni na każde z trzech makroetapów

Plan wdrożenia blockchain w szkole w 90 dni dobrze rozpisać na trzy trzydziestodniowe makroetapy, które można potraktować jako „mini-projekty”:

Taki podział wymusza dyscyplinę: każdy okres kończy się konkretnymi, mierzalnymi rezultatami, które da się sprawdzić prostą listą kontrolną. Zamiast „pracujemy nad blockchainem”, zespół może powiedzieć: „Mamy zatwierdzony opis procesu i listę uczniów do pilotażu” albo „Prototyp wystawił pierwsze 10 certyfikatów testowych”.

Rola dyrektora, koordynatora IT i lidera merytorycznego

Skuteczny plan wdrożenia blockchain w szkole wymaga jasnego podziału odpowiedzialności. Minimalny skład zespołu pilotażowego powinien obejmować:

• Dyrektora lub wicedyrektora – podejmuje decyzje formalne, aprobuję protokół pilotażu, komunikuje projekt radzie pedagogicznej i rodzicom, dba o zgodność z prawem i politykami szkoły.
• Koordynatora IT – może to być nauczyciel informatyki, administrator sieci lub osoba odpowiedzialna za e-dziennik. Zajmuje się kontaktami z dostawcą technologii, wstępną weryfikacją wymagań technicznych, konfiguracją i podstawowym wsparciem użytkowników.
• Lidera merytorycznego – nauczyciel lub wychowawca odpowiedzialny za wybrany proces (np. opiekun koła, nauczyciel przedmiotu, koordynator praktyk zawodowych). To on pilnuje, by rozwiązanie faktycznie wspierało proces edukacyjny, a nie było tylko „gadżetem technologicznym”.

W mniejszych szkołach te role mogą częściowo się łączyć, ale musi istnieć jedna osoba decyzyjna, do której zespół wraca przy każdej wątpliwości co do zakresu lub priorytetu zadań (najczęściej dyrektor lub wicedyrektor). Bez tego projekty blockchain w szkołach grzęzną w sporach o drobiazgi lub w nieskończonym dodawaniu nowych pomysłów.

Główne kamienie milowe w projekcie pilotażowym

Dobrze zdefiniowane kamienie milowe ułatwiają nadzorowanie postępu. W projekcie obejmującym wdrożenie blockchain w szkole w 90 dni kluczowe punkty mogą wyglądać następująco:

• Dzień 7 – wybrany konkretny proces pilotażowy, opisany w 1–2 stronach dokumentu.
• Dzień 15 – lista uczestników pilotażu (nauczyciele, uczniowie, klasy) oraz wstępna mapa danych, które będą rejestrowane.
• Dzień 30 – zatwierdzona specyfikacja pilotażu: cele, zakres, kryteria sukcesu, ryzyka.
• Dzień 45 – wybrana platforma blockchain, podstawowa konfiguracja środowiska testowego.
• Dzień 60 – działający prototyp, który potrafi wygenerować co najmniej 1–3 poprawne wpisy (np. certyfikaty testowe).
• Dzień 75 – wdrożony pilotaż, pierwsze wpisy z udziałem prawdziwych uczniów.
• Dzień 90 – raport z pilotażu z rekomendacją: rozwijać, modyfikować, wstrzymać.

Każdy kamień milowy powinien kończyć się krótką notatką (1–2 strony), która dokumentuje decyzje i wnioski. Taka dokumentacja jest później bezcenna przy rozmowach z organem prowadzącym, kuratorium czy potencjalnymi partnerami technologicznymi.

Etap 1 (dni 1–30): analiza potrzeb i wybór procesu pilotażowego

Inwentaryzacja procesów szkolnych pod kątem blockchain

Pierwszy miesiąc powinien zacząć się od krótkiej, ale konkretnej inwentaryzacji procesów, które w szkole generują formalne dokumenty lub mają długoterminowe znaczenie dla uczniów. W praktyce wystarczy warsztat z 3–5 osobami (dyrektor, koordynator IT, 1–2 nauczycieli), podczas którego powstanie lista procesów takich jak:

• wystawianie świadectw i zaświadczeń,
• wydawanie certyfikatów z zajęć dodatkowych, kół i projektów,
• potwierdzanie praktyk zawodowych,
• przyznawanie nagród i wyróżnień szkolnych,
• udział w olimpiadach, konkursach, projektach międzynarodowych,
• ewidencja ważnych uprawnień (np. BHP, szkolenia specjalistyczne).

Do każdego procesu warto dopisać na marginesie trzy proste informacje:

1. Jak często występuje (rzadko, regularnie, bardzo często)?
2. Jak duża jest liczba uczestników (kilku uczniów, jedna klasa, cała szkoła)?
3. Jakie jest ryzyko błędu (niskie – da się łatwo poprawić; wysokie – konsekwencje formalne)?

Takie uporządkowanie pomaga zobaczyć, że pierwszym celem pilotażu blockchain nie musi być najważniejszy proces w szkole, tylko ten, który jest wystarczająco prosty, żeby zdążyć w 90 dni, a jednocześnie dostatecznie istotny, aby jego poprawa miała sens.

Kryteria wyboru procesu na pilotaż

Przy wyborze jednego procesu na pilotaż dobrze sprawdza się prosty zestaw kryteriów. Proces:

• ma wyraźny początek i koniec – np. kurs trwa od marca do maja, a na końcu wydawany jest certyfikat,
• dotyczy ograniczonej grupy – np. 15–30 uczniów w jednym roczniku, a nie całej szkoły,
• generuje dokument lub zapis, który może być przydatny poza szkołą – np. dla pracodawcy, uczelni, organizatora konkursu,
• ma jasnego właściciela merytorycznego – nauczyciela, który zgadza się być liderem treściowym pilotażu,
• nie jest strategicznie krytyczny – ewentualne problemy nie zablokują kluczowych zadań szkoły (jak wystawianie świadectw końcowych wszystkich uczniów).

Dobrze jest omówić kandydatów na proces pilotażowy podczas krótkiego spotkania z większą grupą nauczycieli (np. podczas rady pedagogicznej połączonej z warsztatem). 30–45 minut poświęcone na dyskusję i wskazanie procesu, który budzi największe zainteresowanie, poprawia późniejsze zaangażowanie i ułatwia komunikację.

Opis procesu pilotażowego – praktyczny szablon

Aby nie gubić się w szczegółach, opis procesu pilotażowego dla wdrożenia blockchain w szkole można zamknąć w prostym szablonie 1–2 strony A4. Powinien zawierać:

Elementy opisu procesu, które ułatwią wdrożenie

Przygotowując opis, opłaca się konsekwentnie trzymać kilku kluczowych sekcji. Pozwala to porównywać różne pomysły na przyszłe pilotaże i ułatwia rozmowę z dostawcą technologii.

• Cel edukacyjny i organizacyjny – jedno krótkie zdanie, co ma się poprawić: np. „uporządkowanie potwierdzania udziału w kole informatycznym i danie uczniom łatwego do pokazania certyfikatu”.
• Opis krok po kroku – jak dziś działa proces (bez blockchaina): kto zgłasza uczniów, kto zatwierdza listę, kto wystawia dokument, gdzie jest przechowywany.
• Rola blockchaina – jeden akapit: co dokładnie ma zostać zapisane w łańcuchu bloków (np. skrót certyfikatu, data, identyfikator ucznia) i co użytkownik końcowy ma umieć zrobić (np. zeskanować kod QR).
• Uczestnicy i ich uprawnienia – dyrektor, nauczyciele, uczniowie, rodzice, ewentualnie pracodawcy lub uczelnie; przy każdym krótki opis, co mogą: tylko odczyt, czy też wprowadzanie danych.
• Zakres pilotażu – liczba uczniów, klas, nauczycieli; okres trwania (np. jeden semestr); maksymalna liczba certyfikatów lub wpisów.
• Dane wrażliwe – które dane są osobowe, które mogą być pseudonimizowane (np. ID ucznia zamiast imienia i nazwiska), co pozostaje poza blockchainem, w systemie szkoły.
• Kryteria sukcesu – 3–5 konkretnych, mierzalnych wskaźników, np. „80% uczniów aktywowało swój cyfrowy certyfikat” albo „czas przygotowania listy certyfikatów skrócił się z tygodnia do dwóch dni”.

Taki opis nie musi być pisany językiem technicznym. Bardziej przypomina scenariusz lekcji: co, kto, kiedy i po co. Na tej podstawie koordynator IT lub partner technologiczny jest w stanie zaproponować najprostszy działający wariant rozwiązania.

Analiza ryzyka i prosty plan awaryjny

Nawet przy niewielkim pilotażu warto zawczasu ustalić, co stanie się, jeśli technologia zawiedzie lub projekt się opóźni. W praktyce sprowadza się to do krótkiego „planu B”, który mieści się na pół strony.

• Ryzyko techniczne – przerwa w działaniu platformy, problemy z logowaniem, brak dostępu do Internetu w szkole; procedura: w takim przypadku nauczyciel prowadzi proces „po staremu”, a wpisy na blockchain są uzupełniane później (o ile ma to sens).
• Ryzyko organizacyjne – zmiana nauczyciela, brak czasu w kluczowym momencie; procedura: wyznaczenie zastępcy lidera merytorycznego i proste przejęcie zadań.
• Ryzyko prawne i wizerunkowe – wątpliwości rodziców, pytania o RODO; procedura: gotowa, krótka informacja dla rodziców i uczniów, konsultacja z inspektorem ochrony danych.

To nie jest wyrafinowana analiza ryzyka w stylu korporacyjnym. Wystarczy, że zespół pilotażowy ma spisane proste odpowiedzi na pytanie: „Co robimy, jeśli…?”.

Uzgodnienie procesowe z dyrektorem i radą pedagogiczną

Gdy opis procesu pilotażowego jest gotowy, przychodzi moment na krótką rozmowę z dyrektorem i – przynajmniej w zarysie – z radą pedagogiczną. Chodzi mniej o zgodę na „technologię blockchain”, a bardziej o jasność, że:

• proces nie zastępuje istniejących obowiązków szkoły (np. wystawiania tradycyjnych dokumentów), lecz je uzupełnia,
• pilotaż ma określony czas trwania i skończy się raportem z wnioskami,
• zespół pilotażowy ma jasno określony mandat do podejmowania decyzji operacyjnych.

Dobrym nawykiem jest zarezerwowanie 10–15 minut na radzie pedagogicznej na krótką prezentację: czego dotyczy pilotaż, kogo obejmuje, jakie są korzyści dla uczniów. Dzięki temu zmniejsza się ryzyko nieporozumień w stylu „czemu moja klasa nie bierze udziału?” czy „czy to znaczy, że świadectwa będą tylko cyfrowe?”.

Etap 2 (dni 31–60): dobór technologii i budowa prototypu

Wybór rodzaju platformy: publiczna, prywatna czy rozwiązanie gotowe

Na drugim etapie najważniejsze jest rozstrzygnięcie, czy szkoła będzie korzystać z własnej infrastruktury blockchain, czy z gotowego rozwiązania oferowanego przez zewnętrznego dostawcę. W edukacji najczęściej pojawiają się trzy warianty.

• Platforma publiczna (np. publiczny blockchain służący wyłącznie jako „rejestr skrótów”) – zaleta: bardzo wysoka trwałość wpisów; wyzwanie: konieczność dbałości o anonimizację danych i koszt jednostkowych transakcji (zwykle niski przy małej skali).
• Platforma prywatna lub konsorcjalna (uruchamiana przez dostawcę lub kilka instytucji edukacyjnych) – zaleta: lepsza kontrola nad danymi i zasadami dostępu; wyzwanie: konieczność zaufania do operatora sieci.
• Gotowe rozwiązanie SaaS (system do wydawania certyfikatów, który „w tle” wykorzystuje blockchain) – zaleta: brak konieczności zajmowania się technicznymi szczegółami; wyzwanie: mniejsza elastyczność i konieczność oceny wiarygodności dostawcy.

Na potrzeby 90-dniowego pilotażu szkoły najczęściej wybierają trzeci wariant. Pozwala on skupić się na scenariuszu edukacyjnym, a nie na administracji węzłami czy pisaniu inteligentnych kontraktów.

Minimalne wymagania techniczne po stronie szkoły

Lista wymagań technicznych dla pierwszego pilotażu może być bardzo krótka. Zwykle wystarczy:

• stabilny dostęp do Internetu w gabinecie dyrektora, sekretariacie i salach, gdzie pracują nauczyciele biorący udział w pilotażu,
• nowoczesna przeglądarka internetowa (Chrome, Edge, Firefox) na komputerach, z których będą korzystać nauczyciele,
• adresy e-mail dla nauczycieli i (opcjonalnie) dla uczniów lub rodziców, jeśli certyfikaty mają być wysyłane indywidualnie,
• podstawowe narzędzia biurowe (arkusz kalkulacyjny) do przygotowania listy uczniów.

Dobrą praktyką jest wykonanie krótkiego „testu technicznego” już w pierwszym tygodniu etapu 2: koordynator IT sprawdza, czy z komputerów w szkole można się zalogować do wybranej platformy demo, czy działa generowanie przykładowego dokumentu oraz czy nie blokuje tego zapora sieciowa.

Bezpieczeństwo i RODO przy wyborze dostawcy

Zanim szkoła podpisze umowę lub regulamin korzystania z platformy, powinna odpowiedzieć sobie na kilka prostych pytań z perspektywy ochrony danych:

• Jakie konkretne dane osobowe trafiają do systemu? Czy da się zastosować identyfikatory zamiast pełnych imion i nazwisk?
• Czy dostawca pełni rolę procesora danych (podmiotu przetwarzającego) i czy oferuje umowę powierzenia przetwarzania zgodnie z RODO?
• Gdzie fizycznie znajdują się serwery – w UE, EOG, czy poza nimi?
• Czy platforma pozwala na usunięcie lub anonimizację danych ucznia na żądanie (przy zachowaniu niezmienności wpisu w blockchainie, np. poprzez odwołanie skrótu do już zanonimizowanego dokumentu)?

Najprostszy model wygląda tak: pełny dokument (np. PDF z certyfikatem) przechowywany jest w systemie szkoły lub u dostawcy w formie, którą da się w razie potrzeby usunąć, natomiast na blockchain trafia wyłącznie skrót kryptograficzny. Sam skrót nie pozwala odtworzyć treści dokumentu, ale umożliwia weryfikację jego autentyczności.

Projekt prostego modelu danych

Zanim powstanie pierwszy prototyp, zespół powinien wspólnie „rozrysować”, jakie informacje mają trafić do systemu. W przypadku certyfikatów może to być kilka podstawowych pól:

• identyfikator ucznia (np. numer z dziennika elektronicznego lub inny lokalny ID),
• nazwa kursu lub aktywności (np. „Koło programistyczne – poziom podstawowy”),
• data ukończenia,
• poziom osiągnięć (zaliczono / bardzo dobre / wyróżnienie),
• identyfikator szkoły (np. REGON, nazwa) i podpisującego (dyrektor, nauczyciel).

Ten „model danych” nie musi być opisany w języku technicznym. Może przyjąć formę prostej tabeli w arkuszu kalkulacyjnym, na której koordynator IT sprawdzi, czy wszystkie potrzebne informacje da się pozyskać z istniejących dokumentów i systemów szkoły.

Budowa prototypu: od arkusza Excel do pierwszego certyfikatu

Praktycznie każdy pilotaż, który udaje się zamknąć w 90 dni, zaczyna się od bardzo prostego przepływu:

1. Nauczyciel lub lider merytoryczny przygotowuje listę uczniów wraz z potrzebnymi polami w arkuszu kalkulacyjnym.
2. Koordynator IT importuje tę listę do wybranej platformy lub tworzy pierwsze wpisy ręcznie.
3. Platforma generuje testowe certyfikaty (PDF lub linki) oraz zapisuje odpowiednie skróty w blockchainie.
4. Zespół weryfikuje, czy:
   • certyfikat zawiera wymagane informacje,
   • kod QR lub link prowadzi do strony weryfikacyjnej,
   • osoba z zewnątrz (np. nauczyciel nieuczestniczący w projekcie) potrafi potwierdzić autentyczność dokumentu.

Na tym etapie nie chodzi o pełną automatyzację. Wystarczy, że prototyp pokazuje cały łańcuch: od danych wejściowych po certyfikat z możliwością weryfikacji. Automatyzację (np. integrację z e-dziennikiem) można rozważać dopiero po udanym pilotażu.

Testy wewnętrzne z udziałem nauczycieli

Zanim do systemu trafią prawdziwe dane uczniów, dobrze jest przeprowadzić krótki test wewnętrzny na fikcyjnych lub zanonimizowanych danych. Może to wyglądać tak:

• zespół pilotażowy wybiera kilku nauczycieli jako „testerów”,
• dla każdego z nich generowany jest „certyfikat testowy”,
• nauczyciele próbują:
  • odebrać certyfikat (np. przez link lub e-mail),
  • sprawdzić go telefonem lub na komputerze,
  • przesłać dalej (np. do innego nauczyciela) z prośbą o weryfikację.

Po takim teście warto spisać dwie listy: „co działa bez tłumaczenia” oraz „co było niejasne”. Druga lista staje się podstawą do modyfikacji instrukcji dla uczniów i rodziców.

Etap 3 (dni 61–90): pilotaż z udziałem uczniów i lista kontrolna

Przygotowanie uczniów i rodziców do udziału w pilotażu

Wprowadzenie uczniów do projektu można przeprowadzić przy okazji zwykłych zajęć lub zebrania klasowego. Dobrze sprawdzają się trzy krótkie komunikaty:

1. Co dostają uczniowie? – np. cyfrowy certyfikat potwierdzający udział w kursie, który można potem wysłać pracodawcy lub uczelni.
2. Jak będą używane ich dane? – jasne rozróżnienie: co trafia do systemu, co (w postaci skrótu) na blockchain, kto ma dostęp do treści dokumentu.
3. Jak długo potrwa pilotaż? – określony okres, po którym szkoła zdecyduje, czy projekt będzie kontynuowany.

Rodzicom można udostępnić jedną stronę informacji (w formie PDF lub wydruku), w której opisany jest cel projektu, zakres danych oraz kontakt do osoby odpowiedzialnej. Często po takim krótkim wyjaśnieniu obawy związane z „nową, tajemniczą technologią” znacząco maleją.

Przebieg pilotażu krok po kroku

Gdy wszystkie przygotowania są zakończone, przychodzi czas na właściwy pilotaż. W uproszczeniu można go ułożyć w następującej kolejności:

1. Zamknięcie listy uczestników – lider merytoryczny zatwierdza, którzy uczniowie spełnili kryteria (np. obecność, zaliczenie zadań).
2. Przygotowanie danych – koordynator IT lub nauczyciel generuje plik z danymi uczniów, zgodny z ustalonym modelem danych.
3. Wygenerowanie certyfikatów – platforma tworzy dokumenty, zapisuje skróty w blockchainie, a system odnotowuje datę i autora wpisu.
4. Dystrybucja – uczniowie otrzymują certyfikaty (e-mailem, przez dziennik elektroniczny albo w formie wydruku z kodem QR).
5. Weryfikacja – kilka osób z zewnątrz (np. inny nauczyciel, przedstawiciel pracodawcy) testuje mechanizm sprawdzania autentyczności.

W małej skali cały ten proces da się przeprowadzić w ciągu jednego lub dwóch tygodni. Najwięcej czasu zajmuje zwykle przygotowanie poprawnych danych wejściowych, dlatego dobrze jest wcześniej przetestować ich format na kilku rekordach.

Monitorowanie postępów w trakcie pilotażu

Żeby 90 dni nie rozmyły się w bieżących obowiązkach, pilotaż potrzebuje prostego mechanizmu monitorowania. Nie musi to być rozbudowany system raportowania – wystarczy kilka wskaźników i krótkie, regularne spotkania zespołu.

Dobrze sprawdzają się cotygodniowe lub dwutygodniowe „przeglądy” (30–45 minut), podczas których zespół odpowiada na trzy pytania:

• co udało się zrobić od ostatniego spotkania (np. liczba wygenerowanych certyfikatów, przeszkolonych nauczycieli),
• jakie problemy się pojawiły (techniczne, organizacyjne, komunikacyjne),
• co trzeba poprawić przed kolejną turą certyfikatów.

Do tego można dołożyć prosty arkusz z kilkoma polami liczbowymi, np.:

• liczba uczniów objętych pilotażem,
• liczba wygenerowanych certyfikatów,
• liczba zgłoszonych problemów (np. „nie dotarł e-mail”, „nie działa link”),
• liczba udanych weryfikacji dokonanych przez osoby spoza zespołu.

Takie minimum danych wystarczy, aby dyrekcja mogła po 90 dniach podjąć decyzję opartą na faktach, a nie na wrażeniach.

Zbieranie informacji zwrotnej od uczniów i nauczycieli

Bez informacji zwrotnej trudno ocenić, czy rozwiązanie jest dla użytkowników zrozumiałe i użyteczne. Zamiast jednego rozbudowanego kwestionariusza, lepiej zastosować krótkie, celowane ankiety – osobno dla uczniów i dla nauczycieli.

Przykładowo ankieta dla uczniów może zawierać kilka prostych pytań zamkniętych i jedno otwarte:

• czy udało Ci się bez problemu uzyskać dostęp do certyfikatu,
• czy wiesz, jak pokazać certyfikat nauczycielowi/pracodawcy,
• czy opis procedury był dla Ciebie zrozumiały,
• co było dla Ciebie najbardziej mylące lub trudne?

Nauczycielom można zadać nieco inne pytania:

• ile czasu zajęło przygotowanie danych dla jednej grupy,
• czy interfejs platformy był intuicyjny,
• jak oceniasz przydatność takiego certyfikatu dla ucznia (w skali 1–5),
• jakie zmiany w procesie lub narzędziu powinny zostać wprowadzone przed ewentualnym wdrożeniem na szerszą skalę?

Krótką ankietę można przeprowadzić online (formularz Google, Microsoft Forms), a wyniki omówić na ostatnim spotkaniu zespołu pilotażowego.

Reagowanie na problemy w trakcie 90 dni

Niemal każdy pilotaż napotyka niespodzianki: błędne adresy e-mail, literówki w nazwiskach, problemy z logowaniem do platformy. Kluczowe jest, aby nie „gasić pożarów” indywidualnie, lecz zbierać powtarzające się problemy i od razu modyfikować proces.

Praktycznym rozwiązaniem jest krótka „księga incydentów” – może to być jedna zakładka w arkuszu kalkulacyjnym z kolumnami:

• data zgłoszenia,
• kto zgłosił (uczeń, nauczyciel, rodzic),
• opis problemu,
• jak został rozwiązany,
• czy wymaga zmiany procedury (tak/nie).

Jeżeli ten sam typ problemu pojawia się więcej niż dwa–trzy razy, zespół powinien zdecydować, czy:

• zmienić instrukcję (np. dodać zrzuty ekranu albo krótkie wideo),
• zmodyfikować szablon danych wejściowych,
• poprosić dostawcę o drobną modyfikację interfejsu (np. jaśniejszy komunikat o błędzie).

Dzięki temu pilotaż nie kończy się jedynie na „odhaczeniu” zadań, ale realnie poprawia proces przed ewentualnym rozszerzeniem na całą szkołę.

Lista kontrolna na ostatnie dwa tygodnie pilotażu

Pod koniec 90 dni harmonogram zaczyna się zagęszczać. Pomaga wtedy prosta lista kontrolna, którą zespół przegląda wspólnie, np. na 75. i 85. dniu projektu.

Przykładowa lista zadań do potwierdzenia:

• wszystkie zaplanowane grupy uczniów otrzymały certyfikaty,
• przeprowadzono co najmniej kilka testowych weryfikacji z udziałem osób zewnętrznych (np. przedstawiciel lokalnego pracodawcy, nauczyciel z innej szkoły),
• zebrano ankiety od uczniów (przynajmniej od reprezentatywnej części grupy),
• zebrano ankiety lub komentarze od nauczycieli prowadzących,
• podsumowano najczęściej zgłaszane problemy i sposoby ich rozwiązania,
• koordynator IT przygotował krótką notatkę techniczną: co zadziałało, co wymaga poprawy, jakie są minimalne wymagania przy szerszym wdrożeniu,
• uzgodniono termin spotkania podsumowującego z dyrekcją.

Taka lista ogranicza ryzyko, że ważne elementy – szczególnie ankiety i notatki – zostaną odłożone „na później”, a potem trudno będzie je odtworzyć z pamięci.

Ocena efektów pilotażu przez dyrekcję

Po zakończeniu pilotażu dyrekcja potrzebuje przejrzystego materiału do decyzji: kontynuować, wstrzymać czy zmodyfikować projekt. Zespół pilotażowy może przygotować zwięzły raport, najlepiej w formie kilku slajdów lub krótkiego dokumentu.

Taki raport powinien zawierać trzy rodzaje informacji:

1. Dane liczbowe – ile osób objęto pilotażem, ile certyfikatów wystawiono, ile zgłoszono problemów, ile razy dokonano weryfikacji.
2. Jakościowe opinie – cytaty z ankiet (bez danych osobowych), kluczowe uwagi nauczycieli i uczniów, przykłady sytuacji, w których certyfikat był rzeczywiście użyty (np. do rekrutacji na staż).
3. Ocena zasobów – ile czasu realnie zajęła obsługa procesu, kto był zaangażowany, czy potrzebne są dodatkowe kompetencje lub wsparcie techniczne przy szerszym wdrożeniu.

Na tej podstawie dyrekcja może przyjąć jedno z kilku podejść:

• rozszerzyć pilotaż na kolejne klasy lub oddziały,
• utrzymać projekt tylko dla wybranych, specyficznych programów (np. dodatkowe zajęcia, konkursy),
• zatrzymać się na etapie pilotażu i przełożyć decyzję o pełnym wdrożeniu, jeśli pojawiły się poważne bariery (np. prawne lub organizacyjne).

Przykładowa matryca decyzji po pilotażu

Aby ułatwić dyskusję, można przygotować prostą matrycę „tak/nie” w czterech obszarach. Każdy z nich zespół ocenia na podstawie doświadczeń z pilotażu:

• Użyteczność dla uczniów – czy uczniowie widzą realną wartość w certyfikacie blockchain (np. planują go dołączyć do CV, pokazać na rozmowie rekrutacyjnej).
• Obciążenie dla nauczycieli – czy proces można obsłużyć w rozsądnym czasie, bez nadmiernej biurokracji.
• Bezpieczeństwo i zgodność z przepisami – czy zespół (wraz z Inspektorem Ochrony Danych) ma pewność, że dane są przetwarzane w sposób zgodny z RODO i wewnętrznymi regulacjami szkoły/organów prowadzących.
• Trwałość rozwiązania – czy dostawca wydaje się wiarygodny, czy ogranicza ryzyko „zniknięcia” usługi, czy istnieje możliwość migracji danych w przyszłości.

Dla każdego obszaru można przyjąć prostą skalę (np. od 1 do 5) i dopiero potem podjąć decyzję, czy przechodzić do etapu szerszego wdrożenia, czy raczej powtórzyć pilotaż z poprawkami.

Rozszerzenie zakresu: od pojedynczego kursu do całej szkoły

Jeżeli pilotaż się sprawdził, naturalnym krokiem jest rozszerzenie projektu. Zanim jednak rozwiązanie obejmie całą szkołę, przydaje się faza „półkroku” – np. dodanie kolejnych dwóch–trzech scenariuszy wykorzystania technologii.

Typowe kolejne obszary:

• certyfikaty z olimpiad i konkursów szkolnych,
• potwierdzenia udziału w kołach zainteresowań i projektach społecznych,
• zaświadczenia o ukończeniu modułów zawodowych lub specjalistycznych warsztatów.

W każdym z tych scenariuszy proces jest podobny, ale mogą zmieniać się szczegóły modelu danych (np. dodatkowe pola dotyczące organizatora, poziomu konkursu, rodzaju nagrody). Dlatego rozszerzenie warto planować etapami, tak aby zespół nie musiał na raz modyfikować zbyt wielu procedur.

Integracja z istniejącymi systemami szkoły

Po udanym pilotażu często pojawia się pytanie o automatyzację. Ręczne wprowadzanie danych dla kilku grup jest możliwe, lecz przy setkach uczniów rocznie staje się zbyt czasochłonne. Na tym etapie rozmowa z dostawcą lub działem IT organu prowadzącego schodzi na temat integracji.

Najczęstsze kierunki integracji to:

• eksport danych z dziennika elektronicznego (np. listy uczniów z zaliczeniem danego modułu),
• powiązanie z systemem kadrowym lub platformą e-learningową (np. automatyczne wystawienie certyfikatu po zaliczeniu kursu online),
• jednolite logowanie (SSO) dla nauczycieli, aby nie tworzyć kolejnego zestawu haseł.

Integracja nie jest konieczna w pilotażu 90-dniowym, ale dobrze, jeśli w trakcie prób zespół odnotowuje, jakie punkty można by w przyszłości zautomatyzować. To skróci późniejsze rozmowy techniczne i pozwoli realistycznie oszacować koszty wdrożenia.

Kształtowanie kompetencji cyfrowych wokół projektu

Projekt blockchain w szkole nie musi pozostać wyłącznie narzędziem administracyjnym. Można go włączyć w szerszy program kształtowania kompetencji cyfrowych uczniów. W wielu szkołach pilotaż był pretekstem do:

• lekcji o wiarygodności informacji w sieci (jak zweryfikować, czy dokument jest autentyczny),
• warsztatów z podstaw kryptografii (na prostych przykładach skrótów i podpisów cyfrowych),
• dyskusji o prywatności i ochronie danych w internecie.

W ten sposób projekt przestaje być „techniczną ciekawostką”, a staje się konkretnym kontekstem dla realizacji podstawy programowej z informatyki, wiedzy o społeczeństwie czy doradztwa zawodowego.

Utrzymanie i długofalowe zarządzanie rozwiązaniem

Jeżeli szkoła zdecyduje się korzystać z technologii blockchain dłużej, niż trwa pilotaż, trzeba ustalić, kto będzie „właścicielem” procesu. Najczęściej są to:

• koordynator IT (odpowiedzialny za kontakt z dostawcą, konta administracyjne, kwestie techniczne),
• wyznaczony nauczyciel lub wicedyrektor (odpowiedzialny za dobór scenariuszy edukacyjnych i komunikację z gronem pedagogicznym),
• Inspektor Ochrony Danych lub osoba wyznaczona (nadzór nad zgodnością z RODO).

Warto ustalić proste zasady, np. jak często przeglądane są uprawnienia w systemie, kto może generować certyfikaty, jak długo przechowuje się kopie dokumentów źródłowych oraz jak wygląda procedura w razie zmiany dostawcy.

Lista kontrolna po 90 dniach – czy projekt spełnił swoje cele?

Na zakończenie pierwszych 90 dni zespół może przejść przez krótką listę podsumowującą. Odpowiedzi „tak/nie” lub w skali od 1 do 5 pomogą szybko ocenić efekt pilotażu.

• czy udało się wygenerować i przekazać uczniom wszystkie zaplanowane certyfikaty,
• czy co najmniej kilku uczniów faktycznie wykorzystało certyfikat (np. w rekrutacji na praktyki, staże, zajęcia dodatkowe),
• czy nauczyciele deklarują gotowość do korzystania z systemu przy kolejnych edycjach kursów,
• czy proces obsługi nie przeciąża koordynatora IT ani sekretariatu,
• czy nie odnotowano poważnych incydentów związanych z ochroną danych lub bezpieczeństwem,
• czy organ prowadzący i IOD otrzymali pełną informację o przebiegu pilotażu,
• czy da się wskazać co najmniej jeden konkretny obszar, w którym projekt przyniósł realną oszczędność czasu lub wzrost przejrzystości (np. mniej papierowych zaświadczeń, łatwiejsze potwierdzanie osiągnięć absolwentów).

Jeśli większość odpowiedzi jest pozytywna, szkoła może traktować 90-dniowy pilotaż jako solidny fundament pod dalsze, przemyślane wdrożenie blockchainu w swoim ekosystemie edukacyjnym.

Najczęściej zadawane pytania (FAQ)

Od czego zacząć wdrożenie blockchain w szkole w 90 dni?

Pierwszy krok to wybór jednego, konkretnego procesu do pilotażu – np. certyfikaty z zajęć dodatkowych, potwierdzenia udziału w konkursach albo badge’e kompetencyjne. Nie warto zaczynać od przebudowy dziennika elektronicznego czy wszystkich świadectw.

Następnie trzeba jasno opisać, kto będzie uczestnikiem pilotażu (konkretna grupa uczniów i nauczycieli), jakie dane mają być rejestrowane na blockchainie oraz jaki efekt ma być mierzalny po 90 dniach (np. liczba wystawionych certyfikatów). Dopiero na tej podstawie dobiera się technologię i partnera technicznego.

Jakie konkretne problemy szkoły może rozwiązać blockchain?

Blockchain najlepiej sprawdza się tam, gdzie liczy się wiarygodność i trwałość danych. W szkole najczęściej dotyczy to:

• cyfrowych świadectw, dyplomów i certyfikatów kompetencji, które pracodawca lub uczelnia może łatwo zweryfikować bez kontaktu z sekretariatem,
• rejestru osiągnięć ucznia: mikrocertyfikatów, badge’y, portfolio projektów,
• niezmiennych logów ważnych decyzji (np. przyznanie dostosowań, ważne uchwały rady pedagogicznej dotyczące ucznia).

Technologia nie rozwiąże jednak problemów organizacyjnych sama z siebie – jeśli procedury są chaotyczne, blockchain tylko „utrwali” ten bałagan.

Jakie dane uczniów można bezpiecznie umieszczać na blockchainie?

Na blockchain zwykle nie trafiają pełne dane osobowe ani informacje wrażliwe (zdrowotne, socjalne, objęte tajemnicą). Najczęściej zapisuje się tam skróty kryptograficzne (hash) dokumentów lub odwołania do zaszyfrowanych zasobów przechowywanych w tradycyjnych systemach.

Oznacza to, że oryginalne dokumenty pozostają w bezpiecznych bazach szkoły, a blockchain służy jako niezmienny „stempel” potwierdzający, że dany dokument istniał w określonej postaci w konkretnym czasie. Takie podejście ułatwia spełnienie wymogów RODO i przepisów o ochronie danych.

Czy blockchain może zastąpić dziennik elektroniczny w szkole?

Blockchain nie jest zamiennikiem dziennika elektronicznego. Nie nadaje się do codziennego wpisywania ocen cząstkowych, frekwencji czy uwag, ponieważ takie dane często są korygowane i wymagają wygodnej, szybkiej edycji.

Może natomiast uzupełniać e-dziennik w obszarach, gdzie potrzebna jest trwałość i łatwa weryfikacja, np. przy potwierdzaniu końcowych ocen rocznych, wyników egzaminów zewnętrznych czy ważnych decyzji administracyjnych dotyczących ucznia.

Jak wygląda przykładowy plan wdrożenia blockchain w szkole w 90 dni?

Praktyczny plan dzieli 90 dni na trzy etapy po około 30 dni:

• Dni 1–30 – analiza i projekt pilotażu: wybór procesu (np. certyfikaty z koła robotyki), opis wymagań, zbudowanie zespołu i harmonogramu.
• Dni 31–60 – technologia i prototyp: wybór platformy blockchain, konfiguracja rozwiązania, przygotowanie i przetestowanie prostego prototypu.
• Dni 61–90 – pilotaż z uczniami: realne wystawianie certyfikatów lub wpisów, zbieranie opinii użytkowników, opracowanie raportu i wniosków na przyszłość.

Każdy etap kończy się konkretnymi rezultatami, które można łatwo „odhaczyć” na liście kontrolnej (np. „prototyp wystawił pierwsze testowe certyfikaty”).

Kto powinien odpowiadać za projekt blockchain w szkole?

Minimalny zespół pilotażowy obejmuje trzy role: dyrektora (lub wicedyrektora), koordynatora IT oraz lidera merytorycznego. Dyrektor odpowiada za decyzje formalne, komunikację z radą pedagogiczną i rodzicami oraz zgodność z prawem.

Koordynator IT zajmuje się stroną techniczną i kontaktem z dostawcą rozwiązania, a lider merytoryczny (np. opiekun koła, koordynator praktyk) pilnuje, by projekt realnie wspierał proces edukacyjny, a nie był tylko ciekawostką technologiczną. W małej szkole część tych ról może pełnić jedna osoba, ale musi być ktoś jednoznacznie decyzyjny.

Jak wybrać pierwszy proces szkolny do pilotażu blockchain?

Dobry proces na start powinien mieć ograniczony zakres, jasne granice czasowe i niskie ryzyko. Dobrze sprawdzają się m.in. certyfikaty z kursów dodatkowych, badge’e kompetencyjne dla uczniów szkół zawodowych/techników oraz potwierdzenia udziału w olimpiadach i konkursach.

Ważne, aby uczniowie w razie problemów technicznych i tak otrzymali tradycyjne, papierowe dokumenty, a szkoła traktowała pilotaż przede wszystkim jako bezpieczne pole do nauki i zbierania doświadczeń przed ewentualną skalą ogólnoszkolną.

Najważniejsze lekcje

• Blockchain w szkole ma sens tylko jako narzędzie do rozwiązania konkretnych problemów (np. chaos w dokumentach, trudna weryfikacja certyfikatów), a nie jako cel sam w sobie czy rewolucja całego systemu.
• W 90 dni realne jest przeprowadzenie ograniczonego pilotażu: wybór jednego procesu, analiza potrzeb, wybór technologii, stworzenie prostego prototypu, testy z małą grupą oraz podsumowanie wyników – bez wymiany wszystkich systemów.
• Największą wartość blockchain daje w obszarach wymagających wiarygodności i niezmienności: certyfikacji (świadectwa, dyplomy), rejestrach osiągnięć ucznia (portfolio, mikrocertyfikaty) i przejrzystych logach kluczowych decyzji edukacyjnych.
• Nie wszystkie dane powinny trafiać na blockchain – wrażliwe informacje pozostają w tradycyjnych systemach, a na łańcuchu bloków zapisuje się głównie skróty kryptograficzne dokumentów lub odwołania do zaszyfrowanych zasobów.
• Blockchain nie zastąpi dziennika elektronicznego, nie naprawi złej komunikacji ani nie uporządkuje bałaganu w procedurach – przed wdrożeniem trzeba najpierw uporządkować procesy, inaczej technologia tylko utrwali chaos.
• Kluczem do udanego startu jest wybór jednego, prostego scenariusza (np. certyfikaty z kursu dodatkowego, badge kompetencyjne, potwierdzenia udziału w konkursach) z małą, jasno zdefiniowaną grupą i niskim ryzykiem.

Przeczytaj również:

• 

  E-dyplomy na blockchainie: czy papierowe świadectwa…

• 

  Jakie zmiany blockchain wymusi na tradycyjnym nauczaniu?

• 

  Blockchain jako narzędzie walki z biurokracją w szkołach

• 

  Blockchain w edukacji: czy da się zdobyć środki na…

• 

  Blockchain w weryfikacji kompetencji miękkich i twardych

• 

  Blockchain a bezpieczeństwo danych edukacyjnych