Temat: ESOD w praktyce

ESOD, czyli Elektroniczny System Obiegu Dokumentów, ma już za sobą pilotażowe wdrożenie. Przypomnijmy, od momentu złożenia wniosku przez obywatela, może on (obywatel oczywiście) śledzić postepy sprawy nie wychodzać z domu. Wszystko dzieje się za pośrednictwem Internetu. System działa. Kiedy waszym zdaniem ESOD będzie rzeczywistością w polskich urzędach. Jako punkt odniesienia proponuję ME 2012.

Temat: ESOD w praktyce

Witam,

Troszkę sprostowania:

Andrzej Janikowski:
ESOD, czyli Elektroniczny System Obiegu Dokumentów, ma już za sobą pilotażowe wdrożenie.

Po pierwsze Systemy EOD mają już dawno za sobą pilotaże i działają w polskich urzędach już od kilku lat.

Andrzej Janikowski:
Przypomnijmy, od momentu złożenia wniosku przez obywatela, może on (obywatel oczywiście) śledzić postepy sprawy nie wychodzać z domu. Wszystko dzieje się za pośrednictwem Internetu.

Po drugie monitorowanie stanu rozpatrywania danej sprawy to zupełnie inna bajka.

Sam SEOD służy jedynie do elektronicznego ewidencjonowania (wprowadzania), dekretacji, wysyłki i śledzenia pism. Ze względu na obecną ilość papierowej dokumentacji większość urzędów nie skanuje wszystkich pism do elektronicznego obiegu. Zazwyczaj obieg obejmuje całkowicie elektronicznie tylko wewnętrzne pisma np. 0725 (z JRWA), natomiast hybrydowo wszystkie pisma wpływające - czyli następuję wprowadzenie, a pismo skanowane jest jedynie w przypadku gdy jest dekretowane do większej ilości osób, oryginał papierowy podąża za dekretacją elektroniczną. Takie rozwiązanie całkiem dobrze sprawdza się obecnie w administracji zalanej przez papierowe pisma. Urząd zyskuje oszczędność papieru na kserokopiach ("Do wiadomości"), lepiej panuje nad przepływem pism, szybciej można znaleźć pisma źle zadekretowane, ustalony jest przepływ pism z Elektronicznej Skrzynki Podawczej (możliwie weryfikowanie podpisu elektronicznego na poszczególnych stanowiskach pracujących przy danej sprawie), za pomocą elektronicznych dzienników i list przesyłek usprawnione jest odbieranie i wysyłanie poczty przez kancelarię, przejrzystość wpływa na polepszenie procedur obiegu dokumentów (również papierowych) i przybliża urząd do rzeczywistego wdrażania procedur ISO.

Kolejnym etapem są Systemy Elektronicznego Zarządzania Dokumentacją, systemy te potrafią obsługiwać sprawy, prowadzić dokumentację sprawy, wersjonowanie dokumentów i formularzy, oraz co najważniejsze odpowiednią archiwizację elektroniczną dokumentacji. Niestety tak kompleksowych rozwiązań, w dodatku dobrze wypełniających przepisy prawne na których funkcjonują urzędy praktycznie nie ma. Z drugiej strony prowadzenie dokumentacji całkowicie elektronicznie wymaga (przynajmniej obecnie) sporej pracy związanej ze skanowaniem pism, a prowadzenie dwóch tych samych teczek jest zbyt pracochłonne ze względu na ręczne uzgadnianie numeracji pism (ponieważ domyślnie systemy numerują pisma automatycznie).

Andrzej Janikowski:
Kiedy waszym zdaniem ESOD będzie rzeczywistością w polskich urzędach. Jako punkt odniesienia proponuję ME 2012.

Po trzecie i chyba najważniejsze w tym temacie, nawet gdyby w urzędzie w pełni działał System Zarządzania Dokumentacją, to obecnie głównym problemem informowania klientów o stanie sprawy jest autoryzacja klienta. GIODO odrzucił możliwość autoryzacji za pomocą PESEL czy nr dowodu, a także konta na portalu urzędu, z powodu oczywistych możliwości nadużyć. Konto na portalu mogłoby być wykorzystywane, ale tylko w przypadku gdy jego weryfikacja odbywałaby się w sposób tradycyjny np. osobiste potwierdzenie założenia konta (wizyta w Urzędzie z dowodem), co w praktyce oznacza mało praktyczny sposób i małe zainteresowanie - widać to było w pierwszych podejściach do rozliczania się z Urzędem Skarbowym.

Myślę, że sensowne rozwiązanie mogą przynieść Rozporządzenia do nowelizacji ustawy o informatyzacji podmiotów realizujących zadania publiczne, a dokładnie określenie profilu zaufanego ePUAP, który to będzie idealnym rozwiązaniem do autoryzacji klienta.

Podsumowując, pierwsze sensowne rozwiązania pojawią się ok rok po wydaniu tych rozporządzeń.

Pozdrawiam,

Tomasz Perlik

Temat: ESOD w praktyce

Dzięki za odpowiedź. Sporo wniosła. Z pozdrowieniami - AJAN.

Temat: ESOD w praktyce

Andrzej Janikowski:

Nigdy. Dlaczego? Ponieważ nie istnieją żadne profesjonalne wymagania na tego typu system.
Każda gmina przygotowuje własne SIWZ-y na systemy workflow (ESOD, eObieg, czy jak je inaczej nazwiemy). W każdej istnieją inne obiegi, w innych systemach, od innych dostawców z niekompatybilnymi API itd. Cały bałagan polskiej administracji przenoszony jest w formę elektroniczną. Czekają nas te same frustracje z innym interfejsem.

EDIT: Jakość tych SIWZ-ów pozwolę sobie przemilczeć, bo wiele razy już zabierałem głos na temat tego jak należy modelować wymagania.Mateusz Kurleto edytował(a) ten post dnia 14.12.10 o godzinie 01:19

Temat: ESOD w praktyce

Witam,

Porusza Pan dwie odrębne kwestie,

Andrzej Janikowski:

Nigdy. Dlaczego? Ponieważ nie istnieją żadne profesjonalne wymagania na tego typu system.

Wymagania istnieją, są to Ustawy i Rozporządzenia, jednak to o czym Pan pisze to zupełnie inny temat, chodzi o standaryzację pracy Urzędów,

Obecnie nie ma standaryzacji postępowania i procedur, nawet w Urzędach, które zajmują się ta sama działką, a co dopiero mówić o całej Administracji,

Każdy z Urzędów ma własny Regulamin Organizacyjny oraz wypracowuje własne podręczniki procedur,

Już na kilku konferencjach i na różnych szczeblach poruszałem ten temat, ponieważ uważam, że jest to temat kluczowy jeżeli chcemy myśleć o standardach przy budowie SEOD co jest konieczne jeżeli myślimy np. o chmurze dla polskiej administracji,

Z tego co jednak widziałem, to temat ten przerażał moich rozmówców,

Wiem, że nie jest to rzecz prosta ustandaryzować mechanizmy i procedury postępowania, proces pewnie potrwał by parę lat, ale jest to do zrobienia, warto go rozpocząć już teraz, np. od zbierania "najlepszych praktyk" na poszczególnych szczeblach administracji i tworzenia najpierw tam pewnych standardów,

Andrzej Janikowski:

W każdej istnieją inne obiegi, w innych systemach, od innych dostawców z niekompatybilnymi API itd.

Tutaj poruszona jest jeszcze inna kwestia - interoperacyjności rozwiązań,

Na dokładną definicję musimy jeszcze poczekać, ponieważ jeszcze nie wyszły wszystkie Rozporządzenia do nowelizacji Ustawy o informatyzacji działalności podmiotów realizujących działania publiczne,

Podejrzewam, ze tam znajdzie się definicja API, na razie jest nią standard XML, czyli jeżeli SEOD ma komunikować się np. z BIP, to SEOD eksportuje XML o określonej strukturze (w specyfikacji warto dodać zapis, aby struktura była szczegółowo opisana), a BIP musi mieć funkcję importu tego XML,

Powyższy sposób standaryzuje tylko w podstawowym stopniu wymianę danych, ponieważ tak jak Pan Andrzej zauważył struktury XML nie są ustandaryzowane,

Pozdrawiam,

Temat: ESOD w praktyce

Tomasz P.:
Witam,

Porusza Pan dwie odrębne kwestie,

Andrzej Janikowski:

Nigdy. Dlaczego? Ponieważ nie istnieją żadne profesjonalne wymagania na tego typu system.

Wymagania istnieją, są to Ustawy i Rozporządzenia, jednak to o czym Pan pisze to zupełnie inny temat, chodzi o standaryzację pracy Urzędów,

Panie Tomku rozporządzenia, dokumentacja procedur itp. to jedynie źródło wymagań na oprogramowanie.
Dobrze przygotowany SWS (Specyfikacja Wymagań Systemu) obejmuje zwykle między innymi:
1) model organizacji - najlepiej zbiór BPMN-owych modeli kluczowych procesów + misja + cele strategiczne + metoda pomiaru ich realizacji
2) wymagania funkcjonalne - najlepiej UML-owy diagram przypadków użycia wraz z ich opisem (scenariusze, alternatywne przebiegi, warunki rozpoczęcia, zakończenia) oraz daigramami sekwencji
3) model danych - najlepiej UML-owy diagram klas dla warstwy danych
4) wymagania pozafunkcjonalne - mierzalne, konkretne wymagania (np. maksymalny czas reakcji systemu na prostą czynność <3s przy jednoczesnej pracy 1000 użytkowników)
5) model uprawnień
6) projekt testów akceptacyjnych - scenariusze testowe dla każdego przypadku użycia + scenariusz testów pozafunkcjonalnych

> > W każdej istnieją inne obiegi, w innych systemach, od

innych dostawców z niekompatybilnymi API itd.

Tutaj poruszona jest jeszcze inna kwestia - interoperacyjności rozwiązań,

Jeżeli systemy tworzone są bez wymagania możliwości automatycznej, elektronicznej wymiany danych z innymi urzędami - to są złe. Winno być tak, że jeżeli jakikolwiek urząd posiada potrzebne innemu informacje, a oba mają prawo dostępu do niego to same wymieniają się informacjami.
Zmiana ustaw, czy innych regulacji, które sprawią że urzędy będą miały obowiązek tak robić zaowocuje kolejnymi przetargami na zmiany oprogramowania, bo dzisiaj nikt nie zapisał tego w wymaganiach.Mateusz Kurleto edytował(a) ten post dnia 14.12.10 o godzinie 12:08

Temat: ESOD w praktyce

Mateusz Kurleto:
Dobrze przygotowany SWS (Specyfikacja Wymagań Systemu) obejmuje zwykle między innymi:
1) model organizacji - najlepiej zbiór BPMN-owych modeli kluczowych procesów + misja + cele strategiczne + metoda pomiaru ich realizacji

Myślę że to przesada, aby wymagać od Urzędów Gminy, aby tworzyli pełną dokumentację projektową oprogramowania. Nawet gdyby Urząd zatrudnił najpierw firmę do opracowania SWS, to nie byłby w stanie zweryfikować czy dokument rzeczywiście opisuje procesy w Urzędzie. Ponieważ dopiero na etapie realizacji poszczególne komórki wychwytywałyby nieprawidłowości. Daltego w przetargach przerzuca się to na dostawcę oprogramowania.

Powyższy proces jest sensowny tylko w dużych projektach centralnych, w których możliwe jest zrealizowanie i sprawdzenie odpowiedniej dokumentacji. Przy takich projektach, które nie mają budżetów rocznych tylko wieloletnie, możliwe jest realizowanie na spokojnie trybów Zamówienia Publicznego np. "negocjacje z ogłoszeniem", gdzie na podstawie opracowanej dokumentacji powstałby naprawdę dobry SIWZ.

Na szczeblu gminnym, czy nawet wojewódzkim, dopiero wprowadza się procesowe podejście do działania instytucji, które zaowocuje łatwiejszym projektowaniem aplikacji przez wykonawców.

Jeżeli systemy tworzone są bez wymagania możliwości automatycznej, elektronicznej wymiany danych z innymi urzędami - to są złe. Winno być tak, że jeżeli jakikolwiek urząd posiada potrzebne innemu informacje, a oba mają prawo dostępu do niego to same wymieniają się informacjami.

Łatwo powiedzieć lecz trudno zrobić ;) Takie słowa słyszę już od wielu lat, problemy są natury formalnej (uregulowania dostępu tylko do wybranych danych, ochrona danych osobowych itp.) i technicznej (zdefiniowanie jednego wspólnego API, bez ograniczania konkurencji, obejmującego wszystkie potrzebne dane jest obecnie praktycznie niemożliwe).

Zmiana ustaw, czy innych regulacji, które sprawią że urzędy będą miały obowiązek tak robić zaowocuje kolejnymi przetargami na zmiany oprogramowania, bo dzisiaj nikt nie zapisał tego w wymaganiach.

Już takie regulacje weszły w życie, przytoczona nowelizacja ustawy o informatyzacji podmiotów realizujących zadania publiczne, nakłada obowiązek aby Urząd sam pozyskiwał dane z rejestrów publicznych. W przyszłości pewnie ten zakres się rozszerzy o inne rejestry.

Temat: ESOD w praktyce

Tomasz P.:
Myślę że to przesada, aby wymagać od Urzędów Gminy, aby tworzyli pełną dokumentację projektową oprogramowania. Nawet gdyby Urząd zatrudnił najpierw firmę do opracowania SWS, to nie byłby w stanie zweryfikować czy dokument rzeczywiście opisuje procesy w Urzędzie. Ponieważ dopiero na etapie realizacji poszczególne komórki wychwytywałyby nieprawidłowości. Daltego w przetargach przerzuca się to na dostawcę oprogramowania.

Nie ma możliwości napisania dobrego oprogramowania bez takiej dokumentacji przy klasycznym cyklu wytwarzania. Metodyki agile natomiast nie wydają się łatwe do zastosowania w projektach dla administracji publicznej.
Brak takiej dokumentacji prowadzi do ogromnej ilości błędów i bubli, które owocują przekroczonymi terminami, budżetami i źle działającym oprogramowaniem.
Warto też zauważyć, że koszty takiej analizy to zwykle 5-10% budżetu na wdrożenie, zatem przy projektach o wartości nawet 280 tyś EUR na samo opracowanie wymagań nie trzeba by było ogłaszać przetargu, a umowy z dostawcą usług projektowych śmiało mogą obejmować nadzór nad wdrożeniem. To coraz popularniejszy model współpracy w biznesie - który cenią uczciwi i zorientowani na sukces projektu zamawiający i dostawcy. Jeśli dobry, jednoznaczny projekt wymagań dla dostawcy oprogramowania przeszkodą - to znak, że próbuje nas oszukać.

Powyższy proces jest sensowny tylko w dużych projektach centralnych, w których możliwe jest zrealizowanie i sprawdzenie odpowiedniej dokumentacji. Przy takich projektach, które nie mają budżetów rocznych tylko wieloletnie, możliwe jest realizowanie na spokojnie trybów Zamówienia Publicznego np. "negocjacje z ogłoszeniem", gdzie na podstawie opracowanej dokumentacji powstałby naprawdę dobry SIWZ.

Nie prawda. Taka analiza na potrzeby wdrożenia np. ESOD w Urzędzie Gminy nie powinna trwać więcej niż 2 miesiące, a koszty raz że często nie wymagają przetargi a dwa - zwracają się wielokrotnie.
Jeżeli koszt analizy prowadzącej do wyeliminowania błędu wymagań wynosi x to koszt jego eliminacji na etapie projektowania i implementacji wynosi 10-100x, a po wdrożeniu (na etapie maintenance) 100-1000x.

Na szczeblu gminnym, czy nawet wojewódzkim, dopiero wprowadza się procesowe podejście do działania instytucji, które zaowocuje łatwiejszym projektowaniem aplikacji przez wykonawców.

Skoro aplikacje IT są z natury procesowe to po co je wdrażać przed wdrożeniem podejścia procesowego do działalności?

Jeżeli systemy tworzone są bez wymagania możliwości automatycznej, elektronicznej wymiany danych z innymi urzędami - to są złe. Winno być tak, że jeżeli jakikolwiek urząd posiada potrzebne innemu informacje, a oba mają prawo dostępu do niego to same wymieniają się informacjami.

Łatwo powiedzieć lecz trudno zrobić ;) Takie słowa słyszę już od wielu lat, problemy są natury formalnej (uregulowania dostępu tylko do wybranych danych, ochrona danych osobowych itp.) i technicznej (zdefiniowanie jednego wspólnego API, bez ograniczania konkurencji, obejmującego wszystkie potrzebne dane jest obecnie praktycznie niemożliwe).

I chce mi Pan powiedzieć, że przez 20 lat współczesnego prawodawstwa w Polsce nie było dość czasu, żeby się tym zająć? Na tym etapie mogę wymagać i nie przyjmować żadnych wymówek. Gdyby cała ludzkość miała takie podejście jak większość (bo znam chlubne wyjątki) naszej administracji to dalej bylibyśmy na etapie hubki i krzesiwa.

Zmiana ustaw, czy innych regulacji, które sprawią że urzędy będą miały obowiązek tak robić zaowocuje kolejnymi przetargami na zmiany oprogramowania, bo dzisiaj nikt nie zapisał tego w wymaganiach.

Już takie regulacje weszły w życie, przytoczona nowelizacja ustawy o informatyzacji podmiotów realizujących zadania publiczne, nakłada obowiązek aby Urząd sam pozyskiwał dane z rejestrów publicznych. W przyszłości pewnie ten zakres się rozszerzy o inne rejestry.

Wow. A do Sttraży Miejskiej dalej trzeba co rok przynosić oryginał ważnego odpisu z księgi wieczystej, żeby dostać wjazdówkę na stare miasto. Mimo, że jest się właścicielem lokalu od 10 lat i co roku kserują sobie ten odpis.

Temat: ESOD w praktyce

Mateusz Kurleto:
Brak takiej dokumentacji prowadzi do ogromnej ilości błędów i bubli, które owocują przekroczonymi terminami, budżetami i źle działającym oprogramowaniem.

W pełni się z tym zgadzam, ale po pierwsze dokumentacja taka nie gwarantuje ominięcia błędów a jedynie je minimalizuje, niestety często tylko nieznacznie, po drugie z ograniczeniami występującymi w administracji poprawne poprowadzenie inwestycji nie jest proste...

Nie prawda. Taka analiza na potrzeby wdrożenia np. ESOD w Urzędzie Gminy nie powinna trwać więcej niż 2 miesiące, a koszty raz że często nie wymagają przetargi a dwa - zwracają się wielokrotnie.

Osobiście myślę, że analiza może potrwać znacznie dłużej, a jej waga może być różna w zależności od jednostki, jako przykład podam analizę działania Powiatowych Urzędów Pracy, Ministerstwo Pracy i Polityki Społecznej zleciło analizę, która trwałą prawie 2 lata, na jej podstawie firma Sygnity stworzyła system Syriusz STD, wersja opracowana z analizy została zmodyfikowana na etapach roboczym, pilotażu i pierwszych wdrożeniach w ponad 40%, oznacza to że analiza miała skuteczność mniejszą niż 60%,

Kolejnym problemem są terminy: budżet jednostki uchwalany jest w marcu, od razu podpisywana jest umowa na analizę, powiedzmy że analiza trwa 2 miesiące, na początku czerwca mamy wyniki, na jej podstawie jednostka opracowuje przetarg (dwa tygodnie), który bez odwołań trwa miesiąc, na wykonanie i wdrożenie systemu zostaje 4,5 miesiąca, co w wielu przypadkach jest stanowczo za mało,

Skoro aplikacje IT są z natury procesowe to po co je wdrażać przed wdrożeniem podejścia procesowego do działalności?

Chodzi właśnie o to, że Urzędy nie są ani procesowe, ani nawet proceduralne, dlatego właśnie analizy są takie długie,

I chce mi Pan powiedzieć, że przez 20 lat współczesnego prawodawstwa w Polsce nie było dość czasu, żeby się tym zająć? Na tym etapie mogę wymagać i nie przyjmować żadnych wymówek.

Proszę sobie nie żartować, 20 lat temu to Tim Berners-Lee dopiero wymyślał WWW ;) informatyka rozwija się w zawrotnym tempie, prawodawstwo po prostu za nim nie nadąża i to nie tylko u nas, niektóre dyrektywy unijne regulujące wymianę elektroniczną pisane były przed upowszechnieniem się e-maila,

Wow. A do Sttraży Miejskiej dalej trzeba co rok przynosić oryginał ważnego odpisu z księgi wieczystej, żeby dostać wjazdówkę na stare miasto. Mimo, że jest się właścicielem lokalu od 10 lat i co roku kserują sobie ten odpis.

No cóż mogę powiedzieć, współczuję. Przed wydaniem wspomnianych przeze mnie wcześniej rozporządzeń precyzujących wiele kwestii wymiany danych między instytucjami, ciężko mi komentować. Mam tylko nadzieję, że rozporządzenia te wprowadzą sensowne rozwiązania, które będzie można szybko wdrożyć lub zaadoptować do istniejących systemów.

Temat: ESOD w praktyce

Tomasz P.:
W pełni się z tym zgadzam, ale po pierwsze dokumentacja taka nie gwarantuje ominięcia błędów a jedynie je minimalizuje, niestety często tylko nieznacznie, po drugie z ograniczeniami występującymi w administracji poprawne poprowadzenie inwestycji nie jest proste...

Zależy od jakości analizy. W kwestii ryzyka sprawa jest prosta - to jak gra w pokera. Jeżeli koszt analizy jest większy niż iloczyn prawdopodobieństwa wystąpienia błędu i kosztu błędu to nie opłaca się analizować, jeśli jest odwrotnie to się opłaca i należy. Warto tylko zaznaczyć, że należy tutaj brać pod uwagę całość kosztu a nie tylko fragment - czyli ocenić skutki.

Nie prawda. Taka analiza na potrzeby wdrożenia np. ESOD w Urzędzie Gminy nie powinna trwać więcej niż 2 miesiące, a koszty raz że często nie wymagają przetargi a dwa - zwracają się wielokrotnie.

Osobiście myślę, że analiza może potrwać znacznie dłużej, a jej waga może być różna w zależności od jednostki, jako przykład podam analizę działania Powiatowych Urzędów Pracy, Ministerstwo Pracy i Polityki Społecznej zleciło analizę, która trwałą prawie 2 lata, na jej podstawie firma Sygnity stworzyła system Syriusz STD, wersja opracowana z analizy została zmodyfikowana na etapach roboczym, pilotażu i pierwszych wdrożeniach w ponad 40%, oznacza to że analiza miała skuteczność mniejszą niż 60%,

To tylko dowód, że skopano analizę lub skopano zarządzanie projektem. A najprawdopodobniej jedno i drugie. Generalnie istnieje wśród dużych podmiotów moda na robienie zbyt dużych projektów, bo wszyscy gremialnie olewają analizę ryzyka a ono rośnie wykładniczo względem skomplikowania projektu.

Kolejnym problemem są terminy: budżet jednostki uchwalany jest w marcu, od razu podpisywana jest umowa na analizę, powiedzmy że analiza trwa 2 miesiące, na początku czerwca mamy wyniki, na jej podstawie jednostka opracowuje przetarg (dwa tygodnie), który bez odwołań trwa miesiąc, na wykonanie i wdrożenie systemu zostaje 4,5 miesiąca, co w wielu przypadkach jest stanowczo za mało,

Te same problemy mają firmy. Rozwiązanie jest proste. Analizy przeprowadza się tak, żeby kończyły się przed projektowaniem budżetu na kolejny rok. Zwykle wypada na 3 kwartał.

Skoro aplikacje IT są z natury procesowe to po co je wdrażać przed wdrożeniem podejścia procesowego do działalności?

Chodzi właśnie o to, że Urzędy nie są ani procesowe, ani nawet proceduralne, dlatego właśnie analizy są takie długie,

W takim razie nie należy robić analizy a projektować organizację urzędu a potem pisać wymagania na oprogramowanie, które pomoże w działaniu zgodnie z nową organizacją. Inaczej marnujemy budżety.

I chce mi Pan powiedzieć, że przez 20 lat współczesnego prawodawstwa w Polsce nie było dość czasu, żeby się tym zająć? Na tym etapie mogę wymagać i nie przyjmować żadnych wymówek.

Proszę sobie nie żartować, 20 lat temu to Tim Berners-Lee dopiero wymyślał WWW ;) informatyka rozwija się w zawrotnym tempie, prawodawstwo po prostu za nim nie nadąża i to nie tylko u nas, niektóre dyrektywy unijne regulujące wymianę elektroniczną pisane były przed upowszechnieniem się e-maila,

Szanowny Panie, proszę nie żartować! Modelowanie procesów biznesowych to początek XXw. Gantt chart 1900' Flow chart 1920' PERT diagram & functional flow charts 1950' - myślę że te 210-160 lat to dość żeby o funkcjonowaniu organizacji myśleć w kategorii procesów i te procesy zacząć dokumentować.

Wow. A do Sttraży Miejskiej dalej trzeba co rok przynosić oryginał ważnego odpisu z księgi wieczystej, żeby dostać wjazdówkę na stare miasto. Mimo, że jest się właścicielem lokalu od 10 lat i co roku kserują sobie ten odpis.

No cóż mogę powiedzieć, współczuję. Przed wydaniem wspomnianych przeze mnie wcześniej rozporządzeń precyzujących wiele kwestii wymiany danych między instytucjami, ciężko mi komentować. Mam tylko nadzieję, że rozporządzenia te wprowadzą sensowne rozwiązania, które będzie można szybko wdrożyć lub zaadoptować do istniejących systemów.

Im dalej w las tym więcej drzew. Mimo, że interesuję się poruszanymi zagadnieniami znacznie bardziej niż przeciętny Kowalski moja perspektywa to wierzchołek góry lodowej. A niestety każdy ukazujący się milimetr napawa większym przerażeniem.

Temat: ESOD w praktyce

Mateusz Kurleto:

Tomasz P.:
Kolejnym problemem są terminy: budżet jednostki uchwalany jest w marcu, od razu podpisywana jest umowa na analizę, powiedzmy że analiza trwa 2 miesiące, na początku czerwca mamy wyniki, na jej podstawie jednostka opracowuje przetarg (dwa tygodnie), który bez odwołań trwa miesiąc, na wykonanie i wdrożenie systemu zostaje 4,5 miesiąca, co w wielu przypadkach jest stanowczo za mało,

Te same problemy mają firmy. Rozwiązanie jest proste. Analizy przeprowadza się tak, żeby kończyły się przed projektowaniem budżetu na kolejny rok. Zwykle wypada na 3 kwartał.

No właśnie nie da się tak zrobić, ponieważ żadna księgowa nie podpisze umowy przed zatwierdzeniem budżetu, czyli przed informacją że ma środki na jej pokrycie (naraża się wtedy na dyscyplinę), również nie można zrobić manewru w którym zamówimy analizę jednego roku a zostanie ona zrealizowana drugiego ponieważ ponieważ środki są angażowane w jednym roku a wydawane w drugim, tutaj również księgowa może wylądować na dyscyplinie, wyjątkiem są tylko umowy długoterminowe płacone okresowo (np. miesięcznie lub kwartalnie) na konieczne media (np. prąd, czynsz itp.),

W takim razie nie należy robić analizy a projektować organizację urzędu a potem pisać wymagania na oprogramowanie, które pomoże w działaniu zgodnie z nową organizacją. Inaczej marnujemy budżety.

No właśnie od początku o to mi chodziło, uważam że już nawet przed samym pomysłem na wdrożenie SEOD, należy najpierw zastanowić się nad funkcjonowaniem instytucji. Obecnie problemem Urzędów jest bowiem stosowanie "pseudo procesów", czyli wiadomo jakie wydziały zaangażowane są w wydawanie decyzji czy prowadzenie sprawy, a nie ma sprecyzowanego przepływu danych i workflow jest "uznaniowy",

I chce mi Pan powiedzieć, że przez 20 lat współczesnego prawodawstwa w Polsce nie było dość czasu, żeby się tym zająć? Na tym etapie mogę wymagać i nie przyjmować żadnych wymówek.

Proszę sobie nie żartować, 20 lat temu to Tim Berners-Lee dopiero wymyślał WWW ;) informatyka rozwija się w zawrotnym tempie, prawodawstwo po prostu za nim nie nadąża i to nie tylko u nas, niektóre dyrektywy unijne regulujące wymianę elektroniczną pisane były przed upowszechnieniem się e-maila,

Szanowny Panie, proszę nie żartować! Modelowanie procesów biznesowych to początek XXw. Gantt chart 1900' Flow chart 1920' PERT diagram & functional flow charts 1950' - myślę że te 210-160 lat to dość żeby o funkcjonowaniu organizacji myśleć w kategorii procesów i te procesy zacząć dokumentować.

Nie żartuje :) Pisze Pan o tym, że ustawodawcy mieli 20 lat żeby zająć się przepisami, a 20 lat temu wymiana informacji w informatyce raczkowała, więc nie ma co oczekiwać, że był czas na przygotowywanie odpowiednich przepisów to regulujących, ogólnie to czasu w prawodawstwie nie ma jeżeli chodzi o nowe technologie, proces legislacyjny trwa długo, a technologie zmieniają się bardzo szybko,

Jeżeli chodzi natomiast o modelowanie procesów biznesowych, wykresy Gantta czy przepływy, są to narzędzia przygotowane dla biznesu, dopiero od niedawna zaczyna się myśleć o administracji jako "firmie" dostarczającej usługi, która musi być wydajna i pracować optymalnie, mimo tego ciągle podstawowym zadaniem Urzędów jest realizowanie prawa ustanowionego przez ustawodawcę, firmy mają więcej luzu ponieważ wystarczy że będą działać w granicach tego prawa,

W Urzędach procesy, wydajność i optymalizacja muszą wynikać z ustaw które regulują ich działania, dlatego tak uczepiłem się we wcześniejszych wypowiedziach tych przepisów,

Powoli zmienia się na lepsze, Urzędy już teraz muszą zacząć zarządzać ryzykiem i prowadzić kontrolę zarządczą, co pewnie wymusi opis procesowy ich działalności,

Im dalej w las tym więcej drzew. Mimo, że interesuję się poruszanymi zagadnieniami znacznie bardziej niż przeciętny Kowalski moja perspektywa to wierzchołek góry lodowej. A niestety każdy ukazujący się milimetr napawa większym przerażeniem.

No niestety tak właśnie jest, rozwiązania informatyczne opierające się o przepisy prawa są naprawdę wyzwaniem, nie tylko w Polsce, kiedyś byłem bardzo krytyczny w stosunku do działań administracji, do czasu aż rozpocząłem poznawać ten mechanizm... teraz mnie już to nie dziwi, czasem irytuje, a ciągle czuję niedosyt... ;)

Temat: ESOD w praktyce

Tomasz P.:
No właśnie nie da się tak zrobić, ponieważ żadna księgowa nie podpisze umowy przed zatwierdzeniem budżetu, czyli przed informacją że ma środki na jej pokrycie (naraża się wtedy na dyscyplinę), również nie można zrobić manewru w którym zamówimy analizę jednego roku a zostanie ona zrealizowana drugiego ponieważ ponieważ środki są angażowane w jednym roku a wydawane w drugim, tutaj również księgowa może wylądować na dyscyplinie, wyjątkiem są tylko umowy długoterminowe płacone okresowo (np. miesięcznie lub kwartalnie) na konieczne media (np. prąd, czynsz itp.),

Albo się nie rozumiemy, albo jest jeszcze gorzej niż wiem. Rozwiązanie o którym pisałem wygląda następująco. Planujemy wdrożenie ESOD. W związku z czym w planie budżetowym na 2011 rok planujemy środki na projekt "Modelowanie i optymalizacja procesów biznesowych gminy XXX oraz modelowanie wymagań na oprogramowanie wspierające ich realizację i monitoring". W 2011 roku realizujemy projekt, efektem którego mamy opisane przeze mnie artefakty. Projekt kończy się w 3Q.2011 więc w budżecie na 2012 rok planujemy środki na projekt "Wdrożenie systemu wspierającego realizację procesów biznesowych gminy XXX". Wszystko działa jak należy. Jeśli projekt wdrożenia jest za duży na jeden rok to należy go podzielić na etapy.

W takim razie nie należy robić analizy a projektować organizację urzędu a potem pisać wymagania na oprogramowanie, które pomoże w działaniu zgodnie z nową organizacją. Inaczej marnujemy budżety.

No właśnie od początku o to mi chodziło, uważam że już nawet przed samym pomysłem na wdrożenie SEOD, należy najpierw zastanowić się nad funkcjonowaniem instytucji. Obecnie problemem Urzędów jest bowiem stosowanie "pseudo procesów", czyli wiadomo jakie wydziały zaangażowane są w wydawanie decyzji czy prowadzenie sprawy, a nie ma sprecyzowanego przepływu danych i workflow jest "uznaniowy",

Czyli się tu zgadzamy.

Nie żartuje :) Pisze Pan o tym, że ustawodawcy mieli 20 lat żeby zająć się przepisami, a 20 lat temu wymiana informacji w informatyce raczkowała, więc nie ma co oczekiwać, że był czas na przygotowywanie odpowiednich przepisów to regulujących, ogólnie to czasu w prawodawstwie nie ma jeżeli chodzi o nowe technologie, proces legislacyjny trwa długo, a technologie zmieniają się bardzo szybko,

Ale co mają technologię do organizacji procesowej? Technologie pozwalają na wspieranie realizacji procesów i ich częściową automatyzację. Można mieć w pełni procesowo pracujący urząd bez jednego komputera.

Jeżeli chodzi natomiast o modelowanie procesów biznesowych, wykresy Gantta czy przepływy, są to narzędzia przygotowane dla biznesu, dopiero od niedawna zaczyna się myśleć o administracji jako "firmie" dostarczającej usługi, która musi być wydajna i pracować optymalnie, mimo tego ciągle podstawowym zadaniem Urzędów jest realizowanie prawa ustanowionego przez ustawodawcę, firmy mają więcej luzu ponieważ wystarczy że będą działać w granicach tego prawa,

A urzędom nie wystarczy działać w granicach prawa? Wystarczy. To, że dopiero teraz zaczyna się myśleć o tym do czego są Urzędy to chyba nie wynik ustaw sprzed e-maila, prawda?

W Urzędach procesy, wydajność i optymalizacja muszą wynikać z ustaw które regulują ich działania, dlatego tak uczepiłem się we wcześniejszych wypowiedziach tych przepisów,

Ale te ustawy istnieją od lat. Wiadomo chyba co dzieje się z moim wnioskiem o wydanie dowodu prawda? Wystarczy to udokumentować. Optymalizacja nie musi być wykonywana na poziomie ustawy - to kompletna bzdura. Optymalizacja proecesów biznesowych polega na znajdowaniu odpowiedzi na pytania "czy koszt księgowania pojedynczego dokumentu może być niższy?", "w jaki sposób wydawać 200 dowodów dziennie zamiast 150? czy potrzeba dodatkowego okienka, czy może Panie w okienkach bez sensu zajmują się np udzielaniem informacji telefonicznej, może lepiej informacje telefoniczną zorganizować niezależnie i wydajność się podniesie?"

Powoli zmienia się na lepsze, Urzędy już teraz muszą zacząć zarządzać ryzykiem i prowadzić kontrolę zarządczą, co pewnie wymusi opis procesowy ich działalności,

Znam jeden bardzo chlubny przykład urzędu, który już wykonał formalne (BPMN) modele swoich procesów w obszarze m.in. księgowości i jest na etapie ich symulowania i później optymalizacji.

Im dalej w las tym więcej drzew. Mimo, że interesuję się poruszanymi zagadnieniami znacznie bardziej niż przeciętny Kowalski moja perspektywa to wierzchołek góry lodowej. A niestety każdy ukazujący się milimetr napawa większym przerażeniem.

No niestety tak właśnie jest, rozwiązania informatyczne opierające się o przepisy prawa są naprawdę wyzwaniem, nie tylko w Polsce, kiedyś byłem bardzo krytyczny w stosunku do działań administracji, do czasu aż rozpocząłem poznawać ten mechanizm... teraz mnie już to nie dziwi, czasem irytuje, a ciągle czuję niedosyt... ;)

Nie w konieczności zachowania przepisów szukałbym problemu. W końcu księgowość regulują przepisy i każda firma korzysta z oprogramowania księgowego bezpośrednio lub pośrednio i wcale nie przeszkadza to w rozwoju.