Jako partner merytoryczny raportu zapraszam do lektury:
Rynek jest praktycznie nasycony w tym sensie, że praktycznie nie ma już firm nie mających oprogramowania wspomagającego zarządzanie. Tu warto podkreślić, że skrót ERP (ang. Enterprise Resource Planning) rozumiany szerzej to nie tylko jeden uniwersalny i zintegrowany pakiet oprogramowania jednego producenta, to każdy system, monolityczny lub złożony z kilku zintegrowanych aplikacji, obejmujący swoim zasięgiem działania wszystkie obszary działania organizacji. (Jarosław Żeliński IT-Consulting.pl) […] Trzeba sobie szczerze powiedzieć, że skoro pełna 100% identyfikacja potrzeb informatycznych na wczesnym etapie projektu, czyli szczegółów graniczy z cudem, więc metodyki klasyczne zwane potocznie waterfall’owymi nie prowadzą nas do sukcesu. (Janusz Pieklik, Business Global Consulting Polska, www.bgc.com.pl)
Polecam cały raport, informacje od dostawców oprogramowania i dwa duże opracowania o wdrożenia dwóch niezależnych i doświadczonych ekspertów: PERSPEKTYWY 2018 – ERP-view.pl – ERP, CRM, ECM, MRP, Business Intelligence, MRP
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Nie raz tu już pisałem, że analizy i projekty związane bezpośrednio z wymaganiami na oprogramowanie to „tylko” ok. 3/4 moich projektów. Jednak nawet, jeżeli projekt nie jest „nazwany” informatycznym, to zawsze jest „informacyjny” w rozumieniu zarządzania informacją (także zarządzanie wiedzą). Tym razem kilka słów na temat dokumentów. Stanowią one podstawową jednostkę informacji (i danych) w każdym systemie biznesowym. Są także źródłem danych dla hurtowni danych.
Wstęp
Wiele projektów związanych z dokumentami jest sprowadzanych do problemu:
„jakie mamy dokumenty i co z nimi robimy?”
Zaniedbuje się bardzo ważny element: odpowiedź na pytanie:
„czy nasze obecne dokumenty, ich ilość i treść, są właściwe?”
Otóż praktyka pokazuje, że dość często problemem są dokumenty opracowane „kiedyś tam”. Inicjuje się projekt z różnymi wymaganiami ale nikomu nie przychodzi do głowy by zastanowić się nad tym czy obecne dokumenty, w ich obecnej postaci, są dobrym pomysłem i powinny takie pozostać.
Czy dokumenty są niezmienialnym bytem? Nie, nie są.
Każda organizacja obraca skończoną liczbą dokumentów, są to różnego rodzaju formularze, w najogólniejszym przypadku dokumentem jest po prostu każda treść, także „zwykła proza” np. notatka. Warto jednak zwrócić uwagę na to, że nawet ona ma pewną strukturę: np. autora, adresata, temat, datę i treść. Dokumenty to określona konkretna treść utrwalona z określonego powodu (w przeciwnym wypadku dokument nie by powstał). Osiem lat temu opisywałem kwestie różnicy między dokumentem, wiedzą, informacją a danymi:
Czy baza danych to wiedza?[?] Model jawnie pokazuje, że bezpośredni związek z Bazą Danych mają Dane. Dalej już są wyłącznie niematerialne pojęcia czym więc jest Zarządzanie Wiedzą (milcząco zakładam, że zarządzać można czymś materialnym)? Jest to ?przechowywanie danych jednoznacznie zrozumiałych, opisujących określone i ograniczone liczbą fakty interpretowane jako pojmowalna przez adresata informacja?. (Źródło: Potrzeby informacyjne firmy ? Zarządzanie wiedzą | Jarosław Żeliński IT-Consulting)
Dzisiaj co nieco o tym, dlaczego od czasu do czasu warto się pochylić nad wzorami dokumentów i czy czasem nie zmienić nieco podejścia do nich.
Dokumenty w organizacji
Swego czasu u jednego z moich klientów „odkryłem” ciekawy dokument. Była to faktura z dodanym zestawem danych odpowiadającym dokumentom WZ oraz analogicznym zestawieniem dotyczącym opakowań zwrotnych. Ten super dokument był pomysłem z przed wielu lat osoby odpowiedzialnej za wydawanie i zarządzanie opakowaniami zwrotnymi w magazynie. Uzasadnienie brzmiało: na jednym dokumencie będą wszystkie informacje związane z konkretną sprzedażą i dostawą. Brzmi ładnie jednak: praktycznie każdy kto miał z tym dokumentem do czynienia, w toku obsługi zamówienia, dostawał nadmiarowe dane, nie raz niejawne (niektóre) ceny, szczegóły zawartości paczek, wartość towaru (po co ta wiedza kierowcom), ilości i salda (tak) opakowań zwrotnych (jak się okazało dokument nie raz pomagał w nadużyciach, niektórzy pracownicy zaś zamazywali czasami część danych przekazując dokument dalej, by ich nie ujawniać). Ale największym problemem było to, że ta osoba uczyniła z tego wzoru dokumentu wymaganie wobec oprogramowania ERP. Jak się nie trudno domyśleć, żaden rynkowy system nie ma takiego dokumentu standardowo, dostawca ERP uznał to wymaganie bez zastrzeżeń, co przyczyniło się do wielu modyfikacji oprogramowania także w innych miejscach, znacznego wzrostu budżetu (współdzielona baza danych propaguje zmiany praktycznie na całą aplikację). Nie będę tu opisywał dalszych losów tego wzoru dokumentu bo celem moim było jedynie pokazanie problemu na realnym przykładzie.
Każdy projekt, czy to wdrożenie nowych zasad zarządzania czy nowego oprogramowania, związany z zarządzaniem organizacją, to (powinien być) także co najmniej przegląd dokumentów i ich obiegu. Kluczowym elementem tego przeglądu powinna być analiza treści tych dokumentów, ich optymalność, nie tylko obiegu ale także treści i jej struktury. Owszem, wiele dokumentów ma narzuconą strukturę np. w odpowiedniej ustawie, jednak są to minimalne zawartości (np. faktura) nie ma zakazu uzupełnienia tej struktury i np. dodania do faktury numeru zamówienia, z którym jest związana.
Ogólnie można określić pewne prawidłowości: jeżeli dokumenty są przeciążane treścią, czyli idziemy w kierunku małej ilości dokumentów zawierających dużo danych, rośnie złożoność reguł pracy z takim dokumentem. Jeżeli zaś idziemy w kierunku dokumentów „bardzo prostych”, rośnie ilość ich typów i rośnie liczba reguł kojarzących te dokumenty ze sobą w celu ich użycia. Ogólnie obrazuje to poniższy diagram:
Tak więc skrajnym rozwiązaniem będzie stworzenie jednego dokumentu, na którym będą wszystkie informacje np. związane z danym zamówieniem. Drugą skrajnością jest podzielenie informacji na odrębne małe niepodzielne już grupki, jak to ma miejsce w znormalizowanych relacyjnych bazach danych. Jeżeli megadokumenty to raczej bardzo rzadkie zjawisko, to przypadek drugi jest dość powszechny. To co nazywamy często dokumentem to tu tak na prawdę nieistniejący byt w relacyjnej bazie danych, generowany ad-hoc „w locie” z szeregu rozdrobnionych tablic danych. Innymi słowy nie są to „stałe struktury” a pewna określona złożona logika, tworząca z prostych danych pobieranych z tablic, konkretne zestawy informacji np. faktury (to dlatego często w „języku dostawcy” faktura to raport a nie dokument!). Ta złożona logika realizowana jest (wykonywana w pamięci komputera) za każdym razem gdy odwołamy się do takiego dokumentu.
Optymalna sytuacja to rodzaj kompromisu pomiędzy złożonością logiki tworzenia i korzystania z dokumentu a jego zawartością. Na powyższym diagramie jest to obszar stanowiący okolice minimum krzywej opisującej zależność pomiędzy liczbą dokumentów a złożonością operowania nimi. Nie ma prostej reguły na opracowywanie i optymalizacje treści i liczby dokumentów jednak są pewne sprawdzone dobre praktyki, a mianowicie jeden dokument, o określonej strukturze, powinien zawierać dane o określonym zdarzeniu w określonym kontekście [powstaje teraz publikacja na ten temat, wydaje się można to jednak zdefiniować, przyp autora 2019]. Dokumenty te, podobnie jak fakty które dokumentują, mogą mieć każdy własny i różny od innych cykl życia, dlatego często bywa bardzo szkodliwe „rozdzielanie” ich na pola bazy danych i pozbycie się redundancji.
Przykładem mogą być: zamówienie jako udokumentowanie faktu zawarcia umowy na dostawę, faktura jako udokumentowanie faktu sprzedaży (przeniesienia własności) oraz dokument WZ dokumentujący fakt wydania z magazynu określonych produktów. Bardzo często specyfikacja tego co wydano z magazynu nie jest tożsama z treścią faktury (sprzedano odkurzacz a wydano odkurzacz i zapasowe worki), na zamówieniu mógł być wyszczególniony odkurzacz, worki oraz wymagane końcówki (które są np. u producenta pakowane w standardzie więc nie ma ich ani na fakturze ani na WZ). Dlatego ma głęboki sens by te dokumenty były jednak „osobnymi dokumentami” a nie zachowywanymi w bazie danych danymi jako odrębne pola pozbawione redundancji, wymagające skomplikowanej logiki (polecenia SQL) by je (te „dokumenty”) pokazać na ekranie czy wydrukować.
To dość trywialny przykład, bo opisane dokumenty są wymagane przepisami jako dowody księgowe, jednak każda większa organizacja ma swoje wewnętrzne dokumenty, na których ilość i treść ma pełny wpływ. Po drugie nawet te dokumenty są często właśnie zapisywane w relacyjnych bazach danych jako rozproszone po małych tabelach dane, wymagające skomplikowanych operacji łączenia w jeden „dokument”, każdorazowo przy próbie jego użycia. Tu zachodzi bardzo duże ryzyko, że postać i treść takiego dokumentu ulegnie zmianie np. po reorganizacji bazy danych. Takich „dokumentów” nie da się (w tej postaci) podpisać elektronicznie, bo one po protu fizycznie na prawdę nie istnieją.
A jak inaczej? Nie ma żadnego problemu by dowolny dokument stanowił sobą jednolity byt np. zestaw danych w formacie XML, skojarzony ewentualnie ze swoją postacią gotową do druku albo np. plik PDF skojarzony z metadanymi opisującymi go (wybór jest na prawdę duży). Nie należy zapominać, że poza dokumentami, które są tworzone w organizacji operujemy dokumentami obcymi, otrzymanymi z zewnątrz i wypadało by mieć taki dokument w postaci takiej jaką przesłał nam ich twórca. Owszem pojawia się redundancja danych ale ona nie stanowi sobą nic złego. Ogromną korzyścią takiego podejścia jest rozwiązanie problemu polegającego na niemożności rozdzielenia „dokumentów” i logiki operowania nimi jeżeli są zapisane w postaci odrębnych pól w relacyjnej bazie danych. Np. staje się niemożliwe pozostawienie faktur i wyniesienie dokumentów magazynowych do odrębnego systemu (w tym zmiana ich struktury) co ma miejsce nie raz przy wdrażaniu systemów WMS (systemy logistyczno-magazynowe). Takie operacji prawie żaden duży zintegrowany ERP nie wytrzyma (usłyszymy raczej, że „my dostosujemy do Państwa potrzeb nas moduł magazynowy…).
Podejście takie ma także inna ciekawą zaletę: jeżeli udokumentujemy osobno struktury dokumentów i logikę operowania nimi (także ich tworzenia), to otrzymamy obiektowy model organizacji: model pokazujący wzajemną współpracę obiektów biznesowych (dokumentów) odpowiedzialnych za przechowywanie informacji, obiektów odpowiedzialnych za rejestrowanie tych informacji, obiektów mających wiedzę jak operować tymi informacjami, obiektów udostępniających to wszystko zgodnie z określoną logiką. Poniżej obiektowy model na którym od prawej mamy: dokumenty z ich treścią oraz logikę ich tworzenia i udostępniania (repozytoria czyli kuwetki na dokumenty), logikę korzystania z informacji w repozytoriach, także ich wzajemnego kojarzenia (samodzielne usługi) oraz logikę dostępu do tego systemu (realizacja scenariuszy przypadków użycia). Jeżeli w toku analizy uznamy, że jakieś elementy tej logiki to zadania poddające się w 100% algorytmizacji, to poniższy model jest jednocześnie modelem logiki aplikacji i nazywamy go Modelem Dziedziny Systemu. Nie jest to absolutnie żadna baza danych, poniższe repozytoria niczego nie współdzielą (można je w dowolnym momencie zamieniać na inne bez konsekwencji dla reszty systemu).
Model ten powstał z użyciem bloków funkcjonalnych wzorca BCE (opisałem go tu: Wzorzec analityczny Boundary Control Entity). Dla wyjaśnienia: powyższy diagram to w pełni poprawny Model dziedziny wykonany z użyciem diagramu klas UML, klasy mają stereotypy boundary, control i entity (powyżej od lewej do prawej), stereotypy te są reprezentowane symbolami opisanymi (ikonami) w BCE. (Źródło: Krzywe i koszty? architektury | | Jarosław Żeliński IT-Consulting)
Prawie zawsze obserwuję, że podstawowym domyślnym założeniem wdrożeń systemów wspomagających zarządzanie, jest uznanie a priori niezmienności struktury i wzorów dokumentów.
Z doświadczenia mogę powiedzieć, że analiza i optymalizacja treści dokumentów wewnętrznych może przynieść bardzo duże korzyści przekładające się na duży wzrost wewnętrznej efektywności i jakości pracy, a w przypadku wdrożeń oprogramowania wspomagającego zarządzanie, pozwala nie raz całkowicie uniknąć bardzo kosztownych i ryzykownych kastomizacji. Zaryzykuje tezę, że kilka projektów w ten sposób wręcz uratowałem…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Obydwa te, spotykane często w prasie, skróty mają wiele wspólnego: oznaczają aplikacje zarządzające obiegiem informacji i jej magazynowaniem (ECM – Electronic Content Management czyli zarządzanie treścią w postaci elektronicznej oraz EOD – Elektroniczny Obieg Dokumentów). Cechą zawartą „nie wprost” w tych nazwach jest zarządzanie także składowaniem i przepływem tej informacji. Osiem lat temu pisałem o kwestiach pojęciowych (czym jest wiedza, jej przetwarzanie, czym są dane):
Problematyka informacji w firmach, jej kolekcjonowania i przetwarzania jest częstym tematem artykułów w prasie specjalistycznej jak i opisem zakresów projektów IT. Termin ten jest jednak nie raz nadużywany. W prasie można pozwolić sobie na pewną dowolność jego interpretacji jednak w opisie zakresu projektu analitycznego pozycja o nazwie ?Zdefiniowanie potrzeb informacyjnych firmy? może rodzić poważne kłopoty z odbiorem tej części projektu gdyż tu na dowolność interpretacji nie powinno być miejsca. (Źródło: Zarządzanie Wiedzą | Jarosław Żeliński IT-Consulting)
Niedawno, 26 stycznia 2016, miałem referat na konferencji pod hasłem Business Process Management:
W trakcie referatu zwróciłem uwagę na to, że to co często nazywamy zarządzaniem procesami (popularny skrót [[BPM]]) biznesowymi, tak na prawdę jest zarządzaniem przepływem pracy, zarządzaniem informacją i nadzorowaniem tych aktywności. Tu zwrócę uwagę na to, że przepływ pracy odwzorowywany jest w aplikacji jako ciąg raportów i notatek:
przełożony dowiaduje się o wykopaniu rowu nie z własnej obserwacji a z raportu swojego podwładnego
dlatego oprogramowanie może operować wyłącznie udokumentowanymi faktami a nie zjawiskami w realnym świecie: to są zapisy jakimi zarządza oprogramowanie zarządzające szeroko pojętą treścią. Tak więc
zarządzanie procesami biznesowymi to nic innego jak zbieranie informacji, przetwarzanie ich i decydowanie o kolejnych pracach do wykonania, informując o tym wykonawców tych kolejnych prac.
Aplikacja wspierająca przepływ pracy to oprogramowanie, które pozwala na tworzenie formularzy (i zasad weryfikacji ich poprawności) specyficznych dla każdego zadania, reguł biznesowych narzucających opcjonalność i kolejność realizacji zadań (aktywności), kategoryzowanie treści i zadań, udostępnianie powstałych treści:
Powyższy diagram przypadków użycia można w zasadzie uznać za „referencyjny”, każda aplikacja tego typu tak mogła by wyglądać, czy to wystarczy dostawcy oprogramowania? Nie, bo cała wiedza o konkretnym wdrożeniu tkwi w szczegółach. Gdzie one są? Pisałem o tym prawie rok temu:
Tu warto na początek wrócić do klasyfikacji wymagań. W artykule Inżynieria wymagań opisałem trzy ich rodzaje: (1) funkcjonalne czyli usługi aplikacji (przypadki użycia tej aplikacji), (2) poza-funkcjonalne czyli cechy jakościowe, (3) dziedzinowe czyli logika biznesowa. I teraz bardzo ważna rzecz: które elementy architektury oprogramowania, za realizację których wymagań odpowiadają? (Źródło: Gdzie są te cholerne szczegóły | | Jarosław Żeliński IT-Consulting)
Jak widać, klucz tkwi w modelu dziedziny systemu czyli w specyfice branży, konkretnej firmy lub organizacji. Powyższe przypadki użycia, jak wyżej, to opis „dowolnego ECM/EOD”. Referencyjna architektura takiego systemu mogła by mieć taką postać:
Dlaczego tak? Komponent zarządzający procesami odpowiada za logikę kolejności przetwarzania treści. Repozytorium odpowiada za zachowywanie i udostępnianie treści. Dodano tu komponent Filesystem, gdyż osobiście jestem zwolennikiem podejścia, w którym dokumenty elektroniczne są składowane nie w bazie danych (tak zwane BLOB) a na dyskach, a logika zarządzania nimi to odrębne oprogramowanie (patrz europejksie zalecenia Moreq). Dzięki temu utrata lub zmian aplikacji (i bazy danych) nie powoduje utraty zasobów.
Na czym więc polega analiza biznesowa przed wdrożeniem EOD/ECM? Czym są tu wymagania? Są nimi reguły biznesowe, wzory dokumentów i słowniki pojęć (danych). To tu tkwi największe ryzyko wdrożenia, kluczem jest tu zawsze tak zwany model pojęciowy. Powyższa architektura jest przeze mnie traktowana jako referencyjna, gdyż gwarantuje możliwość odwzorowania dowolnego „systemu zarządzania informacją”, taką lub podobną zalecaną architekturę można spotkać w wielu opracowaniach na temat ECM.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
W 2011 roku pisałem o tym, że W sądach i urzędach ginę dokumenty. Coś jednak się może poprawi. Tym razem krótki wpis, raczej wręcz zestawienie cytatów. Najpierw cytat z listopada 2013:
Dlatego kiedyś nieprawidłowe realizowanie czynności kancelaryjnych wpływało na nieporządek w dokumentacji i konieczność jej porządkowania w archiwum. Obecnie poprawienie błędów w zarządzaniu dokumentacją w systemie wiązałoby się z nieporównywalnym nakładem pracy a zadanie byłoby trudne do zrealizowania.
Stąd propozycja zmiany kompetencji Archiwów Państwowych w zakresie prowadzonych przez nie kontroli.
Jak podkreśla Andrzej Biernat, projektowane przepisy dadzą archiwom kompetencje w zakresie możliwości kontroli postępowania z dokumentacją bez względu na miejsce jej przechowywania. Bowiem nie będzie się ona ograniczać jedynie do archiwum danego podmiotu.
Jednocześnie przypomina, że pojęcie materiałów archiwalnych, czy dokumentacji niearchiwalnej nie odnosi się wyłącznie do dokumentacji zgromadzonej w archiwum, ale także do dokumentacji bieżącej. (Serwis Samorządowy PAP).
Czy mamy problem? Tak, we wrześniu 2013 PAP pisał:
- To nieprawidłowe stosowanie przepisów kancelaryjnych i archiwalnych lub też opór pracowników przed stosowaniem tych przepisów prowadzi do nieprawidłowego zarządzania dokumentacją w urzędzie ? twierdzi wiceminister administracji Stanisław Huskowski.
Jego zdaniem przyczyną tego jest m.in. nieprzestrzeganie lub też nieprawidłowe stosowanie przepisów kancelaryjnych i archiwalnych w urzędach.
- Bardzo często pracownicy administracji publicznej przy wysokich kwalifikacjach merytorycznych posiadają bardzo małą wiedzę o zasadach pracy kancelaryjnej lub też świadomie nie przestrzegają przepisów kancelaryjnych, uznając je za nieistotne ? ocenia wiceszef MAC. (Serwis Samorządowy PAP).
To taka refleksja po kilku przygodach projektowych z Urzędami. Tam gdzie mi się przydarzył projekt związany z obiegiem dokumentów w urzędach w 100% problemem było własnie ignorowanie zapisów instrukcji kancelaryjnych (one zawierają między innymi opis sposobu znakowania dokumentów: Jednolity Rzeczowy Wykaz Akt – JRWA, i zarządzania nimi). Z moich obserwacji wynika, że problem ginących dokumentów nie polega na tym, że dokumenty „znikają” z powodu zniszczenia czy wyniesienia poza urząd. One po prostu nie są odnajdywane w tych urzędach. Wystarczy, że ktoś odłoży teczkę akt w złe miejsce albo źle oznaczy dokument, który w wyniku tego zostanie umieszczony w złej teczce i – mając świadomość, że tych dokumentów są tysiące – dokument taki staje się nie do znalezienia.
Na koniec ciekawostka z rodzaju „przyganiał kocioł garnkowi”: w firmach „prywatnych” dokumenty giną znacznie częściej. Mało która firma, nie będące urzędem, ma dobrze zorganizowany system obiegu dokumentów. Owszem, dokumenty księgowe, a konkretnie: dowody księgowe, są z reguły dobrze zarządzane ale to efekt wymagań prawa w tym obszarze. Dobrze jest nie raz także z Umowami, ale tu także mamy wymogi prawne (Umowa jako dokument jest tak samo ważnym dowodem jak np. faktura). Pozostałe dokumenty (oferty, zapytania, pisma do klientów itp.) to w większości firm „towar uboczny”.
Jest jednak światełko w tunelu: dobrze zaprojektowany system nazywany CRM, to tak na prawdę system zarządzania dokumentacją pozaksięgową. Korespondencja z klientami, ustalenia projektowe, oferty, reklamacje itp. To dokumenty, które nie powinny ginąć. W organizacjach nie będących urzędami mamy ten sam problem (mimo, że nie muszą one oddawać dokumentów do Archiwów Państwowych): jak prześledzić sprawę związana z obsługa klienta?
Tu pomagają właśnie „tylnymi drzwiami” systemy zarządzania projektami (dokumenty projektowe), systemy CRM (dokumenty poprzedzające sprzedaż, reklamacje, rozliczenia umów itp.), zarządzanie dokumentacja produkcyjną. Tu mała uwaga: tak zwane systemy FK nie zarządzają dokumentami (dowody księgowe), są to systemy rejestrujące ich treść. Zarządzanie tymi dokumentami (oryginały i ich skany) także wymaga posiadania archiwum. Takim odpowiednikiem ERP w obszarze dokumentów jest system ECM czyli [[Enterprise Content Management]]. W pewnym sensie każda organizacja to także Urząd.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.