A. przygotowaniu opisu funkcjonalnego Systemu Muzeum · 21) Monitorowane są w logach serwera wszystkie zmiany w bazie danych, dokonywane z poziomu aplikacji 22) Dostarczona baza

Znak sprawy: KF.AZ.2401.7.JM.2019

Strona 1 z 52

OPIS PRZEDMIOTU ZAMÓWIENIA – dalej jako „OPZ”

A. Przedmiotem zamówienia jest usługa polegająca na przygotowaniu wspólnie z

Zamawiającym opisu funkcjonalnego Systemu Zarządzania Procesami w Muzeum

(dalej jako „SZPM”) oraz jego wdrożenie.

B. Całość zamówienia składa się z:

dostawy i uruchomienia platformy BPMS - Systemu Zarządzania Procesami Biznesowymi,

przygotowanej na podstawie zatwierdzonej przez Zamawiającego koncepcji systemu SZPM,

wraz z przekazaniem nieograniczonych czasowo licencji użytkowania sytemu BPMS,

budowy aplikacji biznesowej składającej się z opisanych w dalszej części procesów oraz

dostawy i uruchomienia wymaganego do działania systemu SZPM dodatkowego

oprogramowania (w tym bazy danych, programu do OCR) wraz z wymaganymi licencjami.

C. W ramach zamówienia zostanie utworzone jednolite środowisko informatyczne pozwalające

na uruchamianie procesów, gromadzenie, przetwarzanie oraz udostępnianie dokumentów i

informacji.

D. Procesy będą zbudowane oraz zoptymalizowane w oparciu o dostarczony przez

Zamawiającego opis startowy (stanowiący punkt 7 niniejszego OPZ, w ramach prac zespołów

wdrożeniowych, przy zastosowaniu metodyk zwinnych - Agile.

E. Przedmiot zamówienia obejmuje również przeprowadzenie szkoleń w zakresie

dostarczonego i uruchomionego SZPM dla 23 pracowników Zamawiającego.

DEFINICJE

W niniejszej umowie zastosowanie mają następujące definicje:

Administrator systemu – użytkownik posiadający najwyższe uprawnienia do zarządzania

systemem informatycznym i odpowiadający za jego sprawne działanie.

Analityk biznesowy – użytkownik posiadający wymagane kompetencje oraz uprawnienia do

tworzenia i uruchamiania procesów biznesowych w systemie.

API (Application Programming Interface) – interfejs programistyczny umożliwiający

wymianę danych pomiędzy aplikacjami.

Aplikacja biznesowa (aplikacja) – dedykowane oprogramowanie wytworzone w oparciu o

platformę BPMS w formule ”low code”, zgodnie z zamówieniem na potrzeby Zamawiającego.

Baza wiedzy – stanowi ją zbiór dokumentów wewnętrznych i zewnętrznych generowanych u

Zamawiającego w procesie zarządzania oraz działalności merytorycznej, wraz z regułami

logicznymi umożliwiającymi efektywne wykorzystanie danych.

Cienki klient – oprogramowanie typu klient w architekturze klient-serwer, niezależne od

obsługiwanej platformy serwerowej (jej zmiana nie pociąga za sobą konieczności wymiany

oprogramowania klienta).

JRWA (Jednolity Rzeczowy Wykaz Akt) – stanowi on jednolitą, niezależną od struktury

organizacyjnej, klasyfikację dokumentacji powstającej w toku działalności organizacji oraz

zawiera kwalifikację archiwalną. Obejmuje wszystkie sprawy i zagadnienia z zakresu

działalności, oznaczone w poszczególnych pozycjach symbolami, hasłami i kategorią archiwalną.


Strona 2 z 52

Kierownik projektu (w przypadku zastosowania metodyki Scrum – kierownik prac - Scrum

Master) – osoba odpowiedzialna za organizowanie oraz prowadzenie prac wdrożeniowych oraz

developerskich po stronie Wykonawcy.

Metody Agile – grupa metod tzw. zwinnego wytwarzania oprogramowania oparta na pracy

zespołów w modelu iteracyjno-przyrostowym. Przewaga tego typu metod wdrażania

oprogramowania w stosunku do modelu kaskadowego (koncentrującego się na wdrażaniu

oprogramowania w takim kształcie, w jakim został on określony na jego pierwszym etapie)

polega na lepszym dopasowaniu produktu do wymagań Zamawiającego. W przypadku

wdrażania platformy BPMS wraz z procesami wyspecyfikowanymi przez Zamawiającego

pozwala na przeprowadzenie optymalizacji procesów na etapie wdrożenia.

Model RACI – opisuje, najczęściej w formie macierzy, odpowiedzialność członków zespołu za

realizację zadań opisuje odpowiedzialność członków zespołu za realizację zadań projektu lub

procesu biznesowego. RACI jest akronimem wywodzącym się z czterech kluczowych

obowiązków występujących podczas realizacji projektu, (z ang. Responsible, Accountable,

Consulted, Informed).

Notacja BPMN 2.0 (ang. Business Process Model & Notation) – notacja graficzna służąca do

opisu procesów biznesowych.

Oprogramowanie OCR – (od ang. Optical Character Recognition) – zestaw technik lub

oprogramowanie służące do optycznego rozpoznawania znaków i całych tekstów z pliku

graficznego o postaci rastrowej.

Scrum – ramy postępowania wykorzystywane w zarządzaniu wytwarzaniem złożonych

produktów opisane w „Przewodnik po Scrumie: Reguły Gry” Kena Schwabera i Jeffa Sutherlanda,

listopad 2017. Jedna z metod tzw. zwinnych (Agile) opisanych powyżej.

System BPMS (ang. Business Process Management System) – System Zarzadzania Procesami

Biznesowymi, system klasy BPMS - platforma BPMS umożliwiająca uruchomienie oraz

projektowanie procesów (biznesowych).

System Zarządzania Procesami w Muzeum (SZPM) – system zarządzania procesami oparty o

platformę BPMS oraz uruchomione z jej pomocą procesy, w tym proces podstawowy pomysł-

projekt-zadanie, pozostałe procesy i raporty oraz elektroniczny proces kancelaryjny obiegu

dokumentów. W skład systemu wchodzi również dodatkowe oprogramowanie tj. baza danych,

program do OCR.

Użytkownicy biznesowi – użytkownicy realizujący tzw. procesy biznesowe. W przypadku

Zamawiającego są to pracownicy wykonujący działania związane z obsługą zadań w systemie

SZPM.

Właściciel produktu (Product Owner) – osoba odpowiedzialna za prowadzenie prac oraz

decydująca o ostatecznym kształcie systemu SZPM po stronie Zamawiającego.

Wykonawca należy przez to rozumieć osobę fizyczną, osobę prawną albo jednostkę

organizacyjną nieposiadającą osobowości prawnej, która ubiega się o udzielenie zamówienia

publicznego, złożyła ofertę lub zawarła umowę w sprawie zamówienia publicznego

Zamawiający/Muzeum – Muzeum Pałacu Króla Jana III w Wilanowie, ul. Stanisława Kostki

Potockiego 10/16, 02-958 Warszawa.


Strona 3 z 52

1. Wymagania ogólne dla Systemu Zarządzania Procesami w Muzeum.

1.1. System Zarządzania Procesami w Muzeum ma zostać zbudowany w oparciu o platformę

BPMS, współpracującą z nią bazę danych, serwer web oraz inne potrzebne

oprogramowanie, w tym oprogramowanie do OCR. System ma służyć do realizacji

procesów biznesowych oraz elektronicznego kancelaryjnego obiegu dokumentów w

Muzeum. Ma dać możliwość modelowania, analizy, optymalizacji procesów biznesowych,

a następnie ich realizacji oraz umożliwiać samodzielne projektowanie procesów przez

Zamawiającego. Projektowanie, analiza i optymalizacja procesów ma się odbywać w

oparciu o notację BPMN 2.0

1.2. Projektowanie procesów, formularzy i raportów ma być dostępne w systemie BPMS dla

użytkowników posiadających odpowiednie uprawnienia - analityków biznesowych (6

osób) oraz administratorów systemu (2 osoby), z możliwością późniejszego rozszerzenia

liczby uprawnionych osób.

1.3. Wszystkie moduły BPMS łącznie z interfejsem zarządzającym systemem BPMS mają być

dostępne przez przeglądarkę WEB-ową (w postaci tzw. cienkiego klienta) oraz

połączenie https.

1.4. System SZPM ma być zintegrowany z posiadanymi przez Zamawiającego programami

pakietu MS Office (Word, Excel, Outlook – (nadawanie, odbieranie poczty,

wprowadzanie i czytanie danych z kalendarza), w zakresie wymaganym do pracy

użytkowników biznesowych. Zakres integracji ma zapewnić funkcjonalność, dającą

możliwości nie mniejsze niż mapowanie pól szablonu (template) dokumentów MS Word

oraz arkuszy Excel przy zastosowaniu XML-a oraz ich przekształcaniu. Dopuszcza się

rozwiązania równoważne, np. placeholdery.

1.5. Aplikacja biznesowa zostanie zrealizowana w postaci tzw. cienkiego klienta – z

interfejsem w postaci przeglądarki WEB oraz połączenia https.

1.6. Dopuszczalna jest możliwość instalacji pewnych komponentów wykorzystywanych

przez system SZPM (tj. sterowniki, biblioteki) na komputerze użytkownika. (Np. podpis

elektroniczny, drukarki, skaner, sterowniki do obsługi baz danych, oprogramowanie

OCR).

1.7. Niezbędna jest współpraca systemu z aktualnymi wersjami przeglądarek Firefox,

Chrome, Safari oraz Internet Explorer w wersji 11 lub nowszej.

1.8. System SZPM ma mieć możliwość przygotowania pulpitu użytkownika przez

administratora systemu w zależności od poszczególnych ról użytkowników. Pulpit

użytkownika ma umożliwiać pracę użytkownika w systemie SZPM bez konieczności

opuszczania okien przeglądarki.

1.9. System SZPM ma umożliwiać pracę użytkownika biznesowego w sieci lokalnej oraz za

pomocą Internetu poprzez dedykowane rozwiązanie klasy VPN posiadane przez

Muzeum, zarówno na komputerach osobistych jak i na urządzeniach mobilnych

(Android, iOS).

1.10. System SZPM ma umożliwiać użytkownikom logowanie na indywidualne konta za

pomocą konta Active Directory - loginu i hasła użytkownika sytemu Windows (za

pomocą protokołu LDAP) oraz zabezpieczenie transmisji danych certyfikatem TLS 1.2.

1.11. System SZPM ma mieć możliwość integracji z różnymi dostawcami kwalifikowanego

podpisu elektronicznego oraz integrację z profilem zaufanym wraz z usługami ePUAP.


Strona 4 z 52

1.12. System ma być kompatybilny z używaną przez Zamawiającego do kwalifikowanego

podpisu elektronicznego aplikacją Szafir, dostarczaną przez KIR S.A. (obsługującą

formaty podpisów XAdES, PAdES, CAdES) oraz innymi aplikacjami dostępnymi na rynku

polskim na moment oddania systemu do eksploatacji. System ma mieć możliwość

wstawienia na wydruku lub podglądzie podpisanego dokumentu symbolu graficznego z

informacją przez kogo i z jaką datą dokument został podpisany.

1.13. System SZPM ma być zintegrowany z aktualnie wykorzystywanym przez Zamawiającego

serwerem poczty IBM Lotus Domino (nadawanie, odbieranie poczty, wprowadzanie i

czytanie danych z kalendarza) oraz mieć możliwość integracji z serwerem Microsoft

Exchange 2019 lub nowszym aktualnym na moment oddania systemu do eksploatacji w

przyszłości.

1.14. System SZPM ma posiadać repozytorium dokumentów (bazę wiedzy) w postaci

archiwum miejscowego, programowo zabezpieczonego przed usuwaniem i dodawaniem

treści za pomocą systemu uprawnień użytkowników. Repozytorium musi posiadać

możliwość wyszukiwania pełnotekstowego, edycji zamieszczonych jak i dodawania

nowych treści. Repozytorium musi posiadać możliwość budowania struktury zgodnej z

JRWA, możliwość dodawania metadanych dokumentów, podglądu oraz udostępniania

dokumentów.

1.15. System SZPM musi posiadać mechanizm wersjonowania plików (dokumentów) oraz co

najmniej możliwość sekwencyjnej pracy użytkowników na tych samych plikach.

1.16. Wymagane przez Zamawiającego oprogramowanie bazodanowe to MS SQL, PostgreSQL

lub równoważne, tzn. musi spełniać następujące warunki:

1) Baza danych umożliwia wykorzystanie 16 GB ram i 8 rdzeni procesora

2) Silnik bazy danych obsługuje bazy o wielkości co najmniej 15 TB

3) Bez ograniczeń ilości użytkowników bazy

4) Automatyczne tworzenie backup z poziomu bazy danych z wykorzystaniem

dziennika wbudowanego w silnik bazy danych

5) Obsługa wielu rdzeni procesora w pojedynczym zapytaniu

6) Wsparcie obsługi bazy danych w pamięci (In-Memory Database)

7) Praca systemu w technologii bazodanowej o następujących cechach:

transakcyjna i relacyjna baza danych wyposażona w zintegrowany system

zarządzania (RDBMS)

8) Przetwarzanie transakcyjne wg reguł ACID (Atomicity, Consistency,

Independency, Durability) z zachowaniem spójności

9) Możliwość współpracy bazy danych z różnymi platformami sprzętowymi

oraz systemami operacyjnymi (min. MS Windows, Linux)

10) Możliwość wykonywania niektórych operacji związanych z utrzymaniem

bazy danych bez konieczności pozbawienia dostępu użytkowników do danych. W

szczególności dotyczy to tworzenia/przebudowywania indeksów oraz procesu

backupu.

11) System RDBMS zapewnia wsparcie dla XML

12) Możliwość podłączania się do bazy danych przy użyciu standardu ODBC

13) System RDBMS zapewnia mechanizm wyzwalaczy (triggers) i procedur

wbudowanych (stored procedures)


Strona 5 z 52

14) Mechanizm wyzwalaczy (triggers) uwzględnia możliwość ich uruchomienia

dla każdego wiersza (each row) lub całości polecenia (statement)

15) System RDBMS zapewnia schemat blokowania (lock) tabel na poziomie

wierszy

16) System RDBMS posiada mechanizm zachowywania więzów integralności

danych z kaskadowym usuwaniem i modyfikacją rekordów

17) Możliwość wykonywania kopii online bez konieczności przerywania

działania systemu

18) Możliwość konfiguracji harmonogramu i parametrów wykonywania kopii

bezpieczeństwa systemu komputerowego

19) Licencja na nieograniczoną liczbę połączeń do bazy danych (nie

ogranicza liczby połączeń do bazy danych)

20) Baza danych zapewnia integralność danych, a w szczególności:

a) integralność danych i transakcji na poziomie bazy danych i aplikacji,

b) efektywny i bezbłędny dostęp użytkowników i procesów do wspólnych danych,

c) bieżącą kontrolę poprawności wprowadzanych danych

21) Monitorowane są w logach serwera wszystkie zmiany w bazie danych,

dokonywane z poziomu aplikacji

22) Dostarczona baza danych nie może być związana z konkretnym sprzętem

(OEM).

23) Baza danych umożliwia szyfrowanie plików i backupów

24) Licencja bazy danych nie może być specyficzna tylko dla aplikacji, ma być otwarta.

1.17. Dostarczony i utworzony system SZPM musi spełniać minimalne wymagania dotyczące

wydajności, które zostaną potwierdzone w wyniku przeprowadzonych testów

akceptacyjnych (w tym wydajnościowych).

(Poniżej wymagania wydajnościowe oraz sposób prowadzenia testów wydajności).

1.17.1. Formularze operacyjne powinny prezentować wymagane dane w ciągu najwyżej 3s

(czas zrealizowania złożonych operacji, np. walidacyjnych, bądź wyświetlania

raportów – do ustalenia na etapie wdrażania, w zależności od złożoności operacji).

1.17.2. Wydajność procesowania: 2000 tranzycji stanu procesu (przejść pomiędzy stanami

logicznymi procesów) w ciągu godziny.

1.17.3. Wyświetlanie u użytkownika systemu SZPM wyników wyszukiwania

pełnotekstowego dokumentu z bazy zawierającej 40.000 dokumentów w czasie nie

przekraczającym 4 sek.

1.17.4. Generowanie w systemie raportów dla max. 50 składowych (z bazy zawierającej min.

40.000 dokumentów) w czasie nie przekraczającym 5 sek. (np. lista faktur w zadanym

przedziale czasowym).

1.17.5. W celu wyeliminowania wpływu czynników zewnętrznych na wyniki testów

sprawności, będą one realizowane w jednej sieci lokalnej na dostarczonej przez

Zamawiającego infrastrukturze sprzętowej i na dostarczonym przez Wykonawcę

oprogramowaniu, po załadowaniu przez Wykonawcę wymaganej ilości danych.

1.18. System SZPM musi być skalowalny, tzn. w przypadku konieczności zwiększenia ilości

użytkowników, uruchamianych procesów oraz dokumentów, ma mieć możliwość

obsłużenia zwiększonego zapotrzebowania, przy założeniu przydzielenia dodatkowych


Strona 6 z 52

zasobów (mocy obliczeniowej, pamięci, powiększenia bazy danych, itp.). Opisane wyżej

działania nie mogą mieć negatywnego wpływu na wydajność systemu.

1.19. System SZPM musi mieć możliwość integracji z posiadanymi przez Zamawiającego

systemami: Sage Symfonia ERP oraz rejestracji czasu pracy (UniRCP) Zamawiającego.

Integracja ma zapewnić obustronną wymianę danych pomiędzy systemami.

1.20. System SZPM (w tym zbudowane procesy) musi być zgodny, na dzień przekazania do

eksploatacji, z aktualnie obowiązującymi wymaganiami ustawy z dnia 10 maja 2018 r. o

ochronie danych osobowych (tekst jednolity: Dz. U. z 2018 r. poz. 1000, 1669, z

2019 r. poz. 730.) oraz rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679

z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z

przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych

oraz uchylenia dyrektywy 95/46/WE (RODO).

1.21. System SZPM ma być przystosowany do wykonywania kopii zapasowych oraz

archiwizacji za pomocą zewnętrznych serwerów backup-ów, m. in. Backup Exec 20 firmy

Veritas użytkowany przez Zamawiającego.

2. Wymagania szczegółowe dla Systemu Zarzadzania Procesami w Muzeum

2.1. System Zarządzania Procesami w Muzeum ma mieć możliwość pełnej obsługi struktury

organizacyjnej obowiązującej w Muzeum. Schemat struktury organizacyjnej Muzeum

stanowi załącznik nr 1 do niniejszego OPZ.

2.2. SZPM umożliwi definiowane i obsługę słowników systemowych.

2.3. SZPM umożliwi dokonanie analizy SWOT projektów: tworzenie i prezentację zestawień

analitycznych dotyczących korzyści programowych, wizerunkowych i ekonomicznych

oraz podgląd analizy finansowej.

2.4. Zarządzanie ryzykiem projektu oraz jego poziomami, zawierające możliwość

definiowania zagrożeń oraz mierników.

2.5. Monitoring realizacji zadań zatwierdzonych, w tym statusy spraw, powiązane

dokumenty, z możliwością ich podglądu, postęp w realizacji zadania, stopień

wykorzystania środków finansowych i powiązanych zapotrzebowań.

2.6. System SZPM ma posiadać rejestr osób upoważnionych do przetwarzania danych

osobowych wraz z możliwością automatycznego dodawania do tego rejestru kolejnych

osób dla których generowane są upoważnienia oraz automatycznego usuwania z rejestru

osób których upoważnienia wygasły.

2.7. W ramach obsługi elektronicznego obiegu spraw (dotyczy uruchamianych procesów)

muszą być zagwarantowane co najmniej następujące możliwości:

1) Ustawianie zastępstwa za nieobecnego użytkownika, również w zadanym przedziale

czasowym,

2) Nadawanie uprawnień użytkowników do obsługi procesu,

3) Delegowania zadania (czynności do wykonania w ramach obiegu) do innego

pracownika,

4) Eskalowanie zadań do przełożonego,

5) Możliwość cofnięcia obiegu przy braku akceptacji,

6) Wstawiania komentarzy/notatek do zadań,

7) Konsultowania zadań z innym użytkownikiem,

8) Przekazywanie powiadomień na wskazany adres e-mail,


Strona 7 z 52

9) Wprowadzanie oraz czytanie terminów do/z kalendarza poczty,

10) Definiowanie i kontrola terminów realizacji zadań oraz terminów ostrzegawczych,

11) Definiowanie ram czasowych, harmonogramów, kosztów realizacji i raportów z

efektów realizacji działań,

12) Tworzenie dokumentów na podstawie szablonów i danych zawartych w systemie.

2.8. W realizacji elektronicznego obiegu spraw musi istnieć możliwość definiowania i

wykonywania czynności automatycznych. Wymagane jest zapewnienie mechanizmu

uruchamiania skryptów lub podprogramów, korzystających z danych przetwarzanych w

procesie oraz uzupełniających dane wynikowe procesu.

3. Wymagania dla sytemu klasy BPMS.

3.1. System Zarządzania Procesami Biznesowymi ma dać możliwość modelowania, analizy,

optymalizacji procesów biznesowych a następnie ich realizacji oraz umożliwiać

samodzielne projektowanie procesów przez Zamawiającego.

3.2. Projektowanie, analiza i optymalizacja procesów ma się odbywać w oparciu o notację

BPMN 2.0. Modele procesów (diagramy) mają być dostępne w edytowalnej formie

graficznej.

3.3. System powinien posiadać wielowarstwową, w pełni webową architekturę i oraz składać

się co najmniej z opisanych niżej elementów:

1) Modułu graficznego projektowania diagramów procesowych metodą drag & drop,

2) Kreatora formularzy elektronicznych z podglądem on-line wprowadzanych zmian,

3) Narzędzia do tworzenia oraz konfiguracji raportów i wykresów,

4) Konfigurowalnego pulpitu użytkownika,

5) Modułu zarządzania uprawnieniami użytkowników,

6) Modułu administrowania i konfigurowania sytemu,

7) Elektronicznego repozytorium danych,

8) Silnika procesów biznesowych;

3.4. System BPMS powinien posiadać (co najmniej) niżej opisane funkcjonalności:

1) Definiowania ról i typów uprawnień w obsługiwanych procesach oraz e-repozytorium.

Role dotyczą użytkowników definiowanych na poziomie procesu a typy dotyczą ich

uprawnień do danych zgodnie z modelem RACI.

2) System powinien gwarantować dostępność, integralność, poufność, rozliczalność

przetwarzanych danych.

3) System powinien umożliwiać podgląd pełnej historii zdarzeń - procesów i akcji

wykonanych przez użytkowników.

4) System powinien umożliwiać przygotowanie rejestrów wymaganych danych.

5) Obsługa złożonych reguł i definiowanie reguł biznesowych wpływających na przebieg

procesu.

6) Możliwość wersjonowania zamodelowanych procesów biznesowych oraz instalacji

wybranej wersji jako aktualnej.

7) Możliwość definiowania podprocesów, uruchamiania podprocesów w pętli oraz

dwukierunkowego przekazywania danych pomiędzy procesem nadrzędnym i

podrzędnym.

8) Możliwość importu i eksportu modeli w formacie XPDL.

9) Możliwość wydruku dokumentów, formularzy, diagramów procesów.


Strona 8 z 52

10) Integracja z serwerem pocztowym w zakresie wykorzystania poczty (wiadomości e-

mail) oraz kalendarza.

11) Integracja z posiadanym przez Zamawiającego programami pakietu MS Office (Word,

Excel, Outlook – w tym z kalendarzem).

3.5. System BPMS ma mieć możliwość utworzenia struktury formularzy i raportów

odpowiadających dotychczas stosowanym przez Zamawiającego formularzom systemu

CRM Xpertis prod. Macrologic S.A. Orientacyjne opisy dotychczas stosowanych oraz

oczekiwań dot. przyszłych formularzy i raportów znajdują się w pkt. 7 Opisu Przedmiotu

Zamówienia.

3.6. Możliwość projektowania interfejsu użytkownika.

4. Zakres zamówienia.

4.1. Dostawa licencji oprogramowania nieograniczonych czasowo (perpetual) na co najmniej

200 użytkowników nazwanych systemu BPMS. Licencja ma dać możliwość instalacji

platformy BPMS na maszynie wirtualnej, której zostaną przydzielone wymagane do

sprawnego funkcjonowania zasoby (w tym odpowiednia ilość rdzeni procesora, co

ważne w przypadku jeżeli jest licencjonowana). Licencje mają uprawniać do

uruchomienia platformy BPMS w środowiskach: developerskim (budowanie procesów),

testowym oraz produkcyjnym.

4.2. Wykonawca dostarczy wszystkie dodatkowe licencje na oprogramowanie niezbędne do

działania systemu SZPM (tj. pełnotekstowy OCR, bazy danych, itp.). W przypadku gdy

Wykonawca gwarantuje, że Muzeum jest uprawnione do posiadania licencji EDU, będą

one akceptowane przez Zamawiającego.

4.3. Instalacja i uruchomienie dostarczonego oprogramowania (utworzenie środowiska

developerskiego, testowego oraz produkcyjnego) na wskazanych przez Zamawiającego

serwerach (maszynach wirtualnych).

4.4. Dostawca przy wsparciu Zamawiającego dokona analizy obecnego stanu, dokona

optymalizacji procesów biznesowych Zamawiającego oraz zaproponuje koncepcję

dedykowanej aplikacji biznesowej, architekturę, interfejsy integracyjne zgodnie z

zakresem wdrożenia. Procesy oraz raporty mają być uruchomione w oparciu o platformę

BPMS.

4.5. Budowa aplikacji, w tym zaprojektowanie procesów biznesowych (zgodnie z opisanymi

dalej wymaganiami).

4.5.1. Zaprojektowanie i wdrożenie następujących procesów (w fazach opisanych poniżej, w

pkt. 4.6.):

1) Elektroniczny kancelaryjny obieg pism,

2) Pomysł-projekt-zadanie (w tym zarządzanie ryzykiem),

3) Obieg zapotrzebowań,

4) Zaliczki,

5) Obieg faktur,

6) Obieg umów,

7) Obieg delegacji,

8) Wnioski urlopowe,

9) Tworzenie i korekty budżetu Muzeum,

10) Tworzenie planu zamówień publicznych;


Strona 9 z 52

4.5.2. Zaprojektowanie i wdrożenie następujących raportów:

1) Raport realizacji budżetu,

2) Raport realizacji zamówień publicznych,

3) Sprawozdanie merytoryczne z działalności Muzeum,

4) Raporty dotyczące wymaganych procesów kadrowych.

4.5.3. Utworzenie repozytorium dokumentów elektronicznych oraz „Bazy wiedzy”;

4.6. Harmonogram projektowania i wdrażania.

Zamawiający przewiduje uruchomienie aplikacji biznesowej w następujących fazach:

4.6.1. Faza I: dostawa oraz uruchomienie platformy BPMS oraz dodatkowego

oprogramowania

4.6.1.1. Etap I:

1) Dostawa i uruchomienie platformy BPMS oraz dodatkowego oprogramowania.

2) Wstępna analiza planowanych procesów oraz stworzenie koncepcji architektury

funkcjonalnej systemu SZPM (opisu funkcjonalnego), przygotowanie mapy

działań wraz z harmonogramem prac dla fazy II i III.

3) UWAGA: W przypadku zastosowania metodyki Scrum wsparcie dla Product

Owner-a przy przygotowaniu rejestru produktu, tzw. Product Backlog.

4) Termin zakończenia etapu I: nie później niż 60 dni kalendarzowych od daty

podpisania umowy

4.6.1.2. Etap II:

1) Szkolenia dla administratorów platformy BPMS oraz analityków biznesowych

2) Odbiór I fazy, na podstawie zaakceptowanej przez Zamawiającego koncepcji

wraz z harmonogramem oraz sprawozdania z przeprowadzonych szkoleń,

upoważniający do płatności częściowej (30 % wartości zamówienia). Jest to

płatność za dostawę oraz uruchomienie platformy BPMS oraz dodatkowego

oprogramowania (w tym przekazanie licencji).

3) Termin zakończenia II etapu (fazy I): nie później niż 30 dni kalendarzowych od

zakończenia etapu I fazy I.

4.6.2. Faza II: dostawa Systemu Zarządzania Procesami w Muzeum

4.6.2.1. Etap I:

1) Projektowanie, testowanie i wdrażanie procesów (w modelu iteracyjno-

przyrostowym, o którym mowa w ust. 6):

a) Pomysł-projekt-zadanie (w tym zarządzanie ryzykiem),

b) Obieg zapotrzebowań,

c) Obieg faktur,

d) Obieg umów,

e) Obieg delegacji,

f) Sprawozdanie merytoryczne z działalności Muzeum,

2) Termin zakończenia I etapu 29.05.2020r.

4.6.2.2. Etap II: odbiory i szkolenia dotyczące wdrożonych procesów.

1) Termin zakończenia II etapu (fazy II): 26.06.2020 r.

2) Zakończenie fazy II potwierdzone protokołem odbioru umożliwia dokonanie

drugiej płatności częściowej w wysokości 30 % wartości zamówienia.


Strona 10 z 52

4.6.3. Faza III: wdrażanie Systemu Zarządzania Procesami w Muzeum

4.6.3.1. Etap I:

1) Projektowanie, testowanie i wdrażanie procesów (w modelu iteracyjno-

przyrostowym, o którym mowa w pkt. 6).

a) Elektroniczny kancelaryjny obieg pism,

b) Zaliczki,

c) Wnioski urlopowe,

d) Tworzenie i korekty budżetu Muzeum,

e) Tworzenie planu zamówień publicznych,

f) Raport realizacji budżetu,

g) Raport realizacji zamówień publicznych,

h) Raporty dotyczące wymaganych procesów kadrowych,

2) Termin zakończenia I etapu nie później niż 30.10.2020.

4.6.3.2. Etap II: odbiory i szkolenia dotyczące wdrożonych procesów.

1) Na tym etapie planuje się przeprowadzenie szkoleń dla zaawansowanych

użytkowników systemu, zgodnie z punktem 4.10 OPZ.

2) Termin zakończenia II etapu nie później niż do 18.12.2020 r.

3) Po zakończeniu III fazy nastąpi jej odbiór oraz Całościowy Odbiór Systemu

Zarządzania Procesami w Muzeum, upoważniający do dokonania płatności

końcowej w wysokości 40 % wartości zamówienia.

4.6.4. Faza IV: świadczenie usług gwarancyjnych przez okres wynikający ze złożonej

oferty.

4.7. Przygotowanie narzędzi opartych na dotychczas stosowanej przez Zamawiającego

technologii IBM Lotus Notes Domino a następnie przeniesienie (migracja) danych z

posiadanego przez Zamawiającego systemu CRM Xpertis prod. Macrologic S.A.

(nierelacyjnych baz danych serwera IBM Lotus Domino) do relacyjnej bazy danych SQL

nowego systemu klasy BPMS. Wielkość lotusowych baz danych wraz z repozytorium

plików, przy wykorzystaniu usługi DAOS (Domino Attachment and Object Services)

wynosi około 60 GB. Zakres migracji: co najmniej baza wiedzy, baza kontrahentów,

umowy, zapotrzebowania, faktury z lat 2016-2019, zadania z roku 2019 i

pomysły/projekty zadań na rok 2020, rejestr osób upoważnionych do przetwarzania

danych osobowych.

4.8. Utworzenie interfejsu API służącego do wymiany danych pomiędzy systemem klasy

BPMS a systemem Symfonia ERP (modułem Finansowo – Księgowym, modułem Kadry i

Płace oraz w razie potrzeby innymi modułami Symfonii ERP używanymi przez Muzeum).

Interfejs ma zapewnić, że faktury opisane w procesie obiegu faktur w systemie klasy

BPMS nie będą musiały być po raz drugi opisywane podczas księgowania w Symfonii

ERP. Dane pomiędzy systemami będą wymieniane dwustronnie w przypadku ich

aktualizacji.

4.9. Opracowanie i przekazanie dokumentacji systemu BPMS, dokumentacji procesów,

materiałów szkoleniowych. Dokumentacja ma być udostępniona poprzez bazę wiedzy.

4.10. Przeprowadzenie szkoleń dla 3 grup użytkowników systemu SZPM: administratorów

systemu SZPM, analityków procesów biznesowych oraz zaawansowanych użytkowników

systemu SZPM w siedzibie Zamawiającego. Celem szkoleń dla administratorów systemu


Strona 11 z 52

ma być przekazanie umiejętności konfigurowania systemu BPMS oraz współpracujących

z nim: serwerów webowych, poczty oraz baz danych - ogólnie zarządzania platformą

BPMS oraz systemem SZPM. Celem szkoleń dla analityków procesów ma być przekazanie

umiejętności analizy procesów, umiejętności definiowania i implementacji nowych

procesów na dostarczonej platformie BPMS. Celem szkoleń dla zaawansowanych

użytkowników ma być przekazanie umiejętności pracy w Systemie Zarządzania

Procesami Muzeum (SZPM), w tym w aplikacji przygotowanej na potrzeby obsługi

poszczególnych procesów w oparciu o platformę BPMS. (Określenie zakresów, czasu trwania

szkoleń oraz ilości osób do przeszkolenia.)

4.10.1. Szkolenie dla administratorów systemu dla grupy 2 osób – maksymalnie 1 osoba na

stanowisko komputerowe (3 dniowe x 6 godz. dziennie).

4.10.2. Szkolenie dla analityków procesów da grupy 6 osób – maksymalnie 1 osoba na

stanowisko komputerowe (4 dniowe x 6 godz. dziennie).

4.10.3. Szkolenie dla zaawansowanych użytkowników systemu da grupy do 15 osób –

maksymalnie 1 osoba na stanowisko komputerowe (3 dniowe x 6 godz. dziennie).

4.11. Przygotowanie dokumentacji systemu oraz instrukcji obsługi w postaci elektronicznej w

formie prezentacji oraz pliku pdf, umieszczonej w bazie wiedzy, zawierającej co

najmniej:

1) Wprowadzenie

2) Manuale

3) FAQ

5. Wymagania dotyczące świadczenia usług gwarancyjnych.

5.1. Zakres gwarancji

5.1.1. Zapewnienie poprawności technicznej i merytorycznej wdrożonego sytemu SZPM,

5.1.2. Zapewnienie integralności danych w systemie,

5.1.3. Zapewnienie poprawności technicznej i merytorycznej oraz integralności zasobów

przeniesionych do nowego systemu,

5.1.4. Bezawaryjne i sprawne działanie dostarczonego oprogramowania z zachowaniem

opisanej funkcjonalności i bezpieczeństwa,

5.1.5. Poprawność wdrożonych procedur związanych z eksploatacją całego systemu oraz

jego konserwacją opisanych w dokumentacji systemu przygotowanej przez

Wykonawcę,

5.2. Sposób realizacji usługi serwisu gwarancyjnego

5.3.1. Udostępnienie telefonicznego helpdesku (w dni robocze tj. od poniedziałku do piątku,

za wyjątkiem dni ustawowo wolnych od pracy w godzinach 8:00 – 16:00),

5.3.2. Udostępnienie internetowego helpdesku (całodobowe przyjmowanie zgłoszeń

siedem dni w tygodniu włączywszy dni ustawowo wolne od pracy),

5.3.3. Realizacja zgłoszeń na niżej opisanych warunkach świadczenia usługi serwisowej:

1) Zgłoszenia są kwalifikowane wg opisanych niżej kategorii:

a) Awaria – zdarzenie powodujące zatrzymanie pracy systemu SZPM lub zatrzymanie

działania jednej z kluczowych funkcji systemu, wymagające interwencji w kodzie

źródłowym lub w konfiguracji systemu,


Strona 12 z 52

b) Usterka – wystąpienie niewłaściwego działania pojedynczej funkcjonalności

systemu SZPM dające możliwość realizacji zadań (obiegów) z użyciem innych

funkcjonalności,

c) Pozostałe – utrudnienie w pracy i/lub obsłudze systemu SZPM nie powodujące

generowania i zapisywania błędnych i/lub niepoprawnie przetworzonych danych

w systemie i niepowodujące nieprawidłowej obsługi reguł biznesowych.

2) Usługi serwisu gwarancyjnego mają być realizowane z zachowaniem następujących

zasad i wymagań:

a) Usunięcie awarii w ciągu 8 godzin od zgłoszenia,

b) Usunięcie usterki w ciągu 3 dni roboczych od zgłoszenia,

c) Wykonanie prac pozostałych (o ile zgłoszenie nie było wskazaniem błędnego

działania systemu SZPM ) w ciągu 7 dni od zgłoszenia.

3) W przypadku naprawy oprogramowania, w ramach gwarancji, na czas napraw

zostanie dostarczone i uruchomione równoważne oprogramowanie zastępcze.

4) Wykonawca zobowiązany jest do dostarczania Zamawiającemu poprawek lub

nowych, ulepszonych wersji rozwiązań pozbawionych wad i usterek wynikłych ze

zgłoszonych niedoskonałości rozwiązania. Termin dostarczania poprawek lub

nowych, ulepszonych wersji rozwiązań wynikać ma z klasyfikacji zgłoszeń oraz

poczynionych między Zamawiającym i Wykonawcą ustaleń, co do sposobu ich

usunięcia.

5) Wykonawca zobowiązany jest w okresie trwania gwarancji do informowania

Zamawiającego o nowych, ulepszonych wersjach rozwiązań rozwijanych przez

Wykonawcę (wraz z listą zmian).

6) W przypadku niedostępności usługi helpdesku z powodu awarii jako datę i czas

zgłoszenia przyjmuje się termin wysłania zgłoszenia innym kanałem (mail, list) na

dane kontaktowe Wykonawcy posiadane przez Zamawiającego.

6. Wymagania w zakresie zarządzania projektem oraz komunikacji.

6.1. W związku z koniecznością dostosowania projektowanych w systemie procesów

biznesowych do wypracowanej przez Muzeum metodyki zarządzania projektami

(zadaniami) przy jednoczesnej konieczności przeprowadzenia optymalizacji procesów

przez Wykonawcę zakłada się ich wdrożenie przy zastosowaniu metod zwinnych (Agile).

W związku z powyższym w ramach niniejszego OPZ przygotowano ogólne opisy

procesów zawierające wymagania Zamawiającego dot. ich przebiegu oraz opisy

oczekiwanych efektów, a także parametry pozwalające na oszacowanie przez

Wykonawcę pracochłonności wdrażanych procesów. Załączone w punkcie 7 opisy dają

możliwość dokonania optymalizacji oraz nadania ostatecznego kształtu procesu na

etapie wdrożenia. Powyższa uwaga dotyczy analogicznie generowanych przez system

BPMS raportów.

6.2. Zaprojektowanie oraz wdrożenie procesów będzie realizowane przez zespoły

projektowe składające się z przedstawicieli Wykonawcy oraz Zamawiającego.

6.2.1. W skład zespołów wejdą po stronie Wykonawcy:

1) kierownik projektu (w przypadku zastosowania metodyki Scrum – kierownik prac –

Scrum Master),

2) analitycy biznesowi oraz wdrożeniowcy, w razie potrzeby programiści.


Strona 13 z 52

6.2.2. Po stronie Zamawiającego:

1) informatycy Muzeum,

2) właściciele poszczególnych procesów,

3) właściciel produktu (Product Owner).

6.3. Wyniki poszczególnych iteracji (przebiegów) zatwierdzane będą przez nadzorującego

wdrożenie ze strony Muzeum właściciela produktu (Product Owner-a). Praca zespołów

będzie się składała z następujących etapów:

1) planowanie,

2) projektowanie,

3) programowanie,

4) testowanie,

5) wdrożenie,

6) informacja zwrotna;

6.4. Zespół wykona, nie więcej niż 5 iteracji dla każdego procesu. Iteracje uznaje się za

zakończoną w momencie uwzględnienia przez Wykonawcę uwag Zamawiającego

zawartych w informacji zwrotnej, co znajdzie potwierdzenie w protokolarnym

zakończeniu poprzedniej iteracji. Każda iteracja kończy się protokołem uzgodnień

(Sprint Backlog), zatwierdzanym przez obie strony – Zamawiającego i Wykonawcę, które

muszą zostać uwzględnione w kolejnej iteracji, na etapie planowania. Iteracja może

zostać zakończona w każdym momencie na podstawie zatwierdzonego obustronnie

protokołu uzgodnień, pod warunkiem osiągnięcia zakładanych przez Zamawiającego

efektów dla danego procesu.

6.5. Spotkania projektowe będą odbywać się w siedzibie Zamawiającego lub w miejscu

określonym przez właściciela produktu.

6.6. Spotkania projektowe w zależnie od potrzeby będą miały status:

1) spotkań analitycznych mających na celu iteracyjne budowanie produktu w oparciu o

analizę biznesową procesu będącego przedmiotem zamówienia i powinny być

organizowane nie rzadziej niż raz na dwa tygodnie. Osobami wymaganymi na tych

spotkaniach są analitycy biznesowi oraz wdrożeniowcy, w razie potrzeby programiści

po stronie Wykonawcy oraz informatycy Muzeum, właściciele poszczególnych

procesów po stronie Zamawiającego.

2) spotkań informacyjno-uzgodnieniowych mających na celu przekazanie aktualnego

stanu realizowanych prac i powinny być organizowane nie rzadziej niż raz na dwa

tygodnie. Osobami wymaganymi na tych spotkaniach są kierownik prac ze strony

Wykonawcy, właściciel produktu ze strony Zamawiającego, a także inne osoby przez

nich wskazane.

6.7. Komunikacja w ramach zespołu projektowego będzie realizowana za wiedzą właściciela

produktu ze strony Zamawiającego oraz kierownika prac ze strony Wykonawcy,

poprzez:

1) spotkania projektowe z których będą sporządzane protokoły zatwierdzane przez obie

strony (Wykonawcę i Zamawiającego),

2) drogą elektroniczną, przy czym oprócz wysyłania kopii do osób, za wiedzą których

odbywa się komunikacja, temat wiadomości opatrzony jest symbolem projektu

(znakiem sprawy),


Strona 14 z 52

3) korespondencję w formie pisemnej (opatrzoną znakiem sprawy z dopiskiem: „SZPM -

Muzeum Pałacu Króla Jana III w Wilanowie”),

4) w przypadku komunikacji prowadzonej drogą telefoniczną, wymagane jest

potwierdzenie ustaleń za pomocą opisanych wyżej form komunikacji.

6.8. Wykonawca zobowiązany jest na bieżąco informować Zamawiającego o wszelkich

zagrożeniach związanych z realizacją przedmiotu zamówienia.

6.9. Prace wdrożeniowe systemu SZPM zostaną zakończone przeprowadzeniem przez

Wykonawcę oraz Zamawiającego testów akceptacyjnych.

7. Ramowe opisy poszczególnych procesów oraz raportów:

UWAGA: Opisy zawierają orientacyjne wymagania Zamawiającego dot. przebiegu procesów oraz wskazania dot.

oczekiwanych efektów a także parametry pozwalające na oszacowanie przez Wykonawcę pracochłonności wdrażanych

procesów. Zamawiający zakłada dokonanie przez Wykonawcę optymalizacji oraz nadanie ostatecznego kształtu procesu

na etapie wdrożenia systemu SZPM. Powyższa uwaga dotyczy analogicznie generowanych przez system BPMS raportów.

7.1. Elektroniczny kancelaryjny obieg pism:

Proces obiegu dokumentów ma współpracować z mechanizmem rozpoznawania tekstu

(pełnotekstowym oprogramowaniem OCR), co ma umożliwiać m.in. rozpoznanie numeru

pisma przychodzącego oraz przeniesienie go do udzielanej odpowiedzi. Zakłada się obieg

ok. 5 tys. pism rocznie.

TEMAT OBIEG AKCEPTACJI OPIS

PISMA

PRZYCHODZĄCE

Dział Administracji wprowadza

nowe pismo:

1. Uzupełnia rubryki (lub nanosi

poprawki):

- numer korespondencyjny

generowany automatycznie, np. 1,

2,3,

- powiązanie z kontrahentem

wybieranym z listy (lub nowym

rejestrowanym na liście),

- numer zewnętrzny pisma

(raczej/lub znak pisma

zewnętrznego),

- data wpływu pisma do Muzeum,

- data z pisma,

- temat przewodni,

- formę dostarczenia: zwykła,

polecona, polecona za

potwierdzeniem odbioru, kurier,

osobiście)

- wstawia skan pisma (możliwość

skanowania z programu)

- wstawia skany załączników.

2. Wysyła pismo do Dyrektora lub

1. Przychodzące pisma powinno

się dać segregować według:

numeru korespondencyjnego,

firmy/adresata/kontrahenta,

numeru zewnętrznego pisma,

daty wpływu pisma do

Muzeum, daty z pisma,

Jednolitego Rzeczowego

Wykazu Akt.

2. Rejestr pism przychodzących

można w każdej chwili

wydrukować.


Strona 15 z 52


Kierownika działu o ile nie jest

wymagana dekretacja Dyrektora.

3. Dyrektor lub Kierownik działu

deleguje pismo do pracownika

odpowiedzialnego za daną sprawę.

4. Pracownik (osoba

odpowiedzialna) może powiązać

pismo z zadaniem i działaniem ,

następnie rejestruje sprawę w spisie

spraw nadając jej znak wg.

Jednolitego Rzeczowego Wykazu

Akt (tutaj NL.345.1-1.2018).

ODPOWIEDŹ NA

PISMO

PRZYCHODZĄCE

Pracownik działu otwiera pismo

przychodzące, na które chce

odpowiedzieć i wybiera okienko

odpowiedź.

1. Uzupełnia rubryki:


generowany automatycznie (taki

sam jak numer pisma

przychodzącego łamany na numer

odpowiedzi np. 3/1,

- pracownik (osoba


pismo z zadaniem i działaniem,

2. Nadaje mu znak wg. Jednolitego

Rzeczowego Wykazu Akt (np.

NL.345.1-1.2018.MM – numer

obowiązkowy, wymuszany przez

system, wszystkie składowe tego

znaku są zmieniane i różne w

różnych działach muzeum),

- data z pisma,

- treść,

- wstawia pismo w Word, które

można edytować.

3. Wysyła pismo do Kierownika

Działu (podczas wysyłki na pismo

wstawiany (przenoszony) jest

automatycznie znak pisma wg.

Jednolitego Rzeczowego Wykazu

1. Kierownik Działu, Dyrektor i

jego zastępcy powinni mieć

możliwość edycji pism.

2. Wychodzące pisma powinny

się segregować według:





Muzeum, daty z pisma, treści,

Jednolitego Wykazu Akt.

3. Rejestr pism można w każdej

chwili wydrukować.


Strona 16 z 52


Akt – j.w. NL.345.1-1.2018.MM).

4. Kierownik Działu ewentualnie

nanosi poprawki, akceptuje pismo i

przesyła je do Dyrektora lub jego

zastępców, lub odrzuca do

pracownika odpowiedzialnego za

daną sprawę, który je poprawia i

uruchamia ponownie obieg.

5. Dyrektor ewentualnie nanosi

poprawki, akceptuje pismo i odsyła

je do Sekretariatu do wydrukowania

lub odrzuca pismo do pracownika

odpowiedzialnego za daną sprawę,

który je poprawia i uruchamia

ponownie obieg.

5a. Dyrektor podpisuje pismo

elektronicznie i odsyła do

działu/pracownika prowadzącego

sprawę

5b. Osoba prowadząca sprawę

wysyła dokument w postaci

elektronicznej za pomocą e-usługi

(np. e-mail, ePUAP, platforma e-

Zamówień, itp.)

6. Osoba prowadząca sprawę

wstawia skan podpisanego przez

Dyrektora Pisma (możliwość

skanowania z programu lub

wstawienia skanu), uzupełnia formę

przesyłki (zwykła, polecona,

polecona za potwierdzeniem

odbioru, kurier, e-mail, osobiście) i

przesyła je do Działu Administracji

(podpisane pismo osobiście

dostarcza do Dział Administracji,

który je wysyła)

7. Dział Administracji uzupełnia:

datę wysłania pisma i kończy obieg.

Uwaga dot. 5a.

Dyrektor powinien mieć

możliwość przesłania pisma do

kontrasygnaty do głównego

księgowego lub podpisu przez

zastępców.

Uwaga dot. 5b.

Osoba wysyłająca pismo w

formie elektronicznej kończy

jego obieg w systemie.


Strona 17 z 52


PISMA WYCHODZĄCE

Pracownik wprowadza nowe pismo.

1. Uzupełnia rubryki:


generowany automatycznie np. 1, 2,

3 ...

- pracownik (osoba


pismo z zadaniem i działaniem,

- rejestruje nową sprawę w

wewnętrznym spisie spraw i nadaje

mu znak wg. Jednolitego

Rzeczowego Wykazu Akt (np.

NL.345.1-1.2018.MM – numer

obowiązkowy, wymuszany przez

system, wszystkie składowe tego

znaku są zmieniane i różne w

różnych działach muzeum),

- data z pisma,

- temat przewodni,

- wstawia pismo w Word, które

można edytować,

2. Wysyła pismo do Kierownika

Działu (podczas wysyłki, na pismo

wstawiany jest automatycznie znak

pisma (sprawy) wg. Jednolitego

Rzeczowego Wykazu Akt – np.

NL.345.2-1.2018.MM).

3. Kierownik Działu ewentualnie

nanosi poprawki, akceptuje pismo i

przesyła je do Dyrektora lub jego

zastępców, lub odrzuca do

pracownika odpowiedzialnego za

daną sprawę, który je poprawia i

uruchamia ponownie obieg.

4. Dyrektor ewentualnie nanosi

poprawki, akceptuje pismo i odsyła

je do Sekretariatu do wydrukowania

lub odrzuca pismo do pracownika

odpowiedzialnego za daną sprawę,

który je poprawia i uruchamia

ponownie obieg.

1. Kierownik Działu, Dyrektor i

jego zastępcy powinni mieć

możliwość edycji pism.

2. Wychodzące pisma powinny

się segregować według:





Muzeum, daty z pisma,

Jednolitego Rzeczowego

Wykazu Akt.

3. Rejestr pism wychodzących

można w każdej chwili

wydrukować.


Strona 18 z 52


5. Osoba odpowiedzialna wstawia

skan podpisanego przez Dyrektora

Pisma (możliwość skanowania z

programu), uzupełnia formę

przesyłki (zwykła, polecona,

polecona za potwierdzeniem

odbioru, kurier, e-mail, osobiście) i

przesyła je do Działu Administracji

(podpisane pismo osobiście

dostarcza do Dział Administracji,

który je wysyła)

5a. Dyrektor podpisuje pismo

elektronicznie i odsyła do

działu/pracownika prowadzącego

sprawę

5b. Osoba prowadząca sprawę

wysyła dokument w postaci

elektronicznej za pomocą e-usługi

(np. e-mail, ePUAP, platforma e-

Zamówień, itp.)

6. Dział Administracji uzupełnia:

datę wysłania pisma i kończy obieg.

Uwaga dot. 5a.

Dyrektor powinien mieć

możliwość przesłania pisma do

kontrasygnaty do głównego

księgowego lub podpisu przez

zastępców.

Uwaga dot. 5b.

Osoba wysyłająca pismo w

formie elektronicznej kończy

jego obieg w systemie.

7.2. Pomysł-projekt-zadanie:

Pomysł -> Projekt zadania -> Zadanie


Strona 19 z 52

Etap I: Tworzenie nowego pomysłu:

1) Zakładka/karta „Założenia”

UWAGA: Zrzuty ekranu zostały udostępnione poglądowo. Nie należy się sugerować ich postacią

graficzną.

Autor pomysłu - Imię i nazwisko autora, przypisywane automatycznie po stworzeniu karty

pomysłu. Domyślnie kuratorem jest osoba tworząca pomysł, można dodać również opcję

wyboru kuratora

z rozwijalnej listy (opcję zmiany kuratora posiada jedynie administrator systemu oraz

użytkownicy

z rozszerzonymi uprawnieniami jak dyrekcja).

Temat - Tytuł pomysłu, jest nazwą która później przechodzi do projektu i zadania.

Powiązania budżetowe – Tworzymy powiązanie z odpowiednim działem oraz pozycją planu

finansowego (budżet musi zostać uprzednio utworzony). System umożliwia powiązanie w

późniejszej fazie, np. w projekcie zadania, stąd brak wymagalności uzupełnienia.

Kod budżetu zadaniowego państwa:

(do wyboru 4 opcje edytowalne przez administratora)

9.1.1.2 – Kod budżetu zadaniowego państwa

9.1.1.3 – Projekt NFOŚ

9.1.1.4 – Kod budżetu zadaniowego państwa

9.1.4.2. – Inwestycje – Wzmocnienie opieki nad zasobami zabytkowymi

Opis syntetyczny - krótki opis do max 1500 znaków zarysu pomysłu (wyższa ilość

przepuszczamy z komunikatem o przekroczeniu).


Strona 20 z 52

Ramy czasowe – czas trwania realizowanego projektu, wybór z kalendarza.

Rok budżetowy – wybieramy czy projekt realizowany będzie w roku bieżącym bądź kolejnym.

Planowany koszt całkowity – wprowadzamy kwotę.

Wkład własny muzeum – wprowadzamy kwotę.

Partnerzy/Sponsorzy/Umowy barterowe – pole nie wymaga uzupełnienia.

2) Zakładka/karta „Analiza”


Strona 21 z 52

Analiza SWOT

MOCNE STRONY - wpisujemy 3 zalety, przewagi, atuty pomysłu

SŁABE STRONY - wpisujemy 3 wady, bariery, słabości pomysłu

SZANSE - 3 okoliczności stwarzające szansę korzystnej zmiany

ZAGROŻENIA - 3 okoliczności stwarzające niebezpieczeństwo niekorzystnej zmiany

(Każda z rubryk analiza SWOT powinna zostać uzupełniona, co najmniej jednym wpisem).

Korzyści z realizacji

Korzyści programowe: Dla Muzeum to elementy lub efekty pomysłu, które mają związek ze

statutową działalnością Muzeum. Dla odbiorców to te, które skierowane są wprost do

odbiorców oferty Muzeum (zwiedzających, gości konferencji, projektów naukowych itd.)

Korzyści wizerunkowe to elementy lub efekty pomysłu, które będą widoczne dla

zwiedzających Muzeum lub przewiduje się ich pozytywny wpływ np. na opinię publiczną na

temat Muzeum.

Korzyści ekonomiczne to wszystkie elementy lub efekty realizacji pomysłu generujące

dodatkowy przychód do muzeum lub stanowiące potencjalne źródło pozyskiwania środków.

Korzyści dla pracowników Muzeum realizujących zadanie: elementy, które pomagają w

rozwoju pracowników w Muzeum.

(Co najmniej jeden z elementów powinien zostać uzupełniony).

3) Zakładka/karta „Ryzyka”

Dodajemy ryzyka wg gotowych wartości słownikowych. Potrzebna jest wcześniej utworzona

lista możliwych kategorii ryzyka.


Strona 22 z 52

“Miernik realizacji zadania” - wybieramy z listy słów kluczowych. Miernik jest

zidentyfikowany w celu strategicznym dla zadania.

“Zidentyfikowane ryzyko” - wybieramy z listy słów kluczowych.

“Przyczyna ryzyka” - wpisujemy przewidywaną przyczynę.

Zaznaczamy na skali “Prawdopodobieństwo ryzyka” oraz “Skutek wystąpienia ryzyka”

(“Poziom istotności ryzyka” oblicza się automatycznie). Skala od 1 do 5.

“Osoby odpowiedzialne za zarządzanie ryzykiem” - wybieramy z rozwijanej listy.

“Planowana metoda przeciwdziałania” (wystąpieniu ryzyka) – uzupełniamy własnymi

słowami.

Poniżej zaprezentowano rozszerzoną analizę ryzyka, planowaną przez Zamawiającego.

ZIDENTYFIKOWANE

ŹRÓDŁA RYZYKA [do wyboru z listy] 1. LUDZIE 2. SPRZĘT IT

3. POZOSTAŁY

SPRZĘT 4. PROCEDURY 5. INNE

ZIDENTYFIKOWANE

RYZYKA

do wyboru z listy +

pole opisowe (zgodnie

z zidentyfikowanymi

źródłami) 1.1 2.1 3.1 4.1 5.1

1.2 2.2 3.2 4.2 5.2

… … … … …

WŁAŚCICIEL

RYZYKA

Kierownik Właściwy /

Dysponent Planu -

Imię i Nazwisko


Strona 23 z 52

SZACOWANIE

RYZYKA

dla każdego ryzyka

możliwość wyboru

poziomu ze skali 2-4-6

: a) P

prawdopodobieństwa,

b) W wpływu; iloczyn

powyższych = I -

ISTOTNOŚĆ RYZYKA

JAKO WSKAŹNIK

KATEGORIA RYZYKA -

wybór z listy: Z -

zewnętrzne/ W -

wewnętrzne; F-

finansowe/ N/F

niefinansowe, mogące

przerodzić się w

finansowe

IDENTYFIKACJA

RYZYK

KLUCZOWYCH -

ryzyka o istotności

24 i 36 -

komunikat o

nieakceptowalnym

poziomie ryzyka

dla zadania -

monit z prośbą o

rekomendację dot.

dalszego

postępowania do

KS (TAK/NIE)

widok:

uszeregowanie

rankingowe

KOSZTY/ SKUTKI:

skutki niefinansowe

oraz finansowe w

przypadku

wystąpienia ryzyka

(2 pola opisowe)

SPOSÓB REAKCJI

NA RYZYKO

do wyboru ze

słownika

1. AKCEPTACJA

RYZYKA

2. TRANSFER

RYZYKA

3. REDUKCJA

RYZYKA

4.

PRZECIWDZIAŁANIE 5. UNIKANIE

REAKCJA NA RYZYKO

POLE OPISOWE, dla

każdego

zidentyfikowanego

ryzyka; jeśli zadania z

ryzykiem o poziomie

24 / 36 zostały

skierowane do

realizacji - wymóg

wyjątkowo

pogłębionego planu

reakcji na ryzyko

PLANOWANE

MECHANIZMY

KONTROLI [do wyboru z listy] 1. PERSONALNE

2.

BIUROKRATYCZNE 3. WYDAJNOŚCIOWE

[pole opisowe do

uzupełnienia] … … …

(aplikowane do źródeł

ryzyka)

*możliwość

generowania

raportów z księgi

ryzyka

LISTA POTENCJALNYCH RYZYK OPERACYJNYCH

NIEINFORMATYCZNYCH LISTA POTENCJALNYCH RYZYK OPERACYJNYCH INFORMATYCZNYCH

1. Nieautoryzowane operacje 1. Destrukcja zbiorów i programów poprzez zewnętrzny impuls

elektromagnetyczny

2. Zapisanie operacji niezgodnie z regulacjami 2. Celowe uszkodzenie urządzeń

3. Nieautoryzowany dostęp pracownika 3. Przypadkowe, niecelowe uszkodzenie urządzeń

4. Kradzież 4. Użycie oprogramowania w nieautoryzowany sposób

5. Fałszerstwo dokumentów 5. Korzystanie z urządzeń w nieuprawniony sposób

6. Kradzież informacji 6. Nieuprawnione użycie nośnika pamięci

7. Przyjęcie fałszywego lub sfałszowanego dokumentu 7. Użycie złośliwego oprogramowania

8. Sprzeniewierzenie aktywów 8. Korzystanie z nielicencjonowanego oprogramowania


Strona 24 z 52

9. Odszkodowania dla pracowników 9. Dostęp do systemu przez nieuprawnionych użytkowników

10. Inne odszkodowania 10. Nielegalne użycie oprogramowania

11. Ujawnienie danych osobowych pracowników 11. Podszycie się pod uprawnionego użytkownika

12. Nieobecność pracowników w pracy 12. Trudności z wprowadzaniem informacji do systemu

13. Niedobór pracowników 13. Nieskuteczne połączenia telefoniczne

14. Nieobecność kluczowych pracowników w pracy 14. Nieskuteczne połączenia internetowe

15. Wypadki pracowników 15. Wyłudzenie nośników kluczy

16. Wypadki klientów 16. Wyłudzenie haseł dostępu

17. Ujawnienie danych osobowych klientów – nieumyślne 17. Włamanie do systemu

18. Ujawnienie danych osobowych klientów – celowe 18. Defekty oprogramowania

19. Ujawnienie informacji – nieumyślne 19. Katastrofy budowlane

20. Ujawnienie informacji – celowe 20. Wybuch bomby

21. Ujawnienie informacji niejawnych – nieumyślne 21. Niewłaściwe warunki eksploatacji urządzeń

22. Ujawnienie informacji niejawnych – celowe 22. Zmiany napięcia sieci

23. Nieuprawnione użycie informacji niejawnych 23. Użycie broni

24. Zalania 24. Starzenie się nośników pamięci

25. Pożary 25. Zbieranie się ładunków elektrostatycznych

26. Klęski żywiołowe 26. Błędy i pomyłki użytkowników

27. Nieumyślne uszkodzenie sprzętu 27. Błędy i pomyłki administratorów

28. Celowe uszkodzenie sprzętu 28. Błędy utrzymania

29. Przerwy w dopływie mediów 29. Zaniedbania użytkowników

30. Błędy księgowe 30. Zagubienie nośnika

31. Przelew niewłaściwej kwoty 31. Niewłaściwe zniszczenie nośnika

32. Przelew nie na to konto 32. Szpiegostwo

33. Awarie sprzętu 33. Terroryzm

34. Przeoczenie terminu 34. Wandalizm

35. Opóźnienia 35. Kradzież

36. Zagubienie dokumentacji

37. Zniszczenie dokumentacji

38. Spory sądowe

4) Zakładka/karta „komentarze” – możemy odczytać komentarze osób uczestniczących w obiegu


Strona 25 z 52

Komentarz dodajemy poprzez wybranie „Dodaj komentarz” na pomarańczowym pasku.

Uczestnik w obiegu w momencie akceptacji, zobowiązany jest do pozostawienia komentarza,

które możemy później przejrzeć w powyższej zakładce.

5) Zakładka/karta „Prawa dostępu”.

Zakładka „Prawa dostępu” powinna zostać uzupełniona osobami spośród pracowników

Muzeum, które z punktu widzenia realizacji zadania muszą mieć podgląd lub możliwość edycji

całej karty pomysłu/projektu zadania/zadania. Prawa dostępu do dokumentów powinni mieć

automatycznie przyznane zwierzchnicy osób je tworzących. Osoby, którym Kuratorka lub

Kurator nie nadadzą prawa dostępu do karty, nie będą widziały lub nie będą miały możliwości


Strona 26 z 52

edycji karty pomysłu/projektu zdania/zadania.

Po uzupełnieniu pomysłu uruchamiany jest obieg. Kolejnym wykonawcą w obiegu jest główny

księgowy. W przypadku akceptacji kroku „Rekomendacja głównego księgowego utworzenia

zadania” przechodzimy do akceptacji pomysłu przez Dyrektora a następnie do etapu II jakim jest

projekt zadania. Cały obieg procesu od pomysłu do zadania znajduje się poniżej. (Schemat obiegu procesu pomysł-projekt-zadanie:)


Strona 27 z 52


Strona 28 z 52

Etap II: Projekt zadania:

Po akceptacji pomysłu przez Dyrektora, dokument w obiegu trafia do kuratora (zazwyczaj

inicjator pomysłu). Należy uzupełnić projekt zadania.

Na tym etapie dochodzą nam 3 kolejne zakładki – Projekt zadania, Budżet oraz Komitet

Sterujący.

1. Tworzenie zespołu zadaniowego:


Strona 29 z 52

W celu dodania nowej osoby do zespołu zadaniowego klikamy „Dodaj osobę”. Następnie w oknie

uzupełniamy Odpowiedzialności oraz Uprawnienia danej osoby.

2. Tworzenie działań:

W celu utworzenia nowego działania w ramach projektu zadania klikamy „dodaj działanie”,

która wygląda w następujący sposób:

Uzupełniamy podstawowe pole karty działania wraz z planowaną datą działania. Pole „Efekty

działania” – podstawowe elementy dające się ująć, jako mierzalne wyniki działania. „Opis

działania” – krótki opis przybliżający przebieg i sens działania. Działania powinny zawierać

również wskaźniki.

Karta działania powinna umożliwić szczegółowe opisanie czynności. Np.:

Zawarcie umów – osoba odpowiedzialna, kwota, terminy

Zamówienie cateringu – osoba, kwota, terminy

Itd.


Strona 30 z 52

Dopiero wówczas widać że zadanie zostało zaplanowane i potrzebne kwoty są właściwe.

Dalszy ciąg karty:

Pole informacyjne „Budżet projektu zadania” podaje założony budżet projektu zadania. Część

dotycząca realizacji będzie aktywna na etapie realizacji Zadania.

Zamawiający oczekuje możliwości definiowania oraz prezentacji wskaźników szczegółowych dla

działania.

3. Tworzenie kosztorysu:

Wybieramy „Dodaj pozycję kosztorysu” – otwiera nam się nowa karta:


Strona 31 z 52

Tworzymy powiązanie z utworzonym wcześniej działaniem, po czym uzupełniamy dane

wymagane.

„Rodzaj” wybieramy z listy rozwijalnej:

„Typ wydatku” – wybieramy z listy rozwijalnej typ wydatku ze słownika zamówień

publicznych. Słownik jest dość obszerny, obecnie jest około 300 pozycji.

4. Dodawanie wskaźników:


Strona 32 z 52

Po wybraniu „Dodaj wskaźnik” uruchamia się okienko z listą rozwijalną:

cd:

Przechodzimy do zakładki „Budżet”


Strona 33 z 52

Następnie „Komitet sterujący”:

Przewodniczący KS – kierownik działu

Główny dostawca – kurator

Główny użytkownik – zastępcy dyrektora

Po uzupełnieniu projektu zadania kurator akceptuje obieg. Po zatwierdzeniu obiegu przez

kolejno: przewodniczącego KS, głównego księgowego; dyrektora, projekt zadania przechodzi do

etapu realizacji, czyli zadania.

Etap III - Zadanie


Strona 34 z 52

Kolejnym krokiem jest realizacja zadania przez kuratora. Dochodzi zakładka „Zadanie”, która

pokazuje upływ czasu oraz dokumenty powiązane z zadaniem – zapotrzebowania, umowy oraz

faktury.

----------------------------------------------------------------------------------------------------------------------------

----------

Zadanie realizowane jest zgodnie z wybranym harmonogramem, zazwyczaj do końca roku

kalendarzowego. Planuje się także „megazadanie”, które agregowałyby zadania planowane na

okres kilku lat. Wówczas zadanie to nie podlega procesowi automatycznego przeniesienia do

archiwum po zakończeniu roku budżetowego.

W zakładce „dokumenty powiązane” mamy:

- Zapotrzebowania (filtry: numer systemowy, nr muzeum, kwota netto, wg autora, status, autor,

wg przedmiotu zamówienia, wg numeru muzeum, wg działań, autor)

- umowy (filtry: numer, numer muzeum, termin rozpoczęcia, przedmiot, wg osoby

odpowiedzialnej, wg działań, wg przedmiotu umowy, wg numeru muzeum, rodzaj dokumentu,

tryb, kwota netto, kwota brutto, kontrahent, status)

- dokumenty finansowe (filtry: numer, numer muzeum, numer zewnętrzny, rodzaj dokumentu,

dział, nazwa towaru, cel zakupu, kwota netto, kwota brutto, termin płatności, kontrahent, status,

wg osoby odpowiedzialnej, wg działań, wg nazwy towaru, wg numeru muzeum, wg numeru

zapotrzebowania)

Z poziomu zadania, powinna być możliwość tworzenia raportów nt. zaangażowania budżetu –

wg zapotrzebowań, umów, faktur, wykorzystania założonej kwoty w działaniach oraz informacji


Strona 35 z 52

o poziomie zaangażowania pracowników (ilość dokumentów, czasy realizacji zleconych

zadań/czynności, zaangażowanie budżetu, itd.)

ETAP KOŃCOWY – Zamknięcie zadania

Po realizacji zadania kurator akceptuje krok obiegu, następnie trafia do przewodniczącego KS,

do głównego księgowego, na końcu do dyrektora, który rekomenduje zamknięcie zadania.

Przy projektowaniu procesu pomysł-projekt-zadanie należy uwzględnić późniejsze

zaczytywanie danych do raportu "Sprawozdanie Merytoryczne z działalności Muzeum".

Oczekiwania Zamawiającego dotyczące kierunku rozwoju procesu stanowi załącznik nr 2 do

niniejszego OPZ.

7.3. Obieg zapotrzebowań:

7.3.1. Utworzenie dokumentu:

7.3.1.1. Pola uzupełniane automatycznie:

1) Data utworzenia zapotrzebowania

2) Autor

3) Kod budżetu zadaniowego Państwa – 9.1.1.2 (z możliwością edycji przez

inicjatora)

7.3.1.2. Pola obowiązkowo do uzupełnienia:

1) Szczegółowy opis przedmiotu zamówienia oraz kosztów/stawek

jednostkowych (np. stawki godzinowej w umowach cywilno-prawnych, kosztu

jednostkowego)

2) Cel/przeznaczenie

3) Typ wydatku – wybieramy ze słownika zamówień publicznych (dowolnie

modyfikowanego przez pracownika ds. zamówień publicznych posiadającego

odpowiednie uprawnienia)

4) Jeżeli zaznaczymy checbox „Zapotrzebowane na umowę rozchodową cywilno-

prawną z osobą fizyczną”, wybieramy dodatkowo pomiędzy umową zleceniem a

umową o dzieło.

5) Pozycje zapotrzebowania – Wskazujemy przedmiot oraz kwotę netto, z tego

poziomu umożliwiamy wskazanie, na jaki rok budżetowy pozycja jest

przewidziana oraz powiązanie z odpowiednim zadaniem i działaniem a także

określamy rodzaj wydatku – bieżący lub inwestycyjny.

6) Pole na umieszczenie dodatkowych załączników

7.3.1.3. Pola nieobowiązkowe:

1) Rodzaj zamówienia – wybierany z listy rozwijalnej (dowolnie modyfikowanej

przez pracownika ds. zamówień publicznych posiadającego odpowiednie

uprawnienia). Pole obowiązkowe na kroku obiegu zamówień publicznych.

a) Dostawy - 4-10 pozycji

b) Usługi - 4-10 pozycji

c) Roboty budowlane - 4-10 pozycji

2) Miejsce na załączniki

3) Wydatek zostanie zrealizowany z zaliczki (checkbox)


Strona 36 z 52

4) Powiązuje zapotrzebowanie z firmą lub kontrahentem wybieranym z bazy firm

7.3.2. Obieg zapotrzebowania

1) Po utworzeniu zapotrzebowania inicjator uruchamia obieg, (jeśli inicjatorem jest

kurator przechodzimy do pkt. 3)

2) Akceptacja kuratora zadania

3) Akceptacja dysponenta planu

4) Akceptacja sekcji zamówień publicznych

5) Akceptacja głównego księgowego

6) Akceptacja Dyrektora

7) Zakończenie obiegu, automatyczne nadanie numeru w ewidencji zapotrzebowań oraz

wygenerowanie metryki obiegu.

8) W przypadku braku akceptacji na dowolnym kroku obiegu, zapotrzebowanie wraca

do inicjatora celem uzupełnienia.

7.3.3. Powiadomienia.

Po zatwierdzeniu zapotrzebowania inicjator otrzymuje mailowe powiadomienie.

7.3.4. Możliwość zwiększenia zapotrzebowania przez inicjatora

Cofnięcie obiegu do kuratora zadania oraz ponowna akceptacja całego obiegu.

7.3.5. Inne

Prawa dostępu – inicjator lub wykonawcy w obiegu mogą dopisać osobę lub dział

Komentarze

Możliwość podglądu dokumentów powiązanych z zapotrzebowaniem (umowy,

faktury).

7.4. Zaliczki:

7.4.1. Wystąpienie o zaliczkę.

Warunkiem wystąpienia o zaliczkę jest zatwierdzone zapotrzebowanie.

7.4.2. Pola uzupełniane automatycznie

Imię i nazwisko inicjatora

Stanowisko służbowe

Data utworzenia.

7.4.3. Pola do uzupełnienia

Nazwa przedmiotu, materiału lub usługi

Ilość

Kwota

W przypadku Działu Obsługi Publiczności możliwość wyboru czy zaliczka jest

jednorazowa czy dotyczy pogotowia kasowego (brak zapotrzebowania).

Powiązanie z zadaniem, działaniem, umową, zapotrzebowaniem, sprawą.

7.4.4. Obieg zaliczki

Po uzupełnieniu inicjator uruchamia obieg

Akceptacja dysponenta planu

Akceptacja głównego księgowego

Akceptacja dyrektora (generowany jest wniosek)

Zatwierdzenie w księgowości gdzie realizowany jest przelew


Strona 37 z 52

Rozliczenie zaliczki przez inicjatora

Akceptacja rozliczenia przez dysponenta planu

Akceptacja przez zamówienia publiczne

Akceptacja głównego księgowego

Akceptacja dyrektora

Rozliczenie w księgowości, generowanie druku rozliczenia zaliczki oraz

automatyczny wpis do rejestru zaliczek przy zakończeniu obiegu.

Podobnie jak w przypadku każdego obiegu generowana jest metryka.

7.4.5. Powiadomienia

Inicjator otrzymuje powiadomienie mailowe o akceptacji wniosku

Inicjator otrzymuje powiadomienie mailowe o rozliczeniu zaliczki

7.4.6. Inne

Możliwość dodawania faktur na etapie Rozliczenia zaliczki przez inicjatora. Pole

forma płatności powinno zostać uzupełnione automatycznie „opłacono z zaliczki”,

bez możliwości edycji. Powiązanie faktury powinno zostać pobrane z

zapotrzebowania.

W zapotrzebowaniach znajduje się checkbox „Wydatek zostanie zrealizowany z

zaliczki”. Po zatwierdzeniu takiego zapotrzebowania, zostanie wygenerowany

wniosek o zaliczkę. Taki wniosek nie będzie przechodził całego obiegu, po

automatycznym wygenerowaniu i uruchomieniu obiegu przez inicjatora, zostanie

przesłany do akceptacji dyrektora, po czym do księgowości. Proces rozliczenia

zaliczki pozostaje bez zmian.

7.5. Obieg faktur:

Proces obiegu faktur ma współpracować z mechanizmem rozpoznawania tekstu

(oprogramowaniem OCR), co ma umożliwiać rozpoznanie numeru faktury oraz ręczne

(lub automatyczne) przeniesienie go do formularza opisu faktury. Zakłada się obieg ok. 5

tys. faktur rocznie.

7.5.1. Dodawanie faktury

Numer porządkowy generowany jest automatycznie wraz z utworzeniem nowej

faktury.

Osoba wprowadzająca fakturę uzupełnia pola: rodzaj dokumentu, osoba

odpowiedzialna oraz skan faktury. Następnie robi powiązanie faktury z firmą lub

kontrahentem wybieranym z bazy firm (baza kontrahentów zintegrowana z

Symfonią). Po zapisaniu wysłane jest powiadomienie do osoby odpowiedzialnej,

która uzupełnia pozostałe pola.

7.5.2. Dokument finansowy

1) Pola do uzupełnienia

a) Data wystawienia

b) Termin płatności

c) Numer zewnętrzny

d) Rodzaj dokumentu

Faktura lub inny dokument finansowy wymagający opisy

Inny dokument


Strona 38 z 52

Opłaty administracyjne

ZFŚS

Zakupy zapłacone z zaliczki

e) Osoba odpowiedzialna

f) Forma płatności

Barter

Gotówka

Przelew

Wydatek zrealizowany ze środków własnych/zwrot na konto

Zapłacono

Zapłacono na podstawie faktury pro forma

Zapłacona kartą służbową

ZFŚS

g) Pozycje dokumentu finansowego (minimum 1) wraz z kwotą netto i brutto

h) Skan faktury

i) Numer zapotrzebowania powiązanego

7.5.3. Pozycja dokumentu finansowego


a) Powiązanie z zadaniem, działaniem, umową, zapotrzebowaniem, delegacją,

sprawą, zaliczką.

b) Nazwa towaru/usługi

c) Cel zakupu/przeznaczenie

d) Numer konta Zakładowego planu kont - słownik

e) Wydatek: bieżący/inwestycyjny/publikacje

f) Rodzaj rozliczenia zapotrzebowania: częściowe lub końcowe

g) Rodzaj rozliczenia umowy: częściowe, końcowe, nie dotyczy

7.5.4. Obieg faktury

1) Po opisaniu faktury uruchamiamy obieg.

2) Akceptacja kuratora zadania

3) Akceptacja dysponenta planu

4) Akceptacja zamówień publicznych (po akceptacji generowany jest opis dokumentu

finansowego)

5) Zatwierdzenie przez dział ekonomiczno-finansowy oraz dokonanie płatności

6) Zakończenie obiegu, oraz wprowadzenie do rejestru faktur

7) Podobnie jak w przypadku każdego obiegu generowana jest metryka.

8) W przypadku braku akceptacji na dowolnym kroku obiegu, dokument wraca do

inicjatora celem uzupełnienia.

7.5.5. Dodawanie rachunku do umowy cywilno-prawnej

Dysponent planu skanuje rachunek uzupełniony o przepracowaną liczbę godzin

oraz stawkę, wybiera rodzaj dokumentu – rachunek do umowy cywilno-prawnej ,

powiązuje rachunek z kontrahentem wybieranym z bazy firm oraz analogicznie jak

w przypadku faktury opisuje wszystkie pola.

Po uruchomieniu obiegu, rachunek wędruje do płac gdzie jest rozliczany.


Strona 39 z 52


Powiadomienie mailowe o zakończeniu obiegu wysyłane do inicjatora

7.5.7. Inne

1) Faktura nie może być wyższa (netto) od powiązanego zapotrzebowania oraz umowy

z uwzględnieniem aneksów,

2) Prawa dostępu – inicjator lub wykonawcy w obiegu mogą dopisać osobę lub dział,

3) Komentarze,

4) Po powiązaniu danej faktury z zapotrzebowaniem automatycznie pojawiają się

dodatkowe informacje zaczytywane bezpośrednio z karty „zapotrzebowania”:

a) Typ wydatku

b) rodzaj zamówienia

7.6. Obieg umów:

Proces obiegu umów ma umożliwiać złożenie kwalifikowanego podpisu elektronicznego

na umowie przez osoby reprezentujące Muzeum. Zakłada się obieg ok. 2 tys. umów

rocznie.

7.6.1. Tworzenie umowy

1) Pola uzupełniane automatycznie

a) Osoba odpowiedzialna - inicjator


a) Przedmiot umowy

b) Rodzaj umowy:

Barterowe/sponsoring

Bez rozliczeń finansowych/darowizny

Bez rozliczeń finansowych/konserwacja obiektu

Bez rozliczeń finansowych/najmu

Bez rozliczeń finansowych/udostępnienia dokumentacji, danych, zdjęć

Bez rozliczeń finansowych/wolontariat

Bez rozliczeń finansowych/współpracy

Bez rozliczeń finansowych/wykonywanie zdjęć i filmowanie

Bez rozliczeń finansowych/wykorzystanie zdjęć i zgoda na publikacje

Bez rozliczeń finansowych/wypożyczenia obiektów

Bez rozliczeń finansowych/ze studentami/praktyki studenckie

Bez rozliczeń finansowych/ze studentami/udostępnienia dokumentacji,

danych, zdjęć

Bez rozliczeń finansowych/ze studentami/wolontariat

Przychodowe/dezynfekcja

Przychodowe/konserwacja obiektu

Przychodowe/kupna – sprzedaży

Przychodowe/najmu

Przychodowe/o dzieło i bez praw autorskich

Przychodowe/współpracy

Przychodowe/wykonywanie zdjęć i filmowania


Strona 40 z 52

Przychodowe/wykorzystanie zdjęć i zgoda na publikację

Przychodowe/zlecenie

Rozchodowe/konserwacja obiektu

Rozchodowe/kupna – sprzedaży

Rozchodowe/o dzieło z prawami autorskimi i bez praw/z firmami

Rozchodowe/o dzieło z prawami autorskimi i bez praw/z osobami fizycznymi

Rozchodowe/o dzieło z prawami autorskimi i bez praw/ z osobami fizycznymi

prowadzącymi działalność gospodarczych

Rozchodowe/w trybie zamówień publicznych

Rozchodowe/współpracy

Rozchodowe/wykorzystanie zdjęć i zgoda na publikację

Rozchodowe/wypożyczenia obiektów

Rozchodowe/zlecenie

Rozwiązanie umowy

Inny rodzaj umowy

c) Tryb zawarcia umowy - 6-15 pozycji listy rozwijalnej (dowolnie modyfikowany

przez pracownika ds. zamówień publicznych posiadającego odpowiednie

uprawnienia):

d) Wymagana akceptacja formalno-prawna (checkbox)

e) Umowa rozchodowa cywilno-prawna z osobą fizyczną (checkbox). Po

zaznaczeniu wybieramy pomiędzy umową zlecenie a umową o dzieło.

f) Kwota umowy netto

g) Kwota umowy brutto (jeśli zaznaczono umowę rozchodową cywilno-prawną,

kwota brutto powinna zostać wyliczona automatycznie)

h) Termin rozpoczęcia umowy

i) Termin zakończenia umowy: określony, nieokreślony

j) Data obowiązywania gwarancji: określona (wskazać do kiedy), brak gwarancji

k) Data wystawienia FV przez kontrahenta

l) Pole na szablon umowy w pliku Word lub PDF

m) Pole na załączniki

n) Umowa wieloletnia lub posiadająca wiele pozycji (checkbox)

o) Powiązanie z zadaniem, działaniem, , kontrahentem wybieranym z bazy firm

oraz numerem sprawy

p) Numer zapotrzebowania powiązanego (obowiązkowe)

7.6.2. Obieg umowy (w zależności od zadeklarowanego trybu zawarcia umowy)

1) Wariant nr 1 dla umów zawieranych w trybie innym niż tryb ustawy Pzp:

a) Inicjator uruchamia obieg (automatycznie nadawany jest numer umowy)

b) Akceptacja kuratora zadania

c) Akceptacja dysponenta planu

d) Akceptacja prawnika (w przypadku zaznaczonego checkboxa o wymaganej

akceptacji formalno-prawnej)

e) Akceptacja sekcji zamówień publicznych (w przypadku umowy bezkosztowej, krok

pomijany)


Strona 41 z 52

f) Akceptacja zastępcy dyrektora

g) Akceptacja głównego księgowego

h) Akceptacja dyrektora

i) Skanowanie umowy podpisanej obustronnie.

2) Wariant nr 2 dla umów zawieranych w trybie ustawy Pzp

a) Inicjator uruchamia obieg wzoru umowy (automatycznie nadawany jest numer

umowy)

b) Akceptacja kuratora zadania

c) Akceptacja dysponenta planu

d) Akceptacja prawnika

e) Akceptacja sekcji zamówień publicznych

f) Akceptacja zastępcy dyrektora

g) Akceptacja głównego księgowego

h) Akceptacja dyrektora

i) Uzupełnienie danymi kontrahenta przez inicjatora

j) Sprawdzenie zgodności dokumentów przez sekcję zamówień publicznych (w

przypadku braku akceptacji wracamy do czynności powyżej)

k) Skanowanie umowy podpisanej obustronnie.

3) Po zakończeniu obiegu generowana jest metryka obiegu oraz aktualizowany jest

rejestr umów a także rejestry dokumentów powiązanych.


1) Powiadomienia mailowe o zatwierdzeniu umowy przez Dyrekcję, uzupełnieniu

danych kontrahenta, wydruku umowy do podpisu, zakończeniu obiegu.

2) Powiadomienie mailowe do płac w przypadku zakończenia obiegu umowy cywilno-

prawnej.

3) W przypadku umów niepodpisanych ponad miesiąc powiadomienie do dysponenta

planu oraz kuratora zadania

4) W przypadku rozliczenia umowy cywilno-prawnej powiadomienie do płac oraz

kuratora

5) W przypadku bliskiego wykorzystania środków w umowie, powiadomienie do

kuratora.

7.6.4. Inne

1) Możliwość elektronicznego podpisu umów przez Dyrekcję, podpisy blokami

2) Możliwość dodawania aneksów z poziomu umowy oraz możliwość podglądu kwoty

umowy po uwzględnieniu aneksów

3) Możliwość podglądu dokumentów powiązanych z umową (np. faktury)

4) Komentarze

5) Prawa dostępu – inicjator lub wykonawcy w obiegu mogą dopisać osobę lub dział

6) Nr wewnętrzny nadawany wg osoby odpowiedzialnej.

7) Po powiązaniu danej umowy z zapotrzebowaniem automatycznie pojawiają się

dodatkowe informacje zaczytywane bezpośrednio z karty ‘zapotrzebowania’:

a) Typ wydatku

b) rodzaj zamówienia


Strona 42 z 52

7.7. Obieg delegacji:

7.7.1. SZPM musi posiadać moduł delegacji umożliwiający rozliczanie delegacji

pracownikom posiadającym konto w SZPM.

7.7.2. Administrator SZPM musi mieć możliwość nadawania uprawnienia użytkownikom do

administrowania delegacjami lub uprawnienie tylko do wprowadzania delegacji w

zakresie jednostek organizacyjnych Zamawiającego.

7.7.3. Moduł delegacji musi umożliwiać wprowadzenie delegacji oraz – po zakończeniu

delegacji, na jej rozliczenie.

7.7.4. Użytkownik posiadający uprawnienia do administrowania delegacjami, musi posiadać

dostęp do:

1) Delegacji do zatwierdzenia

2) Dokumentów (dołączanych do delegacji)

3) Podziału na delegacje odbywane samochodem prywatnym, służbowym oraz innymi

środkami transportu (kolej, autobus, samolot)

4) Opcji umożliwiającej masowe zatwierdzanie delegacji.

7.7.5. Moduł delegacji musi pozwalać użytkownikowi na wprowadzenie informacji o

delegacji poprzez wypełnienie formularza. Formularz delegacji musi zawierać

następujące pola:

1) Numer delegacji (generowany automatycznie)

2) Pełniona funkcja

3) Miejsce wyjazdu

4) Czas trwania delegacji – godzina wyjazdu i godzina powrotu

5) Cel delegacji

6) Uzasadnienie delegacji

7) Środki lokomocji

8) Wyżywienie (delegacja z wyżywieniem lub bez)

9) Zastępca

10) Uwagi i komentarze.

7.7.6. SZPM musi automatycznie definiować zastępstwo w przypadku, gdy użytkownik

wypełniając formularz delegacji zdefiniuje zastępcę.

7.7.7. SZPM musi pozwalać wybranym użytkownikom na rozliczanie i zatwierdzanie

delegacji.

7.7.8. SZPM na liście delegacji musi prezentować i odpowiednio zmieniać automatycznie

status delegacji.

7.8. Wnioski urlopowe:

7.8.1. Moduł urlopy musi umożliwiać uprawnionemu użytkownikowi wprowadzenie

informacji niezbędnych do poprawnego wyliczania ilości dostępnego urlopu.

7.8.2. Moduł powinien pozwalać na wprowadzenie takich informacji jak:

1) Ilość dostępnego urlopu na żądanie (zaległy oraz bieżący)

2) Ilość dostępnego urlopu z tytułu opieki nad dzieckiem

3) Ile godzin ma dzień roboczy dla pełnego etatu.


Strona 43 z 52

7.8.3. SZPM w części pozwalającej na określenie uprawnień użytkowników do modułu

urlopu musi umożliwiać określenie przynajmniej:

1) Czy użytkownik posiada uprawnienia do raportów dotyczących wykorzystania

urlopów?

2) Czy uprawnienia dotyczące zarządzania urlopami dotyczą wszystkich pracowników

czy tylko wybranych?

3) Czy użytkownik posiada uprawnienia do anulowania wniosków urlopowych?

7.8.4. W przypadku zmiany uprawnień do modułu urlopów, SZPM musi zapisywać w

historii listę tych zmian.

7.8.5. Użytkownik posiadający uprawnienia administrowania urlopami powinien mieć

możliwość wprowadzenia dla pracowników informacji o ich zatrudnieniu. SZPM musi

umożliwiać, użytkownikowi definiującemu dane o zatrudnieniu pracownika,

wprowadzenie co najmniej następujących informacji:

1) Data od kiedy pracownik jest zatrudniony

2) Data do kiedy pracownik jest zatrudniony lub na określenie, że okres zatrudnienia

nie jest ograniczony

3) Wymiar etatu np. ½, ¼, itd.

4) Podstawa urlopu (pierwsza praca, 20 dni, 26 dni)

5) Opieka nad dzieckiem

6) Urlopy dodatkowe


7.8.6. Użytkownik posiadający uprawnienia do administrowania urlopami pracowników

musi posiadać dostępną funkcję obliczenia urlopu, która pozwoli na obliczenie urlopu

na podstawie danych o zatrudnieniu pracownika.

7.8.7. SZPM musi umożliwiać wygenerowanie szczegółowego raportu dotyczącego

wykorzystania urlopów pracownikowi posiadającemu odpowiednie uprawnienia.

Raport powinien w sposób tabelaryczny przedstawiać ilość wykorzystanego urlopu w

godzinach i minutach, dla każdego z typu urlopów oraz sumę. Zestawienie powinno

jednocześnie pokazywać wszystkich pracowników, do których użytkownik posiada

uprawnienia administracji urlopami.

7.8.8. SZPM w mechanizmie urlopów powinien dzielić się na następujące foldery/zakładki:

1) Nowe

2) Zweryfikowane

3) Zaakceptowane

4) Anulowane.

7.8.9. W przypadku akceptacji na kroku obiegu, kolejny wykonawca otrzyma

powiadomienie mailowe.

7.8.10. SZPM podczas wprowadzania nowego urlopu musi umożliwiać wprowadzenie w

formularzu elektronicznym następujących informacji:

1) Rok

2) Data od

3) Data do

4) Długość urlopu w dniach i godzinach z przeliczeniem na godziny

5) Rodzaj urlopu


Strona 44 z 52

6) Zastępca (z możliwością wyboru z listy pracowników)


7.8.11. Wymagana integracja modułu urlopy z posiadanym przez Zamawiającego systemem

UniRCP firmy Unicard.

7.8.12. Możliwość wydrukowania wniosków urlopowych.

7.8.13. Możliwość tworzenia planu urlopowego dla komórek organizacyjnych.

7.9. Tworzenie i korekty budżetu Muzeum:

7.9.1. Proces ma za zadanie umożliwić przygotowanie budżetu dla poszczególnych zadań

oraz wprowadzanie korekt do budżetu w trakcie roku budżetowego.

1) Projekt budżetu/budżet powinien generować się automatycznie w oparciu

o zatwierdzone zadania/działania,

2) Przesunięcia środków między działaniami mogą następować na wniosek osoby

odpowiedzialnej za działanie w porozumieniu z kuratorem zadania, wniosek

rozpatruje dysponent planu, po dokonaniu zmiany informacje otrzymuje Główny

Księgowy,

3) Przesunięcia między zadaniami mogą następować na wniosek kuratora zadania do

dysponenta planu, po pozytywnym rozpatrzeniu dysponent zwraca się

z wnioskiem do Głównego Księgowego (w przypadku kwoty mniejszej niż 30 000,00

zł zgoda/brak zgody), (w przypadku kwoty wyższej niż 30 000,00 wymagane jest

ponowienie decyzji o ustanowieniu zadania),

4) Aktualizacje budżetu z poziomu głównego księgowego.

7.10. Tworzenie planu zamówień publicznych:

7.10.1. Etap - przygotowanie w dziale merytorycznym:

1) Każdy z działów wypełnia swoją tabelę planu zamówień publicznych – dalej jako

„tabela planu” stanowiąca formularz w systemie,

2) Uprawnienia do uzupełniania tabeli planu powinien mieć każdy kto wydatkuje

środki finansowe,

3) Możliwość edycji na każdym etapie przygotowania tabeli planu dla wszystkich

uprawnionych.

4) Wypełnioną tabelę planu zatwierdza dysponent planu,

5) Po zatwierdzeniu, tabela planu wędruje na krok obiegu zamówień publicznych,

6) Pracownik ZP może dokonać eksportu tabeli do Excela wg dowolnie wskazanego

kryterium jak i wszystkich kryteriów od razu.

7.10.2. Etap - przygotowanie w ZP:

1) Zatwierdzone tabele planu z różnych działów Muzeum wpływają do ZP,

automatycznie tworząc jeden dokument.

2) Ewentualne zmiany w tabeli planu z danego działu (po zatwierdzeniu przez

dysponenta planu) możliwe są jedynie po cofnięciu przedmiotowej tabeli przez ZP

na krok obiegu danego dysponenta planu.

3) Pracownik ZP może dokonać eksportu tabeli do Excela wg dowolnie wskazanego

kryterium jak i wszystkich kryteriów od razu.

4) Pracownik ZP może dokonać importu tabeli planu z Excela do systemu.


Strona 45 z 52

5) Pracownik ZP ma możliwość (po dokonanej przez siebie korekcie) rozesłania do

poszczególnych działów tabel planu dotyczących ich zamówień celem dokonania

przez te działy (dysponentów planu) ostatecznej weryfikacji i akceptacji

6) Po ostatecznej akceptacji tabela z powrotem trafia na krok ZP

7) ZP tworzą zbiorcze tabele planu dla całego Muzeum

8) Zbiorcza tabela przechodzi krok Pełnomocnika Dyrektora ds. zamówień

publicznych, Zastępcy Dyrektora, Głównego Księgowego i ostatecznie Dyrektora.

9) W przypadku uwag Zastępcy Dyrektora, Gł. Księgowego, Dyrektora, dokument z ich

uwagami trafia z powrotem na krok obiegu ZP celem ustosunkowania się do

przedmiotowych uwag.

10) Pracownik ZP ma możliwość (celem właściwej reakcji na uwagi Dyrekcji)

ponownego rozesłania do poszczególnych działów tabel planu dotyczących ich

zamówień celem dokonania przez te działy (dysponentów planu) kolejnej ich

weryfikacji i akceptacji.

11) Czynności, o których mowa w dwu powyższych punktach, mogą być powtarzane aż

do akceptacji zbiorczej tabeli planu przez całą Dyrekcję Muzeum.

7.11. Raport realizacji budżetu:

Raport powinien się generować w oparciu o gromadzone w systemie SZPM dane. W

raporcie powinny się znaleźć, co najmniej dane przedstawione w poniższej tabeli:


Strona 46 z 52

BUDŻET MUZEUM PAŁACU KRÓLA JANA III W WILANOWIE NA 2018 ROK;

REALIZACJA NA DZIEŃ 31 GRUDNIA; PO KOREKCIE NA DZIEŃ 30 CZERWCA 2018 ROKU

DZIAŁ MUZEUM/

PROJEKT/ SYMBOL

ZADANIE/

SYMBOL

DZIAŁANIE/

SYMBOL

OSOBA

ODPOWIEDZIALNA

ZA ZADANIE

KOD BUDŻETU

ZADANIOWEGO

PAŃSTWA

PLAN 2018

ROK

NETTO

OGÓŁEM

REALIZACJA

NA DZIEŃ

31.12.2018

PLAN

BIEŻACYCH

KOSZTÓW

KOSZTY

PLAN

INWESTYCJI,

WYDAWNICTW,

DZIEŁASZTUKI,

MAGAZYN;

INWESTYCJE,

WYDAWNICTWA,

DZIEŁA SZTUKI,

MAGAZYN;

RAZEM DZIAŁ

PREWENCJI I

KONSERWACJI

501

0 0 0 0 0 0

… (1) 0

…(1)

…(2)

… (2) 0

…(1)

…(2)

RAZEM DZIAŁ

ARCHITEKTURY I

ŚRODOWISKA

502

0 0 0 0 0 0

… (1)

…(1)

…(2)

RAZEM DZIAŁ OBSŁUGI

PUBLICZNOŚCI

503


Strona 47 z 52

… (1)

…(1)

…(2)

RAZEM DZIAŁ

DOKUMENTACJI I

CYFRYZACJI

504

0 0 0 0 0 0

… (1)

…(1)

…(2)

RAZEM DZIAŁ

EDUKACJI MUZEALNEJ

505

0 0 0 0 0 0

… (1)

…(1)

…(2)

RAZEM DZIAŁ

REKONSTRUKCJI

HISTORYCZNEJ I

SPRZEDAŻY

506

0 0 0 0 0 0

… (1)

…(1)

…(2)

RAZEM DZIAŁ

OGRODOWY

507

0 0 0 0 0 0


Strona 48 z 52

… (1)

…(1)

…(2)

RAZEM DZIAŁ

ADMINISTRACJI

508

0 0 0 0 0 0

… (1)

…(1)

…(2) 0 0

RAZEM DZIAŁ SZTUKI

509 0 0 0 0 0 0

… (1) 0

…(1)

…(2)

RAZEM DZIAŁ STRAŻY

PAŁACOWEJ

510

0 0 0 0 0 0

… (1)

…(1)

…(2) 0 0

RAZEM DZIAŁ

ROZWOJU

511

0 0 0 0 0 0

… (1)

…(1)

…(2) 0


Strona 49 z 52

RAZEM DZIAŁ

KOMUNIKACJI

SPOŁECZNEJ

512

0 0 0 0 0 0

… (1)

…(1)

…(2) 0 0

RAZEM DZIAŁ

INWESTYCJI

513

0 0 0 0 0 0

… (1)

…(1)

…(2)

RAZEM DZIAŁ

ZASOBÓW PRACY

514

0 0 0 0 0 0

… (1)

…(1)

…(2)

RAZEM KOSZTY

OGÓLNOZAKŁADOWE

550

0 0 0 0 0 0

… (1)

…(1)

…(2)


Strona 50 z 52

RAZEM KOSZTY

PROJEKTÓW

56…

0 0 0 0 0 0

… (1)

…(1)

…(2)

OGÓŁEM ZADANIA

MUZEUM 0 0 0 0 0 0

* KOSZTY ADMINISTRACYJNE OGÓLNOMUZEALNE DOTYCZĄ WYDATKÓW ZWIĄZANYCH Z BIEŻĄCYM POPRAWNYM FUNKCJONOWANIEM MUZEUM. ZALICZA SIĘ DO NICH W

PODZIALE NA: DZIAŁ ARCHITEKTURY I ŚRODOWISKA (GAZ, ENERGIĘ ELEKTRYCZNĄ, WODĘ); DZIAŁ ADMINISTRACJI (USŁUGI TELEKOMUNIKACYJNE, USŁUGĘ SPRZĄTANIA,

PALIWO I PRZEGLĄDY SAMOCHODOWE, USŁUGI POCZTOWE, ART. BIUROWE I PIŚMIENNE, ŚRODKI CZYSTOŚCI);

** KOSZTY ZARZĄDU DOTYCZĄ WYDATKÓW TAKICH JAK: REPREZENTACJA I REKLAMA (W TYM USŁUGI I MATERIAŁY), PODATKI I OPŁATY, BIEŻĄCA OBSŁUGA PRAWNA, PFRON;


Strona 51 z 52

7.12. Raport realizacji zamówień publicznych:

Raport powinien zawierać rozliczenie zamówień/postępowań ze względu na typy

wydatków. System winien umożliwiać generowanie raportów w postaci eksportu tabeli

do Excela wg dowolnego zakresu dat jak i rodzaju zamówienia w podziale na

zatwierdzone zapotrzebowania i umowy i powiązane z nimi faktury i rachunki.

7.13. Sprawozdanie merytoryczne z działalności Muzeum:

7.13.1. Częstotliwość generowania sprawozdań:

1) po półroczu

2) po 3 kwartale

3) na koniec roku

7.13.2. Raport powinien zawierać możliwie rozbudowane dane opisowe [tekst] i liczbowe

[wskaźniki], wygenerowane:

1) po półroczu

2) po 3 kwartale

3) na koniec roku

7.13.3. Raport powinien zawierać możliwie rozbudowane dane opisowe [tekst] i liczbowe

[wskaźniki], wygenerowane z zasobów architektury „Projekt-Pomysł-Zadanie”, bazy

kontrahentów oraz zasobów Kadrowo-Płacowych (dane nt. liczby i struktury

wiekowej pracowników).

7.13.4. System powinien umożliwiać generowanie raportów w postaci eksportu pliku

tekstowego /elementów tabeli wg dowolnego zakresu dat jak oraz swobodnego

wyboru zakresu kryteriów, z możliwą siatką filtrów (chronologicznie, wg autora, etc.).

7.13.5. Kategorie w raporcie*:

1) Działalność wystawiennicza

2) Publikacje

3) Działalność naukowa (seminaria, debaty, konferencje projektu naukowo-badawcze,

etc.)

4) Działalność edukacyjna

5) Zakupy/ Dary/ Przekazy/ Depozyty

6) Inwentaryzacja/ Wypożyczenia

7) Dokumentacja zbiorów

8) Zastosowanie technik informatycznych

9) Konserwacja

10) Ochrona budynków i muzealiów

11) Współpraca z zagranicą

12) Działalność promocyjna

13) Frekwencja

14) Pracownicy przedział wiekowy

15) Usługi firm zewnętrznych

16) Umowy najmu/ Zobowiązania prawne

17) Przedsięwzięcia MKiDN

18) Realizowane projekty inwestycyjne

19) Inne ważne


Strona 52 z 52

*w celu zapewnienia odpowiedniego zasobu wyjściowego danych do generowania

raportu należy przewidzieć w strukturze Pomysł Projekt Zadanie odpowiednie

pola wyboru (zaznaczenia) do jakiej kategorii odwołuje się dane działanie

(przewiązanie z liczbą wskaźników).

7.13.6. Ostateczna forma, zakres funkcjonalności i końcowy kształt raportu do

rozstrzygnięcia na etapie projektowym.

7.14. Raporty dotyczące wymaganych procesów kadrowych:

Raporty zostały opisane przy okazji opisu procesów kadrowych.

Załączniki:

1) załącznik nr 1 - schemat struktury organizacyjnej Muzeum,

2) załącznik nr 2 - oczekiwania Zamawiającego dotyczące kierunku rozwoju procesu pomysł-

projekt-zadanie.

Documents

A. przygotowaniu opisu funkcjonalnego Systemu Muzeum · 21) Monitorowane są w logach serwera wszystkie zmiany w bazie danych, dokonywane z poziomu aplikacji 22) Dostarczona baza