Idee
Abstrakt
Celem artykułu jest prezentacja idei homologacji systemów informatycznych, jako metody nabywania oprogramowania, która ma wielkie szanse stać się antidotum na wiele problemów, z jakimi styka się Administracja Publiczna stosując metody bardziej „znane i lubiane”.
Tezy zawarte w artykule zostały zaprezentowane publicznie, na seminarium „Systemy Informatyczne w administracji publicznej — doświadczenia z realizacji Programu Syriusz” zorganizowanym przez Ministerstwo, Gospodarki, Pracy i Polityki Społecznej, dnia 30 czerwca 2004 r. Zobacz prezentację: „Homologacja systemów informatycznych — czyli jak kupić na rynku to, czego tam jeszcze nie ma” (PDF).
Artykuł został opublikowany w opracowaniu „Informatyka w Polityce Społecznej, Doświadczenia z realizacji SI Syriusz”, red. Zbigniew Olejniczak, Jerzy S. Nowak, Polskie Towarzystwo Informatyczne, Warszawa 2004, str. 127-138.
Organizacje potrzebują programów komputerowych i mają do wyboru kilka sposobów na ich zdobywanie. Jednym z tych sposobów, obecnie jeszcze mało rozpowszechnionym, aczkolwiek mającym wiele, w stosunku do sposobów konkurencyjnych, zalet, jest homologacja systemów informatycznych. Jest to faktycznie jedyny sposób pozwalający na nabycie produktu dedykowanego na zasadach rynkowych i właśnie to decyduje o sile tej metody. Każdy ze sposobów nabywania oprogramowania[1] ma jakieś wady i oczywiście dotyczy to również homologacji. Tak naprawdę jednak, największym mankamentem jest to, że nie nadaje się do wszystkiego i nie istnieje jeszcze żadna metoda formalna pozwalająca na wykazanie, że właśnie już teraz warto by zwrócić się w stronę homologacji. Aby homologacja mogła zostać zastosowana musi istnieć odpowiedni, atrakcyjny rynek. W przypadku administracji publicznej takich rynków można znaleźć dziesiątki, jeśli nie setki.
Oto pytanie, które dręczyło nie jeden już światły umysł! Ale po kolei. Zacznijmy od tego, że mam pewną potrzebę i zastanawiam się jak ją zaspokoić. Załóżmy, że ta potrzeba, to program komputerowy, wspierający procesy biznesowe zachodzące w jednostkach organizacyjnych administracji publicznej, za optymalizację których jestem w pewien sposób odpowiedzialny. Załóżmy też, że mam pewność co do tego, że potrzebuję tego programu i, że wiem dokładnie o jaki program mi chodzi[2]. Co mogę zrobić aby go mieć? Oczywiście możliwie najszybciej.
Wydaje się, że mam dwie drogi. Albo tę potrzebną mi aplikację (1) kupię na rynku (jeśli taka już istnieje), albo (2) będę musiał spowodować aby ona powstała, ale wówczas też będę musiał pogodzić się z życiem (przez pewien czas) w niepewności — ponieważ decyzja odnośnie wytworzenia oprogramowania, to nic innego jak zadowolenie się nadzieją.
Skupmy się na chwilę na tej drugiej ewentualności. Załóżmy, że nie boję się wyzwań i chcę uczestniczyć w procesie tworzenia nowego systemu informatycznego. W końcu z wykształcenia jestem informatykiem[3], a więc uwielbiam grzebać w programach. Decyzja odnośnie tego, kto ma wykonać produkt jest już wtórna i wiąże się z zaufaniem jakie mam do siebie (moich ludzi) i do świata tzw. profesjonalistów, a tj. firm, które żyją z tego, że piszą programy. Tak czy inaczej, pozostaje mi tylko wiara w to, że:
potrzebny mi produkt będę miał o czasie,
nie będzie on miał zbyt wielu bug'ów, uniemożliwiających jego wdrożenie,
nie poddam się w trakcie przedsięwzięcia, w związku z koniecznością wdrażania ciągłych zmian, prowadzenia renegocjacji, konstruowania aneksów, itp.,
nikt nie cofnie decyzji o przyznaniu środków na realizację projektu, uznając, że właśnie pojawiły się inne cele priorytetowe,
nie okaże się, że trochę się przeliczyłem i wszystko będzie musiało kosztować 3 razy tyle ile zakładałem, lub ile mi obiecano na początku,
że ... (i w tym momencie można by ogłosić konkurs na to, kto wskaże więcej potencjalnych zagrożeń dla projektu informatycznego i zapewniam, że walka o palmę pierwszeństwa byłaby bardzo zacięta[4]).
Na szczęście, wiarę moją mogę w pewien sposób wspomagać. Jeśli tylko obiło mi się o uszy coś takiego jak metodyka prowadzenia projektów informatycznych i dokonałem wyboru właściwej mojemu przedsięwzięciu metodyki — mogę spać już nieco spokojniej. Ale uwaga, tylko nieco. Jeśli znajdzie się taki, który zaręczy całym swoim majątkiem, że uda się i to na sto procent, to albo się w ogóle nie zna na rzeczy, albo należy do szajki Wolanda[5].
No dobrze, przyjmijmy teraz na chwilę, że to, co jest mi potrzebne już istnieje. Już teraz, od razu, natychmiast mogę to zobaczyć, przetestować, zweryfikować pod kątem przydatności. Czyż nie jest to ta sytuacja, o jaką powinno mi chodzić, kiedy skoncentruję swoją uwagę na rzeczywistych potrzebach tych, którzy są odbiorcami oprogramowania? No tak, z kupowaniem nie ma aż tyle fun'u co z produkcją, ale czy będę w stanie wybronić się ze swojej decyzji uruchamiania produkcji, sprowadzającej się do odkrywania koła na nowo?
Kiedy coś, co jest mi potrzebne już istnieje i mogę to po prostu nabyć, oczywiście i tak mogę znaleźć wiele powodów, dla których mimo wszystko lepiej byłoby zabrać się do roboty, a nie kupować. Jakie to mogłyby być przesłanki? Tak dla przykładu, tylko kilka:
ponieważ to coś można zrobić taniej niż kupić,
ponieważ to coś, co jest gotowe nie do końca wpasowuje się w moje potrzeby – chociaż uwaga: na pewno znajdą się tacy, którzy będą argumentować, że łatwiej byłoby to coś rozbudować i/lub przystosować niż zaczynać wszystko od zera,
ponieważ za tym czymś stoi monopolista, który już wielokrotnie pokazał, że później bezlitośnie wyssie z zamawiającego ostatnią złotówkę,
ponieważ nie wierzę, aby to coś dało się jeszcze dalej rozwijać, a przecież moje potrzeby tak często się zmieniają — muszę przecież mieć choć namiastkę pewności, że kolejne zmiany będą miały charakter ewolucji tego co jest, a nie rewolucji,
ponieważ… (ktoś kto lubi produkować zapewne znajdzie jeszcze wiele uzasadnień na potwierdzenie swojej decyzji o wszczęciu nowego projektu informatycznego — a może jest to miejsce na kolejny konkurs?).
Zróbmy jednak jeszcze jedno, ostatnie już, aczkolwiek dwupunktowe założenie:
-
Ja niżej podpisany, i tak dalej, i tak dalej… kieruję się tylko i wyłącznie dobrem beneficjentów aplikacji komputerowej, a to znaczy:
bezpośrednio: uczestników procesów biznesowych wspomaganych przez przedmiotowe oprogramowanie, oraz
pośrednio, co uznaję za ważniejsze: klientów administracji publicznej, bez których optymalizowane procesy nie miałyby w ogóle racji bytu,
Gotowy produkt, taki, który spełnia moje oczekiwania, już istnieje, a co więcej jest takich produktów kilka, na prawdziwie konkurencyjnym rynku, regulowanym przez jakość, cenę, czas dostawy oraz czas reakcji serwisu (i inne takie).
I co teraz? Robić – kupić? Kupić – robić? Oczywiście KUPUJEMY!
Ale, ale… pozostaje jeszcze jeden (mały) problem. Otóż punkt drugi ostatniego założenia, mówiący o tym, że to coś, co jest mi potrzebne już istnieje, nie zawsze jest prawdziwy[6]. Hm, wydawałoby się więc, że nie ma złudzeń co do tego, że skoro kupić się nie da, pozostaje jedynie zakasanie rękawów i zabranie się do ciężkiej pracy. A tymczasem jest jeszcze jedna możliwość, pozwalająca na sprowadzenie zagadnienia do tego, które zdążyłem już bardziej polubić[7].
Tą możliwością jest…
… HOMOLOGACJA SYSTEMÓW INFORMATYCZNYCH. (Ta-dam!)
Ha!. Właśnie takiego pytania bym teraz oczekiwał, a zatem spieszę z odpowiedzią.
HOMOLOGACJA SYSTEMÓW INFORMATYCZNYCH jest sposobem nabywania oprogramowania dedykowanego na zasadach rynkowych.
I co? Wow?! Tak, tak, w związku z tym, że tak wielkie skróty myślowe często bywają kłopotliwe, spróbuję dodać jeszcze kilka słów wyjaśnienia[8].
Otóż mówiąc „oprogramowanie dedykowane” mam na myśli program komputerowy spełniający specyficzne wymagania odbiorcy. Taki, którego jeszcze nie ma, ponieważ żaden z producentów, sam z siebie, nie zauważył tych potrzeb adresatów aplikacji i/lub nie doszedł do wniosku, że wykonanie (i sprzedanie) oprogramowania wychodzącego naprzeciw tym potrzebom, pozwala na odniesienie pewnych korzyści — np. na zarobienie paru groszy (lub milionów EURO) i/lub zdobycie referencji. Kiedy natomiast piszę „nabyć na zasadach rynkowych”, myślę mniej więcej o tym, że dostawcy produktów walczą o klienta prześcigając się jakością, szybkością, ceną, łatwością, przyjemnością, sprawnością, sprawiedliwością, prestiżem i… jeszcze kilkoma innymi cechami — o ile są dla kupującego istotne i cokolwiek by miały oznaczać. Chodzi o to, aby klient miał wybór wśród produktów i mógł dokonywać wyboru.
Poza homologacją, istnieje jeszcze kilka innych sposobów nabywania oprogramowania, o wiele bardziej znanych. Warto zatem dokonać krótkiego porównania.
Tabela 1. Homologacja na tle innych sposobów nabywania oprogramowania. Na podstawie [Metoda2002]. W komórkach tabeli, poszczególne literki oznaczają: Z – zamawiający, W – wykonawca, P – produkt, M – metodyka realizacji projektu informatycznego.
Powyższa tabela stanowi podsumowanie porównania różnych metod nabywania oprogramowania. Akapity poniżej, są szczegółowym omówieniem zagadnienia i odwołują się do poszczególnych komórek tabeli (jak w arkuszu kalkulacyjnym).
(A1-A5) Wymagania, jak by nie było, zawsze pochodzą od odbiorcy, a ten który kupuje bez zastanowienia się nad przydatnością (zasadnością) zakupu, albo jest delikatnie mówiąc dziwny, albo wydaje nie swoje pieniądze.
(A4) W przypadku oprogramowania „z półki” wymagania antycypuje wykonawca aplikacji i w stosunku co do rzeczywistych potrzeb zamawiających, oferowany produkt może charakteryzować się zarazem za wąską jak i za szeroką funkcjonalnością. Produkt „na półkę” ma za zadanie zaspokoić potrzeby wielu klientów, a zatem zawiera w sobie nadzbiór funkcji potrzebnych jednemu użytkownikowi. Często bywa, że adresatowi oprogramowania potrzeba zaledwie kilka procent, spośród wszystkich możliwości oferowanych przez program. Z drugiej strony, jeśli mamy specyficzne potrzeby, których nie dzieli z nami żaden inny klient producenta, zapewne w produkcie „z półki” nie znajdziemy pomocy w tym zakresie[9].
Aby coś kupić wykonawca oczywiście też musi znać swoje wymagania co do przedmiotu zakupu, a zatem nie jest tak, że w ogóle się już nie zajmuje zagadnieniem wymagań. Tak być nie powinno!
(B3) Za wyjątkiem tylko tego jednego przypadku, gdy zamawiający uważa, że sam jest najlepszym wykonawcą, w danej i konkretnej sytuacji — zawsze jest jakiś inny, zewnętrzny producent. Są jakieś zalety zabierania się samemu do prac programistycznych, w chwili, gdy, tak generalnie, ma się przed sobą inne cele niż zarabianie pieniędzy na produkcji oprogramowania. Administracja publiczna powinna więc traktować to jako absolutną ostateczność[10]. O kilku „za” wspomniałem już wcześniej. Warto jednak zastanowić się nad każdym z takich punktów weryfikując, ile ma on w sobie z prawdy.
(C1;C4) Koszty produkcji są tym czego nikt nie lubi, ale ktoś niestety musi je ponieść. Dlaczego jednak miałyby one spoczywać na zamawiającym. Przecież zamawiającemu nie zależy na tym, aby coś było produkowane. On chce to coś mieć. Kiedy koszt produkcji pozostaje po stronie wykonawcy (o ile nie mamy do czynienia z przebrzydłym monopolistą), będzie on szanował każdy grosz. To on powinien mieć nadzieję, że poniesione koszty się zwrócą. Dlaczego zamawiający miałby finansować jakieś niezrozumiałe dla siebie eksperymenty i próby?
(C5) W przypadku kosztów inwestycji w projekcie prowadzonym na zasadach partnerstwa publiczno-prywatnego sprawa jest bardzo ciekawa. Wydawałoby się, że koszty te ponosi wykonawca[11], ale tak na prawdę kredytuje on tylko swoją działalność produkcyjną. Przecież zamawiający umawia się z dostawcą co do ceny i warunków spłaty gdzieś na samym początku[12]. Faktycznie więc wielkiej różnicy, w stosunku do projektu outsourceowanego, w samej istocie rzeczy, nie da się zauważyć. Ot przesunięte są terminy płatności, co zapewne producent i tak jakoś uwzględnia w swoich wyliczeniach.
(C2;C3) Kiedy się produkuje samemu lub też kiedy wynajmuje się do tego zadania wyspecjalizowaną firmę, którą nadzoruje się w trakcie produkcji, trzeba mieć na to środki od razu. Ludziom trzeba płacić za ich pracę (czasem wydaje się, że płaci się za samo przychodzenie do pracy), bez względu na to czy są to nasi ludzie, czy też wynajęci. Jeśli nie mamy na to funduszy w tej chwili, to i tak, jak w przypadku C5, możemy zaciągnąć na ten cel kredyt. Tyle, że kredytodawcą (dla zamawiającego) nie będzie już producent, a dowolna, inna instytucja, mająca do tego prawo i mająca takie możliwości.
(D1-D5) Kolumna D w tabeli, mówiąca o tym jakich wyborów musi dokonać zamawiający wydaje się być najciekawsza. Cały poprzedni rozdział poświęcony został wykazaniu, że najlepsze co może przytrafić się klientowi to wybór spośród gotowych już produktów. Taką opcję gwarantują jednak tylko dwa podejścia.
(D1;D4) Wybór produktu jest możliwy tylko w przypadku zakupów „z półki” i w przypadku zakupu produktów homologowanych. To bardzo ważna cecha homologacji, która decyduje o sile tej metody nabywania oprogramowania.
(D2;D5) W przypadku projektu outsourceowanego oraz w przypadku projektu prowadzonego na zasadach partnerstwa publicznoprywatnego wybór dotyczy dostawcy. Już na samym początku musimy uwierzyć komuś, że ten ktoś jest w stanie na czas i za określoną sumę pieniędzy dać nam to, co jest nam potrzebne. I czynimy to na bazie obietnic oferenta, jego gwarancji oraz informacji o tym, czego udało mu się już kiedyś dokonać. Tłumaczymy też sobie, że jeśli coś pójdzie nie tak, to zawsze będziemy mogli obciążyć producenta jakimiś tam konsekwencjami. Bywa niestety, że się na to wszystko nabieramy. Nie myślimy o tym, że nawet jeśli niesolidny dostawca poniesie konsekwencje swojej niesolidności, to i tak żadna siła nie będzie w stanie sprawić aby niedziałający system nagle zaczął poprawnie funkcjonować. Dla zabezpieczenia się zazwyczaj żądamy od oferentów zaprezentowania metodyki jaka będzie stosowana w trakcie projektu, ale i tak nie jesteśmy w stanie zweryfikować sensowności tego co zostaje nam zaprezentowane. Zazwyczaj też nie zastanawiamy się na tym, że — tę raz zaprezentowaną — metodykę jeszcze warto weryfikować w trakcie trwania przedsięwzięcia. Takie sposoby nabywania oprogramowania nie są najszczęśliwsze. Gorsza może być już tylko jedna ewentualność.
(D3) No właśnie. Kiedy chcemy napisać program sami, pozostaje nam tylko wiedzieć jak się do tego zabrać. A wiedza ta mimo wszystko zawsze będzie lepsza po stronie firm, których podstawowa forma działalności wg PKD oznaczona jest symbolem: 7220Z.
(E2;E3;E5) Tam gdzie nie ma wyboru produktu, tam nie ma rynku produktów. O rynku producentów nie ma sensu mówić ponieważ to nie producenci są tym, co jest potrzebne zamawiającemu. Zamawiający potrzebuje… — tak, tak, wiem, już o tym pisałem, ale napiszę jeszcze raz. Zamawiający potrzebuje produktu.
(E1) W przypadku homologacji systemów informatycznych rynek oprogramowania musi zostać wykreowany przez zamawiającego. Dużą cześć swojego wysiłku, poza specyfikacją wymagań oraz działaniami marketingowymi skierowanymi na adresatów oprogramowania, zamawiający musi poświęcić właśnie temu, aby rynek był korzystny i atrakcyjny dla dostawców. Nie spodziewałbym się rewelacyjnych wyników tej metody, w przypadku gdy pragnienia zamawiającego byłyby skoncentrowane na pozyskanie puli darmowych programów do wyboru z natychmiastowym i darmowym serwisem.
(E4) Program „z półki” to klasyczny przypadek rynkowy. Producent szuka swojej niszy, tworzy coś nowego, stara się to sprzedać. Jak zaczyna mu iść dobrze, podpatrują go inni producenci. I życie jakoś posuwa się do przodu. Producenci wprowadzają coraz więcej unowocześnień, dodają kolejne funkcje i ogłaszają światu, że właśnie wytworzyli cud, który jest w stanie obniżyć koszty o 1000% i zminimalizować nakłady pracy 1000 razy. Jeśli zamawiający nie zastanawiają się nad swoimi rzeczywistymi potrzebami zaczynają wierzyć w to, co do nich dociera w reklamach.
(F1-F5) Mówi się, że rynek klienta jest lepszy od rynku producenta i nie ma to nic wspólnego z tym, kto ten rynek kreuje. Chodzi o to, kto dyktuje warunki. Zobaczmy więc, jak to się ma w odniesieniu do różnych sposobów nabywania oprogramowana.
(F2;F5) Kiedy wybieramy producenta, rzeczywiście do pewnego czasu dyktujemy warunki. Zapisujemy je najpierw w SIWZ lub TOR, a później egzekwujemy w ramach prac komisji przetargowej. Tajemnicą poliszynela jest jednak to, że po dokonaniu wyboru robimy już wszystko, aby właśnie z tym wybranym wykonawcą dobrnąć do końca, bez względu na to jak prace idą źle. A jakże mielibyśmy się przyznać do tego, że dokonaliśmy złego wyboru, albo, że zaakceptowaliśmy jakieś złożone nam propozycje, których nie zrozumieliśmy do końca, a które mają niestety tę nieprzyjemną cechę, że fizycznie nie dadzą się zrealizować w wyznaczonym czasie, bez względu na to ilu ludzi byśmy mogli jeszcze dokooptować[13]. Z drugiej strony przecież i tak nie mamy gwarancji, że z kimś innym szłoby lepiej. Jeśli wykonawca nawala, możemy go oczywiście ukarać, pogrozić mu, dać mu negatywne referencje, ale przecież to w żaden sposób nie spowoduje, że pożądany system otrzymamy na czas. A zatem jakie są nasze możliwości w dyktowaniu warunków?
(F3) Kiedy produkt tworzymy sami, oczywiście możemy sobie sami dyktować warunki. Problem jednak i tak sprowadza się do tego, który został opisany wyżej. Jak nie będziemy dawać rady, znajdziemy winnych w swoim gronie, a i tak szybciej nie będzie.
(F4) Kiedy możemy coś kupić na rynku produktów „z półki” sytuacja wygląda już nieco lepiej. Rzecz jasna, jeśli jest jakiś wybór, tzn. istnieje jakaś konkurencja pomiędzy produktami. Wybierzemy oczywiście najlepszą dla nas ofertę i od razu otrzymamy program. Ale i tu pewnie skończą się nasze możliwości dyktowania warunków. Producenci systemów „na półkę” już mają swoje sposoby, aby uprzykrzyć nam życie, w materiałach marketingowych przedstawiając oczywiście zgoła odmienne spojrzenia. A „przesiąść się” z jednego programu na inny, który niby zapewnia tę samą funkcjonalność, nie jest tak łatwo. Dlaczego? Ot, do funkcjonalności tej trzeba się zazwyczaj dobierać w zupełnie inny sposób.
(F1) W przypadku homologacji mamy możliwość wyboru produktu, a jednocześnie pozostawiamy sobie opcję przejścia na inne, konkurencyjne rozwiązanie. To my przecież formułujemy wymagania dla konkurencyjnych rozwiązań, więc możemy chcieć, aby były one ze sobą kompatybilne.
Skoro tyle pozytywów udało mi się już zebrać na temat homologacji systemów informatycznych[14] pewnie każdy chciałby wiedzieć jak to się robi. To naprawdę proste, choć oczywiście jak zwykle diabeł może tkwić w szczegółach.
Szczegóły każdej implementacji tego procesu nabywania oprogramowania mogą być różne i zapewne jest jeszcze wiele miejsca na innowacje, pozwalające na to, aby proces ten był jeszcze lepszy niż wszystkie te jego wersje, które już kiedyś, gdzieś zostały zastosowane. W uogólnieniu, wszystko powinno się mieścić w następujących ramach:
Zamawiający opracowuje wymagania homologacyjne dla kolejnej wersji produktu oraz zasady dopuszczania produktów spełniających te wymagania do rynku.
Zamawiający publikuje wymagania i zasady homologacyjne, zapraszając wykonawców do udziału w rynku (otwiera rynek).
Wykonawca pozyskuje wymagania i zasady homologacyjne.
Wykonawca analizuje opłacalność inwestycji.
Wykonawca opracowuje produkt.
Zamawiający dokonuje weryfikacji produktu na okoliczność jego zgodności z wymaganiami homologacyjnymi.
Zamawiający przyznaje produktowi świadectwo homologacji — świadczące o spełnieniu przez produkt wymagań homologacyjnych i dopuszczające go do rynku. Jednocześnie też zamawiający informuje o tym fakcie wszystkich adresatów oprogramowania składających się na rynek.
Wykonawca sprzedaje swój produkt na rynku, konkurując z innymi wykonawcami.
Użytkownicy dokonują zakupów.
Użytkownicy wykorzystują zakupione oprogramowanie.
Powyższe jedenaście punktów, to tylko szablon głównego strumienia wartości — ścieżki standardowej procesu homologacji, od której odchyleń można znaleźć zapewne wiele. Z jednej strony, w każdym z powyższych kroków może się zdarzyć coś nieoczekiwanego — ot, chociażby to, że w dowolnej chwili już zapisane wymagania przestaną być aktualne. Albo na przykład to, że któremuś z wykonawców nie uda się przejść pozytywnie przez testy homologacyjne.
Z drugiej strony, sama ścieżka standardowa może być bardziej rozbudowana:
Zamawiający, z jakichś tylko jemu znanych powodów może chcieć, aby przed krokiem szóstym (6), powiedzmy na miesiąc wcześniej, wykonawca podpisywał jakieś zobowiązanie.
Sama procedura akceptacji może być rozbita na kilka etapów (akceptacja wstępna, zgrubna, szczegółowa, itd.).
Do udziału w kroku pierwszym mogą zostać zaproszeni potencjalni wykonawcy, dla których będzie to szansa na wcześniejsze zapoznanie się z wymaganiami oraz możliwość wpłynięcie na nie, w zamian za co zamawiający otrzymałby szeroką weryfikację swoich koncepcji.
Skoro mamy już zgrubne pojęcie o tym, jak można zorganizować proces nabywania oprogramowania na zasadach homologacji, poświęćmy jeszcze jedną chwilę na SWOT tej metody. Uporządkuje to nieco wcześniej rozgłaszane zalety i odsłoni to, co niestety w homologacji nie jest już takie przyjemne. W analizie została podjęta próba spojrzenia z możliwie wielu stron zaangażowanych w pozyskanie oprogramowania — zamawiającego, odbiorcy i wykonawcy[15].
Silne strony
Adresaci oprogramowania otrzymują możliwość dokonania wyboru pomiędzy rzeczywistymi aplikacjami. Jest to cecha, jaka poza homologacją, występuje jedynie w przypadku zakupów oprogramowania „z półki”, a zatem wymyślonego przez marketing firm informatycznych. W przypadku homologacji mamy jednak do czynienia z oprogramowaniem wymyślonym przez zamawiającego.
Adresaci oprogramowania mogą dokonywać wyboru sami, a zatem nikt nie może mieć pretensji, że coś zostało narzucone, w szczególności z góry, przez centralę. Jest to cecha szczególnie istotna w przypadku programów komputerowych dedykowanych jednostkom administracji samorządnej, gdy za dostarczenie właściwych programów komputerowych odpowiedzialne są jednostki szczebla centralnego.
Koszty inwestycji w trakcie wytwarzania oprogramowania ponosi dostawca, czyli tak samo jak w przypadku oprogramowania „z półki”. Zamawiający nie kupuje kota w worku i nie płaci zanim nie zobaczy gotowego systemu na oczy, a co więcej nie musi kupić oprogramowania, które mu się nie podoba lub pochodzi od firmy, która się mu nie podoba.
W porównaniu z innymi metodami nabywania oprogramowania, oprogramowanie homologowane powstaje szybciej i jest „lepsze”. Dzieje się tak dlatego, że szansę na sprzedaż swoich rozwiązań mają przede wszystkim ci producenci, którzy wykażą się lepszą ofertą, a zatem dostarczą na rynek swoje produkty szybciej niż konkurencja i produkty te będą się charakteryzowały wyższą jakością niż programy konkurencyjne. W przypadku, gdy wytwarzamy oprogramowanie sami, albo też zamawiamy je u jedynego słusznego dostawcy, tak naprawdę nie wiemy czy nie można by zrobić czegoś szybciej i lepiej. Kiedy istnieje konkurencja, to właśnie ona pokazuje, że jednak się da. Nawet w przypadku produktów „na półkę” prace nie idą tak dobrze, jak w przypadku programów homologowanych. Jeśli produkt jest nowy, producent utrzymuje prace nad nim w tajemnicy i dopieszcza, aż do momentu, gdy uzna, że jest on wystarczająco dobry, aby rynek go kupił. Jeżeli istnieje silna konkurencja, producenci prześcigają się w dostarczaniu nowych funkcjonalności swoich produktów, często nawet kosztem ich dopracowania. W związku z niekompatybilnością aplikacji „z półki” najważniejszą rzeczą jest sprzedanie jak największej liczby egzemplarzy programu. Nie od dziś wiadomo bowiem, że przejść na coś nowego i nie do końca zgodnego jest przeciętnemu klientowi bardzo, ale to bardzo trudno.
Oprogramowanie homologowane jest tańsze. Wykonawcy liczą na zysk, ale minimum jakie zakładają że osiągną, to zwrot kosztów zainwestowanych w wytworzenie i sprzedaż swoich produktów. W związku z tym, że inwestycja leży właśnie po ich stronie, zapewne będą oglądać każdą złotówkę — a tak z pewnością nie czynią, kiedy stroną finansującą przedsięwzięcie jest zamawiający. Oczywiście kiedy zamawiający finansuje powstanie potrzebnego produktu, to on ogląda każdy grosz, jednak zazwyczaj nie ma żadnych racjonalnych podstaw do uważania, że coś powinno być tańsze. Pozostaje mu wróżenie z fusów, albo nadstawianie ucha na podszepty tych, którzy nie wygrali tradycyjnego przetargu na outsourcing projektu i ponoszenie wydatków na wielostopniową weryfikację. Dla adresatów oprogramowania jest taniej ponieważ ceną steruje rynek.
Pozyskać kontrakt na dostawę oprogramowania produkowanego na zamówienie nie jest łatwo, jak również nie jest łatwo wykreować nowy produkt „na półkę”. W przypadku homologacji, firmy nie muszą walczyć o kontrakt przedstawiając argumenty za tym, że potrafią sprostać zadaniu. Jeśli same w to wierzą muszą jedynie zakasać rękawy i zabrać się do roboty. Nie muszą też wymyślać produktów i kreować rynku dla nich, bo to należy do zamawiającego.
Produktów do wyboru może być znacznie więcej niż firm przystępujących do przetargu na jednego wykonawcę oprogramowania. Kiedy przystępujemy do poszukiwań wykonawcy, staramy się tak sformułować swoje wymagania, aby w trakcie realizacji projektu czuć się tak bezpiecznie, jak to tylko możliwe. Prosimy więc oferentów o wykazanie doświadczenia w podobnych przedsięwzięciach, gwarancje, opisy metod pracy, itp. Takie wymagania są w stanie spełnić jedynie wielcy gracze. W przypadku homologacji systemów informatycznych do walki może przystąpić każda firma, która sama jest w stanie uwierzyć, że da radę i nie musi tego nikomu udowadniać, inaczej jak tylko przedstawiając gotowy i sprawnie funkcjonujący program. Małe firmy, jeszcze nie zbiurokratyzowane i nie funkcjonujące w rozproszeniu często działają o wiele sprawniej niż ci, którzy tych małych nawet nie chcą uważać za swoją konkurencję. Tyle, że nie jest łatwo dać szansę tym małym, aby mogli to udowodnić.
Zamawiający może skupić swoją uwagę na wymaganiach na system. Kiedy wykonuje on oprogramowanie sam musi oczywiście za wszystko sam odpowiadać. Kiedy zamawia wykonanie produktu zazwyczaj chce sprawdzać czy wszystko „pod maską” systemu jest w porządku, aby upewnić się, że system będzie gotowy do następnej rozgrywki[16].
Jawność. Wymagania na system homologowany są udostępniane wszystkim zainteresowanym, nie tylko tym, którzy wyrażą swoją chęć wykonania zadania programistycznego. Dzięki temu możliwe jest uzyskiwanie sygnałów zwrotnych mówiących o jakości samych wymagań. W ten sposób dostarczamy też materiał dla przyszłych kadr informatycznych — np. studentów kierunków informatycznych, którzy podczas nauki stykają się zazwyczaj jedynie z fikcyjnymi problemami. Cenną cechą homologacji jest też jawność samej procedury dopuszczenia do rynku. Każdy wie jak może być traktowany i jak będą traktowani jego konkurenci.
Możliwość otrzymania wielu rozwiązań właściwych różnym odbiorcom. Wymagania na system są jedne jednak odbiorcy tych produktów nie muszą być jednakowi. Widać to wyraźnie na przykładzie Ośrodków Pomocy Społecznej. Jedne ośrodki zatrudniają kilku pracowników, inne kilkudziesięciu, jedne załatwiają kilkadziesiąt spraw w ciągu miesiąca, inne w tym samym okresie kilka tysięcy. Te uwarunkowania nie pozostają bez wpływu np. na dobór odpowiednich technologii.
Słabe strony
Pracochłonność przyznawania świadectw homologacyjnych. Rynek tworzy zamawiający, poprzez publikację wymagań homologacyjnych i zaproszenie firm do ich spełnienia. Zamawiający musi następnie zweryfikować wszystkie przedstawione, gotowe rozwiązania, na okoliczność ich zgodności z wymaganiami homologacyjnymi. Im więcej tych rozwiązań do weryfikacji, tym więcej pracy trzeba włożyć.
Pracochłonność przygotowania wymagań homologacyjnych. Wymagania na system powinny być rozszerzone o elementy, które można by pominąć w przypadku zamówienia na wykonanie jednego rozwiązania. Do tych wymagań powinny być zaliczone wymagania odnośnie jednolitego formatu eksportu/importu danych oraz wskazówek odnośnie sposobu użytkowania programu, tj. poruszania się programie przez użytkowników. Wymagania takie pozwalają na sprawną (w miarę) migrację pomiędzy poszczególnymi homologowanymi aplikacjami, eliminując zagrożenie „odpuszczania sobie” przez dostawców już zdobytych klientów. Niestety sprzedawcy często wychodzą z założenia, że strach ludzi przez zmianą jest zazwyczaj tak ogromny, że wolą oni już pozostać przy kiepskim, ale znanym rozwiązaniu, niż podejmować ryzyko sprawdzania czegoś nowego.
-
Homologacja niestety nie do wszystkiego się nadaje. Aby możliwe było zastosowanie homologacji, musi być możliwe wykreowanie rynku. A rynek to[17]:
zbiór aktualnych i potencjalnych klientów,
dla danego produktu lub usługi,
którzy to klienci dzielą ten sam zbiór potrzeb i wymagań,
i którzy mają możliwość komunikowania się miedzy sobą podejmując decyzję w odniesieniu do zakupu,
Tak więc jeśli potencjalny klient jest tylko jeden (chodzi o jedno wdrożenie systemu, np. w centrali) to nie ma zbioru klientów, więc o rynku nie może być mowy. Bez wątpienia im większy jest zbiór klientów i im mniejszy jest zbiór ich potrzeb i wymagań, tym łatwiejsze jest kreowanie rynku. W którym momencie zaczyna być sensowne rozpoczęcie myślenia o zastosowaniu mechanizmów homologacji? To już niestety bardzo trudno powiedzieć i w zasadzie każdy przypadek należałoby rozpatrywać z osobna. Oczywiście piękną rzeczą byłby posiadanie równania typu:
[liczba klientów] × [liczba wymagań] > [X (znane)]
którego spełnienie mówiłoby nam o możliwości zastosowania homologacji, ale taki wzór nie istnieje i wątpliwym jest aby kiedykolwiek powstał[18].
Wymagania na produkt homologowany muszą być lepiej zapisane niż ma to miejsce, gdy zamawiający płaci za projekt. Związane to jest ze złożonością komunikacji. W przypadku homologacji trudno jest sobie wyobrazić podejście, które warto wziąć pod uwagę przy tradycyjnych projektach na zamówienie, polegające na posadzeniu, na czas trwania przedsięwzięcia, wszystkich osób zaangażowanych razem (użytkowników, doradców, analityków, projektantów, programistów, etc.). To jest realne w przypadku projektów outsourceowanych, a że się tego najczęściej nie stosuje, to już inna sprawa. Kiedy ma się wielu konkurujących ze sobą dostawców, po prostu nie da się ich zebrać wszystkich razem, na stałe.
Pracochłonność obsługi wielu dostawców. Wszyscy dostawcy powinni być jednakowo traktowani i powinni posiadać te same, pochodzące od zamawiającego, informacje. A do tego potrzeba niestety nieco więcej formalizmów, jak np. powołanie jakiegoś ciała koordynującego złożonego z przedstawicieli wszystkich stron (rada homologacji), organizacja spotkań wszystkich uczestników, strona WWW z odpowiedziami na często zadawane pytania, e-mailow'a lista dyskusyjna, forum internetowe, itp. Do tego dochodzi jeszcze konieczność obsługi podmiotów, które powiedzmy, że nie nadążają za średnią — nie można wykluczyć nikogo tylko za to, że pewne rzeczy pojmuje nieco wolniej niż pozostali.
Wodospad. Niemal wszystkie współczesne metodyki wytwórcze oprogramowania głoszą, że do sukcesu łatwiej jest dojść gdy zastosuje się podejście iteracyjne, ewolucyjne czy też spiralne[19], które to podejścia wychodzą na przeciw temu, że zamawiający, tak naprawdę to dokładnie nie wie czego chce i łatwiej jest się mu określić, kiedy otrzyma już coś działającego. Wtedy jest w stanie powiedzieć czy prace idą w dobrą stronę oraz podpowiedzieć, co można by poprawić. W podejściach tych wymagania są rozwijane równolegle z powstającym produktem, a w przypadku homologacji muszą być gotowe w chwili ogłaszania zaproszenia dla firm. Oczywiście nic nie stoi na przeszkodzie, aby zamawiający udostępniał wymagania partiami, w miarę ich uzupełniania, jednak moment ogłoszenia kompletnych wymagań jest jeden i nie sposób jest sobie wyobrazić, aby w wyniku wcześniejszego, nieoficjalnego ich ujawniania zjawiało się u zamawiającego dziesięciu wykonawców ze szczątkowymi prototypami. Każdy wykonawca, na równych prawach z innymi wykonawcami, winien przystępować do weryfikacji swojego rozwiązania zgodnie z warunkami określonymi w przyjętych zasadach homologacji, nie wcześniej niż po ogłoszeniu wymagań homologacyjnych.
Szanse
Możliwość zaistnienia małych firm i uzyskania przez te firmy znakomitych referenci na przyszłość. To nie jest zaleta jedynie dla wykonawców, ponieważ w ten sposób powiększa się rynek producentów, możliwych do wyboru w późniejszych przetargach na realizację projektów. W standardowych procedurach przetargowych wyłaniane są zazwyczaj firmy duże, ponieważ takim łatwiej jest udowodnić, że są w stanie zrealizować zamówienie, a zamawiającym zależy przede wszystkim na uzyskaniu jako takich gwarancji, że przedsięwzięcie ma szanse powodzenia. W przypadku homologacji liczą się nie tyle zapewnienia, że ktoś może sprostać zadaniu, a namacalne dowody w postaci gotowego i sprawnie funkcjonującego oprogramowania.
Możliwość uzyskania dochodu przez wiele firm. To może wydawać się mało istotne z punku widzenia administracji publicznej, bo można by powiedzieć, że skoro pieniądze mają i tak zostać wydane, to nie ważne czy weźmie je jeden czy więcej producentów – ważne aby produkt, za który się płaci był wart tych pieniędzy. To oczywiście mamy zapewnione, a uzasadnienia znalazły się wyżej. Rzecz o jakiej mowa w bieżącym punkcie to przyczynek do zastanowienia się nad ogólną sytuacją kraju, w którym brakuje klasy średniej (ale to już zupełnie inne zagadnienie).
Homologacja, to rówanież szansa do dużych producentów, przyzwyczajonych do wygrywania dużych kontraktów, na duże systemy. Te firmy, tak na prawdę nie mają okazji się sprawdzić i nie wiedzą, czy są w stanie lepiej produkować niż inni. Teraz wiedzą tylko tyle, że mają sprawniejszych sprzedawców. Dostarczając swoje produkty na zasadach homologacji, mogą się dowiedzieć o sobie wiele więcej. Mogą się dowiedzieć, że są lepsi od nich (to czasem boli), ale dzięki temu będą też mogli popracować nad ulepszeniami.
Zagrożenia
Zagrożenie najważniejsze wiąże się z ewentualną nieumiejętnością kreowania rynku. Zamawiający musi zaproponować warunki możliwe do zaakceptowania przez producentów oprogramowania. W innym przypadku albo zostanie z rynkiem zmonopolizowanym, albo też w ogóle z niczym.
Firmy tworzące oprogramowanie podlegające homologacji mogą stosować różne, pseudomarketingowe „chwyty”, mające na celu wprowadzenie w błąd nabywców oprogramowania. Ot, chociażby ceny dumpingowe, znacznie odbiegające od możliwych kosztów wytwarzania. To oczywiście rzecz trudna do udowodnienia, ponieważ istnieje wiele sposobów na to, aby zrobić coś szybciej (można złożyć z gotowych komponentów, można skorzystać z własnej biblioteki wcześniejszych rozwiązań, można zatrudnić lepszych, bardziej doświadczonych specjalistów, można skorzystać z właściwszej danemu przedsięwzięciu metodyki, etc.). Może to jednak powodować, że wybierane będą rozwiązania wcale nie najlepsze — zagrożenie to mogą minimalizować wymagania związane z „łatwym” zmienianiem aplikacji.
Dostawcy oprogramowania mogą zmawiać się co do minimalnej ceny żądanej za swoje rozwiązania.
W związku z tym, że producenci kierowani wymaganiami rynku zmuszeni są do robienia tanio i szybko, może się okazać, że będą mieli ciągoty do poświęcania jakości.
Homologacja nie jest na rękę wielkim korporacjom informatycznym, przyzwyczajonym do wygrywania kontraktów na wykonanie oprogramowania i można się spodziewać, że ich przedstawiciele będą starali się pokazywać, że mimo wszystko homologacja zawsze wypada gorzej od projektów outsourceowanych, czy też prowadzonych na zasadach partnerstwa publiczno-prywatnego. W homologacji nie ma już przecież takich możliwości dyktowania warunków przez wykonawcę.
Homologacja systemów informatycznych jest stosowana przez ministerstwa Ministerstwo Gospodarki i Pracy oraz Ministerstwo Polityki Społecznej[20] i była już stosowana kiedy było to jedno Ministerstwo Gospodarki, Pracy i Polityki Społecznej, jak również jeszcze wcześniej, gdy w tym ostatnim nie występował jeszcze człon Gospodarka. No dobrze, wszystkie te zmiany następowały po sobie w nieznacznych odstępach czasu, ale i tak jest to kilka lat doświadczenia pokazujących, że może się to opłacać. To właśnie na podstawie obserwacji homologacji systemów na potrzeby Jednostek Organizacyjnych Pomocy Społecznej, oraz od niedawna na potrzeby obsługi świadczeń rodzinnych powstał niniejszy materiał.
Zasady homologacji, które są stosowane w tych przedsięwzięciach obecnie nie są już tymi samymi zasadami, jakie obowiązywały powiedzmy dwa lata temu. I oczywiście bardzo dobrze. Zdobywając nowe doświadczenia należy ulepszać swoje procesy. Na pewno też wiele jeszcze dało by się ulepszyć i z tego co wiem, wynika, że prace nad kolejnymi pomysłami innowacyjnymi nie ustają.
Aby zobaczyć gdzie jeszcze homologacja systemów informatycznych na potrzeby administracji publicznej mogłaby zostać zastosowana wystarczy przejrzeć wykazy zadań stawianych w odpowiednich ustawach przed samorządami gminnymi i powiatowymi. Wybór tego sposobu nabywania oprogramowania wydaje się być korzystny nie tylko dla administracji, ale również dla szeroko pojmowanej gospodarki. Może jest to też doskonała metoda na informatyzację administracji w innych krajach Unii Europejskiej.
[Ganowski2004] Procesy Biznesowe a Informatyzacja Administracji Publicznej, w: Systemy informatyczne w administracji, red. Zbigniew Olejniczak, Jerzy S. Nowak, Janusz K. Grabara, s. 65-72.. Wydawnictwa Naukowo Techniczne. Warszawa, 2004.
[Jeruzalski2004] Procedura homologacji w budowie systemu SYRIUSZ, w: Informatyka w Polityce Społecznej, Doświadczenia z realizacji SI Syriusz", red. Zbigniew Olejniczak, Jerzy S. Nowak, str. 139-150.. Polskie Towarzystwo Informatyczne. Warszawa, 2004.
[Mierzwińska2004] Homologacja systemów informatycznych stosowanych w administracji publicznej, w: Informatyka w Polityce Społecznej, Doświadczenia z realizacji SI Syriusz", red. Zbigniew Olejniczak, Jerzy S. Nowak, Polskie Towarzystwo Informatyczne, Warszawa 2004, str. 111-116.. Polskie Towarzystwo Informatyczne. Warszawa, 2004.
[1] Słowo „nabyć” sugeruje, że to coś, co nabywamy staje się naszą własnością i możemy z tym czymś zrobić wszystko, co możemy zrobić z innymi rzeczami, które do nas należą (np. odsprzedać innej osobie, wynająć, sprezentować, przerobić, etc.). W przypadku większości popularnie używanych programów, przede wszystkim tych „z półki”, nie jest to prawdą, ponieważ kupujemy nie programy, a licencje pozwalające nam na korzystanie z nich. Nie ma to znaczenia dla treści zawartych w niniejszym artykule.
[2] O tym co może oznaczać pewność, że czegoś potrzebuję, oraz o tym jak to takiej pewności można dojść pisałem w artykule [Ganowski2004].
[3] Zdanie informatyków w procesie podejmowania decyzji w sprawie nabywania oprogramowania przez organizacje jest bardzo istotne i nie liczyłbym na to, że da się je w najbliższej przyszłości pominąć. Obecne trendy są takie, że tzw. CIO (ang. Chief Information Officer — powiedzmy: szef informatyków w organizacji) jest stałym współpracownikiem, jeśli nie członkiem zarządu.
[4] Aby zwiększyć szanse wygranej proponuję uprzednie zapoznanie się z literaturą fachową, a przede wszystkim z wszelkimi wariacjami na temat praw Murphy'iego oraz ze wszystkimi przygodami Dilberta.
[5] Taki przesympatyczny gość z powieści Michaiła Bułhakowa „Mistrz i Małgorzata”.
[6] Punkt pierwszy też nie zawsze jest prawdziwy, ale to już naprawdę zupełnie inna sprawa, w przypadku administracji publicznej zapewne dla Najwyższej Izby Kontroli.
[7] Pozwolę sobie zwrócić uwagę na fakt, że cały dotychczasowy wywód miał na celu wykazanie, że kupowanie produktów gotowych przez administrację publiczną jest lepsze niż uruchamianie procesów produkcyjnych. W dalszej części niniejszego opracowania będę traktował to jako aksjomat.
[8] To moja własna definicja homologacji systemów informatycznych, jeszcze nie przetestowana przez szeroką opinię – możliwe więc, że wymaga, aby coś do niej dodać lub coś z niej ująć. Wynika ona z blisko dwuletniej obserwacji zmagań z homologacją oprogramowania na potrzeby Jednostek Organizacyjnych Pomocy Społecznej.
[9] Czy ktoś widział edytor tekstu pozwalający na wstawianie spacji nierozdzielających, które podczas wyrównywania tekstu do lewego i prawego marginesu jednocześnie, byłyby traktowane przy rozdziale przerw między wyrazami jak zwykłe spacje? A ilu tak naprawdę użytkowników popularnych edytorów tekstu wie w ogóle co to jest spacja nierozdzielająca, w formie takiej jaka jest dostarczana przez te programy?
[10] W związku z tym, że artykuł niniejszy jest dedykowany nabywaniu oprogramowania przez administrację publiczną, pozwolę sobie wyrazić myśl tę w sposób bardziej bezpośredni: celem administracji publicznej nie jest tworzenie oprogramowania.
[11] Sam się na to nabrałem — podziękowania dla Pawła Szulca, za otwarcie oczu.
[12] Później, oczywiście, wszystko może być renegocjowane, ale nie ma mowy o tym, że klient dokonuje wyboru produktu między innymi na podstawie jego ceny.
[13] W powszechnym mniemaniu przyjmuje się, że dołożenie dodatkowych zasobów ludzkich do projektu zagrożonego opóźnieniem pozwoli na przyspieszanie prac, a to jest na zmniejszenie lub wyeliminowanie przedmiotowego ryzyka. Już w 1975 roku Frederic P. Brooks sformułował tezę zupełnie przeciwną (znaną w kręgach informatyków jako prawo Brooks'a, które zamieścił w pierwszym wydaniu „Mitycznego Osobomiesiąca”). Prawo Brooks'a negują wprost osoby związane z tworzeniem oprogramowania na zasadach Open Source, pokazując żywe dowody jego niepoprawności w odniesieniu do tego jak sami działają (por. Eric S. Raymond, „The Cathedral and the Baazar”). Projektom prowadzonym na rzecz administracji publicznej wciąż jednak bliżej do „Mitycznego osobomiesiąca” niż do „Bazaru”.
[14] W dalszej części artykułu będzie jeszcze trochę o wadach i zagrożeniach tego podejścia.
[15] Gdyby ktoś nie mógł się zgodzić z którąś z poniższych tez, albo
też znalazł by jeszcze jakieś inne za lub przeciw, uprzejmie proszę o
kontakt: <rganowski@metoda.com.pl>.
[16] Z produkcją oprogramowania związane są dwa cele. Cel podstawowy to dostarczenie systemu. Celem drugorzędnym jest przygotowanie się do następnej rozgrywki, a tj. do konieczności wprowadzania zmian (por. Alistair Cockburn; Agile Software Development; Addison Wesley; 2002)
[17] Geoffrey A. Moore; Crossing the Chasm – Marketing and Selling High-Tech Products to Mainstream Customers; Harper Business; 1999.
[18] Gdy homologacja stanie się bardzo popularną metodą nabywania oprogramowania, zapewne powstanie wiele prac naukowych oraz opracowań wielkich firm konsultingowych proponujących takie wzory. Ich przydatność zapewne będzie porównywalna z przydatnością jaką charakteryzują się dziś wszelkie konkurencyjne metody formalne pozwalające na szacowanie kosztów przedsięwzięć informatycznych.
[19] Różnice pomiędzy tymi podejściami nie mają znaczenia dla treści zawartych w niniejszym artykule.
[20] Podobno również przez Ministerstwo Spraw Wewnętrznych i Administracji, w odniesieniu do systemu ewidencji ludności. Tego, przyznaję, nie sprawdziłem. Sam fakt, że usłyszałem te informacje od osób, które mogę uznać za źródła wiarygodne jeszcze o niczym nie przesądza. Przyzwyczaiłem się już dawno do tego, że ludzie mówią o różnych rzeczach używając tych samy słów (jak również o tych samych rzeczach używając słów różnych — co akurat nie jest takie najgorsze). Jeśli będzie mi dane, chętnie zweryfikuję treść niniejszego artykułu na podstawie danych o MSWiA.