Zwrot koncepcyjny w sprawie Centralnej Informacji o Działalności Gospodarczej i system InDyGo

Niedawno relacjonowałem doniesienia prasy na temat koncepcji "jednego okienka" (por. Jedno okienko będzie jednak zamknięte). Wedle aktualnego stanu prawnego - od 1 stycznia 2007 roku mają wejść w życie niektóre przepisy ustawy o swobodzie działalności gospodarczej, a konkretnie te, które stanowią ramy prawne dla utworzenia i działania Centralnej Informacja o Działalności Gospodarczej. Podnoosi się jednak, że gminy nie są przygotowane, że nie ma pieniędzy na realizację ustawy, etc. Stąd konieczność zweryfikowania nieco stanu prawa. Wedle nowej koncepcji – zamiast w gminach – „jedno okienko” realizowane będzie za pomocą urzędów skarbowych. Poniżej kilka słów na temat aktualnych koncepcji z prośbą o dopisywanie w komentarzach własnych uwag (również od webmasterów), dotyczących zagrożeń dla systemu.

Najpierw trochę historii. Na stronach Ministerstwa Gospodarki nadal można przeczytać w komunikacie z lipca 2005 roku: "Powstaje nowy informatyczny system InDyGo. Umożliwi on między innymi utworzenie Centralnej Informacji o Działalności Gospodarczej (CIoDG), a także przygotowanie i nieodpłatne przekazanie Urzędom Gmin oprogramowania kompleksowo obsługującego proces ewidencjonowania działalności gospodarczej oraz przesyłania wymaganych informacji pomiędzy poszczególnymi urzędami oraz CIoDG. Projekt został zatwierdzony przez Ministra Gospodarki i Pracy do wsparcia funduszami unijnymi w ramach SPO WKP działanie 1.5.". Wcześniejsza wersja założeń systemu InDyGo, tj. wersja opublikowana 27 lipca 2005, dostępna jest w Sieci, w formacie PDF.

O tych założeniach można było przeczytać w zeszłym roku, w serwisie 7thGuard (w kontekście obaw środowiska RWO, że może powstać kolejny "Płatnik"):

Trudno się z tymi propozycjami [chodzi o propozycje rządowe - dopisek mój, PVW] nie zgodzić, zwłaszcza że są one rozwinięciem założeń, na których został oparty wcześniej zrealizowany nadzorowany przez ten sam kierowany przez dyrektora Zbigniewa Olejniczaka departament system rozliczenia pomocy społecznej: gminy mają do wyboru skorzystać z centralnie opracowanego modułu obsługi konkretnej aplikacji (a więc wykonać nałożony na nie przez Państwo wymóg bez ponoszenia dodatkowych kosztów) lub z odpowiedniego modułu oprogramowania używanego do kompleksowej obsługi gminy. Moduł taki musi być zgodny z opublikowanych standardem wymiany danych, przy czym zgodność musi być potwierdzona odpowiednim certyfikatem. Głównym elementem procesu certyfikacji jest wynik praktycznej próby przetworzenia testowych danych, wśród których są przykłady typowych błędów i trudnych do interpretacji sytuacji. Praktyka pokazała, że wymóg uzyskania certyfikatu nie jest poważną barierą utrudniającą autorom oprogramowania wdrożenie ich rozwiązań, a nawet wręcz przeciwnie: znacząco ułatwia im testowanie go. Równocześnie prawie dwuletnie doświadczenie pokazuje, że dane dostarczone przez gminy używające własnego, certyfikowanego oprogramowania nie zawierają więcej błędów lub nieścisłości niż centralnie rozprowadzana aplikacja.

Zaistniała potrzeba zmodyfikowania koncepcji. Zrezygnowano z ewidencjonowania osób fizycznych w gminach. Wedle nowych założeń (por. poniżej) od 1 października 2008 r. osoby fizyczne zamierzające wykonywać działalność gospodarczą będą musiały uzyskać wpis do ewidencji działalności gospodarczej prowadzonej przez naczelnika właściwego urzędu skarbowego, a nie tak jak teraz - wpis do ewidencji działalności gospodarczej prowadzonej przez gminę. Gminy zatem będą "uwolnione" z jarzma projektowanego systemu. Zasady wpisu określone będą w zmienianej ustawie o zasadach ewidencji i identyfikacji podatników i płatników. "Jedno okienko" to zatem już nie gminna ewidencja działalności gospodarczej, a okienko w urzędzie skarbowym.

Wedle aktualnej (zmodyfikowanej w stosunku do wcześniej opublikowanej) Koncepcji Systemu InDyGo (sierpień 2006), opracowanej przez Centrum Informacji Społeczno-Gospodarczej Ministerstwa Gospodarki, Zespół autorski pod kierownictwem: dr inż. Zygmunta Bieńko:

System InDyGo będzie pełnił rolę centralnej informacji o wpisach do ewidencji działalności gospodarczej. Informacja ta będzie dostępna przez internetowe wyszukiwarki, co umożliwi zainteresowanym przeglądanie publicznie dostępnych informacji na temat aktualnie zarejestrowanych przedsiębiorców. Umożliwi to zatem wypełnienie zapisów ustawy o jawności informacji zawartych we wpisie.

W ramach projektu stworzony zostanie system informatyczny pn. InDyGo oraz oprogramowanie interfejsowe umożliwiające wymianę informacji (w zakresie objętym CIDG) z autonomicznie działającymi urzędowymi ewidencjami gromadzącymi dane źródłowe, które będą stanowić źródło dla zasilania danymi bazy danych Centralnej Informacji. W szczególności chodzi tu o ewidencje podatników prowadzoną przez urzędy skarbowe i Ministerstwo Finansów, w ramach systemu KEP (obecna Krajowa Ewidencja Podatników w końcu 2008 roku zostanie zastąpiona przez wewnętrznie zintegrowany Centralny Rejestr Podmiotów), dane z sądów, dane z organów koncesyjnych, urzędowych rejestrów działalności regulowanej oraz organów właściwych do spraw zezwoleń i licencji.

Do przesyłania danych przewiduje się wykorzystać otwarty protokół komunikacyjny z zapewnieniem niezbędnej ochrony bezpieczeństwa i monitorowania transferowanych danych. Umożliwi to użycie różnorodnych rozwiązań na poziomie indywidualnych systemów, przy jednoczesnym spełnieniu wymogów istnienia centralnej bazy wpisów do ewidencji działalności gospodarczej.

Koncepcja zakłada, że rejestracja przedsiębiorców objętych CIDG prowadzona będzie w urzędach skarbowych, których właściwość określa art. 4 ustawy o zasadach ewidencji i identyfikacji podatników i płatników. Dane rejestracyjne przekazywane będą przez ewidencję działalności gospodarczej Ministerstwa Finansów do Centralnej Informacji drogą elektroniczną. Informacje zawarte w ewidencji będą jawne i dostępne dla każdego - tu pojawia się problem wyszukiwania informacji w takiej ewidencji. System ma zostać testów uruchomiony w II kwartale 2008 r. Nie będzie specjalnej aplikacji klienckiej (wszystko ma się opierać o interfejs webowy - "lekka architektura", stąd - być może - nie będzie takich problemów jak w przypadku Płatnika i SIMIK; por. Nieneutralny SIMIK). W założeniach mowa jest również o standardach: "w celu obniżenia kosztów systemu i podniesienia jego trwałości wymogiem będzie zbudowanie go w oparciu o otwarte standardy przemysłowe bez stosowania rozwiązań specyficznych dla produktów konkretnych firm wszędzie tam gdzie jest to możliwe". Amen.

Równolegle trwają prace nad nowelizacją ustawy o swobodzie działalności gospodarczej oraz niektórych innych ustaw (wedle projektu z 18 września 2006: uchyli ona przepisy art. 27-45, cytowałem niektóre z nich w przywołanym wcześniej tekście, ale jednocześnie stworzy ramy prawne Centralnej Informacji o Działalności Gospodarczej w rozdziale 3 ustawy (nowe brzmienie art. 23-27)).

Pojawia się pytanie o to, czy istnieje możliwość współdziałania różnych systemów informatycznych w ramach planowanego utworzenia CIDG i wdrożenia instytucji "jednego okienka" w urzędach skarbowych oraz o związane z realizacją tego projektu zagrożenia.

Poniżej kilka uwag (być może nieuczesanych), które nawiązują do powyższego pytania (proszę również czytelników o własne komentarze – które będę mógł wykorzystać w dyskusji na ten temat na forum Rady Informatyzacji).

"Wysoka wiarygodność informacji o działalności gospodarczej" - podszywanie się, phishing, spoofing. Tu warto zacytować fragment założeń: "W systemie InDyGo, do zapewnienia wymiany danych, przewiduje się wykorzystanie systemu internetowej transmisji danych z zastosowaniem protokołu SSL". SSl to Secure Sockets Layer, protokół opierający się na szyfrach asymetrycznych oraz certyfikatach X.509. Powstaje pytanie kto będzie wystawiał te certyfikaty. Jeśli będzie tak, jak w przypadku systemu e-poltax (por. Komentarze uruchomienia e-deklaracji), albo w Poznaniu (por. Odpis z urzędu), to nie zostanie spełniony wymóg bezpieczeństwa. Nie będzie kotwicy zaufania, za pomocą której można by zweryfikować wystawiony przez kogoś certyfikat; jeśli to ministerstwo finansów (na przykład) wystawi certyfikat X.509, albo inny podmiot, którego nie będzie można zweryfikować to efekt będzie taki (albo nawet gorszy) niż w sytuacji, w której nie byłoby SSL'a. Gorszy, gdyż użytkownicy systemu, po ujrzeniu niejasnego komunikatu o tym, że nie można sprawdzić autentyczności - stracą po raz kolejny zaufanie do tego typu rozwiązań. Zatem certyfikaty X.509 powinny być wystawiane przez takie podmioty, których certyfikaty są już w systemach operacyjnych (albo w "magazynach" przeglądarek), by nie trzeba było pobierać z niezaufanego źródła certyfikatu koniecznego do weryfikacji certyfikatu wystawionego dla transmisji.

Z tym, w pewien sposób, wiąże się kolejny problem - podpis elektroniczny ("System powinien umożliwiać wnioskodawcom, posiadającym kwalifikowany podpis elektroniczny, bezpośrednie złożenie wniosku za pośrednictwem odpowiedniego serwisu Internetowego"). Jest problem z różnymi standardami podpisu, z różnymi standardami "dokumentu elektronicznego". Na ten temat m.in. w dziale podpis elektroniczny niniejszego serwisu, a w szczególności w opracowaniu Internet Society Poland, por. Bariery podpisu elektronicznego w Polsce. Innymi słowy - zagrożeniem dla systemu jest to, że nadal rynek nie doczekał się jednolitego standardu podpisu i dokumentu elektronicznego, że rynek oprogramowania do składania i weryfikacji podpisów elektronicznych nie jest hmm... uwolniony (por. w tym względzie zmagania prawne dotyczące Elektronicznej Legitymacji Studenckiej: Rozmiękczanie plastiku czyli komu bije ELS).

Powyższe uwagi związane są również z problemem zaufania do prezentowanych danych i problem bezpieczeństwa. "Wpis nie może podlegać usunięciu" - aktualny jest wpis o "zakończeniu działalności" dane będą archiwizowane wiecznie: "bezterminowe przechowywanie całości historii wpisów"; a jednocześnie będzie istniało ustawowe domniemanie, że dane zawarte w Centralnej Informacji są prawdziwe. Dlatego ważne jest zabezpieczenie systemu przed mechanizmami stosowanymi przez phisherów, ale jednocześnie odpowiedni backup danych. Dane powinny być gromadzone w taki sposób, by dało się odzyskać szybko stan systemu po ewentualnym ataku (zwraca się w "założeniach" uwagę na konieczność takiego przygotowania systemu, by nie był podatny na ataki, ale pewnie nie da się przewidzieć wszystkich możliwości ataku, a dodatkowo - powstają wciąż nowe metody inwazji i modyfikowania danych).

A jeśli chodzi o backup i możliwość odbudowy systemu, to trzeba również pamiętać, by nie wejść na "ścieżkę uzależnienia" od dostawcy. Stąd dostawca powinien udostępnić wszelkie informacje na temat struktury danych, system bazodanowy nie powinien wykorzystywać zamkniętych, niekompatybilnych rozwiązań, etc. Chodzi o to, by nie trzeba było w przyszłości korzystać z dostawcy, który przygotował wcześniejszą wersję systemu. By można było zlecić modyfikację (rozwój, rozbudowę) systemu, bez naruszania postanowień umownych między zlecającym a wykonawcą, by nie trzeba było prosić o udostępnienie "danych stanowiących tajemnicę przedsiębiorstwa" czy innych poufnych informacji, które wykonawca może dać, albo zostawić dla siebie (i wówczas jesteśmy właśnie na "ścieżce uzależnienia"). W tym też kontekście problemem może być kwestia archiwizacji informacji (por. Archiwizacja oceanów informacji).

De facto powstaną dwie części systemu: jedna to centralna baza danych CIDG, druga zaś to system Internetowej informacji o działalności gospodarczej. Tu mowa o tym, że trzeba stworzyć mechanizm uniemożliwiający automatom korzystania z tej bazy "ze względu na konieczność zabezpieczenia przed przeciążeniem wyszukiwarka powinna być wyposażona w mechanizmy uniemożliwiające korzystanie z niej poprzez automaty". Hmmm... (por. Problem z działaniem serwisu UZP). Rozumiem, że istnieje zagrożenie przeciążenia systemu, jeśli pozwoli się innym podmiotom bez opamiętania "zasysać" dane z systemu. Należy jednak uwzględnić jeszcze takie regulacje jak Dyrektywa 2003/98/WE Parlamentu Europejskiego i Rady z dnia 17 listopada 2003 r. w sprawie ponownego wykorzystywania informacji sektora publicznego. Być może nie musi być to automatyczne zasysanie, ale jednak chciałbym móc (chociażby potencjalnie; nie twierdzę, że mam taki plan) na swojej stronie umieścić jawne dane osób prowadzących działalność gospodarczą. Dlaczego nie miałbym tego zrobić (por. Wyszukiwanie osób w brytyjskim serwisie)?

"Lekki interfejs" i internetowe wyszukiwarki, czyli "oprogramowanie interfejsowe" a interoperacyjność i dostępność (więcej na ten temat w dziale web accessibility niniejszego serwisu). Myślę, że wiele będzie zależało od tego, w jaki sposób wykonawca będzie podchodził do "dobrej roboty" webmasterskiej i dobrych praktyk, których emanacją są standardy wypracowane w ramach takich organizacji jak The World Wide Web Consortium (W3C). Przykładowo: w założeniach mowa jest o tym, że interfejs powinien posiadać wersje WAP. Zastanawiam się po co? Gdyby serwis (myślę o tym systemie Internetowej informacji o działalności gospodarczej jak o każdym innym serwisie internetowym) był poprawnie przygotowany, z poszanowaniem standardów, z oddzieleniem warstwy silnika, od treści, a tego wszystkiego od warstwy graficznej, z zastosowaniem arkuszy stylów kaskadowych i z poszanowaniem zasad WAI - można by było stworzyć wersję wyjściową na dowolną platformę. Taki serwis musiałby działać również w przypadku wyłączenia arkuszy styli. Grafik zbyt wiele nie powinien się tu napracować. Serwis powinien być zrobiony praktycznie bez grafiki (w rozumieniu plików graficznych).

W "założeniach" mowa jest o tym, że "Interfejs systemu powinien także występować w wersji uproszczonej i ubogiej graficznie tak, aby był łatwy w użyciu dla użytkowników korzystających z powolnych metod dostępu, takich jak GPRS". On nie powinien także być tak zrobiony. On w ogóle powinien być tak zrobiony. Style! CSS, oddzielenie warstw.

Nie twórzmy różnych wersji interfejsów, a pozwólmy ludziom te wizualne skórki samemu wybierać. Silnik to jedno, ułożenie danych to drugie (najlepiej w oparciu o DIVy), arkusze stylów to trzecie i tymi arkuszami można manipulować, a podstawowy "wygląd" nie powinien być obdarzony wodotryskami i technologiami powalającymi na kolana. Chodzi o to, by nie powtórzyła się sytuacja, z którą mamy do czynienia w przypadku serwisu Prezydenta RP albo w przypadku systemu Geoportal (por. Walka o publiczny dostęp do gromadzonych danych kartograficznych).

Im prostsze rozwiązanie interfejsowe - tym lepsze i bardziej dostępnie. Dobrze przygotowany interfejs webowy pozwoli również na proste przygotowanie (w oparciu o wprowadzone do systemu dane, ale wizualnie "ułożone") wydruku (wydruk formularza – wniosku z wypełnionymi danymi do podpisania przez wnioskodawcę, wydruk potwierdzenia przyjęcia zgłoszenia). Dodatkowo (o czym nie mówi się w założeniach, ale wtrącę swoje "trzy grosze") dzięki takim narzędziom jak chociażby FPDF czy inne biblioteki PDF'owe, można by zintegrować interfejs webowy z mechanizmem generowania dokumentu PDF z określonymi informacjami, dotyczącymi wpisu. To może robić automat. To dodatkowy "bajer", ale możliwy do zrobienia, jeśli tylko architektura serwisu internetowego, z którego będzie się korzystać, będzie poprawnie i modułowo zrobiona. Zresztą nie musi to być przecież PDF. Może to być ODF, czyli Open Document Format (por. ISO 26300), który po elektronicznym podpisaniu mógłby być wygodnym sposobem udostępniania „odpisów”.

W "założeniach" czytam (w dwóch różnych punktach dotyczących interfejsu użytkownika): "Cała funkcjonalność systemu musi być dostępna z użyciem przeglądarek Internetowych, przy czym system musi się dać obsługiwać przy pomocy różnych przeglądarek, działających w różnych systemach operacyjnych" a potem (w kolejnym punkcie): "Podstawowa funkcjonalność systemu od strony wnioskodawcy (składanie wniosków, internetowa informacja) powinna być dostępna dla użytkowników niewidomych, posługujących się urządzeniem lub oprogramowaniem czytającym albo linijką brajlowską". Warto zauważyć, że te różne wymogi przedstawione w "założeniach" wskazują również "źródło" postulatu. Źródłem tego ostatniego wymogu jest "Analityk". Ja bym wskazał art. 32 konstytucji - zakaz dyskryminacji, ale nie tylko. Są założenia unijne, takie jak eEurope 2002: Accessibility of Public Web Sites and their Content, do systemu prawnego wprowadzony zaraz będzie wymóg dostępności dla osób niepełnosprawnych, który wynikał będzie z nowego traktatu ONZ (por. Traktat ONZ: prawa niepełnosprawnych w tym dostępność do informacji). Tak czy inaczej - problem różnych przeglądarek i dostępności dla osób niewidomych, to po prostu jeden i ten sam problem standardu i dostępności zasobów internetowych. Nie można go od siebie oddzielać, bo dojdziemy do sytuacji, w której utworzy się serwisy dla widzących i korzystających z jednych przeglądarek, a potem inną wersję dla osób niewidomych, korzystających z linijek brajlowską. Chodzi o to, że trzeba tak zrobić serwis, by jednocześnie sposób dostępu do niego nie miał znaczenia. I znów - im prościej, tym lepiej. Bez bajerów, czytelnie, nawet po wyłączeniu arkuszy stylów.

"System powinien umożliwiać wymianę danych z systemem KRS w taki sposób, aby użytkownicy systemu InDyGo mogli wyszukiwać i przeglądać dane zgromadzone w rejestrze KRS zaś użytkownicy rejestru KRS mogli, poprzez obsługujący go system, przeglądać wpisy znajdujące się w ewidencji" - co wynika z ustawy wprowadzającej ustawę o swobodzie działalności gospodarczej. System powinien również wspierać przyjmowanie przez urzędnika w okienku US danych rejestracyjnych przedsiębiorcy w zakresie wymaganym przez GUS i ZUS. To problem, który leży już poza sferą interfejsową. Tu chodzi o formaty danych (ew. dobre przygotowanie "formatek" prezentujących pola baz danych z KRS w interfejsie webowym Internetowej informacji o działalności gospodarczej. A jeśli chodzi o bazy danych, to mowa jest zarówno o lokalnych bazach, jak i bazie centralnej: "Dane na temat tego samego podmiotu powinny być identyczne tak w lokalnej, jak i w centralnej bazie danych. Różnica może wystąpić jedynie w przypadku czasowego braku łączności systemu (obsługa off-line) i powinna zostać usunięta przy najbliższej synchronizacji". Na ten temat powinni się wypowiedzieć specjaliści od baz danych, którzy znają najlepsze rozwiązania w zakresie współistnienia i zasilania danymi różnych zbiorów danych. Z mojej korespondencji wynika jednak jeszcze inny problem: "Spięcie wielu różnych baz danych daje potężne pole do kradzieży danych i nadużyć. W razie wycieku danych wszyscy będą wzajemnie zwalać na siebie winę". Te same wątpliwości pojawiły się już w odniesieniu do projektowanego systemu PESEL2 (por. PESEL2 - kończą się konsultacje społeczne).

Niepokoją nieco założenia, zgodnie z którymi: "Dostawca systemu musi opracować otwarty format komunikatów i protokół ich wymiany, który uwzględniał będzie...". Myślę sobie, że jeśli to dostawca systemu ma opracować format i protokół, to jest to gorsza sytuacja od tej, w której dostawca po prostu wykorzysta istniejący już dorobek międzynarodowy w zakresie otwartych standardów formatów danych i protokołów komunikacyjnych. Chyba nie trzeba tworzyć (opracowywać) nowych. Zresztą w "założeniach" jest o tym mowa (w pewien sposób; np. "Oparcie komunikacji pomiędzy systemami lokalnymi a centralnym o otwarte i udokumentowane standardy"). Tutaj zatem istnieje problem zgodności przyjętych rozwiązań z aktami wykonawczymi do ustawy o informatyzacji w zakresie standardów wymiany i formatów danych (por. Minimalne wymagania dla rejestrów publicznych i wymiany informacji, Minimalne wymagania dla systemów teleinformatycznych oraz ich poprawienie, gdyż obecnie dopuszczalne są różne interpretacje: Pytania do minimalnych wymagań oraz Minimalne wymagania i wyjaśnienie MSWiA).

Skoro system ma działać w Urzędach Skarbowych, to powstaje pytanie o relacje tego systemu do regulacji prawnych związanych z fakturami elektronicznymi. Przypominam, że na mocy rozporządzenia Ministra Finansów z dnia 14 lipca 2005r. w sprawie wystawiania oraz przesyłania faktur w formie elektronicznej, a także przechowywania oraz udostępniania organowi podatkowemu lub organowi kontroli skarbowej tych faktur (Dz.U. Nr 133, poz. 1119) - faktury elektroniczne przechowuje się w sposób umożliwiający organom podatkowym lub organom kontroli skarbowej, natychmiastowy, pełny i ciągły dostęp drogą elektroniczną do tych faktur. Wedle jednej z interpretacji Izby Skarbowej w Katowicach: taki "dostęp może być zapewniony tylko na zasadzie pracy w czasie rzeczywistym czyli "on-line"" - tak wynika z decyzji w sprawie interpretacji prawa podatkowego, sygnatura: IPB_1/4407-0002/06/I. Pytanie zatem o infrastrukturę Urzędów Skarbowych i integrowanie tej infrastruktury z systemami teleinformatycznymi podmiotów gospodarczych, wykorzystujących elektroniczny obieg faktur. Jedynie sygnalizuję tu ten potencjalny związek systemu Centralnej Informacji o Działalności Gospodarczej z faktem, że Urzędy Skarbowe będą wykorzystywały swoje zasoby również w innych celach. Jak się wydaje - nie jest potrzebne (nie chciałbym tego postulować), by system kontroli elektronicznych faktur był zintegrowany z omawianym w niniejszym tekście systemem.

Poza rozważaniami tu zawartymi znajduje się problem zagwarantowania prywatności zarówno osób fizycznych prowadzących działalność gospodarczą, ale też osób, które korzystają z systemu (zarówno przeglądają zgromadzone dane za pomocą interfejsu webowego, ale również tych, które wprowadzają dane - urzędników). Jest to problem (por. m.in. Inwigilacyjne uprawnienia wywiadu skarbowego, Walka z terroryzmem, ale nie kosztem prywatności - w tym ostatnim tekście mowa o apelu Europejskiego Inspektora Ochrony Danych Osobowych dotyczącego konstruowania przepisów i systemów w taki sposób, by zawsze chronić dane osobowe, stąd myślę, że to odesłanie jest adekwatne do omawianej problematyki). Jest to problem, który jednak wykracza poza tematykę zagrożenia dla współdziałania różnych systemów informatycznych, a chodzi zarówno o technologię cookies, o monitorowanie, o zestawianie sesji webowych, etc., ale nie tylko o to.

Doniesienia i komentarze na podobny temat gromadzę w dziale informatyzacja niniejszego serwisu.