Załącznik nr 2

SPECYFIKACJA / OPIS PRAC

Cel projektu to zmniejszenie liczby mandantów w ramach systemów SAP HCM KP4 / KT4 z zachowaniem pełnej funkcjonalności i zakresu danych. Projekt będzie dotyczył wszystkich spółek innogy w Polsce, których dane utrzymywane są bądź były w środowisku SAP KP4 / KT4.

W ramach przygotowywanych wycen oraz propozycji harmonogramów realizacji projektu należy uwzględnić dwa możliwe warianty przeprowadzenia prac:

- scalenie mandantów do jednego z istniejących

- migracja do nowego mandanta.1. Podział systemo� w:dev_400 innogy Polska

innogy Stoen Operator

KT4 test_420 innogy Polskainnogy Stoen Operator

dev/test_460 innogy BS Polska

prod_400 innogy Polska

KP4innogy Stoen Operator

prod_460 innogy BS Polska

2

2. Rys historyczny systemu:DATY

ZMIANY SPÓŁEK MANDANT OK JO OR

przejęcia art. 23'

migracja pracowników Uwagi

40003.2005 Stoen (RWE Polska) 890 1 Start systemu03.2005 12.2007 Stoen Info 891

07.2007 RWE Stoen Operator 896 6

600 - te same numery osobowe

10.2014RWE IT Poland -> RWE Polska 890

15 - zmiana numerów osobowych

09.2016RWE Polska -> innogy Polska 890

09.2016

RWE Stoen Operator -> innogy Stoen Operator 896

460

01.2008Stoen Info - RWE IT Poland

4452 0452

60 - te same numery osobowe

nowy zakres numerów osobowych 46520000

09.2013 31.12.2014 RWE GBS Polska443

7 0437

nowy zakres numerów osobowych 46370000

10.2014 04.01.2015RWE Polska -> RWE IT Poland

4452 0452

01.01.2015 nadal RWE GBS Polska

4444 0452 47 cd. 4637xxxx

05.01.2015 nadal

RWE IT Poland - RWE GBS Polska

4454 0452 46

100 - te same numery osobowe cd. 4637xxxx

09.2016 nadalRWE GBS Polska -> innogy BS Polska

4454 0452

46 47

100 - te same numery osobowe cd. 4637xxxx

3

3. Generalne załoz�enia do połączenia mandanto� w – wariant 1 - scalenia do istniejącego mandantaW projekcie połączenia mandatów 400 i 460 zakłada się wykonanie poniższych zadań:

1. Mandatem podstawowym, na którym uzupełniana będzie konfiguracja i wykonywane będą modyfikacje - będzie mandant dev_400.

2. Przed rozpoczęciem projektu klient zadba o odpowiednie przygotowanie mandanta dev_400 – zwolnione zostaną wszelkie nieprzeniesione transporty, wykonawca uzyska zapewnienie, że konfiguracja mandanta 400 na systemach: test_400, test_420 oraz pro_400 jest jednolita.

3. Na mandancie dev_400 utworzony zostanie jeden wspólny transport projektowy, w którym zapisywane będą wszelkie zmiany.

4. Na mandancie dev_400 zostanie utworzona skonsolidowana konfiguracja uwzględniająca elementy mandanta dev_460. Pojedyncze elementy konfiguracji mogą być przenoszone mechanizmami takimi jak transakcja SCC1.

5. W trakcie trwania projektu zamrożone zostaną wszelkie zmiany konfiguracji (nie będzie możliwości wykonywania zmian w istniejącej konfiguracji we wszystkich obszarach podlegających połączeniu). Dopuszczalne będzie dodawanie nowej konfiguracji tylko w wyjątkowych sytuacjach po uprzedniej konsultacji i zatwierdzeniu przez klienta i zespół projektowy. Każda taka zmiana będzie musiała być zapisana do odrębnego transportu (do przeniesienia natychmiast) oraz do transportu projektowego.

6. Równolegle do prac konfiguracyjnych prowadzonych na mandancie dev_400 przygotowywany będzie test_420 – mandant zostanie odświeżony kopią systemu produkcyjnego mandant prod_400 oraz zasilony migracyjnie (wybranym przez klienta narzędziem) pełnymi danymi pracowników z mandanta prod_460

7. Po przygotowaniu uzupełnionej ujednoliconej konfiguracji na mandancie dev_400 transport projektowy zostanie przeniesiony na system testowy mandant test_420

8. Na przygotowanym systemie testowym, mandat test_420, zasilonym danymi z obu systemów produkcyjnych wykonane zostaną wszystkie testy w tym testy równoległej ewidencji i rozliczenia czasu pracy oraz płac

9. Po akceptacji testów transport ze zmianami projektowymi zostanie przeniesiony na system produkcyjny mandant prod_400.

10. Nie zakłada się renumeracji pracowników oraz obiektów struktury organizacyjnej11. Zakłada się rozdzielność regulaminów i schematów po przeniesieniu na jeden mandant12. Zakłada się jednolitość procesów samoobsługi13. Zmiany mogą dotyczyć w poszczególnych obszarach:

a. zmian w programach ABAPb. Dostosowania systemu do nowej skonsolidowanej konfiguracjic. Przygotowania narzędzi migracji i konwersji danych z mandanta 460 na mandant 400

4

14. Zakłada się wykorzystanie jednego narzędzia do migracji danych pomiędzy mandantami we wszystkich analizowanych modułach

15. Zakłada się pełną migrację wszystkich danych z mandanta prod_4604. Generalne załoz�enia do połączenia mandanto� w – wariant 2- utworzenia nowego mandantaW projekcie połączenia mandatów 400 i 460 zakłada się wykonanie poniższych zadań:

1. Mandatem podstawowym, na którym uzupełniana będzie konfiguracja i wykonywane będą modyfikacje - będzie nowoutworzony mandant deweloperski np. dev_500

2. Klient odpowiada za wyrównanie mandantów (dev_400, test_420 i prod_400) pod względem konfiguracji w tym za przeniesienie wszystkich modyfikowalnych transportów. Następnie Klient wykona kopię mandanta dev_400 na dev_500.

3. Na mandancie dev_500 utworzony zostanie jeden wspólny transport projektowy, w którym zapisywane będą wszelkie zmiany.

4. Na mandancie dev_500 zostanie utworzona skonsolidowana konfiguracja uwzględniająca elementy mandantów dev_400 i dev_460.

5. W trakcie trwania projektu wszelkie zmiany konfiguracji wykonywane na mandantach dev_400 i dev_460 będą wymagały powtórzenia (przekopiowania) na mandant dev_500 Dopuszczalne będzie dodawanie nowej konfiguracji tylko w wyjątkowych sytuacjach po uprzedniej konsultacji i zatwierdzeniu przez klienta i zespół projektowy. Każda taka zmiana będzie musiała być zapisana do odrębnego transportu (do przeniesienia natychmiast) oraz do transportu projektowego.

6. Równolegle do prac konfiguracyjnych prowadzonych na mandancie dev_500 przygotowywany będzie system testowy mandant test_520 – mandant zostanie odświeżony kopią systemu produkcyjnego mandant prod_400 oraz zasilony migracyjnie (wybranym przez klienta narzędziem) pełnymi danymi pracowników z mandanta produkcyjnego prod_460.

7. Po przygotowaniu uzupełnionej ujednoliconej konfiguracji na mandancie dev_500 transport projektowy zostanie przeniesiony na system testowy mandant test_520

8. Na przygotowanym systemie testowym, mandat test_520, zasilonym danymi z obu systemów produkcyjnych wykonane zostaną wszystkie testy w tym testy równoległej ewidencji i rozliczenia czasu pracy oraz płac

9. Po akceptacji testów transport ze zmianami projektowymi zostanie przeniesiony na system produkcyjny mandant prod_500.

10. Nie zakłada się renumeracji pracowników oraz obiektów struktury organizacyjnej11. Zakłada się rozdzielność regulaminów i schematów po przeniesieniu na jeden mandant12. Zakłada się jednolitość procesów samoobsługi13. Zmiany mogą dotyczyć w poszczególnych obszarach :

a. zmian w programach ABAP

5

b. Dostosowania systemu do nowej skonsolidowanej konfiguracjic. Przygotowania narzędzi migracji i konwersji danych z mandantów 400 i 460 na mandant

50014. Zakłada się wykorzystanie jednego narzędzia do migracji danych pomiędzy mandantami we

wszystkich analizowanych modułach15. Zakłada się pełną migrację wszystkich danych z mandantów prod_400 i prod_460

6